なぜいつもITプロジェクトは失敗するのか?
February 06, 2007
2005年に米国で遂行されたITプロジェクト17万件のうち、機能、予算、期間等が当初の想定内に収まったものは16%であり、日本でも、「企業IT動向調査2006」(社団法人 日本情報システム・ユーザー協会)によると、システムの仕上がりに満足と回答したユーザーは10%前後だったそうである。(出典:プロジェクトが失敗するのは当たり前?!@IT情報マネジメント)
また、私個人がザッと調べてみたところ、よく「ITプロジェクトの成功・失敗確率」の英語文献で引用されているのは、ITプロジェクトの遂行度合いを10年以上に渡って調査しているStandish GroupのCHAOS Reportのようだ。これの2004年度版(調査対象は4万案件)によると、
- 失敗に終わったプロジェクトは全体の15%(1994年は31%)
- 納期遅延、予算超過、致命的な機能落ち等はありつつ、まぁ何とかカットオーバーにこぎつけた(Challenged) のが全体の51%
- 上記から逆算すると、成功したのは34%
- "Challenged"だったプロジェクトの殆どは、20%以内の予算超過
- 失敗プロジェクトも含め、予算超過案件全体の平均値は「予算を43%オーバー」(1994年は180%)
- 米国全体で無駄に費やされたプロジェクト費用は$55 billion(1994年は$140 billion)。うち$38 billionが"in lost"、つまり「お金は遣ったんだけど何も生み出さなかった」かな?で、$17 billionが予算超過。
Standish Groupの調査基準の詳細が分からないが、もし仮に、上記の「失敗」の定義が、純粋に「全然システムが作れませんでした~」という事態を指すとすると、これに、「手術は成功しました。患者は死にました」系の広義の失敗プロジェクトを加えると失敗率はもっと上がるだろうから、「成功率は10%台」という数字も、あながちおかしくはないように思える。
まとめると、ITプロジェクトが、予算と納期を守ってカットオーバーし、かつユーザーの期待通りの機能をきちんと提供できる可能性は10に1つ程度らしい。ぶっちゃけた話、ITプロジェクトは殆どが失敗する(広い意味で言うと)ということになる。「10回戦って勝てるのは1回」というのは、ギャンブルで賭ける側とすれば割が良いのかもしれないが、競馬馬だったら良いレースには出れないし、相撲取りだって一場所に1.5勝じゃ出世は厳しいだろう。ましてや戦争だったら、兵士はたまったものではない。
しかし、ITプロジェクトの現場が、爆弾を抱えていたり、火を噴いたりして、火消しが召集され、それでも足りなくて傭兵部隊を投入、なんて話は日常茶飯事だと思う。(これって私の周りだけ?)
- なぜITプロジェクトの見積は大抵失敗するのか。
- なぜ「仕様どおり」実装されたシステムのはずなのに、ユーザーの業務とはズレてしまうのか。
- なぜ日本のIT業界ではパッケージソフトが普及しなかったのか。
- なぜ日本のITプロダクトはなかなかグローバルになれていないのか。
- なぜエンジニアは早く家に帰れないのか。(→「生産効率の高いシステム提案で,エンジニアは早く家に帰ろう」──ソフトブレーンの宋文州氏が講演:ITpro)
最近(に始まった話じゃないけど、)こういうことをよく考えている。頑張っても頑張っても成功しない。これは辛いことだ。でも、現実なんだから、目を逸らすわけには行かない。次回から少しずつ整理しつつ、じゃあどうすれば良いのかも、私なりに考えてみようと思う。
ちなみに、Software Hall of Shame (September 2005, IEEE Spectrum)には、有名?な失敗プロジェクトの数々が列挙されている。ぱっと見、在庫・購買・SCM等のトラブルが多く、次いでERP、それからビリングやCRM、という感じだろうか。
Comments