モデリングで失敗しないために――失敗から学ぶモデリングの実践的なコツ：プロジェクトを成功させるモデリングの極意（5）（4/10 ページ）

モデリングを失敗しないためには、失敗の原因と失敗しないためのコツを知ることが肝要です。今回は失敗しないための実践的なコツを紹介します。

[五味弘，MONOist]

• 1回こっきりモデリング

　（a） 抽象化がデタラメで仲間内しか通じないモデル図を作ってしまった、（b） なぜそうなった？、（c） どうせ今回1回しか使わないモデル図だから面倒、（d） なぜ1回しか使わないのか？ ← 今、ここです。

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

　本当になぜ1回しか使わないのでしょうか。モデル図は再利用されてこそ意味があるものです。プログラムコードよりも抽象度の高いモデル図は再利用もしやすいはずです。

　ではなぜ1回しか使わないモデル図になったのでしょうか。その答えは （e0） 抽象化して再利用可能にするためのコストを掛ける計画でないからです。つまりモデルを作り直す「リモデリング」のコストと時間を掛けていないからです。

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

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

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

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

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

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

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

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

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

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