ガイド › ガイド

教訓（ふりかえり）テンプレート

教訓をまとめた文書の多くは、一度書かれ、丁寧に保管され、二度と開かれません。これは、次のプロジェクトで実際に何かが変わるように作ったテンプレートです。

教訓が活かされない理由

誰かが違うやり方をして初めて、教訓は「学んだ」ことになります。「コミュニケーションをもっと良くできた」という段落は何も変えません。担当者もおらず、効果があったかどうかも分からないからです。

そこで以下のテンプレートは、すべての教訓に、証拠、原因、担当者つきのアクションを求めます。答えられないなら、それは教訓ではなく愚痴です。

テンプレート：コピーして使う列

教訓1件を1行とするシンプルな表を使います。書き方は事実に基づき、責める調子にならないようにします。

• 管理番号と、プロジェクトのフェーズ（立ち上げ、計画、実行、完了）。
• カテゴリ：スコープ、スケジュール、コスト、人、取引先、ガバナンス、技術、コミュニケーション。
• 何が起きたか。事実を1〜2文で。
• 影響：失った日数、増えたコスト、影響を受けた効果。分かる範囲で。
• 根本原因：症状ではなく、理由の奥にある理由。
• 提言、アクションの担当者、適用されるチームやプロセス。

セッションの進め方

記憶が新しいうちに、できれば稼働開始から数週間以内に開催し、スポンサーだけでなく作業した人も招きます。可能なら、デリバリーチーム外の人に進行を頼みましょう。プロジェクトマネージャーは自分のプロジェクトについて中立でいることが難しいからです。

3つの問いで進め、それぞれ議論の前に10分間の黙読・記入を行います。声の大きい人が議題を決めないようにするためです。

• うまくいき、繰り返すべきことは何か。
• うまくいかなかったことは何か、根本原因は何か。
• 次回は何を変えるか、誰がそれを実現するか。
• 最大の問題2〜3件には「なぜ」を5回繰り返す。
• あらかじめルールを合意する：議論するのはプロセスと決定であり、人ではない。

教訓を変化につなげる

出てきた意見を、行動に移せる教訓と、単に興味深いだけの教訓に仕分けます。行動できるものには担当者と期日をつけ、PMOのプレイブック、プロジェクト開始チェックリスト、次のプロジェクトのリスク登録簿テンプレートなど、人の目に再び触れる場所に置きます。

• 繰り返される問題は、新規プロジェクト用の標準リスク一覧に追加する。
• テンプレートとチェックリストは、「いずれ」ではなく同じ週のうちに更新する。
• 主な教訓5件を、PMOと次のプロジェクトマネージャーに名指しで送る。
• 新プロジェクトのキックオフごとに、ログを見直す。

進めながら教訓を記録する

最良の教訓ログは、第1週から始まります。何かが起きるたびに1行足すほうが、最後に気合いで記憶をたどるより価値があります。SenshinではこれをRAIDログと一緒に管理できるため、振り返りの時期には、終了した課題や決定事項がすでにそろっています。

Senshinでの位置づけ

よくある質問

その他のガイド

最終更新: 2026-10-22