はじめに
EMの加川(@shinpr_p)です。
ここ数週間で、DROBEの開発チーム体制に変化がありました。今回は体制変更の背景や考慮した事、どのようにチーム体制を考えたかを記事にしてみました。
チームを取り巻く状況によって選択肢は異なりますが、1つの事例としてチーム体制の参考となれば嬉しいです。
※ 余談ですが、この文章は社内向けに体制変更を説明した際に書いたものとある程度同じ内容になっています。
体制変更の背景
現在のDROBE開発チームは、組織観点においてふたつの課題を抱えています。
ひとつは、開発チームメンバーの多さです。
全員が集まるMTGとなると参加者が10名を超えてきます。10名を超えるとコミュニケーションパスが複雑になり過ぎ、性質に依らず話しづらさを感じたり話さなくなったりする人が出てきます。この状態はスクラムの三本柱である「検査」「適応」「透明性」が損なわれることを意味し、課題発見の遅延によってアジリティが失われてしまいます。
参考: ミラーの法則
もうひとつは、開発チームが関心を持つ責務領域です。
注力するビジネスミッションが複数ありそれぞれに担当PdMが存在するが、開発チームはひとつである。プロダクトは事業全体に関係するが、ビジネスミッションの集合では事業全体をカバーできない(取捨選択の観点で意図的にそうしている)。結果として、ビジネスミッションにも優先順位をつけることになり、重要なはずなのに開発着手されない状態が続くことがありました。一方で、開発チームが取り組むビジネスミッションが切り替わるタイミングでは、チームは連続性を失い、価値を積み上げている実感が薄くなってしまうという課題もありました。
また、プロダクトとしては稼働しており利用者もいるがビジネスミッションからは外れる領域に対して、関心を向けることが許容されにくい状態になっていたことも課題です。限られた開発リソースを取捨選択することは重要ですが、関心ごとの境界としてはハードであり優先順位をつける俎上に載せることすらできないという認識を持つ人が多くなってしまっていました。
これらの課題を解決するため、開発体制の変更を行うことにしました。
体制変更の詳細
今回の体制変更では、チームの分割を行います。チーム分割によってふたつの課題に対処していこうと考えています。
チーム体制は以下のようにしました。
この体制に至った経緯
以下、どのような思考プロセスを経てこの体制にしたのかを説明していきます。
1. バリューストリームによるPdMの責務領域の整理
体制を考えるにあたり、DROBEにおけるバリューストリームを可視化する活動が行われました。より正確に表現すると、チーム分割をしたいと考えていた中でPdMの責務領域を整理するタイミングがあり、バリューストリームに沿って責務領域(以下、ビジネスドメイン)を提案しました。
このプロセスによって可視化されたバリューストリームマップは以下の通りです。 本項周辺についてはPO長井による別記事が近日公開予定です。詳細はそちらを参照 & お楽しみに...
参考：バリューストリーム / バリューストリームマッピングとは
2. Team Topologiesによる将来のチーム体制の明示
可視化されたバリューストリームと担当PdMの情報をもとに、Team Topologiesの考え方でチームの構造を定義しました。
参考：チームトポロジーとは
点線で表現された箱は現時点でまだ実態として存在していない概念です。
- xOpsはエンジニア採用が進捗し開発キャパシティが増加したタイミングでビジネスオペレーションのプラットフォームとして、中長期的なミッションを持ったチームの組成を検討したいと考えています
- ミッションは「一連のビジネスオペレーションを包括した、全社のスループット向上」です
- 倉庫の領域は現時点で両チームに関係していますが専門チームを作るほどの開発キャパシティはないため、当面は両チームで分担して開発・運用を行っていきます
- MLについては、プラットフォームチーム化した上でプラットフォーム ＋ イネーブリングという振る舞いに変えていこうと考えています
今回の「チーム体制の変更」で対象となるのは以下の2つです。これらは、チームとして自律的に活動できるようになった時点で、2つのストリームアラインドチーム(以下、SAチーム)として独立させることも選択肢として考えています。
- 商品供給チーム
- DROBE事業の商品調達から商品価値向上に伴う販売の促進を主務として担うチーム
- 顧客体験チーム
- DROBE事業のマーケットからの顧客獲得および購入体験向上伴う販売の促進を主務として担うチーム
3. スクラムの運用を考える
2の後半で示した通りチームとして自律的に活動できるようになった時点で物理的なチーム分割を検討します。スクラム的に言うとふたつのスクラムチームになります。裏を返すと現時点ですぐにふたつのスクラムチームにすることはできないということです。そのため、冒頭で示したLarge Scale Scrum(以下、LeSS)でのチーム分割手法を採用しました。
再掲: チーム体制
参考: Large Scale Scrumとは www.atlassian.com
DROBE開発チームでは2週間スプリントでスクラムを運用しています。LeSSにすることで、イベントの流れが以下のようになります。
以下が、我々のチーム固有の状況に合わせたカスタマイズになります。
- 各ビジネスドメインの担当PdMのことを、「代表者」と定義しています。スクラムにはPdMという役割が存在しないため、代表者にマッピングをしました。SAチームとして独立する際には、代表者ではなくPOとなり、スクラムチームから生み出される価値を最大化することに説明責任を持つようになる想定です。
- チームは担当ビジネスドメインの専門家になることが期待されています。一方で、今回はハードなチーム分割をしない選択肢を取っているため、プロダクト全体を薄く把握した上で担当ビジネスドメインを習熟していくことを期待しています。Sprint Goalによっては他チームのヘルプに行くこともありますし、全体把握を目的に相手チームが担当するビジネスドメインのタスクを受け持つこともあります。
- Sprint Goalは、事前にPOが素案を提出することで方向性を示します。Backlog Refinement、Sprint Planning1を経て今スプリントで取り組むPBIが明確になるため、Sprint Planning2にてそれらを持ち寄り、各チームがSprint Goalを決定します。Planning2にて方向性を見直したいとなった場合は、POとすり合わせを行いフィックスさせます。
- 「トラベラー」は、各チームには所属せず各チームでその専門性が必要とされた時に支援に入ります
- デザイナーは1名しかおらず両チームに所属できないため、デザインの観点でイベントやMTGに参加してほしい時に声をかける運用となります
- xOps担当PdMはOpsのIssueを都度Planning1に持ち込み、優先順位をつけスプリントに組み込んでいく活動をします。また、必要に応じて各チームに所属しxOps関連タスクのデリバリーを支援します。
体制変更後の状態
最後に、体制変更から1スプリントが経過した現在(2023/08/29)の所感を書いて、本記事を締めたいと思います。 現時点でいくつかポジティブな変化が見えています。
- チーム内の発言量が増しました
- 意識するビジネスドメインが狭まったことで、コンテキストが揃っている前提で会話ができるようになりました
- デプロイ頻度と変更のリードタイムが改善しています
- ここは他の要因があるかもしれないのですが、タイミング的には一致しているので経過を見守っていきたいと考えています
デプロイ頻度と変更のリードタイム
- ここは他の要因があるかもしれないのですが、タイミング的には一致しているので経過を見守っていきたいと考えています
一方で、改善したいこともいくつか見えてきています。
- 1つのゴールに向き合う開発者が減った中で、これまでの進め方だと結果非効率になるケースが散見されています
- リソース効率で動いていることがあり、フロー効率で見ると改善の余地があります
- チームの境界が曖昧になっている時が稀にあり、チームのゴール達成やチームを成長させるために頭を使う(新しい価値を作る)ことをもっとやれるはず
- チームが別れリモートワークも相まって別チームのメンバーとのコミュニケーションが減ってしまった
- 開発の観点ではポジティブかつ想定される効果ですが、分断はさせたくないためバランスを取る必要があります
- 夕方に任意で雑談を行う「Coffee Time」を設けてみましたが、効果のほどはまだ不明です
- 新しい概念をそれなりに取り入れているため、まだ理解が浸透していない(それはそう)
- ここはSM(含む自分)ががんばっていきます
どんなフレームワークも運用がキモなので、これから数ヶ月よりよい状態に持っていけるように取り組んでいきます！！
