　しかしこれは、言うのは簡単、実行は難しいものです。「バグのないプログラムを作ってください」と同様なくらい難しいものです。（ウォーターフォール型開発でも）モデリングで後戻りがあっても耐えられるようにする必要があります。これにはいわゆる「ホットスポット（*）」を見つけるのがコツになりますが、この話は次回以降の「モデリングはなぜ失敗するのか」「モデリングを成功させるには」で紹介する予定です。

（*）ホットスポットとは、熱い場所という意味で、モデリングのときは、仕様変更がありそうな場所や仕様が曖昧な場所などを指します。

アジャイルとモデリング

　アジャイル開発は名前の通り、ソフトウェアを俊敏に開発する方法です。世の中にはいろいろなアジャイル開発があり、一緒くたにするのは浜納豆と甘納豆を同じにするようなものですが、ここでは共通的な認識手法として、アジャイル開発でのモデリングはどうするべきかを見ていきます。

　アジャイル開発は短期間（タイムボックスやスプリント、イタレータなどの呼び方があります）での作業を繰り返すことを基本とします。このためモデリングもこの期間で対応したものが必要になります。アジャイルでのモデリングは、この短期間で必要となるギリギリの最小限のものを作ることになります。将来必要になるかもしれないモデリングはしない、あまり多くのホットスポットは考慮しない、今必要なものだけをモデリングする「必要最小限のモデリング」がキーとなります。

　一方、アジャイル開発ではプロトタイピングを多用します。実装に近いモデルを作るくらいなら動くコードをという考えがあり、プロトタイピング至上主義な面もあります。このプロトタイピングとモデリングをどのように両立するのか、またはできないのかを考えてみましょう。

　まず教科書的に言えば、モデリングとプロトタイピングは車の両輪みたいなもので、相互補完するべきものです。シミュレーションでのよい結果に喜ぶだけではダメで、解析解を求めて、結果が一致するかを確認する必要があり、また解析解だけで喜んでいるのもダメで、シミュレーションして、両者が一致するかを確認するとの同じです。これが教科書的な教えになります。

　しかし、これは現実的ではありません。開発現場の人には心には響かないでしょう。何よりもコストが高くなりますので、現場としては、モデリングかプロトタイピングのどちらかにしたいと思うでしょう。同じようにシミュレーションか解析、または実測のどれかにしたいと思うでしょう。それでいいのです。開発現場で欲しいのは教科書的な八方美人的な美辞麗句でなく、使い分けの基準またコツです。しかしここでは教科書的に標語は「モデリングとプロトタイピングは車の両輪（仮）」とさせてください。これを図7に示します。