振り返りを形骸化させないための KPT 実践ガイド

0. 自己紹介と記事を書くにあたっての背景

はじめまして。株式会社ブレーンバディでエンジニアリングマネージャーをしている服部です。
弊社はセールステック領域のSaaSを開発しており、現在は5人ほどの少数精鋭チームで日々開発を続けています。

この3か月、スプリントの振り返り（Retrospective）をKPTで徹底的に回した結果、手応えのある改善サイクルが回り始めました。「振り返りが形骸化してきたかも？」とモヤモヤしている方のヒントになればと思い、実例ベースでまとめます。

こんな人に読んで欲しい

• これからチームで振り返りを始めたいが、進め方に迷っている
• 週次ミーティングで KPT をやっているものの、成果が見えずマンネリ気味
• 「結局 Try が実行されない問題」に悩んでいる

1. TL;DR

• 人ではなくプロセスを見る：個人攻撃はゼロ、事実と仕組みにフォーカス
• Keep/Problem の“呼び水”を用意：ファシリテータが数件仕込んでおくと議論が滑り出す
• 翌週の冒頭で Try をレビュー：実行・未実行の理由まで掘り下げることで学びが定着する

2. 事前準備と会議の冒頭の進め方について

前週のTryを会議メモに書いておく

私たちは、会議メモを見ながらMTGを行っていますが、その会議メモの振り返りパートには事前に前週のTryを書いておくようにしています。
そして、ファシリテーターはその振り返りをぼんやりでいいので事前にしておきます。

振り返りは前週のTryがどうだったかというところから始めます。

• 実行できたかどうか。
• 実行できた/できなかった場合、それはなぜか？
• 実行できた場合、価値のある取り組みだったか？

そのような点について、特にそのトピックに関わるメンバー中心に話を聞いていきます。

いくつかProblemとKeepを見繕っておく

いきなりProblemとKeepをといってもすぐに思い浮かばない人も多いです。
これは自然な反応です。
そのため、ファシリテーターはProblemとKeepを事前にいくつか見繕っておきます。

そしてこういう点は良かったよね。というコメントからKeepの話題をするように刺激していきます。
Problemの時も同様です。
こうやって、事前に準備しておいたトピックを誘い水のように投げ入れます。
その話題について会話していると振り返りのモードにスイッチが入り、「そういえばこう言うKeep/Problemがありましたよね！」というような発言がメンバーから出てきます。

3. 当日のファシリテーション ―― 私が気をつけている５つのこと

人ではなくプロセスを責める

人に問題がある場合の対応は、1on1などの個別コミュニケーションで行うべきです。皆の前で叱責しても意味はありません。
振り返りの場は、メンバー全員が知恵を持ち寄り、プロセスに目を向ける時間です。そのためには心理的安全性が不可欠です。個人攻撃が生じれば、心理的安全性は損なわれます。
とはいえ、心理的安全性は「仲良しクラブ」を作るためのものではありません。本質的な問題解決を進めるには、誰もが心理的ハードルなく率直に意見を述べられることが重要です。そうしてこそ、チームのポテンシャルを最大限に引き出せます。

全員に話を振る

チームで振り返りをする意味は多角的な視点を得ることにもあります。
1人の振り返りであれば、マネージャーが振り返れば済むのです。
見ている風景・解釈はメンバーによって異なります。
なぜそのような風景が見えているのかをできるだけ多くの観点から事実収集することが大事です。

副次的な効果ですが、メンバーのレベル感を測るのにも役立ちます。
振り返りの質は会話していけば、おのずと見えてきます。
正しいレベル感を把握し、適切な育成・マネジメントに活かすことにも繋げていってください。

事実ベースで振り返る

メンバーの解釈は解釈で大事です。ただそれも事実として捉えましょう。
「メンバーはこのような解釈をしている。」という事実としてです。

そして、純粋な事実ベースの振り返りをするために4Wでの質問の型を活用します。
質問の型：「それって いつ・どこで・誰が・何が 起きた？」
事実としてはこういうことがあった。だからこうするという結論を出すことが大事です。

KeepまたはProblemどちらかに偏重しないようにする

弊社の開発組織だと、謙虚なメンバーが多く、Problemが多くでがちです。
ProblemとKeepはバランスよくでるのが理想です。
もちろん同数になるように無理に調整する必要はありません。
両方の側面にちゃんと目を向けることができていれば大丈夫です。
ファシリテーターはどちらの話題にも触れられるように、時間配分をしっかり行いましょう。

必ずTryに落とし込み、翌週Tryを振り返る

振り返りで得た気づきは、必ず具体的なアクションに落とし込みましょう。ここが最重要ポイントです。アクションが定義されない、あるいは定義されても実行されないのであれば、振り返りの価値はほぼゼロになります。

その際に注意すべきは、壮大な Try を掲げないこと。来週確実に自分たちが実行できるレベルに落とし込むことが肝心です。実現可能性が怪しいものは「チャレンジ」として記録し、翌週に達成可否を検証する程度に留めましょう。

「来週確実にできる Try」を最低でも一つ設定する ― これを強くおすすめします。たとえ小さな一歩でも、年間 12 か月 × 4 週で約 50 回の改善になります。小さな一歩を積み重ねれば 50 歩の前進です。大きな改革を一度にやりきろうとせず、継続可能なペースで改善を重ねていきましょう。

最後に. 価値ある振り返りを実践するためのチェックリスト

1️⃣ 会議前

• 前週のTryを会議メモに記載しておく。
• ファシリテータが前回Tryを軽く予習し、論点と質問を整理しておく。
• 議論がスムーズに開始できるように、Keep/Problemの“呼び水”を数件用意しておく。

2️⃣ 会議中

2-A. 振り返りフェーズ

• 前週Tryの実行可否・理由・価値を確認する。
• 4W（When / Where / Who / What）で事実を掘り下げ、解釈と分けて扱う。
• 全員に発言を促し、多角的な視点で振り返る。
• プロセスにフォーカスして心理的安全性を守る。
• KeepとProblem のバランスを意識し、時間配分を調整する。

2-B. Try 設定フェーズ

• 「来週確実に実行できるTry」を最低1つは決定する。
• 実現可能性が怪しい案は「チャレンジ」と区分し、翌週に検証予定を立てる。

3️⃣ 会議後〜翌週

• 決定したTryをドキュメントに記録しておく。
• 翌週の会議冒頭でTryの実行状況をレビューし、学びを定着させる。