MVPとは何を指すものなのか
はじめに
こんにちは、HR系のSaasプロダクトのPdMをしているhiroakiと申します。
プロダクトマネジメントを回していく中で、MVPという言葉はよく出てきますよね。
ただ、MVPって言葉は人によって解釈が異なりやすいな〜と思っています。MVPはMinimum Viable Productの略で直訳すると、最小実行可能製品。うん、解釈ずれそう笑
ということで、今回はMVPって何を指すものなのか個人的な考えを、ツラツラ書いてみようと思います。
MVPとは検証をするためのもの
いきなり引用で恐縮ですが、『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』には、次のような記載があります。
企業は学習のために何かをつくるのと、収益のために何かを作るのを混同することがあります。
（中略）
MVPのいちばん重要な部分は学習です。それが、私がMVPを「学習のための最小労力」と定義しているゆえんです。
（中略）
学習のためにつくっているのであって、稼ぐために作っているのではありません。
この記述からも分かるように、MVPにおいて学習と検証は欠かせない要素です。企業が顧客の課題を深く理解し、それに基づいて機能を育てることで、最終的に収益へと繋げるプロセスが重要であることが強調されています。
さらに、学習や検証の重要性については、『正しいものを正しく作る』にも次のような記述があります。
「何が確かに分かっていて、何が不確かでわからないのか」をまず知ることが最初の一手となる。そして不確かなことを減らしていく活動、すなわち仮説検証を続けていくことになる。
（中略）
重要なのは、どうすれば「何がわかっていないか」を把握できるようになるか、分かっていないことがわかれば「わかるようになるのか」という実践知だ。
ここでのポイントは、「何が分かっていないか」をまず把握し、それを「わかる」ようにするためのアプローチが求められる、ということです。この視点から以下のような3つの階層に整理することができます。
「わかっている」こと: すでに確実な情報や知識として理解していること。
「『わからない』ということがわかっていること」: 不確実な部分が認識されている。それを解消するための検証が必要。
「わかっていないこと」: 現時点で全く視野に入っていない未知の領域。
この3つの段階を整理して、自分たちが「わからない」ものは何かを整理することが検証においては重要かなと感じております。またファネルの下の方に自分たちの理解を寄せていくことがMVPを通した学習において、重要なのかなと思っております。
フィットジャーニーから考える検証
「わかる/わからない」を理解するためには、何に対して「わかる/わからない」が発生しているのか、つまりその対照を把握することも重要かなと思っております。対象を考える上で、フィットジャーニーを参考にしてみました。フィットジャーニーはPMFに至るまでのスタートアップのフェーズを表したものです（以下の図）。
※参考：FoundX「スタートアップ・フィット・ジャーニー 今どの段階にいて、何に取り組むべきかのガイド
このフィットジャーニーの考え方は、PMFを目指すスタートアップだけでなく、プロダクトマネジメント全般にも応用できると考えています。顧客にアウトカムをもたらすことを目標とするプロダクト開発において、顧客課題、ソリューション、プロダクトについて考える必要があります。それぞれに対して、自分たちがどれくらい理解しているのかを考えることで、プロダクトが適切な方向に向かっているかを検証することができると思っています。
顧客に課題はあるか？それはどのようなものか？
自分たちで考えたソリューションは顧客の課題に対して適切か？
ソリューションはプロダクトに適合するか？実現可能か？
各ステップについて詳しくみていきます。
顧客の課題に対して
この部分が土台となり後のステップにつながるため、最も重要なステップです。インタビューやリクエスト等の顧客の声や、日々とっているデータから仮説を出していき、それらの「わからない（と自覚している）こと」に対して実際の声を聞いて顧客の課題を「わかること」にしていくのが重要だと考えています。
この辺りのディスカバリーのやり方はプロダクトのフェーズやビジネスモデル等によっても変わってくると思います。いずれにせよ、次のソリューションを考えるステップと行き来しながらユーザーの課題の解像度を上げていくことは非常に重要です。
課題に対するソリューションに対して
ソリューションを考える際には、まず「どの課題を解決するのか」を明確にすることが重要です。課題が不明瞭なままでは、適切なソリューションを提供することは難しいため、課題とソリューションの対応関係を明確にする必要があります。ちなみに僕は課題とソリューションの関係を視覚化するために、マインドマップのような図を使って整理しています（以下イメージ図）。
※ 黄色い付箋に課題が書いてあり、ピンクの付箋にソリューション案が書いてあります
また、ソリューションを考える際には、デザイナーやエンジニアといった他のメンバーを巻き込むことが非常に効果的です。自分一人では気付かない視点が存在するため、異なる専門知識を持つメンバーの意見を取り入れることで、より多角的にソリューションを検討できるようになります。
ソリューション案が出たら、それを検証していくことが次のステップです。この段階では、「このソリューションが適切かどうか『わからない』ということがわかっている」状態です。実装する前に、プロトタイプを使ったインタビューや、システムに落とし込む前に手動で同様のプロセスを試して、ソリューションのフィット感を検証することができます。
やはり開発しなくてもわかることは、先に潰しておきたいですよね。
ソリューションの検証をしていくと、顧客の課題の中でどこを解決していくと良いか、その範囲も見えてきやすいなと思っています。そこからMVPつまり検証範囲も絞り込めるのかなと思ったりしています
ソリューションに対するプロダクトに対して
これまでに検証してきた内容をもとに、最終的にプロダクトへどの程度、どのようにソリューションを落とし込むかを決めていく段階です。どの程度落とし込んでいくのか、そのスコープの考え方については『PMと開発チームで解決策の手戻りを防ぐ、松竹梅フレームのススメ』という記事が参考になりました。
エンジニアやデザイナーと協力してスコープを検討する際、重要なのは「何を検証したいのか」という視点を外さないことです。僕もPRDには顧客の課題とアウトカムだけでなく、検証内容や計測メトリクスを記載するようにしています。さらに他の機能との連動性や開発リソース、期間を考えながら最終的に開発する機能を考えていくのかなと思っています。
MVPではないものを考える
これまでMVPやその検証内容について考えてきましたが、この章では逆に「MVPではない」と思うものについて触れてみたいと思います。ここでは、それらの良し悪しは議論したいのではなく、あくまでMVPとは何なのかを考える上での個人的な視点を述べているだけですので悪しからず。。
ただスコープを縮めただけの機能
顧客の課題の切り取り方を誤ると、たとえその後の課題とソリューションがフィットしていたとしても、うまくいかない場合があります。ユーザーのジャーニーを考えた時に、一部の行動を切り取ってそこから課題を見出しても、実際は周辺の行動や環境の考慮も一緒に行わなければならなかったり。そうなると、せっかく開発してもユーザーの課題解決や目的通りの検証ができずに、ただスコープを縮めただけの機能になって勿体無いですね。
単にスコープを縮めただけの機能は、MVPではなく単なる開発の途中の機能になってしまいかねないので、しっかりとした検証が必要かなと思います。
検証したい内容があまりないもの
少し議論の余地があるかもしれませんが、「検証したい内容があまりないもの」例えば、ソリューションが明確であるもの等は事前のかっちりとした検証やMVPを使った学習サイクルが有効ではない可能性もあるかなと思っています。
『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』には以下のように書いています。
あるプロダクトマネージャーから「こういった実験はいつもやらなければいけないのでしょうか？（中略）」と聞かれました。答えはノーです。
（※）こういった実験とは、「コンシェルジュ実験」「オズの魔法使いテスト」「コンセプトテスト」等の開発する前の検証のことを指しています。
（中略）
どんな種類の実験でも適切なコンテキストのもとで適切な使い方をすることが重要です。
わかっていること/わかっていないことを整理した上で、もしそれが検証の必要があるのであれば、MVPを用いた検証のサイクルが有効なのかもしれません。
終わりに
以上MVPとは何かについて、色々書いてみました。
MVPとは、単なる機能の最小単位ではなく、検証を通じて「わかること」を増やしていくための道具だと考えています。
また検証し学習をするためのものなので、その後の学習も重要になってくるかなとも思っています。
その後の学習で実は「わかっていないこと」が多かったなと発見することも多々あったり。学習サイクルを回しながら「わかっていること」を増やして良きプロダクトマネジメントを回していきたいですね！
最後まで読んでいただきありがとうございました！！
この記事が気に入ったらサポートをしてみませんか？