　感覚で言えば、抽象化：具象化のバランスは3：1ぐらいです。つまり全体の1／4ぐらいが注目したい、具象化されていて欲しい割合です。この比率はモデリングの目的や種類、プロジェクト、プロダクトによって大きく異なりますので、あくまでも感覚としてだけ、参考にしてください。抽象ばかりでも駄目、具象化し過ぎても駄目、そのバランスが重要になります。

（11）なぜ具象化したのか、なぜ具象化しなかったのかを追及する

　慣れた人が行うモデリングでは、ここで違和感がないので、問いただす必要はないかもしれませんが、少しでも違和感があれば、質問して追求します。ここがモデリングの肝心になる可能性が高い部分です。

（12）変更に対して強いモデリングになっているかを確認する

　具象化したところが100％コールドスポットであれば問題ありませんが、少しでもホットスポットとなる可能性がある場合は、変更に対してどのように考えているかを質問して追及します。

（13）各モデル図が無理をせずにA4用紙に収まっているかどうか確認する

　ここでは厳し目のA4用紙に収まるかどうかでレビューします。A3用紙でも大きな問題はありませんが A4の方がきっと平和でしょう。概要図とその複数の詳細図がそれぞれA4に納まっているかどうかをレビューで確認します。

　これらのチェックリストとともに、前に紹介したメトリクスも意識してモデル図を描き上げ、レビューをします。次はモデリング成功への道の中心となる、「モデリングの継続的活動」について見ていきます。

持続可能なモデリングを目指して

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