nakagamiの日記： プロジェクト成功率は26.7％

日経コンピュータ 2003年 11月 17日号
http://itpro.nikkeibp.co.jp/free/NC/TOKU1/20031111/1/

痛々しいタイトル。

徹夜の連続で、かつバグがいっぱいあって、納期に間に合わず、
出来上がったものは、当初の営業に言っていたものとは似ても似つかぬ
使えない代物・・・という状況が目に浮かぶ。
私も、今までやってきたものの中で、文句なく成功！と胸を張っていえるのは、
イチローの打率ほどもあればいい方かなぁ。

ここでいっている、プロジェクトの成功というのは
・納期
・予算
・出来上がったものの品質（バグがないかだけでなく、要件を満たして使いやすいか）
が、すべて揃ってないといけないので、

「トップセールスで決まった ERP の導入で、予想以上のアドオンが必要に
なり、出来上がったものが、ベストプラクティスとやらで、今までのやりかたと
違って使いにくくなった（とか、在庫も減ってないとか）」
というのは、すべからく失敗になってしまう。

記事中にも、「本当はもっと少ないんじゃないか」といっている人もいるし、
私は、予算や納期が超過しても、出来上がったものが使えるんなら
（ないより、あった方がましなら）、まぁ成功といってあげてもいいんじゃないか
（それでも半分くらいだろうけど）
と思ったりもするが、この数値は、一つの指標として、非常に参考になる。

編集部の作業には頭が下がるが、記事中で、コメントしている人達の中で
「だから、プロジェクトマネージメントが必要だ」「リスク管理が必要だ」と、
トンチンカンなことをいっている人がやっぱりいた。
（編集も、そういう方向に持っていきたいのだろうけど）

失敗の原因は
1.きちんと、要件がヒアリングできる人がいない
2.きちんと設計できる人がいない
3.素早く、正しくコーディングできる人がいない
ひいては、これらの作業が、変に分業になっていて、下流工程のことを知らないのに
スケジューリングしてしまう、プログラムを知らないマネージャがいるから
いけないのだ。

リスク管理をいくら叫んでも、ものを作れる人が集まらなければ、
いつまでたっても出来上がらないのに。