いま、「間違いだらけの業務システム開発」ということで連載しているが、開発プロジェクトがうまくいったのか、そうでなかったのかという実態がどうなっているのかを知ることも参考になると思う。

いささか古いので恐縮ですが、日経コンピュータの2008年に行われた「第2回プロジェクト実態調査」ではシステム開発プロジェクトの成功率が３１．１％だったという報告がある。その5年前の第1回の結果が２６．７％だから、さほど向上していない、まあ同じようなものだ。大方7割のプロジェクトが失敗だったという。

ところで、ここでいうプロジェクトの成功率とは「Q（Quality）、C（Cost）、D（Delivery）」、すなわちシステムの「品質」「コスト」「納期」の3点について当初の計画を順守できたかどうかを尋ね、品質、コスト、納期の3基準すべてで「当初計画通りの成果」を収めたプロジェクトだけを「成功」と定義している。けっこうハードルが高い基準だ。

ただ、これも少々誤解がありそうだ。つまり、システムをつくることをゴールにしているからである。「品質」にどれだけビジネスへの貢献度を加味できているのかがよくわからないので軽々には言えないが、「当初計画通りの品質」というのが微妙である。それ以上に、品質の定義も問題である。

というのも、「当初計画通りの品質」が開発プロジェクトでできるかどうかで、おそらくそれは無理であろうと思う。実際にそのシステムでオペレーションしていくうちにブラッシュアップされて、「当初計画通りの品質」が達成できるではないだだろうか。

ただし、それで終わりではないはずで、求められる品質は日々変化しているわけで、そうなると「当初計画通りの品質」を達成することがゴールではない。その時々でビジネスの要求に応えられる最適な品質を継続的に実現していることが究極のゴールになるでしょう。

さらに、この調査で驚いたのは、5年間でほとんど成功率の向上がみられなかったことである。この間、失敗しないためのプロジェクト管理とかいって、様々な手法や技術が提示されたはずである。それがなにも生かされていないということを意味する。というより、すばらしい手法や技術が有効ではなかったことを意味している。

それはなぜだろうか。プロジェクト管理手法や技術は進歩し、人のスキルも向上したのになぜなのだろうか。答えは、変われていないものがあるからである。作っている業務システムの構造が旧来のものと同じだからである。これは、このブログでも再三指摘したことである。

作っているものが従前から、見てくれではなくて、中味が本質的に進化していなかったら、いくら先進的な技術や開発方法で作ったところで同じことを繰り返すだけなのだ。昔から作られている業務システムは構造的に開発に失敗する要素を素性として内在しているのだ。これが、根源的な問題である。

だから、この構造問題を解決しない限り、次の5年後の2013年に調査しても同じ結果になるのではないだろうか。