こんにちは、Eight事業の開発責任者の大熊です。
Eight事業では、ビジネスパーソン向けの名刺アプリ「Eight」を中心にそのプラットフォーム上でさまざまなサービスを展開しています。最近ではビジネスイベントとITを掛け合わせた新しいイベント体験を創出するという挑戦に取り組んでいます。開発組織が対峙するビジネス状況はBtoC、BtoB、あるいはモバイルアプリ、ビジネスイベントとバラエティ豊かです。
そんなEight事業ですが、事業状況に合わせてバックログへの向き合い方も都度変化してきました。この記事では、過去の取り組みを通じてうまくいったこと、いかなかったこと含めてその変遷をまとめ、今どうしているかをお伝えします。
※「バックログ」はビジネスやプロダクトで実現したいことリスト、「アイテム」は具体的な開発対象とここでは定義しています。
ビジネスごとのチームアサイン
ビジネスごとにバックログがあり、一つのチームがアサインされます。
個人向けの名刺アプリである「Eight」バックログ、中小企業向け名刺管理サービスの「Eight Team」バックログ、プロフェッショナルリクルーティングを提供する「Eight Career Design」バックログがあり、それぞれにチームがアサインされていました。
図で書くとこのような形です。
対象領域に完結して意思決定を行える、担当するチームはその領域の習熟度が高まり生産性が上がっていくことがメリットです。領域をまたがる開発では、複数のバックログに分散してアイテムを積むことになります。しかし、各バックログはそれぞれのビジネスにおける優先度でアイテムが積まれているため、既に大きな開発案件が動いていると他ビジネスからのアイテムの優先度を上げにくく、理想的なタイミングで開発着手できないこともありました。
デメリットはありつつも、基本的には独立して開発を進められるプロジェクトが多くうまく回っていました。事業状況の変化に伴い一部のバックログとチームを統合したりもしましたが、2023年5月まで採用していた形です。
今はビジネスごとではなく「Eight」として一つのバックログになっています。こちらは、この後でまた記載します。
複数ビジネスのバックログを一つのチームにアサイン
複数ビジネスのバックログが一つのチームにアサインされます。これはデメリットがメリットを上回ってしまった事例です。
Eight事業として広告ビジネスを行っていた時期に採用していました（注：広告ビジネスは2023年にクローズしています）。ビジネスの立ち上がりフェーズではイベントビジネスと広告ビジネスの両方に責任を持つ1人のプロダクトマネジャーがいて、その優先度判断のもとで一つのチームが開発を担当していました。
しかし、事業状況が変わりイベントと広告に異なるプロダクトマネジャーが立つようになりました。つまり、ビジネス的にはバックログが二つになりました。このタイミングでチームを分ける手段もありましたが、習熟度やエンジニアリソースの都合もあり従来の開発体制を維持しました。チームが二つのバックログを見るため、各ビジネスのアイテムをチームのバックログ上に並べ直すことになります。この営みを四半期、月次のタイミングで概算工数やビジネスインパクトを踏まえて実施していました。
図としてはこのような形になります。
元々担当していたチームがそのまま両ビジネスに対応するので、知識のリセットを起こさずに開発を継続できることがメリットです。また、イベントビジネスはイベント開催に向けたスケジュールに沿った開発が中心となるため、繁忙期に合わせて柔軟にリソースを当てられるメリットもありました。
しかし、対面するビジネスが二つある状況のため、優先度の調整が課題でした。イベントビジネスの開発ではイベント開催に向けたスケジュールがあり、容易にそのスケジュールを動かしにくい事情があります。また四半期や月次の計画時点での企画や見積もりはどうしても粗いものにしかできず、想定以上に工数がかかってしまうことや、作る中で改善点が明らかになり公開ギリギリで追加対応することが多々発生しました。それ自体は一定仕方ないことですが、その際に他のビジネスにも影響が出てくることが調整を複雑にしていました。
また、イベントビジネスと広告ビジネスのコンテキストスイッチの弊害が目立つようになりました。ビジネス要求の進化につれてシステム側の対応も高度になっていきます。一方で、運用やインシデント対応は仕掛かり中のアイテムがなんであれ必要に応じて対応が求められます。チームとして仕掛かり中のアイテムに集中することが難しくなり、それに起因して生産性や品質への影響が懸念される状況でした。
優先度決めの複雑さやコンテキストスイッチの弊害がリソース効率のメリットを打ち消すほどになったため、ビジネスごとにバックログを分け、それぞれにチームをアサインする体制に変更しました。各ビジネスに当てる工数の目安は決まっていたため、それに従ったアサインとしました。結果としてコンテキストスイッチがなくなり、運用やインシデント対応はあれど一つのビジネス領域の問題に集中できるようになりました。またチームが扱う領域を固定したことで、ビジネス要求が落ち着いている時はエンジニアドリブンで施策を提案する動きを生むこともできました。
一つのプロダクトに複数チームをアサイン
「Eight」プロダクト上で実現されるすべてのアイテムを一つのバックログで管理し、複数チームがアサインされます。
現在の「Eight」開発で採用している体制です。プラットフォーム上で展開されるビジネスによらず、「Eight」で実現する全てのアイテムが一つのバックログで管理されています。つまり、一つの優先度軸で判断されています。図に表すまでもないくらいシンプルです。
きっかけは事業状況の変化です。個別のビジネスごとではなく「Eight」として優先度を判断したい欲求が強くなりました。バックログが分かれていれば、バックログ単位に見れば優先度順に着手できます。しかし、プロダクト全体としてみた時の優先度と乖離してしまう懸念もあります。特に、2023年9月にリリースしたV10プロジェクトでは、ブランディングの変更も伴うためプロダクト全体に手を入れていく必要がありました。一方で、Eight TeamやEight Career Designの施策、コスト削減の施策といった要求も同時に求められていました。もはや特定のビジネスだけ見た優先度判断は成り立ちません。
そこで、各プロダクトマネジャーが担当していた領域の壁をなくし、「Eight」のビジネスオーナーの方針のもと全員で「Eight」プロダクトに向き合うことになりました。プロダクトマネジャーは課題の定義とビジネス状況に合わせた優先度を決める、開発組織はその優先度を踏まえた最適な開発計画を立てることに集中できます。開発計画を立てる中で、あるリリース対象としてどのアイテムまで完了させるか、開発効率やリスクを踏まえてどの順番で着手するかをプロダクトマネジャーも交えて議論します。もちろん複数のビジネスがある中でその優先度を決めること自体に難しさがあり、優先度順に複数チームでアイテムを完了させていくことも簡単ではありません。これ自体にいろいろなチャレンジがあり、今まさに向き合っている課題もありますが、それは3月に開催予定のEight開発プロセスの実践についてお話しするイベントに譲ります。
sansan.connpass.com
まとめ
以上がEightにおけるバックログへの向き合い方の変遷です。
ビジネスの状況変化に合わせて、その時点で最適と思われる形を選んできました。今振り返ってみると失敗と思える判断もありますし、現在進行形で選択しているプロセスも改善の余地はあります。しかし、一貫してビジネス状況に臨機応変に対応しながら最短で価値を届けることを目指してきました。
そんなEightでは、一緒に開発してくださる仲間を募集しています。
事業状況に柔軟に、そして最短でプロダクトデリバリーを実現する組織を一緒に目指しませんか？
media.sansan-engineering.com
