前回、Aras Innovator の基本構成について概観し、システム全体を「Innovatorサーバ」や「Vaultサーバ」などで構成していることや、インストール時に3つのプレパッケージソリューション（PE、PM、QP）がArasフレームワークとともに導入されていることをお話しました。また、Arasフレームワークの中心は「アイテムタイプ」であるということもお話しました。 今回はこの「アイテムタイプ」について、見ていきたいと思います。
「アイテムタイプ」とは
Arasフレームワークの構成要素には多種多様なものが存在しますが、その中心的役割を担うのが「アイテムタイプ」です。
「アイテムタイプ」は、IT的な用語で言うと「クラス」や「エンティティ」（≒DBテーブル）に相当するものです。
もう少し平易な言葉で言うと、 「パーツや文書、受注や出荷指示などの情報を台帳管理している場合の、その 『台帳ファイル』 と 『記入用紙』 」 に相当するものと考えて頂いても結構です。
要するに、情報管理のための 「入れ物」 ないし 「テンプレート」 が「アイテムタイプ」ということです。
先に「アイテムタイプ」が中心的役割を担うと述べましたが、それはこのように、アイテムタイプにより 「対象物をどのように情報管理するか」の骨格 が規定されるためです。
アイテムタイプによって規定される内容には・・・
- どのような項目（属性、プロパティ）を管理するか？
- 例） アイテムタイプ「パーツ」では、「品番」、「名称」、「内外製区分」、…を管理しよう。
- どの項目をキーにするか？
- 例） アイテムタイプ「パーツ」の「品番」項目は重複するとマズイから「一意」（ユニーク）に設定しよう。
- 世代管理するかどうか？
- 例） アイテムタイプ「パーツ」では、個々のパーツの情報を世代管理させよう（更新前の情報も取っておこう）。
・・・などがあります。
そしてこれらに肉付けする形で、アクセス権や情報の見せ方（画面）、ライフサイクルやワークフローなどの設定を追加していき、システム的な情報管理方法が最終的に決定されるのです。
何を「アイテムタイプ」にすべきか
では、どんなものを「アイテムタイプ」にすれば良いのでしょうか？ ITエンジニアの方ですと、オブジェクトモデリングやデータモデリングなどの手法はお馴染みかと思いますので、申し上げるべきことは何も無いです。いつも通りモデリングしてエンティティ抽出してください。抽出されたエンティティこそが「アイテムタイプ」です。
ITエンジニアでない方、IT的なモデリングに馴染みのない方向けに、すごく割り切って申し上げると、
業務的な番号やコードで識別されるモノ・コト ＝ アイテムタイプ
です。 （割り切っていますが、別に独創というわけではなく、この基準に依拠して理論構築しているモデリング手法も存在します。「T字形 TM」とかで検索してみてください。上記はむしろ、この手法からの借用です）
例えば、
- 商品 （識別子： 商品コード）
- 部品 （識別子： 部品番号、品目コード）
- 文書 （識別子： 文書番号）
- 工場 （識別子： 工場コード）
- 受注 （識別子： 受注番号）
- 出荷手配 （識別子： 出荷手配番号）
などが「アイテムタイプ」の候補となります。 なお、「商品名」などは「商品コード」で識別されますので（商品コードが分かれば商品名が分かる）、「商品」アイテムタイプの属性（プロパティ）ということになります。
この辺り、ちゃんとやるには ある程度の熟練が必要ですが、「こんな感じ」でやっても あながち的外れにはなりませんし、書店には関連書籍が溢れ返っていますので、是非チャレンジして頂けたらと思います。
向いているアプローチ
「アイテムタイプが中心です」という話をしていますので、当然「アイテムタイプ中心・アイテムタイプ先行」のアプローチ、言い換えると「データモデル中心」のアプローチが適しています。ただ従来のこういったアプローチは、得てして抽象的な図表や抽象的な言葉でいっぱいで、とてもではないけれど「ユーザ部門が中心となって」とは言えないものでした。
これに対し Aras Innovator では、 設定してすぐに画面上で具体的なデータをもとに確認できる という特長がありますので、
「モデリング」→「プロトタイプ」→「モデリング」→「プロトタイプ」→ ・・・
というサイクルを短期間に何回も回して実現イメージを固めつつ データモデルを確かなものに仕上げていく、といったアプローチを採ることができます。 是非このアプローチを試してみてください。
まとめ
今回、「アイテムタイプ」は「クラス」や「エンティティ」、「テーブル」や「台帳テンプレート」に相当するもので、情報管理対象物の管理方法の骨格を規定するもの、というお話をしました。そして、データモデルを中心に素早くプロトタイプで確認していくアプローチが適しているということも。
次回は、データモデリングの分野で「エンティティ」と並ぶ一大概念でもある「リレーションシップ」について見ていきたいと思います。と言いましても、データモデリングの話をするのではなく、あくまで「Aras Innovator でのリレーションシップ」についてです。アイテムタイプとアイテムタイプの間に関連を持たせることによって、情報が立体的になる様子をご紹介できればと思います。
それでは、また次回。
※（補足1） 「アイテムタイプ ＝ DBテーブル」はただの比喩ではない： Aras Innovator 上でアイテムタイプを作成すると、同名のテーブルが SQL Server 上に自動生成されます。設定したプロパティはそのままそのテーブルのカラムとなります。プロパティを抽象化したテーブル構造になっている訳ではなく 直接的なカラムになっていますので、すごく素直なテーブルが出来上がります。そのため、データ移行なども非常に容易です。
※（補足2） 「アイテム」について： 「アイテムタイプ：パーツ」に対して個々に作成された「パーツA」「パーツB」「パーツC」のようなものを、「アイテム」と呼んでいます。「アイテム」はDBテーブルに格納される各レコード（1行1行）に相当し、システム的には32桁の意味無し識別子「ID」を付番して管理しています。
（アラスジャパン 宮内一也）