まずは2423の法則と222の法則を知ろう！

2423の法則をご存じでしょうか。
システム開発の外注において、様々なトラブルが起こるのは、実は最近始まった事ではありません。
そこで昔から、2423の法則という物が存在しています。

どんな内容かといいますと、

１．契約時は発注者も受注者も２の規模を想定。
２．開発の途中で、仕様変更や見落としていた要件が追加され、４の規模に。
３．受注者は４の規模で請求しようとするが、発注者は２の規模の金額でやって貰いたい。
４．その結果、お互い１ずつ譲歩して３の規模・金額で開発。

発注者も受注者も１ずつ不満を持つという事です。

また222の法則というものもあります。
「情報システムは、期待した２倍の費用、２倍の時間がかかり、期待した１／２の機能しか実現できない」
というものです。

木暮　仁氏が書かれた、【「経営と情報」に関する教材と意見】によりますと、1994年スタンディッシュ・グループの調査では、

プロジェクトに成功したのは16.2％で、不成功とキャンセルされたプロジェクトの平均値は費用は189％、
時間は222%、機能は53%

だそうです。
昔の数字ですので、勿論改善されてきてはいますが、それでも自分が望むシステムを手に入れるという事は当り前に見えて、とても難しいという事がお解りになるかと思います。

なぜ、費用・時間が2倍もかかるのか？

システム開発は、仕様変更に沿った形で開発されるので、それがあいまいだったり間違っていれば当然、大きなトラブルとなります。よく例えに使われるのが、家を建てる事。

図面の設計の段階ならば、間取りの変更も簡単ですが、実際に基礎工事が終わってから、やっぱりもう一部屋欲しい！となってももう遅いわけです。コストの面から見ても膨大な費用がかかるでしょう。

先ほどの【「経営と情報」に関する教材と意見】に、こんな事が載っています。

【「経営と情報」に関する教材と意見】より引用

ベーム（Barry w. Boehm, “Software Engineering Economics,” Prentice-Hall, 1981.）は、要件定義が確定した段階で、要求の誤りを発見して修正する場合のコストを１としたとき、後の段階で発見して修正するコストは、

設計段階　　　　　　　　５
プログラミング段階　　１０
稼働開始後　　　　　１００

になると指摘しています。
また、全体の欠陥のうち、プログラミングのエラーによるものは３５％程度で、６５％は、それ以前の要件定義や設計の上流工程で埋め込まれるとの指摘もあります。

要件定義や上流工程で埋め込まれる欠陥が65%！というのは、恐ろしい話ですね。

プロにお任せは危険

2423、222の法則が存在する事自体、こういったトラブルが「よくある事」だという事を表しています。この認知があれば、

「システムの事は良く解らないから、プロに任せてしまおう。」
「プロなんだから任せても安心。上手くやってくれるだろう。」
「何かあれば、直して貰えばよい。」
「コンピュータなんだから、修正も簡単に出来るだろう。」

といった考えが、危険な事が良く解ると思います。
反対に、

「発注者と受注者とが協力し、要件定義に時間をじっくりかける事」

これが、発注のコツと言えるのではないでしょうか。

【参考サイト】

• ＠IT情報マネジメント：システム部門Q＆A（2） 木暮 仁　氏
  [1] なぜ情報化投資は初期計画より増えるのか？
• 木暮 仁　氏
  [2] 「経営と情報」に関する教材と意見