KPTが思いつかないときの10問｜出来事からKeep・Problem・Tryを作る記入例

思いつかない理由は、材料・問い・話しやすさで分ける

記憶が曖昧なら予定や作業メモを見ます。「よかったことは？」が広すぎるなら、助かった連絡や手戻りがあった場面まで問いを小さくします。何を話しても責められそうなら、無理に内容をひねり出させる問題ではありません。共有方法や進行を見直す必要があります。

会議の前に一人で書く時間を取り、書ける範囲で出来事を出す方法もあります。個人名を挙げて原因を決めつけるより、手順や条件を確認できる書き方にします。項目数を埋めること自体を目的にしないでください。

まず予定・連絡・作業メモから、出来事を拾う

対象期間を決め、会議、納品、問い合わせ、修正、判断待ちなどの記録を見ます。架空の3人チームは10月1日から7日の資料作成を振り返り、「初日に見本を共有した」「承認者が決まらず2日待った」を見つけました。

この段階では、よい・悪いを急いで決めません。誰が見ても同じ意味になりやすい出来事を短く書きます。記録がなく、日数が曖昧なら「約2日」「要確認」とし、確かな数字に変えないでください。

材料を探す10問：大きな成果より具体的な場面へ

一度に全部へ答える必要はありません。自分の記録に合う問いを二つほど選び、一つの出来事を書ければ十分です。分からない項目は空欄にし、会議で他の人の記憶と照合できます。

「連携不足」「頑張る」を、事実と行動へ直す

抽象語が出ること自体は問題ありません。その後に「どの場面で、何が分からなかったか」「次は誰が何をするか」を足します。本人の性格や意欲の問題へ飛ばず、確認可能な作業へ戻します。

架空チームの「連携不足」は、承認者が決まっていないまま資料を提出し、確認待ちになった場面です。次は承認者と確認日を着手時に決める、とすると試しやすくなります。

完成例：KeepとProblemを、Tryへつなげる

同じ出来事を複数の欄へ書いても構いません。見本共有を続ける一方、承認者の確認を加える、といった関係が見えると、次の作業を変えやすくなります。すべてのProblemから別々のTryを作る必要はありません。

Tryは、担当・場面・確認方法まで決める

「確認を徹底する」では、どの行動をしたら実施になるか分かりません。誰が、どのタイミングで、何を行い、どこに残すかを書きます。担当に権限がない決定は、承認する人も確認してください。

Atlassianの4LsはKPTとは別の方法ですが、出来事を振り返り、担当・内容・期限を行動計画に残す進め方を説明しています。本記事の例も、欄を埋めて終わらず次の行動へつなげるために使います。

• 出典：Atlassian：4Lsによる振り返りと行動計画（新しいタブ）

記録がないときは、覚えている一場面から始める

期間を短くし、「最後に終えた作業」「最後に待った連絡」などから探します。思い出せない部分をもっともらしく埋めず、事実の確認を次の作業にできます。「次週は待った場面を一行メモする」もTryです。

特に困ったことがなければ、無理にProblemを作る必要はありません。続けたい手順と、その効果をどう確認するかを話せます。発言の数を評価する進め方だと、事実と違う反省が増える可能性があるため、目的を共有してください。

次回は、Tryを実施できたかから確認する

まず実施の有無を確認し、できなかった場合は、時間、権限、対象の機会があったかを見ます。すぐに本人の意欲の問題へしないでください。実施しても待ち時間が変わらなければ、承認者の負担や確認方法など別の条件を調べます。

会議で相手へ改善を伝える場面はフィードバックの例文も参考になります。KPTは反省の上手さを競う場ではなく、次の作業を少し変え、その結果を確かめるために使ってください。