はじめに
こちらは バイセルテクノロジーズ Advent Calendar 2022 の3日目の記事です。前日の記事は藤澤さんの生産性指標を可視化してチームのワークフローを改善したら生産性が爆上がりした話でした。
こんにちは。テクノロジー戦略本部の尾沼です。
私の所属するプロジェクトでは数ヶ月前まで、メンバー間での知識量や技術力のばらつきに起因した属人化が進んでいました。
しかし最近、スクラム開発においてプロダクトバックログリファイメント（以下リファインメント）やスプリントプランニング（以下プランニング）に注力することでそれらが解消されてきているので、今回はその取り組みについて紹介したいと思います。
背景
私が所属しているプロジェクトでは、5-10人規模でスクラム開発を行っています。そして、日々開発を進める中で2つ問題がありました。
フロントエンド知識量の属人化
私のプロジェクトでは、フロントエンド開発は1名のフルスタックエンジニアによって進められていました。フロントエンド業務委託メンバーの管理も含め、もし彼が稼働できない場合、完全にフロントエンド開発が止まってしまう状態でした。
また、フロントエンドとバックエンド双方の事情を鑑みた上で実装方針を決める必要がある際、彼がいないと方針が固まらないという状態でした。
ドメイン知識量の属人化
ドメイン知識量もメンバーによってバラバラでした。役割やプロジェクト歴によって差が顕著で、コミュニケーションにおける認識の齟齬や作業の手戻りが頻繁に発生し、チームとしての生産性低下につながっていました。
こうした差が生まれてしまう原因はいくつか考えられましたが、そのうちの1つは、チームとしてのタスクの進め方にあると考えられました。開発者がアサインされたタスクの要件定義をよしなに行い進めていくことが多かったので、自分が担当していない部分の知識量は各々の努力に強く依存していました。 また、要件の理解が浅いメンバーは考案する実装方針が目先の対応になってしまいがちなこともありました。
対策
こうした状況を変えるために、ドメイン知識量や技術レベルの平準化に取り組みました。
この試みに期待していたことは以下です。
全員がフロントエンド、バックエンドのタスクに着手できる状態になり、それぞれのタスクが属人的ではなくなる
負担が寄っていたメンバーの負担緩和
今回はその取り組みの中でも効果の大きかった、リファインメントやプランニングについて紹介します。
リファイメント
元より、実装方針の策定や仕様に関してのディスカッションはチームでミーティングを行ってはいたのですが、歴が浅いメンバーは知識量の不足で議論に参加できていないことがよくありました。
そこで、リファイメントのやり方を整備して開発者全員の意見を拾えるようにしました。
リファイメントを行う上で、特に意識したことは次の3点です。
- 社員、業務委託関係なく参加できる方は全員参加すること
- 全員がストーリーの実装イメージをはっきり持てるまで議論して詳細化すること
- ストーリーポイント（以下ポイント）付けの根拠を開発者が全員発表することで、認識のズレを矯正すること
まず、リファイメントミーティングの前にプロダクトオーナーがストーリーチケットの大まかな内容を事前に記入しておきます。記入事項は以下です。
- ペルソナ
- できるようになること
- なぜやるか
※ 以下、プロジェクトでタスク管理に利用しているJIRAの画面イメージのキャプチャとなります。
リファイメント対象のチケットがある場合、1回あたり1時間の枠でリファイメントミーティングを実施します。全ての対象チケットがリファイメント完了となるまでは毎日実施します。実際のリファイメントのミーティングには、社員・業務委託関係なく参加できる方は全員参加し、プロダクトオーナーに対して仕様に関する質疑応答を実施します。また、質疑応答と並行してそのストーリーでの残タスクや行わないことを具体的にします。ディスカッションはその場にいる全員が実装イメージをはっきり持てるまで念入りに行います。もし技術的に専門外のため実装イメージが湧きにくい場合は、イメージが湧くように他メンバーが追加の解説を行うようにしています。
そして、開発者全員でPlapoというプランニングポーカーツールを用いてポイント付けを行います。私たちのチームでは、ストーリーのゴールを実現するために必要なタスクの作業量をポイントとして見積もっています。ポイント付けは各々の得意な技術領域に関わらず、全員がフロントエンドもバックエンドもインフラも考慮して行います。
そしてこの時、どうしてそのポイントをつけたのかを根拠立てて1人ずつ発表するようにしました。このようにすることで認識のズレを矯正し、全員がストーリーのゴールと大まかな作業内容への共通認識を持つことができるようになりました。
プランニング
ストーリーの大まかな内容やゴールはリファイメントでしっかり決まっていても、具体的にどう実装するのかの部分で認識がずれていて手戻りが度々発生していました。
そこで、スプリントプランニングのやり方を整備しました。
特に意識した点は、チームメンバーの誰もが作業内容の共通イメージと、どうしてその作業を行うのかの共通認識をチケット見るだけで得られるようにすることです。
進め方は以下の通り、一般的なスプリントプランニングのフローに沿っています。スプリント内のタスクの進捗を円滑にするために重要なので、〜2.5時間ほどの枠を確保して実施します。
- プロダクトバックログを上から確認する
- それまでのベロシティや次スプリントのメンバーの稼働予定を考慮して、確実に終わらせられるポイント数分ストーリーチケットをスプリントバックログに積む
- プロダクトオーナーが積んだストーリーチケットのゴールと、どうして着手するのかを説明する
- ストーリーチケットを細かいサブチケットに分解する
リファイメントの時点で大まかに書いてあるストーリーチケットの作業内容を深掘って、具体的な作業内容を細かく書きます。ここでの細かさの目安は、プランニングに参加していないチームメンバーでも参加者と同等の認識になる程度です。
そして、細かく書いた内容をもとにサブチケットを切るようにしました。サブチケットにもチケットのゴールを明確に書きます。そして、サブチケットの分解は基本的にプランニング時に全員の合意の下で行うことで、1つ1つのサブチケットで何をすればいいのか全員がわかっている状態を維持できるようにしました。
その結果、手空いたメンバーはどのサブチケットも引き受けられるようになりました。スプリント期間中は、手が空いたメンバーが優先度の高いサブチケットから順番に引き受けていく形式でスプリントバックログを消化しています。
結果
タスクを個人に割り振らず、チームで取りかかるということを実現・運用するために取り組みを続けた結果、フロントエンド開発、バックエンド開発、要件調整や実装方針決めをメンバー全員が担えうるクロスファンクショナルなチームになりました。
現在では以下のようなメリットを享受することができています。
コミュニケーションコストが減りました。特に、少人数でスクラムをやるにあたって、各メンバーが領域問わず仕事をできることはプランニングの時に気にすることが減って良いなと思っています。
フロントエンド開発のサポートもバックエンド開発のサポートも各メンバーができるので、チームとしてタスクを終わらせるために相互にフォローしあおうという雰囲気になりました。
全メンバーのドメイン知識〜具体的な実装方法まで一貫して解像度が増しました。
ベロシティの安定という結果にもつながり、さらに生産性向上の取り組みに着手する余裕も生まれました。
生産性向上の取り組みについて、詳しくは以下記事をご覧ください。
生産性指標を可視化してチームのワークフローを改善したら生産性が爆上がりした話
私自身、元々自身の担当外の知識に関して不足を感じている側でした。自身の抱えているタスクを進める上で考える実装案は俯瞰的ではないものが多かったです。しかし今回の取り組みを通して解像度が増したことで、プロダクトの実装面での考慮はもちろん、プロジェクトの中期的な部分や他のチームメンバーの行動にまで意識を向けた上で、スクラムイベントへの参画や日々のタスクを行うことができるようになってきたと思っています。
おわりに
リファイメントやプランニングに注力し、チームとしてタスクに取り組む環境を整えたことで
負担が寄っていたメンバーの負担軽減
知識量や技術力の不足でスムーズにタスクが進まなかったメンバーの生産性向上
につながり、以前より盤石なチームになったと思います。
また、忙しかったメンバーや負担が寄っていたメンバーが、各々チーム外のことに時間を使えるようになった事実が私としては喜ばしいです。
もし私たちと同じようにチームの中で属人性がボトルネックになってしまい困っている際は、ぜひ参考にしてみてください。
最後に、バイセルではエンジニアを募集しています。少しでも気になった方はぜひご応募お待ちしています。
明日のバイセルテクノロジーズ Advent Calendar 2022は小松山さんの「バッチ処理を Cloud Functions ではなく Cloud Run ジョブで実装した」です、そちらもぜひ併せて読んでみてください！
