スタートアップの専門家が語る、スケールしないことをする意義
- Aisha Washington
- 1 日前
- 読了時間: 11分
初期段階の創業者は、最初からスケールについて考えるよう、しばしば促される。システムをどのようにして数百万人のユーザーに対応させるのか、顧客獲得をどう再現可能なものにするのか、コストを同じ割合で増やさずにオペレーションをどう拡大するのか、と問われる。いずれも正当な問いではある。しかし、このY Combinatorの対談に登場する専門家たちは、それらがあまりに早く問われがちだと主張する。
登壇者たちは、ポール・グレアムの影響力あるエッセイ「Do Things That Don’t Scale（スケールしないことをしよう）」を振り返り、そのメッセージがゼロから会社を築くうえで今なお中心的である理由を説明する。Airbnb、Fleek、Stripe、Algolia、Instacart、DoorDashなどの事例を通じて、手作業は単に一時的に許容される妥協策ではないと論じる。意図的に用いれば、需要を検証し、顧客を理解し、事業のどの部分に本当にスケールさせる価値があるかを見極める強力な手段になる。
スタートアップの世界に異なるプレイブックが必要だった理由
登壇者によれば、シリコンバレーがスケーラブルなシステムに熱狂するようになった背景には、極めて成功したインターネット企業の存在がある。Googleは、ソフトウェアとオンライン流通によって、追加の労力を比較的少なく抑えながら巨大なオーディエンスに到達できることを示した。創業者や投資家が、同じように再現可能な成長モデルを探し始めたのは自然な流れだった。
その志向は次第に制約となった。起業家たちは、誰かがそれを必要としていると証明する前に、スケーラブルな解決策を提示しなければならないという圧力を感じるようになった。実在する顧客との距離を保ったまま、仮想的な需要のための自動化システムを何か月もかけて設計してしまうこともあり得る。
ポール・グレアムのエッセイは、こうした順序に異議を唱えた。パネリストたちが説明するように、ほとんどの若いスタートアップを脅かしているのは、過剰な需要やインフラの崩壊ではない。目先のリスクはもっと単純だ。十分なユーザーを獲得できないか、人々が価値を感じないものを作ってしまうかもしれない。
したがって実務上の優先事項は、最初の方法が労働集約的であっても、問題を直接解決することだ。スケーラビリティはいずれ重要になるが、それは会社がスケールさせる価値のあるものを見つけた後である。
まずはゼロから一へ進む
この対談では、スタートアップの前進を、目の前にある制約の連続として捉えている。最初の課題は、100万人目の顧客に効率よく対応することではない。最初の顧客を獲得し、最初の成功体験を届け、その人がなぜその製品を選んだのかを学ぶことだ。
これは、創業者が初期の仕事をどう評価すべきかを変える。成熟した企業では非効率に見える作業でも、重大な問いに素早く答えられるなら、完全に合理的であり得る。顧客を自らオンボーディングする、サービスを手作業で組み立てる、社内ワークフローを即興で作るといった行為は、孤立した状態でインフラを何週間も構築するより多くを明らかにする場合がある。
登壇者たちは、Airbnbを代表的な事例として取り上げる。創業者たちは掲載情報を改善する必要があったため、ホストがより高品質な写真を用意できるよう支援した。物件を訪れ、一件ずつ掲載情報を改善する方法が恒久的な運営モデルになり得なかったことは明らかだ。それでも、それは同社の切迫した問題、すなわちマーケットプレイスをより魅力的にし、成長が始まるのに十分な活動を生み出すという課題に対処していた。
教訓は、すべての創業者がAirbnbの戦術を再現すべきだということではない。目の前にある障害を直接見極め、洗練されたシステムを待たずに解決する意欲を持つべきだということだ。
Fleekは構築する前にマーケットプレイスを学んだ
Fleekは、手作業のオペレーションを通じて学ぶことを、とりわけ鮮やかに示している。同社は、完成したウェブサイトも、衣類の在庫も、高度なマーケットプレイス基盤もない状態で始まった。代わりに創業者たちはロンドンの卸売業者を訪れ、関係を築き、供給と店舗を直接つないだ。
パネルでは、チームが卸売業者と小売業者の間で衣類を運ぶことさえあったと説明される。一般的な効率性の観点から見れば、創業者自身が商品を運ぶのはプロセスの失敗に見える。しかし学習という観点では、それによって彼らは取引の内側に身を置くことができた。
作業に参加することで、Fleekは小売業者が何を求めているか、卸売業者がどう行動するか、どの価格が機能するか、需要が変化にどう反応するかを観察できた。これは抽象的なアンケート回答ではない。実際の買い手と売り手が実際の購入を完了するのを支援するなかで得られた洞察だった。
約4か月にわたって手作業で運営した後、創業者たちは活動をオンラインに移すのに十分な知識を得た。そのマーケットプレイスは、市場がどう機能すべきかという仮定ではなく、チームがすでに目にしていた行動に基づいていた。
実践的なオンボーディングがより良い製品を生む
登壇者たちは、製品開発と顧客の現実との隔たりを創業者自身が埋めた例として、StripeとAlgoliaを挙げる。Stripeの創業者たちは、単にドキュメントを送って待つのではなく、初期ユーザーのために決済ソフトウェアの導入を支援した。Algoliaも同様に、Product Huntの検索実装を支援した。
直接実装することで得られるのは、新しいアカウントを有効化することだけではない。分かりにくいセットアップ手順、隠れた技術的依存関係、そして顧客が必要だと言うことと、実際に苦労することの違いが明らかになる。
また、それは関係性を変えることもある。創業者と一緒に作業した顧客は、見知らぬ会社にサポートチケットを送る人よりも、率直なフィードバックを共有しやすい。その信頼によって、スタートアップはより鋭い製品インサイトにアクセスできる。
パネリストたちは、この個人的な配慮、すなわち創業者による「FaceTime」を、既存企業がしばしば真似できない強みとして説明する。大きな競合企業はより多くのリソースを持っているかもしれないが、通常、創業者が一人ひとりの小規模な顧客の成功に直接コミットすることはできない。製品が未完成で信頼性も限られるスタートアップにとって、目に見える配慮は価値提案の一部になり得る。
初期の仕事は学習のために最適化する
この対談の中心的な主張は、創業者は初期段階をオペレーションの洗練さではなく、学習のために最適化すべきだというものだ。手作業での提供は、チームがそのプロセスをソフトウェアに組み込む前に、約束した結果が本当に価値あるものかを確かめる助けになる。
この原則は、次のようなシンプルな順序に置き換えられる。
事業における最も重要な不確実性を特定する。
実際の顧客でそれを検証する、最も速く信頼できる方法を設計する。
自動化によって答えが遅れるなら、手作業で実行する。
何が繰り返し価値を生み、何が摩擦を生むのかを記録する。
パターンが明確になってからシステムを構築する。
これは、即興で作ったすべてのプロセスを、実行可能な事業の証拠として扱うという意味ではない。手作業が有用なのは、証拠を生み出すときだ。創業者は依然として、需要が繰り返されるか、顧客が支払うか、基盤となるサービスが最終的に魅力的なビジネスモデルを支えられるかを見極めなければならない。
避けるべきなのは、技術的な完成度と検証を混同することだ。美しく設計されたプラットフォームでも、望まれていない製品を補うことはできない。
InstacartとDoorDashは即席のツールで需要を検証した
Instacartの事例は、成熟した形態なら必要となるすべての提携を結ぶ前に、創業者がマーケットプレイスを検証する方法を示している。動画内で語られるように、同社は食料品店との正式な関係なしに立ち上がった。チームはTrader Joe’sで商品を購入し、写真を撮ってオンラインに掲載し、顧客が食料品の配達を注文するかどうかを確認した。
このアプローチは、長期化しかねない提携交渉のサイクルを回避した。小売業者に未検証のコンセプトを支援してもらう代わりに、創業者たちはまず消費者がそのサービスを求めているという証拠を集めた。
DoorDashも同じように実用的な道を取った。登壇者たちは、その初期プロダクトを、Google DriveやFind My Friendsを含む一般的なツールを使い、わずか1日で組み立てたものとして説明する。目標は、すぐに耐久性のある物流プラットフォームを作ることではなかった。地域の消費者がレストランの配達を注文するか、そして創業者たちがその注文を履行できるかを知ることだった。
これらの実験は、スタートアップの本物の優位性を活用していた。小さなチームは、大組織には実用的でない形で、一時的に作業を調整できる。守るべきプロセスが少なく、統合すべきインフラも少なく、結果を得るたびに方向転換する自由がより大きい。
不完全なシステムは適応を速くする
手作業で物事を行うことで、チームは製品全体を作り直すことなく体験を修正できる。顧客がある手順を好まなければ、創業者は次の注文で変更できる。仮定が誤りだと分かれば、何か月分ものエンジニアリング作業に組み込まれる前に捨てられる。
登壇者たちはまた、創業者が初期のオペレーション上のミスを過度に恐れるべきではないと主張する。需要の増加によって生じる問題は、迅速に解決策を見つける強い動機になることが多い。スタートアップがようやく、即席のプロセスでは支えられないほど多くのユーザーを得たとき、自動化の必要性は具体的で、緊急性があり、定義しやすくなる。
そのため、スタートアップが顧客を集めすぎてスケールできなかったことを理由に失敗することはめったにない。キャパシティの問題は痛みを伴うが、そこには需要の証拠がある。ユーザー不足のほうがはるかに危険だ。収益もなく、作り続けるべき明確な理由も得られないからである。
エンジニアリング上の含意は重要だ。インフラを後回しにすることは、近道が理解され、顧客に許容できないリスクをもたらさない限り、怠慢ではなくスピードの一形態になり得る。
スケールのために構築するタイミングを知る
スケールしない仕事は、発見のための手法であって、永続的な哲学ではない。スタートアップが繰り返される仕事を理解し、継続的な需要を確認し、手作業のボトルネックに直面したなら、学んだことを再現可能なシステムへ転換し始めなければならない。
パネルは、経験豊富なアドバイザーや投資家が、創業者がこの移行を認識する助けになり得ると述べる。早すぎるスケーリングは、未検証の仮定にリソースを浪費する。遅すぎるスケーリングは、サービス品質を損ない、チームを疲弊させ、会社が需要を取り込むのを妨げる可能性がある。
有用なシグナルの一つは反復性だ。創業者がほぼ同じ方法で同じ問題を解き続けているなら、ソフトウェアによってプロセスを標準化できるかもしれない。もう一つは機会費用である。手作業での提供が、より価値ある学習や成長を生む時間を消費するようになれば、自動化の魅力はますます高まる。
目的は、人間の関与をそれ自体のために排除することではない。すでに理解した部分を自動化しつつ、顧客がなお会社に重要なことを教えてくれている場所では、密接な接点を保つことだ。
コンサルティングは橋渡しになり得るが、目的地ではない
登壇者たちは、ソフトウェアスタートアップとコンサルティング会社の境界にも触れる。若い会社は、企業に実践的なサービスを提供することで収益を得られるし、最初の製品は単にそのサービスをより速く、あるいはより信頼性高くするものかもしれない。
これは生産的な出発点になり得る。コンサルティング業務は、創業者を実際の業務環境に触れさせ、顧客の問題について詳細な知識を与える。また、初期開発の資金になることもある。
しかしパネルは、サービス収益だけでは高成長のソフトウェア企業は生まれないと注意を促す。カスタマイズされた仕事は主に人員を増やすことで拡大する一方、スケーラブルな製品は人員を比例して増やさずに、はるかに多くの顧客に提供できる。野心的な成長目標は、この区別を明確にする助けになる。事業が桁違いに成長すると見込まれるなら、創業者は繰り返される専門性を、特注の労働力として無期限に販売するのではなく、最終的に製品へ転換しなければならない。
創業者の努力がもたらす持続的な優位性
動画の締めくくりのメッセージは、気まずい手作業や、一見すると些細に見える仕事を進んで行うことが、既存の競合企業に対するスタートアップの最も強い優位性の一つだということだ。このような仕事は、創業者を顧客に近づけ、実験を加速し、並外れて丁寧なサービスを提供する機会を生み出す。
より深い原則は、非効率性を称賛することではない。規律ある順序付けである。まず、人々が何を必要としているかを学ぶ。次に、その必要に基づいて行動することを証明する。責任ある方法であれば何であれ結果を届け、繰り返されるパターンを研究し、その後になって初めて再現可能にするための投資を行う。
需要がそれに値するものになったとき、スケーラビリティは価値を持つ。その時点までは、創業者にとって最も有効なシステムは、好奇心、緊急性、そして自ら仕事をする意欲そのものかもしれない。
