UMLやSysMLなどのモデリングは“いつ”“何を”“どうするのか”：プロジェクトを成功させるモデリングの極意（3）（6/8 ページ）

「モデリングはいつ誰が何をどのようにするのか」――今回はソフトウェア開発の現場で、モデリングを実際にどのように実施しているのか見ていきましょう。またUMLやSysMLの使いにくいところを、開発現場ではどのようにカバーしているのかも見ていきます。

[五味弘，MONOist]

開発プロセスとモデリング

　ここではソフトウェア開発プロセスとモデリングの関係を見ていきます。開発プロセスによって、モデリング手法や使うモデル図は違うのか、開発プロセスに最適なモデリングとは何かなどを見ていきます。

組み込み系ソフトウェア開発のモデリング

　組み込み系ソフトウェア開発は、エンタープライズ系開発と比較して、ソフトウェアシステムだけでなく全体のシステムを対象にすることや、ハード部門との調整が必須であり、より強いリアルタイム性が求められるなど制約条件が厳しさが特徴となります。

　モデリングでも組み込み系ならでは特徴があります。このためUMLでは力不足でSysMLを使う場合が多いですが、この連載ではUMlとSysMLの詳細まで踏み込みません。組み込み系ソフトウェア開発については、組み込み系開発で多い「擦り合わせ開発」や「派生開発」の節を参照してください。

ウォーターフォールとモデリング

　ウォーターフォール型開発での工程とモデリングの関係は、前節の工程別モデリングを参照してください。モデリングのコツとしては、ウォーターフォール型開発と同様に「後戻りしなくてもいいモデリング」を心がけてください。このためには工程ごとにチェックを厳しくするという方法があります。

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

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

アジャイルとモデリング

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

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

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

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

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

図7. アジャイル開発とモデリングの関係

　実際の開発現場で使える使い分けの基準やコツは、次回以降の「モデリングの失敗、成功」で紹介する予定です。