前回は第1条「納得感のある開発手法を身につけるべし」について書いた。今回は第2条「モデリングは走りながら実践の中で身につけるべし」を説明する。
第2条：モデリングは走りながら実践の中で身につけるべし
モデルとは
まず、モデルとはいったいどのようなもので、何のために行うのか説明しよう。
話をシンプルにするために、ソフトウェア開発におけるモデルに限定してここからは説明をしていく。
ソフトウェア開発におけるモデルとは、対象領域を深く理解するために、ある視点から見て、重要な部分にフォーカスを当て際立たせ、重要でない部分を排除したものを図などによって表したものを言う。
なぜ図にするかというと、人はビジュアルなものの方が頭に残りやすいから。
ではモデリングが上手にできるとはどういうことか？
たとえばUMLの表記法がわかったからといって、モデリングが上手というわけではない。モデリング上手とは、問題領域の本質面を的確に浮かび上がらせる抽象化ができているかということが重要となる。
ここで抽象化という用語を使ったが、この抽象化のテクニックがモデリングの良し悪しとなる。
ここで言う抽象化とは、モデリングの説明で書いた「重要な部分にフォーカスを当てて際立たせ、重要でない部分を排除する」と同じことである。
そのような抽象化されたモデルは、とてもシンプルで分かりやすいはずだ。
設計モデルの宿命
しかし、ソフトウェア設計モデルには、設計を抽象化することで理解を促進させるためにモデルを書くということだけではなく、実装責任を負うモデルということも命題となる。
実装責任を負うモデルを書くためには、プログラムコードにも近いレベルで具体的なモデルを書くことが必要となる。つまり設計モデルは、分かりやすさのために抽象化するということと、実装のために具象化すべきというこという、相反する2つの目標を持つ。（注1）
このことが原因で、設計モデルは、時代の流行という風に吹かれながら抽象化と具象化の狭間をゆらゆらと揺れながらさ迷う宿命を持っている（図2）。たとえばMDA（モデルドリブンアーキテクチャ）という流行の風が吹いているときは、極端に具象化の方に流れていると思った方がよい。しかし、なかなか具象化の極限にいきつかない、なぜならITは時代とともに変化しすぎており、それを具体的なコードに近いモデル（パターン）で表し維持することが困難だからだ。また、このような状況のモデルは、理解のためのモデルということが見失われてしまっているために、そのことに気がついた段階で、具象化から抽象化への風がいきなり吹き荒れ、基に戻る、いや戻りすぎるのだ。
（注1）分析モデルと設計モデルの詳しいことは、
@IT「ソフトウェア開発の匠、第2回 分析モデルはユーザー視点でシンプルに」を参照するとよいでしょう。
走りながらモデリングするとは？
このようなモデルの特性からして、モデリングは走りながら行うべき、というのは僕の口癖なのである。 モデリングは走りながら...にはちゃんとした訳がある。
モデリングとは、問題領域を本質面で抽象化するため、物事の本質を把握するテクニックとしては非常に有用なものだと思う。しかし、それをより具体化しようとしてしまうとモデルの本来のよいところである「わかりやすさ」を見失ってしまう。本質面で抽象化して余計なものを省いていたのに、余計なものが入り込んでしまっている。
だからあまり書き過ぎず程良いくらいがちょうどよいのである。また、すべて図に頼らず、どうしてそのようなモデル（図）として書いているか解説を書くとよい。
それでも十分モデルの効力は働くものだ。説明を書いたらモデルの意味がないと思われるかもしれないが、解説を一度読み、そのモデルの意図がわかれば、あとはイメージとしてその読み手の脳裏に焼き付けることができる。
シンプルに分かりやすく重要部分を説明できている事、それがモデルにはとても重要なのである。
また、モデリングが好きな人の欠点は、立ち止り時間をかけて考え込み、問題領域を抽象化した世界に居留まる傾向があると思う。これは僕もそうなりがちなのでかなり注意している。
そのために、具体的な実践の現場感をなくしてしまったり、ビジネスのスピードについていけなくなったりする。つまりは、問題領域を抽象化した普遍性を捉えるのは得意とするが、現場のリアルなビジネスについては無頓着になったり、行動が伴わなくなったりする。別の言葉で言うと頭デッカチになる（注2）。
実践に役立つモデルは、本質面が、シンプルに抽象化しており、実践の現場の中で、リアルタイムにメンテ可能なシンプルなものである。
真のモデラーは、それを走りながらモデリングすることができる。それを目指すべきだ。そうすることで、現場の中でモデリング力を発揮できるだろう。
（注2）僕は、幼いころ頭がでっかくて二度ほど池に頭から落ちた。
