---
name: retrospective
description: メモ、付箋、アンケートからチームの振り返り（レトロスペクティブ）をまとめる。うまくいったこと、いかなかったこと、繰り返し起きているパターン、短いなぜなぜ分析による根本原因、担当者と日付つきの改善の試み1〜3件を、Start/Stop/Continue、4Ls、うまくいった・いかなかったの形式で書く。チームから振り返りの進行やまとめ、スプリントレトロ、プロジェクト後の振り返り、教訓の整理、「次は何を変えるか」を頼まれたときに使う。
---

# チームの振り返り

振り返りに1時間かける意味があるのは、次のスプリントやプロジェクトの進め方が変わるときだけだ。スクラムガイドはその目的を「品質と効果を高める方法を計画すること」と書いている。だから成果物は感想の一覧ではない。チームが試す変化を1〜3件、それぞれ担当者と日付つきで決める。その前に、前回の振り返りで決めたことを確認する。

## 使う場面

- スプリント、プロジェクト、リリース、四半期の終わりに。
- アンケートの回答、付箋、Slack のスレッドなど手元の材料を、テーマとアクションにまとめたいとき。
- 振り返りの場を進行する前に、進行役の段取りを用意するとき。
- 顧客に影響が出た単発の障害には使わない。時系列つきの障害レビューを書く。

## 用意するもの

- 元の材料: メモ、アンケートの回答、ボードのエクスポート。なければ、進行の段取りと空のテンプレートを作る。
- 対象の期間かプロジェクトと、参加者。
- 前回の振り返りのアクション（あれば）。なければ「前回のアクションの記録なし」と書く。
- 形式の希望。なければ、うまくいった / いかなかった / 次に試す を使う（このスキルの既定値。いちばん素直な形式）。

## 手順

1. **まず前回のアクションを確認する。** ひとつずつ、完了・未完了・取りやめのどれかと、何があったかを一行で書く。半分を超えて未完了なら、今回の最初の試みは「アクションを減らし、小さくする」にする。
2. **形式を選ぶ。** たいていのチームは、うまくいった / いかなかった / 次に試す。行動を変える必要があるなら Start / Stop / Continue。はじめてのリリースのように学びの多かった期間なら 4Ls（Loved 良かった、Loathed 嫌だった、Learned 学んだ、Longed for 欲しかった）。ひとつの振り返りで形式を混ぜない。
3. **材料をテーマにまとめる。** 重複をまとめ、各テーマを何人が挙げたかを数える。一度きりの出来事ではなく、繰り返し起きているパターンを探す。上位のテーマには参加者の言葉をかぎかっこで残す。材料に名前が書かれていない限り、名前は伏せる。
4. **上位2つの問題の根本原因を探す。** チームで変えられることにたどり着くまで「なぜ？」を繰り返す。この手法をトヨタの大野耐一にさかのぼって紹介している Lean Enterprise Institute は、5という回数に意味はないとしている。チームの手が届かない原因にたどり着いたらそこで止め、そう書く。人で止めない（「佐々木さんが忘れた」）。なぜ忘れてもそのまま進む仕組みだったのかを問う。
5. **試みを1〜3件選ぶ。** それぞれ次の期間に試す具体的な変化で、試せるくらい小さく、担当者（ひとり）、見直す日、うまくいったと判断する基準を決める。チームが8件のアクションを出したら、効果がいちばん大きそうな3件を残し、ほかは保留にする。
6. **その場で進行するなら段取りを組む。** 60分なら、Atlassian の Team Playbook の配分で、場づくり（5分）、材料集め（15分）、パターン探し（20分）、アクション決め（15分）、締め（5分）。目的は改善で、犯人探しではないことを最初に伝える。

## 出力の形式

```markdown
# 振り返り — [チーム / プロジェクト]、[期間]

**形式:** [うまくいった / いかなかった / 次に試す | Start/Stop/Continue | 4Ls]
**参加者:** [名前か人数]

## 前回のアクション
| アクション | 担当者 | 状況 | 何があったか |
|---|---|---|---|
| [アクション] | [名前] | 完了 / 未完了 / 取りやめ | [一行] |

## うまくいったこと
- [テーマ] — [n]人 — 「[代表的な声]」

## うまくいかなかったこと
- [テーマ] — [n]人 — 「[代表的な声]」

## 根本原因
**[問題1]**
- なぜ？ [答え] → なぜ？ [答え] → なぜ？ [答え] → 根本原因: [チームで変えられること]

## 次の[スプリント / プロジェクト]で試すこと
| 試み | 担当者 | 見直す日 | うまくいったと判断する基準 |
|---|---|---|---|
| [具体的な変化] | [名前] | [日付] | [目に見える兆候] |

## 保留
- [今回は選ばなかった案]
```

## 例

**入力:** 「プラットフォームチーム、スプリント14の振り返り、6人（PM: 森）、アンケートの回答:『デモがすごくよかった』（3）、『インポーターのペアプログラミングが助かった』（2）、『直前の仕様変更が多すぎる』（4）、『QA にビルドが届いたのが木曜で、テストする時間がない』（3）、『朝会が25分かかる』。前回のアクション:『青木さんがステージング環境を用意する』— 完了、3日目から稼働。話し合いで出たこと: ストーリーが仕上がったのは最後の2日、直前の仕様変更で2つのストーリーがやり直しになった、計画のあとの依頼は開発者に直接届いている」

**出力:**

```markdown
# 振り返り — プラットフォームチーム、スプリント14

**形式:** うまくいった / いかなかった / 次に試す
**参加者:** 6人

## 前回のアクション
| アクション | 担当者 | 状況 | 何があったか |
|---|---|---|---|
| ステージング環境を用意する | 青木 | 完了 | 3日目から稼働 |

## うまくいったこと
- スプリントのデモ — 3人 — 「デモがすごくよかった」
- インポーターのペアプログラミング — 2人

## うまくいかなかったこと
- 直前の仕様変更 — 4人 — 「直前の仕様変更が多すぎる」
- 終盤に QA が詰まる — 3人 — 「QA にビルドが届いたのが木曜で、テストする時間がない」
- 朝会が長い — 1人

## 根本原因
**終盤に QA が詰まる**
- なぜ？ ビルドが QA に届いたのが木曜だった → なぜ？ ストーリーが最後の2日で仕上がった → なぜ？ 直前の仕様変更で2つのストーリーがやり直しになった → なぜ？ 計画のあとの依頼が開発者に直接届く → 根本原因: スプリント計画のあとの変更に決まりがない。

## 次のスプリントで試すこと
| 試み | 担当者 | 見直す日 | うまくいったと判断する基準 |
|---|---|---|---|
| 計画のあとの変更は PM を通し、PM が代わりに何かを外す | 森（PM） | スプリント15の振り返り | スプリント中にやり直しになったストーリーが0件 |
| スプリント終了の2日以上前に QA にビルドを渡す | 青木 | スプリント15の振り返り | QA からテストに2日以上取れたと報告がある |

## 保留
- 朝会を短くする（挙げたのは1人。また出たら取り上げる）
```

## 送る前のチェック

- [ ] 新しいアクションを書く前に、前回のアクションの状況が書いてある。
- [ ] 試みは3件以内で、それぞれに担当者ひとりの名前、見直す日、成功の基準がある。
- [ ] 根本原因をたどった先が、人の名前ではなくチームで変えられることになっている。
- [ ] テーマの人数が材料と合っていて、言われていない言葉を引用していない。
- [ ] 材料に名前が書かれていない限り、個々の意見は匿名になっている。

## よくある失敗

- 「コミュニケーションを良くする」で終わる。誰が、何を、いつから変えるのかを書く。
- アクションを10件書く。チームがやり切れるのは1〜3件で、残りは振り返りへの信頼を削る。
- うまくいったことを飛ばす。何かを変えるとき、何を守るべきかをチームに教えてくれる。