こんにちは。
ピクトリンク事業部開発部 開発1課 に所属しています松本です🐹
今回は、スクラムを使用したアジャイル開発におけるスプリントレトロスペクティブ*1（以下「レトロ」）についての改善活動を記事にしたいと思います！
はじめに
レトロは、チーム開発の継続的な改善に欠かせないプロセスです！
しかし実際の現場で、レトロを効果的に進めることが難しいと感じている方も多いのではないでしょうか。
かくいう私もその1人でして...。
現在のチームで半年間を過ごして、個人的に以下のような課題を感じていました。
- チームの人数が多く、その分選んだテーマについての発散が増え、次スプリントのアクションを決めるまでにまとめられない
- 「何かしらのアクションを決めること」が目的になっており、課題の解決に直結しない
→アクションを実施しても、根本的な解決につながっている実感が持てなかった
これらの課題を少しずつでも解消できないかと、レトロの進め方を見直し、テーマに対する深掘りを行う際に使用するテンプレートを作成しました。
本記事では、作成したテンプレートおよび実際に使用してみた結果などをご紹介します✍️
これまでのレトロの流れ
- ファンダンラーン（Fun-Done-Learned）*2＋「できなかったこと」をメンバーが付箋に書き出す
- 話し合いたい付箋に投票
- 投票数が最も多かったテーマを全員で話し合う
→マインドマップ*3を使用して深掘りする - 深掘りした後に、次スプリントで実施する改善のためのアクション（KPT*4を使用したことがあるメンバーが多く伝わりやすいので、「Try」と呼んでいました）を決める
マインドマップでの深掘りは、メンバーの発言ごとに分岐が増え、話題を収拾することが難しいと感じました。
そこで、「テーマの深掘りをもっとロジカルにできないか🤔」と検討し、サポートできるようなテンプレートを作成してみることに。
作ってみた！
こちらが実際に作ってみたテンプレートです🍰
目的や効果・問題点や改善策の繋がりが視覚的にわかりやすいように図にしました！
これに付箋をぺたぺたと貼っていくイメージです。
テンプレートの使い方
基本的には、♦️ダイヤ型の番号の順番に進めていきます。
違和感があれば前のステップに戻って、前後のステップとの繋がりを考えてみましょう〜🐾
- 定義・目的・効果を決める📝
3つは繋がっているので、目的を達成しても効果につながらない場合は内容が間違っています。
「定義」は、テーマが曖昧であった場合に、メンバーの認識を揃えるために使用します。 - 現状を話し合う🗣️
目的に対して、理想・現実がどうなっているのかを話し合い、ギャップを明確にします。 - なぁぜなぁぜの森🌳
2で明らかになった現状に対し、そうなっている原因はなんなのか？を深掘りします。
例えば、現状が『先月に比べてリードタイムが◯％伸びている』であった場合
なぜ？1回目→『レビューが捌けていなかった』
なぜ？2回目→『PRの粒度が大きいものが多くあった』『・・・』『・・・』
なぜ？3回目→『・・・』
のように、なぜそうなったのか？を何回か繰り返すことで本質的な問題点に近づくことが出来ます。 - 問題点を発見する💡
3で階層的に深掘った中から、本質に近く、チームとして取り組めるTryが出せそうなものを選びます。
この時、「この問題点を解決することで、目的を達成出来るか否か」を考えます。出来ない場合、問題点が間違っている可能性が高いです。 - 改善策（Try）を出す🌱
4で選んだ問題点に対するTryを考えます。
ここで考えたTryを達成することで、問題点が解決することがポイントです！
実際に使ってみて
このテンプレートを使ってみた結果を、良かった点と課題点にまとめてみます。
また、チーム外の方からも、テンプレートや実際のレトロの結果などを見てFBいただきました。
すごく良いアドバイスをいただけたので、共有したいと思います📝
✅良かった点
- 「発散しすぎて話題が収拾出来ない」が減った。
- 本質的な改善に繋がるTryを出せる回数が増えた。
- レトロのレトロが行いやすい！
（議論が上手く進まなかった場合でも、ステップを辿りながら議論を見直すことができるため、時間をかけすぎた場所や深掘りの方向がズレた箇所を発見しやすい。）
✅課題点
- 本質的な問題点を探るため、Tryが大きくなってしまうことがある。
→次の1スプリントでは消化できないためTry分割→仕掛りTryが生まれる。 - メンバーの試行時間が増え、レトロの所要時間が長くなってしまう（約90分）
✅チーム外からのFB
- 1スプリント（1週間）のレトロだと、時間的にも量的にもオーバースペック
- 出来事や状態、べき論としてのファクトが多く、感情面や考え方に関する付箋が少ない
個人的に『感情的な付箋があることに対しての利点』が思いつかなかったので質問すると、以下の回答をいただきました。
例えば『理解しないまま実装するのは危険なので、ペアプロ*5の時ソースコードを読むための時間を取るようにする』みたいなTryが出た時に、べき論やファクトを語る時って「なんでソースコードを読みたくないか」が深掘りできていない。
「時間をかけてソースコード読めばいいのはわかるけど、それで一緒に作業しているナビゲーターの人*6を待たせるのが申し訳ない」みたいな本質的な問題が見つけられない可能性があって、もったいない。
上の例みたいな感情的な話が出来るだけで、
『合言葉を決めてそこから10分間はソースコードを読むために使う。ナビゲーターはその時間近くに待機してSlackを返すなど他の業務をする。』
みたいな、お互い負担が少なくてお互いの時間を有効に活用できるTryに変わる可能性も出てくるかなと。人間の「なんとなく嫌だ」「なんとなく気を使う」「なんとなくめんどくさい」を言語化することで、本音で語り合える分本質的な議論ができる側面があって・・・
なるほど...！！
確かに現在のテンプレートは、論理的な課題整理には有効であるものの、機械的すぎるといいますか😂
レトロで使用したテンプレートを見返すと、実際の付箋も「あるべき論」や「事実ベース」のものがほとんどだったので、もう少し感情的な付箋を書き出せるような仕組みを考えたいと思いました！
テンプレートの将来はいかに
実際に使用してみた結果・アドバイスいただいた内容をもとに、より良いテンプレート・レトロの進行ができるように改善していきたいと思います。
- 感情面の可視化：お気持ち付箋を書き出せる仕組みを考える
- 付箋の色分け：ファクト・あるべき論・事実などを整理することで、議論をスムーズにしたい
- 時間最適化：60分を目指す
などなど。
さいごに
私たちのチームでは、課題を解決するためにテンプレートを導入しましたが、まだ改善の余地があります！
今後も試行錯誤を重ね、より効果的なレトロの形を模索していきたいです。
そして、進化したものをまたレポートとして共有したいと考えています💪
同じような課題を抱えているチームの方、一緒により良い方法を探していきましょう！
*1:スプリント終了時に実施する振り返りのミーティング。チームが継続的に改善していくために、良かった点や課題を話し合い、次に活かす具体的なアクションを決める。
*2:振り返りのためのフレームワークの1つ。楽しかったこと（Fun）、完了したこと（Done）、学んだこと（Learned）の3つの観点で振り返る。
*3:中心のテーマから連想される情報を放射状に広げて整理する思考法・図解法のこと。
*4:振り返りのためのフレームワークの1つ。うまくいっていて続けるべきこと(Keep)、課題や問題点(Problem)を明確にした上で、次に試す改善策(Try)を検討していく流れで振り返る。
*5:ペアプログラミングの略。2人でプログラムを行う開発手法。
*6:ペアプログラミング（ペアプロ）におけるナビゲーターとは、コードをレビューしながら問題の解決を提案する役割を担う人のこと。
