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

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

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

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

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

• 実施タイミング：各スプリント末に固定枠で。1回15〜30分（時点の目安）を上限に短く回す。
• 順序：Keep→Problem→Tryが基本。前回Tryの検証を冒頭に置くと形骸化しない。
• Tryの扱い：担当者と期限を付け、開発課題（チケット）として残す。数は2〜3件に絞る。
• チケット化の手段：BacklogならPOST api/v2/issues、JiraならPOST rest/api/3/issue。どちらもcurl 1行で自動化できる。
• 効果測定：Try実行率（完了Try÷起票Try）を毎スプリント数え、50%を切ったらTryの粒度を疑う。
• 向く場面：継続的に走る開発チーム。向かない場面は単発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が入る器はスプリントレトロスペクティブです。スクラムガイド（2020年11月版）は、このイベントの目的を「品質と効果を高める方法を計画すること」と定め、個人・相互作用・プロセス・ツール・完成の定義について直前のスプリントを検査すると書いています。タイムボックスは1か月のスプリントで最大3時間、そしてこのイベントがスプリントを終結させる、とも明記されています。日本語版のPDFも同じ版で公開されているため、チーム内の用語をそろえるときは原文にあたるのが早いでしょう。

2週間スプリントなら按分して1時間半前後が上限の目安ですが、実務では15〜30分に収めるチームが多数派です。アジャイルソフトウェア開発宣言の背後にある原則も、チームが定期的に振り返って自分たちのやり方を調整することを原則の1つに挙げています。スクラムの枠組みを先に押さえたい場合はスクラム開発とはから戻ってくると、レトロスペクティブの位置づけがつかみやすくなります。

もう1つ、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ボードのテンプレートを先に用意して書き出しの迷いを消す設計

KPTが15分で終わるチームと、45分かけても何も決まらないチームの差は、当日の司会力ではなく事前のテンプレートにあります。白紙のボードを前に「Keepを書いてください」と言われると、人は何を書いてよいか迷い、抽象語に逃げがちです。列の並び順・記入例・必須項目をあらかじめ固定しておけば、書き出しの5分がそのまま議論の材料になります。

下のテンプレートは、リポジトリの docs/retro/ にMarkdownで置き、スプリントごとにコピーして使う前提で組んだものです。冒頭に前回Tryの検証欄を置くこと、Tryに担当者と期限の記入欄を最初から用意することの2点が効きます。

# スプリント 2026-09-15 KPT

## 0. 前回Tryの検証（3分）
- [x] レビュー担当を当番制にする ... 効果あり → Keepへ昇格
- [ ] 仕様確認は必ずスレッドで行う ... 未実施 → Problemへ差し戻し

## 1. Keep（事実で書く。数値があれば添える）
- 朝会が9分で終わった（前スプリント平均14分）
- リリース手順書のとおりに新メンバーが単独でデプロイできた

## 2. Problem（事実で書く。人ではなく出来事を書く）
- 仕様確認の返信が翌日になり、着手が1日遅れた
- テスト環境のDBが週2回落ち、そのたび30分止まった

## 3. Try（2〜3件に絞る。担当者と期限は必須）
- [ ] 仕様確認は当日中に一次返信する 担当:sato 期限:2026-09-26
- [ ] テスト環境のDB監視をSlackへ通知する 担当:tanaka 期限:2026-09-26

チェックボックス形式にしておくと、次回の工程1で「未チェックのまま残ったTry」を目視で拾えます。オンラインホワイトボードやカンバンを使う場合も列の定義は同じで構いません。むしろツールを変えてもテンプレートを変えないほうが、担当者交代時の引き継ぎコストが下がります。

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

KPTが続くかどうかは、振り返りとチケット管理をつなげられるかにかかっています。ホワイトボードやオンラインボードに書いたTryは、会議が終わると忘れられがちです。Tryをそのままバックログの改善チケットとして登録し、次スプリントの計画に乗せる仕組みを作ると、改善が業務フローの中で自走します。バックログ側の考え方はプロダクトバックログとは何かで整理していますので、Tryを機能開発と同じ列に並べるかどうか迷ったら参照してください。

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

ここから先は、手作業のコピーペーストをやめてAPIで起票する手順を示します。KPTの終わり際にコマンドを1本叩けばTryがチケットになる状態にしておくと、「議事録には残ったがチケットにならなかった」という取りこぼしが消えます。

Backlog APIでTryを課題として起票するcurlコマンドを書く

Backlogでは課題の追加APIがPOST api/v2/issues として公開されています。必須パラメータは projectId・summary・issueTypeId・priorityId の4つで、期限日は dueDate（yyyy-MM-dd形式）、カテゴリは categoryId[]、マイルストーンは milestoneId[] で指定可能です。認証は認証ドキュメントのとおり apiKey をクエリパラメータで渡す方式が最短で、社内アプリとして配布するならOAuth 2.0のAuthorization Code Grantにも対応しています。

# TryをBacklogの課題として起票する（必須4項目＋期限＋カテゴリ）
curl -X POST "https://example.backlog.jp/api/v2/issues?apiKey=$BACKLOG_API_KEY" \
  -d "projectId=12345" \
  -d "summary=Try 仕様確認は当日中に一次返信する" \
  -d "issueTypeId=67890" \
  -d "priorityId=3" \
  -d "categoryId[]=222" \
  -d "dueDate=2026-09-26" \
  -d "assigneeId=98765"

issueTypeId と priorityId はプロジェクトごとに値が変わるため、初回だけ課題種別と優先度の一覧APIで実IDを引いて、シェルスクリプトの定数に固定してしまうのが運用としては軽くなります。カテゴリに「retro」を1つ作って categoryId[] に固定すると、後述の抽出と集計が一気に楽になるでしょう。

Jira Cloud REST APIでTryチケットを作り期限を入れる

Jira Cloudの場合はIssuesのグループにある課題作成エンドポイントを使います。認証はBasic認証のドキュメントが示すとおり、メールアドレスとAPIトークンの組み合わせをBase64エンコードしてAuthorizationヘッダーに載せる方式で、curlなら -u オプションに「メールアドレス:APIトークン」を渡せば済みます。パスワードでの認証はすでに使えません。

つまずきやすいのは説明欄です。Jira Cloudでは、課題のコメントやテキストエリア系のフィールドがAtlassian Document Format（ADF）として保存されます。ルートノードは type が doc、version が 1、content が配列という構造で、REST API v3の description もこの形で渡します。下の例はその構造に合わせたものです。

# Jira Cloud: TryチケットをADF形式の説明つきで作成する
curl -X POST "https://your-domain.atlassian.net/rest/api/3/issue" \
  -u "$JIRA_MAIL:$JIRA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "fields": {
      "project":   { "key": "RETRO" },
      "issuetype": { "name": "Task" },
      "summary":   "Try 仕様確認は当日中に一次返信する",
      "labels":    ["retro", "sprint-2026-09-15"],
      "duedate":   "2026-09-26",
      "description": {
        "type": "doc",
        "version": 1,
        "content": [
          { "type": "paragraph",
            "content": [
              { "type": "text",
                "text": "2026-09-15のKPTで決めたTry。翌スプリント冒頭で結果を点検する。" }
            ] }
        ]
      }
    }
  }'

labels にスプリント名を入れておくと、どの回の振り返りで生まれたTryかを後から復元できます。Jiraそのものの操作に不慣れなメンバーがいるなら、Jiraの使い方と基本機能を先に共有しておくと、作業項目とエピックの関係で混乱せずに済みます。

未完了のTryを翌スプリント冒頭で一覧に引き出す抽出条件の作り方

工程1の「前回Tryの検証」を人の記憶に頼ると、必ず抜けが出ます。Backlogの課題一覧取得APIはGET api/v2/issues で、projectId[]・statusId[]・categoryId[]・keyword・count・sort・order・offset といった絞り込みを利用可能です。既定構成のステータスID（1が未対応、2が処理中）とretroカテゴリを組み合わせれば、未完了のTryだけを機械的に取り出せます。

# 未完了のTryだけを期限の近い順に並べる（count は1回100件まで）
curl -s "https://example.backlog.jp/api/v2/issues?apiKey=$BACKLOG_API_KEY&projectId[]=12345&categoryId[]=222&statusId[]=1&statusId[]=2&count=100&sort=dueDate&order=asc" \
  | jq -r '.[] | [ .issueKey, .summary, (.assignee.name // "未割当"), (.dueDate // "期限なし") ] | @tsv'

この出力をKPT開始時にそのまま画面共有すれば、工程1は3分で終わります。担当者が「未割当」、期限が「期限なし」で出てきたTryは、その場で潰すか破棄するかを決めてください。この2つが空のままのTryは、経験上ほぼ実行されません。

GitHub Projectsの組み込み自動化でTryの状態を同期する

チケット管理をGitHubに寄せているチームなら、Projectsの組み込みワークフローでTryの状態遷移を自動化できます。組み込み自動化のドキュメントによると、既定のワークフローには、IssueやプルリクエストがクローズされたときにStatusをDoneへ、プルリクエストがマージされたときにDoneへ、アイテムが追加されたときにTodoへ設定する動きが用意済みです。さらにAuto-addを使えば、フィルタ条件に一致したアイテムをリポジトリから自動でボードへ流し込めます。

運用としては、Try起票時にretroラベルを付け、振り返り用Projectのフィルタを「label:retro」にしておくだけで十分です。Tryを解決するプルリクエストがマージされた時点でStatusがDoneへ動くため、KPT冒頭の点検で見るのは「Doneに移らなかったTry」だけになります。コード変更を伴うTryの追跡精度を上げたいなら、JiraとGitHubを連携する方法の課題キー埋め込みやスマートコミットも同じ考え方で効きます。

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

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

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

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

もう1つ見落とされがちなのがTryの肥大化です。「テスト自動化を進める」のようなTryは1スプリントでは終わらず、翌回も翌々回も未完了のまま並び続けます。ここはアジャイル開発が失敗する5つの原因で挙げた「粒度の合わない計画」と同じ構造で、Tryも1スプリントで完了判定できる大きさまで割ってから起票するのが処方箋になります。

KPTの効果を数字で確認するために取る指標と集計スクリプトの例

KPTを半年続けたとして、それが効いているかどうかを感覚で語ると議論が止まりません。チケット化まで設計してあれば、改善の進み具合はAPIから機械的に数えられます。見る指標は多くする必要がなく、次の3つで足ります。

Tryの実行率とリードタイムをチケットから機械的に数える集計手順

Backlogのretroカテゴリに揃えてあるなら、期間を切って取得し、jqで数えるだけで済みます。下は前スプリント（2026-09-01から2026-09-15まで）に起票したTryの実行率を出す例です。ステータスIDの4は既定構成の「完了」を指します。

# 前スプリントに起票したTryの実行率を数える
curl -s "https://example.backlog.jp/api/v2/issues?apiKey=$BACKLOG_API_KEY&projectId[]=12345&categoryId[]=222&createdSince=2026-09-01&createdUntil=2026-09-15&count=100" \
  | jq '{
      起票: length,
      完了: ( [ .[] | select(.status.id == 4) ] | length ),
      実行率: ( ( [ .[] | select(.status.id == 4) ] | length ) * 100 / length | floor )
    }'

目安として、Try実行率が3スプリント続けて50%を割るなら、原因はチームの怠慢ではなくTryの粒度か担当者配分にあります。逆に実行率が常に100%なら、Tryが安全すぎて改善幅が小さい可能性を疑ってください。リードタイムは created と updated の差分で近似でき、期限より先に伸びるTryが常態化しているなら、スプリント計画でTryの工数を積んでいないサインだと読めます。

Problem再出現率だけは自動化しにくく、四半期に一度、過去のボードを並べて同じ文言を数える手作業が現実的です。同じProblemが3回以上出ているなら、スプリント内の工夫では解けない構造的な課題として、体制やアーキテクチャの側へ持ち上げる判断材料になります。

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の冒頭で状態を点検する運用にすると改善します。BacklogならPOST api/v2/issues の1行で起票まで自動化できます。

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

レトロスペクティブはスクラムにおける「振り返りイベント」そのものの総称で、KPTはそのイベントを進めるための具体的な手法（型）の一つです。レトロという場をKPTという型で運営する、という関係だと整理できます。スクラムガイド2020年11月版は、このイベントを1か月のスプリントで最大3時間のタイムボックスと定めています。

KPTとKPTAの違いはどこにありますか？

KPTAは、KPTの3枠にAction（誰が・いつまでに何をするか）の欄を足した型です。Tryは「試すこと」の宣言にとどまりやすいため、実行責任を分けて書かせることで放置を防ぐ狙いがあります。Tryをチケット化して担当者と期限を必ず埋める運用にしているなら、実質的にKPTAと同じ効果が出ているため、無理に型を移す必要はありません。

オンラインでKPTを回すときに崩れやすいのはどこですか？

沈黙の扱いと、ボードの持ち帰りの2点です。対面なら付箋を書く手が見えますが、オンラインでは書けていない人が可視化されません。書き出し時間を明示的に5分タイマーで区切り、全員が書き終えてから共有へ移す進行にすると解決します。もう1つ、オンラインボードは会議終了と同時に閲覧されなくなるため、Tryだけはその場でチケットへ移し、ボード自体はリポジトリのMarkdownに残す運用が堅いでしょう。

関連記事

• KPT法とは何か｜初心者向け完全ガイド（基礎から知りたい方へ）
• スクラム開発とは｜進め方・役割とメリット・デメリット
• プロダクトバックログとは｜定義・役割とスプリントバックログとの違い
• Jiraの使い方と基本機能｜作業項目・エピック・ボードを実務目線で解説
• SDLCとは｜ソフトウェア開発ライフサイクルの工程とモデル
• DevOpsとは｜開発と運用を統合する実践とツール
• コードレビューとは｜目的・観点と現場の運用設計