KPTとは？チームの振り返りから次に試す行動を決める方法

KPTは、Keep（続けたいこと）、Problem（問題だったこと）、Try（次に試すこと）の三つで活動を振り返る枠組みです。IPAのワークショップ資料でも、この順に振り返る方法として紹介されています。IPA：KPTの参考説明（資料30ページ）

チームで使うなら、三つの欄を埋めた後に「誰が、どの場面で何を試し、次回何を確かめるか」まで決めてみましょう。この記事では、開発やインフラ運用の振り返りで使える進め方と、Tryを選ぶ判断表を提案します。以下の記入例は説明用で、特定企業の実績ではありません。

KPTの三つの欄には何を書く？

Keepは「良かった」で終わらず、次にも再現したい行動を残す欄として使いましょう。Problemには人物の評価ではなく、起きた場面と困った内容を書きます。TryはProblemへの対策だけでなく、Keepを別の作業でも試す案にしても構いません。

スクラムガイドでは、スプリントレトロスペクティブの目的を、品質と有効性を高める方法を計画することとしています。KPTを使う際も、次の行動まで話し合うという観点を参考にできます。Scrum Guide：Sprint Retrospective

KPTの進め方：対象をそろえてからTryを選ぶ

以下は本記事の進行案です。時間や件数を固定のルールとせず、チームの規模と対象業務に合わせて調整してください。

1. 振り返る期間・業務・前回のTryを確認する

「直近の開発期間」「今回の運用引き継ぎ」など、対象を最初にそろえます。前回のTryがある場合は、実行したか、何が分かったか、まだ分からないことは何かを先に確認します。

未実施のTryをそのまま積み増す前に、着手できなかった理由を確かめましょう。時間が足りなかったのか、対象の作業が発生しなかったのかで、次の扱いを変えます。

2. KeepとProblemを各自で書き出す

最初に各自で書く時間を取り、一つの項目には一つの出来事を書きます。「連携が悪い」だけなら、進行役が「どの受け渡しで、何の情報が足りなかったか」を聞いて具体化します。

事実と原因の推測も分けます。例えば「依頼後、希望日までにレビューされなかった」が確認できた出来事なら、「担当者が忙しかった」は本人や記録で確認するまで仮説として扱います。

3. 似た項目をまとめ、扱う論点を選ぶ

同じ受け渡しや作業に関する項目をまとめます。ただし、似た表現でも状況が違う場合は分けて残してください。発言の数だけで決めず、業務への影響と、自分たちが変更できる範囲を確認します。

4. Try候補から、今回試す行動を決める

最初は一つのTryから始める案もあります。次回までに実行し、結果を持ち寄れる大きさに絞ってください。採用しなかった案は削除せず、保留理由と見直す条件を記録します。

Tryを選ぶ判断表

Tryは、実行する場面と確認方法を説明できるかで選んでみましょう。次の表は、候補を実行・調査・相談に分けるための判断案です。

「レビューを早くする」は目指す状態です。Tryとして記録する際は、「依頼者が希望期限と理由を記入する」のように動作へ落とし込みます。速くなるかどうかは実施後に確かめ、効果を先に決めつけないようにしましょう。

そのまま使えるKPT・Tryの記入例

以下は、運用引き継ぎを題材にした架空の例です。担当者名や確認日は、実際の会議で決めた値に置き換えてください。

担当者は、その人だけが改善責任を負う意味ではなく、実施や記録の持ち寄りを確認する役割として決めます。実行に他のメンバーの協力が要る場合は、その分担も残してください。

次回は「実施した」と「役立った」を分けて判断する

次の振り返りでは、Tryを完了扱いにする前に、実施の有無と結果を分けて確認します。

例えば引き継ぎの記入欄を追加できても、それだけで担当不明の問題が解消したとは判断しません。確認し直した場面があったか、読み合わせが負担になっていないかも持ち寄ります。

同じProblemが残る場合は、同じTryを繰り返す前に、対象の出来事と原因の仮説を見直してください。障害後に時系列や原因仮説を詳しく整理したい場合は、障害の振り返り方を参照できます。

KPTの会議を終える際は、今回のTry、実施する人、試す時点、次回の確認材料を読み合わせましょう。その記録を次の振り返りの最初に開くところまで予定に入れれば、継続・変更・取り下げの判断に戻れます。