MVP設計と検証
/w=3840,quality=90,fit=scale-down)
なぜ今さらMVPなのか
そう思った方もいるかもしれません。なぜ改めてMVPについて記事にするのか。それはMVPが非常に有益な概念であり、広く普及したからこそ誤解や誤用が増えているからです。(下記)
MVP開発でよくある間違いや失敗例
- 最小の製品が良いとやみくもに機能を削る
- MVP開発に予算のほとんどを費やしてしまう
- 市場投入を前提としない製品をMVPとして開発してしまう
- MVPで何を検証したら良いか明確でない
- 提供価値が不明確なままMVPを開発してしまう
- MVPのリリース後、何をどう改善すれば良いかわからない
そこで今回改めてMVPについて整理することで、みなさんにMVPをより有効に活用してもらえれるのではと考えました。単なる整理ではなく、シリアルがスタートアップスタジオとして実践の中で学んだ、実際に活用できるMVP開発のノウハウも交えてお話ししようと思います。記事は前編•後編に分け、前編では「MVP設計と検証」後編では「MVPの改善方法」について解説していきます。
MVP普及の背景とMVPの定義
MVPとは（Minimum Viable Product）の略で、直訳すると「実行可能な最小の製品」となります。新規事業やスタートアップのプロダクト開発で採用されているMVPですが、なぜここまで普及したのでしょうか。それは、世の中のニーズが多様化・複雑化・流動化しているためです。世の中に必要とされる製品とはどんな製品か実際に市場にリリースをしなければ判断が難しくなっており、このような状況の中で、実際に市場で製品を検証するための有効な製品開発手法のひとつとしてMVPの概念が確立されました。一般的に、製品を開発するには大きなコストがかかります。そこで、製品を市場で検証するために必要な最低限のものにすることで開発コストを最小に抑えつつ、検証による成果を最大化することを狙ったものがMVPです。
この背景を踏まえ、改めてMVPの定義と要件を整理すると、以下のようになります。
MVPの定義
市場に投下し、実際に利用してもらうことで製品の検証や改善を行うことを目的とした最小の製品
MVPの要件
- 市場に投入可能な製品であること
- 実際に利用可能な製品であること
- 最小の製品であること
MVPで検証すべきことは何か
上述の通り、MVPで重要なことは市場で製品の検証をするためのものであることです。
もう少し詳しく説明すると、製品を市場に投下し、リアルなユーザーに利用してもらうことで、リアルな環境で提供価値を実現する製品かどうかを検証できることが重要です。
また、MVPが想定する提供価値を実現できていなければ、その原因を特定し、製品の改善を行う必要があります。実際の利用を通じて製品の課題を発見することも、MVPの重要な目的のひとつと言えます。
繰り返しになりますが、MVPは製品の検証とリリース後の改善を前提とした開発手法です。そのため、検証コストの最小化、その後の改善のしやすさなどを考慮した結果、最小の製品が合理的であるとなるわけです。
最小の製品とは？その基準はどのように決めるのか
さて、それではMVPとして最適な最小の製品とはどのようなものでしょうか。一般的に、適切なMVP開発の説明として、以下のような図が有名です。
/w=3840,quality=90,fit=scale-down)
しかし、実際にMVP開発をする際には、「スケボーが最小の製品なのか？」「バイクが最小の製品なのか？」という論点が必ず発生します。このような論点に答えを出せいないケースを多々みますが、それは「最小の価値」が定義されていないからです。スケボーとバイクでは提供価値は明らかに異なっています。（下図）
ユーザー視点・ビジネス視点から提供すべき最小の価値を定義した上で、その価値を実現する最小の製品をつくることが重要になります。つまり、最適なMVPとは、最小の価値を実現する最小の製品であり、最小の製品とは最小の価値を実現できる最低限の製品となります。
/w=3840,quality=90,fit=scale-down)
よいMVPと悪いMVP
よいMVPは「最小の価値 = 最小の製品」となるものです。
/w=3840,quality=90,fit=scale-down)
それでは、逆に悪いMVPとはどのようなものでしょうか。実務でよく見かける悪いMVPのパターンは、以下のの3つです。
/w=3840,quality=90,fit=scale-down)
このような悪いMVPのパターンになっていないかみなさんもぜひ振り返ってみてください。
MVPの設計手順
ここまででMVPとは何か、MVPで何を検証するのかは何かを説明しました。
それではMVPは具体的にどのように設計するのでしょうか。その手順を説明して前編を終わりにしたいと思います。
MVPの設計手順はさまざまありますが、シリアルでは提供価値を起点とした下記のようなMVP設計手順をおすすめしています。
提供価値を起点としたMVP設計の手順
- 最小の提供価値を定義する
- 価値を構造化し要素分解する
- 分解を続け、US（ユーザーストーリー）を定義する
- 各USに対して機能やOpsの設計をする
提供価値を起点としたMVP設計では、まず最小の提供価値を明確に定義し、それを構造化・分解していくことでUS（ユーザーストーリー）の定義を行います。USを定義できたら、それぞれのUSに対して機能やOpsの設計をしていきます。
下記に具体例として、UberやGOのようなオンデマンドタクシーサービスのケースを例に、提供価値の定義→提供価値を構造化・分解→US定義→機能・Opsの設計までの一連の流れを説明します。
/w=3840,quality=90,fit=scale-down)
最小の提供価値の定義
既存のタクシーの課題を解決するオンデマンドタクシーの提供価値として今回は「タクシーをスマートに利用できる」と定義しました。
提供価値の分解
「タクシーをスマートに利用できる」はそれぞれ「手配」「乗車」「車中」「下車」の4ステップに分けることができ、それぞれのステップがスマートに利用できる必要があります。そして、これをさらに分解していきます。例えば乗車がスマートとはどういったことが分解していくと「乗車したらすぐ発進する」ことが必要な要素として分解することができます。このように提供価値を実現するために必要な要素に分解していきます。
USの定義
価値を分解していくとUS（ユーザーストーリー）と言われるサービスやプロダクトに求められる具体的な要求内容を定義することができます。例：「乗車したらすぐ発進できる」→「運転手に目的地が事前に伝わっている」USレベルまで要求が具体的になってはじめて機能を設計することができます。
機能やOpsの設計
USが定義できたらそのUSに対してUSを実現するための機能やOpsの設計を行います。例：運転手に目的地が事前に伝わっている」→「目的地の事前登録」など
以上がMVP設計の手順になります。
かなり概略的な説明ではありますが、今まで感覚でMVPを設計していた方には精度の高いMVPをつくる手順としてとてもおすすめなのでぜひ試してみてください。
前編の要点まとめ
- MVPは不確定要素の多い市場において、実際に市場に投下し製品検証するためにうまれた概念
- 最適なMVPとは、市場投入可能な製品かつ最小の価値を実現する最小の製品である
- 最小の製品とは最小の価値を定義することで適切に設計できる
- MVPを活用して実際の市場で製品が機能するか（価値を実現できるか）を検証し、改善する
- MVPの設計は、最小の提供価値を定義→価値を構造化・分解→USを定義→機能設計の順で進める
いかがでしたか？前編では、MVPの定義や検証、設計手順などについて解説しました。
MVPはリリースがゴールではなく、市場での検証と改善を経て、提供価値を実現するプロダクトへと成長させることが重要です。本記事の後編では、価値を実現した製品である MVLP（Minimum Valuable Product） の説明とMVLPに到達するために必要なMVPの改善手法についてお話しします。
X（Twitter）@Adachildren でも最新のプロダクト開発情報を発信しています。もし今お悩みのことなどあれば、DMやコメントで気軽にご相談ください。
🙋♂️ 日本のスタートアップスタジオのスタンダードをつくる仲間を募集しています!!
プロダクトマネージャー、デザイナー、エンジニア、事業開発、マーケ全方位で01特化の人材を募集しています。興味がある方は下記RECRUITページよりお問い合わせください。
🤝 一緒にスタートアップをつくるパートナー企業を募集しています。
共闘や協業をお考えのスタートアップや新規事業の方々は、下記CONTACTページよりお気軽にご相談ください。