無料の教訓テンプレート（Google Sheets、Excel、PDF）

教訓テンプレートとは？

A 教訓テンプレート は、プロジェクトチームが学んだことを記録するための体系的なログです。何が起きたか、うまくいったか改善が必要か、なぜ起きたか、どれほど重要だったか、次回は何を変えるべきかを記録します。各項目は推奨と担当者で締めくくられるため、その知識を同じプロジェクトでも今後のプロジェクトでも再利用できます。

教訓が 特定 状態と、教訓が 習得状態を区別すると役立ちます。「テストの開始が遅れた」と書くことは、教訓を特定することです。それが学ばれたと言えるのは、それを受けて後のフェーズやプロジェクトがテストの計画を変えたときだけです。だからこそ、このテンプレートは観察事項のリストにとどまらず、すべての行に推奨、担当者、アクションのステータスを含めています。

この考え方は主要なプロジェクトマネジメントのフレームワークに共通しています。PMIの*PMBOKガイド*は、 教訓登録簿 をプロジェクト中に最新に保ち、終了時に組織のリポジトリに移すと説明しており、PRINCE2はプロジェクト中に 教訓ログ を使い、教訓を引き継ぐために 教訓報告書 を使います。アジャイルチームは同様の学びを各 スプリントレトロスペクティブで記録します。このテンプレートは、これらのいずれのアプローチでも登録簿として機能します。

教訓によって組織全体の実践を変える方法を含む、より広いプロセスについては、当サイトの次をご覧ください： プロジェクトマネジメントにおける教訓のガイド.

教訓テンプレートのプレビュー

以下は、ダウンロードに含まれる3つのサンプル行を含む最初のタブです。自分の教訓で上書きしましょう。

サンプル行は例です。ご自身の内容に置き換えてください。

テンプレートの内容

• 教訓：#、フェーズ／領域、何が起きたか、うまくいったか改善が必要か？、根本原因、影響、推奨、担当者、アクションのステータス

すべての列には役割があります。下表は、各列に何を書くか、有用な記入とはどのようなものかを説明しています。

初級版、上級版、エキスパート版

• 初級版： 5つの必須の列（フェーズ／領域、何が起きたか、うまくいったか改善が必要か？、推奨、担当者）を持つ1つのタブ。最初のセッションや小規模なプロジェクトに適しています。
• Advanced： 根本原因、影響、アクションのステータスを含む9列すべてと、前述のドロップダウンを備えた完全なログ。ほとんどのチームが継続的な登録簿として使うバージョンです。
• エキスパート版： 上級版のログに加え、説明タブ、担当者別とアクションのステータス別に教訓を自動集計するダッシュボード、アクションのステータス列の色分け、改訂履歴タブ。

教訓テンプレートの記入方法

1. キックオフ時にログを用意する。 共有ドライブにコピーを保存し、ファイル名にプロジェクト名を加え、保存場所をチームに伝えます。教訓の記録は終結時ではなく初日から始まります。
2. 起きたときに教訓を集める。 各フェーズ、マイルストーン、スプリント、重大なインシデントの後に項目を追加します。数日以内に書いた教訓は、数か月後に思い出したものよりはるかに正確です。
3. 何が起きたかを事実に基づく1文で記述する。 人についての意見ではなく、出来事を述べましょう。「サプライヤーは役立たずだった」ではなく、「サプライヤーがハードウェアを3週間遅れて納品した」です。
4. 分類する。 次のどちらかを選びます： うまくいった または 改善が必要。成功も問題と同じくらい丁寧に記録しましょう。それらは繰り返したい実践だからです。
5. 根本原因を見つける。 チームや組織が変えられるものにたどり着くまで「なぜ？」と問い続けます。複雑な問題には、 根本原因分析（なぜなぜ分析）テンプレート または 特性要因図（フィッシュボーン図） が役立ちます。
6. 影響を評価する。 スケジュール、予算、品質、チームへの影響に基づいて、低、中、高を使います。影響によって、どの教訓から議論すべきかを判断できます。
7. 推奨を書き、担当者を割り当てる。 チーム外の人でも実行できるほど具体的にしましょう。複数の人が手伝う場合でも、推奨ごとに担当者を1人割り当てます。
8. アクションのステータスを追跡する。 定例のプロジェクト会議で未完了の推奨をレビューし、未着手から対応中、完了へと進めます。
9. ログを共有して保管する。 終結時にチームとスポンサーとともにログ全体をレビューし、次に引き渡して PMO 、今後のプロジェクトが検索できるようにします（ナレッジベースでも可）。

教訓を引き出すための質問

良い問いは、具体的で有用な教訓を生みます。セッションで次の問いを使うか、事前に送っておきましょう。すべてが必要になるわけではありません。プロジェクトにとって重要な領域を選びましょう。

全体

• 繰り返すべき、うまくいったことは何か？
• 計画どおりに進まなかったことは何か、それはなぜか？
• 何に驚いたか？
• 明日このプロジェクトをもう一度始めるとしたら、何を変えるか？

計画、スコープ、スケジュール

• 目標とスコープは最初から明確だったか？
• 見積りはどれくらい正確だったか、最も外れたのはどこか？
• スコープの変更はどのように要求され、承認されたか？
• 記載されていないのに発生したリスクは何か： リスク登録簿?

コミュニケーションとステークホルダー

• ステークホルダーは、必要な情報を必要なときに得られたか？
• 意思決定は十分に速く、適切な人によって行われたか？
• どの会議や 状況報告書 が役立ち、どれをやめられるか？

チーム、リソース、サプライヤー

• 適切なタイミングで適切な人とスキルがそろっていたか？
• 役割と責任は明確だったか？
• サプライヤーや他のチームは、合意したことに対してどれだけうまく提供したか？

品質と引き渡し

• 成果物は最初から受け入れ基準を満たしていたか？
• 運用部門や顧客への引き渡しはどれだけ円滑だったか？
• 現在その成果を支えている人たちにとって、何があれば助けになったか？

教訓の例

下表は、ウェブサイトのリニューアルプロジェクトの記入済みのログです。各項目に、根本原因と誰かが実行できる推奨があることに注目しましょう。

弱い記入と強い記入

誰にも使われない教訓と実践を変える教訓の違いは、たいてい詳細さのレベルにあります。

複数の項目に同じフォローアップが必要な場合は、アクションを次で追跡し、 アクションプランテンプレート 、ログからリンクできます。

教訓セッションの進め方

セッションの前

• 数日前にテンプレートを共有し、全員に2～3個の教訓を追加してもらいます。
• 中核チーム、主要なステークホルダー、関連する場合はサプライヤーを招待します。全員が発言できる程度の少人数に保ちましょう。
• 可能であれば、プロジェクトマネージャー以外の人にファシリテーションを依頼し、PMが率直に意見を出せるようにします。
• アジェンダを準備します。当サイトの 会議アジェンダテンプレート がうまく機能します。

セッション中

• 最初に基本ルールを伝えます。焦点はプロセスと意思決定であり、個人を責めることではありません。
• フェーズ／領域の列で項目をまとめながら、プロジェクトをフェーズごとに振り返ります。
• 時間の大半を、影響の大きい教訓とその根本原因に使います。
• 次に進む前に、各教訓について推奨と担当者1人を合意します。
• 後で誰かが清書しなくて済むよう、新しい教訓は画面上のテンプレートに直接記録します。

セッションの後

• ログを整理し、すべての推奨に担当者がいることを確認して、数日以内に参加者と共有します。
• 未完了の推奨は、完了するまで定例のプロジェクト会議のアジェンダに加えます。
• 今後のプロジェクトに影響する教訓は、テンプレート、チェックリスト、プロジェクトの方法論の変更に反映させます。繰り返し発生するリスクは、次のプロジェクトの次に記載します： リスク登録簿テンプレート.
• このプロジェクトでまだ修正が必要な問題は、次に移し、 課題ログ 教訓ログに残したままにしないようにします。
• 最終的なログは、次の一環として組織の教訓リポジトリに保管します： プロジェクトの終結.

コツとよくある間違い

• 最後まで待つ。 終結時にしか記録されない教訓は、あいまいで不完全です。各フェーズの終わりやスプリントごとに項目を追加しましょう。
• 人を責める。 セッションが粗探しの場になると、人々は共有しなくなります。個人ではなく、出来事とプロセスを記述しましょう。
• 問題だけを記録する。 成功も同じくらい価値があります。それらは広めたい実践だからです。
• 症状で止まる。 「締め切りが遅れた」は症状です。変えられるものにたどり着くまで、なぜかを問い続けましょう。
• あいまいな推奨。 「コミュニケーションを改善する」は実行可能ではありません。「毎週スポンサーに1ページの状況報告を送る」は実行可能です。
• 担当者もフォローアップもない。 担当者のいない推奨が実行されることはまれです。担当者とアクションのステータスの列を使い、定期的にレビューしましょう。
• 過去の教訓を読まない。 教訓リポジトリのレビューを、すべての新しいプロジェクトを始める際のステップにしましょう。たとえば次を起草するときです： プロジェクト憲章.

教訓、レトロスペクティブ、ポストモーテムの違い

これらの用語は重なり合っています。主な違いはタイミングと範囲です。

スプリントで作業している場合は、当サイトの スプリントレトロスペクティブテンプレート を各スプリントで使い、チームを超えて重要な教訓をこのログにコピーしましょう。教訓と並行して未解決のリスクと課題を追跡するには、次を使いましょう： RAIDログテンプレート.

関連するテンプレートとガイド

RAIDログテンプレートプロジェクトのリスク、前提条件、課題、依存関係を追跡できる無料のRAIDログテンプレート…初級 · 上級 · エキスパートスプリントレトロスペクティブテンプレート無料のスプリントレトロスペクティブテンプレート：うまくいったこと、改善点、アイデア、アクション…初級 · 上級 · エキスパート議事録テンプレート出席者、議論、決定事項、アクションアイテム…を備えた無料の議事録テンプレート初級 · 上級 · エキスパート根本原因分析（なぜなぜ5回）テンプレートなぜなぜ5回を使った無料の根本原因分析テンプレート：問題記述、なぜの連鎖、根本…初級 · 上級 · エキスパートプロジェクト計画書テンプレート無料のプロジェクト計画書テンプレート。目標、スコープ、成果物、タスク、担当者、日付…初級 · 上級 · エキスパートプロジェクト憲章テンプレート無料のプロジェクト憲章テンプレート。目的、目標、スコープ、マイルストーン、予算…初級 · 上級 · エキスパート

すべてのテンプレートを見る

• プロジェクトマネジメントにおける教訓：ガイドと例
• プロジェクト終結：手順、チェックリスト、終結報告書テンプレート
• スプリントレトロスペクティブ：目的、形式、ファシリテーションのコツ

教訓がプロジェクトの終わりにどう位置づけられるかについては、当サイトの次をお読みください： プロジェクト終結ガイド.

よくある質問