#マーケティング #商品開発 #MVP
新しい商品やサービスを開発する際、最初に何に注力をするといいのでしょうか？
｢完璧な製品を作ってから市場に出したい｣ と思うかもしれませんが、実はそのアプローチが失敗を招く可能性があります。開発の初期段階でお客さんの反応を知るための方法として、｢MVP｣ は有効なアプローチです。
MVP とは何か、なぜ重要なのか、そしてどのように MVP を活用すれば良いのか。今回は、商品開発の成功を左右する MVP の秘訣を紐解きます。
商品開発の MVP
商品やサービスを開発する場合、開発の初期段階で有効なのは MVP を開発し、想定するユーザーに使ってもらいテストをするアプローチです。
MVP とは
MVP とは Minimum Viable Product の略で、日本語では ｢実用最小限の製品｣ と訳されます。英語も日本語でも長いので MVP と呼ぶことが一般的です。
MVP の M はミニマムを指しているように、本当にテストしたい機能やデザインに絞った初期プロトタイプが MVP です。検証したい論点と仮説を明確にし、仮説検証のための手段として MVP をつくるわけです。
MVP が実用最小限のプロダクトと言うように、開発には極力リソースをかけないようにすることが大事です。
MVP は仮説検証の手段
MVP は仮説ありきです。大事なのは目指すつくりたいプロダクトがあり、最終ゴールから逆算して何の仮説を検証したいかが明確になっていることです。
例えば、開発したいプロダクトが自動車だとしましょう。この場合に適切ではないな MVP と、良い MVP からの開発のイメージは次の絵のようなプロセスです (上が適切でなはい開発の進め方、下が適切な開発の流れ) 。
絵の補足をすると、プロダクトアイデアのコアになる仮説は ｢想定するお客さんは、人や物を運びたいニーズを持っているだろう｣ です。ここから MVP としてまずはスケボーを作ってみて、初期仮説を検証するわけです。
ありがちなのは目指す作りたい自動車に対して、MVP はタイヤだけを作り込んでしまうことです (絵の下の開発プロセス) 。いかにタイヤがすばらしくても、これだけでは ｢想定顧客に人や物を運びたいニーズがあるだろう｣ という仮説は検証できません。
MVP はあくまで仮説検証の手段です。仮説があってこそでの MVP です。
MVP は ｢Minimum + Viable｣ の両方を満たす
MVP のイメージで、わかりやすい絵をもうひとつご紹介します。
MVP は ｢Minimum + Viable｣ の両方を満たす必要があるという絵です。
この絵で最終的に作りたいプロダクトは、大勢の人を運ぶ船です (絵の右側の Maximum) 。
開発で目指す最終ゴールから逆算をすると、MVP は人間がひとり乗れるボートになります (絵の中央) 。決してネズミが乗るようなボートではありません (絵の左) 。
以上から MVP つくるポイントは次の3つになります。
- 目指す最終形のプロダクトイメージからの逆算
- 今の開発ステージで優先的に検証すべき仮説の明確化
- 仮説が検証できる最小限の機能の実装
MVP の具体例
では次のパートでは、実際のサービスで MVP の具体例を見ていきましょう。
Facebook の MVP
1つ目は Facebook です。Facebook の初期のログイン画面は、次のようなものでした。
サービスが始まった当時の名前は ｢Thefacebook｣ でした。
当初はハーバード大学の学生向けでした。創業者のマーク･ザッカーバーグがハーバードの在学時に生まれたサービスです。
MVP として出した時点で、今と変わらない仕組みがあるのが興味深いです。具体的には、次のとおりです。
- メールアドレスでログインする
- 大学の知り合いが探せる (Search for people at your school)
- 友人の友人とつながる (Look up your friends' friend)
X の MVP
ではもうひとつの MVP の事例として、X (旧 Twitter) で見てみましょう。
初期の Twitter の名称表記は ｢Twttr｣ でした (母音 (Twitter 内の i, e) がないですね) 。
興味深いのは初期の MVP の時点で、すでに今の X のサービス機能の原型があることです。
- フィード機能の実装 (知り合いの ｢今 ◯◯ をしている｣ の投稿)
- 自分が今やっていることが投稿できる
デザインはシンプルです。
色などの見た目は今の X とは違いますが、X の機能として残っている ｢フォロワーのつぶやきがフィード画面に流れる｣ や ｢自分のツイート投稿が簡単にできる｣ は初めから実装されていました。
MVP からの仮説検証
特にプロダクト開発の初期段階では、MVP を使って仮説検証を行うことが、プロダクトの成功の可否を握ります。
なるべくアンケートやメール･メッセージでは済ませず、ユーザーのところに出かけ、直接の対話からフィードバックを得ることが大事です。遠方で物理的に会うのが難しい場合は、ビデオ通話を使うなどのなるべくリアルでの対話に近い場を設定します。
5つの仮説
では、具体的にどのような仮説を持っておくとよいでしょうか？
仮説は大きくは5つあります。
- 顧客仮説: 相思相愛になれる顧客やユーザーは誰か [顧客ターゲット設定の仮説]
- 問題仮説: 設定した顧客･ユーザーが抱えている問題は何か [解くべき問題設定の仮説]
- ソリューション仮説: 自分たちはどのような方法でお客さんの問題を解決するか [問題に対する解決方法の仮説]
- 価値仮説: お客さんにはどんな価値やベネフィットがもたらされるか [顧客が得られる価値の仮説]
- 価格仮説: お客さんが見出した価値には、お客さんはお金を払ってでもほしいという気持ちになるか [顧客が価値に対して支払う価格の仮説]
まとめると、｢誰のどんな問題に対して、自分たちはどう解決し、それは本質的には顧客･ユーザーにどんな価値をもたらすか。その価値にお客さんはお金を払うか｣ という論点に対する仮の答えが MVP を使って検証していく仮説です。
MVP を投入するタイミング
MVP を開発する目的は、MVP を必要最低限のユーザー価値のあるプロトタイプとし、自分たちが提供しようとしている顧客価値が、本当に想定するお客さんにとっても実際に価値があるかどうかを検証することです。
では MVP を投入するタイミングはいつがいいのでしょうか？
MVP を市場に出すタイミングは、まだ MVP を出すのは恥ずかしいと思う時です。あと少しデザインを良くしたい、機能を追加したいと思う気持ちを抑え、このレベルではまだ恥ずかしいと思う状態で市場に MVP を投入するのです。人に見せたり使ってもらうのをどこかまだ躊躇してしまうということは、他の企業がまだアイデアを実現しておらず、注目されていない段階とも言えます。
いち早く MVP を投入し、お客さんやユーザーの反応やフィードバックをもらい改善をまわせば、後から参入するプレイヤーよりも先行者優位を築けます。
MVP の検証方法
MVP の検証ポイントは、主には先ほどの5つの仮説の通りです。
- 顧客ターゲット設定の仮説
- 解くべき問題設定の仮説
- 問題に対する解決方法の仮説
- お客さんが得られる価値の仮説
- お客さんが価値に対して支払う価格の仮説
MVP という仮説検証では、定量的な指標だけではなくインタビュー調査や観察調査からの定性的な評価も行います。
MVP を実際にお客さんに使ってもらったり試してもらい、お客さんへのインタビューでは次のことを中心に MVP が想定通り機能するかを見極めます。
- 今のお客さんの課題感や問題点を解決できる期待をお客さんが持てるか
- MVP のプロダクトに価値を感じたか。最も価値を感じたトップ 3 は何か。それはなぜか
- 使わなかった機能、価値を感じなかったことは何か。それはなぜか
- プロダクトを自分と同じような状況にある同僚や知人に推奨するか
- 抱えてる問題を解決できる商品やサービスなら、今すぐにでもお金を払ってでもほしいと思うか
MVP での仮説検証から次につなげる
仮説検証を受けて、次の開発方針を定めます。
具体的な学びのポイントは、次の通りです。自分たちが想定するターゲット顧客への提供価値は、お客さんにとっても本当に価値があるかどうかを見極めます。
- 自分たちの ｢5つの仮説｣ は何が正しく、何が想定と違っていたか
- お客さんの価値評価の基準は、それは自分たちと同じだったか
- 次は何を改善すべきか。なくすものは何か。新たに追加するものは何か
Think big, start small
商品開発の初期段階で MVP を導入するということは、｢Think big, start small (志は大きく、スタートは小さく) ｣ を実践するということです。
開発目標の全体構想は大きく描き (think big) 、具体的な開発へのアクションは小さく始めていく (start small) というものです。
Think big, start small からのアプローチは、大きなビジョンと具体的な初動の成果を組み合わせることで、長期的な目的達成と短期的な成果を同時に追求する方法です。
この ｢志は大きく、スタートは小さく｣ において、小さく始める意図は次の2つです。
- 良い失敗をする
- 勝ち筋を見極める
順番に見ていきましょう。
良い失敗をする
良い失敗とは、次の2つを満たします。
- できるだけ早い段階で起こる失敗。小さな失敗
- 失敗から学びがある。学びを次に活かせる
小さく始める意図は、良い失敗をするためです。
ただし、だからといって闇雲に失敗していいわけではもちろんありません。これが小さく始めることのもうひとつの次の意図につながります。
勝ち筋を見極める
小さく始めると言っても、小さければなんでもいいわけではありません。｢志を大きく｣ につなげることが大事です。
つまり、小さく始めるのは、描いた大きな絵を実現するための ｢勝ち筋｣ の解像度を上げるためです。失敗をしたとしても、それが ｢志を大きく｣ に活かされるのであれば良い失敗になります。
小さくやってみたことがうまくいけば、その後に全力でアクセルを踏みにいきます。
まとめ
今回は、商品開発の MVP についてでした。
最後にポイントをまとめておきます。
- MVP とは Minimum Viable Product (実用最小限の製品) 。大事なのは、目指すつくりたいプロダクトがあり、最終ゴールから逆算して何の仮説を検証したいかが明確になっていること。仮説検証のための手段として MVP がある
- ユーザーにとっては、MVP は ｢Minimum + Viable｣ の両方を満たすことが重要
- MVP の検証では5つの仮説をつくる。① 顧客ターゲット設定の仮説、② 解くべき問題設定の仮説、③ 問題に対する解決方法の仮説、④ 顧客が得られる価値の仮説、⑤ 顧客が価値に対して支払う価格の仮説
- 仮説検証から学ぶポイントは、① 自分たちの仮説は何が正しく、何が想定と違っていたか、② お客さんの価値評価の基準は、自分たちと同じだったか、③ 次は何を改善すべきか。なくすものは何か。新たに追加するものは何か
- MVP を市場に出すタイミングは、まだ MVP を出すのは恥ずかしいと思う時。あと少しデザインを良くしたい、機能を追加したいと思う気持ちを抑え、このレベルではまだ恥ずかしいと思う状態で市場に投入する
- 商品開発の初期段階で MVP を導入するということは、｢Think big, start small (志は大きく、スタートは小さく) ｣ を実践するということ。開発目標の全体構想は大きく描き (think big) 、具体的な開発へのアクションは小さく始めていく (start small)
- 小さく始める意図は、良い失敗をするため、勝ち筋を見極めるため
マーケティングレターのご紹介
マーケティングのニュースレターを配信しています。
気になる商品や新サービスを取り上げ、開発背景やヒット理由を掘り下げることでマーケティングや戦略を学べるレターです。
マーケティングのことがおもしろいと思えて、すぐに活かせる学びを毎週お届けします。レターの文字数はこのブログの 3 ~ 4 倍くらいで、その分だけ深く掘り下げています。
ブログの内容をいいなと思っていただいた方にはレターもきっとおもしろく読めると思います (過去のレターもこちらから見られます) 。
こちらから登録して、ぜひレターも読んでみてください！