9月もそろそろ終わりです。こんにちは。

このツイートを拝見して、KPTについて自分なりに振り返ることがあったのでメモ的に書いていきます。

KPTとは

KPTとは、ある期間の仕事をチームで振り返り、業務改善を加速するフレームワークのひとつで、Keep・Problem・Tryの頭文字をとって、「ケプト」とか「ケーピーティー」とか言われます。

1週間とか2週間とか定期的に、もしくはプロジェクトの終わりに総括としてやることが多く、成功体験として続けたいこと、課題と感じていること、もっといいやり方として次に活かし実行したいことを、付箋を貼り付けながらチーム全員で書き出して議論していきます。

担当している00:00 StudioのiOSチームではMiroを使って1週間おきにやっています。小さくて見づらいんですが、緑の付箋がKeep、ピンクがProblem、黄色がTryです。

似たような手法として、

- YWT(やったこと・わかったこと・つぎやること)
- 4Ls(LIKED・LEARNED・LACKED・LONGED FOR)

などいろんな手法がありますが、仕事を振り返り、次の改善につなげるというフレームワークとしては一緒です。

KPTをなぜやるのか

業務改善のため

繰り返しになりますが、KPTをやるのは「次の業務の改善につなげる」ことが第一義です。

- P ：技術的に難しいところをチャレンジしてるので、時間が思ったよりかかった -> T：ドキュメントにして会社の知見にしとけば次やる人は早いからやろう
- P：開発スケジュールが全体方針に合ってない気がする -> T：見直して優先順位直そう

実際にあった例ですが、こんな感じでProblemを糧にして、業務をよりよくする、というのが振り返りの本質です。

チームのコンディションの把握

ただ、マネジメントに片足突っ込んでいる身としては「チームの健康状態を確認する」という意義も強いと思っていたりします。

KPTを繰り返す中で、Keepが増えてきて、Problemが少なくなってきて、Tryが常に実行されている、となれば感覚的には「チームはうまく回っている≒健康状態がいい」と言えそうです。

Keepを積極的に発言できるように促す、出てきたProblemを速やかにTryに移して解決する、ができていれば自然とこういう状態になる、という経験があります。

KPTの起こりがちなエラー

ただ、KPTをファシリテーションする、もしくはチームのマネジメントをする役割がある場合には注意が必要だと思っています。

例えば、Keepがたくさん出る状態は感覚的には良いように思うのですが、チームの状態が常に良く、取立てていうほどでは無いのが続いているのであればKは逆に少なくなります。

常に業務の進捗が良いチームが、Keepであえて「進捗が良い！」とは書きません。

ProblemやTryが少なくなってくるのはうまく回っている証左にも見えますが、業務に慣れて、課題意識が減少しているだけかもしれません。

KPTと心理的安全性

逆に、一番やばい兆候は、Problemが出なくなっていることです。

これは、本当に業務に問題がなければいいのですが、チームメンバーの心理的安全性が確保されておらず、問題があっても発言できない状態になっている可能性があります。

マネジメントする側としては、問題があった時の迅速な対応、1on1やどうでも良さそうな雑談などでの信頼残高の獲得、今は使えない手法ですが一緒にご飯食べる、みたいなところでメンバーの心理的安全性を確保する必要があり、

これが担保されていない状態では、KPTに限らず、どんな振り返りも効果を発揮できないと考えています。

Pを積み残さない

次にやばいのは、Problemが積み残されて数週間、みたいな状況が続くことです。

プロジェクト外の力学で残ってしまったProblemでも、解決に向かって動くことを疎かにすると、チーム全体に「しょうがない感」が生まれ、緩やかに推進力が失われていきます。

これは結構厄介で、一度「しょうがない感」が生まれてしまうと、それがチームの文化にまで昇華されてしまって取り戻すのに時間がかかったりします。

こうなった場合、組織全体の業務の見直しや、体制変更を視野に入れて議論する必要があるのかなと思っています。

まとめ

メモ的なので乱雑ですが、KPTについて気にしていることを書きました。

KPTは良いフレームワークですが、習慣的に意識せずに使っていると、逆効果になったりもするんだろうな、気をつけないとな、という内容でした。

それではまた！