仕事のスピードが年々上がり、求められる役割やスキルも複雑化するなかで、「振り返り」の重要性は以前にも増して高まっています。個人であっても組織であっても、経験をただ積み重ねるだけでは十分とは言えません。経験をどう解釈し、どう次の行動に変換するか。そこまで含めて初めて「成長」や「改善」が成立します。

特にIT業界やWeb・プロダクト開発の領域では、その傾向が顕著です。
新しい技術や概念が次々と登場し、昨日の正解が今日には古くなる。そうした環境では、計画通りに進める力以上に、状況を見て軌道修正する力が問われます。

とはいえ現実には、
「忙しくて振り返りまで手が回らない」
「一応反省会はしたが、次に活きていない」
といった声も多く聞かれます。
振り返りが“やった感”で終わり、改善につながらない。これは珍しい話ではありません。

そこで有効なのが、今回取り上げるKPT法です。KPTは、振り返りを感想や反省で終わらせず、次の行動にまで落とすためのフレームワークとして、多くの現場で使われてきました。本記事では、KPT法の基本的な考え方から、なぜ今も使われ続けているのか、そして実務でどう使えば「形骸化せずに回り続けるのか」までを整理していきます。

KPT法とは何か

KPTとは、振り返りを以下の3つの観点で整理するフレームワークです。

• Keep：成果が出ており、今後も続けるべきこと

• Problem：うまくいかなかったこと、改善すべき課題

• Try：課題に対して次に試す具体的な行動

Keep・Problem・Tryの頭文字を取って「KPT」と呼ばれます。
日本語では「ケーピーティー」「ケプト」と読まれることが多いです。

考え方自体は非常にシンプルで、
「良かったことは残す」
「悪かったことは直す」
「直すために、次はこれをやる」
という流れを明確に言語化するものです。

KPTの特徴は、Tryが必ずセットになっている点にあります。
振り返りというと、どうしても「何が良かったか」「何がダメだったか」で終わりがちですが、それだけでは行動は変わりません。KPTは、振り返りを次の実行に接続することを前提とした構造になっています。

もともとはシステム開発、特にアジャイル開発やスクラムにおけるレトロスペクティブ（振り返り）の手法として広まりました。
変化が前提の開発プロセスでは、計画よりも学習と改善のスピードが重視されます。そのなかでKPTは、「短いサイクルで学び、次に反映する」ための実用的な枠組みとして定着してきました。

現在ではIT領域に限らず、営業、マーケティング、バックオフィス、さらには個人の自己成長やキャリアの振り返りなど、さまざまな場面で活用されています。

KPT法が評価され続ける理由

KPTが長く使われている理由は、特別に高度な理論があるからではありません。
むしろ逆で、誰でも理解でき、すぐに使えるのに、きちんと効果が出る点にあります。

課題を早い段階で表に出せる

KPTでは、Problemを明確に洗い出します。
しかも、それを個人の失敗や感情論として扱うのではなく、「改善すべき事象」として整理します。定期的にKPTを行っていると、小さな違和感や詰まりが早い段階で共有されます。
結果として、大きなトラブルになる前に手を打てるようになります。

さらに重要なのは、Problemを出すだけで終わらず、その場でTryまで決めることです。
次に何をするのかが明確になるため、振り返り直後から行動に移りやすくなります。

コミュニケーションとナレッジが自然に蓄積される

KPTは、全員が意見を出す前提のフレームワークです。付箋やボードに書き出す形式を取ることで、発言が得意でない人の考えも拾いやすくなります。「こんなこと言っても意味がないかもしれない」と思われがちな小さな気づきが、実は本質的な問題につながっていることも少なくありません。KPTは、そうした暗黙知を可視化する装置としても機能します。

結果として、チーム内での認識のズレが減り、判断の質やスピードが向上していきます。

改善が“実感”として積み上がる

Tryを設定し、次回のKPTでその結果を振り返る。このサイクルを回していくと、「前より少し良くなっている」という感覚が生まれやすくなります。大きな成功体験でなくても構いません。小さな改善が積み重なっているという実感は、チームや個人のモチベーションを底支えします。

KPTを機能させるための基本設計

KPTはシンプルな分、設計を誤ると形骸化しやすい側面もあります。
ここでは、最低限押さえておきたい前提条件を整理します。

実施のタイミングを決める

KPTは「時間が空いたらやる」ものではありません。
業務プロセスの一部として、あらかじめタイミングを固定することが重要です。

たとえば、
・毎週または隔週
・プロジェクトや施策の終了時
・月次の定例ミーティング
といった形で、あらかじめ組み込んでおくことで、意思決定の負荷を減らせます。

所要時間と人数の考え方

一般的には45分〜1時間程度が適切です。
長くなりすぎると集中力が落ち、重要度の低い話題に時間を取られがちになります。

参加人数は5名前後が最も扱いやすく、10名を超える場合は工夫が必要です。
人数が多い場合は、テーマを絞る、代表者制にする、小さな単位で実施するなどの調整を行います。

KPTの具体的な進め方

実施方法はさまざまですが、ここでは最も基本的な流れを紹介します。

まず、ホワイトボードやオンラインボードを3つのエリアに分け、Keep・Problem・Tryを書き出せる状態を作ります。

次に、参加者それぞれがKeepとProblemを個別に書き出します。
この段階では質より量を重視し、細かいことでも構いません。後から整理できます。

出揃ったら、内容を一つずつ確認しながら、なぜそれがKeepなのか、なぜProblemなのかを掘り下げていきます。特にProblemについては、表面的な現象ではなく、背景や構造に目を向けることが重要です。

議論を通じて見えてきた原因に対して、「では次に何をするのか」をTryとして定義します。
Tryは抽象的な方針ではなく、実行可能な行動として言語化します。

最後に、決めたTryを次回のKPTで必ず検証する前提を共有します。
ここまで含めて、KPTは一つのサイクルになります。

KPTを成功させるためのポイント

KPTがうまく回るかどうかは、フレームそのものよりも運用にかかっています。特に重要なのが、心理的安全性です。Problemを出す場が、誰かを責める場になってしまうと、意見は一気に出なくなります。KPTでは「人」ではなく「仕組み」や「プロセス」に焦点を当てる姿勢が欠かせません。
また、参加人数が多い場合はファシリテーターを置くことで、議論の発散を防ぎ、時間配分をコントロールしやすくなります。

そして何より重要なのが、継続です。KPTは一度やっただけで劇的な成果が出るものではありません。Tryを実行し、その結果をまた振り返る。この循環を続けることで、初めて意味を持ちます。

おわりに

KPT法は、非常にシンプルなフレームワークです。だからこそ、導入のハードルが低く、誰でも始められます。一方で、Tryを曖昧にしたり、次回の検証を行わなかったりすると、簡単に形骸化もします。KPTの価値は、「振り返ること」そのものではなく、改善を実行し続ける仕組みを作れる点にあります。

変化が前提となった現代の仕事環境において、立ち止まって考え、次に進むための型を持つことは大きな武器になります。もし振り返りがうまく機能していないと感じているなら、一度KPTを「運用」まで含めて見直してみると良いかもしれません。