２２２の法則
残念なことに、ＩＴ投資ではコスト・納期・品質（機能）が期待通りに実現できることは、むしろ少ないのです。昔から「情報システムは、期待した２倍のコスト、２倍の時間がかかり、期待した１／２の機能しか実現できない」という、「２２２の法則」がいわれていました。
スタンディッシュ・グループの調査（１９９４年）によれば、計画された開発プロジェクトのうち、成功した（品質、コスト、納期のすべてが計画を満足した）のは１６.２％に過ぎず、不成功（いずれか一つ以上が計画内で実現でききなかった）とキャンセルされたプロジェクトの平均値では、費用は１８９％、時間は２２２％かかり、機能は５３％しか実現していないそうです。まさに２２２の法則です。
その後、次第に改善されてきましたが、それでも「成功」になった割合は３割程度にとどまっています。（図表）（注１、分析）（注２、原因）
スタンディッシュでの「キャンセル」とは、開発途中で、費用や納期がかかりすぎるなどの理由で、開発を打ち切ったことです。
１９９４年の結果を見て、当時、私はこの割合が高いのに驚きました。「計画が雑だ」ということではなく、関係者が「打ち切る勇気がある」ことに驚いたのです。
危ないことに気付きつつ、打ち切る勇気がないままに、さらに深みに陥ってしまうことが多いのではないでしょうか。企業倒産の多くは、撤退戦略が不適切なことが原因だといわれています。
ところで、なぜ、「コスト」の成功割合が多いのでしょうか？
「コスト」は予算で明確になっており、超過を認めてもらうには、「追加予算規程」による制度に従う必要があります。
それに対して、「納期」や「品質」に関しては、明確な稟議規程がなく、関係者への説得だけで認められます。
しかも、「品質」に関しては、マトモな管理さえしていないことが多いのです。
コスト増加が懸念されたとき、「カネは出せない。仕方がないから機能を削ろう」と逃げるのでないでしょうか？
→参照：「２４２３の法則」
計画通りに実現しない原因は多様です。なかには「計画がズサンだった」とか「認めてもらうために楽観的な数字を示した」「当初から無理だと思ったが押し切られた」ということもありますが、主な原因は、「要件分析の不十分」と「想定外の事態」です。
要件分析が不十分なまま開発を開始し、後工程になってからそれが見つかると大きな手戻りが発生します（参照：「要件定義の重要性」)。対象業務の利害関係者が増え複雑になるのに伴い、要件がまとまらない、実施段階になってから重要な要件が指摘されることが多くなってきました。
想定外の事態でよくあるのが、新しいハードウェアやソフトウェアを前提として開発したのに、予定した性能や機能が利用できないことです。コストダウンや利便性向上を図るために、新技術を採用するのですが、反面、不安定なことが多いのです。また、システム開発、ネットワーク、データベースなど多様な技術が必要で多数のベンダが参加するようになり、そのインタフェースでのトラブルが発生する機会が多くなりました。
このようなトラブルを減らし影響を最小に抑えるために、プロジェクトマネジメントが重視されています。（参照：「プロジェクトマネジメントとＰＭＢＯＫ」)