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

• 評価なしモデリング

　モデリングが失敗する理由は私たちの日常生活と全く同じ原因です。つまり失敗しても、失敗から学ばないからです。そして同じ失敗を繰り返すことになります。なぜ、このようになるかと言うと、それはモデリングした結果のモデル図を評価しないからです。優れたモデル図であったのか、駄目なモデル図であったのかを評価しないからです。

　評価する場としてはデザインレビューがあります。しかし、そこではあら探しが中心になっていて、モデル図の正当な評価はあまりなされていません。モデル図の評価以前の問題が山積みされているから、評価までレビューが及ばないのです。

　またモデル図の評価の別機会として、授業や研修といった教育の場で評価することがあります。しかしこれは実際の仕事で使うモデリングでないため、どうしても予定調和的な評価になってしまいます。予定された悪いところを発見し、予定された優れた点を鑑賞するというスタイルになってしまいます。もちろん、これだけでも学ぶところは多いので必要であり、有効な方法です。

　こうなるとモデリングの評価は、モデリングの師匠からの教えが重要になります。その前提条件としては、モデリングで師匠と弟子の関係があることが必要になってきます。実はモデリングだけに限ったことでなく、プログラミングも要求分析もテスト方法論にも通じますが、師匠から評価を受けることは重要です。

　モデル図の評価プロセスが弱いと思った人は、仲間内のモデル図を評価してみてください。逆に他人に自分のモデル図を評価してもらってください。このように仲間内でピアレビューすることで評価プロセスが動き出します。そしてこれがモデリングを失敗しないコツになります。

• 無理やりモデリング

　モデリングをするときに、モデルの対象とモデリングの目的から、モデリングの手法とツール、さらにモデラーを選びます。しかし、選んだ手法やツールがモデル対象や目的の範囲外であった場合、このモデリングは失敗します。合わない手法やツールを使って、無理やりにモデリングすることは、そのモデリングが直ちに失敗することを意味しています。

　例えば、コード生成を目的とした場合、選んだ手法とツールは対応できるのか、細々とした仕様変更が入った場合に低コストでそれを反映できるのか。生成されるコードは実用に耐えられるのか、生成したコードを読解し拡張できるのか、保守をできるのか。一つでも不安なことがあれば、コード生成でその手法やツールは採用しない方がいいでしょう。コード生成の機能があると書いてあっても、きっとツールの範囲外です。使わない方が身のためです。

　仕様整合のためにモデリングをするときは、まずモデル図の了解性が求められます。選んだ手法やツールは仕様整合に使えるか、モデル図を分かりやすく表現することはできるのか、それも一般的なモデラーのスキルでそれができるのかなどを検討します。

　もちろん、手法やツールの範囲外と言っても、使い方に問題がある場合もあります。本来はこの目的で使うのであれば、この機能を使うべきところを、いつもの機能で無理やりモデル図を描いている場合です。例えば、UML では要求をユースケースで詳細に描くのは範囲外です。ツールのせいではなく手法そのものの範囲外です。このようなときはアクティビティ図を使うとか、UMLを止めて SysMLの要求図を使うようにします。適材適所こそ失敗しないためのコツです。

• 一回こっきりモデリング

　モデリングも再利用を考えて行うべきです。いえ、モデリングだからこそ再利用を最初に考えるべきです。プログラミングコードの再利用は太古の昔から言われていますが、モデル図に関しても、再利用されてこそ価値があります。

　しかし再利用を考慮したモデル図はあまりありません。そもそも最初から再利用を考えていないモデル図が多いのです。再利用を考えていないと、システムに特化したモデルになり、抽象化ができていなくて、問題に特化したものになります。さらに悪いことに、再利用と言う指針がないため、抽象化されていても、その方向があさっての方向に行ってしまう可能性があります。1回こっきりのモデル図は粗野で野蛮で下品なモデル図になります。

　再利用を考えないと、仲間内だけのモデル図になったり、効率が悪いモデル図になったり、モデル化と抽象化を勘違いしているモデル図になったりします。プログラムは再利用を考えることで拡張性のある美しいものになります。モデリングでも同じように再利用を考えることで、抽象化は拡張性につながり、また了解性にもつながります。つまり人に読ませるモデル図になります。