早速ですが、チーム開発をする際に振り返りを行っていますか？
なかなか振り返りを実施する時間が取れなかったり、実施はするもののその内容を活かせなかったりで定期的にしっかりと実施するのは難しいのではないでしょうか？
私のチームでもなかなか振り返りが運用にのらず、振り返りをするもののそこでの改善点を改善できなかったり、意見が出てこなかったりでうまくいっていませんでした。
そんな中でも振り返りを運用に乗せる方法があったので、その方法を紹介していきたいと思います。
振り返り手法
振り返りの手法はいくつかあります。その中でもKPTとYWTについて紹介したいと思います。
それぞれ詳しい手法については触れませんが、やってみた感想とどういったプロジェクトに向いていると感じたかを書いていきたいと思います。
KPTによる振り返り
KPTとはKeep, Problem, Tryの頭文字をとったものになります。
KPTは私が今まで一番やってきた手法になります。
良かったこと、よくなかったことをチームとして出していけるので、良かったことは褒め合い、よくなかったことはチームとして今後にどう活かしていけるのかを話すきっかけを作ることができました。
些細なことでもKeep, Problemともに出すことでチームとして現状の認識を合わせられると思います。
チームとして生産性の改善をしていきたい場合に向いていると感じています。問題点は問題点として次にどのように活かすかを話し合って進めていくので、現状の課題に向き合い、改善していくタイミングに向いていると思います。
YWTによる振り返り
YWTはやったこと、わかったこと、次やることの頭文字をとったものになります。
YWTは個人で振り返って次に何をやっていくかを考える際に向いている手法だなと感じています。
事実（やったこと）から何を得たか、その結果からネクストアクションを考えていくフレームワークなので、何かを改善していくというよりは、現状からより良くしていくのに向いているフレームワークだと感じています。
両方経験してみて感じたこと
KPT, YWTともに、振り返りのフレームワークとしては扱いやすいものだと感じています。
３ステップで次に何をしていくのかまで決めることができるので、手軽に次のアクションを決めることができます。
どちらのフレームワークで行うかは、それぞれのチームの状況によって変わってくると思いますが、状況に合わせたフレームワークを用いて振り返りを行うことで、より生産性の高いチームとなっていくと思います。
また、振り返りは一回やって終わりではないので、週次や隔週などで実施をし、ネクストアクションとして定めたものがどうだったかといった観点でも振り返っていくことでより良いチームづくりができるのではないでしょうか。
