はじめに
Scrumを導入しているチームでよく聞く悩みのひとつが、
「レトロスペクティブをやっているけど、正直あまり変化を感じない」
というものです。
本記事では、Scrum Guide（2020年版）をベースにしつつ、
レトロスペクティブを“形骸化させない”ための考え方と実践ポイントを、具体例付きで整理します。
レトロスペクティブとは何か
レトロスペクティブの説明（Scrum Guideより）
Scrum Guide 2020では、スプリント・レトロスペクティブを次のように説明しています。
- スプリントの最後に行われるイベント
- 人・プロセス・ツール・作業のやり方を検査する
- うまくいった点、問題点を明らかにする
- 改善すべき最も有用な変更を計画する
ポイントは、「振り返ること」自体が目的ではないという点です。
レトロスペクティブの目的
レトロスペクティブの目的はシンプルです。
- チームのやり方をより良くする
- 次のスプリントで試す改善を決める
- 継続的に学習・改善するチームになる
つまり、
次のスプリントで「何が変わるか」
が決まらないレトロスペクティブは、価値が半減してしまいます。
レトロスペクティブの結果に現れやすい3つのパターン
レトロスペクティブのアウトプット（改善案）を眺めてみると、だいたい次の3パターンに分類できます。
① マインド系（良くないパターン）
例
- 「XXを意識する」
- 「コミュニケーションを大切にする」
- 「もっと早めに共有する」
一見もっともらしいですが、
- 行動が具体化されていない
- 個人の意識や頑張りに依存している
という特徴があります。
結果として、
- 次のスプリントで忘れられる
- 同じ指摘が何度も出てくる
という“レトロスペクティブあるある”に陥りがちです。
② プロセス系（良いパターン）
例
- 「レビュー依頼時はSlackにテンプレートを貼る」
- 「XXのステータスが変わったらSlackに自動通知する」
- 「朝会で必ずブロッカーを確認する」
プロセス系の改善案は、
- 誰がやっても同じ行動になる
- チームの仕組みとして残る
- 再現性が高い
という特徴があります。
レトロスペクティブのアウトプットとして、最も理想的な形です。
③ タスク系（注意が必要なパターン）
例
- 「XXの資料を作成する」
- 「手順書を修正する」
タスク系は、
- そのスプリント限りで終わる
- 根本原因を解決していない
ことが多く、基本的には良くないパターンに分類されます。
ただし例外あり
以下のように、プロセス改善を実現するための手段であればOKです。
- 「Slack自動通知を行うためのスクリプトを作成する」
- 「レビュー依頼テンプレートを作る」
この場合、
- 目的：プロセス系の改善
- 手段：タスク系
という関係が明確になっています。
レトロスペクティブをうまく進めるコツ
① 全員が意見を出せるアジェンダとファシリテート
- 最初は全員が黙って書き出す時間を作る
- 付箋やオンラインボードを使う
- ファシリテーターが発言量を調整する
「声が大きい人の意見だけで決まる」状態を防ぐことが重要です。
② すべての課題を扱わない
ありがちな失敗が、
- 出てきた課題を全部議論しようとする
ことです。
以下の観点で絞り込みます。
- 影響が大きいか
- 再現性が高いか（また起こりそうか）
重要なものを少数選び、深く議論する方が効果があります。
参考として、KPTでレトロスペクティブを実施する場合、以下の画像のようなボードを作成するとより重要なものの選定がしやすくなります。
このKPTボードでは、Problem（問題）を「どれくらい重要か」と「どれくらい起こりやすいか」で整理しています。
Problemの中はマトリクスになっていて、
- 横軸（X軸）：影響度（右に行くほど低い）
- 縦軸（Y軸）：再現性（上に行くほど高い）
という見方をします。
つまり、左上にあるProblemほど「影響が大きくて、しかも何度も起こりそう」な問題ということになります。
最初は記載者が書いた課題はどの位置なのかを判断して、課題共有後にチームで位置を決定すると良いでしょう。
③ 改善案が「具体的・仕組み化」されているか確認する
改善案を決めるときは、次をチェックします。
- 誰が・いつ・どうやるかが明確か
- 「意識する」になっていないか
- 次のスプリントで試せるか
チーム内で
「それ、マインド系になってない？」
とツッコミ合えるようになると、レトロスペクティブの質が一段上がります。
チームで実際にあった例
課題
- レビューが滞留しがち
最初に出た案（マインド系）
- 「レビューを優先する意識を持つ」
改善後（プロセス系）
- 「レビュー依頼時はSlackに ＠here + テンプレート投稿」
・レビュー依頼用テンプレート作成 （タスク系） - 「24時間レビューがつかない場合は自動リマインド」
・レビュー依頼自動リマインドBot作成 （タスク系）
結果として、
- レビュー待ちが可視化
- 特定の人の善意に依存しない
状態になりました。
まとめ
- レトロスペクティブは検査と適応のためのイベント
- マインド系ではなく、プロセス系の改善を目指す
- 重要な課題に絞り、具体的で仕組み化された改善を決める
この視点を持つだけで、レトロスペクティブは「やっているだけのイベント」から、
チームを前に進める武器になります。