2014年10月28日
ポール・グレアムによる「スケールしないことをしよう」後編
(2014-10-08)by Paul Graham
本記事は、原著者の許諾のもとに翻訳・掲載しております。
本エントリは翻訳リクエストより投稿いただきました。
ありがとうございます!リクエストまだまだお待ちしております!
本エントリは 翻訳リクエスト より投稿いただきました。
ありがとうございます!リクエストまだまだお待ちしております!
前編は こちら です
火を燃やし続ける
時に、わざと狭い市場に焦点を合わせるのがまさにスケールしないコツなのです。丸太を加える直前に火が最高に熱くなるよう、最初は穏やかに燃やし続けるようなものです。
Facebookはこれを実行しました。Facebookは当初はハーバードの学生向けのものでした。その形態では、たった数千人の潜在市場があっただけでしたが、学生たちは、Facebookは本当にためになると感じたので、極めて大勢の学生が登録をしました。Facebookがハーバードの学生に向けたものでなくなった後も、特定の大学の学生のために長い間残っていました。私がStartup Schoolでマーク・ザッカーバーグにインタビューした際に「各学校のために履修コースの一覧表を作成するのに多くの労力を割いたが、そうすることで、学生たちはそのサイトが自分たちの家であると感じるようになった」と言っていました。
マーケットプレイスと呼ばれるようなスタートアップは、最初はたいていその市場の一部から始めなければなりませんが、このことは他の種類のスタートアップでも機能します。一部ではあるものの、その大多数をユーザーとして素早く獲得できる、そんな市場が存在するかどうかを問う価値は常にあります。 ^(1)
火を抑えたまま燃やし続ける戦略を用いるほとんどのスタートアップは、無意識にそれを行っています。自分たちや、偶然にもアーリーアダプターになる友人たちのために何かを作り、後になってさらに大きな市場に提供できるかもしれないと気付くのです。あなたが無意識にその戦略を行ったとしても、この戦略は同じように効き目があります。このパターンを意識していない場合に一番恐ろしいのは、その一部を単純に捨て去ってしまう人たちにあります。例えば、自分や友人のためのものを何も作らなければ、あるいは作るとしても、あなたが実業界出身であなたの友人がアーリーアダプターでなければ、簡単に手に入るはずの完全な初期の市場を得ることはもうないでしょう。
企業の間では、最高のアーリーアダプターはたいてい他のスタートアップです。彼らはもともと新しい物事を受け入れやすく、まだ創業したばかりなので選択肢をまだ全て決めていないのです。さらに、成功すれば急速に成長するので、あなたも一緒に成長します。B2Bスタートアップのすぐ手の届くところに、他の何百ものスタートアップからなる市場が存在することは、YCモデル(および特にYCを大きくすることについて)の予期しない多くの利点の1つだったのです。
Meraki
ハードウェアのスタートアップ ではスケールしないことを行う別の形態があり、「Merakiを行う」と呼んでいます。私たちはネットワーク機器を提供するMerakiに投資しませんでしたが、創業者はロバート・モリス大学の卒業生で、私たちは彼らの経歴を知っていました。彼らは本当にスケールしないことを行うことから始めていました。自分たち自身でルーターを組み立てたのです。
ハードウェアのスタートアップではソフトウェアのスタートアップではおこらないような障害に直面します。工場の製造工程の最低発注量は通常数十万ドルです。これはあなたを『キャッチ=22』のようなジレンマの状況に置くでしょう。製品がなくては成長を促せないし、製品を製造するためには資金を調達する必要があります。ハードウェアのスタートアップが資金の投資者に頼らなければならなかった頃は、これに打ち勝つために人をかなり納得させる必要がありました。クラウドファンディング(より正確には事前注文)の登場は大いに助けとなっています。しかしそれでも可能なら最初にMerakiを行うようスタートアップに薦めます。それを実際に行ったのがPebbleです。Pebbleは最初の数百の腕時計を彼ら自身で 組み立てました 。その段階を経ていなければ、Kickstarterを始めたとき腕時計で11億円相当を売り上げることはなかったでしょう。
初期の顧客に必要以上に注意を払うことに似て、製品を自分自身で製造することはハードウェアのスタートアップにとって価値のある結果になります。あなたが工場であれば、より早く設計を微調整できます。またそうでなければ決して知りえないことを学びます。Pebbleのエリック・ミジコフスキーは彼が学んだことの一つを「よいネジを調達することが、どんなに重要なことだったか」と述べました。意外でしょう?
コンサルタント
ときおりB2Bスタートアップの創業者に、一人のユーザーを選んで、極端なまでに従事して、そのユーザーにとっての何かを作るコンサルタントとして振る舞えと助言します。その初期のユーザーはあなたを形作るための型として役立ちます。彼らのニーズに完全に合うまで微調整し続けると、通常は他のユーザーも望む何かを作っていると分かるでしょう。たとえそこに多くのユーザーはいなかったとしても、おそらくより多くのユーザーを抱える隣接した領域があります。本当に何かを必要としている一人のユーザーを見つけ、またその要求に応えられることさえできれば、人々が望む何かを作る足掛かりを得ます。またそれはほとんどのスタートアップにとって一番最初に必要なことでもあります。 ^(2)
コンサルティングはスケールしない仕事の典型的な例です。しかし(気前よく体を許す他の方法のように)対価が支払われていない限りそれは安全です。これは企業が最後の一線を超える場面です。顧客を特別に気遣う製品の会社である限りは、たとえすべての問題を解決しなくても彼らはとても感謝します。しかし顧客がその気遣いへ明確に支払いを始めるとき、つまり時給で払い始めるとき、彼らはあなたがすべてをやってくれると期待します。
初期の熱心ではないユーザーを集めるための別のコンサルティング的手法は、彼らに代わってあなた自身でソフトウェアを使うことです。私たちはそれをViawebで行いました。販売業者にオンラインストアを作るためのソフトウェアを使いたいか尋ねながら提案したとき、いくつかは断ってきましたが、それ以外は彼らのためのソフトウェアを作るよう求めてきました。ユーザーを得るためなら何でもするつもりだったので、それを実行しました。私たちはその時点できわめて時代遅れのように感じました。大きく戦略的な電子商取引のパートナーシップを組織化する代わりに、私たちは旅行かばんやペンや男性用のシャツを売ろうとしていました。しかし今思えば行動としてまったく正しいことでした。というのも販売業者が私たちのソフトウェアを使ってどのように感じるか教えられたからです。何度かフィードバックループが即時的になりました。いくつかの販売業者のサイトを作っている途上で、私たちにない機能が必要だと分かりました。そこで数時間をその機能の実装に費やし、そしてサイト作成に戻りました。
手作業
ただ自分のソフトウェアを使うだけでなく、あなたがソフトウェアであるような、もっと極端な変わり種の方法もあります。少数のユーザーだけのときは、のちに自動化しようと計画していることを手で行ってやり過ごせる場合があります。これはより早く立ち上げさせます。最終的にあなた自身をループの外として自動化するとき、自身の経験に基づく筋肉の記憶があるので、何を作ればよいのか正確に分かるでしょう。
手作業の部分がユーザーにとってソフトウェアのように見えるとき、この手法は悪ふざけのような面を持ち始めます。たとえば、Stripeが”インスタントな”販売業者アカウントを最初のユーザーに配信する方法は、その陰で正式な販売業者アカウントを創業者が手動でサインアップする方法でした。
いくつかのスタートアップは最初にすべて手作業でできます。解決を必要とする問題を抱える誰かを見つけられたら、あなたはそれを手作業で解決して、先へ進んで、できる限りのことをして、その後徐々にボトルネックを自動化できます。まだ自動化していない方法でユーザーの問題を解決することはちょっと恐ろしい考えかもしれません。しかしまだ誰の問題も解決していない自動化の仕組みを抱えるという、はるかに多いケースに比べれば恐ろしくありません。
ビッグ
普通は機能しないある種の初期戦術についても、言及する必要があるでしょう。それは一気に立ち上げること(ビッグローンチ)です。私はときどきスタートアップが動力のある飛行機というよりも、むしろ何か弾丸のようなものと信じているように見える創業者と会います。十分な初期速度で立ち上げさえすれば、彼らは会社を大きくすると信じているようです。彼らは報道解禁時刻を設けて8つの異なる出版物で同時に立ち上げたがっています。また火曜日は、もちろん、何かを立ち上げる最適な日だと彼らはどこかで読みます。
小さな立ち上げの重要性を認識するのは簡単です。いくつかの成功したスタートアップについて考えてください。いくつの立ち上げを覚えていますか? 立ち上げで必要なのはコアとなる最初のユーザーが全てです。あなたが数か月後にどのくらいうまくやっているかは、何人のユーザーがそこにいるかより、それらのユーザーをあなたがどれくらい幸せにしたかに依存します。 ^(3)
なぜ創業者は物事を立ち上げようと考えるのでしょうか? それは自己中心主義と怠惰の組み合わせです。彼らは、自分たちが作っているものは、それを聞いた誰もがすぐにサインアップするほど素晴らしいものだと考えています。さらに一人ずつユーザーを集めるよりも、自分の存在を広めるだけでユーザーが得られれば、とても効率的だとも考えています。しかしたとえあなたが作っているものが本当に素晴らしくても、ユーザーを得ることは常に緩やかな過程となるでしょう。部分的な理由としては、素晴らしいことというのは往々にして奇抜でもあるからで、またより重要な理由はユーザーが別のことに関心を持っているからです。
パートナーシップも通常は機能しません。一般にそれらはスタートアップで機能しませんが、成長し始める方法としてはとりわけ機能しません。経験の浅い創業者によくあるミスは、大きな企業とのパートナーシップが彼らの大きなチャンスになると信じてしまうことです。6か月後に彼ら全員が同じことを言います。それは予想より大変な道だったし、結局のところ実際には何も得ることがなかった、と。 ^(4)
初期にただ何かを極端に行うだけでは十分ではありません。あなたは初めに極端な”努力”をする必要があります。ユーザーや大きなパートナーを得るという夢がつまったビッグローンチかどうかに関わらず、戦略が努力を省いてくれるのなら、事実それ自体が疑わしいです。
ベクトル
何かを始めるためにスケールしない手間のかかることを行う必要性はかなり普遍的なので、スタートアップのアイデアをスカラー量のようにを考えることをやめるのは良いことといえます。その代わりに、あなたが作ろうとしているものと、初期の会社を立ち行かせるためにあなたがするつもりのスケールしない何かとを、ペアのように我々は捉えるべきなのです。
このやり方でスタートアップアイデアを見始めると興味深いものとなるかもしれません。今や、1つ目と同じように2つ目についても想像力を膨らますことができる、そんな2つの要素があるからです。しかしほとんどの場合2つ目の要素は、ユーザーを手作業で集めて、彼らに圧倒する体験を与える、というありふれたものになるでしょう。またベクトルとしてスタートアップを扱う主な利点は、二次元で熱心に働く必要があることを創業者に思い出させる点でしょう。 ^(5)
最良の場合、ベクトルの両方の要素はあなたの会社のDNAに寄与します。何かを始めるために行わなければならないスケールしない何かは、単なる必要悪などではなく、その会社を恒久的により良くする変化になります。もし小規模なときにあなたがユーザーの獲得について積極的でなければならないなら、おそらく大きくなったときもまだ積極的でしょう。もし自身のハードウェアを製造しなければならないなら、あるいはユーザーに代わってソフトウェアを使わなければならないなら、あなたは他では学べなかったことを学ぶでしょう。そして最も重要なのは、ユーザーが少数しかいないくても、あなたはそのユーザーを喜ばせるために熱心に働こうとするのであれば、あなたは多数のユーザーを抱えたときもそうし続けるでしょう。
前編は こちら です
注
-
もし手っ取り早くサインアップしてくれる部分集合と、最も多くを支払ってくれる部分集合から選ばなければならないなら、通常は前者の選択が最良です。おそらく新しいものが好きな人々だからです。彼らはあなたの製品によりよい影響を及ぼすでしょう。またあなたに販売の労力をそれほど消費させないでしょう。またたとえ彼らが少ない額しか持っていなくても、あなたは初期に目標成長率をそれほど維持する必要はありません。 ↩
-
もちろん、一人のユーザーにとってだけ本当に有益な何かを作ることになりかねない場合を想像できます。しかしそれは経験の浅い創業者でもわかるぐらいに普通は明らかなことです。だからあなたが一人の市場のために何かを作っているか明らかでないなら、そのような危険性について心配は無用です。 ↩
-
立ち上げの大きさと成功の間には逆の相関があるかもしれません。私が覚えている顕著な立ち上げはSegwayやGoogle Waveのような有名な大失敗です。Waveは特に驚くべき例で、私は過度の立ち上げによって部分的につぶされた、実際に素晴らしいアイデアだったと考えています。 ↩
-
GoogleはYahooの背後で大きく成長しましたが、パートナーシップではありませんでした。YahooはGoogleの顧客でした。 ↩
-
これは2番めの要素が空であるようなアイデアは、少なくとも創業者自身にとってはおそらく悪い考えなのだと気づかせてくれます.それは会社を立ち行かせるためにあなたができることが存在しないようなアイデアで,その理由には例えば自力で勧誘するためにユーザーを見つける方法がないという理由があります. ↩
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 グループマネジャー 株式会社ニジボックス デベロップメント室 室長 Node.js 日本ユーザーグループ代表
- Twitter: @yosuke_furukawa
- Github: yosuke-furukawa