初のアドベントカレンダー投稿です。なんならQiitaに記事を投稿するのも初で緊張しているのですがノリで書いていきたいと思います。ノリで読んでいただけると幸いです。
はじめに
Phone Appli の開発チームがスクラムを導入して1年が経とうとしています。
私自身は Phone Appli で初めてスクラムを経験したのですが、予測不能で巨大なプロジェクトを達成するためにメンバー自身が計画を立てては遂行する仕組み、誰かの命令を聞くとか言われた通りにやるとかではなくてメンバーの1人1人が価値を生み出すことにリソースを割き責任をもつという思想に共感し面白さを感じています。
とりわけレトロスペクティブというイベントにその色は濃く表れていると思うのですが、このイベントは特に固定の手法が準備されているわけではなく、チームが状況に応じて手法を選択することができます。
そして世の中にはたくさんの手法があるのですが、どれを選ぶかによってこのイベントの方向性はガラッと変わていきます。この楽しさに目覚めちゃって色々つまみ食いをしたくなってしまっているこの頃です。
今日はここに、この1年で実践したレトロスペクティブ—ふりかえりの手法について備忘を兼ねて残していきたいと思います。
スクラムガイド2020における定義
そもそもレトロスペクティブってなんのこと？という方のために教科書を開いてみます。
スプリントレトロスペクティブの目的は、品質と効果を高める方法を計画することである。
スクラムチームは、個人、相互作用、プロセス、ツール、完成の定義に関して、今回のスプリントがどのように進んだかを検査する。多くの場合、検査する要素は作業領域によって異なる。 スクラムチームを迷わせた仮説があれば特定し、その真因を探求する。スクラムチームは、スプリント中に何がうまくいったか、どのような問題が発生したか、そしてそれらの問題がどのように解決されたか(または解決されなかったか)について話し合う。
スクラムチームは、自分たちの効果を改善するために最も役立つ変更を特定する。最も影響の大きな改善は、できるだけ早く対処する。次のスプリントのスプリントバックログに追加することもできる。
スプリントレトロスペクティブをもってスプリントは終了する。スプリントが 1 か月の場合、 スプリントレトロスペクティブは最大 3 時間である。スプリントの期間が短ければ、スプリン トレトロスペクティブの時間も短くすることが多い。
かなりざっくり説明するとこのイベントでは、今回のスプリントでうまくいったことや問題となったことについて話し合って、次のスプリントでより良い結果を出せるようにするためにどんなアクションをとるか決めていきます。
2020年のふりかえり
さて2020年にレトロスペクティブで採用した手法ですが下記の5つでした。
そんなに多くないとか言わないで。
KPT
Keep (よかったこと)、 Problem (課題)、 Try (次のスプリントで実践すること) を略して KPT です。
みんなからはけぷとって呼ばれています。
今回のスプリントのよかったこと・問題だったことを出し合って、次のスプリントで続けるべきこと・改善すべきことを決めていきます。
Phone Appli の開発チームは基本的に KPT を採用しています。一番慣れているから例えば他チーム同士でパッと集まってもすぐ実施できるのはいいところでしょうか。課外活動的なプロジェクトの反省会などでもお目にかかることが多いです。
KWT
Keep (よかったこと)、 Wakattakoto (わかったこと)、 Try (次のスプリントで実践すること) を略して KWT です。
こちらは KPT の変わり種。
KPT を採用したけれど、日本人の悲しい性か Problem という言葉が強すぎるのか当たり障りのない問題ばかり挙げられて本当に改善すべき問題が見て見ぬ振りをされている...という悩みを抱えていた時に採用された手法です。
Problem とどう違うの？という感想を言っているメンバーもいましたが、「Problem として挙げることで誰かを傷つけてしまうかもしれない」「雰囲気を悪くしてしまうかもしれない」という思いから Problem を書くのを遠慮してしまっていたメンバーがいつもよりサクサク意見を出している印象でした。
当時はこちらの記事 振り返りはKPT法より『KWT法』がオススメ を参考にしたと記憶しています (たしかそのはず...)
YWT
Yatta (やったこと)、 Wakattakoto (わかったこと)、 Tsugi (次にやること) を略して YWT です。
また KPT っぽい... かもしれませんが、最大の違いは経験に直結しているところでしょうか。KPT を実施するときに「よかったこと...うーん...何があったっけ... (タイムアップであんまり書き出せない)」なんていう場面を目にすることがありますが、YWT では思い出すまま書けば良いのでワークの間に手が止まりづらい印象でした。
ただし KPT のこの問題に関してはワークの前に何があったか思い出す時間を設けることで改善される気もします。
YWT と KPT の違いについては、こちらの KPTとYWTの違いは？～KPTがうまくいかない理由と、YWTの特性を考える という記事がわかりやすかったです。
Fun!Done!Learn!
語感がすでに楽しい!!
プロジェクト初期の成果物が出ないスプリントやチームビルディングをしている時期で、Keepにフォーカスして振り返ろう、という流れで採用されました。チームメンバーの興味の向き先やひととなりがいつもより滲み出ていて面白かったです。うまいこと Learn!! の枠に KPT でいう Problem のような項目が出ていたりしたのもツボでした。
詳しい方法はちらほら記事が見つかるのですが、出自をみると ファン・ダン・ラーン(FDL)ふりかえりボード が原典の模様ですのでこちらを貼っておきます。
象、死んだ魚、嘔吐
語感がすでに重い!!
Problem にフォーカスしたふりかえりです。ずっと問題を抱えていてもやもやしているけれどそこから脱却できない状態が続いている、ときに採用されました。
今チームが抱えている、メンバー各人が抱えている Problem をブレストして
象 (目を瞑れない大きな問題)、死んだ魚 (放っておくとますます悪化する問題)、嘔吐 (胸につかえている他と比べて個人的な問題)
の3つに分類し、インパクトが大きく自分たちで解決できるものを次Sprintの課題として対処しました。
当時は自分たちで解決することに注目していましたが、今思えばあまりに大きな問題はチームの妨害リストに入れたり、チーム外のメンバーと協力して対処したり対処の仕方があると思います。
よかったこととしては、個人的な悩みだと思っていたことが意外とチーム全体に関わるものだと明らかになったこと、レトロスペクティブの時間が終わるまでに解決策を捻り出そう (この時間を前向きに終わらせよう) という力が普段より強かったことでしょうか。
この手法はこちら、 Airbnb Story のなかで紹介されています。
さいごに
どんな手法を採用したとしても、チームがプロジェクトの中でよりプロダクトの品質を高め、より効果を高められるように計画をたて改善を続けよう、というレトロスペクティブの目的はブレません。
いつもおんなじ手法、でも実現できることだとは思うのですが、行き詰まりを感じたとき、なんだか飽きちゃったとき、チームのみんなで今までと違う手法を試してみたら、新鮮な気持ちで自分たちを見つめ直すことができるんじゃないかな、と思います。
ちなみに 今年の9月に開催された ふりかえりの手法を学ぼう というイベントでは鬼のような量の手法が紹介されていたみたいです (参考 : 「ふりかえりの手法をたくさん学ぼう」で紹介された手法まとめ)。
なんならもうルーレットで選んだやつ試してみるぐらい遊び感覚で気軽にふりかえりをやってみるのも楽しそう。