- マネジメント
KPTのやり方と具体例120個 テンプレートとYWTとの違い
KPTとは、ふりかえりで出た意見を Keep(続けたいこと)・Problem(困ったこと)・Try(次に試すこと)の3つに分けて書き出し、次の行動を決める手法です。 枠が3つだけなので初めてのチームでも始めやすく、週次や隔週の定例にそのまま組み込めます。
この記事は、ふりかえりで「何を書けばよいか」に絞っています。開発チーム向けの具体例を、設計・実装・レビュー・テスト・リリース・連絡の場面別にKeep 40個・Problem 40個・Try 40個の計120個載せました。あわせて、あいまいなTryを行動に書き直す前後対比20例、30分・60分・90分の進行表、そのまま貼れるテンプレート、YWTなどほかの手法との違いを表にまとめています。
確認環境:具体例の件数は Python 3.11 で数え、重複がないことも確かめました。Tryの管理表の集計式は LibreOffice Calc 24.2(ヘッドレス実行)で再計算した結果を載せています。
KPTの早見表
| 枠 | 意味 | 書くこと | 書き方のコツ | 例 |
|---|---|---|---|---|
| Keep | 続けたいこと | うまくいったこと、次も続けたい行動 | 行動と、それで得られた結果をセットで書く | PRを300行以内に収め、当日中にレビューが終わった |
| Problem | 困ったこと | 困ったこと、時間がかかったこと | 人ではなく出来事を、数字を添えて書く | レビューの依頼が2日間そのままになった |
| Try | 次に試すこと | Problemへの対策、Keepをさらに伸ばす工夫 | 誰が・いつまでに・何を・確認方法の4つを書く | レビュー担当が、依頼から1営業日以内に最初の返事をする |
| 知りたいこと | 見る場所 |
|---|---|
| 書く内容が思いつかない | Keepの具体例40個、Problemの具体例40個、Tryの具体例40個 |
| Tryが「気をつける」で終わってしまう | あいまいなTryを書き直す前後対比20例 |
| 時間配分を決めたい | 30分・60分・90分の進行表 |
| すぐ使える枠がほしい | KPTのテンプレート |
| YWTなどとの違いを知りたい | KPT・YWT・KPTA・Fun/Done/Learn・4Lsの比較 |
本記事の内容は、ご自由にお使いください。
ご利用の際は、出典として本ページへのリンクを記載いただけますようお願いします。
(記載例)出典:株式会社RJC「KPTのやり方と具体例120個 テンプレートとYWTとの違い」
KPTのやり方(5つの手順)
| 手順 | やること | ポイント |
|---|---|---|
| 1. 前回のTryを確かめる | 前回決めたTryの結果を、完了・途中・未着手で確認する | できたTryはKeepに移す。できなかったTryは理由を聞き、続けるかを決める |
| 2. KeepとProblemを書く | 各自が黙って付せんやシートに書く | 話す前に書く時間を取ると、全員の意見が出やすい |
| 3. 共有してまとめる | 1人ずつ読み上げ、似た内容を近くに寄せる | この段階では解決策を話さず、内容の確認だけにする |
| 4. 話し合う対象を絞る | 投票で2〜3個に絞る | 全部に対策を立てようとせず、効果の大きいものを選ぶ |
| 5. Tryを決める | 対象ごとにTryを考え、4つの要素で書く | 1回のふりかえりで決めるTryは3個までが目安 |
Keepから先に話すと、場の空気がやわらぎ、Problemも出しやすくなります。 また、Problemは「誰が悪かったか」ではなく「何が起きたか」で書きます。たとえば「Aさんのレビューが遅い」ではなく「レビューの依頼が2日間そのままになった」と書くと、仕組みの話に進められます。
Keepの具体例40個(場面別)
Keepは「行動」と「その結果」をセットで書くと、ほかの人がまねしやすくなります。PRはプルリクエストの略です。
| No. | 場面 | Keep(続けたいこと) |
|---|---|---|
| K01 | 設計 | 設計書を書く前に、画面の流れを手書きの図で全員と確認した |
| K02 | 設計 | テーブル定義の変更を、変更履歴の表に毎回書き残した |
| K03 | 設計 | 外部連携の仕様で不明な点を、質問票にまとめて早めに確認した |
| K04 | 設計 | 設計レビューの前日に資料を配り、当日は議論に時間を使えた |
| K05 | 設計 | エラー時の動きを、正常時と同じ表の中に並べて書いた |
| K06 | 設計 | 用語集を最初に作り、設計書の中の呼び名がそろった |
| K07 | 設計 | 設計の判断理由を、設計書の末尾に一言ずつ残した |
| K08 | 実装 | 着手前に、作業を半日以内の単位に分けてチケットにした |
| K09 | 実装 | コミットを小さく分け、メッセージに目的を書いた |
| K10 | 実装 | 共通の処理を見つけた時点でチャットに共有し、1つの関数にまとめた |
| K11 | 実装 | コードの整形と静的解析を、保存時に自動で走らせた |
| K12 | 実装 | 30分進まなければ相談する、という決まりを全員が守れた |
| K13 | 実装 | ブランチを毎朝最新に合わせ、競合を小さいうちに解消した |
| K14 | 実装 | 環境構築の手順をREADMEに書き、新しく入った人が半日で動かせた |
| K15 | レビュー | PRを300行以内に収め、当日中にレビューが終わった |
| K16 | レビュー | レビューコメントに「必須」「提案」「質問」のラベルを付けた |
| K17 | レビュー | PRの説明欄に、確認手順と画面の画像を載せた |
| K18 | レビュー | レビューの依頼から1営業日以内に、最初の返事をした |
| K19 | レビュー | よい書き方を見つけたら、コメントで具体的に伝えた |
| K20 | レビュー | 指摘が多かった項目を、チェックリストに追加した |
| K21 | レビュー | 設計に関わる指摘は、コメントを重ねず10分の通話で決めた |
| K22 | テスト | テスト項目を実装の前に書き、仕様の抜けを2件見つけた |
| K23 | テスト | 境界値の項目を表にして、漏れなく洗い出した |
| K24 | テスト | 不具合の報告に、再現手順・期待する結果・実際の結果をそろえて書いた |
| K25 | テスト | 自動テストをプッシュのたびに走らせ、10分以内に結果が出た |
| K26 | テスト | テスト用データを作るスクリプトを用意し、誰でも同じ状態を作れた |
| K27 | テスト | 修正した不具合に、再発を防ぐテストを必ず足した |
| K28 | テスト | テストの進み具合を、消化した項目数と不具合の件数で毎日共有した |
| K29 | リリース | リリース手順書を、事前に検証環境で1回通した |
| K30 | リリース | 切り戻しの手順と判断の時刻を、手順書に書いておいた |
| K31 | リリース | リリース作業を2人で行い、1人が読み上げ、1人が実行した |
| K32 | リリース | リリース後の30分間、決めておいた項目でログと画面を確認した |
| K33 | リリース | リリースの内容を、利用者向けの言葉で前日までに知らせた |
| K34 | リリース | 設定値の違いを、環境ごとの一覧表で管理した |
| K35 | 連絡 | 朝会を15分で終え、長くなる話は別の時間に分けた |
| K36 | 連絡 | 質問には、気づいた人がまず「見ています」と返事をした |
| K37 | 連絡 | 決まったことを、その日のうちにチケットへ書き残した |
| K38 | 連絡 | 休みや不在の予定を、1週間前に共有カレンダーへ入れた |
| K39 | 連絡 | 困りごとを朝会で言いやすい雰囲気があった |
| K40 | 連絡 | 発注側への質問を1つの表にまとめ、回答の期限を添えた |
Problemの具体例40個(場面別)
Problemは、出来事と数字(時間・件数・回数)で書きます。番号は次のTryの表と対応しています。
| No. | 場面 | Problem(困ったこと) |
|---|---|---|
| P01 | 設計 | 設計レビューの資料が当日に配られ、読む時間で会議が終わった |
| P02 | 設計 | エラー時の動きが設計書になく、実装の途中で質問が続いた |
| P03 | 設計 | 同じ項目が、画面設計書とテーブル定義で別の名前になっていた |
| P04 | 設計 | 設計の変更が口頭で伝わり、設計書に反映されなかった |
| P05 | 設計 | 外部連携の仕様の確認が遅れ、2日分のやり直しが出た |
| P06 | 設計 | 1画面の設計書が長く、読み切るのに時間がかかった |
| P07 | 設計 | 性能の目標が決まっておらず、設計案を比べる基準がなかった |
| P08 | 実装 | 1つのチケットが大きく、3日間進み具合が見えなかった |
| P09 | 実装 | 同じ入力チェックを、3人が別々に実装していた |
| P10 | 実装 | ブランチを長く分けたままにして、競合の解消に半日かかった |
| P11 | 実装 | 環境構築に2日かかった |
| P12 | 実装 | 1人で半日悩み、相談したら5分で解決した |
| P13 | 実装 | ログの書き方がそろっておらず、調査に時間がかかった |
| P14 | 実装 | 仕様の読み取り方が人によって違い、作り直しが出た |
| P15 | レビュー | PRが1,000行を超え、レビューに2日かかった |
| P16 | レビュー | レビューの依頼が2日間そのままになった |
| P17 | レビュー | コメントが必須なのか提案なのか分からず、やり取りが増えた |
| P18 | レビュー | 同じ指摘が、別の人に繰り返し出た |
| P19 | レビュー | 確認手順が書かれておらず、レビュー担当が動かし方を調べた |
| P20 | レビュー | レビューが1人に集まり、待ち時間が長くなった |
| P21 | レビュー | 設計に関わる指摘が、実装が済んだあとに出た |
| P22 | テスト | テスト項目を実装のあとに書き、仕様の抜けに気づくのが遅れた |
| P23 | テスト | 不具合の報告に再現手順がなく、確認のやり取りが増えた |
| P24 | テスト | 自動テストに20分かかり、結果を待たずに次の作業へ進んでいた |
| P25 | テスト | テスト用データを手で作っていて、人によって結果が違った |
| P26 | テスト | 修正した不具合が、別の修正でもう一度出た |
| P27 | テスト | 境界の値のテストが漏れ、総合テストで見つかった |
| P28 | テスト | テスト環境を2つのチームで使い、データが上書きされた |
| P29 | リリース | 手順書にない作業が当日に見つかり、30分延びた |
| P30 | リリース | 切り戻しの判断基準がなく、迷う時間が出た |
| P31 | リリース | 設定値の違いに気づかず、検証環境の値のまま反映した |
| P32 | リリース | リリースの知らせが当日になり、利用者からの問い合わせが増えた |
| P33 | リリース | リリース後に確認する項目が、人によって違った |
| P34 | リリース | 作業を1人で行い、手順を1つ飛ばした |
| P35 | 連絡 | 朝会が30分を超える日が続いた |
| P36 | 連絡 | 決まったことが記録されず、同じ話を2回した |
| P37 | 連絡 | 質問がチャットで流れ、返事がないままになった |
| P38 | 連絡 | 発注側への確認が、担当者ごとに別々に行われた |
| P39 | 連絡 | 不在の予定が分からず、レビューの依頼先に迷った |
| P40 | 連絡 | 進み具合の報告が「順調です」だけで、遅れに気づけなかった |
Tryの具体例40個(場面別)
P01〜P40のProblemに、同じ番号のTryが対応しています。どれも「誰が・いつまでに・何を・確認方法」の4つの要素に分けて書いてあります。
| No. | 場面 | 誰が | いつまでに | 何を | 確認方法 |
|---|---|---|---|---|---|
| T01 | 設計 | 設計担当 | レビューの前営業日の15時まで | 資料をチャットに載せる | 司会が開始時に、全員が読んだかを聞く |
| T02 | 設計 | 設計担当 | 次の設計書から | 画面ごとに、エラー時の動きの表を足す | 設計レビューのチェックリストに項目を追加 |
| T03 | 設計 | リーダー | 今週金曜まで | 用語集を作り、設計書のひな形からリンクする | 次の設計レビューで名前の不一致が0件 |
| T04 | 設計 | 変更した人 | 変更した当日中 | 設計書の変更履歴に1行書き、チャットで知らせる | 週次で変更履歴とチケットを見比べる |
| T05 | 設計 | PM | 設計の開始から3営業日以内 | 連携先への質問を質問票にまとめて送る | 未回答の件数を朝会で確認 |
| T06 | 設計 | 設計担当 | 次の設計書から | 1画面の設計書を、概要1枚と詳細に分ける | レビューの時間が1画面30分以内 |
| T07 | 設計 | PM | 来週の定例まで | 主要な3画面の応答時間の目標を発注側と決める | 要件定義書に数値が載っている |
| T08 | 実装 | 各担当 | 着手する前 | チケットを1日以内で終わる単位に分ける | 朝会で2日以上動かないチケットを確認 |
| T09 | 実装 | リーダー | 今週中 | 共通部品の一覧をREADMEに作る | 実装前に一覧を見ることをチェックリストに追加 |
| T10 | 実装 | 各担当 | 毎朝の作業開始時 | 作業ブランチに最新の変更を取り込む | PRの競合の件数を週次で数える |
| T11 | 実装 | 直近で構築した人 | 今週金曜まで | つまずいた点を手順書に追記する | 次に入る人が手順書だけで1日以内に構築できる |
| T12 | 実装 | 全員 | 次のスプリントから | 30分進まなければ、相談用のチャットに書く | ふりかえりで相談の件数を数える |
| T13 | 実装 | リーダー | 来週水曜まで | ログの書式と出す場面を1ページにまとめる | コードレビューのチェックリストに追加 |
| T14 | 実装 | 実装担当 | 着手する前 | 受け入れ条件を3行でチケットに書き、設計担当に見せる | 受け入れ条件のないチケットが0件 |
| T15 | レビュー | 実装担当 | 次のPRから | 300行を目安に分け、超えるときは説明欄に理由を書く | PRの平均行数を週次で見る |
| T16 | レビュー | レビュー担当 | 依頼から1営業日以内 | 最初の返事をする。難しければ代わりの人を指名する | 朝会で1日を超えた依頼を読み上げる |
| T17 | レビュー | レビュー担当 | 次のレビューから | コメントの先頭に「必須」「提案」「質問」を付ける | PRのひな形にラベルの説明を載せる |
| T18 | レビュー | リーダー | 月末まで | 3回以上出た指摘を、静的解析の規則かチェックリストに入れる | 翌月に同じ指摘の件数を数える |
| T19 | レビュー | 実装担当 | PRを出すとき | 説明欄に確認手順と画面の画像を載せる | PRのひな形に欄を用意する |
| T20 | レビュー | リーダー | 次のスプリントの初日 | レビュー担当を2人1組の当番制にする | 1人あたりのレビュー件数を週次で見る |
| T21 | レビュー | 実装担当 | 実装を始める前 | 方針を5行で書き、レビュー担当に見てもらう | 方針を確認した人の名前をチケットに記録 |
| T22 | テスト | テスト担当 | 実装の着手と同じ日 | テスト項目の一覧を書き始める | 実装の完了時に項目の一覧がそろっている |
| T23 | テスト | PM | 今週中 | 不具合報告のひな形に、再現手順・期待する結果・実際の結果の欄を作る | 差し戻しの件数を週次で数える |
| T24 | テスト | 開発担当 | 来週金曜まで | 時間のかかるテスト上位5件を調べ、並列に走らせる | 実行時間が10分以内 |
| T25 | テスト | テスト担当 | 次のテスト開始まで | テスト用データを作るスクリプトを用意する | 2人が別々に実行して同じ結果になる |
| T26 | テスト | 修正した人 | 修正と同じPRで | 再発を防ぐテストを1件以上足す | レビューでテストの有無を確認 |
| T27 | テスト | テスト担当 | 次の機能から | 入力項目ごとに境界値の表を作る | テスト項目のレビューで表を確認 |
| T28 | テスト | リーダー | 今週中 | テスト環境の利用時間の予約表を作る | 上書きの連絡が0件 |
| T29 | リリース | リリース担当 | リリースの3営業日前まで | 検証環境で手順書を1回通す | 通した日と結果を手順書に記録 |
| T30 | リリース | PM | 次のリリースの1週間前まで | 切り戻す条件と判断する時刻を手順書に書く | リリース前の確認会で読み合わせる |
| T31 | リリース | 開発担当 | 今週金曜まで | 環境ごとの設定値の一覧表を作る | リリース手順に一覧との照合を追加 |
| T32 | リリース | PM | リリースの3営業日前 | 変更点を利用者向けの言葉で知らせる | 知らせた日を手順書に記録 |
| T33 | リリース | テスト担当 | 次のリリースまで | リリース後に確認する10項目を表にする | 確認結果を表に記入して残す |
| T34 | リリース | リーダー | 次のリリースから | 2人1組で、読み上げる役と実行する役に分ける | 手順書に2人の名前の欄を作る |
| T35 | 連絡 | 司会 | 明日から | 1人1分を目安にし、長くなる話は朝会のあとに分ける | タイマーで15分を計る |
| T36 | 連絡 | 会議の司会 | 会議の当日中 | 決定事項と担当をチケットに書く | 次の会議の冒頭で前回の決定事項を確認 |
| T37 | 連絡 | 質問した人 | 1営業日返事がないとき | 朝会で直接聞く | 未回答の質問の件数を週次で数える |
| T38 | 連絡 | PM | 今週中 | 発注側への質問を1つの表にまとめ、窓口を1人にする | 表の外で行われた質問が0件 |
| T39 | 連絡 | 全員 | 休みの1週間前まで | 共有カレンダーに予定を入れる | 朝会で今週の不在を確認 |
| T40 | 連絡 | 各担当 | 毎日の朝会で | 残りの作業時間を数字で言う | 残り時間のグラフを毎朝更新 |
期限や数値は一例です。自分のチームの周期(1週間、2週間など)に合わせて書き換えてください。
あいまいなTryを書き直す前後対比20例
Tryが実行されない理由の多くは、書き方にあります。「気をつける」「徹底する」「意識する」のような言葉で終わるTryは、誰が何をすれば完了なのかが決まっていないため、次回のふりかえりで結果を確かめられません。次の4つの要素に分けて書き直します。
| 要素 | 問い | 書き方 |
|---|---|---|
| 誰が | 動くのは誰か | 役割か名前を1つ。「全員」は、全員が同じ行動を取る場合だけ使う |
| いつまでに | 期限、または始める日はいつか | 日付、曜日、「次のPRから」のようなきっかけ |
| 何を | 完了したと言える行動は何か | 目に見える行動や成果物。数字を入れる |
| 確認方法 | できたことをどう確かめるか | 数える、記録を見る、別の人が試す |
| No. | あいまいなTry | 誰が | いつまでに | 何を | 確認方法 |
|---|---|---|---|---|---|
| 1 | コミュニケーションを増やす | リーダー | 来週月曜から | 毎日16時に10分の相談の時間を設ける | 2週間後に相談の件数を数える |
| 2 | 設定の間違いに気をつける | 開発担当 | 次のリリースまで | 設定値の照合を手順書の1項目にする | 手順書のチェック欄に記入がある |
| 3 | テストをしっかりやる | テスト担当 | 今週金曜まで | 入力項目ごとの境界値の表を作る | テスト項目のレビューで表を確認 |
| 4 | ドキュメントを整備する | 直近で環境を作った人 | 水曜まで | READMEに環境構築の手順を10行で書く | 別の1人が手順どおりに構築できる |
| 5 | レビューを丁寧にする | レビュー担当 | 次のPRから | チェックリストの8項目を見てから承認する | PRのコメントに「確認済み」と書く |
| 6 | 早めに相談する | 全員 | 明日から | 30分進まなければ相談用のチャットに書く | 次回のふりかえりで件数を数える |
| 7 | 見積もりの精度を上げる | 各担当 | 次のスプリント計画まで | 終わったチケットの見積もりと実際の時間を表に記録する | 差が2倍を超えたチケットを計画時に見直す |
| 8 | 仕様をよく確認する | 実装担当 | 着手する前 | 受け入れ条件を3行で書き、設計担当に見せる | チケットに確認者の名前が入っている |
| 9 | 情報共有を徹底する | 会議の司会 | 会議の当日中 | 決定事項をチケットに書く | 次の会議の冒頭で確認 |
| 10 | 自動化を進める | 開発担当 | 月末まで | テスト用データの作成をスクリプトにする | 手作業の手順が手順書から消えている |
| 11 | スケジュールを意識する | 各担当 | 毎日の朝会で | 残りの作業時間を数字で報告する | 残り時間のグラフが毎日更新されている |
| 12 | 品質を上げる | 修正した人 | 不具合の修正と同じPRで | 再発を防ぐテストを1件以上足す | レビューでテストの有無を確認 |
| 13 | リリース作業を慎重に行う | リリース担当 | リリースの3営業日前まで | 検証環境で手順書を通す | 手順書に通した日を記録 |
| 14 | 朝会を短くする | 司会 | 明日から | タイマーを15分に合わせ、超える話題は別の時間に移す | 1週間の朝会の時間を記録 |
| 15 | レビュー待ちを減らす | リーダー | 次のスプリントの初日 | レビューの当番表を作る | 待ち時間の平均を週次で見る |
| 16 | リファクタリングする | 開発担当 | 次のスプリント内 | 重複した入力チェック3か所を1つの関数にまとめる | 既存のテストがすべて通る |
| 17 | ログを見やすくする | リーダー | 来週水曜まで | ログの書式を1ページにまとめる | 新しいコードのレビューで書式を確認 |
| 18 | 新しく入った人を支える | 指名された相談役 | 最初の2週間 | 毎日15分の質問の時間を取る | 2週間後に本人へ困りごとを聞く |
| 19 | 発注側と認識を合わせる | PM | 毎週の定例で | 画面を動かして見せる時間を10分取る | 議事録に指摘の件数を書く |
| 20 | ふりかえりを活かす | 司会 | 次回のふりかえりの冒頭 | 前回のTryの結果を5分で確認する | Tryの表の「結果」欄がすべて埋まっている |
書き直すときは、「それは、次のふりかえりで完了か未完了かを言えますか」と問いかけると、足りない要素に気づけます。
30分・60分・90分の進行表
使える時間に合わせて3つの進行表を用意しました。
30分(週次・少人数向け)
| 時刻 | 時間 | やること |
|---|---|---|
| 0:00〜0:03 | 3分 | 前回のTryの結果を確認する |
| 0:03〜0:10 | 7分 | KeepとProblemを各自で書く |
| 0:10〜0:18 | 8分 | 1人ずつ読み上げて共有する |
| 0:18〜0:26 | 8分 | 対象を1〜2個に絞り、Tryを考える |
| 0:26〜0:30 | 4分 | Tryを4つの要素で書き、担当と期限を読み上げる |
60分(隔週・標準)
| 時刻 | 時間 | やること |
|---|---|---|
| 0:00〜0:05 | 5分 | 前回のTryの結果を確認する |
| 0:05〜0:15 | 10分 | KeepとProblemを各自で書く |
| 0:15〜0:30 | 15分 | 共有し、似た内容をまとめる |
| 0:30〜0:35 | 5分 | 投票で2〜3個に絞る |
| 0:35〜0:52 | 17分 | 絞った対象ごとにTryを考える |
| 0:52〜1:00 | 8分 | Tryを4つの要素で書き、担当と期限を読み上げる |
90分(工程やリリースの区切り向け)
| 時刻 | 時間 | やること |
|---|---|---|
| 0:00〜0:10 | 10分 | 期間中の出来事を時系列で並べ、前回のTryを確認する |
| 0:10〜0:25 | 15分 | KeepとProblemを各自で書く |
| 0:25〜0:45 | 20分 | 共有し、場面別(設計・実装・レビューなど)にまとめる |
| 0:45〜0:50 | 5分 | 休憩 |
| 0:50〜1:00 | 10分 | 投票で3個に絞る |
| 1:00〜1:20 | 20分 | 絞ったProblemの原因を掘り下げ、Tryを考える |
| 1:20〜1:30 | 10分 | Tryを4つの要素で書き、次の工程の計画に入れる |
| 人数・周期 | おすすめの進行表 |
|---|---|
| 3〜5人、毎週 | 30分 |
| 5〜8人、隔週 | 60分 |
| 工程の終わり、リリース後、長い期間をふりかえるとき | 90分 |
KPTのテンプレート
記入用(Markdown)
## ふりかえり(KPT) 2026-10-05
参加者:
対象の期間:
### 前回のTryの結果
| No. | Try | 誰が | 状態(完了・途中・未着手) | 結果のメモ |
|---|---|---|---|---|
| 1 | | | | |
### Keep(続けたいこと)
| No. | 場面 | 内容(行動と結果) | 書いた人 |
|---|---|---|---|
| K1 | | | |
### Problem(困ったこと)
| No. | 場面 | 内容(出来事と数字) | 書いた人 | 票 |
|---|---|---|---|---|
| P1 | | | | |
### Try(次に試すこと)
| No. | 対応するProblem | 誰が | いつまでに | 何を | 確認方法 |
|---|---|---|---|---|---|
| T1 | | | | | |
記入用(タブ区切り)
表計算ソフトのA1セルに貼り付けて使います。種類の列に Keep・Problem・Try のどれかを入れると、並べ替えや絞り込みができます。
日付 種類 場面 内容 書いた人 票 誰が いつまでに 確認方法 状態
2026-10-05 Keep レビュー PRを300行以内に収め、当日中にレビューが終わった 開発A
2026-10-05 Problem レビュー レビューの依頼が2日間そのままになった 開発B 4
2026-10-05 Try レビュー 依頼から1営業日以内に最初の返事をする 司会 レビュー担当 次のPRから 朝会で1日を超えた依頼を読み上げる 未着手
Tryの管理表と完了率の数式
決めたTryは、次回まで見える場所に置いておきます。次の表を貼り、状態の列を更新していきます。
No. Try 誰が 期限 確認方法 状態 結果のメモ
1 レビュー依頼に1営業日以内で最初の返事をする レビュー担当 2026-10-16 朝会で1日を超えた依頼を読み上げる 完了 平均の待ち時間が2日から半日になった
2 検証環境で手順書を1回通す リリース担当 2026-10-14 通した日を手順書に記録 完了 手順の抜けを1件見つけた
3 共通部品の一覧をREADMEに作る リーダー 2026-10-09 チェックリストに追加 途中 一覧は作成済み、チェックリストがまだ
4 テスト用データを作るスクリプトを用意する テスト担当 2026-10-16 2人で実行して同じ結果 未着手 次回へ持ち越し
5 朝会を15分で終える 司会 2026-10-06 タイマーで計る 完了 平均13分
| 知りたいこと | 数式 | 結果 |
|---|---|---|
| 完了したTryの件数 | =COUNTIF(F2:F6,"完了") |
3 |
| Tryの件数 | =COUNTA(F2:F6) |
5 |
| 完了率 | =COUNTIF(F2:F6,"完了")/COUNTA(F2:F6) |
0.6 |
完了率が低い状態が続くときは、Tryの数を減らすか、4つの要素が書けているかを見直します。 5個決めて2個できるより、2個決めて2個できるほうが、次のふりかえりに弾みがつきます。
KPT・YWT・KPTA・Fun/Done/Learn・4Lsの比較
ふりかえりの手法はKPTだけではありません。枠の分け方が違うと、出てくる意見も変わります。
| 手法 | 枠 | 向いている場面 | KPTとの違い |
|---|---|---|---|
| KPT | Keep・Problem・Try | 定期的な業務の改善、チームのふりかえり | ― |
| YWT | やったこと・わかったこと・次にやること | 研修のあと、個人の経験の整理 | 問題からではなく、行ったことと学びから始める |
| KPTA | Keep・Problem・Try・Action | Tryが実行されにくいチーム | Tryを「案」とし、実行する行動をActionとして分けて書く |
| Fun/Done/Learn | 楽しかったこと・やったこと・学んだこと | チームができたばかりの時期、前向きな空気をつくりたいとき | Problemの枠がなく、前向きな面に目を向ける |
| 4Ls | Liked・Learned・Lacked・Longed for(よかった・学んだ・足りなかった・望んだ) | 長い期間や大きな区切りのふりかえり | 学びと要望の枠があり、気持ちの面も拾いやすい |
KPTとYWTの違い
| 比べる点 | KPT | YWT |
|---|---|---|
| 出発点 | よかったことと困ったこと | 行ったこと(事実) |
| 中心になる問い | 何を続け、何を変えるか | そこから何がわかったか |
| 得意なこと | チームの進め方の改善 | 個人や小さなチームの学びの言語化 |
| 最後の枠 | Try(試すこと) | 次にやること |
| 向いている周期 | 週次・隔週の定例 | 研修や作業の区切り、日報や週報 |
選び方
| こんなとき | 選ぶ手法 | 理由 |
|---|---|---|
| 毎週・隔週で進め方を少しずつよくしたい | KPT | 枠が少なく、短い時間で回せる |
| Tryが決まっても実行されないことが続く | KPTA、またはTryを4つの要素で書くKPT | 行動と担当をはっきり分けて書ける |
| 学んだことを言葉にして残したい | YWT | 「わかったこと」の枠がある |
| チームができたばかりで、Problemを出しにくい | Fun/Done/Learn | 前向きな話題から始められる |
| 工程やリリースの区切りで広くふりかえりたい | 4Ls | 学びや要望まで拾える |
| KPTが続いて、意見が似通ってきた | YWTやFun/Done/Learnに1回切り替える | 問いが変わると、違う意見が出やすい |
この記事のTryの書き方(誰が・いつまでに・何を・確認方法)は、KPTAのActionにあたる内容をTryの中に書き込む形です。枠を増やさずに同じ効果を得られるので、すでにKPTを使っているチームでもそのまま取り入れられます。
続けるためのコツ
| 起きやすいこと | こうするとよい |
|---|---|
| Problemばかりが並び、空気が重くなる | Keepから先に書いて共有する。Keepが少ない人には司会が問いかける |
| 毎回同じProblemが出る | 前回のTryが4つの要素で書かれていたかを確かめ、書き直す |
| 発言する人が偏る | 話す前に、全員が黙って書く時間を取る |
| Tryが多すぎて手が回らない | 投票で絞り、1回につき3個までにする |
| Problemが個人への指摘になる | 「何が起きたか」と「数字」で書き直す |
| 意見が出なくなってきた | 場面(設計・実装・レビュー・テスト・リリース・連絡)を1つずつ読み上げて思い出す |
よくある質問
Q. KeepとProblemは、どちらから書けばよいですか? A. Keepからがおすすめです。うまくいったことを先に共有すると、Problemも落ち着いて出しやすくなります。書く時間は両方まとめて取り、読み上げるときにKeepを先にします。
Q. Tryは何個決めればよいですか? A. 1回のふりかえりで3個までが目安です。少なく決めて確実に終えるほうが、次回のKeepが増えて続けやすくなります。
Q. 1人でもKPTはできますか? A. できます。週の終わりに、Keep・Problem・Tryを1〜2行ずつ書くだけでも効果があります。学んだことを中心に残したい場合は、YWTのほうが書きやすいこともあります。
Q. 具体例をそのまま使ってもよいですか? A. 書き出しのきっかけとして使い、数字や担当を自分のチームの出来事に置き換えてください。一覧を場面ごとに読み上げて「似たことはありましたか」と聞くと、意見が出やすくなります。
まとめ
- KPTは、Keep(続けたいこと)・Problem(困ったこと)・Try(次に試すこと)の3つの枠で行うふりかえり
- Keepは行動と結果を、Problemは出来事と数字で書く
- Tryは「誰が・いつまでに・何を・確認方法」の4つの要素で書くと、次回に結果を確かめられる
- 具体例120個(Keep 40・Problem 40・Try 40)は、設計・実装・レビュー・テスト・リリース・連絡の場面別に使える
- 時間は30分・60分・90分から、人数と周期に合わせて選ぶ
- 1回に決めるTryは3個まで。完了率を数式で出し、次回の冒頭で確認する
- 学びを残したいときはYWT、前向きな空気をつくりたいときはFun/Done/Learn、区切りで広く見たいときは4Lsが選択肢になる
参考
- アルー株式会社「KPT法とは」https://service.alue.co.jp/blog/KPT-method (KPT・YWT・Fun/Done/Learn・KPTA・4Lsの枠と向いている場面)
本記事の内容は、ご自由にお使いください。
ご利用の際は、出典として本ページへのリンクを記載いただけますようお願いします。
(記載例)出典:株式会社RJC「KPTのやり方と具体例120個 テンプレートとYWTとの違い」
株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。
WE ARE HIRING
RJCで一緒に開発しながら、
成長を楽しみませんか?
RJCは、Web・モバイル・AIを活用した開発プロジェクトで、テックリードやPM・PMOも活躍するシステム開発会社です。会社を知る、待遇を確かめる、話を聞いてみる。気になるところ見てみてください!
- 127日年間休日
- 12時間平均残業時間
- 毎日ガチャ遊びココロも大切にする福利厚生。アマギフなどの賞品ラインナップ!
ほかにも、チケットレストラン、書籍読み放題、2年ごとの慰労報奨(休暇 or 金一封)、11期連続の黒字決算。