Michael Seibel
私はY Combinatorでアクセラレーターの運営をサポートしているMichaelと申します。この仕事に就く前は、2007年と2012年に2度YCに入ってスタートアップをしていたことがあります。
本日は Minimum Viable Product（実用最小限の製品）、略して MVPについて話をしたいと思います。私たちは常に「業界用語は使わないように」と創業者に口うるさく言っていますが、スタートアップというのは業界用語に溢れており、MVPもその1つです。
MVP とは価値の検証を行うもの
MVPとはとてつもなくシンプルなものだと考えてください。皆さんがターゲットにしたい最も初期のユーザーに提供し、それが何らかの価値をもたらすかどうかを見極めるための最初のプロダクトです。これがMVPの本質で、いたってシンプルです。
皆さんは先週、アイデアの出し方や解決したい問題の把握について講義を受けたと思いますが、私が皆さんに言いたいのは、MVPの開発を決断する前にユーザーに話を聞くことが有益だということです。研究の類に3年費やすべきだとか、業界で10年働かなければならないということではありません。ユーザーとの会話が役に立つということです。自分自身がユーザーである時は、自社のプロダクトが役立っているかどうか自分で分かるので、もっと楽です。
最初のユーザーを見つける方法
よく「最初のユーザーをどのように見つけるか？」という奇妙な質問を受けるのですが、これには困ってしまいます。理論的に、創業者は誰かが抱えている問題を解決しようと決めているはずです。ですので、最初のユーザーを見つける方法は、その問題を抱えた人たちと話すことです。それが自分の場合はより簡単です。得体の知れないユーザーのためにプロダクトを作っているとしたら、いささか疑問です。
ローンチ前の目標
さて、ローンチ（立ち上げ）前のスタートアップの目標は極めてシンプルです。
まず1つ目のステップは、迅速なローンチです。これは設立当初からのYCの精神の1つです。10年経ってもなお優れたアドバイスであり、今後もそうあり続けるでしょう。皆さんが本日の講義から1つ学んで帰るとしたら、ローンチはとにかく迅速にということです。それだけです。実のところ、講義のその他の内容は、基本的にこの点を繰り返し要約したものです。
2つ目は、スタートアップにとって明らかに必要なことで、初期顧客の獲得です。自社のプロダクトを使ってくれる人を見つけてください。いかにして世の中の人全員に自社プロダクトを使ってもらうかというビジョンを持つ必要はありません。やり取りの中で自社プロダクトに価値を見出してくれるかどうか検証可能なユーザーが必要です。
皆さんは驚かれるかもしれませんが、自社プロダクトと接点を持ってくれるユーザーを1人も見つけられず、行き詰った創業者は大勢います。これはよくある話ですので、このステップを乗り越えることは極めて重要です。
次のステップは、そのMVPのローンチ後にユーザーの話を聞き、フィードバックを得ることです。これも非常にありがちな間違いの1つですが、ほとんどの創業者は、自分が作り出したいプロダクトのアイデアを頭に描いています。
そして、完全なプロダクトが出来上がるまでは、初期の不完全なものに対するフィードバックは意味がないというおかしな考えを持っています。「完成品ではないのだから、上手く機能しないのも当然だ。完成させるには3年、1千万ドル、そして十分な人員が必要だ。だから、中途半端なものに対するフィードバックは無意味だ」という考えです。
しかし、現実はどうでしょうか。ある意味、完成品は創業者の頭に入れておくべき非常に素晴らしいアイデアですが、柔軟であるべきです。なぜなら、自分が作り出したいと考えている完全なプロダクトは、顧客が求めているものと全く異なるかもしれないからです。
ここで皆さんに言っておきたいのは、「自分が解決しようとしている問題や顧客は確固として維持し、自分が作り出しているソリューションについては柔軟になる」ということです。重要なのは反復（イテレーション）であり、反復とピボットは区別しておきたい点です。
創業者は、何かの作り方を見つけ出すと、大抵それに心を奪われてしまいます。そして、一部のユーザーにそれが受け入れられないと、「これで他の問題を解決できないだろうか。このドライバーは何かを締めるには役立たないが、他の問題を解決できるかもしれない」と思い始めます。そして、「料理に使えるかもしれない、掃除に使えるかもしれない」と考えます。しかし「いや、問題だったのは何かをねじ止めすることだ。自社のドライバーがユーザーである機械工の問題を解決できないのなら、機械工や問題から逃れず、ねじ止めを解決する必要がある。役立たずのドライバーを改良する必要がある。不完全なのはドライバーだ」ということなのです。
問題なのは、機械工ではなく、何かをねじ止めする必要があるという事実でもありません。要は反復です。実際に問題が解決されるまで自分のソリューションを改善し続けることです。
リーンなMVPを作る
ほとんどの場合、非常にシンプルなMVP（リーンなMVP）を作るべきです。つまり、数カ月ではなく数週間で迅速に作り上げられるものです。これはソフトウェアを含むかもしれませんし、正直なところ、ランディングページとスプレッドシートだけで開始するスタートアップも存在します。大半のスタートアップはすぐにスタートすることができるはずです。
2つ目は、機能は極めて限定的なものにすることです。初期ユーザーのニーズをシンプルに凝縮する必要があります。往々にして創業者はユーザーと潜在的ユーザーが抱えるあらゆる問題を解決したがりますが、現実には少数の初期ユーザーと彼らの最上位の問題に注目し、それ以外は後々の対応として見過ごすことです。あらゆる人を念頭に置いたビジョンを持つべきですが、MVPは非常に小規模なものにとどめます。それが反復のベースとなります。これは単なる出発点であり、特別なものではありません。必要なのはとにかく始めることです。
そして、自分のMVPは非常に特別なものだと考えないでください。
例１）Airbnb
典型的な例を紹介しましょう。
これは確か2008年のAirbnb初のランディングページの1つです。Airbnbの最初のプロダクトについて皆さんが興味を覚えるかもしれない点は、支払い機能がなかったことです。当時のAirbnbで宿泊場所を見つけた時は、ホストに直接代金を支払うことになっていました。
言うまでもなくこれは大きな問題でしたが、Airbnbは支払い機能なしでスタートしました。マップビューもありませんでした。Airbnbで検索する時、その家が街のどこにあるか調べますよね？その機能がなかったわけです。また、コードを書いていた人はパートタイムでした。
最初から全てが完璧だったという魔法のような話は様々な人から聞かされますが、立ち上げ当初のAirbnbは万全ではありませんでした。
例２）Twitch
次はTwitchです。
これはスタート初日のTwitchですが、あまり馴染みがありませんね。ご存知の方も少しはいるかもしれませんが—。動画とチャットがありますが、それ以外は何もありません。Twitchはオンラインのライブ番組配信サイトJustin.tvとしてスタートしましたが、創業者であるJustinの生活を追うチャンネルが1つあるだけで、彼の生活に興味がなければこのサイトを離れる、これだけでした。動画の解像度は非常に低いものでした。
笑い話を1つ紹介しましょう。当時とある創業者から、「アパートの中をビデオで撮られているのは気味悪くないかい？秘密の書類や物を全部見られるんじゃない？」と聞かれた私は、「かろうじて顔がわかるくらいだったから、室内の書類なんて見えっこないよ」と答えていました。そして最も重要なことに、ビデオゲームがありませんでした。私たちがアパートでビデオゲームをしようと決めてようやくそれが登場しました。
つまり私が言いたいのは、迅速に始めることは可能だということです。現在のTwitchは当時よりかなり複雑になっています。
例３）Stripe
最後に紹介するのがStripeですが、昔は/dev/paymentsという名前でした。名前を変えて良かったですよね。名前はすぐに覚えてもらえるものにしましょう。これはスタート初日のStripeで、銀行取引はありませんでした。彼らがどのような支払処理をしていたかここでは詳しく説明しませんが、とてもスタートアップらしい方法でした。
機能はほとんどありませんでしたが、素晴らしかったのはStripeを使いたい時に創業者が自分のオフィスに来て実装してくれたことです。なぜなら、彼らはStripeを使ってくれる人を求めて必死になっていた、そしてユーザーがバグを見つける前に自身でバグを見つけて修正するのに都合が良かったからです。
このように、非常にシンプルかつ迅速なMVP開発の例を3つ紹介しました。この3社はどれも10億ドル企業となっていますが、創業当初は大半の人に全く馬鹿げていると言われるようなものから始まりました。
ヘビーMVPを作るべきとき
しかしごく稀に、ヘビーMVP（機能を充実させたMVP）を作るべき場合があります。
「ヘビーMVP」という言葉は2日前にこのプレゼンテーションを準備した時に私が思い付いた言葉ですが、流行るかもしれません。保険や銀行のような厳しい規制下にある業界、あとドローンもそれに含まれるかどうか判断が分かれますが、それらの業界におけるローンチは困難です。他の業界よりも困難です。
まず、多くの規制当局の認可を得る必要があります。ロケットのようなハード技術に携わっている場合、数週間でロケットを作り上げるのは無理です。バイオテクノロジー産業では、数週間で抗がん剤を発明するのは困難です。月へのロケット打ち上げは、他の全ての必要事項を満たしても、数週間で地球にトンネルを掘って車に代わる超高速車両を開発することはできません。
そうした状況下でもMVPは、自分の会社が手掛けていることを説明するシンプルなウェブサイトで始められることを覚えておいてください。誰かと話をした時、何か参照できるものがあることは有益です。簡単なウェブサイトなら数週間でなく数日で作ってスタートすることができます。何らかの変則的な方法をとれば、ヘビーMVPはリーンMVPよりも素早く完成できるかもしれません。
ローンチは特別なものではない
さて、ここでローンチについて少しお話しします。ローンチに関して誤解している創業者が多いからです。大企業が何かをローンチするのを見て、彼らはスタートアップもそのようにするものだと思い込んでいます。彼らは大企業をスタートアップと同じように考えて見ています。Facebookはもはやスタートアップではありませんが、マスコミの注目を集める、世間の話題となる等々、それを目にした創業者たちは、これぞローンチで成功を収めた会社の姿だと考えます。
では、1つ皆さんにお尋ねします。Googleがローンチした日の事を覚えている人はこの中で何人いますか？いませんよね。Facebookは？Twitterは？いませんよね。つまり、ローンチは全然特別なものではないということが分かりましたね？自分がやってみたい魔法のようなローンチという夢のようなアイデアを持っていたら、それは捨て去ってください。
ローンチは特別なものではありません。何よりも重要なのは、まず顧客を獲得することです。
すっきりさせるために、別の言葉を使いましょう。ローンチとは、顧客を獲得する時のことです。
プレスローンチは？これは実に感動的ですね。自社のプロダクトを記事にしてもらい、反響を呼び、世間の話題となる時です。プレスローンチは後回しにして、カスタマーローンチをとにかく早く行うことです。これが私たちの目標です。
まだプロダクトを手にして使っていない顧客から何かを学ぶことはとても困難です。顧客の話はいつでも聞けても、自分が作りたいものが顧客の問題を解決できるかは分かりません。顧客にプロダクトを提供すれば、それが彼らの問題を解決しない場合はすぐに分かります。調査することも良いですが、顧客に何かを提供するまではそれが役に立つかどうか全く分かりません。つまり、ピッチスライドばかりに時間を費やすより、何であれ顧客に提供できるものを作ることに時間を費やすことに価値があります。
MVP を早く作るコツ
最後に、MVPを迅速に作り出すためのコツをいくつかお伝えしましょう。
タイムボックスを作る
第一に、仕様をタイムボックス化することです。ローンチ前に作るべきことのリストを仕様としてタイムボックスにしましょう。例えば、「3週間後にローンチしたいとすればどうすればよいか？3週間で作れるだけの仕様にしよう」となります。ここで3週間のうちに完成できない機能は全て除外することができるので、皆さんの作業はかなりシンプルになります。
文書化する
第二に、仕様を文書化することです。これはとても単純なようですが、大半の人はここで失敗します。文書にしたものがなければ、自分が手掛けていることをローンチ前に変更するのは容易です。創業者が何かを始め、ユーザーの話を聞き、「これを使いたいとは思わないね」と言われます。あるいは、そんなことはないと投資家のもとへ行きますが、「これは会社としてやっていけないよ」と言われます。投資家はすべてお見通しだからです。
そこで、創業者は軌道修正を決断します。それは文書には残らないため、軌道修正をしたことすら気付きません。こうして、3週間の計画が3カ月の計画になってしまいます。仕様を文書化していれば、少なくとも仕様を常に変更していることは正直に認めざるを得ません。
仕様を削る
第三に、仕様を削ることです。約3週間の短期勝負で1週間が過ぎた頃、多くの仕様を盛り込みすぎて期限に間に合わないと気付くかもしれません。大丈夫です。明らかに重要でないものを削りましょう。重要でないものがない場合は、重要なものを削っていきましょう。
ここでの大切な目標は、世に何かを送り出すことです。それがひとたび世に出たら、継続する勢いは非常に強いものです。何も出さなければ、いとも簡単に次々と遅れが生じてしまいます。
MVPに心を奪われない
そして最後に、自分のMVPに心を奪われないでください。多くの人は頭の中に描いているビジョンにとらわれるものですが、私がここで皆さんに紹介したプロダクトはどれも当初のビジョンを貫徹したものではありません。自分のMVPに心を奪われないでください。
MVPは長い道程における最初のステップにすぎません。1年生の時に書いたレポートに心を奪われることはないでしょうし、往々にしてMVPが持っている影響力はその程度のレベルです。講義は以上になります。
Q&A
今から少し質疑応答の時間にしましょう。何か質問はありませんか？ない、いいですね。
話者2
私はユーザーとの対話を模索中なのですが、幾つかのサブタイプセグメントがあって、もちろん各々が特定のものを求めています。つまり、数が非常に少なくてばらつきがないようであれば、どうやって—。
Michael
良い質問です。つまり、ユーザーの話を聞くと、彼らがそれぞれ求めるものはあなたが作りたいと思っているものですが、それらの間に重複する部分があまりないわけですね？包括的な回答をすると、ユーザーに機能を尋ねないことです。自分たちが求めているものを教えてくれとユーザーに頼まないことです。機能を考え出すのはユーザーの仕事ではなく、皆さんの仕事です。
ユーザーの仕事は皆さんに問題を伝えることです。つまり、あなたがユーザーの話を聞いているとしたら、彼らが抱えている問題には継続性があると思われます。彼らはおそらく問題の解決法を分かっていないため、問題についての説明に多くの時間を費やすのではなく、問題を解決し得ると思われる機能の候補の長いリストをあなたに伝えているのでしょう。
「どんな頻度でその問題を経験しているのか？」、「その問題はどれくらいひどいものか？」、「その解決法に対価を払う意志があるのか？」、「同じ問題を抱えている人を知っているか？」など、これらは私たちがユーザーから聞き出したい質問です。
一方、ユーザーが「私はMicrosoft Wordが好きなのですが、あんなことやこんなことができる機能を作ってほしいと思います」などと機能という領域に入り込もうとしている場合は、「では、なぜそれを求めているのですか？どんな問題を抱えているのですか？その問題にはどれくらいの頻度で直面しているのですか？」と問題に戻ることです。これが機能の罠にはまり込むのを回避する方法です。これは非常によくある話です。いかがですか？
話者3
私は自分のMVPにこだわるか、より良いものを見つけて軌道修正するか、迷っています。MVPに着手しましたが、潜在的ユーザー全員に話を聞いて、「いやいや、これを入れさせてください、あれを入れさせてください、これを入れる必要があります」ということになっています。私はADT療法を受けて、自分が始めたことを続けるべきでしょうか？あるいは、いつ立ち止まって「これは変化の正当な理由になるか？」と自問すればよいでしょうか？
Michael
わかりました。つまり質問は、「自分はMVPを変更し続けるというサイクルにはまり込んでいて、ローンチにこぎつけていない」ということですね。こうしたサイクルにはまり込んでいる人をたくさん見ていますが、スタートアップに存在する問題に対して「今やっていることを止める」ことが回答となる場合が多いです。
まずは今やっていることを止めてみましょう。MVPを変更し続ける必要はありません。MVPを変更している理由の1つは、MVPは特別なものとあなたが考えているからです。MVPは特別なものと思わなければ、変更を加え続けることはなかったでしょう。
話者3
仰っていることが分かりません、もう1度説明していただけますか？
Michael
自分のMVPが特別だと考える人は、MVPは完璧なものでなければならないと考えます。MVPは完璧なものでなければならないと考えると、MVPと向き合うことに多くの時間を費やします。MVPは酷いものだという前提、つまり「クローゼットの中から色をつけてだめにしてもいいシャツを見つけよう」と考える人は、そのシャツの仕立てに多くの時間を費やしませんよね。つまり、自分のMVPは特別なものでないと思っている人は、無駄な修正にあまり時間をかけないものです。
話者4
MVPをローンチしてフィードバックを求めるとのことでしたが、［聞き取り不能］に尋ねるべき重要なことは何ですか？
Michael
シンプルな質問です。MVPに関するフィードバックを得たい時に最も知りたいことは、「MVPは解決してもらいたかった問題を解決しているか？」です。これに尽きます。その質問には80もの異なった回答の仕方があるかもしれませんが、自分が解決しようとしている問題を明確に理解していれば、これは実に明快です。尋ねる必要がないことも多々あります。ユーザーと対面している場合は、その相手は自分がやってほしいと思っていることをしているかどうかを見ることができます。数字から見て取れることもあります。
日常の問題があって、それをユーザーに紹介した場合、彼らは翌日戻ってきましたか？日常の問題を解決するプロダクトで、何らかの理由でユーザーが使い続けていないのに、その問題を解決しているプロダクトを見たことがありません。関連性のあるものでも微妙に違うフィードバックはたくさんあります。ユーザーは皆さんが彼らに解決してほしい問題を解決できているでしょうか？他に質問はありますか？はい、そこの後ろの方。
話者5
MVPはどれだけ続けるべきですか？つまり、成長し始めたら次のステップは？
Michael
スタートアップの醍醐味を知っていますか？私はスケジュールやロードマップについて考えるのは好きではありません。MVP開発前のステージにある人に対しては、「何かをローンチしなさい。それを見つけなさい」と言います。皆さんはスタートアップを始めると決意しました。そのスタートアップの特徴の1つは「A地点からZ地点まで行く方法は明確ではない」ということです。つまり、のめり込み過ぎて「MVP開発はステップBと理解しているが、実際はステップC、D、Eばかりを考えている」人には、「まずは目の前にある問題を解決してはいかがですか？」と助言するでしょう。
話者6
例えば、顧客の継続を増加させるためのMVPの改善、そしてユーザー登録数の拡大や問題に関するリードジェネレーションに向けた努力、この両者をどうバランスさせるのですか？
Michael
MVP開発後に取り組むべきは成長か継続か、ということですね？こういった質問は良いですね。これはとても愉快な質問です。なぜなら、私の回答は馬鹿げたほど月並みだからです。答えは「両方」です。それが現実です。
多くの創業者は自分のスタートアップは複数の変数が絡む問題だと本質的に理解しています。しかし、複数の変数が絡む問題は一筋縄ではいかないため、創業者はこれをたった一つの変数で何とかなる問題にしようと試みます。そこで彼らは、秘密のアドバイザーに「より重要なのは成長でしょうか？継続でしょうか？」と尋ねます。
より重要なのは、シャワーを浴びることでしょうか？トイレに行くことでしょうか？私が皆さんにしてほしいのは両方です。失礼しました、両方とも重要です。創業者は複数の事を上手くこなす必要があります。
話者7
分かりました。エンドユーザーと話ができなかったスタートアップについてお話をしていただけますか？そして、エンドユーザーが問題について話してくれない場合、どう対処すればいいのでしょうか？
Michael
質問の内容を明確にしましょう。ユーザーが話したくない問題を抱えている場合、どのように話を聞き出せばよいか、ということですね？その問題とは何か教えていただけますか？
話者7
2型糖尿病です。
Michael
2型糖尿病ですか。私は自信を持って言えますが、自分が患っている2型糖尿病について話したがっている人を10人は見つけられるはずです。2型糖尿病を患っていてそのことを話したがっている患者を見つけられないのに彼らを助けるためのスタートアップを始めようとしているのは、疑問があります。設定が間違っている例の1つかと思いますので、その質問の根拠は受け入れかねますね。次の質問に移りましょう。はい、どうぞ。
話者8
投資家に発表する前の段階で必要なユーザー登録数、あるいはアクティブユーザーはどれくらいでしょうか？例えば、［聞き取り不能］、市場規模などを基にした場合—。
Michael
非常に良い質問です。簡潔に言えば、投資家に話をする前にどれほど進捗しているかということですが、その答えも言わないでおきましょう。投資家と話すべき時期については別の講義が必要だと思いますので、その講義をお待ちください。講師が誰にせよ、この質問に素晴らしい回答をしてくれるでしょう。
話者8
分かりました、ありがとうございました。
話者9
—の前にどんな種類の数字や魅力を求めるべきでしょうか？
Michael
その質問を言い換えると、Product/Market Fitに到達した時期をどう見極めるかですね。分かりました。正解でありながら創業者が嫌う典型的な回答をしますと、「それを尋ねているうちはProduct/Market Fitには到達できていない」となります。
Product/Market Fitに到達した時に起こる傾向として、ユーザーが自社のプロダクトを熱心に使い始め、創業者はオンライン上でそれを継続する以外に、何かの行動から次の段階へと移行します。これがほとんどの場合のProduct/Market Fitの状態です。創業者は新機能について考えることを止め、ファネルを通じたコンバージョンの改善について考えることを止め、より良い流通方法について考えることを止め、「自社のプロダクトを使うために明日訪問してくる人をどう満足させればいいか分からない。どうしよう。翌週も同じだ。このままでは駄目になるのは間違いない。ユーザーが多すぎる」という状況です。
面白いのは、私がそのように表現する時、皆さんがそこにいるかどうかを知るのは難しくありません。恐るべき現実は、Product/Market Fitに到達している人はほとんどいないということです。ほとんどゼロです。
人はこの言葉を軽々しく使い、「誰かが自社のプロダクトを使っている」ことだと定義したがります。誰かが自社のプロダクトを使っていることはProduct/Market Fitではなく、ユーザーがいるということです。それは素晴らしいことですが、Product/Market Fitではありません。後ろの方、どうぞ。
話者10
ユーザーに話を聞けば聞くほど、問題の定義はどんどん広がっていきます。つまり、MVPについて考える時、どこに［聞き取り不能］？私たちはたった1人のユーザーからスタートし、小さな実験を試みましたが、その最中に問題自体にさらに多くの特質があることが判明しました。
Michael
ユーザーとのやり取りが始まって問題についてより深く理解すると、その問題が拡大していく場合はどうなるかということですね？それは全く問題ないですし、実際に予想されることです。しかし、ここで私が言っておきたいのは、創業者がよく間違うことですが、全てのユーザーの問題を解決する必要があると考えてしまうことです。
ここで重要なのは、一連の問題を抱えるユーザーが1人いた場合、そのユーザーと同じような人が他にいるかどうかを把握することです。皆さんにできることは、「あなたと全く同じ問題を抱えている他の人を知っていますか？」と聞くことです。どんな問題でも、少し戻って創業者のビジョンについて考えると、問題のサブセット全体を包含しています。
私が思うに、創業者がMVPで失敗してしまうのは、彼らが大きなビジョンを持ち、シンプルなMVPを開発しようとしないからです。彼らはまるで、潜在的ユーザー全員にあらかじめ対処しなければ失敗に終わってしまうかのように考えています。
スタートアップや創業者がしなければならないことはたくさんありますが、ここでは2つのことを心に留めておかねばなりません。それは、「ビジョンは大きく、MVPは小さく」です。成長と継続です。
私たちがYCで口を酸っぱくして言っていることは、投資家向けのピッチと顧客向けのピッチは全く異なるということです。創業者はいつもこれらをひとくくりにしようとするか、どちらかを犠牲にしようとします。
1つの問題として考えるほうがはるかに簡単だからです。1つのことを考えるか、相反する2つのことを考えるか。全ての人に支払いをするつもりだが、ユーザーのためにインストールするのは使いにくい小さなAPIである。こんなことがあり得るのでしょうか？これは両方ともいわば真実であり、創業者はそれに慣れる必要があります。次を最後の質問にしましょう。どうぞ。
話者11
製薬業界における自社ユーザーは科学者でしょうか？患者でしょうか？
Michael
製薬業界における自社ユーザーですか？これはあなたに対する質問だと思います。会社を立ち上げたあなたは、自分が作っているもの、解決しようとしている問題、その問題を抱えている人を理解しているはずです。それらは私には分かりかねることです。ここまでにしましょう。今日は皆さんとお話ができてよかったです。どうもありがとうございました。
記事情報
この記事は原著者の許可を得て翻訳・公開するものです。
原文: How to Plan an MVP (2019)
