モデリングことはじめ長沢 智治

モデリング

皆さんは、モデリングというと何を思い浮かべるでしょうか？「UML」などの特定のモデリング言語やそれらを用いた開発手法を思い浮かべる方もいらっしゃることでしょう。また、「コードの自動生成」や「リバース エンジニアリング」などを思い浮かべる方もいらっしゃることでしょう。

私はというと、まず思い浮かぶのは、路線図です。ソフトウェア開発とは関係のない、地下鉄などの路線図です。または、家の設計図ですね。立面図やかな計図などです。

どのモデルについても極論してしまうと、現状や今後できるものを簡単化して表現したものになります。このことに着目して、このコラムでは、「モデリングは、ものごとを簡単化するもの」と定義してみましょう。

なぜ、モデリングするのか

では、なぜ、ものごとを簡単化する必要があるのでしょうか？それは現実が複雑だからです。目的を達成するための情報が多すぎたり、複雑すぎて見えなくなってしまっていたり、ステークホルダーが多すぎたりするとなかなか本質をとらえることができなかったり、共通認識を持つことが難しかったりします。

したがって、複雑な現実から、その目的を達成するために必要な情報を整理すると一歩前進できるのはないかと考えることができます。極端に言ってしまえば、目的を達成するために不要と思われる情報は、たとえ、それが別の目的や次のステップでは重要な情報であっても一度捨てる勇気も必要ということになります。

たとえば、先に挙げた地下鉄の路線図ですが、非常に複雑です。複雑すぎて慣れていないと乗り換え方法を間違えて返って遅刻をしてしまうなどもあるかもしれません。現に路線があり、電車が走っているわけですから、覚えてしまえば苦になることはありませんが、すべての路線、乗換駅、通過する駅、停車する駅など把握するのはかなり骨が折れます。そこで、路線図というモデルがあればどうでしょうか。一目でどの路線に乗るべきか、どこで乗り換えるべきかを見ることができます。ただし、路線図では、乗るべき路線や乗り換える駅などは、把握することができますが、何時に乗ればいいのか、どの電車がその駅までいけるのか (その電車の終点が目的地より前の場合もありますよね) は、把握できません。それらは、また別のモデル (時刻表) が必要になります。

別のものも見なければいけないなんて面倒だと思う方もいると思いますが、これらが一つのモデルで表現されていたら・・・恐ろしく複雑なモデルになることは容易に想像できるでしょう (駅をクリックしたら、時刻表がポップアップして・・・というサイトとしての使い勝手の話はなしでお願いしますね)。

これは先にもうひとつ例に挙げた建築における設計図も同様です。その時々、目的や見る人によって最適なモデルで把握することが大切ですね。

ソフトウェアの開発においても同じことが言えます。たとえば、ソースコードの静的な情報を把握したければ、UML のクラス図や Visual Studio のクラス ダイアグラム機能が役立つでしょう。オブジェクト間のメッセージのやり取りを把握したければ、シーケンス図が役に立つでしょう。エンドユーザーの課題を把握したければ、ビジネス ユース ケース図や BPMN などが役に立つでしょう。

それぞれの目的に応じて、共通認識を持ちたい事項に着目してモデリングすることが解決への糸口となるのがわかります。

モデリングする上でのコツ

ソフトウェア開発においては、ゴールは要求にマッチしたソフトウェアを開発し、リリースすることです。開発者 (もしくは開発経験者) ならば、往々にしてモデリングを行うときに、「どう実装しようか」まで頭の中で考えてしまいがちです。すると、この時点で共通認識を持たなければならない事項を見失い、ついつい詳細に踏み込みすぎてしまう恐れがあります。

「途中まで、モデリングしていたけど・・・我慢しきれなくなって実装に入ってしまった。」とよく聞きます。気持はよくわかりますし、場合によってはモデルを記述することに実はあまり意味がない場合もあるため、一概には言えませんが、本来のそのモデリングの意義をもう一度再確認すると、モデリングとうまく付き合っていけるかもしれません。

マイクロソフト株式会社
エバンジェリスト
長沢 智治 (http://blogs.msdn.com/tomohn)