KPT振り返りとは？Keep・Problem・Tryで改善を生むフレームワーク

KPT振り返りとは

KPTとは、Keep（継続すること）・Problem（問題点）・Try（次に試すこと）の3つの視点でチームの活動を振り返り、改善アクションを導き出すフレームワークです。日本語では「けぷと」と読みます。

KPTはアジャイル開発のスプリントレトロスペクティブ（振り返り会）で広く使われている手法です。アリスター・コーバーンが考案した振り返りの手法がベースとなっており、日本ではソフトウェア開発コミュニティを中心に普及しました。シンプルな構造でありながら、チームの改善活動を継続的に回せる実用性の高さが特徴です。

PDCAサイクルが「計画→実行→評価→改善」のプロセス改善を体系的に進めるのに対して、KPTは「チームが自ら気づき、自ら改善する」参加型のアプローチです。全員が意見を出し合うことで、現場の実態に即した改善策が生まれやすくなります。

構成要素

KPTは3つのカテゴリでチームの活動を分類します。ホワイトボードや付箋を使って、チーム全員が意見を書き出す形式が一般的です。

要素	意味	記入する内容
Keep	継続すべきこと	うまくいったこと、今後も続けたい良い習慣や取り組み
Problem	問題・課題	困ったこと、改善が必要なこと、障害となっていること
Try	次に試すこと	Problemの解決策やKeepをさらに発展させるアイデア

KPTの構造上の特徴は、ProblemとTryが対になっている点です。単に問題を列挙するだけでなく、必ず「ではどうするか」の具体的なアクションに落とし込みます。この「問題提起→解決策提示」の流れがあるからこそ、振り返りが前向きな改善活動になります。

KPTとYWT・FDLの違い

振り返りフレームワークにはKPT以外にもいくつかの手法があります。

YWT（やったこと・わかったこと・次にやること）は個人の学びの振り返りに適しており、KPTよりも内省的です。FDL（Fun・Done・Learn）はチームの感情面にも焦点を当てる手法で、メンバーのモチベーション把握に有効です。

KPTの強みは「問題を明確にしたうえで対策を出す」という構造のわかりやすさにあります。初めてチーム振り返りを導入する場面では、KPTが最も取り組みやすい選択肢です。

実践的な使い方

ステップ1: 振り返りの準備をする

振り返りの対象期間と時間枠を決めます。スプリントレトロスペクティブなら1〜2週間分、プロジェクトの節目なら1ヶ月程度が目安です。時間は30分〜1時間を確保します。ホワイトボードまたはオンラインツール（Miro、FigJamなど）に3つの領域を準備します。

ファシリテーターを1名指名し、参加メンバーは5〜8名程度が理想的です。人数が多すぎると発言の偏りが生じやすいため、10名を超える場合はチームを分割します。

ステップ2: Keep・Problemを書き出す

まず個人ワークとして、各メンバーが5分程度でKeepとProblemの付箋を書き出します。1枚の付箋に1つの意見を記載し、できるだけ具体的に書くことがポイントです。「コミュニケーション不足」のような抽象的な記述ではなく、「設計レビューで仕様の認識ズレが3件発生した」のように事実ベースで書きます。

書き出しが終わったら、全員がボードに貼り出し、似た内容をグルーピングします。必要に応じて補足説明を加えながら、チーム全体で内容を共有します。

ステップ3: Tryを導出する

ProblemのグループごとにTryを検討します。「次のスプリントでどうするか」「誰が何をいつまでにやるか」を具体的に決めます。Tryが曖昧なままだと実行されないため、担当者と期限を明確にすることが重要です。

Tryの数は3〜5個に絞り込みます。あれもこれもと施策を増やしすぎると、どれも中途半端になりがちです。インパクトの大きいProblemから優先的にTryを設定します。

ステップ4: 次回の振り返りで追跡する

前回のTryが実行されたかどうかを次回のKPTの冒頭で確認します。成功したTryはKeepに昇格させます。未実行や効果不十分のTryは原因を分析し、再度Tryとして設定するか、取り下げるかを判断します。この追跡の仕組みがなければ、KPTは「ただの感想大会」に劣化してしまいます。

活用場面

• アジャイル開発のスプリントレトロスペクティブ: 1〜2週間のスプリント終了後にチームで実施します
• プロジェクトのマイルストーン振り返り: フェーズ完了時や中間レビュー時に実施し、後半の進め方を改善します
• 研修・ワークショップの振り返り: 参加者のフィードバックを構造化して、次回のプログラム改善に活かします
• 組織の定期振り返り: 月次・四半期ごとにチームの活動を振り返り、業務改善につなげます
• 個人の自己振り返り: 1人で実施する場合にも、KeepとProblemを分けて書き出すことで改善点が見えやすくなります

注意点

Problemの「犯人探し」にしない

KPTの場は安全な空間でなければなりません。「誰が悪かった」ではなく「何が問題だったか」にフォーカスする姿勢をファシリテーターが徹底することが大切です。心理的安全性が確保されていないと、メンバーはProblemを出さなくなり、表面的な振り返りに終わります。

Keepを軽視しない

Problemに意識が集中しがちですが、Keepの共有もチーム改善において重要な役割を果たします。うまくいっていることを言語化し、チームで認識を揃えることで、良い習慣の定着と士気の向上につながります。

Tryを具体的なアクションにする

「もっと頑張る」「意識する」のような精神論的なTryは改善につながりません。「毎朝10分のスタンドアップミーティングを導入する」「PRのレビューを24時間以内に完了するルールを設ける」のように、行動レベルで記述します。

振り返りの頻度を適切に保つ

振り返りの間隔が長すぎると記憶が薄れ、具体性のある振り返りが難しくなります。一方、頻度が高すぎると「振り返り疲れ」が発生します。アジャイル開発のスプリント単位（1〜2週間）が多くの場面で適切な頻度です。

まとめ

KPTは、Keep・Problem・Tryの3要素でチームの振り返りを構造化し、具体的な改善アクションを導き出すフレームワークです。問題の特定から解決策の実行、そして次回の追跡までをシンプルな仕組みで回せる点が強みです。心理的安全性を確保し、Tryを具体的なアクションに落とし込むことで、チームの継続的な改善サイクルが機能します。

参考資料

• What is a Sprint Retrospective? - Scrum.org（スプリントレトロスペクティブの目的、進め方、チームへの効果を公式ガイドとして解説）
• Sprint Retrospective: How to Hold an Effective Meeting - Atlassian（レトロスペクティブの実践的なファシリテーション手法とチームプレイブック）
• アジャイル（アジャイル開発）とは？開発手法の特徴やメリットを解説 - グロービス経営大学院（アジャイル開発の全体像と反復的な改善プロセスの基本を解説）