データモデリングの実践に必要な専門知識が３つある。文法知識（関数従属性を含む図法に関する知識）、業務知識（会計等を含めた適用分野に関する知識）、そして、さまざまなモデリング事例の知識だ。これらは一朝一夕には身につかないが、それこそが労働市場におけるシステム設計者の参入障壁になっている。必要な専門知識を誰でも簡単に身につけられるとしたら、データモデリング（情報システム設計）の仕事は高度専門職のひとつとはみなせない。
ただし、それらの専門知識をそなえているとしても、システム設計者としていい仕事が出来るかどうかは別の話だ。現場で優れたデータモデルを生み出すためには「抜本的に考える」という姿勢が欠かせない。それを身につけるのは、上述した専門知識を覚えるよりも難しいかもしれない。
これに関して、数学が得意だった学生時代の友人を思い出す。数学には覚えるべき公式がたくさんあって、何やら暗記科目のようではないか――私がそのように愚痴ると彼は、「自分も忘れることはあるが、そのときは最初から考えて公式を組み立て直す」とこともなげに言ったものだ。数学が得意な人間はそのように考えるのかと感心したものだが、システム設計も同様である。
前述した３つの専門知識のうちの「さまざまなモデリング事例の知識」を十分に知っていれば、現場で抜本的に考える必要はないように思える。モデリング事例に含まれるパターンを選び出して適用すればいいだけだからだ。とはいえそれらは膨大な数学の公式のようなもので、丸暗記できるものではない。忘れたパターンについては、数学が得意な彼のように、抜本的に考えて再構築するといった対応も時には必要だ。
より重大な問題は、明文化されたモデリング事例にはそれぞれ「適用可能な文脈」が前提されている点にある。現実の設計課題は常に精妙かつ独特だ。それらの課題と同じ文脈を持つモデリング事例が存在するとしたらたいへんな僥倖といっていい。ぴったり合う参照モデルがなければ、抜本的に考えて「新しい公式」を編み出さねばならない。
具体例を挙げよう。図１は発注・入荷の典型的なデータモデルで、私が書籍やブログでも何度か紹介しているパターンだ。「発注見出し」と「発注明細」にもとづいて発注内容を伝えると、仕入先から納期回答があるので、その内容を「入荷明細」として登録する。入荷明細は今後の在庫推移を変動させる要素のひとつとなると同時に、実際に入荷して検収されれば仕入計上の起点にもなる。未来の在庫推移を把握したい業態にとっては強力なパターンだ。
しかし、いかに強力であっても、このパターンも特定の業務要件と結びついている。たとえば、業態によっては物品だけでなく、人工（にんく）の調達が含まれる。ソフトウエア開発業などはその典型的なのだが、その場合、未来の在庫推移を監視する必要はほとんどなく、より重要なのはコスティング（原価集計）である。特定プロジェクト向けに発注されたのであれば、仕入額はそこに跡付けされなければいけない。そのためには図２のほうがはるかに使いやすい。
このモデルでは、発注明細に対して図１の入荷明細（入荷予定／実績）ではなく、検収明細（検収予定／実績）が置かれている。さらに検収金額を何カ月かに分割してコスティングするためのエンティティ「コスティング明細」が置かれている。検収明細上のコスト額がコスティングポリシーに従ってコスティング明細として展開され、それぞれのプロジェクトにおける費目別金額として集計される。たとえば、何か高価な設備を買った場合、その仕入額は減価償却のように数年間に渡って分割されてコスティングされる。制度会計上の仕入計上と管理会計上の原価集計とはタイミングも期間も違っていいという話だ。
もし、図２が求められる設計課題に対して図１を適用してしまえば、より合理的な形にたどりつけなかったという意味で設計は失敗である。手に入るどんなモデリング事例についても「固有の業務要件」が関わっている。過去にうまくいったパターンをなんとかの一つ覚え式であてはめるようではいけない。この場合であれば、コスティングに関する要件にそって抜本的に考えることで、はじめて図２の形にたどりつける。抜本的に考える姿勢の重要性がおわかりだろうか。
ようするにモデリング事例の膨大な知識は、丸暗記すべきものではないということだ（そもそも覚えきれないが）。では、我々はそれらを何のために学ぶのだろう。他でもない。「文法知識」と「業務知識」とを頭の中でつなげる訓練のためだ（図３）。
文法知識と業務知識とは完全に独立した知識体系である。データモデルというものは、まさに両者の間（あわい）に成立する工学的認識だ。これを得るためには、文法知識と業務知識をつなげるためのスキルが必要で、膨大な「モデリング事例」の分析経験はまさにそういったスキルの習得に欠かせない。そしてその過程は、個々の要件に対して効果的なデータモデルを生み出すための基礎訓練にもなる。
付言すると、この種の課程は基礎的でありながら、ひどくないがしろにされている。参照できるモデリング事例が少ないことが何よりも問題だし（私はサイトや書籍で積極的に公開しているほうだと思うがそれでも足りない）、その少なさゆえに、膨大な事例から学ぶことの必要性や重要性も認識されていない。文法や理屈さえ理解すればデータモデリングは担えると信じられている。粗忽で危険な勘違いだ。
まとめよう。モデリング事例にもとづく事前学習は、システム設計者としての構想力(imagination)を鍛えるために欠かせない。いっぽうでモデリング事例の知識が、個々の開発課題における要件の理解を歪める可能性がある。効果的かつ創造的なモデルを生み出すために、モデリング事例の知識は現場では一時的に棄却(unlearn)したほうがいい。何のためか。複雑精妙な個々のシステム要件について、初めて出会ったかのような気分で抜本的に考えるためだ。
