MVP（Minimum Viable Product）は必要最小限の機能を持ったプロダクトのことを指しますが、プロトタイプとはどこが異なるのでしょうか。本記事では、MVP開発の概要や実施目的、進め方をまとめました。今後、新しいプロダクトを作成する予定がある人は、以下で紹介するフレームワークなどを使い、効率的にプロダクト開発を進めていきましょう。
MVPとは
MVPとは、「Minimum Viable Product」を略したビジネス用語で、必要最小限の機能を持ったプロダクトのことを指します。この段階のプロダクトは市場に投入され、改良のための顧客からのフィードバックを得る役割を果たします。
簡単にいえば、「アイデアが市場に受け入れられるのか」を把握するための試作品と置き換えられます。必要最小限の機能だけに抑えてプロダクトの作成にかかる時間を短くすることで、競合他社が同じようなプロダクトを出す前に市場に投入でき、認知度で差をつけることもできます。
フィードバックを得たあとには、新機能の追加や改善を繰り返して、プロダクトの完成へとつなげます。
プロトタイプとの違い
プロトタイプも、フィードバックを得るために作成される試作品です。ただし、MVPのような市場投入は想定されておらず、基本的には既存のクライアントに提供したり、社内で共有したりする目的で作られます。
MVPとは異なり、プロトタイプは最低限の機能に留める必要はありません。特にクライアントに提供する場合は、要求に応じた機能を実装することが必要になるでしょう。プロダクト開発の進捗度によっては、完成品に近い試作品が求められるケースもあります。
一方で、MVPは市場で評価してもらうことが前提であり、ユーザの反応を見たりフィードバックを得たりするために実装する機能をどうするか判断します。
PoCとの関わり
PoC（Proof of Concept：概念実証）とは、あるプロダクトが実際に使えるものなのかどうかを検証するプロセスです。仮説検証をスピーディーに繰り返すことで、「このプロダクトは作ることができるのか」「ビジネスとして成立するのか」について判断します。
PoCでは、主に「価値・技術・事業性」に関する仮説を立てて、市場投入などを通して検証を行います。そのため、PoCのプロセスには、MVPやプロトタイプの作成が含まれる、という考え方もあります。
PoCの導入効果や成功のポイントを解説＞＞
MVPを開発するメリット
MVPを開発するメリットには、以下のようなものがあります。
- コストや時間を削減できる
- 失敗のリスクを抑えられる
- 初期段階で顧客のニーズをつかめる
- 方向転換がしやすくなる
- 先行者利益を期待できる
上記のメリットをなぜ得られるのか、以下で詳しく解説します。
1.コストや時間を削減できる
MVPではプロダクト開発の早い段階で市場に投入することで、コストや時間を抑えながらフィードバックを得られます。プロダクトを完成させてから市場に投入する場合と比べると、MVPは機能を限定することができるので、開発にかかるコストや時間は少なくて済みます。
実際に、MVPを市場に投入できたら顧客からのフィードバックをもとに機能を見直し、早期に本来あるべきプロダクト像に近づくことができるため、開発全体のスケジュールも短縮できる可能性があります。
2.失敗のリスクを抑えられる
MVPには、プロダクト開発の失敗のリスクを抑える役割もあります。
プロダクトの作成にあたってMVPを投入しない場合は、入念な市場調査が必要になります。入念な市場調査をしても顧客のニーズを満たせないと、それまでの開発費用や製造コストは無駄になります。
その点、MVPで早い段階から顧客フィードバックを得られれば、ニーズに基づいたプロダクトの開発を進められます。もしアイデア自体に問題があったとしても、MVPはコストを抑え短時間で作成できるため、大きな損失を出す前に軌道修正や撤退することもできます。
3.初期段階で顧客のニーズをつかめる
初期段階で顧客のニーズをつかむと、優先度の高い機能を見極めて開発を進められます。
仮にビジネス用のチャットツールを開発する場合、主な機能としてはビデオ通話やファイル共有、スケジュール共有などが考えられます。いずれもビジネスに役立ちますが、全ての機能を顧客が必要としているとは限りません。
MVPの投入によって、もし使用率の低い機能が見つかった場合は、その機能の開発を中止したり、優先度を下げたりできます。代わりに使用率の高い機能を充実させれば、より顧客満足度の高いプロダクトを開発できる可能性があります。
4.方向転換がしやすくなる
従来の開発手法に比べると、MVPはプロジェクトの方向転換が行いやすくなっています。短いスパンで要件を見直せる上に、開発・作成のコストも抑えられるためです。
仮にアイデアの一部に問題があったとしても、次のMVPを作成してその問題を解消することができます。まだプロダクトを完成させていない段階だからこそ、機能や仕様を調整して、顧客のニーズに沿ったものに方向転換ができるようになります。
一方で、要件定義を詳細に設定したあとにプロダクトを一気に開発する手法では、小さな方向転換でも多くのコストがかかります。プロダクトの開発途中で仕様に重大な欠陥が見つかった場合は、要件定義からやり直す必要があり、市場投入が遅れてしまう可能性もあります。
5.先行者利益を期待できる
想定顧客となる消費者や企業から早期に認知されるために、MVPを活用するケースもあります。
特に先端技術を搭載したプロダクトは、いち早く市場投入をすることで注目を得ることができます。市場からの注目は、先行者利益や、他の企業との提携や出資などにつながる可能性があります。
ただし、革新的なプロダクトだと認知されるには、競合他社や代替品がないことに加えて、顧客の課題を解決できることが前提になります。斬新なアイデアであったとしても、ニーズがなければ注目は集められないということは意識しておきましょう。
MVPの代表的な種類
MVPはいくつかの種類に分類されます。ここからは、MVPの代表的な種類について解説します。
モックアップ
モックアップは、プロダクトの外観を完成品に近い形に整えて市場に投入する手法です。基本的に機能を実装しないため、完成品と同じ見た目でも動作することはありません。
パソコンを例に挙げると、キーボードからの入力や画面表示は実装せず、デザインや大きさ、重さなどを判断してもらうことが目的になります。ウェブサイトの試作ページや印刷物のゲラ刷り（試し刷り）なども、モックアップと呼ばれる場合があります。
コンシェルジュ
コンシェルジュは、顧客の獲得からプロダクトの提供にいたるまでのプロセスを、全て手作業で行う手法です。基本的には、プロダクトの開発前に「需要があるのか」を調査する目的で行われます。
具体的にどのような手法が該当するのか、以下では配食サービスを例にして紹介します。
手順1.高齢者などが多い施設に行き、サービスの仕組みを説明する
手順2.献立に必要な食材を調達し、自ら調理をする
手順3.興味を示した顧客の自宅に行き、配食サービスを提供する
手順4.顧客からフィードバックをもらう
本来は食材を自動発注したり、工場で調理をしたりするビジネスモデルであっても、上記のように全て手作業で対応します。そのため、製造プロセスの大部分が不透明なままでも、コンシェルジュでは大まかな需要をつかむことができます。
オズの魔法使い
オズの魔法使いは、顧客から見える部分だけを実装し、他の機能は全て手作業で行う手法です。「ウィザード法」とも呼ばれ、プロダクトの需要を調査するために行われます。
前述のコンシェルジュとの違いを明確にするために、以下では同じ配食サービスにおける例を紹介します。
手順1.ウェブサイトを立ち上げ、申し込みページを作る
手順2.献立に必要な食材を調達し、自ら調理をする
手順3.配送サービスを使って、調理した商品を届ける
手順4.顧客からフィードバックをもらう
顧客からすると、申し込みまでのプロセスや商品の受け取りは目に見える部分です。そのため、手順1と手順3は実装し、手順2は手作業で行います。
顧客は実際のプロダクトと同じ流れでサービスを利用できるため、コンシェルジュよりも具体的なフィードバックを得られる可能性があります。
コンビネーション
コンビネーションは、既存のプロダクトを組み合わせてMVPを作成する手法です。使い勝手を完成品に近づけることは難しいケースが多いのですが、必要な機能を実装したMVPを提供できれば、アイデアに対する需要や課題を確認することができます。
例えば、オンライン診療を受けられる医療システムは、病院と患者、診療に特化した通話アプリの組み合わせで実現できます。一般的な通話アプリは診療に特化していないため、画質の問題で顔色を判断できない状況も想定されます。しかしコンビネーションで、一般的な通話アプリを使えば、問診などある程度の「診療」は可能なので、病院も患者もこのサービス形態が便利かどうかを判断できるでしょう。
コンビネーションの利点は、アイデアに対する需要から次の工程（診療に特化した通話アプリの開発など）に移れるかを判断できることです。顧客からのフィードバックをもとに機能を追加すれば、顧客のニーズに合ったシステムを構築しやすくなるでしょう。
ランディングページ
ランディングページ（LP）とは、お問い合わせや商品購入などの成果につながった行動を意味するコンバージョン（CV）に特化したウェブページです。基本的には営業トークを再現したような内容で、チラシのように目立つデザインやフォントが使用されています。
MVPにおいては、プロダクト自体に直接ふれてもらう形ではなく、LPを通してユーザーの反応を検証するために活用します。例えば「先行申し込み」や「試供品の申し込み」ができるボタンを設置し、プロダクトの特徴や解決できる課題を分かりやすく紹介して、その内容に興味をもったユーザーが申し込みをする流れを作ります。
SaaSを開発している企業は、LPを通して、利用者登録してもらうことで、すぐにMVPを提供できます。有形商材を提供する場合でも、事前に申し込みや資料請求の数を把握できるため、反響がどれくらいあるかを確認できます。
MVPの検証に使えるフレームワーク「MVPキャンバス」とは
MVPの設計や検証プロセスでは、「MVPキャンバス」と呼ばれるフレームワークが活用されます。MVPの目的を達成するためには、必要最小限の機能を開発することが重要です。作りこみすぎるとコストや時間がかかり、逆に機能が不足すると的確なフィードバックを得られません。
そのため、MVPキャンバスでは仮説検証の要素を10に分けて、まずは必要なデータを収集するためのMVP像を明確にします。各要素は、それぞれ以下の通りです。
- 仮説
顧客が何を求めているのか、プロダクトで解決できる課題は何か。 - 目的
検証で何を学びたいのか。 - 検証方法
どうやって検証するのか。 - 必要なデータや条件
どのようなKPIを設定するのか。 - MVP
どのようなMVPを設計するのか。 - 作成や検証のコスト
どれくらいの費用がかかるのか。 - 作成や検証の時間
どれくらいの時間がかかるのか。 - リスク
どのようなリスクがあるのか、未然に回避できるリスクはあるのか。 - 結果
どのような検証データを得られたのか。 - 学び
検証で何を学んだのか、課題はどこにあるのか。
仮説検証の目的や方法、条件などを明確にすると、MVPに必要な機能が分かります。また、検証後には「結果」と「学び」をまとめることで、今後のプロダクト開発の方向性を検討しやすくなります。
MVPの失敗例
ここからは、MVP開発でありがちな失敗例をもとに注意したいポイントを紹介します。
プロダクトの完成が目的になる
MVPを作成する目的は、プロダクトの完成ではありません。あくまでもフィードバックを収集して、プロダクトが顧客ニーズに合っているかを検証することが目的です。
MVPに必要以上の完成度を求めると、フィードバックがない状態で開発を進めることと同じになります。途中から顧客のニーズを反映することや、柔軟な方向転換ができなくなるため、MVPとは言えなくなります。
また、市場投入の時期が遅れると、先行者利益を損なうかもしれません。MVPの作成途中で「この機能を追加したほうがいい」と感じても、その機能はMVPに本当に必要なのか、まずは市場投入できる状態にすることを優先するべきではないかを検討しましょう。
リリースまでの期間が長い
リリースまでの期間が長いMVPも、本来の目的から外れやすくなります。
MVPはスモールスタートが原則であり、市場投入が遅れるとプロダクトの新規性や優位性が損なわれます。リソースが豊富な後発企業などに先行されると、収益化自体が難しくなる可能性もあります。
特に技術の移り変わりが激しい業界では、作成途中に時代遅れのプロダクトになるリスクもあります。そのため、市場投入の計画を立てる際には、期間を短めに設定しておくことが重要です。
ただし、スピードのみを優先すると、必要最低限の機能を実装できなかったり、使いにくさが目立ったりする、MVPではないものになってしまいます。前述のMVPキャンバスを活用しながら、目的に合った要件・仕様を慎重に判断しましょう。
検証内容が明確でない
MVPでは、新規で立ち上げ予定のプロダクトが市場に受け入れられるのかを検証するための段階であるため、検証内容が明確になっていないと目的を達成できない可能性があります。
MVPの検証内容をうまく整理できない場合は、前述した仮説検証の要素を整理できるフレームワークであるMVPキャンバスを活用しましょう。MVPキャンバスの要素を順に埋めていくことで、検証内容が明確ではないという理由での失敗を回避できます。
検証内容を設定したら、各要素が関連しているかを精査します。これらの要素の設定に時間をかけ過ぎてもMVPの本質から外れてしまうため、検証に必要な最小限の要素を埋めて、できるだけ早くMVPを市場に投入することを目指すことが重要です。
MVPの作成前に市場投入までの計画を立てよう
MVPを市場投入することで、コストや時間を抑えながら早い段階でフィードバックを得られます。フィードバックをもとにプロダクトを改善すれば、顧客のニーズを満たしたプロダクトを作成しやすくなるでしょう。
そのためには、自社のプロダクトで解決したいユーザーの課題を洗い出した上で、MVPを通して検証したい仮説を立てることが大切です。
（提供：CAC Innovation Hub）
