　なぜ、入力を曖昧にしたままモデリングをしてしまったのでしょうか。これも原因はいろいろと考えられます。（e1）情報を聞き取ることが困難であった、（e2）確定した情報は誰も持っていなくて、これから決めようとしていた、（e3）情報が曖昧だということを気づかなかったなどが挙げられます。他にも理由があるでしょうし、（e1）と（e2）は原因と結果の関係かも知れません。原因の深堀りはここまでにして、これらの対策を考えてみましょう。

　ここでは（e2）の対策を考えてみます。これは（e1）の原因であるかも知れませんので（e1）の対策になる可能性もあります。そしてきっと（c）の対策である「曖昧なままにモデリングをしない」という意味のない対策よりは、開発現場に実効的な対策が立てられるでしょう。

　（e2）の対策としてはずばり、曖昧である箇所も許すことです。大事なのはどこが何の理由で曖昧にしているのか、さらにその影響を閉じ込める、または影響範囲を明記することになります。つまり、「曖昧な箇所の明記と分離」です。これをホットスポットと呼んでもいいでしょう。さらに運用的に言えば、ホットスポットの書き方を統一しておく方がいいでしょう。ノートに書くだけでも、UMLであればステレオタイプにするのもいいですが、表記を統一することが分かりやすくするために重要で、それがコツになります。

図4. 曖昧モデリングのなぜなぜ問答の続き

1回こっきりモデリング

モデリングはなぜ失敗するのか―― 悪いモデル、汚いモデル、意味がないモデル
誰もが失敗したくてモデリングする訳ではないのに、失敗しているモデリングを見る機会は減りません。今回はモデルの失敗例を通じてその原因を探ります。
UMLやSysMLなどのモデリングは“いつ”“何を”“どうするのか”
「モデリングはいつ誰が何をどのようにするのか」――今回はソフトウェア開発の現場で、モデリングを実際にどのように実施しているのか見ていきましょう。またUMLやSysMLの使いにくいところを、開発現場ではどのようにカバーしているのかも見ていきます。
UMLやSysMLを活用できないエンジニアのための実践的活用術（後編）
前編では「モデル」の目的とその効果、具体的なモデル手法について代表的なものを説明しましたが、後編ではその手法を実践するツールを紹介します。
UMLやSysMLを活用できないエンジニアのための実践的活用術（前編）
モデリングの手法やツールの基礎を覚えるだけでなく、モデリングの目的やその本質をつかんで、ソフトウェアの開発現場で実際に役立つように基本を学んでいきましょう。