レトロスペクティブ(ふりかえり)の目的は?
スプリントレトロスペクティブの目的は、品質と効果を高める方法を計画することです。スクラムガイド(2020年版)では、スクラムチームが前のスプリントを検査するとされています。対象は、人・やり取り・プロセス・道具・完了の定義(DoD)です。
レトロスペクティブはスプリントの最後のイベントで、これでスプリントが終わります。時間の上限は、1か月のスプリントで3時間です。参加するのは、スクラムチーム(プロダクトオーナー・スクラムマスター・開発者)です。
スプリントレビューとはどう違う?
どちらもスプリントの終わりに行うので、混同しやすいイベントです。違いを並べます。
| 観点 | スプリントレビュー | レトロスペクティブ |
|---|---|---|
| 検査するもの | プロダクト(できあがったインクリメント) | 進め方(人・やり取り・プロセス・道具・完了の定義) |
| 参加者 | スクラムチームと主要な関係者 | スクラムチーム |
| 結果 | プロダクトバックログの見直し | 改善の行動(次のスプリントバックログに入れることもある) |
| 順番 | スプリントの最後から2番目 | スプリントの最後 |
| 上限(1か月のスプリント) | 4時間 | 3時間 |
レビューについては、スプリントレビューとは?で解説しています。
どう進める?(5つの段階と時間配分)
ふりかえりの進め方として知られているのが、次の5つの段階です。出典は、エスター・ダービーとダイアナ・ラーセンの著書『Agile Retrospectives』(2006年)です(当サイトが要約)。
- 1
場を整える
目的と時間を確認し、全員が話せる雰囲気を作る
- 2
事実を集める
スプリントで起きた出来事やデータを並べる
- 3
気づきを得る
なぜそうなったかを話し合い、原因を探る
- 4
やることを決める
次のスプリントで試す改善を1〜2個に絞る
- 5
締める
決めたことを確認し、ふりかえり自体も短く見直す
いきなり「改善案」から入らず、事実と原因を先に共有するのがコツです。
| 段階 | 時間 | やること |
|---|---|---|
| 場を整える | 5分 | 目的と時間を確認する。前回の改善がどうなったかも確かめる |
| 事実を集める | 15分 | 付箋やボードで、スプリントの出来事とデータを並べる |
| 気づきを得る | 15分 | なぜそうなったかを話し合い、原因を探る |
| やることを決める | 20分 | 改善を1〜2個に絞り、担当と確かめ方を決める |
| 締める | 5分 | 決めたことを読み上げ、ふりかえり自体も短く見直す |
リモートで行う場合は、オンラインのホワイトボードを使います。最初に各自が付箋を書く時間をとると、発言の偏りが減ります。
KPTなど代表的な手法は?
「事実を集める」「やることを決める」の段階で使う手法には、次のようなものがあります。ときどき手法を変えると、話が新鮮になります。
| 手法 | やり方 | 向いている場面 |
|---|---|---|
| KPT | Keep(続けること)・Problem(問題)・Try(次に試すこと)の3つに付箋を書いて貼る | 初めてのふりかえり。日本で広く使われ、説明が短くて済む |
| Start・Stop・Continue | 始めること・やめること・続けることを出す | 行動を変える案をはっきり出したいとき |
| タイムライン | スプリントの出来事を時系列に並べ、気分の上下も書く | 長いスプリントや、大きな出来事があったとき |
| 帆船(ヨット) | 追い風(助け)・いかり(足かせ)・岩(危険)・島(目標)を絵で表す | ゴールに対する障害とリスクを話したいとき |
| 4つのL | 良かった・学んだ・足りなかった・欲しかったの4つで出す | 学びを残したいとき |
KPTの注意点は、Problem の欄が「人の悪口」になりやすいことです。「〇〇さんのレビューが遅い」ではなく、「レビュー待ちで作業が2日止まった」のように、出来事として書きます。
心理的安全性とファシリテーションはなぜ大事?
ふりかえりで本当の問題が出るかどうかは、「言っても責められない」とメンバーが感じているかで決まります。この状態を心理的安全性と呼びます。問題を言うと責められるチームでは、表面的な意見しか出ず、改善が進みません。
進行役(多くはスクラムマスター)が気をつけることは、次のとおりです。
- 人ではなく仕組みを見る: 「誰のせいか」ではなく、「何が起きやすくしていたか」を問います。
- 全員が話せるようにする: 声の大きい人だけが話さないよう、付箋に書いてから出す、順番に話すなどの工夫をします。
- 上下関係を持ち込まない: 上司が同席すると本音が出にくい場合、チームで参加者を話し合います。
- 秘密を守る: ふりかえりで出た話を、チームの外で評価に使わないと約束します。
- 改善を絞る: 一度にたくさん決めず、効果の大きいものを1〜2個に絞ります。
よくある失敗と対策は?
| よくある失敗 | 対策 |
|---|---|
| 決めた改善が実行されない | 改善を1〜2個に絞り、担当と確かめ方を決めて、スプリントバックログに入れる |
| 毎回同じ話になる | 手法を変える。進行役を交代する |
| 印象だけで話が進む | 待ち時間や不具合の数など、事実のデータを持ち込む |
| 時間切れで何も決まらない | 時間配分を決め、「やることを決める」時間を先に確保する |
| 責め合いになる | 人ではなく出来事と仕組みを見るよう、進行役が問いを変える |
特に多いのが、最初の「決めたのに実行されない」です。次の節で、実行されるようにする工夫を見ていきます。
改善をどう次のスプリントに入れる?
スクラムガイドでは、最も効果の大きい改善には、できるだけ早く取り組むとされています。次のスプリントのスプリントバックログに加えることもできます。
実行されるようにするための工夫は、次のとおりです。
- 改善を「〇〇する」という具体的な行動の形で書く(例:「レビュー依頼は当日中に返す」)
- 担当者と、確かめる方法を決める(例:「レビュー待ちの日数をボードに書く」)
- 次のスプリントバックログに、改善のアイテムとして入れる
- 次のふりかえりの最初に、前回の改善がどうなったかを確かめる
改善のアイテムをどう並べるか、プロダクトバックログとの関係はプロダクトバックログとは?で扱います。
教訓(レッスンズラーンド)とはどう関係する?
予測型のプロジェクトでは、教訓(レッスンズラーンド)をフェーズやプロジェクトの終わりにまとめることが多いです。アジャイルのふりかえりは、それをスプリントごとにこまめに行い、すぐ次に生かす仕組みと言えます。
新ECO(2026年版)の Business Environment のタスク6は「継続的改善」です。教訓の活用、継続的改善のプロセスの更新、組織のプロセス資産(OPA)の更新が含まれます。Process のタスク10(終結)にも、最後の教訓やふりかえりをまとめる活動が例として挙がっています。
残し方は、役に立つ範囲で分けるとよいでしょう。チームの中だけで役立つ改善はスプリントバックログへ。他のチームにも役立つ学びは、組織の教訓の記録やテンプレートへ残します。組織のプロセス資産についてはOPAとEEFの違いで詳しく扱います。
確認問題1
ふりかえりが責め合いになる
(当サイトの独自問題)前のスプリントで、リリースに障害が出ました。ふりかえりでは、開発者どうしが「テストを担当した人の確認不足だ」と言い合い、名指しされた開発者は黙り込んでしまいました。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解:2。ふりかえりは責める場ではなく、仕組みの問題を見つける場です。進行役として出来事の流れを事実として並べ、何が起きやすくしていたかを探るよう促します。
1:個人の責任追及は心理的安全性を壊し、次から問題が出なくなります。3:一緒に学ぶ機会を失い、責め合いの空気も残ります。4:原因の分析もしないまま人を替えるのは、仕組みの問題を見逃す対応です。
確認問題2
決めた改善が実行されない
(当サイトの独自問題)スクラムチームは毎回のふりかえりで、改善を5〜6個決めています。しかし次のスプリントではほとんど実行されず、同じ問題が繰り返し出ています。開発者からは「ふりかえりは意味がない」という声も出始めました。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解:3。改善は効果の大きいものに絞り、スプリントバックログに入れて作業として扱います。結果は次のふりかえりで確かめます。
1:改善の周期が遅くなり、問題が長引きます。2:チームの自己管理を弱め、監視されている雰囲気を生むだけです。4:チームの改善を承認待ちにすると、かえって実行が遅れます。
確認問題3
他チームにも役立つ学び
(当サイトの独自問題)あるスクラムチームが、ふりかえりで気づきを得ました。「外部APIのテスト用データを早めに業者へ依頼すると、待ち時間が大きく減る」というものです。実行して効果も確かめました。同じ業者を使うチームが、社内にほかに3つあります。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解:1。他のチームにも役立つ学びは、組織のプロセス資産(教訓の記録)として共有します。継続的改善と知識の移転の両方につながります。
2:組織全体で改善する機会を逃します。3:やり方を採用するかどうかは、各チームが判断することです。4:終結まで待つと、他のチームが今すぐ得られる効果を失います。
継続的改善の場面の問題は、無料模試30問にも含まれています。