ドメインベースの開発体制への移行

CTOのishkawaです。

10Xの開発チームは、4月1日からドメインベースの開発体制に移行しました。

ここで言うドメインとは、注文やピックパックや配達などの業務領域を指す言葉です。ドメインベースの開発体制に移行するということは、開発チームの分割単位をドメインにして、各ドメインを担当する開発チームが決まっている状態にするということです。

組織移行の背景

これまでは、開発チームの分割単位をパートナー企業としてきました。各パートナー企業を担当する開発が決まっているため、パートナー企業の目線でプロダクトの未熟な面があっても迅速に対応できますし、それによって事業機会を掴めたケースもありました。

一方で、プロダクトを開発運用する中で以下の課題も出てきました。

  • 認知コストの増大: Stailerは多様なドメインを抱えるプロダクトなので、すべてのドメインを理解するのは至難の業です。一方で、パートナー企業のニーズはどこのドメインにも生じうるので、開発者は必要に応じてあらゆるドメインを理解する必要がありました。

  • アドホックな対応の積み重ね: 開発チームがパートナー企業に紐づくため、開発のスコープがパートナー企業のニーズを満たすところまでになりやすい状況でした。結果として、アドホックな対応が積み重なってしまっていました。

  • コードのオーナーシップの希薄化: Stailerのコードは非常に大きいですが、それぞれの箇所に対応する開発チームが存在する訳ではないため、オーナーシップが曖昧でした。それが故にコード自体に対する改善の積み重ねや、抜本的な見直しがしづらい状況でした。

これらの課題は、開発チームがアサインされる範囲と時間軸を適切ではなかったことが影響しています。この状況を変えるため、よりコントロール可能な範囲に対して長期にわたって開発チームをアサインする方針にシフトすべきと考えました。

組成した5つのチーム

以下のチームを組成します。各チームにはPM/SWE/デザイナー/QAがアサインされます。

  • お買い物チーム: お客様が買い物に使用するシステムを取り扱う(カート作成完了まで)。売場表示、カート管理、販促、コミュニケーションなど。
  • お会計チーム: お客様が作成したカートを元に注文を行うシステムを取り扱う。クレジットカード決済、ポイント利用・付与、配達先管理、注文管理など。
  • お届けチーム: お客様が作成した注文を元に、オペレーションを行うシステムを取り扱う。ピックパック、配達、WMS連携など。
  • マスターデータ入稿チーム: マスターデータを入稿するシステムを取り扱う。主に商品マスターのインポートに取り組む。
  • 標準セットアップチーム: 新規パートナーのセットアップや既存パートナーの対応を行う。他のチームに渡せるものは渡す。

各チームのドメインは粗く緩いものとなっていますが、まずはこの体制でスタートして、将来的により厳密なサブドメインを発見していく想定です。

パートナー事業部との連携方法

事業部との連携は、中長期と短期の2つで分けて考えます。

  • 中長期的: プロダクトにいつどのような変更が入るのかといった中長期的なコミュニケーションは、ロードマップを通じて行います。CEO ⇄ 各ドメインオーナー ⇄ 各パートナー事業責任者の3者は月や四半期に1度、ロードマップの状態を確認・更新します。
  • 短期的: 不具合の修正はマイナーな機能変更などの短期的なコミュニケーションは、ワークフローを通じて行います。ドメインチームは各パートナー事業部からの依頼を受け取り、バックログに乗せたり、調整を図ったりします。

いずれの場合も重要な役割を果たすのはPMです。プロダクト開発には「やるべきこと」が無限にあって、プロダクトを価値あるものにすべき、パートナー事業部のニーズに応えるべき、品質を上げるべき、運用コストは抑制すべきなど、挙げていったらキリがありません。そんな状況の中でも、PMは開発チームが何をするのか決定し、チームの内外に説明を果たさなければなりません。

この役が上手く機能して、関係者全員がAs One Teamで成果に向かえることを期待しています。

期待する変化

開発チーム目線では、組織移行によって以下のような変化が起きることを期待しています。

  • 長期目線に立ったプロダクト開発ができる。
  • チーム毎の継続的な改善サイクルが回る。
  • ドメインに立ち入った開発が加速する。

課題はまだ山積み

この組織移行には、まだまだ多くの課題が残っています。例えば、ドメインの境界を技術的にどのように実現するのか、インフラをどのように分割するのか、アラートをどのようにチームに紐づけるのか、ドメインチームの事業成果をどのように計測するか、事業部が守りたいタイムラインをいかに実現するか、といったものです。

こうした課題を認識しつつもこの意思決定に踏み切っているのは、先に挙げた課題がプラットフォームを目指す上で根本的なものだと捉えたためです。まずはこの根本的なイシューを解いて、それから山積みになっている課題を1つずつ解いていこうとしています。