データモデリングの上達には「事例研究」が不可欠
効果的なデータモデルは「顧客の要望」を緻密に分析するだけでは得られない。設計者側の「専門家としての経験的蓄積」による補完が欠かせない。ところが、システム開発の世界ではそのように語られることはほとんどない。「記法を理解し、システム要件が明らかであれば誰にでもデータモデルは描ける」とみなされているからだ。そのような認識の甘さがどれだけデスマーチを引き寄せているかわからない。
少し調べればわかることだが、データモデル（ER図）の技術者向けの説明では、主キー、外部キー、候補キー、テーブル関連、関数従属性、ナントカ正規形などといった専門用語の解説が中心になっている。たしかにそれらは取っつきにくい概念で丁寧な説明が必要なのだが、それゆえに、それらを理解することがデータモデリングに上達するための鍵とみなされている。しかしこれは、楽典（楽譜の読み書き）をマスターすれば誰でも交響楽を作曲できると考えるようなことだ。
実際の作成過程についてはどうだろう。「システム要件の中から動詞と名詞を捉えて整理せよ」とか「トップダウン方式とボトムアップ方式があって、実際にはそれらのミックスである。両者のバランスに注意しよう」とか「概念モデル、論理モデル、物理モデルの順番で段階的に精緻化すると進めやすい」などといったもっともらしい説明はよく見かける。しかし、その程度のアドバイスだけでまともなモデルを描けるわけがない。
どうも、データモデリングを含めたシステム設計に関する語りには、それを算数の問題を解くような過程とみなしている節がある。算数の問題文には考慮すべき要点が網羅されていて、それらを一定の手順で変形すれば唯一の正答に到達できる。システム設計がそういうものであるならば、手順さえ理解すれば中学生でもやれるし、要件を様式化すれば自動化できるということだ。そして、失敗した（デスマーチ化した）としたら、設計において考慮すべき要件を調べ尽くせなかったゆえと判定される。現行システムの現状分析が、無駄としか思えないほど膨大な工数をかけて実施されるのはその表れだ。字面の知識の理解と現行システムを緻密に調べ上げることばかりが重要視されて、地道なトレーニングや職業適性についてはほとんど語られない。
これに関連して思い出すことがある。昔、あるプロミュージシャンによる公開レッスンに参加したときのことだ。「ではみなさん、『朝』をテーマとしたフレーズを弾いてみてください」と求められて、私を含めて多くの参加者が途方にくれた。「朝」だけでなく、夕日、海、風といったテーマが次々に挙げられて、もうお手上げである。ところが彼はその場で適当に挙げたテーマに沿って、どんどんアドリブで弾いてしまうのだった。プロであることのスゴみを思い知らされたものだ。
そのとき、課題である「朝」が詳細に定義されていたわけではない。ただの「朝」だろうが、より限定された「冬の朝」や「主人公のこれこれこのような経緯のあとの朝」だろうが、彼は朗々と弾いてしまっただろう。つまり、ある種のプロフェッショナル活動は、膨大な「専門家としての蓄積」と、クライアントの舌足らずな要望に対応する「それっぽいソリューション」を自在に引き出すためのスキル、によって支えられている。参照可能な蓄積の量が多ければ多いほど、ソリューションの品質や妥当性が担保されることになる。そして、蓄積の量を嬉々として増やしていけるのは、彼らがその専門性に対する親和性（職業適性）を持っているからだ。
システム設計は「算数の問題を解く仕事」ではなく、どちらかといえばミュージシャンの仕事、具体的には「監督の要望に応じて効果的な映画音楽のスコアを創造する仕事」に近い。顧客の要望に対して提示される答は1つとは限らない。しかしいくつかの候補を挙げれば、顧客はその中からもっとも効果的と思われるものを主観的に（ある程度は客観的にも）選び取れる。優秀な専門家であることの要件は、顧客の曖昧な要望にもとづいて、なるべく効果的なソリューションを、なるべく多く提示できることだ。顧客に多くの選択肢を与えて納得感を得てもらうためだ。
ところが、多くのシステム開発の現場ではこのようにコトは進展しない。「朝のテーマ…ですか。うーん、それでは曖昧ですね。きっちりと定義してもらわないと作曲できません」と監督の舌足らずな要望にケチをつけるようなことが起こる。
「朝の何時頃でしょうか。どんな風景が見えていますか。どんな天気で、登場人物の気分はどんな感じなのでしょうか」ようするに「専門家としての蓄積」が貧弱なのだ。最近ではその貧弱さに伴うしわ寄せを「プロダクトオーナー」だの「ドメインエキスパート」などといった珍妙な役割に押し付けるやり方さえ流行っている。
「なぜそんなにこまごまと説明しなけりゃいけないんだ」
「監督の意図を楽曲に確実に反映するためです。そして、それぞれの意図がどのフレーズに対応するかも管理する必要があります」
「うーん、面倒だからとりあえず朝っぽい曲をいろいろ弾いてみてよ。その中から選ぶからさ」
「だからぁ、それでは曖昧すぎるんです。せめて曲のキーとコード進行くらいは明示してもらえませんか」
本来その道のプロであれば、顧客の語る曖昧な要望にもとづいて、それっぽいソリューションを次々と提示できるようでなければいけない。それらの中から顧客が選んだソリューションによって、当初の要望が逆方向に定義される。顧客はシステムの専門家ではないのだから、彼らの要望が曖昧だったり、舌足らずだったり、ときには矛盾していたりするのは当たり前。「お客さんの要望が非論理的だしコロコロ変わるので、まともに設計できない」といった嘆きは、システム設計者として未熟であることの告白以外の何物でもない（ヒヨッ子時代の私がそうだった）。
では、専門家として求められる蓄積はどのようにして身につけたらいいのか。まずは社内資料をひっくり返して、質の良い設計事例を研究し倒すくらいはやって当然だ。有能なミュージシャンは膨大な楽曲を分析し、有能な建築士は膨大な建築事例を分析する。社内の事例がアテにならないのであれば、拙書「データモデル大全」のような書籍も役立つ。データモデリングの理屈や取り組む際の姿勢についての説明も書かれているが、もっとも価値があるのは後半の設計事例集である。こういった情報はなかなかまとまって公開されないので、存分に活用してほしい。