【編集部注】本稿は米国スタートアップやテクノロジー、ビジネスに関する話題を解説するPodcast「Off Topic」が投稿したnote記事の転載だ。前回までの記事はこちらから読める。
こんにちは、宮武（@tmiyatake1）です。普段は、LAにあるスタートアップでCOOをしています。今回も引き続き、Lenny Rachitsky（@lennysan）さんから許可を頂き、翻訳した「How to Kickstart and Scale a Marketplace Business」のパート5をお送りします。
本シリーズは、大きく3つのフェーズに分けての構成になります。
1) フェーズ1：ニワトリとタマゴ問題について
・マーケットプレイスを拘束・制限すること
・サプライ側かデマンド側、どちらにまず集中するべきか？
・初期サプライの伸ばし方
・エンドユーザーの伸ばし方
2) フェーズ2：マーケットプレイスのスケールの仕方
・サプライ側とデマンド側のどちらが伸び悩んでいるかをどう判断するべき？（←今回）
・スケール時のグロース戦略
・クオリティー担保戦略
・学び・やり直すと何を変える？
3) フェーズ3：マーケットプレイスの進化させる方法
・「Managed」（管理された）マーケットプレイスへの進化する方法とは？
・新規事業の追加方法 ・新規事業の追加方法
PMFに達成後によくある問題
今回は、PMFを達成したマーケットプレイス企業（2段階目）からよく寄せられる質問に答えたいと思う。
- サプライ側とデマンド側のどちらが伸び悩んでいるかをどう判断するべき？
- グロース戦略をどうアクセルを踏んでスケールさせられるか？
- クオリティー担保をどう保つか？
- やり直せるなら何か違うことをやるべきか？
成長すると初期のグロース戦略が効率悪くなる。その際にサプライ側かデマンド側のどちらにフォーカスするかを再度検討する必要がある。2段階目の全体像の図のチートシートが以下になる。今回、は最初のステップとしてフォーカスする側を決める判断軸についての説明と事例紹介。
「スケール」のタイミングとわかるサインは以下だ。
- PMFを達成していること（初期地域・カテゴリーで高いリテンションの数字と成長率があること）
- 新しい市場もしくはカテゴリーでローンチする強い仮説を持っていること
- 強い競合が現れた時
サプライ側で拘束されることが多かったのは、スケールすると変わってくる
フェーズ1で話した初期成長では80%の会社がサプライ側にフォーカスしていたのが、スケールすると市場やカテゴリーによって大分変わる事例が出てきている。

ここで話しているサプライ側とデマンド側の「拘束」とは、そのサプライもしくはデマンドが一番の取引数へ繋がる要因のこと。
大きな割合の事例は常にサプライ側が足りてない
40%の事例は初期でサプライ側にフォーカスしていて、スケールしてもサプライ側が足りてなかった。こういう企業にとってはサプライサイド獲得に掛けたROIがデマンド側を獲得するためのROIを遥かに上回っていた。
事例1：Uber
サプライ側が常に足りてなかったため、サプライとデマンドのアンバランスについてあまり考えてなかった。この結果、需要に応じてリアルタイムで料金を変動する『サージプライシング』が生まれた。最終的に一つの市場でマックス20%〜30%以下の配車がサージされるように目標設定した。それ以上だとサプライ側が足りてないと判断して、これがベンチマークとなった。常にユーザー体験から考えていた時にはどのレベルのサージがあればユーザーがアプリを嫌ってしまう？と考えていた（Andrew Chen氏）
事例2：OpenTable
我々はサプライ側に引き続きフォーカスすることをわかっていた。市場の何店舗と何パーセントのレストランを取れたのかをグラフ化して、そのグラフの上にユーザー数と合計予約数に比べてのOpenTableで取れた予約率を記載した。どの市場も似ていたので、先ほど話したKPIの実績次第で市場への投資を判断していた。一つの市場のレストランシェアを勝ち取れると成長率は線形成長ではなく、指数関数的成長だった（Mike Xenakis氏）
事例3：DoorDash
我々のグロース要因を見ると、4つの要素があった：セレクション、デリバリー、クオリティー、安さ。全部サプライ側の要因だった。そのためいつもサプライ側が足りてなかった。デマンド側が足りてないと感じた時は数回あったが、かなりレアケースだった。一つの市場のでローンチした時は特定の地域で1日のデリバリー数の目標を設けてた。そこの地域が目標達成すると「卒業」する。目標を早く達成できない市場はすぐにDasherやレストランが離脱する傾向だった（Micah Moreau氏）
常にデマンド側が足りてない会社は3社のみ
事例1：Rover
我々の場合はデマンドが足りなかった。サプライ側で問題がはなかった。犬好きで、家で働いていて、$50稼ぎたい人たちはいっぱいいて、そうするとRoverに来てくれる。デマンド側はAirbnbと同じく、他人を信頼させるユーザー行動を変えなければいけなかった（David Rosenthal氏）
事例2：TaskRabbit
TaskRabbitは一切サプライ側の獲得で困らなかった。何千人とサービスプロバイダーがウェイトリストにいたが、デマンド側で苦労した（ Brian Rothenberg氏）
事例3：AngelList
シンジケートの方にピボットした時はLP獲得するのが大変だった（Babak Nivi氏）
サプライとデマンドのどちら側ともアンバランスを経験した会社が多数
40%の事例は地域やカテゴリー毎にアンバランスがあった。これを解決するために自社モデルやどちら側が足りてないかを見つけるツールを開発していた。
事例1：GrubHub
どの地域がサプライが足りてないかわかるために、一つの市場でレストランのカバレッジを出すモデルを作った。モデル内容とすると二つのKPIをトラッキングした。
- 市場の何%のレストランはGrubHub対応していて、何%は対応してないか
- 平均GrubHubレストランのオーダー数
1つに地域での平均GrubHubレストランのオーダー数がその地域平均よりも圧倒的に高ければその地域のサプライ獲得にフォーカスした（Casey Winters氏）
事例2：Thumbtack
どのKPIが一番ユーザー満足度（NPS）を予測できるかを探してたら、「Hire Rate（採用率）」が相関していた。大体ユーザーはProを探す時に最低3つの検索結果が出ると満足していた。サービスとして60%の検索結果が3つ以上の結果が出ていればうまくいっていると判断し、その以下はサプライ側が足りてないと判断した（Sander Daniels氏）
事例3：Airbnb
最初にサプライ側かデマンド側が足りてないのを判断するために稼働率を見た。ある%を超えていればサプライ側が足りてないと判断した。その後は稼働率と予約率を見るモデルを作ったんだ。そこで変曲点が起きた際の稼働率を見た。最近だと計量経済学モデルを使って、サプライ側かデマンド側を一つを増やすとどれだけ売上が上がるか計算するモデル（Lenny Rachitsky氏）
ちなみにAmazonがエコノミストを採用するのは、上記のような計量経済学モデルが必要になるから。テック企業のエコノミストの役割や採用の話は、ポッドキャストの第9話「スタートアップの新しい役職と職業」の回でもご紹介しました。
事例4：Zillow
ローンリクエストに対しての見積数、1ユーザーあたりのローンリクエスト数、レートの競争力、地域ごとのコンタクト率など、マーケットプレイスの状態を図るKPIを見ていた。どこかが低ければサプライを増やすかデマンドの調整をしていた（Nate Moch氏）
事例5：Instacart
ゴールはサプライとデマンドのバランスに投資すること。常にどちらにも投資してた。見ていた一つのKPIはAvailability(可用性)。高ければユーザーが即時デリバリーを頼めるので、可用性が高くしてすぐにサービスのバリューをユーザーに感じてもらうようにした（ Max Mullen
次はマーケットプレイスのスケールとアクセル方法についてご紹介します、次回も楽しみにしてください！
Written by Lenny Rachitsky (@lennysan) | Translated by Tetsuro (@tmiyatake1) | Edited by Miki (@mikirepo)
