プロジェクトの失敗とその二大要因 –見積りのミスと未確定の仕様–

2019年11月24日

プロジェクトの失敗とは

プロジェクトの失敗とは、プロジェクトが以下の3つの項目の内、いずれかに該当している状態を指します。

  • プロジェクトの費用が予算を上回ってしまう
  • 要求されていた要件が満たされていない
  • 納期を過ぎても成果物が完成していない

まとめると、プロジェクトの失敗とはプロジェクトが費用超過、要件の未充足、納期遅延のいずれかの状態にあることだと言えるでしょう。

プロジェクトの成功率

プロジェクトの成功率は30%と言われてきました。言い換えればプロジェクトの失敗率は70%ということになります。
現代ではISO21500に代表される国際標準や、PMBOKのようなプロジェクトマネジメントの手法が確立されてきたため、成功率は高まっていると期待されますが、依然としてプロジェクトを成功に導くのは容易なことではありません。
では、プロジェクトが失敗に終わる原因は何なのでしょうか。

プロジェクトが失敗に終わる原因

プロジェクトの失敗には、費用超過、要件の未充足、納期遅延などさまざまなものがあります。
しかし「ではなぜ費用が超過したのか?」「要件が未充足に終わったのか?」「なぜ納期に遅れたのか?」と、失敗の原因をさらに深掘りしていっても、その要因を特定することは容易ではありません。
複数の要因が複雑に絡み合ってプロジェクトが失敗していることがわかります。

プロジェクト失敗の二大要因

プロジェクトの失敗を誘う要因は様々ありますが、二大要因として「見積りのミス」「未確定の仕様」が挙げられます。
以下、詳しく見ていきましょう。

見積りのミス

 不正確な見積りの影響

「見積りのミス」はプロジェクト失敗の大きな要因の1つです[1]ロバート・L・グラス (著)、山浦 恒央 (訳)『ソフトウエア開発 55の真実と10のウソ』日経BP出版センター、2004年、42頁。
不正確な見積りはプロジェクトに必要な作業を洗い出せておらず、それに伴って必要な人員等の資源(リソース)を確保できないという結果につながってしまいます。
その結果、リソースがないため作業ができずにスケジュール遅延を招いたり、当初予定していたよりも多い費用を払わなければならなかったりするというプロジェクトの失敗に陥ってしまいます。

見積りを再検討するタイミングを設ける

正確な見積りはプロジェクトの成功を大いに助けてくれますが、これまで見積りの手法が様々考案されている現代においても、プロジェクト・マネジャーを完全に安心させるような見積り手法は誕生していません。
プロジェクトが段階的詳細化、つまり進めてみてようやく詳しい内容がわかるという性質がある以上、プロジェクト開始前には、ミスのない見積りは期待できないでしょう。
そのため、プロジェクト前に作成した見積りにすべてを期待するのではなく、見積りに詳細な注意書きをするほか、仕様が確定した段階で再度見積りを検討するなど、見積りを見直すタイミングを設けたほうが現実的でしょう。

未確定の仕様

仕様を確定させない影響

「未確定の仕様」もプロジェクトを失敗させる大きな要因です[2]前掲『ソフトウエア開発 55の真実と10のウソ』、110頁。。見積りのミスは最悪供給者である開発業者が金銭的な負担をすればプロジェクトそのものは終結させられる可能性があります。しかし、仕様が不正確であると、プロジェクトで求められていた要件を満たすことができず、プロジェクトを終結させられなくなってしまいます。

資料を作成して仕様を確定させる

仕様が確定していない状態に対しては、要件定義書をはじめとする各種資料を作成して対応していきます。
ITプロジェクトではさらに外部設計書・内部設計書などを作成し、取得者であるクライアントの承認を得る必要があります。
また、これらの資料がどの段階まで訂正ができるのかを策定し、開発に移ったのちに仕様が変更されないようにプロジェクト運営をする必要もあるでしょう。

プロトタイピングで認識の相違をなくす

外部設計書・内部設計書のような資料を作成したとしても、取得者側のIT知識が足りない場合は、認識を共有することができず、開発の途中で仕様の変更が発生する可能性があります。
そのため、プロトタイプを作成して供給者・取得者間の認識の差異をなくすことも仕様の確定につながり、プロジェクトの成功率を高めることができます。

リスク・マネジメントを行う

以上見てきた「見積りのミス」「未確定の仕様」はプロジェクトが失敗する主要な要因ではありますが、上述の通り、プロジェクトの失敗にはこの他無数の失敗要因が隠れています。
こうしたプロジェクトの失敗要因を整理し、対処するのがリスク・マネジメントです。リスク・マネジメントを通じて失敗要因、即ちリスクを洗い出し、その対応案も含めたリスク登録簿リスク報告書を作成することで、プロジェクトの失敗を未然に防ぐことができます。
取得者・供給者間で忌憚のない意見交換を行い、不安要素を整理することが肝心だと言えるでしょう。

1ロバート・L・グラス (著)、山浦 恒央 (訳)『ソフトウエア開発 55の真実と10のウソ』日経BP出版センター、2004年、42頁。
2前掲『ソフトウエア開発 55の真実と10のウソ』、110頁。