7.2 振り返りと評価とは?|プロジェクトを成長資産に変えるレビューと分析の技術

7.2 振り返りと評価
プロジェクトを成功に導くために重要なのは、実行中のマネジメントだけではありません。
終了後の「振り返りと評価」こそが、次のプロジェクトをより良くするための土台となります。
本章では、成果だけでなくプロセス・チーム・組織的な視点から振り返りを行い、再現性のある成功と、避けられる失敗を明らかにする方法を解説します。
なぜ振り返りが必要なのか
プロジェクトが終わると、多くのメンバーはすぐに次の業務や案件に移ります。
しかし、振り返りをせずに次へ進むと、以下のような損失が生じがちです:
- 成功の要因が曖昧で、再現できない
- 失敗やミスが繰り返される
- 個人に学びが偏り、チームや組織に共有されない
つまり、振り返りは「過去を責めるもの」ではなく、「未来の成功率を高めるための戦略的行動」です。
振り返りの4つの観点
プロジェクト全体を多面的に評価するには、以下の4つの視点が有効です:
- 成果: 目標は達成されたか?成果物の質、納期、コスト、満足度
- プロセス: 計画・進捗・変更管理の運用は効果的だったか?
- チーム: 連携・役割分担・意思疎通に課題はなかったか?
- 環境: 外的要因(ステークホルダー、組織体制、ツールなど)は適切だったか?
これらを整理することで、単なる「うまくいった/いかなかった」にとどまらず、本質的な学びにたどりつけます。
評価手法:KPT・5つのなぜ・360度レビュー
具体的な振り返り方法として、次のようなフレームワークが役立ちます:
KPT(Keep・Problem・Try)
- Keep: 今後も続けるべき良かったこと
- Problem: 問題やうまくいかなかったこと
- Try: 次に試したい改善案
5 Whys(5つのなぜ)
問題の根本原因を探るため、「なぜ?」を5回繰り返して本質に迫る方法です。
360度レビュー
プロジェクト関係者全員から多面的なフィードバックを集め、チーム内の相互理解と改善の材料とします。
アクションブリッジでの振り返り実践
アクションブリッジでは、振り返りを以下のような形でサポートできます:
- タスクの履歴やコメントを時系列で確認し、意思決定の流れを可視化
- 進捗グラフ(バーンダウン、ガント)を用いてペースと遅延要因を分析
- 振り返り用テンプレート(KPT記録用)をドキュメント形式で共有
- 関係者からの匿名コメント・アンケートで率直なフィードバックを収集
これにより、記憶や主観に頼らず、事実と対話に基づいた振り返りを行うことができます。
振り返りを定着させるには?
形式だけのレビューで終わらせないためには、次の工夫が効果的です:
- 必ず予定を確保し、クロージングプロセスとして扱う
- PMだけでなく全員参加型にする
- 指摘よりも「次に活かす視点」で建設的に進める
- フィードバックを次プロジェクトのWBSやタスクテンプレートに反映する
まとめ:振り返りは「改善の起点」である
振り返りは過去を後悔する場ではなく、未来を設計する場です。
プロジェクトで得た知見を個人の経験にとどめず、チームや組織の“共有資産”に変えていくことが、強いチームの条件です。
→ 次は「7.3 次回プロジェクトへの学び」に進み、ナレッジ化と継承の技術について掘り下げていきましょう。

下田 昌平
株式会社レシートローラーのCEO兼CTOとして、現在電子レシートサービスの開発や、会話を自動で仕分けてアクションタスクを生成するシステム「ACTIONBRIDGE」の開発を手掛けています。幼少期からプログラミングに親しみ、96年には測定器向けのプログラム開発にも携わるなど、技術に対する深い探究心を持ち続けています。 前職では、コールセンター業界最大手の企業の子会社である研究開発会社のCEO/CTOを務め、数多くの技術開発プロジェクトをリードしました。現在もなお、プログラミングの最前線でコードを書き続けています。カテゴリー
タグ
検索履歴
チーム

下田 昌平
株式会社レシートローラーのCEO兼CTOとして、現在電子レシートサービスの開発や、会話を自動で仕分けてアクションタスクを生成するシステム「ACTIONBRIDGE」の開発を手掛けています。幼少期からプログラミングに親しみ、96年には測定器向けのプログラム開発にも携わるなど、技術に対する深い探究心を持ち続けています。 前職では、コールセンター業界最大手の企業の子会社である研究開発会社のCEO/CTOを務め、数多くの技術開発プロジェクトをリードしました。現在もなお、プログラミングの最前線でコードを書き続けています。