KPTによるプロジェクト振り返り

こんにちは、土居です。

ここのところ参画しているプロジェクトで、より問題点を明確にして解決していくために、KPTを取り入れた振り返りが始まりました。

弊社ではまだ始まったばかりですが、実は以前勤めていた会社でもKPTを使っていた時期がありました。

KPTは（Keep/Problem/Try）の略で、割と有名な手法ではあり、解説記事もたくさんあるかと思います。今回はKPTがどういうものかといった説明は割愛させていただきまして、これまででうまくいったと感じる部分や、そうでなかった（難しかった）部分を紹介しつつ、これからのKPT運用に生かしたいと思います。

Keep

いきなりですが、個人的にKPTで一番難しいと思っているのがこちらです。プロジェクトであった様々な「よかったこと」を挙げていくのですが、以前は単に事実（無事リリースが完了した、ある問題に対処できた、など。。）を挙げていくだけで終わりがちでした。
一口に良かったことといっても、できればそこから成功の要因となった持続可能な手段を抽出し、今後にも生かしていけるとさらに良いのかなと思います。
Problemは対処がおわったら消していましたが、Keepの中でもそういった生かしていけるものは残して毎回目につくようにしておくのも良さそうです。

Problem

こちらは割合シンプルで、プロジェクトを進める上で問題が何も起きないといったことはまずないと思います。いくらでも思いつき、ともすれば溢れかえることもあります。
そもそも状況・環境的に仕方ない問題に対しての愚痴みたいなものが並んでしまうこともありました。。ですので、具体的な解決策（システマチックならなお良し）が考えうるものに絞りたいところです。

Try

Problemで上がったものに対して、ではどうやって解決するのか？誰がやるか？といったことを列挙します。Problemには、ある対処をすればそれで解決できるものもあれば、ある程度継続して意識をもっていくことで改善していくといった性質のものもあるかと思います。前者はタスク・チケット化できますが、後者はTryに残しておくことで一部のKeep同様、振り返りの度に意識できるようにしたいです。

進行

主にプロジェクトリーダーがファシリテーターとよばれる進行役としてKPTを行っていくかと思いますが、慣れてきたらメンバーで交代してやっていくのも良かったです。普段は自タスクのみに必死でしたが、これをやってみると

• 全体視点（自分のタスクもあくまで一部）
• 他のリーダー以外のメンバーがどんな風に進行しているか
• ホワイトボードに何か書いて、人前で喋って。。ということがほぼなかったのでそういったこと自体

などなど、感じることが多く楽しかったです。

まとめ

語ってはきたものの、実はKPTについて書籍などでどういったものかしっかり学んだことがあるわけではありません。。ですが、Keep/Problem/Tryと３つにプロジェクト上の要素を分類し、定期的に皆で振り返ることはとても価値があると感じますので、振り返りをする上でやったことのなかった方は試してみてください！

MMMでは全領域で仲間を募集しています。興味を持って、話を聞いてみたいなと思っていただけた方がいらっしゃったら、下記よりご応募お待ちしております！

リモートワークで自社オウンドメディアを立ち上げたいWebプロデューサー募集
フルリモートワークでチームを率いるフロントエンド領域のテックリード大募集
リモートワークでAWSなサーバーレスシステムに携わりたいエンジニア大募集
リモートワークでチームを引っ張りたい経験豊富なUI/UXデザイナー大募集

どいけん