KPTとは？振り返りの進め方と書き方の例【テンプレート付き】

KPTとは、続けたいことをKeep、困ったことをProblem、次に試すことをTryに分けて振り返る手法です。会議で意見を並べるだけでなく、次の仕事の進め方を変えるために使います。開発チームのスプリント終了時や、マーケティング施策の節目などに取り入れられます。

この記事では、初めて進行する人向けに、記入例と45分の進め方を紹介します。時間配分、人物、件数は説明用の架空例です。

KPTの3項目と、書き分ける基準

「連携が悪い」だけでは改善対象が曖昧です。どの受け渡しで何が起き、誰の次の作業に影響したのかまで書きます。Keepも「頑張った」で終えず、効果があった行動を残すと再現しやすくなります。

KPTは振り返りの書式の一つです。スクラムにおける振り返りの目的は、品質とチームの有効性を高める改善を考えることです。書式そのものが必須ルールではありません。Scrum.orgのレトロスペクティブ解説でも、その目的が説明されています。

45分で実施する進行例

1. 最初の5分で対象期間、目標、前回Tryの結果を確認します。
2. 次の7分は全員が黙ってKeepとProblemを書きます。最初から順番に発言させると、先に出た意見へ寄りやすくなります。
3. 10分で似た内容をまとめ、当事者に事実を補足してもらいます。
4. 8分で今後への影響とチームで変えられる範囲から、扱う問題を選びます。
5. 10分でTryを決め、最後の5分で担当、期限、確認方法を読み合わせます。

件数の多さを成果にせず、実行できるTryを1〜2件に絞る方法から始めてください。深刻な障害の原因究明は、別の時間を確保する方が適切な場合もあります。

そのまま使える記入テンプレート

以下の表をチームの共有文書へコピーし、空欄を埋めて使えます。改善の実施と効果の確認を分けておくことがポイントです。

「担当を決めたから完了」とせず、試した結果まで確認します。承認待ちが減っても差し戻しが増えたなら、速度だけで成功と判断せず、依頼時の情報を見直す必要があります。

KPTが形だけになる原因と直し方

毎回同じProblemが出るときは、前回のTryが実施されたか、実施しても効かなかったかを分けます。未実施なら担当や時間の確保、効果がなければ原因の捉え方を見直します。

発言が少ないときは、事前記入や匿名の意見収集を試します。ただし、誰にどこまで共有するかを最初に決めてください。個人の評価の場にすると、問題が隠れやすくなります。

Tryが「意識する」「徹底する」だけなら、観察できる動作に変えます。「確認を徹底する」なら、「公開前チェックに計測画面の確認欄を追加し、確認者を記録する」と具体化できます。

KPTとほかの振り返り手法の使い分け

事実と次の行動を簡潔に整理したいならKPTが向きます。学びや感情を丁寧に拾いたい場合は、レトロスペクティブとは？振り返りの進め方とフレームワーク7選で紹介する別のフレームワークも候補になります。スクラム全体の流れはスクラムとは？スクラム開発の進め方・役割・イベントを図解を参照してください。

KPTは毎日行うべきですか？

頻度は仕事の区切りと、改善を試す時間から決めます。毎日短く実施する運用もありますが、前回のTryを試せないほど会議を増やす必要はありません。

TryはProblemからしか作れませんか？

Keepを別の業務に広げるTryも有効です。問題を減らす視点と、良かった行動を再現する視点の両方を持ちます。

振り返りを次のタスクにつなげる

会議後は、Tryを実際の作業計画へ移し、次回の冒頭で結果を確認します。Xtrategyのプロジェクト管理では、施策のタスク進行、コスト、承認状況をプロジェクト単位で確認できます。振り返りで出た改善を、日々の施策管理と結び付ける際に機能を確認してみてください。