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