第1回,第2回で,概念データモデリングを行なう本当の目的は業務ルールの整理と分析にあることについて解説しました。ところが,概念データモデリングの重要性を理解して実際にモデリングを開始しても,実際には思うようにモデリングできない場合があります。そこで今回は,正しい概念データモデリングの方法を解説します。

ケース4

 D社は,四輪エンジンのシャフト部品などを製造する金属部品メーカーです。今年度から取り扱い製品の大幅な増加が予想され,製造工程を統合的に管理する生産管理システムの導入を決定しました。システム化の対象範囲は,年間予算を作成する「営業部」,生産計画,製造指図,設計/材料情報を管理する「生産管理課」,工程進捗を見る「製造部」,品質情報を管理する「品質管理課」の4部門です。

 情報システム部では,まずは業務を分析し新システムの概念データモデルを作成することになりました。ところが,初めて本格的に取り組んだ概念データモデリングの作業は,なかなか進みません。プロジェクトマネージャ(PM)と概念データモデリングを担当するSEのやり取りをのぞいてみましょう。

PM●これが作業中の概念データモデルか(図1)。特に販売計画のところがよくできているね。

図1●D社が作成中の概念データモデル
図1●D社が作成中の概念データモデル
[画像のクリックで拡大表示]

SE●営業部から資料(図2)をもらってきて参考にしました。

図2●販売計画の例
図2●販売計画の例
[画像のクリックで拡大表示]

PM●工程エンティティというのは?

SE●必要かどうかは分からないんですが,工程の進捗管理業務がシステム化対象の業務なのでたぶん必要になると思ってエンティティにしてみました。

PM●おいおい,大丈夫かい? 工程エンティティと品質検査エンティティがあるけど,品質検査も工程の一つじゃないのかな?

SE●実は,品質検査関連の業務がよく分からなくて,エンティティを一緒にすべきか分けるべきか迷っているんです。

PM●うーん。販売計画はうまくできているから,これと同じように,一通りの帳票を集めたほうがよさそうだね。

SE●はい,そう思って各部署にとにかくすべての帳票を集めてもらうように依頼してみました。ですが,たくさん集まりすぎて,どれとどれを概念データモデルにすべきか迷ってしまって…。

PM●それは困ったね…。

 ――その後,各部署から業務知識の豊富なメンバーを兼任ながら選出して体制の立て直しを図ったものの,D社の概念データモデルは進みそうにありません。