KPTとは？開発チームの振り返りをスプリントで機能させる進め方・ツール連携・判断

KPTは、Keep（続けること）・Problem（困っていること）・Try（次に試すこと）の3枠で振り返りを整理するフレームワークです。読み方は「ケプト」または「ケーピーティー」。もともとシステム開発の現場で生まれ、アジャイル開発やスクラムのスプリント振り返り（レトロスペクティブ）に広く根づいてきました。ただ、枠を埋めるだけの会にしてしまうと、Problemが愚痴で終わり、Tryが宙に浮いて何も変わらない——という失敗も起こりがちです。

この記事は、KPTの言葉の定義よりも一歩先、開発チームがスプリントの中でKPTを運用し、Tryを実行可能な開発課題として追跡し続けるための実装・運用設計に焦点を当てます。用語のやさしい入門は姉妹記事のKPT法とは何か（初心者向け完全ガイド）にゆずり、本稿は現場で回すための解像度で解説していきます。

まとめ：KPTは「Tryの追跡」まで設計して初めて改善が回る

先に結論を置きます。KPTの成否を分けるのは、KeepやProblemの数ではなく、Tryを担当者・期限つきの開発課題に変換し、次のスプリントで結果を確認できる状態にするかどうかです。振り返りの場で決めたTryをBacklogやJiraのチケットに落とし、翌スプリントのKeep/Problemで「あのTryはどうなったか」を最初に点検する。この閉じたループができれば、KPTは会議のための会議から、チームの改善エンジンへ変わります。

• 実施タイミング：各スプリント末に固定枠で。1回15〜30分（時点の目安）を上限に短く回す。
• 順序：Keep→Problem→Tryが基本。前回Tryの検証を冒頭に置くと形骸化しない。
• Tryの扱い：担当者と期限を付け、開発課題（チケット）として残す。数は2〜3件に絞る。
• 向く場面：継続的に走る開発チーム。向かない場面は単発PJや1〜2名の少人数。

KPTとは何か｜Keep・Problem・Tryの3枠で振り返る手法

KPTは、振り返りの論点を次の3つに分けて可視化します。感情論や犯人探しに流れやすい振り返りを、事実と行動の言葉に翻訳するための枠組みだと捉えると扱いやすくなります。

ポイントは、KeepとProblemを「事実ベース」で書き、Tryを「次スプリントで検証できる粒度」まで具体化することにあります。Problemに「コミュニケーション不足」と書いても動けません。「仕様確認の返信が翌日になり待ち時間が発生した」まで解像度を上げると、Tryが自然と決まります。

開発チームのスプリント振り返りにKPTが選ばれてきた3つの背景

振り返り手法は数多くありますが、開発チームがKPTを選ぶ理由は主に3つです。第一に、枠が3つだけで学習コストが低く、新メンバーが入っても運用が崩れにくい。第二に、Keep（承認）とProblem（課題）を並べることで、心理的安全性を保ちながら課題を出せる。第三に、Tryという「行動」で締めるため、次のスプリントのSDLC（開発ライフサイクル）の反復に改善が直接つながります。

スクラムのレトロスペクティブは「検査と適応」を目的にしたイベントであり、KPTはその器としてよく噛み合います。DevOpsが掲げる継続的改善の文化を、チーム単位の小さな習慣に落とし込む道具——それがKPTの立ち位置だと考えると、運用の狙いがぶれません。

KPTの進め方｜スプリント末に実施する具体的な手順を工程で解説

実際の回し方を、時間配分つきの工程で示します。数値は15〜30分枠を想定した目安（時点の一例）で、チーム規模に応じて調整してください。

工程1｜前回のTryの検証から始めて振り返りの空中分解を防ぐ

最初の3〜5分で、前スプリントのTryが実行されたか、効果はどうだったかを確認します。ここを飛ばすとTryが「言いっぱなし」になり、KPTは急速に形骸化します。効果があったTryはKeepへ昇格、効果が薄ければProblemとして再検討する、という交通整理をこの段階で済ませておきましょう。

工程2｜KeepとProblemを事実ベースで並べて論点を絞る

各自が付箋やオンラインボードにKeep・Problemを書き出し、5〜10分で共有します。ファシリテーターが担うのは「誰が悪いか」ではなく「何が起きたか」への言い換えを促す役割。似た項目はその場でグルーピングし、議論の対象を絞り込みます。人ではなく事象に矢印を向けるのがコツです。

工程3｜Tryを担当者と期限つきの開発課題へ確実に書き換える

Problemの中から、次スプリントで手を打つものを2〜3件選び、Tryへ変換します。ここで必ず担当者と期限を決め、コードレビューの運用改善のように、既存の開発プロセスへ組み込める形にします。「全員で気をつける」は担当者不在のため実行されません。Tryは主語を1人に絞ると動き出します。

KPTのTryをBacklogやJiraと連携し開発課題として追跡する

KPTが続くかどうかは、振り返りとチケット管理をつなげられるかにかかっています。ホワイトボードやMiroに書いたTryは、会議が終わると忘れられがちです。Tryをそのままバックログの改善チケットとして登録し、次スプリントの計画に乗せる仕組みを作ると、改善が業務フローの中で自走します。

• チケット化：Tryを1件1チケット。ラベルに「retro」を付け抽出しやすくする。
• 可視化：進行中Tryを専用ボードやスイムレーンで常時見える化する。
• 点検：翌スプリントのKPT冒頭でチケットの状態を確認し、完了・継続・破棄を判断。

受託開発の現場では、KPTで生まれた改善サイクルを納品後も内製チームが回し続けられるかが、長期の運用品質を左右します。改善プロセスの定着や内製化そのものを支援する体制が必要なら、保守運用・内製化支援サービスの枠組みが参考になります。ツール連携と運用ルールをセットで設計しておくと、担当者が代わってもKPTが途切れません。

KPTがうまくいかない開発現場でよくある失敗パターンと処方箋

KPTが「意味のない会議」になる原因は、だいたい決まっています。代表的なアンチパターンと処方箋を整理します。

とりわけ多いのがTryの放置です。決めたのに翌週へ引き継がれず、同じProblemが毎回並ぶ。これを防ぐ最短の一手が、前述のチケット化と冒頭点検の習慣づけになります。逆に、Keepを軽視して課題ばかり並べるチームは、振り返り自体が苦痛になり参加率も落ちていく。良かった動きへの承認を先に置くだけで、場の空気は変わります。

KPTを採用すべき現場と他の振り返り手法へ切り替える判断基準

ここは筆者の判断を言い切ります。KPTは万能ではなく、向き不向きがはっきりした手法です。以下の条件に照らして採否を決めてください。

KPTを採用すべき現場：スプリントやイテレーションを継続的に回す3名以上の開発チーム。定例の振り返り枠が確保でき、Tryをチケットとして追跡できる体制があるなら、KPTは第一候補になります。学習コストの低さから、立ち上げ期のチームにも据えやすい。

他手法へ切り替えるべき場面：課題出しより「学びや事実の時系列整理」を重視したいなら、Fun・Done・Learnやタイムライン型が噛み合います。個人の週次振り返りにはYWT（やったこと・分かったこと・次にやること）が軽量です。原因を深掘りしたい重大インシデントの振り返りには、KPTより「なぜなぜ分析」を組み合わせる方が向きます。KPTにアクション管理を強化したKPTA（Action追加型）へ発展させる手もあります。

迷ったら、まずKPTで始めるのが現実的です。3枠のシンプルさゆえに導入の失敗が少なく、チームの成熟に応じてKPTAや他手法へ育てていけます。手法の乗り換えを目的化せず、Tryが実行され改善が積み上がっているかを唯一の判断軸にしてください。

よくある質問

KPTの読み方と意味を簡潔に教えてもらえますか？

読み方は「ケプト」または「ケーピーティー」です。Keep（続けたいこと）・Problem（課題）・Try（次に試すこと）の頭文字で、振り返りの論点を3枠に分けて整理するフレームワークを指します。

KPTはどのくらいの頻度で実施すべきですか？

スプリントやイテレーションの区切りごと、つまり1〜2週間に1回が基本です。間隔が空くと事実の記憶が薄れ、Tryの検証もしにくくなります。短い周期でこまめに回す方が改善は積み上がります。

KeepとProblemがうまく出ないときはどうすればよいですか？

抽象語で止まっているサインです。「何が」「いつ」「どう困ったか」を具体的な出来事まで書き下してみてください。事実の粒度が上がると、KeepもProblemも自然に言葉になり、Tryへ変換しやすくなります。

Tryが毎回実行されずに終わってしまうのはなぜ？

担当者と期限が決まっていないか、チケット化されていない可能性が高いです。Tryを2〜3件に絞り、1件ずつ主語を1人に固定してバックログに登録し、次回KPTの冒頭で状態を点検する運用にすると改善します。

KPTとレトロスペクティブの違いは何ですか？

レトロスペクティブはスクラムにおける「振り返りイベント」そのものの総称で、KPTはそのイベントを進めるための具体的な手法（型）の一つです。レトロという場をKPTという型で運営する、という関係だと整理できます。

関連記事

• KPT法とは何か｜初心者向け完全ガイド（基礎から知りたい方へ）
• SDLCとは｜ソフトウェア開発ライフサイクルの工程とモデル
• DevOpsとは｜開発と運用を統合する実践とツール
• コードレビューとは｜目的・観点と現場の運用設計