会社案内ダウンロードMMMブログ2019-04-05KPTによるプロジェクト振り返りこんにちは、土居です。ここのところ参画しているプロジェクトで、より問題点を明確にして解決していくために、KPTを取り入れた振り返りが始まりました。弊社ではまだ始まったばかりですが、実は以前勤めていた会社でもKPTを使っていた時期がありました。KPTは(Keep/Problem/Try)の略で、割と有名な手法ではあり、解説記事もたくさんあるかと思います。今回はKPTがどういうものかといった説明は割愛させていただきまして、これまででうまくいったと感じる部分や、そうでなかった(難しかった)部分を紹介しつつ、これからのKPT運用に生かしたいと思います。Keepいきなりですが、個人的にKPTで一番難しいと思っているのがこちらです。プロジェクトであった様々な「よかったこと」を挙げていくのですが、以前は単に事実(無事リリースが完了した、ある問題に対処できた、など。)を挙げていくだけで終わりがちでした。一口に良かったことといっても、できればそこから成功の要因となった持続可能な手段を抽出し、今後にも生かしていけるとさらに良いのかなと思います。Problemは対処がおわったら消していましたが、Keepの中でもそういった生かしていけるものは残して毎回目につくようにしておくのも良さそうです。Problemこちらは割合シンプルで、プロジェクトを進める上で問題が何も起きないといったことはまずないと思います。いくらでも思いつき、ともすれば溢れかえることもあります。そもそも状況・環境的に仕方ない問題に対しての愚痴みたいなものが並んでしまうこともありました。具体的な解決策(システマチックならなお良し)が考えうるものに絞りたいところです。TryProblemで上がったものに対して、ではどうやって解決するのか?誰がやるか?といったことを列挙します。Problemには、ある対処をすればそれで解決できるものもあれば、ある程度継続して意識をもっていくことで改善していくといった性質のものもあるかと思います。前者はタスク・チケット化できますが、後者はTryに残しておくことで一部のKeep同様、振り返りの度に意識できるようにしたいです。プロジェクトリーダーがファシリテーターとよばれる進行役としてKPTを行っていくかと思いますが、慣れてきたらメンバーで交代してやっていくのも良かったです。普段は自タスクのみに必死でしたが、これをやってみると全体視点(自分のタスクもあくまで一部)他のリーダー以外のメンバーがどんな風に進行しているかホワイトボードに何か書いて、人前で喋って。いうことがほぼなかったのでそういったこと自体などなど、感じることが多く楽しかったです。まとめ語ってはきたものの、実はKPTについて書籍などでどういったものかしっかり学んだことがあるわけではありません。Keep/Problem/Tryと3つにプロジェクト上の要素を分類し、定期的に皆で振り返ることはとても価値があると感じますので、振り返りをする上でやったことのなかった方は試してみてください!MMMでは全領域で仲間を募集しています。採用メンバー紹介リモートワーク健康管理ソリューション・サービスお問い合わせ見積もり依頼や詳しいご相談など、クラウド・AWSに関する困りごとをお気軽にご相談ください。以下のお問い合わせ先から受け付けています。お問合わせはこちら※通常1営業日内にご回答いたします。