案件が終わったあとのKPT（Keep・Problem・Try）——形式は整っていても、内容が「次はコミュニケーションを密にする」「見積もりはもっと丁寧にやる」という抽象的な感想で終わっていることがあります。
この内容では、半年後に同じ失敗が起きます。「もっと丁寧に」は行動に落とせないからです。
案件終了時の振り返りを次案件に活かすためには、「何が起きたか」を感想ではなく具体的な事実と再現性のある教訓に変える必要があります。この記事では、5つの観点で教訓を記録する方法を解説します。
振り返りが感想で終わる理由
振り返りが「感想」になりやすいのは、「何を残すべきか」のフォーマットが決まっていないからです。
「よかった点・悪かった点」という問いかけは自由すぎます。人は自然と「気持ち・印象・反省」を書きます。「コミュニケーションが悪かった」「スケジュールが甘かった」——これは感想であり、次の行動に変えにくいです。
「次案件で何が変わるか」を問われると、「もっと頑張る」という答えになります。頑張るは行動ではありません。
教訓として残すべきは「次の案件開始時に何を変えるか」です。そこから逆算して、何を記録すればいいかが決まります。
残すべき教訓1：見積と前提
「今回の見積もりで前提としていたことは何か。その前提は正しかったか」を記録します。
具体的に記録する内容：
- 見積もり時の主な前提（仕様確定済み・他社連携なし・顧客確認は週1回 など）
- 実際に前提が崩れた件があれば、それが何でどこに影響したか
- 次回の見積もりで追加すべき前提・条件
「見積精度が低かった」ではなく、「〇〇の前提が崩れたため追加工数が〇時間発生した」という形で残します。次回の見積もり時に「あの案件ではXXが前提だったが崩れた」という参照ができます。
残すべき教訓2：進捗と課題
「進捗を遅らせた原因は何か」と「課題管理で機能しなかった部分は何か」を記録します。
具体的に記録する内容：
- 遅延が発生したフェーズと原因（顧客確認待ち・技術的な問題・体制の問題 など）
- 課題が長期間放置された件があれば、なぜ放置されたか
- 次回、早期に対処するために変えるべきこと
「進捗管理が甘かった」ではなく、「テストフェーズで〇〇の確認待ちが2週間続き、リリースが1週間遅延した。次回は確認待ちをPMが3日以内に督促するルールを作る」という形です。
残すべき教訓3：品質と手戻り
「手戻りが多かった工程と原因」を記録します。
具体的に記録する内容：
- 手戻りが多かった成果物（設計書・実装・テストなど）
- 手戻りの原因（要件曖昧・レビュー不足・担当者スキル不足 など）
- 次回、手戻りを減らすために変えるべきこと
「品質が低かった」ではなく、「設計書の顧客合意が薄く、実装後に仕様変更が3件発生した。次回はキックオフ時に仕様確認チェックリストを使う」という形です。
残すべき教訓4：顧客対応
「顧客対応で苦労した点と、うまくいったこと」を記録します。
具体的に記録する内容：
- 顧客確認待ちが長期化した件とその理由
- 認識ズレが起きた場面とそのきっかけ
- 顧客との合意形成でうまくいったこと（次回も使えるもの）
苦労した点だけでなく、うまくいったことも残します。「この顧客タイプにはこのアプローチが効いた」という知識は、チームの財産になります。
次案件で使える形にする
4つの観点で記録した後、「次案件の開始チェックリスト」に変換します。
チェックリストの形式にすることで、次の担当者（または自分）が同じ案件を始めるときに「何を確認すべきか」がすぐ分かります。
例：
- 見積もり前に〇〇の前提を確認する
- テストフェーズの顧客確認待ちには3日ルールを設ける
- 設計書のキックオフ確認にチェックリストを使う
感想を書くのではなく、チェックリストに変換する——この変換作業が「振り返りを次に活かす」という行為です。
まとめ
案件終了時の振り返りが感想で終わるのは、「何を残すか」のフォーマットがないからです。
見積と前提・進捗と課題・品質と手戻り・顧客対応の4観点で具体的な事実を記録し、それを次案件のチェックリストに変換することで、教訓が行動に変わります。
次案件開始チェックリスト
前案件の教訓から作る「次案件開始時の確認5点」の例です。
- 見積もりの前提（仕様確定・レビュー込み・依存関係）をキックオフ前に確認する
- 設計書のキックオフ時に顧客合意チェックリストを使う
- テストフェーズの顧客確認待ちは3日以上になったらPMからリマインドする
- 週次報告の「判断依頼」欄を毎週必ず使う（なければ「特になし」と書く）
- プロジェクト終了後30日以内に振り返りミーティングをセットする
このチェックリストは前案件の教訓を元に作り直すものです。毎回テンプレートのままではなく、「前回の失敗から1点追加する」という運用が定着の近道です。
同じ失敗を繰り返さないためのナレッジ管理や、組織としてのPM育成を体系的に進めたい方は、法人向けPM育成ページや受託開発PM向けの課題別パックをご覧ください。