レトロスペクティブ テンプレート：形式と記入例、そしてアクションアイテムを次のレトロまで生かす方法(2026)

レトロスペクティブとは、チームがスプリントやリリース、1か月といった期間の働き方を振り返り、何を変えるかを決めるミーティングです。何を作ったかはレビューで扱います。レトロで扱うのは、どう作ったかです。何が作業を遅らせ、何が進めやすくしたのか。次回は何を1〜2つ変えるのか。レトロスペクティブ テンプレートは、この対話を決まった順序で収める1枚のページです。これがあると、ミーティングが不満のリストではなく、決定を生み出します。

このガイドでは、まず手法を扱います。形式、コピーして使えるスプリントレトロスペクティブ テンプレート、記入済みの例、多くのチームがローテーションで使う4つのプロンプトセットです。その後、仕組みを説明します。チームがすでに使っているツールのどこにレトロがあるのか、そして通話のあとアクションがどうなるのかです。レトロスペクティブの本当の試金石は、1時間の終わりのボードではないからです。試されるのは次回の最初の5分間です。全員で合意した2つの変更が実際に行われたのかを、誰かが尋ねるときです。

レトロスペクティブとは何か、何ではないか

レトロスペクティブの近くには4つのミーティングがあり、チームはこれらを混ぜてしまいがちですが、代償を伴います。

レトロスペクティブは、4つのうちチーム自身を対象とし、チームのいる場で、チームが決める唯一のミーティングです。だから成果物は小さくなります。チームが1サイクルで変えられる習慣は1〜2つで、10個ではありません。リストが長いレトロは、たいてい名前を間違えたレビューかインシデントレビューになっています。スプリントレビューのアジェンダとレトロのアジェンダが別のページであるのには、理由があります。

レトロスペクティブは、感想を言い合うだけのステータスミーティングでもありません。「スプリントの感想を順番に言いましょう」では、気分は出てきても変更は生まれません。以下のテンプレートでは、意見の前にデータを、発言の前に書くことを、1時間が終わる前に決定を求めます。

テンプレートに含めるもの：形式

使えるレトロスペクティブ テンプレートには、次の順序で7つのパートがあります。ネット上のテンプレートの多くはこの一部だけで、特に抜けやすいのは最初と最後です。

1. 前回のレトロのアクションの確認。 何よりも先に、前回の各アクションについて、担当者と次の3つの状態のいずれかを確認します。完了、理由付きの未完了、取り下げです。3件のリストなら2分で済みます。この枠を飛ばすレトロは、アクションが任意であると宣言しているようなもので、場の全員がそれを感じ取ります。
2. 期間の事実。 何をリリースし、何が遅れ、何が壊れたかを、数字や日付で、誰かが話す前にボードに載せます。3〜5行です。同じ事実をもとに議論すれば意見は収束します。それぞれの記憶をもとに議論すると、収束しません。
3. うまくいったこと。 まず書きます。1人につき1点ごとに1枚のメモとし、そのあと読み上げます。先に書くというルールのおかげで、静かな半数のメンバーの声が届きます。レトロが2人の声に支配されてしまう、よくある原因への対策でもあります。
4. うまくいかなかったこと。 同じ方法です。メモは作業と働き方についてのもので、人についてのものではありません。個人名を挙げたメモは、ファシリテーターが1on1向けの「パーキングロット」に移します。
5. グループ化と選択。 メモをクラスターにまとめ、各自が取り上げたいクラスターに2票ずつ投じます。上位1〜2つが、残り時間のレトロの主題になります。残りは次回に回し、回したもののリストは保管します。
6. 1〜2つの変更をアクションとして。 選ばれた各クラスターについて、チームが約束する変更を、アクションアイテムとして書きます。担当者は1人、動詞は1つ、期日は1つです。「見積もりを上手くなる」は願望です。「Lena — 木曜のプランニングに15分の見積もりチェックを加える — 次のスプリントから」はアクションです。
7. 担当者、確認日、感謝。 アクションを担当者とともに読み返し、確認日(通常は次回のレトロ)を伝え、名前を挙げた感謝を1周して締めます。最後の項目は飾りではありません。次回、項目4のメモを書いてもらえる雰囲気をつくるのは、これです。

含めないものは、レビュー(スコープ)、インシデントレビュー(1つの障害のタイムライン)、1on1(1人の人)に属する内容です。それらを抱え込もうとするレトロは長引き、何も決まりません。

進め方：事前、当日、事後

事前：枠を固定し、事実を準備する。 レトロスペクティブは定例のミーティングで、実際にリリースしたものをもとに話せるよう、レビューのあと、次のプランニングの前に置きます。1週間のなかでの位置づけはミーティングケイデンスのガイドにあります。前日にファシリテーターが、チームのチャンネルに期間の事実(リリース済みリスト、遅れたリスト、インシデント)と、担当者付きの前回のアクションを投稿します。こうしておけば、項目1と項目2は会議中にまとめるのではなく、会議の前に読んでおけます。ファシリテーターは持ち回りにします。毎回マネージャーが進めるレトロは、マネージャーへの報告会になってしまいます。

当日：先に書き、そのあと決める。 まずアクションの確認から始めます。各担当者が、完了か未完了かとその理由を1文で話します。次に、事実を1分で読み上げます。それから、うまくいったことと、いかなかったことを、8分間静かに書きます。メモは書かれるたびに全員に見えるようにします。ボードが翻訳されるなら各メンバーの言語で、されないなら場で決めた1つの言語で書きます。読み上げ、クラスタリング、投票には15分かけます。選ばれたクラスターに残りの時間を使います。この間のファシリテーターの唯一の仕事は、時間切れになる前に、話を名前のついたアクションに変えることです。各アクションを声に出して読み返し、担当者に二度同意してもらいます。最後の5分間は、担当者付きのアクションと確認日を確認し、感謝で終えます。

事後：当日中に、次のレトロが開くはずの場所にページを公開する。 ノート付きのボード、選ばれたクラスター、担当者付きのアクション、前回のアクションとその状態を、1ページにまとめて、欠席した人を含む全員に送ります。そして、次のレトロが始まる場所に置きます。次のページの冒頭にあるアクション確認は、今回のページの末尾にあるアクションリストのコピーです。ファシリテーターのノートに眠っているレトロは、チームのものになっていないレトロです。

1時間をどう進めるか、つまり冒頭、タイムボックス、最後の5分間での成果の読み返しは、あらゆる効果的なミーティングと同じ技術です。レトロに特有なのは、先に書くルールと、変更は2つまでという上限です。

スプリントレトロスペクティブ テンプレート

[チーム] — レトロスペクティブ、スプリント [番号] / [期間]
日付: [日付] · 時間: [開始]〜[終了] · リンク: [ミーティングリンク]
目的: 働き方の変更を1〜2つ選び、前回選んだ変更を確認する。
ファシリテーター: [名前、持ち回り] · 記録: [名前、または「リキャップ」]
事前資料: 前回のレトロのページ、今期の事実

1. 前回のレトロのアクション — ファシリテーター — 5分 — 情報共有
– [担当者] — [アクション] — 期日 [日付] — 完了 / 未完了: [理由] / 取り下げ
– [担当者] — [アクション] — 期日 [日付] — 完了 / 未完了: [理由] / 取り下げ

2. 期間の事実 — ファシリテーター — 3分 — 情報共有
リリース済み: [リスト]。遅れ: [リスト]。障害: [リスト]。[今期に重要な数字を1つ。]

3. うまくいったこと — 全員、まず書く — 8分 — 議論
[メモ。1点ずつ。書いたあとに読み上げる。]

4. うまくいかなかったこと — 全員、まず書く — 8分 — 議論
[作業と働き方についてのメモ。人についてではない。]

5. グループ化と投票 — 全員 — 10分 — 決定
クラスター: [A]、[B]、[C]。各自2票。選択: [1〜2つ]。次回に回す: [残り]。

6. 私たちが約束する変更 — チーム — 15分 — 決定
– [担当者] — [動詞＋目的語] — [日付]から — [日付]のレトロで確認
– [担当者] — [動詞＋目的語] — [日付]から — [日付]のレトロで確認

7. 担当者、確認日、感謝 — 5分
アクションを担当者とともに読み返す。確認日: 次回のレトロ、[日付]。1人1回、名前を挙げて感謝を伝える。

パーキングロット: [挙がったが選ばれなかった項目 — 次回のレトロのページに持ち越す]

このテンプレートはプレーンテキストなので、ドキュメント、キャンバス、ホワイトボードの付箋列、チャットメッセージのどれにも、書式を直さずに貼り付けられます。大事なのは順序で、ツールではありません。

記入例：2週間のスプリントを終えた、8人のプロダクトチーム

プラットフォームチーム — レトロスペクティブ、スプリント31
目的: 働き方の変更を1〜2つ選び、前回選んだ変更を確認する。
ファシリテーター: Mateusz · 記録: リキャップ
事前資料: スプリント30のレトロのページ、昨日チャンネルに投稿されたスプリント31の事実

1. 前回のレトロのアクション — 5分
– Priya — リスボンのメンバーがライブで参加できるよう、デイリーを9:30に移す — 期日 11月2日 — 完了
– Kenji — モバイルトラックの完了の定義を1ページにまとめる — 期日 11月6日 — 未完了: QAリードの修正待ち。期日を11月20日に変更

2. 期間の事実 — 3分
計画した11項目のうち9項目をリリース。遅れ: エクスポートジョブ、オンボーディングメール。障害: 1件、40分、検索インデックス。木曜のレビューは25分超過。

3. うまくいったこと — 8分
検索の修正をペアで行い、当日中に完了した。チャンネルに事実が残っていたので、「何をリリースしたか」を誰も二度聞かなかった。リスボンのメンバーが毎回のデイリーに参加した。

4. うまくいかなかったこと — 8分
スプリント開始時に、2項目の仕様が中途半端だった。デモを会議中に準備していたため、レビューが長引いた。インシデントレポートが3日遅れで書かれた。

5. グループ化と投票 — 10分
クラスター: スプリント開始時の準備状況(6票)、レビューの長さ(4)、インシデントの報告書(3)、見積もり(2)。選択: 準備状況、レビュー。次回に回す: インシデントの報告書、見積もり。

6. 私たちが約束する変更 — 15分
– Lena — プランニング前の火曜に、各項目の準備状況チェックを行う。1行の仕様と担当者がない項目はスプリントに入れない — スプリント32から — 11月28日のレトロで確認
– Tomás — レビュー当日の正午までに、デモ環境を準備しテストを済ませる — スプリント32から — 11月28日のレトロで確認

7. 担当者、確認日、感謝 — 5分
読み返し済み。確認日: 11月28日。検索のペア作業をしたPriyaと、早い時間から参加してくれたリスボンのメンバーに感謝。

パーキングロット: インシデントの報告書、見積もり — スプリント32のレトロで最初に扱う。

このページが機能する理由に注目してください。最初の項目と最後から2番目の項目は、2週間を隔てて見た同じリストです。スプリント31のアクションは、スプリント30のページの下部で生まれ、今回のページの上部で評価されました。スプリント32のアクションは、11月28日に評価されます。このループこそがレトロスペクティブの価値のすべてであり、多くのテンプレートが記憶任せにしている部分です。

4つのプロンプトセットと、それぞれが合う場面

テンプレートの項目3と4は一対のプロンプトで、チームは同じ組み合わせに飽きてきます。次の4つはよく知られた代替案で、いずれも最後は項目5と6に進みます。

どのセットを使う場合でも、守るべきルールは2つです。話す前に書くこと、そして成果物は担当者付きの1〜2つのアクションであることです。メモの壁は豊かになっても決定が生まれないプロンプトセットは、ミーティングを面白くした分、役に立たなくしています。

すでに使っているツールのなかで、レトロはどこにあるか

主要なプラットフォームはいずれも、レトロにボードやドキュメントを提供しますが、どこで止まるかはそれぞれ異なります。以下はベンダー自身のページに記載された動作のみを対象とし、各事実を確認した月を添えています。

どの行にも共通することが2つあります。1つは、レトロのボードがミーティングの横にあるドキュメントで、書かれた、あるいは行われた1つの言語のままであることです。もう1つは、前回のアクションが実行されたかどうかは、ドキュメントが答えてくれる問いではないことです。次のミーティングで誰かが前のページを開き、場に向けて読み上げます。それで問題ない場合は、4つのどれを使っても構わず、この表がそのまま答えです。TeamsやMeetの通話の文字起こし、録画、サマリーが、そのあとどこに保存され、誰がまだ開けるのかは、TeamsとMeetが文字起こし、録画、サマリーを保存する場所にまとめています。各プラットフォームのライブ翻訳が通話中にどこまでカバーし、どこで止まるのかは、TeamsとMeetのガイドにあります(Teams、Meet)。

アクションを次のレトロまで生かす方法

InterMINDは、ミーティングがチャンネルの中に残るコミュニケーションの空間です。そのため、レトロスペクティブには自然な置き場所があります。専用のチャンネルです。そこに前日、期間の事実と前回のアクションを投稿します。チャンネルは各回のリキャップを保管するので、スプリント30のページはスプリント31のページからワンクリックの距離にあります。各メンバーは自分の言語で入力し、ほかのメンバーの発言を自分の言語で読みます。ほかの場所で下書きしたページは、メールでチャンネルに届きます。ホストがチャンネルに専用のアドレスを設定すると、そこに送られたメッセージが、送信者名つき、添付ファイルそのままの通常のメッセージとして表示されます。

通話中、ボードは Share to conference で、ビデオタイルの隣、全員の画面に置かれるノートになります。場がポイントを書き込む間、ファシリテーターがそれをライブで編集し、参加者全員が自分の言語でそれを読めます。原文はトグルひとつで切り替えられます。前回のセッションのリキャップも同じ方法で会議に共有できるので、項目1の前回のレトロのアクションは、誰かの記憶ではなく、全員の画面にある実際の記録になります。

通話が終わると、リキャップがミーティング自体から作成されます。サマリー、合意済み・未決・意見が分かれたと印のついたポイント、担当者付きのアクションアイテムで構成され、各行にタイムスタンプが残ります。リキャップはメールで、チャンネルのメッセージとして、カレンダーの予定のリンクとして届き、サインインしたメンバーは誰でも自分の言語で読めます。記録は、場がたまたま使った言語で一度だけ書かれるのではなく、読み手ごとに翻訳されます。どのメンバーも編集でき、編集のたびに作成者と改訂履歴が残ります。ホストは、トラッカーやCRMの受信メールボックスなど、任意のアドレスにリキャップのコピーを追加できるので、2つのアクションは誰かが転送しなくても記録システムに届きます。TeamsとMeetは、上で見たドキュメントによれば、その場の言葉を翻訳します。通話中の字幕や、ミーティングの言語でのリキャップです。ここでは、翻訳された状態に留まるのは空間そのものです。

チームステータスページをオンにした組織では、レトロのアクションの確認も行われます。リキャップが記録するすべてのアクションは、組織のタスクチェーンに加わります。次のリキャップが書かれるとき、未完了のものは、話された内容と照らして判定されます。完了したと報告されたアクションは完了とされ、話し合われたが終わっていないアクションは、ミーティングの言葉による理由とともに未完了とされ、誰も触れなかったアクションは未完了のままです。判定結果は組織のステータスページに載り、それぞれ根拠となったリキャップが添えられます。次のセッションの冒頭では、Miaが未完了の項目とその担当者を読み上げます。そのため、誰も前のページを開かなくても、テンプレートの項目1は話題になります。チームステータスページはプレビュー機能です。組織の管理者がアルファ版の規約に同意したうえで、Settings → Advanced でオンにします(Preview featuresページで各機能を説明しています)。

ゲスト、たとえばスプリントに参加している外部契約者や、1回のレトロに招かれたクライアントのエンジニアは、リンクからアカウントなし、無料で、スマートフォンやブラウザから参加し、ミーティングを自分の言語でライブで聞けます。ゲストには、あとから残る記録はありません。記録にアクセスできるようにするのはアカウントで、アカウントは無料です。ホストが空間を提供し、有料プランでは、過去28日間にアクティブだったメンバーに対してのみ料金を支払います。静かになったメンバーも、無料でアクセスを維持できます。

• 完全なリキャップを開く — あなたのリキャップを作るのと同じコードで描画された、本物の記録です。アクションアイテムも含まれます。
• ライブデモを試す — サインアップ不要。話すと、聞き手ごとに翻訳された場の声が聞こえます。

手法としてのレトロスペクティブは、どのツールを使っても変わりません。誰かがチームに何を変えるかを尋ね、答えを2つに絞らせる必要があります。残らなくていいのは2つ目の仕事です。通話のあとにボードを1つの言語で打ち直すことと、前回決めたことを誰かがやったのかを尋ねて次のレトロを始めることです。

FAQ

レトロスペクティブミーティングとは何ですか?

レトロスペクティブは、チームがスプリント、リリース、1か月といった期間の働き方を振り返り、働き方の1〜2つの変更を約束する、定例のミーティングです。最初に前回のレトロのアクションを確認し、期間の事実をボードに載せ、うまくいったことといかなかったことを書いて集め、グループ化して投票し、担当者と確認日のあるアクションで締めくくります。作ったものを見るレビューや、1つの障害を見るインシデントレビューとは別物です。

スプリントレトロスペクティブはどう進めますか?

レビューのあと、プランニングの前に枠を固定し、前日にチームのチャンネルへ期間の事実と前回のアクションを投稿します。ミーティングでは、前回のアクションを確認し(5分)、事実を読み上げ、誰かが話す前に、うまくいったことといかなかったことのメモを静かに書き、読み上げ、クラスタリングし、各自2票で投票します。残りの時間は、上位1〜2つのクラスターを、担当者1人と期日1つのアクションに変えることに使います。アクションを読み返し、確認日(通常は次回のレトロ)を伝え、感謝で締めます。ページは当日中に、次のレトロが開く場所に公開します。

レトロスペクティブの5つのステージとは何ですか?

広く使われる5段階の構成は、場を整える(目的、前回のアクション、ルール)、データを集める(期間の事実と全員のメモ)、洞察を生み出す(メモをグループ化し、背後にあるパターンを見つける)、何をするか決める(担当者付きの1〜2つのアクション)、締めくくる(読み返し、確認日、感謝)です。このガイドのテンプレートは、項目ごとにこの段階に対応します。項目1〜2が場の設定と事実の収集、3〜5が収集とグループ化、6が決定、7が締めくくりです。

スプリントレビューとスプリントレトロスペクティブの違いは何ですか?

レビューは作業、つまり何を作り、それが意図したものか、バックログで何が変わるかを、ステークホルダーが同席して見ます。レトロスペクティブは働き方、つまち何がチームを遅らせ、何を変えるかを、チームのみで見ます。レビューの成果は承認された項目とバックログの変更で、レトロの成果はチームの働き方についての1〜2つのアクションと、前回のアクションの完了・未完了です。実際にリリースしたものをもとに話せるよう、レトロはレビューのあとに置きます。

Start, stop, continueとは何ですか?

3つの列を持つレトロスペクティブのプロンプトセットです。チームが始めるべきこと、やめるべきこと、続けるべきことを挙げます。基本テンプレートの「うまくいったこと／いかなかったこと」の組の代わりに使え、メモから直接アクションを出したいチームに向いています。「始めること」のメモは、すでにアクションの半分だからです。グループ化、投票、約束する変更は1〜2つまでという上限は、引き続き適用されます。

レトロスペクティブの4つの質問とは何ですか?

定番のレトロスペクティブでは、何がうまくできたか、何を学んだか、次回は何を違うやり方にすべきか、まだ何が腑に落ちないか、の4つを尋ねます。これは4Ls(Liked、Learned、Lacked、Longed for)の別の形で、四半期やプロジェクト終了時のように、改善と同じくらい学びが重要な、より長い期間に向いています。

スプリントレトロスペクティブはどのくらいの長さにすべきですか?

2週間のスプリントで、5〜10人のチームなら45〜60分です。内訳は、前回のアクションに5分、事実に3分、書くことに16分、読み上げ、クラスタリング、投票に15分、変更に15分、締めに5分です。いつも長引くレトロは、レビューやインシデントの議論を持ち込んでいることが多く、極端に短いレトロは、書くことやアクションを飛ばしていることが多いです。

レトロスペクティブ テンプレートには何を含めるべきですか?

7つです。前回のレトロのアクションとその状態、期間の事実、うまくいったこと、うまくいかなかったこと(どちらもまず書く)、グループ化と投票、担当者と期日のあるアクションアイテムとして書いた1〜2つの変更、そして読み返し、確認日、感謝による締めくくりです。次回に回したものはパーキングロットに残します。多くのテンプレートが飛ばす2つの部分は、最初と最後から2番目です。つまり古いアクションの確認と、新しいアクションへの担当者と期日の設定です。これらが、1回のレトロを次のレトロにつなげます。

出典: Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Recap in Microsoft Teams; Zoom — Generating meeting agenda with AI Companion; Zoom — Using Meeting Summary with AI Companion; Google — Calendar & Meet settings for "Take notes for me"; Google Meet — "Take notes for me" in Google Meet; Slack — Meeting agenda template; Slack — Use huddles in Slack。表の各セルには、その事実を確認した月を記載しています。Microsoftのノートのページ、Zoomのアジェンダのページ、Googleの各ページ、Slackの各ページは2026年10月に、Microsoftのリキャップのページ、Zoomのミーティングサマリーのページは2026年8月に確認しました。5段階の構成とプロンプトセットは一般的な実務慣行であり、ベンダーの主張を含みません。ベンダーはプラン、機能、対応言語を随時変更します。最新の状況は各社のページでご確認ください。