アジャイル開発におけるレトロスペクティブって何？効果的な振り返りの方法

スパイスファクトリーのを見る。
継続的な改善を目指すアジャイル開発においては、スプリントの完了時に今後の改善につなげるために「レトロスペクティブ」として振り返りを行います。

なぜアジャイル開発においてはレトロスペクティブを行うのでしょうか。また、レトロスペクティブはどのように進める必要があるのでしょうか。

この記事では、アジャイル開発を得意とする当社が、レトロスペクティブの概要やポイント、注意点についてご紹介します。

レトロスペクティブとは

レトロスペクティブとはどのような取り組みであり、なぜ重要なのでしょうか。まず初めに、その概要についてご紹介します。

スプリントにおける「振り返り」であるレトロスペクティブ

レトロスペクティブとは「過去にさかのぼる」「過去を懐かしむ」という意味の英単語ですが、とくにアジャイルの文脈においてはスプリント終了時に実施される「振り返り」のためのミーティングのことを指します。

通常、スクラム開発においては数週間～ 1 ヶ月程度のスプリントを繰り返すことで開発を進めていきますが、スプリント完了時に今回のスプリントを振り返るためにレトロスペクティブを行います。レトロスペクティブを通して課題の洗い出しや改良案の提案を行うことで、次回以降のスプリントをより良いものにします。

スプリント期間中は開発作業に時間を取られ、改善の取り組みまで手がつかないケースも多いといえます。

レトロスペクティブの時間をとることで、チームメンバーから有益な意見を引き出して改善を進めることで、スクラム開発の理念でありメリットでもある「継続的な改善」を実現することができます。

レトロスペクティブの目的と必要性

スクラム開発の実践におけるバイブルである『スクラムガイド』によれば、レトロスペクティブの目的は「品質と効果を⾼める⽅法を計画すること」とされています。

レトロスペクティブで整理された改善策を計画し、今後のスプリントに反映させていくことを繰り返すことで、チームを発展的に高めていくことができます。

レトロスペクティブを通して、チームの非効率な作業やコミュニケーション不足、タスクの整理などを行うことで、開発効率の向上、ひいては開発するプロダクトの品質向上につながります。

※参考：Ken Schwaber & Jeff Sutherland「スクラムガイド」

効果的なレトロスペクティブの進め方とヒント

以下では、効果的なレトロスペクティブの進め方と、レトロスペクティブを実施するうえでのポイントをご紹介します。

事前準備

レトロスペクティブを実施する前に、ルールや進め方を整理します。

実施時間（タイムボックス）

まず、実施時間（タイムボックス）を検討します。スクラムガイドによれば、スプリント期間が 1 ヶ月の場合、スプリントレトロスペクティブは最⼤ 3 時間程度とすることが推奨されています。

スプリントの期間が短ければ、スプリントレトロスペクティブの時間も短くします。たとえば 2 週間スプリントの場合は 1 時間 30 分とするなど、調整を行います。

参加者

基本的に、スクラムチームを構成するプロダクトオーナー、スクラムマスター、開発者の全員が参加します。お互いに意見を出せるように、全員が発言権を持つようにします。

手法の検討

詳細は後述しますが、レトロスペクティブを効果的に進めるために、KPT や FDL などのいくつかの手法（フレームワーク）が利用できます。

今回のレトロスペクティブはどのような手法により実施するか、事前に検討します。

実施時

レトロスペクティブにおいては、スプリント中に何がうまくいったか、どのような問題が発⽣したか、それらをどのように解決したか、または解決できていないかを話し合います。この際のポイントは、洗い出した意見を集約しつつ、次のスプリントで実施するアクションとして整理することです。

チームとして、スプリントを改善するために有効と思われる変更を整理したうえで、効果が高いと思われるものから優先的に実施します。内容にもよりますが、改善策は次のスプリントにおけるスプリントバックログに追加することで具体化できます。

レトロスペクティブの代表的なフレームワーク

レトロスペクティブの実施においては、いくつかのフレームワークが利用できます。以下では、代表的な 4 つのフレームワークをご紹介します。

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 匹の子ぶたフレームワークでレトロスペクティブを行うことで、最初はわらの家に置かれていた内容も、だんだんと木の家、レンガの家へと移動していく様子が可視化できます。これにより、チームの成長や改善状況を把握しやすくなります。

レトロスペクティブのよくある失敗と注意点

以下では、レトロスペクティブにおけるよくある失敗や注意点をご紹介します。

意見がでない・発言者が偏る

よくあるのが、レトロスペクティブにおいて意見がでなかったり、いつも同じ人が発言してしまったりというケースです。とくに、チームの課題や改善点などは発言しにくいと感じる方も多いといえます。
誰でも発言しやすい環境をつくるためには、第一にチームの雰囲気を良い状態に保つ点が重要となります。

開発がうまくいっているケースは良いものの、そうでない場合はともすれば犯人探しやダメだしの場ともなりかねません。スクラムマスターなどが中心となり、心理的な障壁を減らすためのファシリテーションを行うことがポイントです。

チームの範囲外への問題への対応

システムの開発において、課題の発生源はスクラムチーム内だけとは限りません。ステークホルダーや組織など、さまざまな外的要因が存在します。

たとえば、ステークホルダーが急に無理な仕様変更を依頼し、プロジェクトを成功させるためには対応せざるを得なくなってしまったり、プロダクトオーナーが別の案件の兼務を指示され、開発に割けるリソースが減ってしまったりといったケースもあります。

このような問題は、スクラムチーム内で対処することが難しいことも多いといえます。一方で、注意しなければならないのが、レトロスペクティブの場を「愚痴の言い合い」にしないことです。外的要因を改善できる可能性があるのであればその可能性を検討する、もしくは改善できないのであれば、それを前提として最善策を検討するといったように、前向きな視点が重要です。

悪い状況の時こそレトロスペクティブが必要

スケジュールが厳しいプロジェクトやリソースが限られているプロジェクトなど、難しい状況にある場合に、レトロスペクティブは軽視されがちです。このような場合、スクラム開発のプロセスに存在するからと事務的に実施されたり、場合によっては省略されてしまったりということも往々にしてあります。

一方で、このような状況の時こそレトロスペクティブが必要といえます。時間がない状態で作業以外のことをやるのはモチベーションが湧かないこともありますが、レトロスペクティブに時間を使い改善を進めることで、長期的に見ればチームに余裕を生むことにつながります。

レトロスペクティブで効果的な改善を

この記事では、アジャイル開発において実施されるレトロスペクティブについて、その概要や主なフレームワークなどについて紹介しました。

レトロスペクティブを含めたスクラム開発の取り組みをうまく進めるためには、アジャイル開発やスクラム開発の経験や知識が必要です。スパイスファクトリーでは、アジャイル開発・スクラム開発によりこれまで多数のお客さまのシステム開発を支援してまいりました。

アジャイル開発でプロダクトやサービスの開発を検討されている方は、ぜひお声がけください。

スパイスファクトリーのシステム開発サービスを見る