「Stailerの課題はなんですか？」と問われたら、最近は「スケーラビリティです」と答えています。
一つ一つが一球入魂のパートナーとの事業推進にかかる負担を軽減し、より高い成果を型として10Xがアウトプットするにはどうすれば良いか。この問いに対するストレートな答えが「プラットフォームとしての進化」にあると思っています。
前提: プラットフォームとアグリゲーター
本論の前に「noteがFacebookやTwitterにならないためには、と考えてみた** (2020)」のなかで引用されていた「The Bill Gates Line **By Ben Thompson (2018)」というエントリに非常に感銘を受けたため、これを使ってプラットフォームとは何かという概念を揃えておきたいと思います。
The Bill Gates Line** **」のエントリの始点は「GAFA等のBig Techが提供するサービスは必ずしもすべてがプラットフォームではない」というところにあります。そこでプラットフォームという概念と、対比として生まれるのがアグリゲーターという概念です。
プラットフォームとアグリゲーターという2つの概念については以下のように書かれています。
This is ultimately the most important distinction between platforms and aggregators: platforms are powerful because they facilitate a relationship between 3rd-party suppliers and end users; aggregators, on the other hand, intermediate and control it.
(対訳)プラットフォームが第三者供給元とユーザーの関係構築の便宜を図ろうとするのに対して、アグリゲーターはその間に入りコントロールしようとする。これが究極にして最大の相違点です。
Bill Gatesが「Facebookはプラットフォームではない」と否定した時には、以下のようなパンチラインを生み出しています。
“That’s a crock of shit. This isn’t a platform. A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it. Then it’s a platform.”
(対訳) ”そんなの嘘っぱちだ。これはプラットフォームではない。プラットフォームとは、それを利用するすべての人の経済的価値が、それを作った会社の価値を超えたときにできるものだ。それがプラットフォームだ。”
つまり、どういうことか
「noteがFacebookやTwitterにならないためには、と考えてみた」から拝借します。
第三者供給元に何らかのバリューを提供しているという点では、プラットフォームもアグリゲータも似ている。ただアグリゲータの場合は総じて、「需要元となる消費者を効率的に持ってこれる」というところで供給元を手懐けるので、戦略の第一手は、往々にして、消費者のニーズをこれでもかというくらい埋めるところから始まる。それはFacebookなら友達運用の効率化であり、Googleなら知的生産性の向上であり、AppleならiPhoneによる生活のオンライン化だった。
つまりユーザー体験の操縦席にだれが座るのか、という問への解として、この2つは全く別のものだと理解できます。
- アグリゲーターは、ユーザーを自身のサービスに直接粘着させ、それによってサプライに対して交渉力を強め、ユーザー体験を直接コントロールしようとする
- プラットフォームは、「ユーザーに対して3rd Partyがユーザー体験をコントロールするためのツルハシを提供」することに徹し、ユーザー体験へ間接的に関与する
Stailerはプラットフォームか否か
Stailerはプラットフォームです(と、話されています)。しかし、Stailerがなぜプラットフォームであるか、という定義は明確にされておらず曖昧です。
ここでは以下の図を用いながらGatesとThompsonに則って明確な定義づけを試みます。
Stailerはなぜプラットフォームであるか
またStailerをプラットフォームとして定義づけると、逆説的に以下のことも言えます。
- Stailerはエンドユーザー(ネットスーパーの利用者)にとってはプラットフォームではない (アプリケーションとして映る)
- Stailerはサプライヤが雇用するオペレーションスタッフや、ドライバー、本社従業員(ここの線引は若干怪しい)にとってもプラットフォームではない(アプリケーションとして映る)
- Stailerは直接的にユーザーの体験をコントロールしない。ユーザーの体験をコントロールするのはDeveloperおよび小売企業(パートナー)である。
Shopifyというプラットフォームを例にとってみてもおおよそ同じことが言えそうです。
Shopifyは自身でユーザー体験をコントロールしません。コントロールするためのアプリケーションが多数あり、このアプリケーションを提供するための土台がShopifyというプラットフォームです。アプリケーションを使ってユーザー体験をコントロールしているのはマーチャントか、マーチャントから委託されたDeveloperです。
余談: Stailerがアグリゲーターになるとしたら？
米オンライングロサリーの代表的サービスでもあるInstacartや、Amazonが日本で行っているライフ、成城石井、バローなどとの3P提携販売はまさにアグリゲーションの典型的なモデルでしょう。
「配達してほしいユーザー」「オペレーター」「出店している企業のサービス」を束ねて、トライアングルの間でのマッチングを提供します。ユーザーは「Safewayで買っている」「バローで買っている」のではなく「Instacart(のSafeway)で買っている」「Amazon(のバロー)で買っている」と話します。これはUber EartsやWoltなどで展開されるQuick Commerceにも全く同じことが言えそうです。
Stailerがアグリゲーターになるとしたら、を考えます。すべてのプラットフォーム上のパートナーサービスをアグリゲートした、Instacartのようなモデルの新規事業を実施したときには、それは明確なアグリゲーションになるでしょう。ただそのアグリゲーションは間違いなくプラットフォームのの価値を毀損するというトレードオフが発生します (Developerや小売企業は競争にさらされ、経済価値を毀損する可能性が発生します)。
このトレードオフはInstacartが発表したプラットフォームにおける懸念としても顕在化しています。Instacart上で競合と競争にさらされている多くのスーパーマーケットが、その競争の舞台役者であるInstacartに自社ECの基盤を任せるのか？という問で、疑問符がついています。
余談2: アプリケーションとプラットフォームの関係
Stailerはプラットフォームを通じて提供”できなければいけない”アプリケーションについて、かなり途上の段階にあるといえます。
「価値があるアプリケーションを容易に生み出せるようにする」がStailerプラットフォームの役割だとすると、「価値があるアプリケーションは何か」を特定し、確認することがまだまだ求められるフェーズです。
この点から、アプリケーションとプラットフォームの関係において実は親子は明確です。アプリケーションが親で、プラットフォームが子なのです。「アプリケーションの価値をスケールする」というイシューが大きくなって、初めてプラットフォームは意味をもつでしょう。難しいのはStailerは同時にこのスケール”も”重要なフェーズだということなのですが。
Stailerはプラットフォームとしてどこへ進むか
Stailerはプラットフォームとしては2つの役割に対してフォーカスする必要があります。
- 「価値があるアプリケーション」を探索し、定義すること
- 「価値があるアプリケーション」を第3者が、簡易に・安定して提供できるプラットフォームを構築すること プラットフォームの開発だけではなく、「必要なアプリケーションを探索し続ける」ことが必要になります(なぜならオンライングロサリーを成功させるための型が作りきれていないから)。
価値探索とスケール。これらを同時に内包しようとしたとき、Stailerとステークホルダーの関係は以下のようなものになるのではないでしょうか。
- 少数のパートナーに対しては、10X自身がカスタマーやスタッフの体験を直接コントロールするディベロッパーとしても振る舞い続ける。
- パートナー/カスタマーフェイシングを通じて「価値のあるアプリケーション」を探索し続ける。これらを特にTierが高いエンタープライズで行う (機会の大きさから)
- 同時に、多くのパートナー・Developerに対してStailerを開放できるようなプラットフォームを構築することで、スケーリングを図る。
今後発生するすべてのStailerの活動は、1のアプリケーション探索か、2のプラットフォーム拡張、いずれかのフォーカスにアラインしている必要があります。
Gapの認識、未来へ向けたステップ
最後に、プラットフォームとしてどうあるべきか(To Be)、と、現状のStailer(As Is)のGapをクリアにし、プラットフォームとしてのStailerの方向性に思いを馳せたいと思います。
一つわかりやすい例を挙げると、以下のようなフローをより正式なものとして取り組むイメージです。
- ステップ1. パートナー企業Aに対し、”新機能A”を提供する。結果、高い価値が確認できた。
- ステップ2. プラットフォームに上記の機能を開発し、Developerが自由にアプリケーションに機能追加可能にする
- ステップ3. パートナーBやパートナーCがこれらのセットアップをDeveloperに依頼できる
必要となるイシュー
現時点ではこういったプラットフォームを目指していく上で、アプリケーションとプラットフォームが適切に区分けされた実装や組織にはしきれていない、というのが正直なところです。
しかし、目指す姿へ向けてStailerの実装を適切に分解し、それに一致した組織を設計していく、というのが最も大きなイシューだと考えます。例えば以下のようなものです。
- プラットフォームと、それを活用して生み出されるアプリケーションについて、プログラムやデータの観点で適切に摂理面を分け、独立して扱えるアーキテクチャ
- 3rd PartyがStailerを扱う上での明確なルールがドキュメントとして公開され、適切な制約の中でアプリケーションのセットアップ・運用が可能な環境をつくる
- 3rd Partyを介したとしても、SLA/SLO/SLIに沿った信頼性やセキュリティの水準が広く担保できる状態をつくる
現時点でStailerが提供しているスタッフアプリや、在庫管理システム、お客様向けのアプリなどは利用者から高い評価を受けており、またこれらを第3者がゼロから創るには膨大なナレッジとリソースが必要になるでしょう。
Stailerがプラットフォームとして機能するということは、最終的に多くのディベロッパーを通じてStailerの価値が世の中に浸透する速度を早めることに繋がり、敷いてはOnline Penetrationというゴールへ最短で近づける手段になりうると思います。
ステップ
とはいえ、いきなりすべてを理想の状態にできるわけではなく、ステップを描いて踏む必要がありそうです。以下のようなイメージで取り組んでいきたいな、と思っています。
と、ここまでプラットフォームとしての青写真を語ってきましたが、これを実現する上で超えなくてはいけないハードルも多く、これからの10Xにとって大きなチャレンジだとも考えています。やっていきです。
また次回はStailerのプラットフォーム化についてはわかったから、結局どういう機能をのせていくべきなんじゃい、というよりユーザー体験に近いレイヤについても書こうと思います。
