【KPT】とは？振り返りの進め方5ステップと具体例｜形骸化させないTryの書き方

約 18 分で読めます

KPT（ケプト）は、Keep（続けること）・Problem（課題）・Try（次の行動）の3つで振り返るフレームワークです。Tryを行動で決め、次回に検証するまでの進め方を例つきで解説します。

KPTは、付箋に書き出すだけなら誰でもすぐに始められます。一方で、Tryが「気をつける」「徹底する」のような言葉で終わると、次回の振り返りで確かめられることが何もなくなり、同じ話し合いを繰り返すことになります。この記事では「Tryを『いつ・誰が・何を』まで具体化し、次回のKPTで結果を検証するところまでを1回分とする」という考え方を軸に、手順・テンプレート・欠点への対策を順に説明します。

KPTとは？Keep・Problem・Tryの意味と読み方

KPTは、Keep・Problem・Tryの頭文字を取った振り返りのフレームワークです。Keep・Problem・Tryの3つの欄に分けて書き出し、チームで話し合うのが基本の形式です。

Keep・Problem・Tryそれぞれの意味

Keepは「良かったこと」の感想ではなく、うまくいった理由まで書くと再現しやすくなります。Problemは人ではなく事柄を書くのが原則です。TryはKeepを伸ばす行動でも、Problemを解消する行動でも構いません。

読み方と使える場面

読み方は「ケプト」または「ケーピーティー」が一般的です。チームでも個人でも使えるため、スプリントやプロジェクトの区切り、月次の業務レビュー、個人の週次の振り返りなど、期間を区切って「次はどうするか」を決めたい場面で使えます。

由来については、NotePMやAgile Studioの解説によると、アリスター・コーバーン氏がアジャイル型の開発手法の現場で紹介した振り返りの方法が原型で、その後日本で広まったとされています。

「反省会」との違い

反省会は「何が悪かったか」を確認して終わりがちですが、KPTでは必ずTryがセットになります。振り返りの結論が「次に何をするか」という行動になる点が最大の違いです。全員が同じ枠に書き出すため、課題を早く見つけやすく、声の大きい人だけで話が進むのを防ぎやすくなります。また、決まったTryが目に見える形で残るため、次回の振り返りの起点にもなります。

KPTの進め方は？準備から次回の検証までの5ステップ

KPTは1回の会議で完結するものではなく、「決めたTryを実行し、次回のKPTで結果を確かめる」ところまでで一巡します。全体の流れは次の図のとおりです。

ステップ1：ボードを3エリアに分け、材料を準備する

ホワイトボードを Keep・Problem・Try の3エリアに区切り、ペンと付箋を用意します。配置は自由ですが、KeepとProblemを左に上下で並べ、Tryを右に置くと、左の材料から右の行動を導く流れが見た目にも分かります。

リモートの参加者がいる場合は、Miroのようなオンラインホワイトボードに同じ3区画を作れば、離れた場所にいる参加者も同じボードに書き出せます（リンク経由で当サイトが報酬を受け取る場合があります）。無料プランで足りるかどうかは、後半の「オンラインでKPTをするなら」の節で判断材料をまとめています。

振り返りに資料やデータが必要なら、各自が事前に用意しておきます。たとえば「見積もりより時間がかかった」という話をするなら、作業工数の記録を持ち寄ると、感覚ではなく実績をもとに話せます。前回のKPTで決めたTryの一覧も、このとき手元に用意しておきます。あわせて、時間と発言を管理する進行役を1人決めておくと、話が脱線したときに戻しやすくなります。

ステップ2：各自で相談せずにKeepとProblemを書き出す

最初は他のメンバーと相談せず、自分の考えを付箋に書き出します。3分程度で時間を区切る例もあり、時間を決めておくと考え込みすぎを防げます。付箋1枚に1つの事柄を書くと、後で並べ替えたりまとめたりしやすくなります。

ステップ3：共有し「なぜ」を掘り下げる

書いた付箋を1人ずつ読み上げながら貼り、似た内容はまとめます。Keepには「なぜうまくいったのか」、Problemには「なぜ起きたのか」を問いかけ、原因まで掘り下げます。

Problemが多い場合は、全部を一度に扱おうとせず、影響の大きいものから優先順位を付けます。ここで守るべきルールは、Problemとして挙げるのは人ではなく事柄であること、そして挙がったProblemに対して批判や個人攻撃をしないことです。責任追及の場になると、次回から本当の課題が出てこなくなります。

ステップ4：Tryを「いつ・誰が・何を・どのように・いつまでに」で決める

掘り下げた原因に対して、次に試す行動を決めます。「いつ・誰が・何を・どのように・いつまでに」行うかを書き、さらに「次回のKPTで何を見て結果を判断するか」まで決めておきます。目標を具体的に書くSMARTの考え方は、Tryの書き方にもそのまま当てはまります。

Tryは多ければよいわけではなく、次回までに実際に回せる数に絞ります。具体的な書き方は、後半のテンプレートと具体例の節で良い例と悪い例を並べて説明します。

ステップ5：実行し、次回のKPTで検証してKeep・Problemへ振り分ける

決めたTryを実行し、次回のKPTの冒頭で結果を確かめます。うまくいったTryはKeepへ、うまくいかなかったTryはProblemへ振り分けます。この手順全体の要がこのステップです。

ここを省くと、毎回の振り返りがゼロからの話し合いになり、Tryに効果があったのかどうかも分からないままになります。逆に、前回のTryの振り分けから始めれば、KeepとProblemの一部は最初から埋まった状態で議論を始められます。

Tryを会議のあとに忘れないようにするには、普段のタスク管理の場所に載せておくのが確実です。カンバンボードで作業を管理しているなら、Tryを1枚のカードとして追加し、担当者と期限を付けておけば、日々の作業と同じ画面で進み具合が見えます。

KPTの人数・時間・頻度はどれくらいが目安？

人数や時間について、主な解説記事の記述を整理すると次のとおりです。情報源によって幅がある項目は、出典を添えています。

時間配分のイメージをつかむために、45分で行う場合の一例を挙げます。

• 前回のTryの検証とKeep・Problemへの振り分け：5分
• 各自でKeep・Problemを書き出す：5分
• 共有と原因の掘り下げ：20分
• Tryの決定（担当・期限・確認方法まで）：10分
• 予備：5分

頻度は、編集部としては「Tryを1回試して結果が見える周期」に合わせることをすすめます。スクラムのスプリントで開発しているなら、スプリントの終わりごとに行えば、前回のTryの結果がちょうど出そろった状態で振り返れます。ウォーターフォール型の開発のように工程が長く続く場合は、工程の区切りだけでなく、工程の途中にも定期的な回を入れると、改善を次の工程まで持ち越さずに済みます。

間隔を空けすぎると、細かい出来事を忘れてしまい、改善すべきタイミングも逃しやすくなります。迷ったら短めの間隔で始め、話すことが少なすぎると感じたら間隔を延ばすほうが調整しやすいです。

KeepやProblemが思いつかないときはどうする？

書き出しの時間になってから考え始めると、手が止まりやすくなります。対処は、会の前と会の中に分けて考えます。

会の前には、自分が関わった業務やプロジェクトを振り返り、気になった点や違和感を覚えたことを洗い出しておきます。次のような問いを手元に置いておくと思い出しやすくなります。

• Keepの手がかり：予定どおり、または予定より早く終わった作業は何か。誰かに助けられた場面はあったか
• Problemの手がかり：待ち時間が発生した場面はあったか。やり直しになった作業はあったか。確認の往復が多かったやりとりはどれか

会の中では、「小さなことや、全員がおそらく分かっていることも書いてよい」と最初に決めておきます。書く基準が高すぎると、誰も付箋を出せなくなります。

もう1つの方法は、前回のTryの結果から振り分けを始めることです。うまくいったTryはKeep、うまくいかなかったTryはProblemになるので、ゼロから考える必要がなくなります。編集部としては、この順番を毎回の定番にする進め方をすすめます。

KPTのテンプレートと具体例｜そのまま書き写せる記入枠

そのまま書き写せるKPTテンプレート

ホワイトボードでもスプレッドシートでも、次の項目を枠として用意すれば使えます。Tryの欄に「次回の確認方法」を入れておくのがポイントです。

具体例：5人のWeb制作チームの2週間スプリント（編集部作成の仮想例）

ここからは、5人のWeb制作チームが2週間のスプリントを終えてKPTを行う場面を想定して考えてみます。書き方の型を示すための仮想例です。

• Keep：デザイン担当と実装担当が毎朝短く打ち合わせたことで、デザインの疑問をその日のうちに解消できた。続ける理由は、質問をためずに済むから
• Problem：レビュー依頼が週末に集中し、金曜日にレビュー待ちの作業が積み上がる。原因は、依頼を出す期限が決まっておらず、各自が実装を終えた時点でまとめて出しているため

このProblemに対するTryを、悪い例と良い例で比べます。

「レビューを早めに出す」が機能しないのは、やる気の問題ではなく、次回に検証できないからです。「早め」の基準がないため、次回のKPTで「早めに出せたか」を聞いても全員が「出せたと思う」と答えるしかなく、効果があったのか分からないまま同じProblemが再び挙がります。良い例のように期限と確認方法を決めておけば、次回は件数を見るだけでKeepかProblemかを判断できます。

同じ考え方で、たとえば「仕様の確認漏れで手戻りが出た」というProblemなら、「仕様をよく確認する」ではなく「ディレクターは着手前に受け入れ条件をチケットに書き添える。次回KPTで手戻りになったチケットを確認する」のように書きます。手戻りの原因がスプリントの範囲を超えて仕様の決め方そのものにあると分かった場合は、要件定義の手順から見直すほうが近道です。

業務系の題材での記入例を見たい場合は、NotePMのKPTテンプレートページに「スタッフ研修の準備」を題材にした例が掲載されています。

KPT法の欠点は？反省会で終わらせないための対策

KPTはシンプルなぶん、運用を誤ると形骸化しやすいフレームワークです。主な欠点と対策を先にまとめます。

欠点1：Tryが曖昧・未検証だと形骸化する

最も多い失敗がこれです。「次は頑張ろう」のような精神論のTryは、何をすればよいかが決まっていないため、実行も検証もされません。対策は、先ほどのテンプレートのように担当・期限・確認方法まで書くことと、次回の冒頭で必ず前回のTryを検証することの2つです。

Tryが大きすぎて1回のサイクルで終わらない場合もあります。その場合はWBSでの作業分解と同じ要領で、次回までに終えられる単位に切り分け、最初の一歩だけをTryにします。

欠点2：Problem探しの会になり、Keepが前菜扱いになる

Agile Studioの記事が指摘するように、KPTというとProblemとTryの話が中心になり、Keepは本題に入る前の前菜のような扱いになっているチームは少なくありません。Problemばかりが並ぶと、参加者は「責められる場」と感じ、本当の課題を出さなくなります。否定しないこと、批判しないことをルールとして明文化し、会の最初に読み上げると、ある程度の心理的安全性を確保できます。

欠点3：Keepに含まれる問題を見落としやすい

Keepに挙がった事柄にも問題が隠れていることがあります。「締め切りに間に合った」がKeepでも、その裏で特定の人が残業で吸収していたなら、続けるべきやり方とはいえません。Keepにも「なぜうまくいったのか」「無理や偶然に頼っていないか」を問いかけると、見落としを防げます。

なお、同じProblemが何度もKPTに挙がる場合は、振り返りの場だけで抱え込まず、課題管理表に移して担当者・期限・ステータスを付けて追跡するほうが確実です。KPTは改善の行動を決める場、課題管理表は解決まで追いかける場と役割を分けると、どちらも回りやすくなります。

Keepから始める回し方（強みを中心にしたKPT）

Problem偏重を避けたいチームには、Keepを中心に置く回し方もあります。Agile Studioの記事によると、一般的な紹介ではK→P→Tの順でカードを出すと説明されることが多いものの、アリスター・コーバーン氏の解説はK→T→Pの順で、Problemはかなり付加的な位置づけだったとされています。

この考え方に沿うなら、まずKeepで自分たちの強みを確認し、その強みを伸ばすTryを決めます。Problemは「強みや自分たちのよいところを発揮するうえで障害になること」と定義し直して扱います。毎回の振り返りが重い雰囲気になっているチームでは、数回試してみる価値があります。

オンラインでKPTをするなら、Miroの無料プランで足りる？

先に結論を書くと、KPTは紙やスプレッドシートでも成立するため、オンラインホワイトボードは必須ではありません。そのうえで、リモートの参加者がいてボード上で書き出しを進めたいチームなら、Miroの無料プラン（Free）から始めれば足ります（リンク経由で当サイトが報酬を受け取る場合があります）。有料のStarterが必要になるのは、後述する2つの条件に当てはまる場合です。

Freeでできること・注意点

Freeはチームメンバー数に上限がなく、すべてのユーザーが無料です。テンプレートのほか、キャンバス上で文書、テーブル、タイムライン、カンバンなどの形式を使えます。KPTの3区画は、自分で枠を描いて見出しを付ければ十分に作れます。

注意点は、編集可能なボードが最大3件までという点です。回ごとに新しいボードを作っていくと、すぐにこの上限に達します。KPTでは、1枚のKPT用ボードを使い回し、回ごとに日付の見出しを付けた区画を足していく運用が合います。前回のTryが同じボード上に残るため、ステップ5の検証もしやすくなります。

また、ボードの公開範囲やゲストの扱いはプランによって異なる場合があります。Miroのチームに振り返りの参加者以外も入っている場合は、誰がKPTのボードを閲覧できるかを、公式の料金ページやヘルプで事前に確認しておきます。ボード上のタイマーや投票を使わなくても、書き出しの時間はビデオ会議ツールやスマートフォンのタイマーで計り、優先順位は付箋に印を書き足すなどの手作業で決められます。

Starterが必要になる2つの条件

次のどちらかに当てはまる場合は、Starterを検討します。

• 各自の書き出し時間を、ボード上のタイマーで区切りながら進行したい
• Problemの優先順位を、ボード上の投票で決めたい

振り返りの内容を見られる人を限定したい場合は、ボードのアクセス権をどのプランでどこまで設定できるかを、契約前に公式の料金ページで確認してください。

Starterの料金と契約上の注意

Starterの料金は、年払いでメンバー1人あたり月US$8です（2026年11月2日時点の公式料金ページの米ドル表記）。年払いは月払いより20%お得に設定されており、料金はワークスペースに追加したメンバー1人ごとにかかります。

想定として、KPTに参加する5人全員をメンバーにして年払いする場合を計算すると、US$8×5人×12か月＝US$480が年間の額です。月あたりに直すとUS$40になります。これは公式の米ドル表記にもとづく税別の計算上の目安で、日本から購入する際の表示通貨や税額は含めていません。

支払い方法、メンバーの追加・削除時の請求の扱い、更新や解約の条件は、契約前に公式の料金ページや利用規約で確認してください。

KPTの書き出しと振り返りだけが目的なら、上位のBusiness（年払いでメンバー1人あたり月US$20）を前提にする必要はありません。社外のゲスト招待や他ツールとの連携が必要な場合は、どのプランで使えるかを公式の料金ページで確認してください。Businessが候補に入る場合は、14日間の無料トライアルで試してから判断できます。

リモートでKPTを始めるなら、まずMiroの無料プランでKPT用のボードを1枚作り、Keep・Problem・Tryの3区画と回ごとの見出しを用意するところから始めるのが手堅い進め方です。タイマーや投票をボード上で使いたくなった時点で、それらが使えるプランを公式の料金ページで確かめてから切り替えれば十分です（リンク経由で当サイトが報酬を受け取る場合があります）。

まとめ

KPTを反省会で終わらせるかどうかは、Tryを行動として書き、次回のKPTで検証するかどうかで決まります。人数や頻度、使う道具は後から調整できますが、検証のないKPTは何度回しても同じ話し合いに戻ります。

次の振り返りでは、Tryを1つだけ選び、「誰が・何を・いつまでに」と「次回のKPTで何を見て判断するか」を書いてから会を閉じてください。そして次回の冒頭で、そのTryをKeepかProblemに振り分けるところから始めます。リモートで行う場合は、オンラインホワイトボードに1枚のKPT用ボードを用意し、回を重ねるごとに同じボードへ書き足していくと、前回のTryを見失わずに済みます。