KPT アンチパターン 〜失敗事例紹介〜

はじめに

KPT (Keep/Problem/Try) 等のふりかえりで、K (Keep) ネタを増やすみんなの工夫 というのを見て「あるある」と思ったので、KPTをやってみてこれはよくなかったとか、これは失敗だったなぁという自分の経験をまとめてみます。
振り返りの手法としては、KPT、YWT、Fun/Done/Lean、Celebration Gridなどがありますが、一番有名なのはKPTなのかもしれないですね。

失敗その1 Tryが振り返りの度に溜まっていく

個人的にKPTあるある第1位はこれじゃないかなと思います。特に振り返りの経験が少ないと、たくさん改善しようと思いTryをたくさん考えてしまいます。忙しかったりすると実際にTryが行われる訳でもなく…次回の振り返りでさらにTryが積まれ、実施される事のないTryがたくさんある状態になりがちです。また、Problemが並ぶとエンジニア的には課題には解決策を考え無いといけないと思いがちな所為もあると思います。
Tryがどんどん積み上がっていくのは精神的にも嬉しくないですし、振り返りしても改善が行われないので振り返り自体が無駄なのでは？という意見が出たりもします。

対策

個人的には以下が有効だと考えます。

• たくさんTryを考えるのではなく、実行されると一番効果がありそうなTryに絞る
• 実施されないTyrは一旦タスクから削除する（実施されないと問題な場合は再度Problemとして上がってくる事が多い）

失敗その2 Tryが実施されない

Tryの数を少なくしたり重要なものに絞ったりしても、忙しくて実施されないという場合があります。実施されないと何も状況は変わらないので、こちらもその1と同じように振り返り無駄なのでは？といった意見が出たりします。また、実施不可能な事をTryにしていたり、最初のアクションが不明瞭なままTryにしているケースもあります。

対策

個人的には以下が有効だと考えます。

• Tryの実施に時間と期日を割り当て、とにかく期日までには実施する
• 実施可能なTryにする
• 粒度が荒かったり、簡単には実現できない時はまず最初のアクションと期日を決める

失敗その3 KPT（振り返り）に時間がかかる

炎上プロジェクトの途中で振り返る場合は、時間をかけてProblemを議論するのがいいと思いますが、プロダクトチームで定期的に振り返りを行なっている場合、ファシリテーターが時間配分を考えず深堀りしているとMTGの時間が長引いてしまいがちです。また、潜在的な問題が多いのに振り返りの間隔が長いと単純にProblemが多く、話すのに時間がかかってしまいます。

対策

個人的には以下が有効だと考えます。

• ファシリテーターはタイムキーピングしつつ深堀りするトピックを選ぶ
• KPTの開催間隔が妥当なのか検討する

失敗その4 KPTの時間がしんどく（ツラく）なる

これは冒頭のKeepを増やす案を募集しているのと一緒ですが、毎回Problemについて会話しているとTryを実施していても改善を感じにくくなってきます。問題が毎回発生しているチーム=ダメだ…ってなりがち。プロダクトチームで定期的にKPTを実施しているとこんなパターンに陥りがち。反省するのも悪くはないですが、程々に。単に運が悪い時もあります。

対策

個人的には以下が有効だと考えます。

• ポジティブに振り返りを実施する
• Keepの時間を増やし良いところや改善点を認識する
• YWT、Fun/Done/Lean、Celebration Gridなど別に手法に変える

失敗その5 Keepがあまりでない

定期的にKPTをするとなると、Keepが大事になってきます。ただし、Keepを続けたい事にしてしまうとあまり出てこなかったりもします。

対策

個人的には以下が有効だと考えます。

• ポジティブに振り返りを実施する
• 感謝を伝える、よかった事やポジティブになれるような事も記載する
• YWT、Fun/Done/Lean、Celebration Gridなど別に手法に変える

失敗その6 外から来た人がダメ出しをして人間関係が険悪になる

わりとパンチのあるネタです。とあるプロジェクトが上手くいっていなかったのでKPTを実施し、Problemを洗い出す。こう聞くと良さそうですが、その洗い出し方や指摘の仕方が悪いと「アイツの言っていることは正しいが、一緒に仕事をしたくない」という状態になります。似たようなものに、ややトラブっているプロジェクトに新しいPjMがやってきて課題をビシバシと指摘し厳しく対策を要求したら「あのPjMとは一緒に仕事ができません」となったプロジェクトを見た事があります。まぁ、そのプロジェクトはその後僕がPjMする羽目になったんですが…。似た事例としては組織のマネージャーなどでも見た事があります。転職や異動で新しくやってきた人が、過去の事情を知らずにダメ出しをしまくり、あの人とは仕事ができません、となるパターンです。我々はみな人間なので関係性が大事ですね。

対策

個人的には以下が有効だと考えます。

• 伝え方に気をつける
• 関係性に気をつけ、過去の事情も考慮する

失敗その7 振り返ろうとしたが、思い出せない

KやPを書こうとした時に「あれ、なんだっけ…」、「なにかあったけど思い出せない…」となる時があります。これには大体二つのパターンがあって、「期間が長すぎるので何があったのかもう思い出せない」パターン、これは長いプロジェクトをやっていると細かい事などを忘れてしまったり、プロジェクトが完了してしばらく日数が経ってから振り返ろうとする時に起こりがちです。もう一つのパターンとしては、「色々起きたので忘れてしまう」パターンです。色々なことが起きると印象の強い事は覚えていますが、そうでない事は忘れてしまいます。例えば、障害の対応について振り返ろうとすると細かい時系列は解らなくなってしまったり、2週間に1度振り返っている時に、直近で障害が起きるとその事はよく覚えているものの、「先週ってなにやったっけ…」となりがちです。

対策

個人的には以下が有効だと考えます。

• 時系列で起きたイベントを事前にまとめ、それを見ながら振り返る

長いプロジェクトなら月毎にイベントをまとめておくとか、障害時ならば発生時刻から終了時刻までに行った対応があると振り返りやすいです。

#おわりに
あまりまとめた事がなかったので、まとめてみました。
いかがでしたか？

また何か思い出したり、やらかしたら追記したいと思います。

2021/10/06 その7追記
2023/07/04 QiitaからZennにも記載してみました