Team Productivity Playbook
機能するレトロスペクティブの進め方
あるエンジニアリングチームがレトロスペクティブを6か月間毎週実施していました。毎回、同じ問題が挙がりました：デプロイのプロセスが遅すぎる、レビューの優先順位が不明確、ドキュメントが常に後回し。毎回、アクションアイテムが作成されました。毎回、次のレトロスペクティブまでに何も変わっていませんでした。
6か月後、誰かが「私たちはレトロスペクティブをやっている意味があるのか？」と尋ねました。
問題はレトロスペクティブのフォーマットではありませんでした。問題はその後でした。
なぜほとんどのレトロスペクティブは機能しないのか
レトロスペクティブが機能しない理由は一つです：アクションアイテムが実行されないからです。アクションアイテムが実行されない理由はいくつかあります：
オーナーが不明：「チームがXを改善する」はアクションアイテムではありません。誰も責任を持ちません。
期限が不明：「次のSprintまでに」は決まっていますが、「近いうち」は決まっていません。
多すぎる：1回のレトロスペクティブで8つのアクションアイテムが生まれたら、どれも実行されません。
フォローアップがない：次のレトロスペクティブが始まって、前回のアクションアイテムを誰も確認しません。
機能するレトロスペクティブはこれらの問題を構造で解決します。
60分フォーマット
このフォーマットは60分で完結し、フォローアップを中心に据えています。
最初の10分：前回のアクションアイテムのレビュー
多くのチームはこのステップを省略します。それがすべての問題です。
前回のレトロスペクティブのアクションアイテムのリストを表示してください。各アイテムについて、担当者に一言聞いてください：完了しましたか、進行中ですか、それとも着手できていませんか？
評価もフィードバックもありません。ただ確認するだけです。完了したものにはチェックを入れます。完了していないものについては、次の週に引き継ぐか、優先度が変わったので削除するかを決めます。
このステップが最も重要です。前回の決定事項の確認なしにレトロスペクティブを始めることは、「アクションアイテムは実行されなくても構わない」というメッセージをチームに送ることになります。
次の35分：振り返り本体
振り返り本体には多くのフォーマットがあります。最もシンプルで効果的なのは3つの質問です：
うまくいったこと：このSprintまたは期間でうまくいったことは何ですか？繰り返すべきことは何ですか？
改善が必要なこと：うまくいかなかったこと、フラストレーションを感じたこと、変えたいことは何ですか？
試したいこと：次のSprintで試みたい新しいこと、実験したいことは何ですか？
付箋紙（物理的またはデジタル）を使い、各人が個別に考えを書き出してから共有します。5分間の沈黙で考えを書き出し、次に1人ずつ声に出して読みます。テーマを探してグループ化します。
「改善が必要なこと」の各テーマについて、5回の「なぜ」を掘り下げてください。「デプロイが遅い」が表面的な問題です。「テストが不安定だから自動テストの実行を避けている」が根本原因かもしれません。根本原因のみがアクションアイテムに値します。
最後の15分：アクションアイテムの絞り込み
ここが機能するレトロスペクティブと機能しないレトロスペクティブを分けるステップです。
アクションアイテムの候補リストを見てください。次の3つの質問でフィルタリングしてください：
誰が担当するか？ 担当者が決まらない場合は、アクションアイテムではありません。チームへの提案にしてください。
いつまでに完了するか？ 次のSprintの終わりまでに完了できますか？できない場合は、より小さなステップに分解するか、今回は見送ってください。
これを達成すれば、実際に状況が変わるか？ 多くのアクションアイテムはフラストレーションに対する反射的な反応です。「ドキュメントをもっと書く」は意味がありません。「Sprint終了時にドキュメントチェックリストを追加して、次のSprintに持ち越さない」は具体的です。
このフィルターを通ると、通常1〜3つのアクションアイテムが残ります。それだけで十分です。
アクションアイテムを実行可能にする3つのルール
ルール1：チームではなく個人に割り当てる 「チームが」ではなく「Tanaka（テックリード）が」と書いてください。複数人が関与する場合は、1人をオーナーにしてください。オーナーは他の人に協力を求める責任を持ちます。
ルール2：完了の定義を含める 「コードレビュープロセスを改善する」は完了の定義がありません。「PRのレビューガイドラインを作成して、次のSprintの初日にチームと共有する」は完了の定義があります。
ルール3：2週間以内に完了できるものだけ含める 2週間以内に完了できないアクションアイテムはプロジェクトです。バックログに追加して、プロジェクトとして扱ってください。
2週間後のチェックイン
次のレトロスペクティブまで待たずに、2週間後（または次のSprintの中間）に短い非同期チェックインを設定してください。
形式はシンプルです。Slackチャンネルまたはドキュメントに投稿してください：
「レトロアクションアイテムのチェックイン：[アクションアイテム1] — 進捗状況は？ [アクションアイテム2] — 進捗状況は？」
各担当者が返信します。完了していない場合は、何が邪魔しているかを1文で書きます。
このチェックインにより、次のレトロスペクティブで「なぜこれができなかったのか」という会話が始まる前に、実行の障壁を早期に発見できます。
レトロスペクティブの健全性を測る指標
レトロスペクティブが機能しているかどうかを判断するシンプルな指標があります：
アクションアイテムの完了率：前回のレトロスペクティブのアクションアイテムのうち、何パーセントが次のレトロスペクティブまでに完了しましたか？70%以上が良い目標です。
繰り返し問題の出現頻度：同じ問題が3回以上連続して出てきた場合、アクションアイテムが機能していないか、根本原因に対処していないかのどちらかです。
参加率と発言の質：毎回同じ2〜3人だけが発言している場合、心理的安全性の問題があるかもしれません。全員が少なくとも1つのことを投稿することを期待するフォーマットを使ってください。
よくある失敗
問題を述べるだけで根本原因を掘り下げない：「コミュニケーションが悪い」はレトロスペクティブのテーマとして役に立ちません。「先週のデプロイについての情報が、関係する全員に届いていなかった。なぜなら〜」は役に立ちます。
10以上のアクションアイテムを作る：多すぎるアクションアイテムは優先順位がないことを示します。3つ以下に絞り込む規律を持ってください。
ファシリテーターが結論を誘導する：ファシリテーターの仕事は会話を進めることで、答えを出すことではありません。「これが問題だと思います」と言い始めたら、ファシリテーターの役割を放棄しています。
問題のあるレトロスペクティブを決して実施しない：レトロスペクティブが不快だからといって避けることが最悪の失敗です。問題のあるレトロスペクティブこそ、最も必要なレトロスペクティブです。
次のステップ
次のレトロスペクティブの前に、前回のアクションアイテムのリストを探してください。存在しない場合は、それ自体が最初のアクションアイテムです。
存在する場合は、各アイテムの状況を確認してください。完了しているものはいくつありますか？完了していないものの理由は何ですか？
このレビューからレトロスペクティブを始めてください。その10分間が、次の1時間で何を変えるかを決定します。
