アジャイル開発におけるレトロスペクティブって何？効果的な振り返りの方法
レトロスペクティブ（Retrospective）とは、アジャイル開発・スクラムにおいてスプリント終了時に実施する「振り返り」のミーティングです。チームの仕事の進め方を見直して品質と効果を高める改善策を決め、次のスプリントに反映することを目的とします。
| 項目 | 内容 |
|---|---|
| 定義 | スプリント終了時に行う「振り返り」のミーティング。スクラムに定義された正式なイベントの 1 つ |
| 目的 | 品質と効果を高める方法を計画すること（スクラムガイドによる定義） |
| 実施タイミング | スプリントの最後。スプリントレビューの後、次のスプリントプランニングの前 |
| 参加者 | プロダクトオーナー、スクラムマスター、開発者などスクラムチームの全員 |
| 所要時間 | 1 ヶ月スプリントで最大 3 時間程度。スプリントが短ければ短縮する（2 週間なら 1 時間 30 分程度） |
| 代表的なフレームワーク | KPT（KPTA）、FDL、TimeLine、3 匹の子ぶた |
継続的な改善を目指すアジャイル開発では、なぜレトロスペクティブを行うのでしょうか。また、レトロスペクティブはどのように進めれば効果的なのでしょうか。
この記事では、アジャイル開発を得意とする当社が、レトロスペクティブの概要や進め方、代表的なフレームワークの比較、注意点についてご紹介します。
レトロスペクティブとは
レトロスペクティブとはどのような取り組みであり、なぜ重要なのでしょうか。まず初めに、その意味や目的についてご紹介します。
スプリントにおける「振り返り」であるレトロスペクティブ
レトロスペクティブとは「過去にさかのぼる」「過去を懐かしむ」という意味の英単語ですが、とくにアジャイルの文脈においてはスプリント終了時に実施される「振り返り」のためのミーティングのことを指します。
通常、スクラム開発においては数週間～ 1 ヶ月程度のスプリントを繰り返すことで開発を進めていきますが、スプリント完了時に今回のスプリントを振り返るためにレトロスペクティブを行います。レトロスペクティブを通して課題の洗い出しや改良案の提案を行うことで、次回以降のスプリントをより良いものにします。
スプリント期間中は開発作業に時間を取られ、改善の取り組みまで手がつかないケースも多いといえます。
レトロスペクティブの時間をとることで、チームメンバーから有益な意見を引き出して改善を進めることで、スクラム開発の理念でありメリットでもある「継続的な改善」を実現することができます。
レトロスペクティブの目的と必要性
スクラム開発の実践におけるバイブルである『スクラムガイド』によれば、レトロスペクティブの目的は「品質と効果を⾼める⽅法を計画すること」とされています。
レトロスペクティブで整理された改善策を計画し、今後のスプリントに反映させていくことを繰り返すことで、チームを発展的に高めていくことができます。
レトロスペクティブを通して、チームの非効率な作業やコミュニケーション不足、タスクの整理などを行うことで、開発効率の向上、ひいては開発するプロダクトの品質向上につながります。
※参考：Ken Schwaber & Jeff Sutherland「スクラムガイド」（新しいタブで開きます）
スプリントレビューとの違い・スクラムイベントにおける位置づけ
レトロスペクティブは、スプリントプランニング・デイリースクラム・スプリントレビューと並ぶ、スクラムに定義された正式なイベントの 1 つです。各イベントの役割や全体の流れについては、スクラムイベントの解説記事で詳しくご紹介しています。
混同されやすいイベントにスプリントレビューがありますが、両者は検査する対象が異なります。スプリントレビューがスプリントの成果物（プロダクト）をステークホルダーとともに検査する場であるのに対し、レトロスペクティブはチームの仕事の進め方（プロセス）を検査する場です。レトロスペクティブはスプリントレビューの後、スプリントの最後に実施され、そこで決めた改善策が次のスプリントへとつながります。
効果的なレトロスペクティブの進め方とヒント
以下では、効果的なレトロスペクティブの進め方と、レトロスペクティブを実施するうえでのポイントをご紹介します。
事前準備
レトロスペクティブを実施する前に、ルールや進め方を整理します。
実施時間（タイムボックス）
まず、実施時間（タイムボックス）を検討します。スクラムガイドによれば、スプリント期間が 1 ヶ月の場合、スプリントレトロスペクティブは最⼤ 3 時間程度とすることが推奨されています。
スプリントの期間が短ければ、スプリントレトロスペクティブの時間も短くします。たとえば 2 週間スプリントの場合は 1 時間 30 分とするなど、調整を行います。
参加者
基本的に、スクラムチームを構成するプロダクトオーナー、スクラムマスター、開発者の全員が参加します。お互いに意見を出せるように、全員が発言権を持つようにします。
手法の検討
詳細は後述しますが、レトロスペクティブを効果的に進めるために、KPT や FDL などのいくつかの手法（フレームワーク）が利用できます。
今回のレトロスペクティブはどのような手法により実施するか、事前に検討します。
実施時
レトロスペクティブにおいては、スプリント中に何がうまくいったか、どのような問題が発⽣したか、それらをどのように解決したか、または解決できていないかを話し合います。この際のポイントは、洗い出した意見を集約しつつ、次のスプリントで実施するアクションとして整理することです。
チームとして、スプリントを改善するために有効と思われる変更を整理したうえで、効果が高いと思われるものから優先的に実施します。内容にもよりますが、改善策は次のスプリントにおけるスプリントバックログに追加することで具体化できます。
60 分で実施する場合のアジェンダ例（テンプレート）
初めてレトロスペクティブを実施する場合は、時間配分をあらかじめ決めておくと進めやすくなります。以下は、書籍『アジャイルレトロスペクティブズ』（Esther Derby、Diana Larsen 著）で提唱されている 5 段階の構成をもとにした、60 分で実施する場合のアジェンダ例です。
| 時間配分 | ステップ | 主な内容 |
|---|---|---|
| 5 分 | チェックイン（場づくり） | 全員が一言ずつ発言し、話しやすい雰囲気をつくる。今回のテーマと使用するフレームワークを共有する |
| 15 分 | データ収集 | スプリント中の出来事や事実を付箋などで洗い出す（KPT であれば Keep・Problem の書き出し） |
| 15 分 | 分析 | 洗い出した内容をグルーピングし、課題の背景や原因をチームで掘り下げる |
| 15 分 | アクションの決定 | 効果が高い改善策を 1 ～ 3 個に絞り、担当者と次のスプリントでの進め方を決める（KPT であれば Try・Action の整理） |
| 10 分 | クローズ | 決定したアクションを全員で確認し、レトロスペクティブ自体の進め方についても簡単に振り返る |
ポイントは、洗い出した意見をすべて扱おうとせず、アクションを絞り込むことです。議論が時間内に収まらない場合も、タイムボックスを優先して「次回に持ち越す」判断をした方が、レトロスペクティブを継続しやすくなります。
レトロスペクティブの代表的なフレームワーク
レトロスペクティブの実施においては、いくつかのフレームワークが利用できます。まずは代表的な 4 つのフレームワークの特徴と、それぞれが向いているチーム・状況を一覧で整理します。
| フレームワーク | 特徴 | 向いているチーム・状況 |
|---|---|---|
| KPT（KPTA） | Keep（継続）・Problem（課題）・Try（挑戦）の 3 視点で整理する定番の手法。Action を加えて KPTA とすることもある | 初めてレトロスペクティブを導入するチーム。課題と改善策を体系的に整理したい場合 |
| FDL | Fun（楽しかったこと）・Done（やったこと）・Learn（学んだこと）のポジティブな 3 観点で振り返る | モチベーションを高めたいチーム。批判的な雰囲気になりやすい場合の切り替えに有効 |
| TimeLine | 時系列と感情の上下をグラフにプロットして現状を分析する | スプリント中の出来事が多かった場合。感情面も含めて丁寧に振り返りたい場合 |
| 3 匹の子ぶた | わらの家・木の家・レンガの家の 3 段階で取り組みの成熟度を可視化する | 振り返りにマンネリを感じているチーム。改善の進捗を継続的に可視化したい場合 |
以下では、それぞれのフレームワークの進め方を詳しくご紹介します。
KPT（KPTA）
レトロスペクティブにおいて比較的良く利用されるフレームワークとして、KPT が挙げられます。KPT は「Keep（継続）」「Problem（課題）」「Try（今後の挑戦）」の 3 つの視点で現状を分析する手法です。これらに「Action（取り組み）」を加えて KPTA として整理することもあります。
レトロスペクティブのミーティングにおいて KPT を利用する場合、まず良かった点と悪かった点を全員で上げていき、Keep と Problem として整理します。この際、ホワイトボードや付箋などを利用して全員が参加しやすいように環境を整えるとよいでしょう。また、この時良かった点を先に洗い出すようにすることで、発言しやすいような空気感をつくることも進め方のコツです。
次に、Keep と Problem に対して、それらを維持するため、もしくは改善するために挑戦することを Try としてまとめます。Action まで整理する場合は、Try に対して具体的な行動を記載していきます。この際、Try のうち重要度や効果を踏まえて優先的に取り組むべき点を Action としてまとめることがポイントです。
KPT はレトロスペクティブだけでなく、人事考査における面談やプロジェクト完了時の振り返りなど、さまざまな場面で利用できるフレームワークです。
FDL
KPT と類似する手法として FDL が挙げられます。FDL は「Fun（楽しかったこと）」「Done（やったこと）」「Learn（学んだこと）」という 3 つの観点で振り返りを行うフレームワークです。シンプルな手法であり、ネガティブな要素がないためにモチベーションを高めやすい整理方法といえます。
場合により、F・D・L の各観点は重複します。たとえば、実際にやってみて楽しかったことは Done と Fun の両方に位置します。さらに学びがあった場合には、FDL すべての領域に位置することになります。やったことが楽しく、また学びがあるのであれば、それは継続すべき要素といえます。この領域に含まれる要素を増やしていくことを目指します。
TimeLine
TimeLine では、X 軸に時系列を、Y 軸に感情の上下をプロットすることで、現状を分析する方法です。まず初めに、スプリント中に実施したことや発生したこと、思ったことなどを付箋に書き出します。次に、ホワイトボードに作成した時系列と感情のグラフに、これらを張り出します。
次に、それぞれの出来事や思ったことに対して、関連性を見つけたり改善案を検討したりします。グラフ上に感情面の情報が含まれているため、たとえば良い感情を生み出したできごとは継続できるようにアクションを検討したり、悪い感情を生み出した出来事は改善策を検討したりといった取り組みがしやすくなります。
3匹の子ぶた
最後に、少し変わったフレームワークとして『3 匹の子ぶた』を紹介します。童話として知られている 3 匹の子ぶたをモチーフにした振り返り手法であり、少し視点を変えたレトロスペクティブを実施したい場合などに有効です。
3 匹の子ぶたの童話と同じく、このフレームワークでは「わらの家」「木の家」「レンガの家」という3つの観点に分けて現状を整理します。わらの家には課題やうまくいっていないことを、木の家には部分的にうまくいっているものの改善の余地があることを、レンガの家にはうまくいっていることを整理します。3 つの観点に現状を整理できたら、それぞれの観点ごとにチームで議論を行い、改善策や課題の解決方法を検討します。
継続的に 3 匹の子ぶたフレームワークでレトロスペクティブを行うことで、最初はわらの家に置かれていた内容も、だんだんと木の家、レンガの家へと移動していく様子が可視化できます。これにより、チームの成長や改善状況を把握しやすくなります。
レトロスペクティブのよくある失敗と注意点
以下では、レトロスペクティブにおけるよくある失敗や注意点をご紹介します。
意見がでない・発言者が偏る
よくあるのが、レトロスペクティブにおいて意見がでなかったり、いつも同じ人が発言してしまったりというケースです。とくに、チームの課題や改善点などは発言しにくいと感じる方も多いといえます。
誰でも発言しやすい環境をつくるためには、第一にチームの雰囲気を良い状態に保つ点が重要となります。
開発がうまくいっているケースは良いものの、そうでない場合はともすれば犯人探しやダメだしの場ともなりかねません。スクラムマスターなどが中心となり、心理的な障壁を減らすためのファシリテーションを行うことがポイントです。
チームの範囲外への問題への対応
システムの開発において、課題の発生源はスクラムチーム内だけとは限りません。ステークホルダーや組織など、さまざまな外的要因が存在します。
たとえば、ステークホルダーが急に無理な仕様変更を依頼し、プロジェクトを成功させるためには対応せざるを得なくなってしまったり、プロダクトオーナーが別の案件の兼務を指示され、開発に割けるリソースが減ってしまったりといったケースもあります。
このような問題は、スクラムチーム内で対処することが難しいことも多いといえます。一方で、注意しなければならないのが、レトロスペクティブの場を「愚痴の言い合い」にしないことです。外的要因を改善できる可能性があるのであればその可能性を検討する、もしくは改善できないのであれば、それを前提として最善策を検討するといったように、前向きな視点が重要です。
悪い状況の時こそレトロスペクティブが必要
スケジュールが厳しいプロジェクトやリソースが限られているプロジェクトなど、難しい状況にある場合に、レトロスペクティブは軽視されがちです。このような場合、スクラム開発のプロセスに存在するからと事務的に実施されたり、場合によっては省略されてしまったりということも往々にしてあります。
一方で、このような状況の時こそレトロスペクティブが必要といえます。時間がない状態で作業以外のことをやるのはモチベーションが湧かないこともありますが、レトロスペクティブに時間を使い改善を進めることで、長期的に見ればチームに余裕を生むことにつながります。
スパイスファクトリーの現場での実践例
最後に、こうした失敗を避けるためにスパイスファクトリーの現場で行っている、一般的なプラクティスをご紹介します。
まずは KPT から始め、形骸化を感じたらフォーマットを変えるのが当社の基本的な進め方です。KPT は導入しやすい一方、長く続けると意見が定型化しがちです。「最近同じような Keep と Problem ばかり出ている」と感じたタイミングで、FDL や TimeLine に切り替えることで、チームから新しい視点の意見を引き出しています。
Problem の洗い出しでは「人ではなく仕組みに注目する」ことをルールとして明示しています。課題を特定の個人の責任として扱うと、犯人探しの雰囲気が生まれ、次回以降に意見が出なくなってしまいます。「なぜその状況が起きたのか」をプロセスや仕組みの問題として掘り下げることで、心理的安全性を保ちながら本質的な改善につなげています。
また、決定したアクションは必ず次のスプリントのスプリントバックログに載せて追跡し、次回のレトロスペクティブの冒頭で実施状況を確認するようにしています。「決めたが実行されない」状態が続くと、レトロスペクティブ自体への信頼が失われるためです。アクションを 1 ～ 3 個に絞り、確実に実行しきることを優先しています。
このほか、ファシリテーターをスクラムマスターに固定せず持ち回りにすることで、メンバーの参加意識を高める工夫も行っています。
レトロスペクティブを含むスクラムイベントの設計や定着に課題を感じている場合は、当社のスクラム開発支援サービスもご活用いただけます。
レトロスペクティブで効果的な改善を
この記事では、アジャイル開発において実施されるレトロスペクティブについて、その概要や主なフレームワークなどについて紹介しました。
レトロスペクティブを含めたスクラム開発の取り組みをうまく進めるためには、アジャイル開発やスクラム開発の経験や知識が必要です。
スパイスファクトリーでは、アジャイル開発・スクラム開発によりこれまで多数のお客さまのシステム開発を支援してまいりました。
アジャイル開発でプロダクトやサービスの開発を検討されている方は、ぜひお声がけください。
