振り返りで付箋が並んでも、次の二週間に何も変わらない。そんなKPTなら、参加者が「また同じ話をするだけ」と感じるのも自然です。
この場面では、たくさんのTryを採用するより、次の期間に試せる変更を一つ選び、結果を見に行くことを優先します。 KPTはKeep（続けたいこと）、Problem（困ったこと）、Try（試すこと）を話すための枠です。Problemを人の反省文にしないことも大切です。
以下は架空の問い合わせ管理アプリの改修チームが、件名の上限修正を終えた後に行う振り返りです。
会議の前に、事実を一枚に置く
「今回はレビューが遅かった」と言う前に、どの変更で、いつ、何が待ちになったかを確認します。
| 事実 | 記入例 |
|---|---|
| 対象期間 | 9月10日〜23日、件名の入力条件とAPIエラー表示の改修 |
| できたこと | 100文字／101文字の境界テストを追加し、リリースした |
| 待ちが起きたこと | 空白だけの件名の扱いが未決で、実装とレビューが各1日止まった |
| 初めて分かったこと | 画面とAPIが異なる入力条件を使っていた |
これは参加者を裁くための記録ではありません。「レビュー担当が悪い」のような言い方にすると、改善できる作業の流れが見えなくなります。未決の仕様をどの時点で誰に持ち込むか、という問いに変えます。
KPTの記入例
| 欄 | このチームの記入例 | 会話で確かめること |
|---|---|---|
| Keep | 境界値100／101文字をテスト表で共有したので、画面とAPIを同じ条件で確認できた | 次回も作業前に境界値を置けるか |
| Problem | 空白だけの件名をどう扱うか未決のまま着手し、レビュー時に初めて分かった | どの時点なら仕様担当へ相談できたか |
| Problem | 画面とAPIの条件が別実装で、片方の変更が見落とされた | どの資料やテストなら差を見つけられたか |
| Try候補 | 着手前に入力例と境界値を仕様担当へ見せる | 準備の負担はどれくらいか |
| Try候補 | 画面とAPIの条件を同じテスト表で確認する | 一覧を維持できるか |
この表ではProblemを二つ出しましたが、同時に二つの運用を変える必要はありません。今回は「未決条件がレビューで初めて見つかった」ことを先に扱います。理由は、次の入力項目追加が予定されており、すぐ試せるからです。
Tryを実験として一つに絞る
試すこと：入力項目の改修に着手する前に、担当エンジニアが「空・空白だけ・上限・上限超過」の例を1枚にし、仕様責任者と15分確認する。
担当：次の入力項目改修の担当エンジニアA。仕様責任者Bが回答する。
期限：次の改修着手前日まで。
確認すること：実装中・レビュー中に未決条件で止まった回数と、その条件がいつ発見されたか。
見直す日：次回の二週間の振り返り。
15分で全仕様を決め切る必要はありません。決められない条件が見つかったら、決定者と期限を残すだけでも、実装者が黙って推測する状態を減らせます。次回の振り返りで待ちが減らなければ、確認会の時間や参加者を変えます。効果がなければTryをやめる判断もできます。
Atlassianの振り返りガイドも、意見の優先付け、担当者と期限のある行動、次回までの実行を重視しています。ここでの一件に絞る方法は、負担を小さくして効果を確認するための編集上の提案です。
発言しやすさと、決定の責任を両立する
KPTを議題にしても、参加者が言いにくいことを安全に言えるとは限りません。司会は一人の発言を結論にせず、各自が先に書く時間を設けます。個人の行動だけをProblemにせず、情報や権限の流れを聞きます。ただし決めたTryには担当者を置きます。責任を曖昧にしないことと、犯人探しをしないことは両立します。
チームの問題が繰り返される背景まで考えるなら、『エンジニアリング組織論への招待』の出版社紹介が参考になります。上記のKPT例は本からの引用ではありません。リーダー候補の本棚（Amazon・アフィリエイトを含みます）にも載せています。
次のKPTでは、最後の5分を使い、Tryを一つ・担当を一人・見直す日を一つ決めてみてください。次回、その結果から続けるか変えるかを話せます。
