MVP検証の成功確度と効率性を高める「最適なミニマム加減」の決定方法
こんにちは！NEWhで新規事業の伴走支援をしている谷口です。
今回は練り上げてきた新規事業アイデアを「見える」「触れられる」「使える」カタチにして、実際のユーザーに初めてその価値を体験してもらう試金石となる、MVP検証について改めて考えてみたいと思います。
はじめてMVP検証に挑もうとされている方、何度かMVP検証にトライしてきたけど、どうもうまくいかないという方への学びやヒント、ハードル突破の一助になればと思います。
MVPとは何か？ビジネスアイデアを加速させるためのカギ
まず改めてここで、MVP(Minimum Viable Product)とは何か？どんな仮説を検証するためのものなのか、その定義や位置づけから整理したいと思います。すでにMVPについては酸いも甘いも知り尽くしているという諸兄も多くお見えかと思いますが、改めて向き合ってみると、その深さに改めて気づくことも多いです。
『リーンスタートアップ』の著者、エリック・リースの定義によると、このように定義されています。
チームが最小の労力で顧客についての最大量の検証済み学習を収集できる新製品のバージョン。
もう少しだけ補足を付けた定義としては、このような表現もされていますね。
「最小限実行可能製品」または「MVP」とは、新製品を市場に導入する開発手法で、基本的な機能を備えていますが、消費者の注意を引くのに十分です。最終製品は、製品の初期ユーザーから十分なフィードバックを得た後に市場にリリースされます。
これら定義の通り、新製品(新サービス)について、ターゲットとする顧客から最少の労力で、最大のフィードバックを得るための文字通りミニマムバージョンの製品(サービス)という意味合いです。
なぜ「ミニマム」でなければならないのか？
MVPを語るうえで、その背景にあるのが「リーンスタートアップ」です。新しいビジネスアイデアや製品を市場に導入する際のアプローチで、「仮説 - 実験 - 学習 - 反復」というサイクルを通じて、効率的なリソース利用と市場への素早い導入を目指すものですが、このアプローチの核となるのがMVPです。
リーンスタートアップは、失敗のリスクを最小限に抑えつつ、市場のニーズに迅速に対応することを目的としています。MVPはこのプロセスの中で、製品が顧客にとって価値あるものと認識されるか、PoC（Proof of Concept）を通した仮説検証するために欠かせません。MVPを通した顧客との対話から、企業はより確かな意思決定を行い、製品のブラッシュアップやビジネスモデルの調整を素早く行うことが可能になります。これを行うことで、陥りやすい「作ってみたはいいものの、使われない」「思ったほど売れない」といったリスクを極力下げることができます。
MVPの4つのタイプ
次に、数多く世の中で論じられているMVPの類型やその活用事例について、MVPのタイプを4つに分類しました。
注意したいのは、これらは決して順番に行うべきものでもなく、プロジェクトの状況や明らかにしたい仮説、チームが持つケイパビリティ、リソースや期間、予算などの制約事項によって、自由に選択すればよいということです。
定義や類型の知識だけでは、実際に運用できない理由
ここまで定義や類型をお伝えしてきましたが、この情報をもとに正しく「最少の労力で最大の学習を得る」MVPを作り上げることができるでしょうか？MVP検証の経験者であれば、多くの方の答えはNOだと思います。その理由として、大きくは3つが挙げられます。
核となる提供価値やその仮説が不明瞭
MVPの範囲を絞り込むための核となる提供価値が何なのか、その境界線があいまいになっていることが多くあります。これは、MVP検証に至るまでの顧客との対話を通した深い理解が不足していたり、市場や競合に関する十分な調査を経ていないことに起因することが多くあります。
また、仮に核となる提供価値を認識できたとしても、顧客に何を問うのか(何が未検証のまま残されている仮説なのか)？が不明瞭な場合、やはりMVPの要件を明確に定めることは難しくなります。
仮説検証の経験不足
新規事業開発自体が初めてであったり、いわゆるプロダクトアウトの製品提供による成功体験があったり、トップダウン型の文化が下地にある場合、こうしたMVPの検証方法やそのプロセスに関する理解や経験不足を抱えたまま、プロジェクトが進行してしまうことがあります。
検証方法の「ミニマム」度合いが不明確
検証プロセスやMVPをどの程度までミニマムにするべきか、何が正解なのか、その判断が難しいところです。これは、リソース、時間、コストに関する制約と、市場への迅速な展開とのバランスを取ることそれ自体、またそれをロジカルに決めきる、ステークホルダーに説明し納得してもらうことが困難であるためです。
「ミニマム」度合い判断のプロセス
この3つの障害を乗り越えてミニマムな提供価値と機能を筋肉質に絞り込むためにはどのようにすればよいか、その実践的な進め方を考えてみます。
1：仮説を棚卸する
まずはじめに、ここに至るまでに立ててきた仮説と、顧客インタビューやアンケートによって検証した結果、その結果から生じた新たな仮説を整理します。
ここで注意したいことは「インタビューやアンケートで検証したことが、必ずしも正ではない」ということです。MVP検証前に行ったこれらの多くは紙面や口頭、動画などのイメージをもとに回答されたもの。ユーザが実際に利用シーンや価値の体験をイメージしづらい「体験したことがない」ような新サービスは特に、MVPを使ったリアリティに近い形で再度、検証し直すことが必要になります。
2：理想とするサービスを明らかにする
ミニマムを決めるためには「完全」「全体」を一度俯瞰する必要があります。これまで積み上げてきたやや抽象的な、顧客に提供するサービス利用体験の流れにあわせて、フロントエンド/バックエンドの関連をサービスブループリントを描くことを通して、具体化していきます。
3：サービスを棚卸する
ブループリントで全体を俯瞰しながら、サービスのコアな提供価値と機能に向けて、削ぎ落していきます。ここで重要なのは棚卸する基準をあらかじめメンバー内で定義しておくことです。
一例としてサービスのアイデンティティとなる提供価値かどうか、これを理解して体験するための利用体験に直結するか否かという線引きを挙げましたが、汎用的な基準というものは存在せず、メンバーが納得/迷いなく判断できる閾値を言語化したうえで、サービスブループリントを使いながら、ミニマムな範囲を設定していく、ということになります。
4：制約事項や外的要因を考慮する
「ミニマム」度合いを決定する際には、製品の開発と市場投入にかかる時間やコストも考慮する必要があります。リソースが限られている場合、より簡素化された製品を開発し、市場への投入を早めることが最適解となることもあり得ます。その一方で、市場の競争が激しい場合や製品の複雑性が高い場合には、より洗練された「ミニマム」製品が必要になる場合があります。
どの型を採用するかには必然性がある
こうしたプロセスを経てミニマムな形となった製品/サービスを踏まえて、先に挙げた4つの分類を見直してみると、また違った解釈ができるのではないかと思います。
インタラクティブ型
サービスの提供価値が主にフロントエンド体験できるサービスで、検証したい仮説もその体験によって検証できる場合に採用したい方法です。
コンシェルジュ型
MVPの事例として代表的なのが、バックエンドはマンパワーで回し切る形です。これは物販やパーソナライズサービスなど、一人一人に合わせた対応を行うことで完結する提供価値を持つ場合に用いられます。ただし、注意すべき点はユーザが価値を得るまでの「タイムラグ」。1日後が当たり前なのか、すぐさま価値が得られないといけないものなのかによって、人力で許されるのか、MVPとはいえど自動化が必要なのかは大きく異なります。
プロトタイプ型
サービスの提供価値の範囲が比較的狭く、かつ即時性が求められる場合や、自身やチームにアジャイル開発が可能なケイパビリティがある場合（創業者自身がプログラマだったTwitterは良い例)などは「作ってしまったほうが早くて、確実」です。
完全体験型
これは少しイレギュラーなケースかもしれません。ほぼ本製品/サービスに近いβ版に近いものを作り上げたうえで、提供地域等の範囲をミニマムにして検証を行うケースです。例として挙げたUBERの高級車サービスや後期のAirbnbが行ったサンフランシスコに限定したサービス提供で、顧客のリアルな反応を見たうえで、ケイパビリティやリソースを持つ企業が、本格投資を行うか否かを判断するような場合に限られるかもしれません。
さいごに
いかがでしたでしょうか？
より実際のプロジェクト現場に近い目線から、現実的・実践的なMVP作りに必要な「ミニマム」加減の設定方法について、MVP定義から主要型、削ぎ落しのプロセスをご説明してきました。
多種多様な新商品やサービスがあるなかで、絶対的な判断基準は存在しえないのが現実ですが、それでも右往左往しない定石的な進め方はあるように思います。
新規事業を進めたい企業や担当者にとって、常にこころがけたいのは「いかに素早く、しかしリアリティのあるサービス体験」を実際の顧客に問うて、素早く学んで改善するかということです。仮説は仮説、顧客に実際に問うてみないことにはわからないものです。
今回の内容が、皆さまのプロジェクトを少しでも前進させ、顧客との距離が少しでも縮められることに役立つことがあれば幸いです。
この記事が気に入ったらサポートをしてみませんか？