　なぜなぜ分析では、原因をお金や時間などのリソースのせいにしてはいけないという教えがありますが、ここではこのリソース問題も原因として挙げておきます。しかしこれだけだともう一段深読みしないと、対策の立てようがありません。ですがもう一段なぜなぜ分析をすると、解がない大げさな問題が原因となり無理な対策（例えば、全人類を洗脳するしかないなど）が挙がってくるかも知れませんので、ここでは別の副原因を探ってみます。

　なぜ1回こっきりのモデル図になったのか。その原因は（e1）モデルを再利用するという考えそのものが希薄であることです。また（e2）再利用するためには、ネーミングからもろもろの箇所で抽象化するスキルが必要ですが、そのスキル不足というのもあるでしょう。もちろん、再利用が必要であることも知っていて、そのためのスキルもあるが、時間がない＝お金がないという（e0）が原因である可能性も高いです。しかし、ここでは（e1）と（e2）にスポットライトを当てて対策を考えます。

　（e1）と（e2）の対策はモデル図の再利用の意識付けをすることであり、そのためにはモデラーの育成、教育がまず必要となります。次は開発プロセスにモデル図のリモデリングの時間を入れるなどの改良があります。さらに奥行きのある対策にするには、再利用する文化、そのための教育をする文化の醸成も組織として必要になってきます。

図6. 1回こっきりモデリングのなぜなぜ問答の続き

参考：プログラムの再利用

　プログラムコードの再利用を考えてみましょう。再利用されるプログラムはどんな性質を持っていて、再利用されないプログラムはどんな悪癖を持っているのでしょうか。

　まず再利用されるプログラムには、ツールやユーティリティープログラムなどがあります。これらはライブラリプログラムとして与えられていて、その仕様はきっちりと書かれています。また実行効率も優れていてバグも少ないでしょう。

　一方、再利用されないプログラムは特定システムにのみ適用されるプログラムで、これらはアプリケーションプログラムと呼ばれています。アプリケーションプログラムはライブラリプログラムと比較して、仕様が特定用途向けであり、またしばしばその仕様は不明確で不十分です。これはもう最初から再利用するな、危険！だと言っているようなものです。プログラムが再利用されない直接的な原因は「仕様が不明確・不十分」「用途が特定用途向けで抽象化されていない」があります。

　さらになぜなぜ分析をしてみます。再利用されるプログラムと再利用されないプログラムの差はどこから来るものでしょうか。再利用を前提として作られたユーティリティープログラムなのか、1回こっきりで作られたアプリケーションプログラムの違いは何でしょうか。再利用が前提にあるかどうかが底流にあることは間違いありませんが、そのプログラムを作るのに掛けるコストが違います。つまりお金です。一般にライブラリを作る人は優秀で時間も自由に使って作成されます。これが原因です。その結果が再利用されるか再利用されないかです。つまりモデリングと同じ原因になります。このようになぜなぜ分析はやり方を間違うと、いつも同じ結論になってしまいます。

　「それにつけてもお金の欲しさよ」

失敗しないための、小粒でもピリリとする実践的なコツ

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