KPT法とは？読み方と3要素の書き方・記入例・テンプレートの作り方

KPT法は、活動を振り返って「Keep（続けたいこと）」「Problem（問題）」「Try（試したいこと）」の3枠に整理する手法です。道具は模造紙と付箋、あるいはスプレッドシートで準備できます。手軽な一方で、Tryだけが積み上がって誰も見返さなくなる、Problemを並べただけの反省会になる、という形で止まりやすい手法でもあります。

この記事では、3要素の書き分けと4ステップの進め方、営業やバックオフィスでの記入例、シートの列構成、機能しなくなったときの立て直し方を扱います。由来についても、検索上位の解説と一次資料を突き合わせた結果を示します。

まとめ｜Tryの絞り込みと次回冒頭での検証

KPT法の成否は、書き出しの丁寧さではなくTryの扱い方で決まります。要点は次の4点です。

• 読みは「けぷと」。KPT法・KPT分析・KPT形式はいずれも同じ手法を指す
• Keepは感想ではなく、次も続けたい行動を「〜する」という動詞の形で書く。天野勝氏の解説がこの書き方を基本としている
• Problemには解決策を書かない。解決策を混ぜると、そのままTryの選択肢が1つに固定される
• 振り返りは前回のTryの確認から始める。書き出しから始めると前回の決定が検証されず、改善が積み上がらない

KPTはスクラムやアジャイル開発の専用手法ではなく、営業でも経理でも個人でも同じ手順で回せます。以降で具体的な書き方と運用を順に見ていきます。

KPT法とは何か｜読み方と3要素が指すもの

KPTは Keep・Problem・Try の頭文字です。天野勝氏が2006年に書いた連載では「思考フレームワークのKPT(Keep/Problem/Try:けぷと)」と表記されており、読みは「けぷと」です。KPT法・KPT分析・KPT形式・KPT方式・ケプト法といった呼び分けが流通していますが、内容に差はありません。

Keep・Problem・Tryの書き分け

3枠の区別があいまいなまま始めると、Keepに感想が並び、Problemに愚痴が並び、Tryに「頑張る」が並びます。同連載は各枠の書き方まで指定しており、そこに従うと翌回に使える記録になります。

Problemの列が分かりにくいかもしれません。「仕様の確認が不十分」という書き方には「仕様を十分に確認する」という解決策がすでに含まれています。原文もこの点を挙げて「Problemを書くときには、『解決策を明示しない』ように注意しましょう」と述べています。事実だけを書いておけば、確認手順を変える、仕様の書き方を変える、レビュー担当を変えるといった複数のTryを比べられます。なお、Problemには現在の問題だけでなく、これから起こりそうだと感じているリスクも書き、前回の未解決分は消さずに残します。

Keepから先に書く理由

3枠のうち書き落とされやすいのがKeepです。問題を挙げる場だと参加者が受け取ると、出てくるのはProblemばかりになります。Keepを先に埋める順序にすると、うまくいっている手順が言語化されて他のメンバーへ移植でき、Problemを出す心理的な負担も下がります。順序を入れ替えるだけで、場の性格が反省から引き継ぎへ寄ります。

KPTの出どころ｜一次資料が示すシート様式の出典

KPTの由来について、日本語の解説記事の多くは「アジャイル開発で生まれた手法」と書きます。ただし出典まで示したものはほとんどありません。Alistair Cockburnの名を出す記事もありますが、記述は「Alistair Cockburn氏の『The Keep/Try Reflection』という手法を元に日本で発展した振り返りフレームワークと言われています」という伝聞にとどまり、書名やページの指定がありません。

2006年の一次資料が示していること

手がかりになるのが、天野勝氏による「ふりかえりガイド[3] - KPTによるふりかえり」（オブジェクト倶楽部メールマガジン、2006年2月8日配信）です。ここではKPTを「改善を行う際に用いる思考フレームワーク」と定義し、シートの様式を次のように説明しています。

「模造紙やホワイトボードを3つの区画に仕切り、左上にKeep（続けたいこと）、左下にProblem（問題）、右にTry（試したいこと）を見出しとして書いた反省シート（Reflectionシート、別名:KPTシート）のフォーマット」を用いるのが一般的である、という記述です。そしてこの「フォーマット」に付けられた脚注が指しているのは、Alistair Cockburn著『アジャイルソフトウェア開発』です。

つまり出典で結び付けられているのは、Cockburnの書籍にある振り返りシートの様式であって、KPTという3文字の呼称や手法そのものの発明ではありません。「CockburnがKPTを考案した」という形の説明は、この帰属を1段跳ばしたものです。発案者を断定できる一次資料は見当たらないため、本記事でも断定しません。

書籍化と、一般業務への広がり

KPTがソフトウェア開発の外へ広がった経路として確認できるのは、天野勝『これだけ！KPT』（すばる舎、2013年8月29日刊、208ページ、ISBN 9784799102756）です。版元の紹介文は「継続（ｋｅｅｐ）」「問題点（ｐｒｏｂｌｅｍ）」「挑戦（ｔｒｙ）」の3つの視点で整理する手法と説明しており、少なくとも2013年には、開発現場に限定しないリーダー向けの解説書が刊行されていたことが分かります。

スクラムガイド2020年版におけるKPTの不在と位置づけ

実務上の誤解も1つ解いておきます。スクラムガイド2020年版の日本語版PDFを全文抽出して数えると、「KPT」という語の出現回数は0回です。スクラムが定めているのはイベントとしてのスプリントレトロスペクティブであり、その目的は「品質と効果を高める方法を計画することである」です。検査する対象や改善の扱いも定められていますが、KPTなどの具体的な進行形式は指定されていません。KPTはその枠に当てはめて使える型の1つという位置づけになります。スクラムの枠組み自体はスクラム開発とは？進め方・役割・メリット・デメリットをわかりやすく解説で整理しています。

所要時間の上限も同ガイドが示しており、「スプリントが1か月の場合、スプリントレトロスペクティブは最大3時間である」と定めています。この上限は1か月のスプリントに対する規定です。一般業務のKPT会議の所要時間は、参加人数と議題に応じて別途設定します。

振り返りの設計論としては、Esther DerbyとDiana Larsenの『Agile Retrospectives』（Pragmatic Bookshelf、2006年7月、ISBN 9780977616640）が場を Set the Stage / Gather Data / Generate Insights / Decide What to Do / Close the Retrospective の5段階に分けています。本記事では、Keep・Problemの書き出しを Gather Data、原因の検討を Generate Insights、Tryの選択を Decide What to Do に対応させて説明します。場を開く Set the Stage と、決めたことを確認して閉じる Close は、KPTの様式だけを真似すると抜け落ちる部分です。開始時に目的と発言ルールを共有し、終了時に決定事項を読み上げる時間を足して補ってください。

KPT法の進め方｜4ステップと時間配分

以下の時間配分は本記事の進行例です。4ステップの合計30分から50分に開始時と終了時の確認を加え、全体で30分から60分を目安に調整します。人数は、全員が発言して合意まで届く範囲として4人から8人が扱いやすい規模です。これを超える場合は、少人数での書き出しや順番に発言する時間を設けます。

ステップ1：前回のTryの実行・効果の確認（5分から10分）

白紙から始めません。2006年の原文も「2回目以降のふりかえりでは、前回のKPTのTry項目を確認することからはじめます」と明記しています。前回決めたTryを読み上げ、実行したか、効果はあったかを先に判定します。うまくいったTryはKeepへ移し、効果が出なかったものは取り下げるか作り直します。この工程を飛ばすと、新しいTryだけが毎回積み上がり、前回の決定が検証されないまま流れていきます。前回のTryの確認を、毎回の進行表に組み込みます。

ステップ2：テーマの限定とKeep・Problemの書き出し（10分から15分）

対象期間と範囲を先に宣言します。「今月の業務全般」のような広いテーマにすると論点が散り、Tryが抽象語になります。「先月の見積もり作成」「前回の展示会運営」のように、全員が同じ出来事を思い出せる単位まで絞ってください。書き出しは各自が黙って書く時間を取り、口頭から始めません。先に話し出した人の視点に全員が引きずられるのを防ぐためです。

ステップ3：優先するProblemの選定と原因の検討（10分から15分）

出たProblemをすべて掘ると時間が足りません。影響の大きいものを2つか3つ選び、次のTryを選べる程度まで原因を検討し、時間内に確認できない点は追加調査に回します。原因をたどる作業は責任の追及にすり替わりやすく、2006年の原文もその点に注意を促しています。真因の特定に時間をかけるべき論点は、KPTの場ではなく別枠に切り出し、なぜなぜ分析とは？5回のなぜで真因に迫る手順・事例・現場での進め方を解説の手順で扱ってください。

ステップ4：Tryのアイデア出しと実行項目の選択（5分から10分）

Tryの書き出しと採用は別の作業です。原文は、この区画では「なるべく多くのアイデアを挙げることを第一の目標」とし、そこから効果が期待できそうなものを選んで合意する、という順序を示しています。最初から実行するものだけを考えるとアイデアが出なくなるためです。

採用する数は、次の振り返りまでに結果を判定できる範囲に絞ります。目安は1つから3つで、担当者と期限を必ず付けます。スクラムガイドも改善項目について「最も影響の大きな改善は、できるだけ早く対処する。次のスプリントのスプリントバックログに追加することもできる」と、既存の作業一覧へ載せる扱いを示しています。KPTのシートに書いたまま放置せず、普段使っているタスク管理へ移すのが要点です。

KPT法の記入例｜営業・バックオフィス・個人の3場面

書き方は場面によって変わりません。変わるのは「何を事実として書けるか」です。書き方の粒度を、営業・バックオフィス・個人の架空の記入例で示します。表中の件数・日数は説明用の仮定です。

3例に共通するのは、Problemに件数や日数が入っていること、Keepがすべて動詞で終わっていることです。「多い」「遅い」とだけ書くと、次回に改善したかを判定できません。数えられる事実が出てこない場合は、次回までに数えること自体をTryにします。

KPTシートの作り方｜区画の配置と6列構成

紙やホワイトボードで行う場合は、前章で引いた様式どおり左上にKeep、左下にProblem、右にTryを置きます。左側の事実を見ながら右側へ案を書き足す視線の流れになる配置です。

3区画の記録に実施日や担当・期限を添えると、回をまたいでTryを追跡しやすくなります。実務で回すなら、次の6列でシートを作ります。

この構成にしておくと、次回の冒頭で前回採用したTryを状態にかかわらず抽出でき、未着手の理由と実行済みの効果をまとめて確認できます。ホワイトボードで実施した場合も、終了時にこの6列へ転記しておけば同じ運用になります。手書きで残す場合は、実施日を付けて保管してください。

KPTに使うツールの選び方｜無料枠の上限と記録方法の比較

専用ツールは必須ではありません。参加者が同時に書き込む必要があるか、記録を検索したいかの2点で選べば足ります。無料で始める場合、実際に効いてくるのは機能差より無料枠の上限です。

Miroの無料枠は編集できるボードが常時3件までなので、回ごとに新しいボードを作る運用とは相性が悪く、4回目で過去分が編集できなくなります。Trelloの無料枠はワークスペースあたり10ボードまでで、Standard（年間払いで1ユーザーあたり月額5米ドル）にするとボードが無制限になります。KPTとYWTに対応した国内サービスにはラジログ（lp.radilog.app）があり、2026年9月時点の公式FAQでは、ベータ版を提供し、新規登録者を優先して利用を案内すると説明されています。

注意点が1つあります。KPT専用の小規模サービスは提供が止まることがあり、過去の解説記事が挙げているサービスにも現在アクセスできないものがあります。記録の本体はスプレッドシートなど自分で書き出せる形式に置き、ツールは書き出しの場として使うのが安全です。料金と上限も改定されるため、導入前に公式ページで確認してください。Tryを開発課題として課題管理システムへ連携し、実行率まで数える運用はKPTとは？開発チームの振り返りをスプリントで機能させる進め方・ツール連携・判断で扱っています。

KPTが続かなくなる4つのパターンと立て直し方

KPTの欠点として挙げられるものの多くは、手法そのものではなく運用の型に原因があります。止まり方はおおむね4通りに分かれます。

未検証のTryの蓄積と採用数の見直し

採用数を見直すべきパターンです。次回までに実行・検証できる量を超えてTryを採用すると、検証しない項目が増え、やがてシート自体を開かなくなります。立て直しは、未検証のTryを一覧にして継続・保留・取り下げを選び、次回に検証する分だけを残すところから始めます。取り下げは失敗の記録ではなく、判定できる量まで戻す操作です。

Problemへの偏りとKeepの書き出しの改善

Keepが埋まらない場合は、成果だけでなく、次も続けたい小さな行動まで対象を広げます。書き出しの順序をKeepからに固定し、他のメンバーが気づいた良い行動も募ってください。原文も、無意識にやっている良い行動は本人ほど気づきにくいと指摘しています。なお、件数の達成を次の工程へ進む条件にはしません。

原因分析による時間超過と議題の切り分け

Problemを1つ掘り始めたら止まらなくなり、時間切れでTryが決まらないまま終わる型です。振り返りでは次の一手を選ぶために原因も検討しますが、掘る対象は2つか3つに制限し、時間内に扱いきれない分析は別の会議へ切り出してください。

KPTを使うべきでない場面

次の3つの状況では、KPTを使わない判断のほうが適切です。第一に、原因が分かっていて対策も決まっている場合です。振り返りの形式を通す意味がなく、担当と期限を決めれば済みます。第二に、人事評価や責任追及と結び付いている場合です。Problemが個人の落ち度として記録されると受け取られた時点で、事実が出てこなくなり、記録としての価値が失われます。第三に、対人的なリスクを取れる状態がまだ無い場合です。Amy Edmondsonは1999年の論文で、チームの心理的安全性を「そのチームは対人的なリスクを取っても安全だという、メンバーに共有された信念」と定義しました（Administrative Science Quarterly 44巻2号350-383頁）。この信念が共有されていない段階でProblemを求めても、当たり障りのない項目しか並びません。

単発イベントの評価に使う場合は、Tryを実行する別の業務や結果を確認する機会を先に決めておきます。実行先がなく記録だけが目的なら、アンケートや報告書を選ぶほうが適しています。

PDCA・YWT・Start Stop Continueとの違い

振り返りの手法は複数あり、扱う対象が違います。まず用語の階層として、レトロスペクティブは振り返りの場そのものを指す言葉で、KPT・YWT・Start Stop Continueはその場で使う型です。両者は並列の選択肢ではありません。

PDCAとの最大の違いは、計画の有無です。PDCAは計画を立てたうえで実績との差を見るため、目標値がない活動には当てはめにくい構造になっています。KPTは計画がなくても、起きた事実さえあれば回せます。両者は排他ではなく、PDCAのCheckとActの部分をKPTの形式で進める組み合わせも成立します。PDCAの各段階の回し方はPDCAサイクルとは？意味・4つのステップと具体例、回し方のコツまで解説で解説しています。

YWTとの違いは対象です。YWTは「わかったこと」を明示的に問うため、個人が経験から学びを取り出す用途に向きます。人材育成の文脈で設計するなら、経験学習サイクルとは何か？コルブ博士提唱の理論概要と組織学習・人材育成における重要性を徹底解説の枠組みと合わせて選ぶと、目的と型がずれません。

よくある質問

KPIとKPTの違いは何ですか？

別物です。KPIは Key Performance Indicator の略で、目標の達成度を測る指標を指します。KPTは Keep・Problem・Try の略で、振り返りの進め方の型です。何を測るかと、どう振り返るかの違いであり、対立する概念ではありません。KPIを設定している業務の月次振り返りをKPTの形式で行う、という併用が普通の使い方です。

「KPT」「KPT法」「KPT分析」は同じものですか？

同じ手法を指します。KPT形式・KPT方式・ケプト法という呼び方も見かけますが、内容に違いはありません。分析という語が付くことで定量分析の手法と誤解されることがあるものの、KPTは数値を統計的に処理する手法ではなく、事実を3枠に整理して次の行動を決める進め方です。

1人の業務振り返りにもKPTは使えますか？

使えます。2006年の原文も、チーム全体で続けることだけでなく個人的に続けたいことをKeepに書いてよいとしています。1人で行う場合に崩れやすいのは、Problemを自己評価として書いてしまう点です。「集中力が足りなかった」ではなく「割り込み対応で予定が2日ずれた」のように、外から観測できる事実として書けば翌週に検証できます。

Keepに書くことが思い浮かばないときはどうすればよいですか？

成果が出た項目を探すのをやめて、「同じ状況がもう一度来たら、また同じ順番でやるか」という問いに置き換えます。特別うまくいっていなくても、毎回そのやり方を選んでいる手順があれば、それはKeepです。それでも出ない場合は、対象期間を直近1週間に絞ったり、予定表や作業記録を見返したりして、続けたい行動を探します。なお、ペアプログラミングのようにチーム内で名前が共有されている作業は、動詞に直さず名前のまま書いて構いません。

KPTはアジャイル開発でないと使えませんか？

その制約はありません。KPTは、活動を振り返って続けたい行動・問題・次に試すことを整理する枠組みであり、開発工程やスプリントを前提にしていないためです。開発以外の営業・経理・店舗運営・個人の業務でも、この記事の4ステップがそのまま使えます。

関連記事

• KPTとは？開発チームの振り返りをスプリントで機能させる進め方・ツール連携・判断
• PDCAサイクルとは？意味・4つのステップと具体例、回し方のコツまで解説
• なぜなぜ分析とは？5回のなぜで真因に迫る手順・事例・現場での進め方を解説
• スクラム開発とは？進め方・役割・メリット・デメリットをわかりやすく解説
• 経験学習サイクルとは何か？コルブ博士提唱の理論概要と組織学習・人材育成における重要性を徹底解説