モデリングはなぜ失敗するのか―― 悪いモデル、汚いモデル、意味がないモデル：プロジェクトを成功させるモデリングの極意（4）（5/10 ページ）

誰もが失敗したくてモデリングする訳ではないのに、失敗しているモデリングを見る機会は減りません。今回はモデルの失敗例を通じてその原因を探ります。

[五味弘，MONOist]

効率が悪いモデル図

　実装したときの実行効率が悪いモデル図や実装が面倒で複雑で、実装効率が悪いモデル図など、各種効率が悪いモデル図による失敗例です。

　確かに連載の第1回目でモデリングの目的は分かりやすさが一番重要であり、効率などは目的の項目にさえ出てこなかったものです。この点をもう少し詳しく言うと、概念モデルや分析モデルでは効率はあまり気にしません。しかし実装モデルになると効率は重要になってきます。もっと正確に言えば、分析モデルでも効率はある程度は意識することになります。

　もちろんモデルの了解性と拡張性、効率は相互にトレードオフになるものです。このトレードオフをどのようにバランスさせるかというのもモデラーの腕の見せどころ、アピールポイントになります。

　それではどのようなモデル図だと、効率が悪くなるのでしょうか。例えば、目的のものにアクセスするために多くの回り道をするモデル図は気になります。設計レビューのときに「どうしてこんなに回り道をするのか」という質問をしたくなります。これに対して3秒以内に答えが返ってこないときは要注意です。例えば、図7のようなオブジェクト図のようにオブジェクトのたらい回しをしてそうな箇所を見つけたら、レビューのときにはぜひ質問をするべきでしょう。「なぜAは直接Cのオブジェクトを呼ばないの？」と。

図7. 効率が悪いモデル図

　効率が悪いモデル図も駄目ですが、実装が面倒、もっと言えば、実装が不可能なモデル図の失敗例もあります。イベント指向（または割り込み処理中心）で実装するときに大掛かりなデータを受け渡す、関数型プログラミングで副作用を使わない場所で破壊的変更している操作がある、オブジェクト指向なのにデータとプログラムが完全に分離している、関数呼び出しのトリガーが不明など、実装がモデル図から読めない失敗例があります。

　どうして効率の悪いモデル図を描くのか、その原因は実装を知らないモデラーが原因であることが多いです。本来、モデリングと実装はそれぞれ別の作業であり、実装に依存せずにモデリングをするのが原則です。しかしソフトウェア開発は実装も含めて、つまりプログラミングも含めて、モデリングのような作業になります。

このため、実装を少しは意識してモデリングする必要が出てきます。しかし逆の失敗例もあります。実装に依存し過ぎて、つまりモデル図が実装に過剰適応していて、進化の余地がなくなってしまっている失敗例もあります。ここは実装とモデリングはいい関係で、つまり、付かず離れずの関係で付き合っていく必要があります。

仲間内だけのモデル図

　中の人＝一緒に開発している人＝仲間内にしか分からないモデル図を見かけます。この仲間内のモデル図は以下の特徴があります。

（1） 自分たちが当たり前だと思うことは描かない→実は当たり前ではない

（2） 仲間内用語（ジャーゴン）を使って描く→用語辞書も作らない

（3） モデリングやその先の実装で苦労した（する）ところを不必要に詳しく描く→これがモデルを分かりにくくしている元凶（その情報は役に立たないばかりでなく有害）

（4） 結局、読者（外の人）を意識せずに描く→自分たちのメモ用

図8. 仲間内だけのモデル図

　このようなモデル図を作ってしまう原因は、今までは外の人に読ませる必要がなかったことが大きな原因でしょう。もし未来永劫、中の人だけで開発ができるのであれば、それでもいいでしょうが、しかし少しでもそうでないのなら、外部の読者を意識して描く必要があります。

注意

ここの項目を見て、仲間内用語はモデル図から追放するという決定はしてはいけません。例えばJISで定義されている用語だけでモデル図を描きなさいという決定はダメです。ジャーゴンを完全に一掃するのはコストが掛かります。モデル図はその用語辞書だけで膨大なものになります。しかし用語辞書を作らなくていいという意味でもありません。

ジャーゴンの使用も用語辞書の量も結局、コストとのトレードオフになります。繰り返しますがコストとのトレードオフを考えて、バランスを取ってください。もう少し具体的に言えば、特許や論文を書くレベルまでの用語解説は要求しません。しかし部長に出す報告書レベルではジャーゴンが多すぎます。会社上層部に出す報告書レベルぐらいがいいかもしれません。