NTT DATA TECH
📘

形骸化しないスプリントレトロスペクティブ:チーム学習を生む実践的ガイド

スプリントレトロスペクティブ

スプリントレトロスペクティブ(以下、レトロ)は「やっているつもり」になりやすいイベントです。レトロを開いても、同じ課題ばかり挙がる、改善が行動につながらない――そんな悩みをよく耳にします。しかし本来のレトロは、スクラムの経験主義をチームの学習へ変える仕組みです。本記事では、形骸化を防ぎ、次のスプリントを確実に変化させるための設計とファシリテーションの実践を解説します。


レトロの概念:経験主義の学習装置として

スクラムは透明性・検査・適応の三本柱をもつ経験主義のフレームワークです。レトロはこのうち、検査→適応チームの学習へつなげる装置だと捉えると、意義がはっきりします。

  • 何が起きたのかを透明にする
  • 事実を検査する
  • 次のスプリントで適応する

目的の再提示:レトロの目的は「品質と効果を高める方法を計画する」ことです。ここでの「品質と効果」は、特定の成果物に限定されず、チームの働き方・プロセス・価値創出全体を含む広い概念として扱うのが実務的です。

スプリントレトロスペクティブ
スクラムガイド2020より

検査の軸の例

  1. チームは価値を生み出しているか
  2. ゴール(プロダクト/スプリント)に近づいたか
  3. 各スプリントで有用なインクリメントを届ける責任を果たしたか

ここでのポイントとしては、うまくいかなかったことだけではなくうまくいったことから言語化することです。これにより再現性と士気を高めることができます。


5ステップでレトロを設計する

Derby & Larsen は『アジャイルレトロスペクティブス』で、以下の5つのアクティビティを通じたレトロスペクティブの形式を提唱しています。

  1. 場を設定する
  2. データを収集する
  3. アイデア/洞察を出す
  4. 何をすべきか決定する
  5. レトロを終了する

この5つで発散→収束のリズムが生まれ、話し合いを行動へ着地させやすくなります。特に2. →3. のアクティビティにおいて、「事実」と「解釈」を分ける意識を持つと、感情的な応酬になってしまうことを避けやすくなります。


参加者とファシリテーションのあり方

参加者:プロダクトオーナー(以下、PO)、開発者(以下、Dev)、スクラムマスター(以下、SM)を含むスクラムチーム全員。スクラムチーム全員が「インクリメントを届ける共同責任者」であり、当事者として参加します。
外部からの参加者:チームの自由意思に基づく招待は可です。ただし、管理職等からの参加要請が強すぎる場合は、透明性や率直な対話に影響を与える可能性があります(いわゆる「インビジブル・ガン効果」)。
進行役:スクラムチームは自己管理型ですので、SMが固定の進行役である必要はありません。ローテーション制やファシリテーターなしで回せる状態は成熟のサインです。SMが常にファシリテーターや司会進行を担っている状況は、チームが自律的に機能しておらず、SMへの過度な依存が生じている兆候かもしれません。


ファシリテーションに使える実践テクニック

1) まず「場の契約」をつくる

  • ノーム・カースの最優先条項を短く読み上げ、「非難ではなく学習」の前提を共有。
  • ワーキングアグリーメント(例:割り込みなし、時間厳守、結論は実験単位 など)を冒頭に再確認。
  • チェックインで発言のスイッチを入れる(例:「今の集中度を10点満点で」「週末の予定は?」など)。

ノーム・カースの最優先条項
「今日見つけたものが何であれ、チームの全員が、その時点でわかっていたことやスキルおよび能力、利用可能なリソースを余すことなく使って、置かれた状況下でベストを尽くした、ということを疑ってはならない。」

2) 参加設計で「全員の声」を引き出す

  • 1-2-4-All:個人→2人→4人→全体の順で話を広げると、参加の偏りが減り、短時間で合意の核ができます。
  • ブレインライティング:個人ワークで静かに書き出してから共有する順にすると、声の大きさの差によるバイアスを緩和できます。

3) 論点を絞る:可視化された合意形成

  • ドット投票:かきだされた付箋や項目に対して、全員で平等な数の票をもって重要だと考えるものや気になるものに対して、投票することで発散された意見やデータを上位2〜3テーマに絞ることができます。
  • ファイブフィンガー投票:全員でいっせいに手を上げ、その時に挙げる指の本数でそれぞれの合意具合を表明することで、チーム内で懸念や課題感を持っている人がいないかを可視化することができます。

4) 手法の選び方

  • ねらいに応じてスタート/ストップ/継続、Sailboat、学習マトリクス等をローテーションし、視点を変えましょう。
  • 例:フローの詰まり→Sailboat、感情と事実の分離→学習マトリクス、優先度付け→ドット投票。

フレームワークの功罪と集中の原則
KPT/Fun-Done-Learn等は取り組みを始めやすい一方で、Tryが過多になりやすく、最もインパクトのある改善に集中しづらいリスクがあります。大項目に絞る設計(ドット投票→上位2件)とセットで用いる、もしくは目的適合度の高いSailboat/学習マトリクス等へ切替える運用が無難です。フレームワーク自体の有効性も毎回検査すべきです。

フレームワークについては、多種多様なものが実際の手順やファシリテーションのポイントともにオンライン上に公開されていますので、ぜひ検索してみてください。

5) オンライン/ハイブリッドの工夫

  • 付箋は事実/解釈/感情に列分けして貼ると、意見の発散と収束がスムーズになります。
  • 投票は匿名・同時を基本とすることで意見や提案の安全性が高まります。

改善の選択と実施:少数・自己完結・スプリント完結

  • 少数に絞る:スクラムの価値「集中」に沿い、本当に効く変更へフォーカスすることで、やった気になったが結果につながっていない、という状況を防ぎます。
  • 自己完結スクラムチーム自身でやり切れる改善のみ採択する。依存が強い施策は分解し、「明日から動かせる一歩」に再設計します。
  • スプリントに収まるサイズ:プロダクトバックログアイテムと同様に、次スプリントで検査可能な大きさまで分割しましょう。
  • みんなで取り組む:個人へのアサイン、ToDo化を避け、チーム全体の仕事として取り組みましょう。
  • バックログに追加:改善はプロダクト/スプリントバックログへ追加します。プロダクトバックログはスクラムチームの作業の唯一の情報源です。

レトロで扱う情報をどこまでチームの外に公開するか

レトロで扱う情報(個人の失敗・感情・未成熟な仮説等)をどこまで外部に出すかは、自己管理の一部としてチームが合意しておきましょう。
人事評価や指摘文化に流用されると、透明性と心理的安全が崩れます。開示は目的適合(学習・支援要請)に限るのが基本です。


おわりに

レトロは「反省会」ではなく、チームが経験を学びに変えるための学習装置です。完璧な進行よりも、「事実を共有し、次の一歩を小さく試す」ことが本質です。今回ご紹介した5つのアクティビティをベースに、あなたのチームに合う形で少しずつカスタマイズしてみてください。次のスプリントの冒頭で実験の結果を語ることができたら、それが改善文化への一歩と言えるでしょう。


参考文献・リンク

NTT DATA TECH
NTT DATA TECH
設定によりコメント欄が無効化されています