製品・サービスを開発するにあたって「MVP」を作ることがあります。
しかし具体的にMVPとはどういうものか理解しておらず、本当にMVPを開発に用いるべきか判断できていない方も多いのではないでしょうか。
MVPは製品・サービスのニーズを把握するのに有効で、リーンスタートアップを成功させるための重要なプロセスの一つと言われています。最小限の労力で今後本開発すべきなのかを判断できるので、新規事業・サービスなどを開発するのに適しています。
MVPを用いて開発を成功させるためには、以下の3つがポイントです。
- 開発は最短で行う
- ユーザーとの親密度を上げる
- 具体的な回答を得るための質問を作る
この記事ではMVPとはどういう手法か、メリット・デメリット、MVPを開発する際のポイントや利用すべきフレームワークなどについて解説しています。
目次
MVPとは、最短期間で仮説を検証する製品を開発すること
MVPは『Minimum Viable Product』の略で、「必要最低限の機能だけを搭載した製品」を意味する言葉です。最小限の機能を持った製品をユーザーに提供し、ユーザーの声を吸い上げます。
MVPの最大の目的は「仮説の検証」です。
ユーザーからのフィードバックをもとに、開発中の製品やサービスが本当にユーザーから求められているのかを、最短で判断することができます。つまり、「売れるかどうか」を判断するために使います。
MVPは、新規事業開発や今後仕様が変更されうる開発には最適です。現状どう変えるか具体的に決まっていないものの、修正・変更点が上がることが想定されている場合はMVPを活用すると良いでしょう。
一方、既存システムの改修や、デザインをリニューアルする場合など、事前に方針が具体的に定まっていたり、仮説検証を挟むことがないなら、そのまま完成を目指した方が効率的かと思います。
MVPを開発するメリット・デメリット
MVPを開発するメリットとデメリットは以下です。
<メリット>
- リリースから仮説検証を最短で行える
- ユーザーのニーズからズレた製品開発のリスクを回避できる
<デメリット>
- ウォーターフォールで開発を行う場合には向かない
- 開発に2ヶ月以上かかる複雑な機能には向かない
参考：MVP（Minimum Viable Product）とは？実践するメリットと検証方法
参考：MVPとは？ 実用最小限の製品で顧客ニーズを正確に測るマーケティング技法の正体
メリット
リリースから仮説検証を最短で行える
MVPを開発する場合、ユーザーが求めている「最小限の機能」に集中します。その結果、シンプルな製品作りを自然と心がけるようになります。
複雑な製品を作る程、開発に費やす工数が大きくなり、リリースまで時間がかかります。しかし、MVPは「製品やサービスに需要があるのか、素早く検証する」ことが目的なので、リリースまでのスピードも早くなります。
ユーザーのニーズからズレた製品開発のリスクを回避できる
MVPを用いることで、ユーザーのニーズに沿って開発を進めることができます。
実際に本開発をすべきかを正確に判断できるので、「市場から求められていない製品の開発」を行うリスクを回避することが可能です。
製品開発にかかるコスト・リソースもおさえられるので、開発中止の判断によるダメージも最小限におさえることができます。
デメリット
ウォーターフォールで開発を行う場合には向かない
MVPは、スケジュールを綿密に組み立ててから開発を行うウォーターフォールの手法には向いていません。
MVPは、ユーザーの声を汲み取り完成系を目指すことが多いため、仕様変更やスケジュールに融通が利かないウォーターフォールとは相性が悪いです。
綿密な見積もりを考えるよりも、製品自体の課題を解決する方にリソースを割いた方が良いでしょう。
開発に2ヶ月以上かかる複雑な機能には向かない
開発に2ヶ月以上かかる複雑な機能はMVPに不向きです。MVPは「最短で」最低限の製品を作ることを目指しているので、期間は「２ヶ月以内」が望ましいです。
Cloud ElementsのCEO兼共同創設者であるMark Geeneは、MVPで開発を行う条件のひとつに「2か月の開発期間内に作ること」を挙げています。機能を最小限におさえても、2ヵ月以上の期間がかかる見込みなら、MVPの開発には向いていないと判断しましょう。
参考：MVP開発の6ステップ / FIモントリオール発・IoTスタートアップの紹介
MVPで開発を成功させる3つのポイント
MVPを通して開発を成功させるポイントは以下の3つです。
- ユーザーと良好な関係を築く
- 完璧を求めるのではなく、「最小限最短」を目指す
- 具体的な答えを収集できる質問項目を作る
参考：MVP開発はプロダクト開発ではない | ソリューション検証の進め方
1.ユーザーと良好な関係を築き、集客する労力を減らす
MVPを開発過程に導入する場合、ターゲット層と仲良くなると成功に近づきます。
利用者のフィードバックありきのMVPですから、長期的な関係性を築いた方が、より深いコメントが得られます。特に、前回使った時よりも具体的に何が良くて、何が悪くなってしまったのか聞ける点で効果的と言えます。
数を当たるのではなく、少人数でもファンを作れる対応を心がけるのがオススメです。「無料で製品を使えるクーポンを渡す」などして、ユーザーの心が離れない工夫をしましょう。
2.完璧を求めるのではなく、「最小限・最短」を目指す
MVPを開発する際は、最小限・最短を目指しましょう。
細部にこだわって完璧なものを求めすぎると、失敗の原因になりやすいからです。MVPはフィードバックを解消していく過程の中で完成に近づけていくものです。
初めから完璧なものを作ろうとして開発期間が延びてしまうと、「最短で仮説検証が行える」というMVP開発のメリットを潰しかねません。最低限の時間とコストでの開発を目指しているので、完全なものは目指す必要はありません。
3.具体的な答えを収集できる質問項目を作る
試作品を使ってもらうことで得たユーザーの声を、問題解決に活かさないとMVPを行う意味がありません。しかし、フィードバックを全てユーザーに委ねるのではなく、正確な情報がもらえるような質問項目をつくることが大切です
たとえば新型の掃除機を使ってもらったとすれば、「この掃除機で使いにくい点は何ですか？」という曖昧な質問の仕方ではなく、「吸引力を5段階で評価してください」「移動時の滑らかさを5段階で評価してください」など、ポイントを絞って回答が得られるようにすると良いでしょう。
MVPの王道フレームワークは「MVPキャンバス」
MVPの開発では、独自のフレームワークとして「MVPキャンバス」を使用します。
MVPキャンバスとは、MVPの無駄をなくすために、AppSociallyの高橋氏とRecruit MTLが共同で開発した思考プロセスのことです。
MVPキャンバスは以下の10の要素から構成されます。
- 仮説
- 学び
- 実証
- データ・条件
- 製造
- コスト
- 時間
- リスク
- 結果
- 学び
MVPキャンバスは、チーム全体の認識を合わせたり、目的がズレるリスクを減らすために有効です。MVPキャンバスの作成しておくことで、「そもそも検証したい仮説な何か？」など、原点回帰がしやすくなります。
MVPキャンバスを使わないとユーザーの声に振り回されて目的が変わったり、開発中に仕様が変わったりするリスクがあります。
要素1：仮説
作ろうとしているサービスや製品で、最優先の仮説を書きます。同時に優先順位まで書くと、何から着手すべきか明確になり、スムーズに開発を進められるでしょう。
まずは、世の中でどんなサービスに需要がありそうか、ブレインストーミングなどを行い案をたくさん出すと良いでしょう。
要素2：学び
なぜ要素1で挙げた仮説を検証したいのか、または何のために仮説を検証するのか書きます。目的を明確化することでチーム間の認識齟齬をなくし、今後もブレることのない軸を作ります。
要素１で出した仮説の問題点を洗い出し、最もリスクの大きい問題を選定します。
要素3：実証
仮説を検証するために、どんな実証の仕方をするのか書きます。複数の実証法が出た場合は、新たにキャンバスを作り比較すると効果的です。
要素4：データ・条件
仮説を検証するために必要な条件や、定量化されたデータを記入します。
ここに記載された条件やデータを元に、実証結果の良し悪しを評価します。
実証の仕方にもよりますが、記事ならPV数、動画なら視聴回数、CVRなど具体的に目標数字を設定します。そして、なぜその数値を目指すのか根拠も明確にすると良いでしょう。
要素5：作る
要素1～要素4までの内容を元に、PR動画を作るのか、試作品を作るのかなど、仮説検証のために必要なものを作ります。
要素6：コスト
要素5で決定したものを作るためにかかるリソース数を見積もります。アイデアが複数ある場合は、費用対効果が最も高いものを選ぶのがベターです。
要素7：時間
仮説を実証するまでにかかる時間を見積もります。具体的かつ現実的な数値を書くことで、「納期」のような役割を果たし、生産性が向上しやすくなります。
要素8：リスク
今回のMVP開発はどんなリスクが回避できて、逆にどんなリスクが発生するか書きます。
発生するリスクに対しては、リスクヘッジする方法も考えましょう。
要素9：結果
得られた実証結果を記載します。
要素4で書いた条件やデータを元に、OKかNGか判別し、課題を浮き彫りにすると良いでしょう。
要素10：学び
実証結果から、分かった問題や、その改善案、ネクストアクションを記載します。
MVPの開発の2つの注意点
MVPの開発で注意すべき点は以下の2つです。
- 見た目・使い勝手を疎かにしすぎない
- ユーザーの声に振り回されすぎない
MVPを開発する際に陥りがちなことですので、事前に対策し、スムーズに開発が行えるようにしましょう。
1.見た目・使い勝手を疎かにしすぎない
最短で作ることを目指していると言っても、ある程度の使いやすさや見た目には注意を払いましょう。
UIが悪すぎたり見た目が極端に悪いと、本来検証したかった仮説に関係ないフィードバックが多くくる可能性があります。
「最低限の機能」を作るとはいえ、デザインやUIを度外視するのは避けてください。
2.ユーザーの声に振り回されすぎない
ユーザーの声を取り入れようとし過ぎて、MVPを行う「本来の目的」を忘れないように注意しましょう。
目的がぶれると、初めに定めた目的を達するために仮説・検証した時間が徒労に終わる可能性があります。
確かにMVPは、ユーザーの声を取り入れることで、製品の質を上げていきます。しかし、MVPはユーザーの声を取り入れることが目的ではありません。MVP開発を通して、初めに決めた問題を解決することが目的です。
そのため、解決したい問題に関わるコメントを取捨選択する必要もあります。
まとめ
MVPはユーザーが製品・サービスを本当に求めているのか、本当に売れるのかなどを把握するのに有効です。特に新規事業・サービスなど、市場に新たな価値を提供する場合にはMVPを活用して開発を進めるのが良いでしょう。
逆にウォーターフォールのように開発要件ががちがちに固まっている場合は相性があまりよくありません。
MVPを開発スピードとユーザーとのコミュニケーションの方法を強く意識することが成功のコツです。実際にMVPを作る際は、MVPキャンバスと呼ばれるフレームワークを活用しましょう。
MVPを作る際、最短を意識するあまりデザインやUIに無頓着すぎると良いフィードバックが返ってこない恐れがあります。また、ユーザーのフィードバックに反応しすぎると、本来のMVPの目的が果たせなくなることもあるので注意しましょう。
コメント