始める前に合意しておく一文
ふりかえり文化の古典であるノーマン・カースの『プロジェクト・レトロスペクティブ』(2001)は、始める前に全員が一つの前提に合意するよう求めます。何を発見しようとも、各自がその時点で知っていたこと、持っていた技術、与えられた資源と状況の中で最善を尽くしたと心から信じる、というものです。ふりかえりの基本指針(Prime Directive)と呼ばれる一文です。
これが形式的なきれいごとではない理由があります。ふりかえりが誰かの落ち度を裁く場になった瞬間、人は問題を口にする代わりに隠し始めます。次の回からは本当の問題がテーブルに上がってきません。非難の禁止は優しくしようという話ではなく、ふりかえりに使うデータを守る装置です。
Keep・Problem・Try, 3欄の役割
KPT はアジャイル宣言の共著者アリスター・コーバーンのふりかえりワークショップの構成(続けること、繰り返される問題、次に試すこと)から生まれ、日本の開発コミュニティで今の名前として定着した枠組みです。欄が3つしかないので、初めてのチームでも進め方を別途学ぶ必要がほとんどありません。
- Keep: 続けたいこと。うまくいったこととその理由を書きます。
- Problem: 繰り返される問題。1回の出来事ではなくパターンを書きます。
- Try: 次の期間に試すこと。Problem から選んで実験に変えます。
Keep を最初にやる理由
うまくいったことから話すのは、場を和ませるためではありません。うまくいったことの大半は偶然ではなく誰かの再現可能な行動であり、明示しておかないと次の期間に音もなく消えるからです。障害を共有チャンネルに早く上げたら対応が速かったのなら、それは褒め言葉の材料ではなく維持すべきプロセスです。
Keep が毎回空になるチームは、基準を高く取りすぎている可能性が高いです。立派な成果でなくても、次もこうしたいと思えるものはすべて Keep です。
Problem は人ではなくやり方に向ける
同じ問題でも、書き方次第でふりかえりは生きも死にもします。名前が主語の文は非難になり、やり方が主語の文は改善の対象になります。形容詞を取り除いて測れる事実に置き換えるのもコツです。
Try は決意ではなく実験
ふりかえりが言いっぱなしで終わるのはここです。もっとコミュニケーションを取ろう、丁寧にやろうといった Try は何も変えません。よい Try は実験の形をしています。何を、いつまで、どう確認するかがあって初めて、次のふりかえりで続けるか捨てるかを判定できます。
数も重要です。Try を5個選ぶチームは、たいてい一つも守れません。いちばん痛い Problem を一つ選び、実験1、2個に絞りましょう。ふりかえりを重ねるほど、チームには検証を通過したルールが一つずつ積み上がります。それがふりかえりの成果物です。
60分の進行表
初めて導入するチームなら60分で十分です。付箋でも共有文書でも、各自が黙って書く時間と一緒に見る時間を分けるのがコツです。
| 時間 | やること |
|---|---|
| 最初の5分 | 前回の Try がどうなったかを確認 |
| 10分 | Keep を各自書き、続けて一緒に読む |
| 20分 | Problem を各自書き、似たものをまとめて一番痛いものに投票 |
| 20分 | 選ばれた Problem を Try の実験に変える(担当・期限つき) |
| 最後の5分 | 記録を整理し、次回の日付を確定 |
よくある質問
ふりかえりはどのくらいの頻度でやるのがいいですか?
スプリントで働くチームならスプリントの終わりごと、そうでなければ2週間に1回が無難です。大きな事故のときだけふりかえりを開くと、ふりかえりという言葉が詰問と同義になってしまいます。普段から短く頻繁にやるチームほど、問題が小さいうちにつかまえられます。
リモートチームではどう進めますか?
同じ文書を開き、各自が書く時間をタイマーで明示的に区切れば、対面とほぼ同じように回ります。静かなチームなら、書く段階は匿名にして議論から名前を出す方法もあります。ビデオ会議の沈黙が気まずくて書く段階を飛ばすのが、リモートふりかえりの一番よくある失敗です。
毎回同じ Problem が出てきます。
二つに一つです。Try が実験に落ちず何も変わらなかったか、チームの権限の外にある問題でふりかえりでは解けないか。前者なら Try をもっと小さく刻み、後者ならふりかえりの記録にチーム外の課題と印を付けて、権限のある人に届けるところまでをふりかえりの仕事にしてください。同じ問題を3回目に書いているなら、必要なのはふりかえりではなく別のチャンネルです。