フレームワーク活用ガイドひとことで言うと#
プロジェクトで得た**「うまくいったこと」「うまくいかなかったこと」「次はこうしよう」**を記録し、組織の共有資産にするプラクティス。同じ失敗を二度と繰り返さず、成功パターンを他のプロジェクトにも広げるための仕組み。
押さえておきたい用語#
- AAR（After Action Review）
- 米軍発祥の行動後振り返り手法のこと。教訓管理のルーツであり、「何が起きたか→なぜか→次はどうするか」を構造化する。
- 教訓データベース（Lessons Learned Repository）
- 過去の教訓を検索・再利用できる形で蓄積した共有資産のこと。新プロジェクト立ち上げ時に参照する。
- 根本原因（Root Cause）
- 問題の表面的な症状ではなく本質的な発生原因のこと。「なぜ」を繰り返して特定する。
- 横展開（Lateral Deployment）
- ある教訓を他のプロジェクトやチームにも適用すること。成功パターンの横展開が教訓管理の最大の価値。
教訓管理の全体像#
こんな悩みに効く#
- 前のプロジェクトで同じ失敗をしたのに、また繰り返している
- プロジェクトが終わると知見が散逸し、組織に残らない
- 「振り返り」をやっているが、やりっぱなしで改善につながらない
基本の使い方#
プロジェクト完了後だけでなく、節目ごとに教訓を集める。
- フェーズ完了時
- 大きな問題が発生した直後
- プロジェクト完了時（最終レビュー）
ポイント: 記憶が新鮮なうちに記録する。プロジェクト終了まで待つと細部を忘れてしまう。
チーム全員で「何が起きたか→なぜ起きたか→次はどうするか」を議論する。
- What went well?（うまくいったこと）
- What didn’t go well?（うまくいかなかったこと）
- What should we do differently?（次に変えること）
- 安全な場を作り、個人の責任追及はしない
ポイント: 失敗だけでなく成功も必ず振り返る。成功パターンこそ横展開の価値がある。
教訓を検索・再利用できる形で記録する。
- カテゴリ（技術、コミュニケーション、リスク管理など）
- 状況の説明（何が起きたか）
- 根本原因（なぜ起きたか）
- 推奨アクション（次はどうすべきか）
ポイント: 「○○に注意する」のような曖昧な記述ではなく、具体的なアクションを書く。
記録した教訓を次のプロジェクトの計画に実際に反映する。
- 新プロジェクトの立ち上げ時に関連する教訓をレビュー
- チェックリストやテンプレートに教訓を組み込む
- 定期的に教訓データベースをメンテナンス
ポイント: 記録するだけでは価値ゼロ。次のプロジェクトで実際に参照・適用されて初めて意味がある。
具体例#
プロジェクト概要: 6ヶ月の基幹システム移行プロジェクト。予定より1ヶ月遅延して完了。チーム15名、予算8,000万円。
教訓セッション（抜粋）:
| カテゴリ | 状況 | 根本原因 | 推奨アクション |
|---|---|---|---|
| データ移行 | テストデータと本番データの差異で移行に2週間の手戻り | 本番同等のテスト環境がなかった | 移行テストは必ず本番データのサンプルで実施 |
| コミュニケーション | 業務部門への影響が直前まで伝わらず混乱 | 業務部門の代表者が定例に不参加だった | 影響を受ける部門の代表者を必ずステコミに参加させる |
| リスク管理 | ベンダーの遅延リスクを事前に把握できた | 月次リスクレビューが機能した | リスクレビューの月次実施を標準プロセスに組み込む |
活用: 次の移行プロジェクトのキックオフで教訓をレビュー。「本番データでのテスト」をプロジェクト計画に組み込み、同じ失敗を回避。結果として次のプロジェクトでは移行テストの手戻りゼロ、1週間前倒しで完了した。
背景: 自社SaaSを開発する8名のスクラムチーム。レトロスペクティブは実施していたが、教訓が組織に蓄積されず、メンバーが入れ替わるたびに同じ問題が再発。
仕組み構築: Notionに教訓データベースを作成。カテゴリ・タグ・影響度で検索可能に。レトロスペクティブの最後10分で「他チームにも共有すべき教訓」を選定し、データベースに記録するルールを策定。
蓄積された教訓の例:
| 教訓 | カテゴリ | 影響度 |
|---|---|---|
| 外部API連携は必ずモック環境を構築してからテストする | 技術 | 高 |
| デザイナーとエンジニアのハンドオフにはFigma Dev Modeを必須化 | プロセス | 中 |
| 大規模リファクタリングは必ずフィーチャーフラグで段階リリース | 技術 | 高 |
成果: 6ヶ月で47件の教訓を蓄積。新メンバーのオンボーディングに教訓DBレビューを組み込んだところ、新メンバーの初スプリントでの障害発生率が60%減少。チーム全体のバグ発生率も前年比25%改善。
背景: 年間50件以上のプロジェクトを受注する地方建設会社。現場ごとに独自のやり方で進めており、ある現場で起きた問題が別の現場で繰り返されることが常態化。年間の手戻りコストが推定3,000万円。
導入: PMO主導で教訓管理プロセスを標準化。各プロジェクトの中間報告会（月次）と完了報告会で教訓シートの提出を義務化。Excelベースの簡易データベースで管理し、新規プロジェクトのキックオフ時に関連教訓を5件以上レビューするルールを設定。
3年間の成果:
| 指標 | 導入前 | 1年後 | 3年後 |
|---|---|---|---|
| 蓄積教訓数 | 0件 | 120件 | 380件 |
| 年間手戻りコスト | 3,000万円 | 2,100万円 | 1,200万円 |
| 工期遅延プロジェクト率 | 38% | 28% | 15% |
結果: 3年間で手戻りコストが60%削減（年間1,800万円の改善効果）。教訓のレビューが習慣化し、「前に○○現場でこういう教訓があった」とベテラン以外も過去の知見を活用できるようになった。
やりがちな失敗パターン#
- 犯人探しになる — 「誰のせいか」を追及する場になると、本音が出なくなる。問題のプロセス・仕組みに焦点を当て、個人を攻撃しないルールを徹底する
- 記録して終わり — 教訓をきれいにまとめても、次のプロジェクトで参照されなければ無意味。新規プロジェクトのキックオフに教訓レビューを組み込む
- プロジェクト終了後にしかやらない — 半年後の記憶は曖昧。マイルストーンごとに小さく振り返る習慣をつける
- 教訓が抽象的すぎる — 「コミュニケーションを改善する」では次に活かせない。「影響を受ける部門の代表者をステコミに毎回参加させる」のように、誰が何をするかまで具体化する
まとめ#
教訓管理は、プロジェクトの経験を組織の財産に変えるプラクティス。失敗を繰り返さず、成功を再現するために、「記録する」だけでなく「次に活かす」仕組みまで作ることが重要。記憶が新鮮なうちに、安全な場で、具体的なアクションとして記録しよう。