![既存ツールを活用した検証フェーズごとの最適なMVPとは?|スタートアップが学ぶべきMVP開発](https://onlab.jp/wp-content/uploads/2023/10/mvp_title2.jpg)
2023年10月11日
Open Network Lab (以下「Onlab」)は、日本初のアクセラレーターで、2010年4月のスタートからこれまで数々のスタートアップをサポートしてきました。そんなOnlabからはこれまでにgiftee、POPER、FRIL、WIHLL、SmartHRといった、上場を果たした、または資金調達を経て成長し続けるスタートアップを輩出しています。今回はスタートアップがMVP開発に取り組む上での具体的な方法や使用できる既存ツールなど、その注意点やポイントについて解説します。
【 筆者プロフィール 】
Open Network Lab HOKKAIDO プログラムディレクター 小田 貴志
新卒でNHKにディレクターとして入局し、報道や自然などのドキュメンタリー制作を手掛ける。旅行業界でインバウンドビジネスディレクターを経て、エンジニアに転身。要件定義から設計、実装、デザインまで幅広い範囲に従事。その後、家庭料理シェアやフードデリバリーなどのスタートアップ立ち上げを経験し、再びエンジニアへ。2022年より「Open Network Lab HOKKAIDO」の運営に参画。得意領域はビジネスの仮説検証、プロトタイプやMVPの構築、UI/UXデザイン。
スタートアップにとってのMVP開発は、最初の顧客(ファーストカスタマー)を探すことから始まります。ファーストカスタマーの特徴として挙げられるのは、課題について猛烈に話す、お金を払う準備がある、製品へフィードバックをくれる、といったものです。
顧客・課題が見つかったら、ソリューション、プロダクト、マーケットの検証を始めていきましょう。
まずは「課題×ソリューション|PSF(プロブレムソリューションフィット)」を見つけ出すために、顧客に「この解決策はどうか?」と聞いていきます。ここでは顧客にイメージが伝われば十分なので、「それさえ見せれば何かしら顧客のニーズがわかる」ような初期のMVPを作りましょう。デモ動画やモック、チラシ、LP、営業資料でもいいですし、海外ではGoogleフォームにプロダクトのイメージ動画が載っているだけのLPという場合も珍しくありません。
次に「ソリューション×プロダクト|SPF(ソリューションプロダクトフィット)」の検証に進みます。この段階では「コレで解決できますか?」と顧客に聞いていきます。簡単なプロダクトを作り、それがソリューションとして顧客の課題を解決できているのかを確認します。プロダクトの表側だけ作って裏側は人力でやってみるという検証方法でも十分です。また既存のツール、例えばShopifyやLINEでひとまず動く状態のものを作ってみるのもいいでしょう。これらが顧客の課題を解決することが分かれば、このステップはクリアです。
最後にプロダクト×マーケット|PMF(プロダクトマーケットフィット)」を検証します。「コレにお金を払って使い続けますか?」と顧客に問う段階で、β版を提供して、それに顧客が粘着してくれるのか、お金を払い続けてくれるのかを確認します。
ちなみに、各段階でのMVPは、自社開発するだけでなく、下図のようなツールを使うことも有益です。むしろ、MVP開発においてはノーコードツールや標準的なサービスを使い、なるべくコストをかけないことを心がけて下さい。例えば顧客と動画でコミュニケーションをとるサービスの場合、いきなり動画機能を実装しなくても、MVPを作るだけならZoomで代替できるかもしれませんし、チャット機能はSlackやLINEで代替できるケースも多いでしょう。
①ユーザーに向けた要件と検証要件を明確に
MVPを考える上では、「(1) ユーザーに向けた要件」「(2) 検証のための要件」を考える必要があります。
まずは(1) ユーザーに向けた要件です。
言わずもがなですが「① コアの価値(機能)が明確になっているか」を考えなくてはいけません。「② 何者かが伝わり信頼できる」ことも重要です。例えばLPを作っても、開発しているのがどんな会社かわからなくては、顧客は不信感を募らせてしまいます。開発者の写真、経歴、開発への思いを書いておくことは重要ですし、口コミ・レビューを掲載しておくことは信頼に繋がるでしょう。
「③ 行動がとれる」ように設計しておくことも忘れないでください。LPを見たあとに、プロダクトの事前予約をしてほしいのに、そのためのURLがなければ何のためのMVPかわかりませんよね。最後に、ユーザーに向けては「④ 値段がついている」ことも重要です。お金を請求するのは怖いことでもありますが、この要件をクリアできたらそのプロダクトは本当に必要とされているということを意味します。また値段がついていることで「有料でも使う」という顧客を見つけられるメリットもあるでしょう。
次いで、(2) 検証のための要件です。
まずは「① すぐに改善ができる」状態にしておきましょう。例えば一般的に、開発を外部の会社にお願いしていると、高速に検証サイクルを回すことは難しくなります。また顧客が他の方とMVPについての情報を共有できるように「② アクセスや共有ができる」状態にしておくことも忘れないようにしましょう。物理的なプロダクトで直接の共有が難しいという場合でも、LPがあれば最低限の共有は可能なので、その程度を目指すと良いかと思います。
②に関連して、MVPは「③ 計測できる」ようにもしておきましょう。アンケートやGoogleアナリティクスなどをうまく使い、顧客の熱狂を測れるようにしておくのがベターです。また「値段がついている」の裏返しですが、「④ 支払いを受け付けられる」ようにしておきましょう。今はさまざまな決済プラットフォームがあるので、導入は難しくはないかと思います。
②MVPプロダクトの軸は何か決める
MVPを構築していくにあたっては、プロダクトの軸を選択していく必要があります。
1つ目の軸は「顧客セグメント」を単一とするのか、複数とするのかです。セグメントは絞って単一にしたほうが検証から市場への導入を早くできるので、なるべく絞ったほうが良いでしょう。多くの市場を見すぎると、標準化しにくくなるという弊害も発生しやすくなります。
2つ目の軸は「イノベーション」の多寡です。あまりに多くのイノベーティブな機能を詰め込みすぎると、顧客のスイッチングコストや学習コストが高くなってしまいます。そのため、最初に顧客に出すときはコアなイノベーションに絞り、それ以外は冒険せず、業界標準的な仕様にしておけば問題ありません。とはいえそのバランスは難しいので、顧客の声を聞きながら調整するのがよいでしょう。
3つ目の軸として、ハイタッチかロータッチかという「ソリューションタイプ」が挙げられます。顧客毎にカスタマイズするのか、誰でも使えるように標準化するのかと言い換えてもいいでしょう。とはいえ、あまりにカスタマイズしすぎると受託開発やコンサルティングビジネスになってしまうので、ある程度標準化は見据えておかなくてはなりません。本当に初期の段階に、どの機能が顧客にとって価値があるのかわからないという状況だったら、一旦ハイタッチ(カスタマイズ)にすることは問題ありません。
③ユーザーに実際に試してもらいバイアスのないフィードバック(回答)を得る
MVPを誰に試してもらうのか、事前に検討しておきましょう。
まずはローンチ前に、一旦自分たちで一通りMVPを試す「ウォークスルーテスト」を実施します。自分たちで試せばわかるエラーなどは潰してから外部の方に試してもらってください。その後、バイアスのない周りの方に試してもらいましょう。なぜバイアスのない方にお願いするのか。皆さんのことを応援してくれている人にお願いすると、あまりネガティブなフィードバックが返ってこないからです。ここまで試したら、あとは「自力でみつけた課題のある顧客に使ってもらう」「市場でみつけた課題のある顧客に使ってもらう」と、順に進めていけばいいでしょう。
④顧客のリテラシーに合わせたUIとチュートリアル(基本的な操作解説)が重要
コア機能を使ってもらえているのだけど、結局顧客のソリューションが解決できていないというケースでは、UX(ユーザーエクスペリエンス)が下がってしまいます。例えばデータを書き出さないと問題は解決できないのに、データを書き出す機能がなければ、顧客の問題は解決できているとは言えず、むしろ中途半端に顧客の時間を奪っている分だけ、顧客の不満は高まってしまうかもしれません。顧客の業務や生活を見渡し、そこにピタッとはまるようなMVP開発を心がけましょう。
また、全く説明もないままにイノベーティブなソリューションを投入しても顧客は上手くプロダクトを使ってくれません。説明書を用意する、ポップアップを出す、チュートリアルや動画を設定するなど、ローンチプランを固めておかないと、せっかく興味をもってこれた顧客が使ってくれないという事態に陥ってしまいますので、顧客の製品利用コストはなるべく下げるようにしましょう。
なにはともあれ、MVP開発はとにかく「小さく素早く何度も試す」ことが重要です。小さなMVPを作り、数人に意見を聞くだけで、プロダクトの方向性が見定まるかもしれません。恥ずかしさは捨て、精度の高いフィードバックをもらうようにしましょう。
また「お金をもらう」ことも大事です。サービスを構築する前に契約できる状態にまでもっていけるなら尚良しです。無料ユーザーと有料ユーザーには天と地の差があります。有料ユーザーから有益なフィードバックをもらいましょう。
MVPには「定量的・定性的に計測していく」ことも重要です。定量が大事なのは当然として、(定量的に計測できないけど)少人数が熱狂しているという状態は、何かしらのPMF達成の予兆かもしれないので、そういう方を見つけたらぜひ話を聞きにいってみてください。
また「目標を設定する」ようにしましょう。スタートアップにとって最大のリソースは「時間」です。とにかく小さく小さくプロダクトを開発しブラッシュアップして、時間あたりの価値を最大化しましょう。
最後に「仮説を搭載/計測」することも大事です。仮説がないと、ある状態が良い状態なのか、悪い状態なのか判断できません。今何を試しているか常に意識しながらMVP開発を進めてください。
ここまで色々と説明してきましたが、大事なことは「顧客ととことん向き合う」こと、「小さく素早く何度も試す」こと。これに尽きます。顧客の話を聞いていれば、何かしらの方向性が見えてきます。1人に聞いてわからなければ2人目、3人目に聞く。そういった姿勢でMVP開発に取り組むといいでしょう。顧客に聞けば聞くほど、熱量の高いプロダクトが作れるようになります。
・ ・ ・
今回は、MVP開発に取り組む上での具体的な方法や注意点やポイントについて解説しました。事業検証の中で本当に顧客の熱量を測れているのか、他社スタートアップ事例を聞きたい、事業について相談したい場合は、事業相談会を実施していますので、ご質問があればお気軽にお問い合わせください。
(編集:pilot boat 納富 隼平 / Onlab事務局)
We will send you the latest events information and articles
or notify opening of application for each Onlab's Program, and more.
We use cookies to improve site usability.
If you do not agree to provide the cookie,
please refrain from visiting the website.
OK