　モデルはコードよりも万人に理解しやすいため、誰でも全体のソフトウェア構成を理解でき、設計の議論に参加でき、モデルで開発できるようになります。ベテランのエンジニアだけでなく、入りたての新人でも、技術を忘れてしまった部長でも、設計に踏み込まないユーザーでも、設計の議論に参加できます。議論をすることで理解が深まりますので、開発チーム全体のスキルアップができます。設計と実装（コード）の関係が明確になり、コードの共有からモデルを共有するようになるでしょう。

　ここはモデリングの良さを知ってもらうために少し大げさに書いていますが、とにかくコード中心の職人技（例えば1人の天才ハッカーの超絶技巧）から、モデル中心の一般人のチームの技で作れることが、モデルの大きな効果でしょう。

　ここでは設計レベルのモデリングを想定して、モデルの目的や効果を話しましたが、要求モデリングやアーキテクチャモデリング、ビジネスモデリングでも同様なことが言えます。例えば、要求モデリングのときは、要求を日本語の文字中心で書いていた仕様書を分かった振りをしていたメンバーが、要求図などのモデル中心で議論することで理解が進み、深い議論ができるようになるでしょう。この連載ではモデル中心のソフトウェア開発をするためのコツを学んでいくようにします。

モデルに求められるもの――モデルの分かりやすさ

モデルに求められるもの

　モデルの目的や効果を紹介してきましたが、そのためにモデルはどうあるべきでしょうか。つまりモデルに求められるものは何でしょうか。

　モデルに求められるものは、コードに求められるものとは違いますし、どのような目的で使われるかによっても異なります。コードには正確性や完全性が求められますが、アーキテクチャモデルではコードレベルの完全性は求められず、正確性や完全性を求めるのであれば、アーキテクチャ設計仕様書や疑似プログラムコードなどで表現することになるでしょう。このようにモデルに求められるものは時と場合に依存します。全部を求めるのは駄目なのです。

　それではモデルで求められるものは何でしょうか。時と場合に依存しますが、共通に求められ、そして一番求められるものは、ずばり、モデルの「分かりやすさ」です（図0）。この了解性こそがモデルの肝心です。了解性を犠牲にしてまで、正確性や完全性を追いかけないでください。これは全くの本末転倒です。この連載ではモデルの失敗例として完全性を求めるあまり分かりにくくなったモデルを紹介する予定ですので、反面教師にしてください。