先日、とあるスタートアップ界隈の方とお話している中で出てきたキーワード「MVP(Minimum Viable Product)」。
言葉は聞いたことがあって、記事もさらっと目を通した気がするけど、ちゃんと理解できていない…
ということで、改めて、「MVP(Minimum Viable Product)」について、まとめてみたいと思います。
目次
MVPとは
そもそもMVPという言葉は書籍「リーン・スタートアップ」において登場した言葉であり、その書籍の日本語訳としては、「実用最小限の製品」と表現されました。
本家エリック・リースの解説は以下の通りです。
“The MVP is that version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time”
「MVPとは、（Build-Measure-Learnの）フィードバック・ループ１周を回せる『必要最低限の労力』＋『最低限の実装時間』バージョンの製品」（筆者訳）
そう言われても、なかなか理解に苦しみますよね…
分かりやすく説明されている記事がありましたので、引用させていただきます。
１つめは、イノベーションを起こす最初の製品・サービスは、最初に使いはじめるユーザがすぐに理解できるような単純な製品であるということ
２つめは、フィードバック・ループを回すための実験手段として、MVPは製品としてではなく学習を得るための手段だと考えるということです。
１は、イノベーションを起こすような新製品・サービスはアーリーアダプターのニーズだけを汲み取ることに専念すべきで、マスマーケットの多様化されたニーズに対応する製品・サービス設計をしてはいけないということを説明しました。アーリーアダプターが製品・サービスを手にした時に、ほんの数秒でバリューと使い方が分かるような状態でなければ、決してユーザに受け入れられることはありません。これは、アントレプレナーの多くが犯してしまう、適切なソリューション案を見出しているにも関わらず、機能をそげ落とすという恐怖に撃ち勝てずにムダな機能を盛り込みすぎたために、マーケットからイノベーションが認知されないという、とても残念な結果を生み出します。失敗する新サービスの多くは「機能が足りない」ことよりも「機能が多すぎ」て、プロポジションが明確にならないことで消えていくのです。イノベーションは機能やソリューションによって認知されるのではなく、「単純明快なプロポジション」から生まれるのです。
２は、イノベーションの形成段階では、多くの場合、実験手段として作った製品・サービスと、正式なリリースバージョンの間には明確な境界線が存在しないことを意味しています。既存のマーケットに対して新製品を投入し、確実に予測された期間で投資額を回収するという「プロジェクト」とは異なり、イノベーションを起こすために新規市場と新製品を同時に開発する段階においては、実験フェーズとローンチ・公開（販売）フェーズを分離することはまったく意味がありませんし不可能なことです。市場の存在、そして市場の拡張とともに成長するイノベーティブな製品にとって、実験と製品の区別をつけることはそもそもも困難です。例えば初期のグルーポンは機能の多くをシステム化せず、手作業で処理することによってビジネスモデルを検証しました。つまり、スタートアップ側からすれば製品・コードなしでビジネスモデルを実験したにも関わらず、マーケット側からは完全にサービスが存在しているという状態なのです。どこまでの機能を実装すれば「サービス」と呼べるのか、どこまでしか実装しなければ「実験」にとどまってしまうのかを問うこと自体、あまり意味がないのです。
引用:https://leanstartupjapan.co.jp/?p=530
この方は、記事の中で複合機を例に挙げて、MVPを紐解かれていましたが、非常に面白い視点でした。
その結果として、MVPを再定義されており、シンプルで分かりやすい表現でした。
再定義「MVPとは」
『”Problem/Solution Fit”を達成するために必要な、アーリーアダプターが利用する代替手段を超える最低限の価値提供成果物（または中間成果物）』
MVPの実践
MVPはどのように実践したら良いのでしょうか。
Eric Ries氏は「MVPを構築しようと考えているときには、調査したいことに直接結びつかない機能やプロセス、労力を取り除く、という原則に従いましょう。」と述べました。
言い変えれば、MVP戦略は、使用できる製品を提供することだけを追求します。エモーショナルデザインは、将来製品開発を反復するときに考えます。
MVPを構築する
バージョン1.0をリリース
製品開発は学習の邪魔
MVPの縮小化
継続的デプロイを始める
アクティベーションの流れを定義する
登録の障害は下げても学習の犠牲にしてはいけません。
手順を減らしても学習を犠牲にしてはいけません。
UVPを届けましょう。
うまくいかなかったときのことを考えておきましょう。
マーケティング用のサイトを構築する
マーケティング用のサイトの解剖
概要ページ
サービス利用規約とプライバシーポリシーページ
製品ツアーページ(動画やスクリーンショット)
ランディングページの分解
独自の価値提案
ビジュアルの支援
明確な誘導
もっと詳しく知るための情報
社会的証明
引用:https://k2works.github.io/blog/2014/04/18/runnig-lenan-startup/
MVP – テストアプローチ
Webサイトとアプリケーション
製品の需要をテストするもっとも簡単な方法の１つは、製品のWebサイトを作成し、アクセス状況を調査することです。Webサイトは完璧に機能しなくても、何が利用できるかを説明し、詳細な情報を提供するために顧客にクリックをうながすモックアップで十分です。クリック数を訪問者数と比較して、製品への関心度を判断することができます。サービス
サービスを販売する際に、もっとも簡単にテストする方法は、サービスを提供する製品を構築することではなく、誰かにサービスを試してもらい、そのサービスに対していくら支払えるか計ってみることです。この方法であれば、払える額が正確にわかるまで繰り返しテストすることができます。新機能
既存の製品に新しい機能を加える前に、既存のWebサイトにその機能の広告を載せて、より多くの情報を提供するリンクを設置するべきかもしれません。リンク先では、新機能が現在開発中であることを説明します。リンクの訪問者数を調査することで、開発を始める前に、新機能のニーズを適切に理解することができます。「早期のリリース、頻繁なリリース」との違いは？
MVP戦略は、オープンソース戦略で使われる「早期のリリース、頻繁なリリース」と比較されることがあります。どちらの戦略も、クライアントからのフィードバックを把握して開発を反復する点は同じです。しかし、MVP戦略は消費者と対峙し、取った戦略が正しいか検証するという明確な目的があります。一方でオープンソース戦略は、消費者自身が次の戦略を決めるなど、消費者に大きく依存する点でMVP戦略とは異なります。両方とも製品を開発するための優れた手法ですが、MVP戦略は、すべての機能を実装する製品に向けて、より素早く簡潔にアプローチできます。
まとめ
新規事業やスタートアップ企業において、じっくり計画して、お金も時間もかけて創ったプロダクトを外してしまった場合、再起不能の事態に陥るリスクがあります。
リスクを低減し、必要最小限のプロダクトを提供し、マーケットや顧客に受け入れられるかを実験することが現代において、より重要なんだと思います。
