• HOME
  • Blog
  • 【スクラム実践者向け】チームを加速させる「より良いレトロスペクティブ」実践ガイド

Blog

【スクラム実践者向け】チームを加速させる「より良いレトロスペクティブ」実践ガイド

2026.09.02

はじめに

スクラムにおいて、チームのパフォーマンスを長期的に高めるための最も重要なイベントが「レトロスペクティブ(振り返り)」です。
しかし、「毎回同じような意見しか出ない」「決めた改善策がなかなか実行されない」といった悩みを抱えているチームも多いのではないでしょうか。

実際、我々トレーナーも、より良いレトロスペクティブをするためにはどうすれば良いか?という質問を日々多く頂戴します。

本記事では、Scrum Inc. Japanに蓄積されているお客様とのやりとりをもとに、チームを確実に加速させるための具体的なステップやフレームワーク、現場で使える改善アイデアの例をご紹介します。

そもそも、レトロスペクティブとは?

レトロスペクティブとは、スクラムチームの作業の品質と有効性を高めるために、自分たちの「プロセス」を検査し、もっと良くするために試してみたい「改善(KAIZEN)」を特定するイベントです。

スクラムマスターにとって、このイベントを効果的にファシリテートすることが最優先事項と言っても過言ではありません。

より良いレトロスペクティブの5つのステップ

レトロスペクティブは、以下の流れで進めると効果的です。

1. 場の設定(心理的安全性の確保)

まずは、全員が率直に意見を言える「場」を作ります。

  • グラウンドルールの確認: 「この時間はレトロにのみ利用する」「原因を追求しても、責任の追求はしない」「全員がベストを尽くしたことを疑わない」といったルールに合意します。
  • アイスブレイク: スプリントの感想や「感謝の気持ち」を伝え合うことで、チームをポジティブな雰囲気にします。「幸福指標」を計測し、その点数の根拠や「もう1点増やすためには?」と尋ねるのも効果的です。

💡 戦国大名に学ぶレトロスペクティブの「場の設定」

実は、日本の戦国時代にも、図らずもこのレトロスペクティブと全く同じ取り組みを行なっている戦国大名がいました。

 黒田孝高(官兵衛、如水)・長政親子は、月に1回、身分に関わらず自由に意見を出せる「異意会」を城内で開いていました。
その際のルールは「何を言われても腹を立てない」「批判されても恨まない」「外部に漏らさない」というもの。
現代の心理的安全性に通じる素晴らしいグラウンドルールです。

2. 起こったことの洗い出し(事実の確認)

人間の記憶は曖昧で、直近1週間のことは思い出せても、2週間前のことは意外と思い出せないものです。
記憶に頼るのではなく、客観的なデータ(事実)を集めましょう。

  • スケジュールやDoneになったチケット
  • メールやチャットツールでのやりとり
  • スプリントバーンダウンチャート
  • 障害のバックログ など

こうしたものを確認することによって、振り返りの対象となる出来事を洗い出します。

3. 整理(フレームワークの活用)

洗い出した事実を、目的に合わせたフレームワークで整理します。
インターネットで検索すると出てくる膨大なレトロスペクティブの種類も、大部分はこの整理のステップのバリエーションにすぎません。

主だったものを挙げますので、用途に合わせて試してみてください。

  • KPT: Keep(続けること)、Problem(課題)、Try(試すこと)
  • YWT: やったこと(Y)、わかったこと(W)、次にやること(T)
  • 4Ls: Liked(よかった)、Learned(学んだ)、Lacked(足りない)、Longed For(こうしていきたい)
  • Fun Done Learn: 楽しかったこと、やり遂げたこと、学んだこと
  • Sailboat: 島(ゴール)、太陽(盛り上げたこと)、追い風(加速させたもの)、いかり(減速させたもの)、岩(リスク)

特に、最後のSailboatは、チームが新たなテーマに取り組む際や、長期的に活動していく中で見直したい事柄(ゴールや、支援してくれる人たち、今後のリスク)などを洗い出す観点で有効です。

4. 改善のアイデア出し

チームで明らかにした課題に対する解決策を考えます。
ここではスクラムマスターの視点を変えるテクニック・ファシリテーションが有効になります。
ここでは、特に効果が高い2つのテクニックを紹介します。

  • 制約を操作する
    「時間や費用などの制約を取り払う」または逆に「すぐに即効性のあるものは?」と制約を入れてみます。
    改善のアイテムを実施するにも労力はかかるため、忙しいチームほど、レトロスペクティブが億劫になることがあります。
    そういう時こそ、すぐ出来ること、労力がかからないものをあげてみよう、というようなファシリテーションが有効です。
  • ユーザーストーリーで考える:
    「誰が(Who)」「何をしたい(What)」「なぜなら(Why)」の形式で考えます。
    普通に改善のアイデアを挙げていくと、大抵の人は、自分が行う改善に集中してしまいます。(=Whoを自分に限定してしまう)
    相手の立場に立って何が必要か、何をしたいのかを考えると、非常に有効なアイデアを得ることができます。

かつて、夏場には幼稚園児が通園バスに取り残されて亡くなってしまう、という悲しい事故が起こりました。
その対策として、まずすぐにできることを、そして自分たちがやることだけでなく、園児(Who)の立場で「園児として、クラクションを鳴らしたい。大人に助けてもらいたいからだ」と考えることができれば、「園の関係者として、園児にクラクションの鳴らし方を教える」というアイデアを導くことができます。
実際、そこに気づいた幼稚園では、翌日には園児たちにクラクションの鳴らし方を教えていましたよね

5. 改善の集約と行き先

先ほども述べた通り、改善のアイテムを実施するにも労力はかかるため、次のスプリントで実施する改善は「1つ」に絞ることを強く推奨します。
選ぶ基準は、ROI(価値/労力)が高いもの、すぐに効果が出るもの、チームが一番やりたいと思うことを選ぶなど、色々あると思いますが、まずは気軽に、チームがやりたいものを多数決で選ぶのが良いと思います。

また、選んだ改善のアイデアの行き先は、大部分がスプリントバックログになりますが、それ以外にもチームが新たに決めたルールなどは、ワーキングアグリーメントや完成の定義に追加されます。

1スプリントで終わらない大きな改善や、プロダクトそのものに対する改善などは、プロダクトバックログにプロダクトバックログ(PBI)として格納し、扱うと良いでしょう。

「良い改善」と「良くない改善」の違い

  • ❌ 良くない改善:
    「もっと注意する」「一層気を付ける」などは良くない改善の典型例です。
    人はミスをする生き物で、精神論では問題は解決しません。
    また、抽象的すぎて「達成できたか」が定量的に確認できないものもNGです。
  • ⭕️ 良い改善:
    AT車がブレーキを踏まないとエンジンがかからないように、また洗濯機が蓋を開けたままでは動かないように、「ミスに気づけるような仕組み、危険な状態で先に進めない仕組み(ポカヨケ)」を作ることが重要です。
    また、問題発生の確率を減らすのも立派な対策です。あまり完璧な(それにともなって労力が大きい)対策を目指しすぎないようにしてください。

実際に現場で出た改善アイデア例

最後に、実際のチームのレトロスペクティブから生まれた実践的なアイデアをいくつかご紹介します。

  • スクラムボード/スプリントボードの工夫
    「Doing」と「Done」の間に「Waiting for Reply(返事待ち)」レーンを作り、外部チームの対応待ちタスクを可視化する。
  • スクラムイベント(デイリースクラム)の工夫
    デイリースクラムで「やったこと」は話さず、「課題や問題点」を中心に話すようにして時間を短縮し、本来の目的に集中する。
  • 協力して欲しい仕事の可視化
    他の人にやってほしい・教えたいタスク(チャレンジタスク)の付箋の色を変え、他のメンバーが新しい仕事に挑戦しやすくする。
  • ワーキングアグリーメント
    16時以降はチームのミーティングを設定しないルールにし、時短勤務のメンバーに精神的な負荷をかけないようにする。
  • 自動化による効率化
    チームが多くの時間を費やしている繰り返し作業を洗い出し、簡易なスクリプトで自動化できないか検証する。

おわりに

レトロスペクティブは、単なる反省会にせず、チームがより楽しく、効率よく価値を生み出すための「カイゼン」を生み出すポジティブな場としてください。

今回ご紹介したグラウンドルールやアイデア出しのテクニックを、ぜひ次のレトロスペクティブから試してみてください。
例え一つであっても、確実な改善を積み重ね続けることで、チームは必ず加速していくはずです!

執筆:木代 圭