山脇 弘成（SSAITS代表）
PMP®有資格者・Webプロジェクトマネージャー。
大手メディアや官公庁のWebプロジェクト実績多数。
「技術」だけでなく「対話」を重視し、御社の「ほんとは、こうしたかった」を形にします。
プロジェクトの「真の失敗」とは何か？
プロジェクトの失敗とは、どのような状態を指すのでしょうか？
長くプロジェクトマネジメントの世界では、以下の「QCD」のいずれか、または複数に該当した場合に失敗とみなされてきました。
- 予算（Cost）の超過： 予定していた費用を上回ってしまう
- 納期（Delivery）の遅延： 期限を過ぎても成果物が完成していない
- 品質・要件（Quality）の未充足： 要求されていた機能や基準を満たしていない
しかし、最新のPMBOK第8版などでは、これらに加えて「成果の失敗（価値の未創出）」という非常に重要な視点が追加されています。
たとえ納期や予算を完璧に守ってシステムを完成させても、それが「誰も使わないシステム」であったり、「ビジネスの利益（価値）に繋がらないもの」であれば、それはプロジェクトとして大失敗なのです。
「計画通りに作ること（プロセスの成功）」と「価値を生み出すこと（成果の成功）」。現代のプロジェクトマネージャーは、この両方を満たさなければなりません。
プロジェクトが失敗に終わる「3大要因」
プロジェクトの成功率は、長らく「30％程度」と言われてきました。言い換えれば、プロジェクトの約70％は何らかのトラブルを抱え、失敗や炎上の危機に瀕しているということです。
では、なぜそこまで失敗するのでしょうか？
様々な原因が複雑に絡み合っていますが、現場で起きる炎上の根本原因を突き詰めると、以下の「3大要因」に行き着きます。
要因1：見積りのミス（不確実性への準備不足）
「見積りのミス」はプロジェクト失敗の典型的な要因です。
不正確な見積りにより「必要な作業が洗い出せていない」「必要な人員が確保できない」という事態に陥り、結果としてスケジュール遅延や大幅なコスト超過（デスマーチ）を引き起こします。
【対策：予備（バッファ）を積み、段階的に見直す】
プロジェクトには「段階的詳細化（進めてみて初めて詳細がわかる）」という性質があるため、初期段階で完璧な見積りを作ることは不可能です。
そのため、不測の事態に備えてあらかじめスケジュールや予算に「コンティンジェンシー予備（バッファ）」を積んでおくことが不可欠です。また、フェーズが進んで仕様が明確になるたびに、見積りを見直してステークホルダーと再合意するプロセスを組み込みましょう。
要因2：変動・肥大化する仕様（スコープクリープ）
「未確定の仕様」や、プロジェクトの途中で次々と要求が追加されていく「仕様の肥大化（スコープクリープ）」も致命的な要因です。当初の計画が崩壊し、現場が混乱に陥ります。
【対策：変更を前提とし、プロトタイプで合意する】
かつては「設計書を完璧に作り、仕様をガチガチに確定させてから開発する」のが正解とされていましたが、変化の激しい現代では「仕様は必ず変わるもの」という前提に立つのが主流です。
- プロトタイピングの導入： 早い段階で試作品（プロトタイプ）を作り、依頼者と「認識のズレ」をなくす。
- 統合変更管理の徹底： 仕様変更の要望が出た際、現場の判断で安易に引き受けず、「予算や納期にどう影響するか」を評価・審査するルール（チェンジコントロール）を必ず設ける。
要因3：ステークホルダー間の認識ズレと対立（人間関係）
見積りや仕様といった「技術やプロセスの問題」が完璧でも、「人間関係（政治）」でプロジェクトが頓挫することは多々あります。
「現場の担当者は賛成していたが、最終報告で役員にちゃぶ台を返された」「特定の部署が非協力的でデータを出してくれない」といった、ステークホルダー（利害関係者）間の対立やコミュニケーション不足は、プロジェクトの進行を完全にストップさせます。
【対策：徹底したステークホルダー・マネジメント】
プロジェクトの初期段階で、「誰がキーマン（決裁者）か」「誰がこのプロジェクトに反対しそうか」を洗い出し、彼らの期待や不安をコントロールする「ステークホルダー・マネジメント（根回し）」を行うことが、身を護る最大の盾になります。
まとめ：リスク・マネジメントがプロジェクトを救う
以上見てきた「見積り」「仕様」「ステークホルダー」という3大要因は、いずれもプロジェクトに潜む「不確実性（リスク）」です。
こうした失敗要因を事前に予測し、対応策を整理しておく活動をリスク・マネジメントと呼びます。
「もし仕様変更が起きたらどうするか」「もしキーマンが反対したらどうするか」といった対応案（リスク登録簿）をあらかじめ作成し、クライアントやチームとオープンに議論しておくこと。
プロジェクトの失敗を防ぐ一番の近道は、都合の悪い不確実性から目を背けず、真正面から向き合うことなのです。
参考
- ロバート・L・グラス (著)、山浦 恒央 (訳)『ソフトウエア開発 55の真実と10のウソ』日経BP出版センター、2004年