TONY0922のブログ

学んだことを適当に記録していくブログです。主にRuby, Java, PHPで仕事してます。更新頻度はそんなに高くないので、ご了承下さい。

チームで実践したKPTのボリュームを増やすコツ

この記事はマネーフォワードアドベントカレンダー2021🎄の5日目の記事です。

現在、ソフトウェアエンジニアとスクラムマスターを中心にお仕事させていただいている TONY です。MoneyForwardさんへは、業務委託にて、 経理財務プロダクト本部 Journalizeグループの開発チームにて生産性を上げるための取り組みを行っています。今回はその中の一環として、チームのレトロスペクティブを改善した取組みをご紹介します。

そもそもレトロスペクティブとは？

スプリント終了後に行うチームの振返り作業を指します。基本的にKPTをmiroで管理していて、スプリント内で発生した課題（Problem）、今後も維持していきたいこと（Keep)、チームで取り組むべき施策（Try）を各メンバーが日常的に作成して、これを元に振り返りをします。私の所属している開発チームは、1スプリント2週間で行っており、レトロスペクティブも2週間ごとに1時間行っています。

レトロスペクティブの流れは以下の通りです。

  1. 各メンバーのミッション状況共有（5分）
  2. 前スプリントから残っているTry状況の確認（5分）
  3. 本スプリントのKPT出し＆新規Try作成（45分）
  4. 週1勉強会のテーマ決め（5分）

当時の開発チーム内のメンバー構成は「経験5年以上のベテランエンジニア」と「経験3年未満の若手エンジニア」で約6:4くらいの割合でした。何回かレトロスペクティブを行っていると、KPTを出す人や議論中の発言がどうしてもベテランエンジニアに偏りがちで、若手エンジニアの発言や自発的な意見が出てこない問題がありました。スクラムはメンバー全員の自発性を前提にしているので、こうなるとベテランエンジニアらの一方的な意見でチーム方針が決まってしまいます。そうなると、若手エンジニアはベテランエンジニアに対する意見におんぶに抱っこ状態になり、チームとしての対話が減ってしまうことを懸念したので、僕から一度チーム全員でこのKPTの問題について、話し合いを行うようミーティングを何回か設定させていただきました。

ミーティングでは「もっとチームでKPTが出てくるようにするにはどうすればいいのか？」というテーマで話し合いました。 若手エンジニアからの意見は以下の通りです。

  • KPTを書くことが習慣化されておらず、忘れてしまう。
  • どのようなKPTを書けば良いのかわからない。

それぞれに対して原因と対策を考えます。

KPTを書くことが習慣化されておらず、忘れてしまう。

さて、皆さんは振り返りをどのタイミングで書きますか？当時の開発チームは夕方にチームのSlackチャンネルに「今日のKPTを書くことを促すbot」を流していました。
f:id:galepilot:20211203104539p:plain

しかし、上記のようなbotだけでは、KPTがあまり記載されない実態がありました。夕方は各メンバーが自身のタスク消化に集中したり、ミーティングが入っていたり、リリース作業を行ったりすることが多く、botに気づかなかったり、後回しにされると言う状態でした。また、とある人はレトロスペクティブを数日まとめて書く人もいましたが、やはり数日前のことをきちんと覚えていることは難しいのか、比較的KPTのボリュームが少ない傾向にありました。

対策: 朝会直後にKPTを追加する時間を設けた

当時の開発チームは朝10:00から30分ほど、Zoom上で朝会を設けるのですが、朝会後の10分間で前日のKPTを書けていない人向けの時間を設けて、書いた人から朝会を抜けるルールを採用してみました。前日にすでに記載している人はそのまま朝会から抜けても良いし、さらに追加しても良いです。各メンバー最低1つ以上、KPTを出すように仕組み化しました。強制的にKPTを促すルールがちょっと強権的なので、数週間試してみて、合わなそうであればやめるつもりでしたが、不満もなく今でも継続できています。もし、このルールがだんだんしんどくなってきた場合は、またチームで話し合えば良いと思っています。

どのようなKPTを書けば良いのかわからない。

振り返りを長く続けてくると、どういうことを書くべきかネタが尽きてくることがあります。 また、若手エンジニアの場合は自分のProblemがチームにとって、取るに足らないものだと感じてしまい、記載するのを躊躇すると言う意見もありました。 確かに各メンバーでどういう基準や観点でKPTを書くのか全く共有されない状態で運営していたので、これを機にチーム内で共有してみても良いと思いました。

対策: チームで振返り観点リストを作った

チームでどういう時にKPTを出すのかを言語化して、共有する取り組みを行い、以下の観点リストをチームで作成しました。

【振返り観点リスト】
- 1. 自分に関すること、他人に関すること
- 2. 仕事で失敗したこと、成功したこと
- 3. チャレンジしたこと
- 4. いつもと違うこと、発見があったこと
- 5. 疑問が浮かんだこと、不満に感じたこと
- 6. 誰かと相談して解決したこと
- 7. どうしても書きたくて仕方のない身の上話

ポイントは振り返りは自分のことだけではなく、他人のことを書いてもOKと言うことです。例えば、チームメンバーの挑戦を別の人がKeepとして書いてもいいですし、他人の行動から学んだことを共有としてKeepに書いてもOKです。また、自チーム以外のことを書いてもOKとしています。例えば、他チームに対する疑問や不満に感じることがあれば、その原因は何かをチーム内で話したり、必要に応じて、他チームを巻き込んで改善できるきっかけができるからです。

上記のリストを KPTボードから見える位置に貼り付けて、KPTを書く際の基準になるよう運営しています。

結果どうなったか？

圧倒的にKPTのボリュームが増えると同時に、若手エンジニアからのKPTもかなり増えて、KPTのボリュームが一番少なかった時期に比べて、約2−3倍に増えました。

一番ボリュームが少なかった時期のKPTボード

f:id:galepilot:20211203104542p:plain

改善後

f:id:galepilot:20211203104537p:plain

以上、参考になれば幸いです。 これからも、開発チームがより価値をユーザーに届けられるように、レトロスペクティブをよりよく運営できるように協力できればと思います。