スプリントレトロスペクティブ（振り返り）は、Scrum チームが各スプリントの終わりに開く振り返りミーティングです。作業の進め方そのものを検査します——何がうまくいったか、どこに問題があったか、次のスプリントで何をひとつ改善するか。 レトロスペクティブが見るのは「私たちの働き方」であり、スプリントレビューが見るのは「私たちが作ったもの」です。
30 秒版
- 頻度：各スプリント終了時に 1 回。スプリントレビューの直後；
- 所要時間：2 週間スプリント → 60〜90 分。1 週間スプリント → 45 分；
- 成果物：担当者名と検証可能な完了基準を備えた改善アクション 1〜2 件（「次は気をつけよう」の山ではない）；
- 健全サイン：連続 3 回の振り返りのアクションがすべて着地していれば、プロセスは本当に改善しています。
標準アジェンダ（60 分版）
| 時間 | 区分 | 目的 |
|---|---|---|
| 0:00–0:05 | 冒頭とアイスブレイク | トーンを設定：心理的安全性、人ではなく事象について |
| 0:05–0:15 | データ収集 | 全員がスプリントの事実と感覚を書き出す（下の活動フレームを使う） |
| 0:15–0:30 | インサイト生成 | 分類・投票し、最重要の 1〜3 テーマを浮かび上がらせる |
| 0:30–0:50 | アクション決定 | テーマを具体的なアクションに変換：誰が何をし、何をもって完了とするか |
| 0:50–0:60 | 締め | 前回アクションの達成状況を確認し、今回のアクションをボードへ |
24 の振り返りアクティビティ/ゲーム
A. 定番フレーム（日常のローテーションに十分）
B. 品質に絞ったアクティビティ
C. 場を温めるアイスブレイク（いわゆる「レトロゲーム」枠）
D. 根因を掘るアクティビティ
E. リモートチーム向け
F. 新鮮さを保つ変化球
忘れられないアクションの書き方
| 悪い例 | 良い例 |
|---|---|
| 「テストを強化する」 | 「リリース前に checklist を毎回実施。当週のオンコール QA が実行し、次 2 回の振り返りで実施率を確認」 |
| 「無駄なやり取りを減らす」 | 「バグレポートは台帳に一本化。チャットでは問題を説明せずリンクだけ貼る。来週水曜に抜き打ち確認」 |
| 「コード品質を上げる」 | 「pre-commit の lint フックを導入。バックエンド担当が今週金曜までに設定」 |
振り返りはデータで支える。印象ではなく
「このスプリントは品質が悪い」——こうした印象論は反論を招くだけです。定量データに語らせましょう：- このスプリントの欠陥総数と、モジュール別・深刻度別の分布；
- 欠陥ごとの平均修正時間と、往復質問の回数；
- 欠陥の発生源分布（社内テスト / ベータユーザーの報告 / 本番ユーザーの報告）。