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期連続の黒字決算。

ABOUT RJC RJCがどんな会社か知る 考え方、研修、働き方、福利厚生、社員の前職まで。RJCのことが丸わかり! RJC丸わかりページへ JOB DESCRIPTION 仕事内容・待遇を見てみる 仕事内容、給与・待遇、選考の流れ。経験者も未経験も!応募前に知りたいこと、まとめました! 募集要項を見る ENTRY エントリーする エントリーは1〜2分・履歴書不要です。まずは話を聞いてみたい、という方でも歓迎です! エントリーフォームへ

RJCで一緒に開発しながら、 成長を楽しみませんか?