お久しぶりです。スクラムマスターの@sakebookです。
Switch 2が当選してなくて残念ですが、MtGのFFコラボがあるので楽しめてます。
自己管理されたスクラムチームであっても、無意識のうちに得意な人が得意なタスクを手に取り、結果として知識が偏ってしまう…。そんな経験はないでしょうか。それはチームのパフォーマンスを一時的に高めますが、同時に「〇〇さんがボトルネックになる」という将来のリスクも育てています。この『短期的なスピード』と『長期的なチーム力』のジレンマは、チームの成熟度が問われる課題です。
私達のチームでは、属人化を防ぐためにいくつかの取り組みを始めて、うまくいっています。今では大体のことが、チームの誰がやることになっても「わからない」とかはない状態になっています。
前提
私達はPO、SM、エンジニア3名の、合計5人のチームです。なので、エンジニア3人の中で属人化を防げているという話です。
メンバーの減少があって3人ですが、4-5人のときにも属人化を減らせていたと思います。
スプリントは1週間で、チームはフルリモートの環境です。
取り組み
「計画者」と「実装者」をあえて分ける
スプリントプランニングのトピック3「選択した作業をどのように成し遂げるのか？」を、私達はエンジニアで詳細見積もりという枠で行っています。
そこでは、
- スプリントに積んだプロダクトバックログアイテムに仮に個人をランダムにアサインし、どのように着手して進めるのか各自作業計画を立てる
- 作業する単位で子課題を作成する
- その後、各自作業計画を発表して、疑問点や考慮漏れなどを皆で洗い出す
- そして最後に仮のアサインを外し、スプリント中の実装担当者をアサインする
- すべてのアサインを決めることはせず、デイリースクラムで調整する
という流れで作業計画を立てています。この作業計画では、コードのこの関数を修正するという話まで行います。
この詳細見積もりを行うことで、
- 皆が着手する課題に対して同じ理解で着手できる
- 事前に問題点に気づきやすくなる
- この作業は他のリリースに影響するので別途ブランチを切ったほうがいい
- 不確実性が高いのでペアで進めたほうがいい
- 依存関係があるのでxxまでに終わってないとスプリントゴールに影響しそう
- などなど
という効果がありました。
私達のチームでは木曜をスプリント始まりにしているのですが、木曜はほぼスクラムイベントで埋まります。この詳細見積もりは2時間枠を取っています。途中休憩を挟みつつ、短く終わるときもあれば長くなるときもあります。
スプリントをまたいだタスクは別メンバーが引き継ぐ
こちらも詳細見積もりでの取り組みです。
前回のスプリントの残りがあったときには、着手していた人に作業計画を共有してもらいます。
アサインを検討するときには、着手していた人以外が行うようにしています。
これは
- 解決しなかった問題が解決する場合もあるし、複数の視点で見れる
- 一人が詰まっててスプリントをまたいでしまった可能性もあるので、それを次回にも起こらないように防ぐ
という効果があります。 残りがあったときは、スプリント中におかわりして追加したものであることが多いので、バトンタッチすることで属人化を防ぐ役割もあります。
「自分が作っていない機能」をレビューで発表する
スプリントレビューのための準備の時間をチームで確保するようになりました。スプリントレビュー準備という枠です。
そこでは、スプリントゴールと、スプリントプランニングのときに話したスプリントレビュー予定の内容を照らし合わせてどんなインクリメントを提示できるかを話します。
共有する内容の大筋と発表者を決めるのですが、その内容にあまり関わっていなかった人に発表してもらうようにしています。
こうすることで
- スプリント内で何に取り組んでいたのかの理解を底上げする
- 作ったけどなんの課題解決につながってるのかわからないというのを防ぐ
- 皆でやってる意識が持てる
- ドメイン知識も身についていく
という効果があります。
スプリントレビュー準備では、プロダクトゴールに近づくために必要なことについても考え、スプリントレビューでPOと話す内容として整理します。
AIへの指示（プロンプト）とその結果の要約を残す
JXではいくつものAI Coding AgentやAI Editorを活用していますが、その効果的な使い方は個人の経験に依存しがちです。これも一種の属人化と言えます。そこで、性能や活用具合による差を少なくし、チーム全体の生産性を底上げするためにこの取り組みを始めました。
知見共有も兼ねて、AIに指示させたものはサマリーを作成して特定のディレクトリに保存するというのを試験的に行っています。
AIが、過去の経緯などを調べるためにそのディレクトリを活用するケースもあって、指示の安定化と性能の底上げに貢献しています。
取り組みの始まり方
これらの取り組みははじめからあったわけでもなく、同時に始まったものでもありませんでした。
スプリントを繰り返し、スプリントレトロスペクティブで振り返る中で生まれました。
私達のチームでは、スプリントレトロスペクティブの手法を固定せず、複数利用しています。
手法によって話の出やすさや話の切り口は異なります。改善が滞っているチームではいつもと異なる手法を採用してみるというのは効果的かもしれません。
今回紹介した取り組みも、自分たちにも合いそうなものがあったなら改善の一つとしてTRYしてみてください。
