職業がら多くのデータモデルを見る機会があるのだが、根本的な発想が間違っているために何のアドバイスもできないことがある。そういったケースではしばしば設計担当者が自分のスタイルに固執しているので、アドバイスなどそもそも余計なお世話だったりする。そうなるともうガンバッテと言うしかなく、案の定その後にデスマーチ化する。悪いことに大抵は膨大なコストを投入したあげく、使いにくく保守しにくい業務システムとして完成してしまう。しかもその原因がDB設計の失敗に帰されないので、設計担当者は次の案件でも同じような仕事を繰り返す。
その種の典型的なアンチパターンが、データモデルを「概念を整理した図面」とみなす考え方だ。何の問題もなさそうに思えるかもしれない。私は断言するが、データモデルは「概念を整理した図面」ではないし、「現実を写し取った図面」でもない。正確に言えばそういった側面もあるといえばあるのだが、それだけでなく、まともなデータモデルには明確な「ソリューション」が含まれている。
具体例を示そう。たとえば、メーカーのユーザが次のような語りをしていたとする。
今までは、製品別の受注を担当する営業さんが個々にエクセルで引当して出荷予定を管理してきたが、それをデータベースで一元化したい。そうすれば営業さん以外でも受注して納期を答えられるし、誰もが製品毎の出荷予定を見れるようになる。
これに応えて、次図のような「データモデル」が描き出されたりする。いかにも素人くさいポンチ絵で、まさに「概念を整理しただけの図面」だ。これを「概念モデル」だの「クラス図」だの「ドメインモデル」などと呼び替えても、役に立たない点で違いはない。
問題は何か。ユーザの語りに含まれるモノだのコトだのを並べて線をつなげただけで、彼らが抱えている問題に対する「ソリューション（解決策）」を含んでいない点だ。この手の貧弱なモデルを「問題モデル」と呼び、ソリューションを含む「解決モデル」と区別する手法もあるようだが、いったん前者をまとめることで後者が生み出しやすくなるわけではない。仮に前者を作ることが自分の役割で、後者については別の担当者の仕事と考えているとしたら、無責任きわまりない。そもそもそんな役に立たない図面を疑問を持たずにまとめている時点で、抜本的に考えることが求められるシステム設計者としてあまりに頼りない。
まともな「ソリューションを含むモデル」の例を示そう（図２）。出荷予定というからには「在庫」が問題になるはずだ。製品や中間品の製造予定、資材の消費予定、製品の出荷予定といったさまざまな品目の受払予定が抽象化され、現在庫からの受払予定にもとづく在庫推移が示される。このようなDB構造上の工夫を盛り込むことで、製品を含めたすべての品目の在庫推移がわかるようになる。
「いや、これはフェアではない。ユーザは製品の出荷予定については語っていたが、資材の出庫予定だの在庫など語っていなかったではないか」といった反論は無意味だ。製造業の物流まわりを理解していれば、問題は製品の出荷予定だけでないことは明白である。ユーザの語りにはかならず漏れや的外れがあるもので、そうでないと期待するのはある種の甘えでしかない。なにしろユーザは「自分の仕事の専門家」ではあっても「システム設計の専門家」ではないのだから。
ここで重要なのは、図２がユーザの語りを写し取っただけのものではなく、業務システム開発者としての知識や経験や創意工夫が盛り込まれている点だ。いっぽう最初に挙げた図１は、いわば「高層ビル設計の専門家ではない施主」の思いを素人なりに清書しただけの図面であって、これを基礎にすれば高層ビルは施工中に倒壊するだろう。これに対して「私はお客様の要望どおりに設計しただけ」といった言い訳が許されるなら、システム設計など中学生にでも任せたらいい。
プロと素人の仕事を分けるのはどこか。成果物に「専門知識や実務経験に裏打ちされたソリューション」が含まれているかどうかだ。あなたがまとめたモデルはどうだろう。
