English version is available here =>
Dev.to: The Concept of Designing Retrospective
はじめに
この記事ははてなに投稿した上手に振り返る。チームがもっと強くなる。 ~レトロスペクティブを設計するという考え方~の中から、エンジニアリングに関わる部分だけを抜粋して転載しています。
また、この記事はRSGT2025へのプロポーザルに使用する目的で書いているので、プロポーザルへのいいねをいただけると泣いて喜びます。
それでは本編をどうぞ！
レトロの質はチームの質、ひいてはプロダクトの質につながる
この記事を読んでいる皆さんは、きちんとレトロスペクティブを行っていますか？
スクラムを実践している開発者にこの質問をすると、「毎スプリントきちんとやっている」「隔週だが時間をしっかりとっている」と返ってくることが多いです。
しかし、実際に何をしているかを聞くと、KPTを書いて発表するだけ、というケースがよく見られます。
レトロスペクティブは、スクラムの三つの柱である 『透明性』『検査』『適応』 のうち、 『検査』 を担う活動であり、適応のための準備をする活動でもあります。
この『検査』の質は、直接チーム、ひいてはプロダクトの質に直結します。
そのため、ただKPTを書いて発表して終わるだけでは、少し不十分かもしれません。
スクラムには代表的な検査イベントとして、 スプリントレビュー もあります。
スプリントレビューはプロダクトへの検査であり、プロダクトをどう向上させていくかを担います。
一方、レトロスペクティブはチーム活動への検査であり、チーム活動の質をどう向上させていくかを担っています。
思いつく限りで、代表的な検査の観点を図にまとめてみました。
こうして見ると、それぞれのイベントには非常に多くのトピックがあり、少し話しただけでは改善できないことがわかると思います。
これらのトピックについて効率よく議論し、実際にチーム活動を向上させる改善サイクルを回していくためには、各イベントをしっかりと設計し、チームを議論に導く必要があります。
今回はスプリントレビューには触れませんが、イベントや会議を設計するという考え方はさまざまな場面で役立ちますので、もし興味があれば参考にしてみてください。
レトロスペクティブを設計する
レトロスペクティブを設計するとはどういうことでしょうか。
レトロも含め、ほとんどの会議には目的があります。
アイデア出し、情報共有、目の前の問題への対応策の決定など、目的はさまざまです。
そして、レトロの参加者たちがその目的にスムーズに辿り着けるかどうかは、アジェンダとファシリテーションの質に大きく左右されます。
どのような運びで議事進行を行うか、どんな方法で議論を行うのか、発散させるのか収束させるのか、どのように結論づけるのか、といった要素が重要です。
そういった観点から、参加者を目的により効率的かつ適切に導くためのアジェンダと議論の方法を考えることが、レトロスペクティブを設計するという考え方になります。
フェーズとツール
レトロの設計を始めるにあたって、レトロをフェーズとアクティビティという視点から見てみましょう。
フェーズとは、言葉の通り議論の段階のことです。
設計段階では、議論を進めるにあたり、どのような段階を踏めば効率よく結論に辿り着けるかを考えます。
例えば、共有・発散・分析・意思決定という四つのフェーズがあったとすると、発散と分析は一回ずつで良いのか、意思決定は必要なのか、それぞれにどの程度の時間を使うのかなどを検討します。
レトロにも目的はありますが、それぞれのフェーズにも目的があり、フェーズの目的を達成するために使用されるツールが次に説明するアクティビティになります。
アクティビティとは、それぞれのフェーズでどのような議論の方法を用いるかです。
例えば、冒頭に出てきたKPTも議論を行う方法としてのアクティビティの一つです。
他にも、『帆船のレトロ』や『5 Whys』、『ブレインストーミング』、 『Good/Bad/Ugly』 などのアクティビティは馴染みのある方も多いのではないでしょうか？
それぞれのアクティビティには得意なことと苦手なことがあり、チームの状況や議論のフェーズ、所要時間に合わせて組み合わせを考える必要があります。
各フェーズごとに適切なアクティビティを組み合わせることで、より効率的に議論を進めることができます。
このように、レトロのタイムボックスやチームの状況を分析し、議論の段階（フェーズ）と議論の方法（アクティビティ）の組み合わせを考えることが、レトロスペクティブを設計するにあたっての基本になります。
また、この考え方は普段の会議でも使用することができますので、レトロに限らずワークショップやプレゼンテーションなど、さまざまな場面で必要に応じて使ってみてください。
なお、これらのアクティビティは手札の多さや成熟度によって設計の質が大きく変わります。
アクティビティをあまり知らない、やり方がわからないという場合には、ぜひ参考文献の章にある『アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き』を読んでみてください。
非常に多くのツールが紹介されています。
レトロスペクティブの5つのフェーズ
さて、いきなりレトロスペクティブを設計しなさいと言われても、何から始めれば良いかわからないかもしれません。
ご安心ください。スクラムのレトロスペクティブには、一般的に使われる「**5つのフェーズ」**というフレームワークがあります。
これは、レトロスペクティブの時間を5つのフェーズに分割し、それぞれにアクティビティを組み合わせて結論に導くという考え方です。
以下に、その5つのフェーズを簡単にまとめます。括弧内は、1時間のレトロスペクティブを設計する場合の時間配分の目安です。
- Set the Stage - 場を設定する（5分以内）
- Collect the Data - データを集める（10分程度）
- Generate Insights - データを分析する（30分程度）
- Make Decisions - 何をするか決める（10分程度）
- Close the Retro - レトロを閉会する（5分以内）
このフレームワークでは、議論の準備をし、議論の種を集め、集めたトピックについて議論し、何をするかを決定し、今後に向けて動き出すという流れを作ります。
それでは、それぞれのフェーズについて説明します。
Set the Stage - 場を設定する
このフェーズでは、参加者全員が安心して議論できる準備を行います。
参加者全員が議論に参加できることが重要です。しかし、残念なレトロスペクティブでは、一部の主張が強い方がずっと話していたり、最初に発言する機会を逃した人が最後まで黙ったままになることがあります。
このフェーズは、参加者全員に「これから議論に参加する」「この場で発言して良い」という意識を持ってもらい、そのためのルールを制定・確認する場です。
全員が議論に参加し、チームとしての進む方向を決める場で意見を述べることは、多くの視点を集めるだけでなく、レトロスペクティブで決まった改善案を実行する際の当事者意識にもつながります。
このフェーズは軽視されがちですが、開始が遅れるなどでよほど時間が押していない限り、必ず行うようにしてください。
さて、このフェーズで何を行うかは、チームの成熟度に大きく依存します。
チームの成熟度に合わせて、二つのアクティビティを紹介します。
チェックイン
例えば、チームの心理的安全性が高く、各メンバーが活発に意見を言い合える場合は、何か一言発言してもらうだけでも構いません。
本来のチェックインはレトロに集中してもらうために行うので、レトロに期待することや今の自分の状況を言ってもらうことがルールですが、別にそれにこだわる必要はありません。
「今週のスプリントに関する感想を一言で！」、「今の気分を20文字で！」、「今日のお昼ご飯に食べたものとその感想を一言で！」などで十分です。
これは質問の答えを知りたいわけでも、仲良しごっこをしたいわけでもなく、「これから声を出すぞ」「自分の意見を発言するぞ」という雰囲気を作るための準備体操のようなものです。
意味がないように感じるかもしれませんが、このアクティビティの有無で議論の活発さは大きく変わります。
たとえバカバカしく感じても、必ず行うようにしてください。
実際に私の所属する会社では、この 「感情の輪」 の上に自分の名前を置いて、その理由を一人一言で話すというアクティビティをよく最初に行います。
画像引用：Wikipedia: Emotion classification
チームの約束
一方、一部の主張が強い方がずっと話してしまうようなチームの場合、議論のルール決めや確認から始めます。
具体的なルールとしては、「全員が話す量が同じになるようお互いに気を遣う」、「誰かが話しているときは遮らず最後まで聞く」、「話に入りづらいと感じたらサインを出す」、「1分以上続けて話す場合は他のメンバーに意見や質問がないか確認する」などが考えられます。
これらのルールは、ファシリテーターやスクラムマスターが決めても良いですが、一度レトロスペクティブの時間を使って話し合っても良いかもしれません。
チームとして決めた約束事であれば、つい話したくなってしまうメンバーも、あまり話すのが得意でないメンバーも、それぞれが納得しながら議論に参加できるようになります。
また、役職の高いメンバーがいる場合、事前にその方に発言の頻度や強さを少し抑えてもらうようお願いしておくのも有効です。
Collect the Data - データを集める
参加者全員が話す準備ができたら、次に議論するための種を集めます。
データというと、消化したストーリーポイントや稼働日数、PR数などの定量的なものをイメージするかもしれませんが、ここでいうデータには感情や意見、出来事などの定性的なものも含まれます。
KPTを貼り出すこともデータ収集活動の一つです。KPTはデータ収集から意思決定までを一貫して行うツールですが、この時点ではTRYは「やったほうがいいと思うこと」程度の扱いにしておいた方がいいでしょう。
具体的なデータとしては以下のようなものが挙げられます。
定量的なデータと取得するためのツール
- 消化したストーリーポイントの推移：Jiraなど
- 開発活動のリードタイム（※1）：Findy Teamsなど
- 4 Keysの値（※2）：Jira、Findy Teamsなど
- 実効稼働時間（※3）：カンバン上のチームカレンダーやグループウェアなど
※2 デプロイ頻度、変更のリードタイム、変更障害率、サービス復元時間
※3 スプリント内の合計稼働時間のうち、休暇やミーティング、スクラムイベントなどを除いた時間
定性的なデータと代表的なアクティビティ
- チーム活動内容へのフィードバック：Keep/Problem/Tryなど
- チームの状況へのフィードバック：Good/Bad/Ugly、帆船のレトロなど
- スプリント内の出来事：タイムラインなど
- メンバーの感情的フィードバック：Mad/Sad/Gladなど
もちろん、これらすべてのデータを集めるのは現実的ではありませんし、多すぎる情報はノイズになります。
どのようなデータをどのように集めるかは、スクラムマスターやチームメンバーが何を話したいかを事前に確認し、ファシリテーターが決めてください。
また、一点押さえておきたいのは、レトロスペクティブで最も重要なのはこの後に続く議論と分析だということです。
したがって、データ収集の時間を抑えるために、データを自動で収集するツールを使ったり、日々の活動の中でKPTを集めるのは非常に有効な手段です。
実際にスクラムトレーナーとのメンタリングミーティングの中でも繰り返し指摘され、日常的にタイムラインと感情・活動フィードバックを集めるためのボードを作成しました。
また、私が参加したチームでは、Found and Resolvedという、チーム全体で話したいことを気づいた段階で設置するスペースも用意していました。
Generate Insight - データを分析する
次はデータ分析のフェーズです。データ収集の最後でも触れましたが、このフェーズはレトロスペクティブの核と言っても過言ではありません。 チームメンバー全員の知恵を結集して、収集した課題の分析と解決策の模索を行います。
議論するトピックを選ぶ
データ分析フェーズを始めるにあたって、まず最初に行うべきことは、議論する課題の選出です。各メンバーはそれぞれの課題感を抱えており、データ収集ではさまざまなトピックが出てきます。
しかし、議論できる時間も改善に充てられる時間も限られているため、どの問題を解決するか、あるいはどの良い点をさらに伸ばすか、議論の対象を絞る必要があります。
おすすめのトピックの絞り方として、ドットボーティングとヒートマップがあります。
ドットボーティング
ドットボーティングはよく使われる手法なので、ご存知の方も多いかと思いますが、一応解説します。
ドットボーティングでは、一人あたりの投票数（例：3票）を決め、データ収集で集めたトピックの中で議論したいものに投票します。持ち票を絞るのは、各メンバーに優先順位付けを行ってもらうためです。
最も多く投票を集めたトピックが、チームとして関心が高い内容となり、改善した際のインパクトも大きくなります。ドットボーティングは短時間で行える上、シンプルで分かりやすいという利点があります。
ただし、注意点として、ドットボーティングを行う際は、色や記名などで誰が投票したかが分からないようにする必要があります。
投票者が分かると、チーム内のパワーバランスや気遣いで投票が偏る可能性があります。チームメンバー全員がフラットに議論するトピックを選出するためにも、同じ色の無記名のドットを使用しましょう。
ヒートマップ
個人的にドットボーティングよりおすすめなのがヒートマップです。ドットボーティングの拡張版で、データ収集で集めたトピックの中から、議論したいものに決められた数以下の好きな数のドットを投票します。ドットの数はそのトピックへの関心度を表し、例えば最大3票の場合、以下のような意味付けをします。
- 1票：興味がある
- 2票：話したい
- 3票：とても話したい
投票後、ドットボーティングと同様にドットの数を集計し、最も投票数の多いものから順に議論を始めます。
ヒートマップの良いところは、各メンバーの意志の強さが反映される点にあります。ドットボーティングでは、それほど興味がないトピックにも票が入ることがありますが、ヒートマップでは興味の度合いが票数に影響します。ヒートマップを行うことで、あまり共感が得られていないが特定のメンバーにとって非常に重要なトピックにもスポットライトが当たり、一部のメンバーしか気づいていない問題も議論の対象として選ぶことができます。
議論を深める
議論する対象が絞れたら、次は議論に移ります。選ばれたトピックに対して意見や知恵を出し合い、試してみたいこと・やってみたいことを共有します。
議論は結論が出るまで自由に行っても良いですが、フィッシュボーン図を使ったり、5 Whysやリーンコーヒーを活用することで、より効率的に進めることができます。
私自身、1on1や通常の会議でもリーンコーヒーをよく使うので、ここではリーンコーヒーについて解説します。
リーンコーヒー
リーンコーヒーは、タイムボックスを設定して多くのトピックを議論するための手法です。以下のようなルールで、短時間で分析とアイデア出しを行います。
- 10分間を5分・3分・2分の3つに区切る。
- 最初の5分が終わった段階で議論を一旦止める。
- そのトピックについて満足した場合は👍のサインを出し、まだ話したい場合は何も出さない。
- 過半数が👍を出した場合は次のトピックへ、そうでない場合は議論を継続する。
- 残りの3分でも同様に行い、最後の2分が終わったら無条件で次のトピックへ移る。
この方法で議論を進めることで、30分で最大6トピック、最低でも3トピックについて話すことができます。また、それぞれのトピックでTRYのアイデアが2つずつ出れば、6個のトピックから12個のTRYの種が生まれます。
余談ですが、リーンコーヒーを行う際には書記を設けることをおすすめします。議論の流れを視覚的に追えるようにすることで、建設的なTRYを生み出しやすくなります。
Make Decisions - 何をするか決める
議論を深め、さまざまなTRY（試してみたいこと）が出たら、最後にチームを良くするために何を実行するかを決定します。
議論の中でTRYが出たからといって、この後の改善内容が決まったわけではありません。上がったすべてのTRYを実行することはできませんし、議論の中で出てきたTRYが必ずしも実行可能なものとは限りません。
このフェーズでは、主に以下のような議論と意思決定を行います。
- どのTRYがチームにとって最も重要かを決定する
- TRYを実行可能なものに磨き上げる
- TRYのアサイン（担当者）を決める
- TRYを管理する
このフェーズを経ることで、TRYは以下のように実行可能なものになります。
それぞれについて説明していきます。
どのTRYがチームにとって最も重要かを決定する
適切なトピックを選択し、活発な議論が行われると、多くのTRYが出てくることがあります。しかし、そのすべてを実行することは現実的ではありません。
多数のTRYを同時に進めようとすると、次のスプリントでチームは多くの変化に直面し、疲弊してしまいます。最悪の場合、TRYを実行しようという意欲が徐々に減少し、レトロスペクティブが改善案を出すだけの場になってしまう可能性もあります。
このフェーズの最初には、ドット投票やヒートマップなどを活用して、どのTRYを次のスプリントで行うかを決定しましょう。
TRYを実行可能なものに磨き上げる
冒頭でも述べたように、議論の中で生まれたTRYは、そのままでは実行に移せない場合があります。選んだTRYを実行可能なものにするために、わかりやすく文言を修正したり、サブタスクを作成したり、スコープを調整したりして磨き上げます。
TRYを磨き上げる際には、SMART目標という基準に照らし合わせることをお勧めします。
SMARTな目標とは、目標設定でよく使用される基準で、以下の5つの単語の頭文字を取ったものです。
- Specific（具体的）：明確で具体的である
- Measurable（計測可能）：進捗や成果が測定できる
- Attainable（達成可能）：現実的に達成可能である
- Relevant（関連性がある）：問題解決に適切である
- Time-bound（期限がある）：明確な期限や時期が設定されている
例えば、以下のような問題とTRYが上がっていたとします。
問題：PRが溜まってしまい、コンフリクトが多数発生している
議論の中で出たTRY：レビューの時間を決めてペアレビューを行う
このTRYはそのままでは実行可能とは言えません。SMARTの観点から磨き上げてみましょう。
- Specific（具体的）：やること自体は明確なので問題ありません。
- Measurable（計測可能）：頻度や時間が明記されていないため、計測が難しいです。例えば「毎日1時間」と明記すると良いでしょう。
- Attainable（達成可能）：レビュワーとレビュイーのスケジュール調整が必要です。例えば、デイリースクラム（DS）の後に1時間ブロックするなどのサブタスクを作成すると、実現可能性が高まります。
- Relevant（関連性がある）：レビュー時間を確保することでPRの滞留を防ぐため、問題解決に適しています。
- Time-bound（期限がある）：期限が設定されていません。例えば、「2週間継続し、効果をレトロで評価する」とすると明確になります。
このようにTRYを磨き上げることで、以下のような具体的なTRYとタスクが生まれます。
問題：PRが溜まってしまい、コンフリクトが多数発生している
改善策（TRY）：次の2週間、DS後に1時間ペアレビューの時間を設定し、その後継続するかを議論する
タスク
- カレンダーに予定を登録する
- DSのアジェンダの最後にペアレビュー依頼を追加する
- 毎日のDSでペアレビューが必要な人がいないか声掛けする
- 2週間後に継続の是非を話し合う
アサインを決める
磨き上げたTRYを実行するために、次にアサイン（担当者）を決めます。誰がそのTRYを完遂する責任を持つのか、作成したサブタスクを誰が行うのかを明確にしましょう。
一般的なレトロスペクティブでありがちなのが、改善案は出たものの、実行されずに終わってしまうことです。この段階で責任者を決めておくことは、チーム全体で責任を持って改善に取り組む習慣をつけ、レトロスペクティブを形骸化させないためにも非常に重要です。
以前参加していたチームでは、「〇〇警察」（e.g. レビュー警察・ペアプロ警察） という一時的な役割を設け、チームが決めた改善案が実行されているかをチェックしたり、声掛けを行ったりしていました。
身近なメンバーが声掛けをしてくれることで、抵抗なく自然に改善案を実行できるため、非常に有効な取り組みだと感じました。
TRYを管理する
この項目は必須ではありませんが、TRYを管理することでチーム活動の改善に大きな効果がありました。
選んだTRYを磨き上げ、アサインを決めても、日々のタスクに追われて一週間前や一ヶ月前に決めた改善案が流れてしまうことがあります。
このような事態を避け、確実に改善を実行するために、レトロスペクティブで出たTRYをカンバンで管理し、デイリースクラム（DS）で進捗確認を行うことをお勧めします。毎日、前スプリントのTRYとタスクの進捗状況を確認し、チーム活動の改善が進んでいるかをチェックすることは非常に有効でした。
Close the Retro - レトロを閉会する
次のスプリント以降にどのような改善を行うかが決まったら、最後にレトロを閉会します。
このフェーズでは、チームが学んだことを記録し、改善案を定着させ、参加者やファシリテーターに感謝を述べます。
主に行うことは以下のとおりです。
- レトロ内容の振り返り
- カンバンの見える場所にTRYやタスクを移す（TRYカンバンを使っているならそこに転記することも含む）
- （オフラインの場合）ホワイトボードや付箋の写真を撮る
- （オフラインの場合）会場の片付けを行う
- 参加者やファシリテーターに感謝を伝える
個人的に好きなアクティビティを二つ紹介します。
レトロのレトロ
レトロスペクティブはチーム活動の改善活動ですが、レトロ自体も改善の対象です。レトロの最後にレトロ自体の振り返りを行うことで、次回以降さらに効率的・効果的にレトロを行うことができます。
「レトロのレトロ」では、最後に各メンバーから良かった点や改善点を書き出してもらいます。
例えば、「言いたいことがなかなか言えなかった」「議論が停滞してしまうことがあった」「フェーズ間の関連性が弱かった」などのフィードバックを率直に伝えてもらうことで、次回のレトロ設計に活かすことができます。
感謝の輪
このアクティビティは、四半期に一回のレトロで特に有効です。また、プロジェクトやリリースの最後に行う全体レトロでも非常に効果的です。
方法は非常にシンプルで、順番にチームと各メンバーに感謝を伝えてもらうだけです。
手順：
- 最初の人がチームとチームの誰か（もしくは全員）に対して感謝を述べる。
- 感謝を述べた人が次の人を指名し、その人が同様に各メンバーに感謝を述べる。（ステップ1で感謝を述べたメンバーを指名しても構いません。）
- 最後の人が感謝を述べ終わったら、レトロの完了を宣言する。
レトロスペクティブは継続的な改善を行うために開催されますが、一緒に働くメンバーに対して感謝を述べて締めくくることで、次のスプリントをポジティブに始めることができます。また、レトロ自体や改善活動全体の印象もポジティブになります。
まとめ
かなり長くなってしまいましたが、以上がレトロスペクティブをデザインするという考え方についてでした。
レトロスペクティブは代表的なスクラムイベントの一つであり、「よくわからないけどとりあえずやってみる」という形で行われがちなアクティビティだと思います。
スクラムのゴールは継続的な仮説検証と改善を通じてプロダクトの価値を上げていくことなので、どうしても焦点はバックログやスプリントレビューなど、プロダクトやサービスそのものの改善に向きがちです。
しかし、同時にスクラムの主体はチームであり、チームの質の向上はひいてはプロダクトの質につながります。
もしこの記事でレトロに興味を持っていただけた方がいたら、ぜひ今一度レトロスペクティブというイベントを設計してみてください。
最後になりますが、冒頭で書いた通り、この記事はRSGT2025へのプロポーザルのために作成しました。
もしいい記事だなと思ってくださった方がいらっしゃいましたら、プロポーザルへのいいねをお願いします🙏
RSGT2025 プロポーザル
また、この記事に関して相談したい・質問したい、また自分のチームで一度設計とファシリテーションをして欲しいなどがありましたら、以下のメールアドレスまでぜひご連絡ください。
最後までお読みいただきありがとうございました。
参考文献
The Five Phases of a Successful Retrospective
Are you an Elite DevOps performer? Find out with the Four Keys Project
アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き (Amazonへのリンクですが、アフィリエイトではありません)