この記事はアソビュー！ Advent Calendar 2024 の15日目（裏面）です。
こんにちは、アソビュー！を開発しているマーケットプレイス開発部の山内（@mauchi0106）です！
秋もすっかり深まり冬になってきましたが、みなさまいかがお過ごしでしょうか？ 私は、先日の休みに山梨のフォレストアドベンチャー・こすげに行ってきました。 木々の中でのアスレチックをしたり、紅葉を見ながらのジップラインは爽快でとても楽しかったです！ ぜひ、みなさんも季節を感じに行って見てはいかがでしょうか。
さて、今回は私達が利用しているバックログ管理方法を紹介しようと思います。
はじめに
みなさんはどのようにバックログ管理をしていますでしょうか？ 大規模開発チームになるにつれて、バックログが巨大なものになりタスク管理がしにくくなったり、チーム編成が変更になりそのたびにバックログを整理しているということがよく発生すると思います。
アソビューでもバックログ管理に多くの課題感を持っていました。しかし、現在は、試行錯誤する中で変化するチーム編成に対応できるバックログ管理ができつつあると感じています。 本日は、私がバックログ管理の課題感に対してどのように向き合い、改善を行ってきたかを紹介します。
チーム編成の変化
アソビュー！を開発しているマーケットプレイス開発部は、webアプリとiOS、Androidのネイティブアプリを複数チームで開発しています。 チーム編成は基本的には固定であるものの、メンバーの異動や加入、プロジェクトの開始、開発ロードマップの変更等により、日々変化が起きております。
実際、マーケットプレイス開発部でも「※チャレンジ制度」を利用したメンバーの異動が発生して、チーム編成が変わったり、チーム分割などが頻繁に起こっております。
※「チャレンジ制度」とは
アソビューのプロダクト組織の中で、配置転換による個人の成長やチームの活性化を促進している制度です。
今の所属とは違う別のプロダクトチームへの配置転換や、自身の役割の変更、または別領域にチャレンジするために自ら手を上げてチャレンジすることができます。
例えば、アソビュー開発チームのメンバーが、新規事業のチームに手を上げてチャレンジしたり、SRE領域にチャレンジした例などがあります。
バックログ管理の課題感
当初は、セッション（webアプリの訪問数）とCVR（Conversion Rate: コンバージョン率）、LTV（Lifetime Value: 顧客生涯価値）という、それぞれのアウトカムを目標とする3チーム体制で開発を進めていました。
チーム名はセッションチーム、CVRチーム、LTVチームとし、バックログもセッション、CVR、LTVに関連するタスクを目的別に分類。さらに、可用性向上や細かいエンハンスを扱うエンハンスバックログを加え、合計4つのバックログで管理する形を取っていました。
当初は各チームがバックログから優先度の高いタスクを順調に消化していました。しかし、開発日数が進むにつれてチーム人数の変動や分割、タスク優先度の変更が相次ぎ、結果としてタスクの消化が思うように進まない状況が生じました。
バックログ管理で直面した3つの課題
当時のバックログ管理の課題感をまとめると以下のような状態でした。
- 柔軟性の低さ：1チーム1バックログになっており、他のバックログからタスクを移動させるなどの柔軟な調整がしにくい。
- サイロ化：チームがアウトカムごとに分かれているため、各チームがそれぞれのアウトカムに繋がるタスク中心に行うような状態。
- 優先度の見落とし：エンハンスなどのチームに紐づいていないバックログのタスクが、無意識のうちに優先度が下がってしまい、重要性を見失いやすい。
どのようなバックログ管理に変更したか
変更した具体的な手法とプロセスをステップごとに紹介いたします。
目標を共通化する
チームごとの個別目標（例: セッション、CVR、LTV）ではなく、アソビュー全体の事業目標を共通目標に設定しました。 これにより、チーム間での優先順位のすり合わせがスムーズになり、全体最適を意識した開発が可能になりました。 また、各チームがそれぞれのアウトカムに繋がるタスクを行うようなサイロ化を払拭するために、チーム名もアウトカムと紐づくものではなく、自由な命名に変更してもらいました。
バックログを目的別に分解する
従来の「1チーム1バックログ」から、「目的別にバックログを分ける」方式に変更しました。
以下は新しいバックログ構造の例です。
- セッション：ユーザー流入増加に関連するタスク
- エンハンス：小規模な改修や、不具合の修正タスク
- 可用性向上：アプリケーションの安定性やパフォーマンス向上に関するタスク
- アプリ機能開発：新しいアプリ機能に関連するタスク
- アプリグロース：アプリのABテストやグロースハックに関連するタスク
スプリントプランニングの最適化
スプリントプランニングを2段階に分け、すべてのバックログを横断的に確認できるようにしました。
- スプリントプランニング1：PdMとチームリーダーが優先度を議論し、それぞれのバックログを見ながらタスクを選定
- スプリントプランニング：選定されたタスクをスプリント内に割り振り、タスクの詳細のすり合わせとスプリントのゴールを設定
新しいバックログ管理の成果
チームに依存しないバックログ管理をするようになってから、事業計画に応じた柔軟なタスク配分ができるようになりました。 また、各チームが事業目標への意識が高まり、事業として何を優先度高く行う必要があるかの意識を持てるようになってきたと感じます。これもチームでのサイロ化を払拭し、バックログの垣根をなくし、視野が広くなったからなのではと思います。
さらに、今までは埋もれがちであった可用性向上のタスクや、エンハンスのタスクを別のバックログで管理することにより、優先度を落とさずに対応できるようになっております。
まとめ
今回は、変化するチーム編成に対応するためのアソビュー流のバックログ管理について共有させていただきました。 複数チームでの開発の場合は、バックログ自体を目的別に細分化することでバックログの整理と柔軟性を向上することができると思いますので、参考にしていただけたら幸いです。
さいごに
アソビューでは、「生きるに、遊びを。」をミッションに様々なプロダクトの開発や改善をしております。
カジュアル面談のご希望も随時お受けしておりますので、お気軽にエントリーどうぞ！一緒にお話しましょう〜！
