ふとした思い付きで、他の人がなぜプロジェクトが失敗すると考えているのか、検索して、いくつかの記事を読んでみた。 それぞれ主張していることは違いがあるし、 みんな自分の立場で発言しているから、 どれが正しいとも言い難いのだが、 いくつか書き留めておきたい。

まず、The top 10 reasons why projects failから、

スポンサーが目標に対して献身的でない。 会社の戦略に合致していない。 間違った理由で開始した。 人員配置がよくない（技術が足りない、専念していない等）。 プロジェクトのスコープがいい加減。 計画がなってない（存在しない、古すぎる等）。 コストが勘定に入ってない。 資金が足りない。 マネージメント技法がなってない。 反省を活かしていない。

The six key reasons why projects failから、

ユーザの関与が足りない。 期間が長すぎる。 必要条件がでたらめ。 スコープがどんどん広がる。 必要条件の変更管理がされていない。 試験をちゃんとやらない。

After all this…. Why Do Projects Fail?より、

ユーザの声が足りない。 利害関係者が喧嘩する。 あいまいな必要条件。 コストとスケジュールの推定がでたらめ。 仕事に見合った技術がない。 必要な人材さえいなくなるようなコスト削減。 計画の失敗。 コミュニケーション不足。 アーキテクチャがださい。

他にも、 Why do Projects Fail?、 Why do projects fail?、 Why Do Projects Fail などなど、この話題は無数に語られているようである。

しかし、全体的に意見の一致を見ているのは、 ヒトが最も重大な鍵を握っているということのようだ。 カネや技術の話題ももちろん出現しているのだが、 中には技術はプロジェクトの成否に関係ないと言い切っている人までいるほどである。

確かに、技術が問題になる以前でマネージメントで失敗してしまえば、 もはや技術は無関係な世界になるわけで、 いかにヒトが重要であるか、経験と照らし合わせて、よく理解できる。 とりわけユーザが十分にプロジェクトに時間やエネルギーを割くことの重大性はほとんどの記事で指摘されているが、 これは必ずしもサービス提供側の勝手な言い分とも言えないのではないか。

話は脱線するが、自分がこの業界に入ってからよく分かったことの一つは、ソフトウェアを開発している会社は、評判という意味で、とても不利な立場にいるということだ。 なぜならば、

客が原因で失敗した場合。 客が悪いと公言するわけにはいかないので、SIerは製品が悪かったことにする。 SIerが原因で失敗した場合。 自分が悪かったと公言するわけにはいかないので、SIerは製品が悪かったことにする。 製品が本当に悪くて失敗した場合。 なるべくならSIerの責任したいが、大抵は言い逃れができないので、開発ベンダ自身の責任となる。当たり前だが。

という場合分けが成り立ってしまうからなのだ。 自分が悪くても他人のせいにしたがるという性質のおかげで、 どっかにしわ寄せが来るわけで、ソフトウェア関連では大体ソフトウェアを作っているところに来てしまうんである。

実際、ろくにシステムアーキテクトもできないような駄目なコンサルティング会社が、当然のように大型プロジェクトで失敗して、 その挙句にソフトウェアがいけてないことにしたのを、かなり間近に見たことがある。 うちの会社とは直接関係なかったけれど、間接的には風評被害を受けたので、えらい迷惑だった。

そういうのが分かってきてから、 まともな能力があるんだかないんだか知りもしない人が何とかいうソフトウェアは駄目だとか言っていても、私はもうあんまり信用しないことにしている。 本当にそのソフトウェアが駄目なのか、その人が駄目なのか、分かりようがないからだ。 ソフトウェア開発というものが属人的な性格を強く帯びている以上、 関わった人間を抜きにしては何も語れないよなあと思うのであった。

どうしてソフトウェア開発が個々の人間の能力に深く依存していて、 工場のようにはならないのか、私なりの理論があるのだが、 それはまたの機会に。