« 開発者が自動化に負けないためのたったひとつの方法 | トップページ | システム設計のスキルは「掛け算」で作用する »

2020.09.06

データモデリングの上達には「事例研究」が不可欠

 効果的なデータモデルは「顧客の要望」を緻密に分析するだけでは得られない。設計者側の「専門家としての経験的蓄積」による補完が欠かせない。ところが、システム開発の世界ではそのように語られることはほとんどない。「記法を理解し、システム要件が明らかであれば誰にでもデータモデルは描ける」とみなされているからだ。そのような認識の甘さがどれだけデスマーチを引き寄せているかわからない。

 少し調べればわかることだが、データモデル(ER図)の技術者向けの説明では、主キー、外部キー、候補キー、テーブル関連、関数従属性、ナントカ正規形などといった専門用語の解説が中心になっている。たしかにそれらは取っつきにくい概念で丁寧な説明が必要なのだが、それゆえに、それらを理解することがデータモデリングに上達するための唯一の鍵とみなされている。しかしこれは、「楽典(楽譜の読み書き)をマスターすれば誰でも交響楽を作曲できる」と考えるような勘違いだ。

 データモデリングの過程についてはどうだろう。「システム要件の中から動詞と名詞を捉えて、それぞれをイベント系エンティティとリソース系エンティティとして整理せよ」とか「トップダウン方式とボトムアップ方式があって、実際にはそれらのミックスである。両者のバランスに注意しよう」とか「概念モデル、論理モデル、物理モデルの順番で段階的に精緻化すると進めやすい」などといったもっともらしい説明はよく見かける。しかし、その程度のアドバイスだけでまともなモデルを描けるわけがないと私は断言できる。じっさい私はこれまでそのようにモデリングしたことはないし、今後もそれでやれるとはまったく思えない。

 どうも、データモデリングを含めたシステム設計に関する語りには、それを算数の問題を解くような分析的過程とみなしている節がある。算数の問題文には考慮すべき要点が網羅されていて、それらを一定の手順で変形すれば唯一の正答に到達できる。システム設計がそういうものであるならば、手順さえ理解すれば中学生でもやれるし、要件を様式化すれば自動化できるということになる。そして、失敗した(デスマーチ化した)としたら、設計において考慮すべき要件を調べ尽くせなかったゆえと判定される。現行システムの現状分析が、無駄としか思えないほど膨大な工数をかけて実施されるのはその表れだろう。字面の知識の理解と現行システムを緻密に調べ上げることばかりが重要視されて、地道なトレーニングや職業適性についてはほとんど語られない。

 これに関連して思い出すことがある。昔、あるプロミュージシャンによる公開レッスンに参加したときのことだ。「ではみなさん、『朝』をテーマとしたフレーズを弾いてみてください」と求められて、私を含めて多くの参加者が途方にくれた。「朝」だけでなく、夕日、海、風といったテーマが次々に挙げられて、もうお手上げである。ところが彼はその場で適当に挙げたテーマに沿って、どんどんアドリブで弾いてしまうのだった。プロのスゴみを思い知らされたものだ。

 このように、ある種のプロフェッショナル活動は、膨大な「専門家としての知識や経験の蓄積」と、これを基礎として「クライアントの舌足らずな要望に対応するそれっぽいソリューション」を再構成して提示するためのスキルおよび感性によって支えられている。基本的に、依拠可能な蓄積の量が多ければ多いほどソリューションの品質や妥当性が担保されることになる。求められる蓄積の量は膨大ではあるが、彼らがそれを嬉々として増やしていけるのは、その分野に対する圧倒的親和性(職業適性)を持っているゆえだ。

 システム設計はまさにその種のプロフェッショナル活動のひとつである。それは「算数の問題を解く仕事」ではなく、どちらかといえば「監督の要望に応じて効果的な映画音楽のスコアを創造する仕事」に近い。顧客の要望に対していくつもの候補を挙げれば、顧客はその中からもっとも効果的なソリューションを主観的に(ある程度は客観的にも)選び取れる。優秀な専門家であることの要件は、顧客の曖昧な要望にもとづいて、なるべく効果的っぽいソリューション候補を、なるべく多く提示できることだ。顧客に多くの選択肢を与えて納得感を得てもらうためだ。

 ところが、多くのシステム開発の現場ではこのようにコトは進展しない。「朝のテーマ…ですか。うーん、それでは曖昧ですね。きっちりと定義してもらわないと作曲できません」と監督の舌足らずな要望にケチをつけるようなことが起こる。

「朝の何時頃でしょうか。どんな風景が見えていますか。どんな天気で、登場人物の気分はどんな感じなのでしょうか」
「なんでまたそんなにこまごまと説明しなけりゃいけないんだ」
「監督の意図を楽曲に確実に反映するためです。そして、それぞれの意図がどのフレーズに対応するかも厳密に管理する必要があります」
「そんなことまでして何の意味があるのかねぇ。面倒だからとりあえず朝っぽい曲をいろいろ弾いてみてよ。その中から選ぶからさ」
「だからぁ、それでは曖昧すぎるんです。せめて曲のキーとコード進行くらいは指定してください。その通りに作りますから」
 ようするに、専門知識は豊富なのかもしれないが「専門家としての経験的蓄積」が貧弱なのだ。最近ではその貧弱さに伴うしわ寄せを「プロダクトオーナー」だの「ドメインエキスパート」などといったご都合主義的な役割に押し付けるやり方さえ流行っている。情けない。

 本来その道のプロであれば、ど素人の語る曖昧でいい加減な要望にもとづいてソリューション候補を次々と提示できるようでなければいけない。映画音楽を任されたミュージシャンであれば、DAWを使ってデモ演奏を何度もプロトタイピングするだろう。楽譜だけでは監督にわかってもらえるとは限らないからだ。システム設計者であれば、DB上で動作するシステムを何度もプロトタイピングすべきである。設計書だけでは顧客にわかってもらえるとは限らないからだ。そのようにして提示された候補の中から選ばれた答によって、当初の要望が逆方向に定義される。

 システムの発注者といえどもシステムの専門家とは限らない(だからこそ業者に発注するのである)。彼らの要望が舌足らずだったり、ときには矛盾していたりするのは仕方のないことだ。「お客さんの要望が非論理的だしコロコロ変わるので、まともに設計できない」といった嘆きは、システム設計者として未熟であることの告白以外の何物でもない(ヒヨッ子時代の私がそうだった)。

 では、専門家として求められる蓄積はどのようにして身につけたらいいのか。まずは社内資料をひっくり返して、質の良い設計事例を研究することから始めたらいい。有能なミュージシャンは膨大な楽曲を分析し、有能な建築士は膨大な建築事例を分析する。社内の事例がアテにならないのであれば、拙書「データモデル大全」のような書籍も役立つ。データモデリングの理屈についても書かれているが、もっとも価値があるのは後半の設計事例集である。こういった情報はなかなかまとまって公開されないので、存分に活用してほしい。言うまでもなく、実務経験の蓄積も欠かせない。知識がスゴいわりに執刀経験の少ない脳外科医に、あなたは自分の脳の手術を任せたいと思うだろうか。

|

« 開発者が自動化に負けないためのたったひとつの方法 | トップページ | システム設計のスキルは「掛け算」で作用する »

コメント

事例研究は事例を見て、自分でERDを描いてみる。その後、実際にシステム化する場合の問題点などを考えてみるなど必要ですね。そこまでしないと頭に残らない。本を読んだだけで分かった気分になるのが危険。僕がそうでした。実際の仕事でデータベース設計で悩んだところが、後で渡辺さんの本を再読したらヒントが書いてあった事がありました。何度も読んだ(つもり)本だったのに。。
事例研究していれば、データベース設計を登山で例えると出発を5合目から始められるような気がします。
毎回、ブログで有益な情報ありがとうございます。

投稿: MOMO | 2020.10.11 09:15

MOMOさん

まさに事例研究と実務経験の両輪が欠かせないという逸話だと思います。事例研究はあくまでも他人の経験にもとづく学びですが、それを切実な自分の問題として受け取るには「設計あるある」として思い当たるための経験的蓄積が必要です。どっちか欠けてもよろしくないですね。

投稿: わたなべ | 2020.10.11 13:52

コメントを書く



(ウェブ上には掲載しません)




« 開発者が自動化に負けないためのたったひとつの方法 | トップページ | システム設計のスキルは「掛け算」で作用する »