コストをなるべくかけずに事業のMVPを検証するための具体的な方法8つ

シリヤト!!という事業を運営していることもあり多くの方から事業についてご相談いただいているんですが、MVPの検証にコストや時間をかけすぎな方が多いよなーと感じています。
MVPの検証に大きなリソースや時間を割いたにもかかわらずニーズが全くないことが分かりそれまでの努力が無駄になってしまった、という悲劇はなるべく避けたいもの。
そこでこの記事では、MVPを最小限のコストで検証するための具体的な方法について書いていきます。

※過去記事のカテゴリ別まとめはこちら。

そもそもMVPとは

Minimum Viable Productを略した言葉であり、「ユーザーに価値を提供する上で最小限の機能」という意味です。
ユーザーになんらかのサービスを使ってもらう上で最も重要な機能とも言い換えられます。

なぜMVPという考え方が大事なのかというと、サービスを設計する際にはなんらかの課題・ニーズがあると仮定して、そこに仮説と改善を重ねて拡大をしていきます。
それにあたり、そもそものニーズが全く存在しなかった場合、それらの仮説や改善は全く意味がなくなってしまうのです。
そのため、まずそこにニーズがあるかどうかを最小限の機能を用いて検証することで事業の可能性を探ろう、というのがMVPを用いた事業開発の考え方です。

これによるメリットとして、課題があるか否か、そしてそれを解決できるかという最も重要な仮説を早期に検証することが可能となるため、冒頭に書いたような沢山の時間と費用をかけて商品開発を行ったにもかかわらず全く使われない・売れない、という悲劇を防ぐことができます。
ここからは、どのようにMVPを用いた仮説検証を行うか具体的に書いていきます。

最小限の機能で行う

こちらは具体的な方法というよりも前提に近いですが、MVPでの検証であるにもかかわらず、機能が肥大化してしまっているケースもまま見ます。
例えば会員登録機能は多くのウェブサービスで見られますが、MVP検証の場においては必要ない場合も多いです。
このように、いつかは必要になる機能であっても初期段階では削るべきものも多いので、仮説検証段階から本当に必要な機能かどうかゼロベースで考えることが肝要です。

ヒヤリングする

ここからは具体的な方法論に入っていきます。
簡単な話で、課題を抱えていると仮説を持っているユーザーに対してそれを確かめ、また、自分が考えている解決策が有効であるか聞いてみる、ということです。

ただ、特にC向けの事業である場合ヒヤリングって結構難しくて、ここでの感触が良かったけれども実際にリリースしてみたら全く使われない、ってことはよくある話です。
それを避けるためには以下について注意することが必要です。
ーーーーー
1. （無意識に）ユーザーは嘘をつく
2. ヒヤリングで誘導してしまっている可能性がある
3. ユーザーは飛躍した未来を想像できない
ーーーーー
逆にB向けの事業である場合、経済合理性で動くことが多いのでC向けよりも確度の高いヒヤリングを行うことが可能です。

ヒヤリングについて詳しく書くとかなり長くなってしまうので割愛しますが、近いうちにこのテーマについても書こうと思います。
ちなみに僕は訪日旅行者向けウェブメディアを開始する前に浅草あたりで200人くらいの訪日旅行者の方にいろいろと質問をし、これはイケると感じたので事業開発をはじめました。

事前登録を行う

こちらはITリテラシーが高い業界の方がターゲットである場合に特に有効です。
事前登録を行うためのLPを用意してSNSへの投稿や広告出稿を通じアクセスを集め、そこでどれくらいの登録が行われるのかを見て課題の強さを検証する方法です。
こちらのSmartHRさんの事例がとても参考になります。

ここで問題になるのは、果たしてどれくらいの数値であれば事業としてGOサインを出すべきなのかという閾値設定です。
こちらについてはサービスの単価や市場規模などによって異なるのですが、基本的には登録数ではなく、LPへのCPCと事前登録のCVRを見るべきだと考えます。
なぜなら、登録数は広告出稿料を増やせばなんとかなってしまうからです。
加えて、CPCは今後逓増する可能性が高いこと、事前登録よりも実際の発注に至るCVRの方が当然高くなるということも前提になります。

まず販売する

事前登録とは異なり、こちらはITリテラシーが低い業界の方にも有効です。
要するに、開発する前からサービスを売ってしまおう、というものです。
この方法が適しているのは主にB向けである場合が多いと思いますが、とりあえず営業資料を作ってしまって実際の顧客に販売を行う。
そしてそこで受注を取ることができるようであれば、実際に開発に移行して開発完了後に納品するというものです。
こちらについて、受注を取るためについ納期を短めに伝えてしまいがちですが、特に立ち上げ期の開発では予期せぬトラブルが起こりがちなので余裕を持ったそれを伝えましょう。

クラウドファンディングを使う

ハードウェア、D2Cスタートアップなどに適した方法です。
この方法を使うメリットは、C向けの商品であったとしてもユーザーが納期に寛容であるということです。
ハードウェア・D2Cでは大きめの初期費用が必要になるためここで資金を得られないとそもそも開発できないという状況もあるでしょうし、もはやクラウドファンディングは必須なんじゃないかなーと思ってます。
FABRIC TOKYO社の森さんもクラウドファンディングをおすすめしてますね。
ちなみにD2Cとかだと少なめのロットで作る、という考え方もありますがクラウドファンディングやっちゃった方が在庫リスクをより回避できるのでおすすめです。

人力で行う

ここからは少し毛色が変わって事業設計寄りの話です。
例えばあなたが「AIとの問答により個人に最適なサプリメントをカスタマイズして提供する」というサービスを作ろうとしていると仮定します。
将来的にはもちろんシステムの力でそれを行うべきですが、最初の段階であればその選定システムの元となる知識を持つ人が人力でやり取りすればシステム開発を行うことなくニーズの検証ができます。
なぜなら、このサービスを使いたい人は「最適なサプリメントが欲しい」わけであり、「AIに返信してほしい」と思ってるわけではないからです。

狭く行う

これも上と近いですが、特にオフラインが絡む事業である場合、地域を絞って　スタートするのが有効です。
例えば最近上場して話題のUberは現在は70カ国以上で運営されていますが、最初はサンフランシスコのみで開始しています。
日本だと、トリクルさんは都内8区内のみで営業を開始されていて、最近全国展開を開始する旨をリリースされてましたね。

アプリでなくWEBで行う

最近はずいぶん早くなったみたいですが、iOSアプリだとなんらかのアップデートを行う度に審査期間が生じます。
また、両OSのアプリを同時に開発するのは大変ですし、2019年1月時点でiOSのシェアが4割、Androidが6割とほぼ半々なので、片方のOSに寄せると半分取りこぼしちゃうのはもったいない。
後はインストールして使ってもらうのって結構手間だし、アプリ開発者よりWeb開発者の方が市場に多いというのもあります。
たとえばGunosyさんも開始時はメールでお勧め記事のURLが複数送られてくる、というサービスでした。

まとめ

MVPを検証する方法について色々と書いてきましたが、重要なのは「ユーザーの課題を最小限のコストで検証する」という意思を強く持つことです。
最小限とは？というのはそれぞれの事業内容によって異なりますが、周りを見てるとMVP検証にリソースを割きすぎている場合が多いので、ぜひ一度前提を疑ってゼロベースで考えてみるのがよいんじゃないかと！
その思考を行う上で、この記事が役に立てば嬉しいなーと思ってます。

僕を、すぐに雇えます

僕を月給3万円で雇えるシリヤト!!というサービスをはじめました。
サービスを始めた背景や意図についてはこちら。
初回無料MTG実施中なのでお気軽にどうぞー！

※過去記事のカテゴリ別まとめはこちら。
※こちらからフォローすると更新通知が受け取れます。