8.2 失敗したプロジェクトの教訓
どれほど綿密な計画を立てたとしても、プロジェクトが失敗に終わることはあります。
しかし、その失敗は単なる「結果」ではなく、次に活かすべき「教訓」として、非常に価値のある情報です。
このセクションでは、失敗したプロジェクトに共通して見られる要因と兆候を、多角的な視点で整理し、再発を防ぐために必要な気づきを丁寧に解説します。
1. 目標が曖昧だった、あるいは途中でブレた
- ステークホルダーごとに異なる期待値が整理されていなかった
- ビジネスゴールが明文化されず、関係者の認識がバラバラだった
- 途中で経営方針が変わり、プロジェクトの目的がズレた
方向性がブレたまま進行すると、プロジェクトは形式的に完了しても「期待外れ」として評価されてしまいます。
2. 課題やリスクの共有が不十分だった
- 課題管理表が形骸化していた
- 現場の声が吸い上げられず、意思決定層に伝わらなかった
- リスクへの事前対応（回避策・緩和策）が準備されていなかった
「言えない雰囲気」「面倒だから先送り」などの文化が残るチームでは、リスクの早期対処が困難になります。
3. 人的要因の見落とし
- PMや重要なリーダーのアサインが遅れた、または不在だった
- レビューや承認が形式だけになっていた
- メンバーの中途離脱による引き継ぎ不足が発生した
人材の安定性や責任感も、プロジェクトを支える大きな要素であることを再認識させられます。
4. プロジェクトマネジメントが機能していなかった
- 状況把握はしていたが、判断や調整に踏み切れなかった
- 定めたルール（レビュー・進捗報告）が守られていなかった
- 報告はされていても、行動につながっていなかった
「わかっていたけど動けなかった」は、失敗の典型的な兆候です。
失敗事例：ECサイトリニューアルプロジェクト（小売企業）
概要： BtoC向けECサイトの全面改修プロジェクト（期間：約8ヶ月、途中で断念）
- キックオフ時点でKGI・KPIが曖昧、要件が流動的
- ユーザー部門との連携が薄く、仕様確認が後手に回った
- 中核メンバーの離職により、対応遅れと連携崩壊が発生
- 公開直前に品質トラブルが多発し、予定通りのリリースを断念
このプロジェクトでは、「目的の曖昧さ」「役割不在」「コミュニケーション不足」が複合的に重なり、リカバリー不能な状態に陥った典型例でした。
まとめ：失敗は“兆候”の積み重ねである
プロジェクトの失敗は、一つの決定的ミスではなく、小さな違和感・放置された判断・見過ごされた兆候の積み重ねで起こります。
だからこそ、「何かがおかしい」と感じた時点で立ち止まり、対話し、修正する勇気と仕組みが必要です。
AB ではこう動かす
上で挙げた失敗パターンは、それぞれ AB Project Management の機能と対応しています：スコープが曖昧 → プロジェクト説明と Wiki の「Out of Scope」ページに、スコープを 1 か所にまとめておけるので、勝手に広がりません。リスクが見えない → Risk タイプのタスクとチェックインの周期で、リスクを「シートの底」ではなく現役のタスクとして残せます。エスカレーションが遅れる → 変更履歴タブがステータスや担当者の変更を自動で残すので、エスカレーション自体を別レポートにする必要がありません。知識が分散する → Wiki ページ、コメント、添付がプロジェクトに紐づくので、ドライブやメールに散らばりません。担当が曖昧 → 担当者フィールドがあるので、各タスクに必ず名前が乗ります。AB は失敗そのものを防ぐ道具ではありませんが、まだ安く直せるうちに失敗を見えるようにしてくれます。
→ 次は「9.0 よくある質問（FAQ）」に進み、実務で直面しやすい疑問や不安を整理していきましょう。