ある会社のシステム開発方法論を作成していたとき「データモデルを現状分析工程の成果物にして、ユーザにレビュしてもらおう」とある人が言いました。すると、別な人が「データモデルはシステム内部の構造を記述しているのだから、ユーザがレビュするような性質のものではない」と反論します。さて、どちらが正解なのでしょう？
概念データモデルはいわば「業務用語の地図」ですから、本来的にはユーザが作成しレビュすべきものです。しかし、モデリングの技術を覚えるのは大変なので、レビュだけできれば良いでしょう。
論理データモデルや物理データモデルはコンピュータ依存の仕様が付加されたものですから、ユーザが作成・レビュするものではありません。
個々の企業風土によってユーザの関わり度合いは異なるのですが、一般に概念データモデルをユーザにレビュしてもらうのには抵抗があります。私は、「建設業界では、部屋の見取り図や建物の構造図をユーザがレビュしているのだから、情報処理業界においても、ユーザが歩み寄るべきだ。業務フロー図と概念データモデルぐらいレビュしてほしい」と主張しています。いきなり大きな図を見せなければ、こちらが期待する以上にユーザは積極的にレビュしてくれるものです。
１５年ほど前のエピソードを１つご紹介します。
ある電力会社で実施した現状分析工程の中で、概念データモデルを作成しました。最終納品を控えた重要なレビュ会議に、たまたま時間が空いたということで業務部門の部長さんが参加しました。ちなみに、電力会社の部長さんと言えばかなり偉い人で、私のような協力会社の１担当者としては非常に緊張する場面です。私は概念データモデルの読み方を１０分程度で説明して、レビュを進めました。その部長さんは業務に精通しているらしく、「ＡというエンティティとＢというエンティティは、業務的に関係が深いはずだから線で結ばれていないのは変だ！」など、次々と不備を指摘します。
この日まで私と業務部門の副長さんの２人で概念データモデルを作成してきたわけですが、「面目丸つぶれ、いったい２ヶ月かけて何をつくってきたんだ！」といった雰囲気になり、大変なレビュ会議になりました。私は冷や汗をかきながら一通りレビュを終わらせて、「部長、いろいろと確認不足の点があり申しわけございません。後日、きちんと修正して納品いたします。」と頭を下げました。しかし、このまま引き下がるわけにはいかないと思い、「今日のレビュのように、業務実態とあっていない部分や不備があったとしても、部長さんのように業務を良くしっている方が、１０分程度の読み方講座を聞けば、間違いを指摘できます。概念データモデルというのはそういった技術なのです」と、使っている技術自身をアピールして帰ってきました。
「業務用語がほぼそのままエンティティ名やデータ項目名になっているから、私でもレビュできたんだ」と部長さんは非常に感動しておられました。
今となってはなつかしい思い出ですが、「エンティティの配置や選択する用語が適切であれば、概念データモデルは確実にユーザがレビュできる成果物である」というお話でした。
概念データモデルの品質は、ユーザがレビュし、高めるべきでしょう。
