事業フェーズ転換期の課題に、PMはどう立ち向かう？10Xが取り組んだ“ドメイン体制”への移行のウラ側

サービスの規模が大きくなると、事業フェーズの転換が求められます。事業フェーズが変わるとき、今までどおりのやり方ではうまく組織をまとめられない、開発を進められないこともあります。

増大する認知コストやカスタマイズ要求などの課題が生じたとき、どのように解決すればいいのでしょうか。

今回は小売チェーン向けECプラットフォーム「Stailer（ステイラー）」を提供している株式会社10X（テンエックス）を招いて座談会を開催。10Xで働く浦さん、太田垣さん、宮前さんの3名に「事業フェーズの転換期にPMが直面する課題」や「10Xが始めた“ドメイン体制”の開発」などの疑問に迫ります。

登壇者：株式会社10X

浦 祐介
グリー株式会社でデータアナリストに携わったのち、ランサーズ株式会社にて新規事業責任者を経験。その後、株式会社ZOZOにてPMチームのマネージャーとして、広告チームの立ち上げやPMチームの組成、AI導入の推進、大型リニューアルなどを担当。2021年5月に10Xに入社。

太田垣 慶
DeNAにてソーシャルゲーム事業の立ち上げプロジェクトリーダーなどを経験。サンフランシスコを拠点として、海外展開に従事。2社で子ども向けプロダクトづくりに取り組む。メルカリにてUS mercari、メルペイの立ち上げやグロースに携わる。Playco、frankyを経て2021年11月に10Xにジョイン。登山が好き。

宮前 宏一
2009年スマホアプリの運営会社に入社。ソーシャルゲームの企画・運営などを担当したのち、アメリカで北米向けアプリの企画開発を担当。2018年にメルカリに入社し、メルカリUSのPMとしてグロース施策の推進・CRM基盤の開発などを担当。2019年10月にメルペイに移動し、大型キャンペーンやグロース基盤などのPMを担当。2022年10月に10Xへ入社。

10Xが提供するのは“小売業のための”プラットフォーム

椿原：
―― まずは、会社やプロダクトについて教えてください。

浦：
私から、10Xが開発したプラットフォーム「Stailer（ステイラー）」についてご紹介しますね。

ステイラーは、小売業者がネットスーパーを始められるプラットフォームです。

小売業の店舗の市場規模が15兆円で、そのうちオンライン販売の市場規模はたった2％程度。そのため、「オンラインでの買い物はまだまだ便利になる」と考えて取り組んでいます。

とはいえ「ネットスーパーのプロダクト」と聞いても、いまいち想像しにくいですよね。

10Xでは、以下4つの機能を開発・運営しています。

• お客様向けアプリ（実店舗同様の購買体験をご提供）
• 店舗スタッフ向けアプリ（ピッキング・パッキング・お客様へのご連絡）
• 配達スタッフ向けアプリ（ラストマイル・配達業務）
• 小売本部向け管理画面（在庫管理・売上確定・POS連携）

たとえばスタッフ向けアプリの利用シーン。

ネットスーパーに注文が入ったら、まず店頭スタッフが商品を売り場から探します。商品があれば配達、欠品の場合はお客様に連絡するというオペレーションをアプリ上で実現できます。

ほかにも配達機能では、配達ルートを自動で計算して効率的な順序を出すなど、ドライバーさんが使える機能もあります。

つまり、Stailerはお客様の体験とオペレーションの両軸をサポートするプラットフォームです。

ドメイン体制への移行――開発チームを細分化し、5つのチームを組成

次に事業フェーズが変わっていくなかで、プロダクトや組織をどのように「ドメイン体制」に移行させたのかについてご説明します。

ここでいう「ドメイン体制への移行」とは、各開発チームが担当するドメイン（業務領域）を分けて、それぞれのドメインを担当する開発チームが決まっている状態にすることです。

10Xでは、ドメインで分けた以下5つのチームをつくっています。

• お買い物チーム
• お会計チーム
• お届けチーム
• マスターデータ入稿チーム
• 標準セットアップチーム

では、どのようにドメイン体制に移行したのか。

2021年9月の時点ではワンチームでプロダクトをつくっている状態でした。その後、2022年4月に特定の企業向けチーム・複数企業のサービスローンチを支援するローンチチーム・サービスを改善する体験改善チームの3部門に分かれます。

同年9月にはローンチ以外の運用なども担う複数社チームと、特定の企業向けのワンチームをつくり、4チーム体制になりました。

現在は開発チームがドメイン体制になったことで、エンジニアのアサインなどはお届けチーム・お買い物チームで対応し、PMはクロスでアサインする形をとっています。

10Xがドメイン体制に移行した背景

10Xがドメイン体制に移行したきっかけは、担当する業務領域が広くなりすぎたことで仕様把握の認知コストや、一時的なカスタマイズ対応が増えたなどの課題が生まれたことでした。

当初は、横向けのアサイン形態を採用していました。（画像横軸の点線部）

しかし、この体制ではA社を担当しているスタッフはお客様向け・店舗スタッフ向け・配達スタッフ向けアプリと、小売本部向け管理画面の全領域の仕様を把握しないといけません。

そのため、個別の実装をそれぞれの担当者で行なっていたのですが、いろいろと問題が出てきてしまって……。

そこで、画像の赤線のように“縦のアサイン”を始めました。（※実態としてはドメインで分類しているため、アプリや画面での分類ではなく横断するケースがあります。）

急にドメイン体制に移行してしまうと社内も混乱すると考え、複数のチームをつくって3ヶ月の検証期間を設けました。

ドメイン体制に移行するなかで行なったことは、以下のとおりです。

• コミュニケーションフローの構築や、仕組みづくり
• 担当ドメインに応じて、チームごとにミッションを策定
• 専用の会議体を設けて議論の場を構築
• 依頼事項、プロダクトの成長性などの観点からPMをアサインすべきか判断

プロダクト開発における課題解決につながった。ドメイン体制化での変化

椿原：
――ドメイン体制に移行してからは、どのような変化があったのでしょうか？

宮前：
先程も申したとおり、移行前は次の2つの課題がありました。

• 一時的なカスタマイズ対応が増えた
• 仕様把握の認知コストが増えた

これらの課題において、それぞれどのような変化があったのかをお話しします。

まず、一時的にカスタマイズ対応が増えたことに関しては、開発チームになったことによって、より適切にカスタマイズを受け入れられるようになったと思っています。

たとえば、私が担当しているお届けチームで最近「パートナーさんが見る管理画面にこういうオペレーションをしたいから、この情報を出してほしい」という要望をいただいたんです。

そのときに、そのオペレーションにニーズがあるのか、理想的なオペレーションと合っているのかの議論を挟んで、「やる・やらない」「やるならこの形がいいのでは」という提案ができるようになりました。

2つ目の仕様把握の認知コストが増えた点でも、いい傾向が見られていると感じています。

絞られた領域と深く向き合うので、自分たちがそもそも何に向き合っているのかや、プロダクトそのものについて深く理解できるようになりました。

たとえば、ドメイン体制に移行する前はパートナーに近い立場ですべてのプロダクトを担当していたため、パートナーのイシュー理解度は高かったんです。

一方で、主体的にプロダクトの課題を見つけて解決するのはあまりできていませんでした。

移行後、開発チームになってからは自分たちが担当している領域に繰り返し触れることで、1対応あたりのコストが下がりました。

ドメイン体制で生まれた3つの課題

一方で、ドメイン体制に移行したことで以下3つの課題が生まれたんです。

• 事業のイシューにどう向き合うか
• チームをまたいだロードマップづくり
• 各種プロセスのメンテナンス

今回は、「事業のイシューにどう向き合うか」と「チームをまたいだロードマップづくり」の2つの課題について説明します。

まず「事業のイシューにどう向き合うか」について。複数のチームと連携するべき課題でも1つのチームを軸に解決策を考えてしまうことがありました。

たとえば、お届けチームのPMのミッションは、ネットスーパーのキャパシティ（配送枠の総量）を大きくすることです。しかしキャパシティを上げるとなると、お買い物チームやお会計チームの領域にも解決策はあるはずです。

3チームまたいで最適な策を考えて優先度をつけていく必要があるのですが、どうしてもお届けチームを起点に考えてしまうのが現状の課題となっています。

また、チームをまたいだロードマップづくりにおいても、直近で向き合っている課題です。

ドメインチーム体制になってから、ロードマップをつくるサイクルを2回行なっています。

1回目は各社や各事業部からいただいた要求を、最初に担当チームに割り振って各チームでロードマップをつくる方法で進めていました。

ただ、各チームを横断するような要求はどうやって優先度を決めればいいのかというような、リソースを含めた適切なアロケーションができない課題が生まれたのです。

そこで2回目のロードマップづくりでは、パートナーや事業部開発チームから出た要望について、一旦チーム全体で優先度を決めるというプロセスを挟むようにしました。

これによって、チームを横断する要求の優先度が決めにくい状態を解決し、これをもとに各開発チームがロードマップを引くプロセスを試しています。

椿原：
―― 10Xさんの「ドメイン体制への移行」のお話、とても興味深かったです。ありがとうございました！

＊＊＊

サービスやプロダクトが大きくなったことで事業フェーズを転換し、ドメイン体制に移行した10X。体制を変えたことでプロダクト開発における問題の解決につながった一方で、新たな課題も生まれたといいます。

今回のお話を聞いて、新しい課題にも臨機応変に対応しながら、最適な開発組織をつくっていく必要があるとわかりました。

---

LboseのPM勉強会では、参加者からの質問への回答も行なっています。今回のイベント内でいただいた質問の一部をご紹介します。

◆チームをまたいでディスカッションするとき、どのメンバーを入れてどのくらいの規模で行なっていますか？
◆店舗の業務フローなどで、PMが現場に行なったり、実際に業務を体験したりはしていますか？
◆開発チームをアサインするときはプロダクト単位ですか？それとも、機能単位で特性を見て決めていますか？

登壇者に質問ができるのは、イベント参加者限定。オンラインイベントですので、学びを深めたい方はぜひご参加ください。

次回のイベントは、Shippioの3名をゲストに迎え、レガシー産業の顧客課題を正しく解決し続けるためのプロダクトディスカバリーについて伺います。

イベント詳細はこちらから