振り返りシートのテンプレート｜プロジェクトの教訓を残す書き方と記入例

プロジェクトが無事にリリースされました。全員がほっとしつつも少し疲れていて、すでに次の仕事にも半分取りかかっています。誰かが1時間の振り返り会を設定し、チームは苦労話をいくつか披露し合い、記録係は二度と誰も開かないドキュメントを埋めます。そして半年後、次のプロジェクトがまったく同じ轍を踏むのです。

この繰り返しを断ち切るのが、よくできた教訓（レッスンズラーンド）のテンプレートです。金曜日には忘れられている、その場限りの反省会ではありません。何がうまくいき、何がうまくいかず、それはなぜかを構造化して記録し、その場にいなかった人でも読んで理解し、同じ落とし穴を避けられるようにしたものです。両者の違いは、ほぼ構造で決まります。この記事では、プロジェクトの振り返りシートとして私たちが実際に使っているテンプレート、そのままコピーできる記入例、そして遠慮ではなく本音で話せる場にするためのファシリテーションのコツを紹介します。

レッスンズラーンド（lessons learned）とは？

レッスンズラーンド（lessons learned、教訓）のドキュメントとは、プロジェクトが後に残す、長く使える知識のことです。PMI（Project Management Institute）は、これを「再利用できるように知識を記録すること」と位置づけています。大事なのは、この「再利用」という言葉です。レトロスペクティブ（スプリントの振り返り）が改善するのは次の2週間です。教訓の記録は、プロジェクトが終わり、メンバーが入れ替わった後も生き続けるべきものです。

教訓を記録するのに適したタイミングは3つあります。ところが多くのチームは1つ目しか使わず、しかもうまく使えていません。プロジェクトの終了時には、チームが解散する前に振り返りの場を設けます。メンバーが新しい仕事に移ると、細かい記憶はすぐに薄れるからです。大きなマイルストーンやフェーズゲートでは、プロジェクトの途中で教訓を記録します。そうすれば、次のプロジェクトに注意を残すだけでなく、同じプロジェクトの中で実際に軌道修正できます。そして重大なインシデントの後は、数日以内にまとめます。タイムラインをありのままに再現できるほど、記憶が新しいうちに書くためです。

PMI 自身のガイダンスでは、終結（クロージング）の段階でワークショップを開き、プロジェクトマネージャーだけでなく関係部門の代表者を招き、中立的なファシリテーターが進行することを勧めています。最後の点は見た目以上に重要なので、後ほど改めて取り上げます。

レトロスペクティブ・ポストモーテムとの違い

この3つは混同されがちで、そのせいで目的に合わない会議を開いてしまうチームがあります。重なる部分はありますが、それぞれ視点が異なります。

レトロスペクティブは、定期的に行うチームの習慣です。問題があったかどうかにかかわらずスプリントごとに開き、視線はチームの内側に向いています。問いは「自分たちはこのチームとして、次のイテレーションでどうすればもっとうまく協力できるか」です。先を見越して、決まったリズムで行うものです。ポストモーテムは、何かが起きてから行う、対象の狭い振り返りです。失敗したリリースや障害など、特定の失敗の後に開き、タイムラインを組み立てて、二度と起こさないための根本原因を1つ突き止めます。いわば調査です。

教訓（レッスンズラーンド）のドキュメントは、その両方よりも範囲が広いものです。プロジェクト全体を対象とし、失敗と同じくらい成功も扱い、その場にいなかった人に向けて書きます。レトロスペクティブはチームを改善し、ポストモーテムはインシデントを分析します。教訓は、次のプロジェクトと組織の記憶に生かされます。インシデントを含む厳しいスプリントの後に3つすべてを行うことはもちろん可能で、成熟したチームは実際にそうしています。ただし、3つは別々の成果物で、1つにまとめるべきではありません。

ヒント：会議には目的どおりの名前をつける。 「レトロ」と呼んでいながら、実際には来年のプロジェクトのために記録を残したいのであれば、参加者は記録よりもガス抜きを優先してしまいます。最初に「この内容はプロジェクトのアーカイブに残り、次のチームが読みます」と伝えましょう。この一言だけで、出てくる意見の質が変わります。

教訓テンプレートに欠かせない6つの項目

世の中には10列、12列もあるテンプレートが出回っていますが、ほとんどは使われずに終わります。私たちが運用を続けてわかったのは、本当に必要なのは6つの項目だということです。どれか1つでも欠けると、ドキュメントは知らないうちに役に立たなくなります。

1. 観察（何が起きたか）

出来事や傾向を具体的に書きます。「コミュニケーションが悪かった」では役に立ちません。「デザインの引き継ぎに受け入れ基準がなく、QA が推測でテストケースを作った」と書けば教訓になります。

2. 結果（うまくいったか、いかなかったか）

良かったか悪かったかを示す、シンプルな印です。成功も記録しておく必要があります。うまくいったことを繰り返すことが価値の半分を占めるのに、多くのチームはそれを記録し忘れるからです。

3. 根本原因（なぜ起きたか）

表面の症状ではなく、その下にある仕組み上の状態を書きます。最初に出てきた答えで止めず、さらに掘り下げましょう。「遅れた」は原因ではありません。「見積もりはフルメンバーでの稼働を前提にしていたが、2人がサポート当番も兼務していた」が原因です。

4. 推奨事項（次回どうするか）

具体的で実行できる変更を書きます。「コミュニケーションを改善する」ではなく、「スプリントに入れる前に、すべてのチケットに受け入れ基準を必須とする」のように書きます。

5. 担当者（誰が引き継ぐか）

チームではなく、必ず個人名を書きます。PMI はこの点をはっきり示しています。推奨事項ごとに、それを実行するか、できない場合はその理由をエスカレーションする責任を持つ担当者が必要です。「チームで直します」は、誰も直さないのと同じです。

6. カテゴリ（後から探せるように）

教訓ごとに、スコープ、スケジュール、コスト、品質、リスク、リソース、ステークホルダー、コミュニケーションといった領域のタグを付けます。カテゴリがあるからこそ、次の PM は40件のドキュメントを読まなくても、「スコープについて学んだことすべて」をアーカイブから検索できます。

コピーして使える教訓テンプレート（振り返りシート）

テンプレートは次のとおりです。ドキュメント、Wiki、スプレッドシートに貼り付け、教訓1つにつき1行ずつ追加していきます。テンプレートの本体はヘッダー行だけで、空の行に記入していきます。

表の上には、前提を伝える短いヘッダーを付けます。プロジェクト名、期間、参加者、ファシリテーターです。後から読む人は、誰のプロジェクトで、おおよそいつのことなのかがわからないと、当時の条件が自分たちにどこまで当てはまるかを判断できません。

振り返りシートの記入例

テンプレートだけではイメージしにくいので、架空のプロジェクトで同じテンプレートを埋めてみました。リリースは2週間遅れたものの、スコープは守った顧客ポータルの再構築プロジェクトです。4行のうち2行が成功事例である点に注目してください。不満ばかりのドキュメントは責任追及の記録のように読めてしまい、次の振り返りで誰も本音を話さなくなります。

4行だけですが、どの行も行動に移せるほど具体的で、担当者の名前があり、次の PM が探せるようにタグが付いています。目指すべき水準はここです。あいまいな20行よりも、的を射た4行のほうが価値があります。

本音を引き出す、誰も責めない振り返りの進め方

テンプレートを用意するのは簡単です。難しいのは、上司が同席する場で本当のことを話してもらうことです。次のような工夫が効果を発揮します。

中立的なファシリテーターを立てましょう。理想は、プロジェクトの評価に利害のない人です。プロジェクトを率いた PM が、その検証の場を仕切るべきではありません。結論に思い入れが強すぎるからです。どの問題も、人ではなくプロセスの問題として捉えます。根本原因を「Priya が基準を書き忘れた」ではなく「準備完了の定義のチェックがなかった」と書けば、参加者は身構えずに済み、分析も的確になります。そして、うまくいったことから始めます。不満に入るための前置きとしてではなく、本気で取り上げてください。建設的な雰囲気ができ、残すべきやり方も見えてきます。

さらに、会議の前に、できれば匿名でいくつか意見を集めておきましょう。いちばん口数の少ない人が最も重要な教訓を持っていることはよくありますし、悪い報告ほど対面の場では上がってきにくいものです。簡単な事前アンケートを用意しておけば、誰も最初に口にしたがらないことを拾えます。

ヒント：記録係と進行役を分ける。 ファシリテーターが、良い議論を導きながら正確な記録を取ることはできません。どちらかが必ずおろそかになり、たいていは記録のほうです。専任の書記を決めるか、会議を録音しておきましょう。そうすれば、ファシリテーターは議論に集中でき、後から文言を確認できます。

教訓の価値は記録の質で決まる

誰も認めたがらない失敗パターンがあります。会議は充実し、議論も率直だったのに、出来上がったドキュメントが薄いというものです。誰かがタイピングしながら半分だけ聞いていて、推奨事項は言い換えられるうちにぼやけ、担当者2人の名前は記録されないままでした。会話は宝の山だったのに、記録は付箋1枚分しかありません。

ここで役立つのが AI 議事録ツールです。Laxis のようなツールは会議を録音して文字起こしし、発言されたアクションアイテム、決定事項、担当者を自動で抽出します。そのため、テンプレートの「推奨事項」と「担当者」の列は、疲れた書記が1時間後に思い出して書いた内容ではなく、参加者が実際に約束した内容から埋められます。Zoom、Google Meet、Microsoft Teams で使え、100以上の言語に対応しているので、分散チームにも向いています。無料プランもあるので、次のプロジェクトの振り返りで試せます。ファシリテーターは議論に集中でき、記録は正確に残ります。

すべての推奨事項と担当者を自動で記録

Laxis が教訓の振り返り会議を録音し、アクションアイテム、決定事項、担当者を抽出します。進行役は会話に集中できます。

Laxis を無料で試す

まとめ

教訓のドキュメントの価値は、書いたかどうかでは決まりません。次のプロジェクトが始まる前に、誰かがそれを開くかどうかで決まります。推奨事項はアーカイブではなく、バックログとして扱いましょう。前回のプロジェクトで未対応の項目をキックオフに持ち込み、最初のスプリントが始まる前に担当者を割り当てます。誰も行動に移さない教訓は、高くついた感想にすぎません。

よくある質問

教訓テンプレート（振り返りシート）には何を入れればいいですか？

6つの列を入れます。何が起きたか（観察）、うまくいったかどうか（結果）、その背景にある根本原因、具体的な推奨事項、個人名で書く担当者、そしてスコープ、スケジュール、コスト、品質、リスク、コミュニケーションといったカテゴリです。担当者とカテゴリの列があることで、単なるメモの一覧が、次のチームが実際に行動でき、検索もできる記録に変わります。

教訓の振り返りはいつ行えばいいですか？

タイミングは3つです。チームが解散して記憶が薄れる前のプロジェクト終了時、途中で軌道修正できる大きなマイルストーンやフェーズの終わり、そして重大なインシデントから数日以内の、詳細を覚えているうちです。PMI は、終結の段階でワークショップを開き、プロジェクトマネージャーだけでなく関係部門の代表者を招くことを勧めています。

教訓のドキュメントとレトロスペクティブの違いは何ですか？

レトロスペクティブは、チームの今後の協力の仕方を改善するために、スプリントごとに繰り返し行うチーム中心の習慣です。教訓のドキュメントは、将来のプロジェクトや、その場にいなかった人が再利用するための、長く残り検索できる記録です。レトロスペクティブは次の2週間を、教訓は次のプロジェクトを良くします。

教訓のドキュメントとポストモーテムの違いは何ですか？

ポストモーテムは対象が狭く、特定のインシデントに絞ったものです。1つの失敗を掘り下げてタイムラインを組み立て、二度と起こさないために根本原因を突き止めます。教訓のドキュメントはもっと範囲が広く、プロジェクト全体の失敗だけでなく成功も記録します。壊れたものだけでなく、繰り返すべきやり方も残します。

誰も責めずに本音で話せる振り返りにするには、どうすればいいですか？

結果に利害のない中立的なファシリテーターを立て、どの問題も人ではなくプロセスの問題として扱い、根本原因は人の名前ではなく仕組みの状態として書きます。会議の前にいくつかの意見を匿名で集めておくと、控えめな人の声や悪い情報も表に出てきます。そして、うまくいったことから始めて、建設的な雰囲気をつくりましょう。