レトロスペクティブは、スプリントなど一定の区切りごとにチームが自分たちの仕事のやり方を検査し、次の区切りに向けて改善を決める場です。日本語では「ふりかえり」と呼ばれます。スクラムではスプリントの最後に置かれる正式なイベントであり、思いつきの反省会ではなく、目的とタイムボックスが定められた設計物です。
ただ、現場で崩れるのはたいてい進行の技術ではありません。材料が人の記憶しかないことが原因です。2週間前に何が起きたかを全員がうろ覚えのまま集まれば、議論は印象論に流れ、出てくる改善案も「気をつける」で終わります。この記事では、レトロスペクティブの定義を一次情報で押さえたうえで、ふりかえりの材料をリポジトリのデータから自動で集め、決めたアクションを追跡し、改善の成果を指標で確認するまでを、実際に動かせるコマンドとワークフローで解説します。
まとめ：レトロスペクティブは事実の準備とアクション追跡で決まる
先に結論を置きます。レトロスペクティブの質を決めるのは司会の腕前ではなく、会の前に事実が揃っているかと決めたことが次の区切りまでに追跡されるかの2点です。この2つを仕組みで担保すれば、進め方の型（KPTなど）は後から差し替えが効きます。逆に、型だけ洗練させても材料と追跡が無ければ、会は感想の交換で終わります。
- 定義：スクラムではスプリントを締めくくるイベント。1か月スプリントで最大3時間のタイムボックス。
- 事前準備：マージ済みPR・インシデント・未消化のアクションを
ghで機械的に集め、会の冒頭に置く。 - 自動化：GitHub Actions の
scheduleで、スプリント末にふりかえり用issueを事実つきで自動生成する。 - 計測：DORAの指標（デプロイ頻度・変更のリードタイムなど）を並べ、改善が効いたかを数字で確認する。
- 追跡：アクションは担当者と期限つきのissueにし、次回の冒頭で状態を点検する。
- 向かない場面：単発の請負案件、1〜2名の体制、区切りが定義されていない開発。
レトロスペクティブとは何か｜スクラムが定める目的とタイムボックス
言葉としての retrospective は「過去を振り返る」を意味しますが、開発の文脈では特定のイベントを指します。ここを曖昧にしたまま「反省会をやろう」と言うと、目的が個人の反省になってしまい、本来の狙いから外れます。
スクラムガイドが定義するスプリントレトロスペクティブの位置づけ
The 2020 Scrum Guide は、スプリントレトロスペクティブの目的を「品質と有効性を高める方法を計画すること」と定めています。スクラムチームは、前回のスプリントについて個人・相互作用・プロセス・ツール・完成の定義という観点で何がうまくいき、どんな問題が起き、それがどう解決された（あるいはされなかった）かを検査します。
位置づけも明確で、このイベントがスプリントを締めくくります。タイムボックスは1か月スプリントで最大3時間。2週間スプリントなら1時間〜1時間半あたりが現実的な枠になります。ここで押さえたいのは、対象が「個人の頑張り」ではなくプロセスとツールを含む仕事のやり方全体だという点です。ビルドが遅い、レビュー待ちが長い、環境構築に半日かかる——こうした仕組みの話こそが本来の議題になります。
スクラムそのものの進め方を整理したい場合は、スクラム開発とは（進め方・役割・メリット）とアジャイル開発とはを先に読んでおくと、イベント間の関係がつかみやすくなります。
ふりかえり・反省会・レトロスペクティブという言葉の違いを整理する
3つの語は現場で混ざりがちですが、指すものが違います。混同すると会の設計も参加者の心構えもずれるため、チーム内で用語をそろえておく価値があります。
| 呼び方 | 対象と目的 | 開催の区切り |
|---|---|---|
| レトロスペクティブ | プロセスとツールの改善計画 | スプリント末（定期） |
| ふりかえり | 同上の日本語表現 | スプリント末（定期） |
| 反省会 | 問題の原因と責任の確認 | 不定期・事後 |
| ポストモーテム | 障害の事後分析と再発防止 | インシデント後 |
反省会とポストモーテムには存在意義がありますが、レトロスペクティブの代わりにはなりません。定期的にやり方を見直して調整するという考え方は、アジャイル宣言の背後にある原則の12番目に置かれています。障害が起きたときだけ集まるのでは、この原則が求める定期性が満たされません。
ふりかえりの材料をgh CLIとjqでスプリントの事実から集める
ここからが本題です。会の前に、そのスプリントで実際に何が起きたかをデータで揃えます。GitHubを使っているチームなら、gh コマンドだけで十分な材料が手に入ります。
マージ済みPRのリードタイムをコマンド一つで一覧にする具体手順
gh pr list のマニュアルによると、--state には open / closed / merged / all を指定でき、--search ではGitHubの検索構文がそのまま使えます。--json で取り出せるフィールドには createdAt・mergedAt・number・title・additions・deletions などが並んでいます。作成からマージまでの経過時間を計算すれば、レビュー待ちの実態を数字で確認できる仕組みです。
# 直近スプリント（14日）にマージされたPRを、作成からマージまでの時間つきで並べる
gh pr list --state merged --limit 100 \
--search "merged:>=2026-09-01" \
--json number,title,createdAt,mergedAt \
--jq '.[] | [.number, .title, (((.mergedAt|fromdateiso8601) - (.createdAt|fromdateiso8601)) / 3600 | floor)] | @tsv'
# 同じ母集団からリードタイムの中央値（時間）だけを出す
gh pr list --state merged --limit 100 \
--search "merged:>=2026-09-01" \
--json createdAt,mergedAt \
--jq '[.[] | ((.mergedAt|fromdateiso8601) - (.createdAt|fromdateiso8601)) / 3600] | sort | .[length / 2 | floor]'
出力を眺めると、たいてい極端に長いPRが数本混ざっています。その1本を取り上げて「なぜ5日止まっていたのか」を聞くだけで、レビュー担当の偏り、仕様の揺れ、依存待ちといった構造的な問題が表に出ます。
記憶ではなく数字を持ち込むと議論は人から仕組みの話へと変わる
データを冒頭に置く効果は、議題の質より先に議論の向き先に現れます。「Aさんのレビューが遅い」は人の話ですが、「レビュー待ちの中央値が38時間で、うち7割が特定の1人に集中している」は仕組みの話です。後者なら当番制やレビュアー自動割当という打ち手に進めます。
集める材料は、PRだけに限りません。インシデントのissue、デプロイ回数、CIの失敗回数、未消化のアクションアイテム。いずれも gh と jq の組み合わせで数分の作業です。ここを人手の記憶に頼り続けると、アジャイル開発が失敗する原因で挙げられるような、形だけのイベント化に近づいていきます。
GitHub Actionsでふりかえり用のissueを毎スプリント自動生成する
コマンドを知っていても、毎回誰かが手で叩く運用は続きません。スプリントの区切りに合わせて自動実行し、事実が書き込まれたissueが勝手に立つ状態にします。
scheduleのcronはUTC基準なので日本時間との時差を必ず補正する
GitHub Actions のイベントリファレンスによれば、schedule のcronは分・時・日・月・曜日の5フィールドで、実行は既定でUTCです。日本時間の金曜10時に走らせたいなら、UTCでは同日の01:00を指定します。最短間隔は5分で、それより細かい指定はできません。手動でも起動できるよう workflow_dispatch を併記しておくと、スプリント日程がずれた週にも対応できます。
name: sprint-retro-prep
on:
schedule:
# UTC 01:00 金曜 = JST 10:00 金曜（cronは5フィールド・既定はUTC）
- cron: '0 1 * * 5'
workflow_dispatch:
permissions:
issues: write
pull-requests: read
jobs:
prepare:
runs-on: ubuntu-latest
steps:
- name: collect facts and open retro issue
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
GH_REPO: ${{ github.repository }}
run: |
SINCE=$(date -u -d '14 days ago' +%Y-%m-%d)
{
echo "## 事実：直近14日のマージ済みPR"
gh pr list --state merged --limit 100 \
--search "merged:>=$SINCE" --json number,title \
--jq '.[] | "- #\(.number) \(.title)"'
echo ""
echo "## 前回のアクションアイテムの状態"
gh issue list --label retro-action --state all --limit 20 \
--json number,title,state \
--jq '.[] | "- [\(.state)] #\(.number) \(.title)"'
} > retro.md
gh issue create \
--title "レトロスペクティブ $(date -u +%Y-%m-%d)" \
--label retrospective \
--body-file retro.md
この仕組みが入ると、会の準備という属人作業が消えます。参加者は開始前にissueを読み、事実を頭に入れた状態で集まれます。「今回は何を話すんでしたっけ」という最初の5分が丸ごと不要になる点も、2週間に1回の積み重ねでは小さくありません。
なお permissions の指定は必要な範囲に絞ってください。issueを作るだけなら issues: write と pull-requests: read で足ります。CI/CDの権限設計を含めた考え方はDevOpsの実践の文脈で整理しておくと、他のワークフローにも同じ基準を適用できます。
デプロイ頻度と変更のリードタイムをDORAの定義に沿って計測する
ふりかえりで改善を決めても、効いたかどうかを測らなければ次の判断ができません。個別のスプリントの感触ではなく、期間をまたいだ推移で見る必要があります。ここで使えるのが、広く参照されている配信パフォーマンスの指標群です。
四半期ごとの推移を並べるとふりかえりの成果が数字として見える
DORAのソフトウェアデリバリー指標は、スループット側として「変更のリードタイム（コミットから本番デプロイまでの時間）」「デプロイ頻度」「失敗したデプロイの回復時間」、安定性側として「変更失敗率」「デプロイリワーク率」を挙げています。全部を追う必要はなく、最初はリードタイムとデプロイ頻度の2つで十分に議論の土台になります。
| 指標 | 定義の骨子 | ふりかえりでの使い方 |
|---|---|---|
| 変更のリードタイム | コミットから本番までの時間 | 待ち時間の発生箇所を特定 |
| デプロイ頻度 | 一定期間のデプロイ回数 | バッチの大きさを点検 |
| 変更失敗率 | 即時対応を要した割合 | 品質側の副作用を確認 |
| 回復時間 | 失敗から復旧までの時間 | 運用体制の弱点を洗う |
注意したいのは、指標を個人やチームの評価に使わないことです。評価に紐づいた瞬間、数字を良く見せる行動（PRを細切れにする、デプロイを空打ちする）が始まり、データとしての意味が失われます。あくまでチームが自分たちのために見るものだ、という合意を先に取ってください。指標の推移は四半期単位で並べると変化が読み取りやすくなります。
決めたアクションを次スプリントで消化させるチケット運用を設計する
ふりかえりが形骸化する最大の原因は、決めたことが消えることです。ホワイトボードに書いた改善案は、会が終われば誰の視界にも入りません。ここを追跡可能な状態に変えるのが、実装側でできる一番の貢献です。
未消化のアクションアイテムを会の冒頭で点検する運用に切り替える
やり方は単純で、決めたアクションを専用ラベルつきのissueにし、担当者を1人に固定し、次のスプリント末を期限にします。そして次回の冒頭で、そのラベルの状態を読み上げるところから始めます。
# 未消化のアクションアイテムを担当者と作成日つきで洗い出す
gh issue list --label retro-action --state open --limit 50 \
--json number,title,assignees,createdAt \
--jq '.[] | "\(.createdAt[0:10]) #\(.number) \(.title) @\(.assignees[0].login // "未割当")"'
# 2スプリント以上放置されているものだけを抽出して棚卸しの対象にする
gh issue list --label retro-action --state open --limit 50 \
--json number,title,createdAt \
--jq --arg limit "$(date -u -d '28 days ago' +%Y-%m-%d)" \
'.[] | select(.createdAt[0:10] < $limit) | "- #\(.number) \(.title)"'
2スプリント放置されたアクションは、やる気の問題ではなく粒度の問題であることがほとんどです。「テストを増やす」のような曖昧な項目は着手点が無いため動きません。棚卸しの場で、具体的な作業へ割り直すか、いっそクローズするかを決めてください。数を絞る勇気も要ります。1回のふりかえりで持ち帰るアクションは2〜3件が上限だと考えると運用が保ちます。
チーム内に改善のサイクルを定着させる取り組み全般については、スクラムチームの作り方で文化面の要素を補えます。仕組みと文化は両輪で、どちらかだけでは続きません。
進め方の型を選ぶ｜KPT・タイムライン・Fun Done Learnの使い分け
材料と追跡が整った前提で、会の進め方をどの型で運営するかを決めます。型は目的によって向き不向きがあり、ずっと同じものを使い続ける必要はありません。
| 型 | 向く状況 | 注意点 |
|---|---|---|
| KPT | 定常的な改善サイクル | Tryが宙に浮きやすい |
| タイムライン | 出来事の多いスプリント | 作成に時間がかかる |
| Fun Done Learn | 士気が落ちている時期 | 課題が出にくい |
| Five Whys | 特定の障害を深掘り | 個人追及になりがち |
迷ったらKPTから始めるのが現実的です。3枠のみで学習コストが低く、新しいメンバーが入っても運用が崩れにくいという利点があります。枠の埋め方、Tryをチケットへ落とす手順、失敗パターンまではKPTとは（開発チームの振り返りをスプリントで機能させる進め方）で詳しく扱っているので、型の運用に踏み込む段階になったらそちらを参照してください。
型を変えるタイミングの目安は、同じ話題が3回続けて出るときです。同じ議題が繰り返されるのは、その型では掘れない層に原因があるサインだと捉えると判断しやすくなります。
受託開発でレトロスペクティブを採用する条件と見送るべき場面の判断
ここでの判断は明確です。受託開発の現場でレトロスペクティブが機能するのは、チームが継続して同じプロダクトに関わり、改善の結果を自分たちで受け取れる場合に限られます。この条件を満たさない案件で導入しても、会は続かず、やった記録だけが残ります。
採用すべき条件は3つです。第一に、2週間前後の区切りが実際に運用されていること。区切りが無いと検査の対象が定まりません。第二に、決めたアクションを自分たちの判断で実行できる裁量があること。すべてが発注側の承認待ちなら、出てくるのは要望リストであって改善計画ではありません。第三に、同じメンバーが次の区切りにも残ること。人が入れ替わり続けるなら、改善は引き継がれずに消えます。
スプリントを持たない受託案件でもふりかえりを機能させる工夫点
見送るべきなのは、数週間で完結する単発の請負、1〜2名の体制、そして工程が直列に進むウォーターフォール型の進め方で工程間の手戻りが構造的に許されない案件です。この場合は無理に定期イベントを作らず、工程の節目（設計完了時、結合テスト完了時）にポストモーテム寄りの短い会を置くほうが実態に合います。材料の自動収集だけは同じ仕組みが使えるので、コマンドとワークフローは流用してください。
長期で保守運用まで担う案件なら、ふりかえりは投資として回収できる取り組みです。リリース後の改善サイクルを社内に定着させるところまで含めた体制づくりは、保守運用・内製化支援で相談を受けています。仕組みを入れる段階で設計しておくと、担当者が変わっても回り続ける形にできます。
よくある質問
レトロスペクティブの時間はどれくらい取るべきですか？
スクラムガイドが定める時間は、1か月スプリントで最大3時間です。2週間スプリントならその半分を上限の目安とし、実際には60〜90分に収めるチームが多く見られます。事実の収集を自動化しておけば、短い枠でも議論に時間を割けます。
リモート環境でもレトロスペクティブは成立しますか？
成立します。むしろ材料をissueやオンラインボードに書き出す前提になるため、記録が残る点は有利です。全員が同時に書き込める場を用意し、発言の順番を決めておくと、特定の人だけが話す状態を避けられます。
参加者が意見を出さないときはどう対処すればよいですか？
いきなり口頭で聞かず、最初の5分を各自の書き出しに充ててください。書いたものを並べてから話すと、発言のハードルが下がります。それでも出ない場合は、データの異常値を起点に「この3日間の停滞は何でしたか」と具体的に尋ねるほうが早いです。
KPTとレトロスペクティブはどう違うのでしょうか？
レトロスペクティブは会そのもの、KPTはその会を進めるための型の一つという関係です。レトロという場をKPTという型で運営する、と整理すると混乱しません。型は状況に応じて差し替えられます。
マネージャーは参加させたほうがよいですか？
評価権限を持つ人が同席すると、チームが率直に問題を出しにくくなる傾向があります。原則はチームだけで行い、外部の判断や予算が必要なアクションが出た時点で別途持ち込む形が扱いやすい運用です。
