　これは前回の記事や前節で紹介した「一回こっきりモデリング」のアンチパターンそのものだと思われるかも知れません。しかし一回こっきりモデリングで言及したのは、これから作るモデル図を再利用可能にするために抽象化して使えるものにするということです。再利用できないモデル図を無理やりに再利用することではありません。再利用しにくいモデル図を再利用することは決してあってはいけません。ここの教訓はこれだけです。

今すぐ必要とされるものだけモデリングする

　これは必要とされているものだけモデリングするというものです。もっとハッキリ言うと、「今すぐに必要とされてないものは描かない」というコツになります。デザインレビューで突っ込まれるから、いちゃもん的な質問やコメントをもらいたくないから、防御的にモデル図になんでもかんでも入れてしまおうというものは止めてくださいということです。これは前回の記事の「相反する目的を持つモデル図の失敗例」で紹介したものになります。

　ここまで極端な例を出すまでもなく、またアジャイル宣言の文言を出すまでもなく、必要とされるまでモデル図に描かないという方針は立派なコツになります。ただし、レビューのときには耐え忍ぶ必要があります。「それは今回のレビュー対象ではありません」とはっきり言い切りましょう。

今見る人だけを対象にしてモデリングする

　このモデル図をこの期間に誰が見るかをはっきりさせてモデリングします。将来的に見る人やもしかしたら見る人を対象にせずにモデル図を作成します。これは「1回こっきりモデリング」のアンチパターンになる危険性があります。想定していない人が見ると、理解できないモデル図になるかも知れません。特に中の人だけに向けて描かれたモデル図は外の人には理解されないでしょう。

　このようにここで挙げたコツはモデル図の再利用や抽象化などに反してしまう可能性があります。この問題に対する解決方法はモデル図の対象者を明記することになります。悪い言い方をすれば、想定外の人を門前払いすることです。このコツはやや危険な劇薬になっています。

モデリングの利用状況

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