MVPがWebサービス開発では必要な理由とその方法
This page is only available in Japanese.
「MVP」という言葉を聞いたことがありますか？
事業を新しく始める際に、MVPを作ることが重要だと言われています。
この記事では、MVPの説明や作り方、気を付けたいミスについて解説します。
MVPとは「実用最小限の製品」
「MVP」とは、「Minimum Viable Product」の略で、日本語では「実用最小限の製品」を意味します。
アメリカの起業家フランク・ロビンソン(Frank Robinson)が2001年に提唱しました。
MVPは顧客を満足させ、将来の開発に役立つフィードバックを得るための最小限の機能を持った製品です。
ここでのポイントは「実用最小限」です。
つまり、顧客が必要とする最小限の機能を備えることが重要です。
機能が多すぎても少なすぎてもいけません。
MVPとは「実用最小限の製品」です。
それでは、なぜ、最小限の機能のみを持った製品を作るのでしょうか。
MVPのメリットとデメリットについて見ていきます。
MVPのメリットとデメリット
MVPを作ることには、以下のメリットとデメリットがあります。
MVPのメリットはこの3つ。
- 仮説を検証できる
- PDCAサイクルを早く回せる
- 開発の予算・スケジュールが抑えられる
一方でMVPのデメリットはこの3つです。
- コピーされてしまうリスクがある
- 顧客の期待に応えられない
- ハードウェアや物理的な製品には適用しにくい
それぞれ具体的にご説明します。
メリット
MVPには3つのメリットがあります。
- 仮説を検証できる
- PDCAサイクルを早く回せる
- 開発の予算・スケジュールが抑えられる
順番に見ていきましょう。
1. 仮説を検証できる
事業を始めるのであれば何かしらの仮説を立てているはずです。
「◯◯に困っている人が日本に100万人いるはずだ」
「◯◯を解決するには◯◯が必要」
「競合Aの方法では不十分で顧客は満足していない」
こういった仮説をもとに事業計画を立てているのではないでしょうか。
どれだけ優秀な人でも、仮説はあくまでも仮説。
実際に試してみないと本当に正しいかどうかはわかりません。
MVPはその問題を解決するための最小限の機能を持った製品です。
実際に作って提供することで、仮説が正しいかどうかを検証できます。
「仮説の検証ならインタビューやアンケートで良いんじゃないの？」と思うかもしれません。
私も最初はそう思っていました。
しかし、残念ながらインタビューやアンケートでは本当の反応を知ることは難しいんです。
「あなたは◯◯があったら使いますか？」と聞かれると「使います」と答える人が多いですが、実際に使ってみたら使わないこともよくあります。
よくSNSで見かける「◯◯が欲しい人はいいねしてください。反応が多ければ作ってみます」という投稿があります。
たくさんのいいねがついたので、いざ作ってみても使ってくれる人が少なかったという話をよく聞きます。
そうならないように、実際に触って試してもらえるMVPを提供しましょう。
また、「最小限」というのがポイントになってきます。
複数の機能がある製品だと、果たしてどの機能が良い影響を与え、どの機能が悪い影響を与えているのかわかりません。
はたまた、複数の機能が互いに影響しあい相互作用を起こしているかもしれません。
これでは適切な仮説検証ができません。
顧客の問題を解決する最小限、できれば1つの機能だけに絞りましょう。
2. PDCAサイクルを早く回せる
1番目のメリットと関連しますが、顧客からのフィードバックをもらっただけで終わりにしてはいけません。
フィードバックをもとに改善を繰り返すことが重要です。
つまりPDCAサイクルを早く回すことが大切です。
MVPは最小限の機能を持った製品です。
そのため、ひとつの変更が与える影響範囲が限定されます。
機能が多いと、少しの変更であっても他の機能に影響を与えてしまうことがあります。
それが不具合を起こしてしまう原因になると容易に想像できます。
変更の影響が限られているため、顧客から得たフィードバックをすぐに反映させることができます。
そのためPDCAサイクルを早く回すことができるのです。
PDCAサイクルを回せば回すほど、良かった点を伸ばし、悪かった点を改善することができるようになります。
3. 開発の予算・スケジュールが抑えられる
ITに関する事業の予算の大部分は人件費です。
そのため作る機能が増えれば増えるほど、開発に必要なお金と時間が増えていきます。
詳しくは開発の予算とスケジュールについて解説した記事をご覧ください。
Web制作で予算とスケジュールがオーバーしてしまう理由とその解決策
言い換えれば、作る機能が少なければ、開発にかかる予算と時間も少なくて済むということ。
特に仮説の検証をして、想定した効果が得られなければ方向転換することもあります。
そう考えると、できるだけ投資金額は抑えたいですよね？
「1年後までに1,200万円をかけて新規事業を作る」という計画があるとします。
(単純化のために開発費が1ヶ月あたり100万円とします)
2つの進め方を考えてみましょう。
- 1年かけてあらゆる機能を盛り込んだ製品を1個作る
- 1ヶ月ごとに1つの機能を盛り込んだ製品を12個作る
どちらも1年間という期間で1,200万円の予算というのは変わりません。
あなたはどちらの進め方のほうが成功の可能性が高いと思いますか？
もちろん、2つ目の進め方のほうが成功の可能性が高いですよね。
1つ目の進め方だと、1年間の開発期間が終わるまで顧客の反応を見ることができません。
もし、最初に立てた仮説が間違っていた場合、1,200万円の投資が無駄になってしまいます。
一方で2つ目の進め方だと、1ヶ月ごとに顧客の反応を見ることができます。
仮説が間違っていても1ヶ月分の投資で済みます。
さらに、もし1ヶ月目の製品で成功した場合、2ヶ月目からはその製品に注力して改善を続けることができます。
起業や新規事業は野球の打席に例えられます。
バッターボックスに立つチャンスが多ければその分ヒットやホームランを打つ回数が増えます。
あのイチローでも最も高い打率は3割7分。
つまり、3回に1回しかヒットを打てないということです。
1年で1回しか打席に立てない進め方と、1年で12回打席に立てる進め方。
どちらが成功の可能性が高いか。
もちろん回数が多いほうですね。
ここまでMVPを作るメリットをお伝えしてきましたが、MVPも万能ではありません。
デメリットも見てきましょう。
デメリット
MVPは仮説検証ができPDCAサイクルを早く回すことができる反面、以下のデメリットがあります。
- コピーされてしまうリスクがある
- 顧客の期待に応えられない
- ハードウェアや物理的な製品には適用しにくい
1. コピーされてしまうリスクがある
MVPは顧客の反応を見るために早い段階から市場に投入する製品です。
そのためもし競合他社があなたの製品をコピーしてしまった場合、市場でのシェアを奪われるリスクがあります。
MVPのポイントは最小限の機能を作ること。
裏を返せば、コピーもしやすくなってしまっています。
コピーされないようにするには参入障壁を高くすることが重要です。
参集障壁を高くする方法はこのようなものがあります。
- あなたしかできない技術を使う
- あなたしか持っていないデータを使う
- あなたしかリーチできない顧客をターゲットにする
共通するのは「あなたしか」です。
他社が真似したくても真似できないものを作ることが大切です。
実はコピーされるリスクはMVPだけに限らず、どのような業界・製品でも存在します。
例えばTikTokが流行ったことにより、Instagramはストーリーズ、YouTubeもショート動画機能を導入しました。
技術的には難しくないため真似されやすいのです。
あなたにしかできないアイディア・技術で差別化を図りましょう。
2. 顧客の期待に応えられない
MVPは最小限の機能を持った製品です。
仮説をもとに作っているはずです。
しかし、その見当が外れてしまった場合、顧客の期待に応えられない可能性があります。
顧客は別の機能を求めていたり、多機能の製品を欲しているかもしれません。
そのような顧客の期待を裏切ってしまうことになります。
そしてその裏切りがあなたのブランドを傷付けてしまうかもしれません。
大きい企業やインフルエンサーと呼ばれるようなブランディングが大切な場合には、MVPであっても慎重に進める必要があります。
一度の失敗で失うものが大きいためです。
一方で良くも悪くもブランドがないスタートアップや個人事業主の場合、失敗を恐れずチャレンジすることができます。
顧客の期待に応えられないのは残念なことですが、そのフィードバックをもとに改善、新たな事業開発に繋げられます。
3. ハードウェアや物理的な製品には適用しにくい
MVPは改善のサイクルを早く回せることがメリットです。
そのためハードウェアや物理的な製品には適用しにくい方法です。
例えばWebサービスはプログラマーやデザイナーの修正がすぐに反映されます。
一方でリアルな店舗の場合には、変更に時間とお金がかかります。
ブログはパソコンさえあればすぐに追記・修正ができますが、紙の本はそうはいきません。
あなたが考えている事業が変更に柔軟かどうかがMVPを適用するかどうかの判断材料になります。
もし、ハードウェアや物理的な製品で変更に時間とお金がかかる場合には少し工夫をしてみてください。
例えば実際の製品を作る前に広告や事前予約といった方法で顧客の反応を見ることができます。
クラウドファンディングがまさにそれを満たした方法と言えるのではないでしょうか。
MVPに適しているのは変更が柔軟な事業です。
その中でもWebサービス開発にはMVPを作るのが向いていて、むしろ必須とさえ言えます。
Webサービス開発でMVPが必要な理由
MVPを作ることがWebサービス開発において重要な理由は、この3つです。
- フィードバックを得やすい
- Webサービスは変更が容易
- 開発費用の大部分が人件費
1. フィードバックを得やすい
MVPを作るメリットでお伝えしたように、仮説を検証することがMVPの目的のひとつです。
つまり仮説を検証できなければMVPの意味がありません。
Webサービスは多数の行動解析ツールがあり、顧客がどこに注目し、どこで離脱するかを知ることができます。
常にオンラインで繋がっているWebサービスの強みです。
またこういった新規事業を使ってくださる顧客はSNSを活用していることが多く、SNSを通じたコミュニケーションが取りやすい傾向にあります。
近い距離でコミュニケーションを取ることで、良かったことや悪かったこと、様々なフィードバックを得ることができます。
2. Webサービスは変更が容易
顧客からのフィードバックをもとに改善を繰り返すことで、ブラッシュアップされよりよい製品を作ることができます。
Webサービスでは変更が即座に反映されます。
その変更を顧客がすぐに使うことができるため、PDCAサイクルの回転がとても早くなります。
私も自社サービスを作っているときにTwitter(現X)でのやりとりから、機能のアップデートを1時間以内に行った経験があります。
それほどのスピード感だと、驚きと共にファンになってくれる方も多いです。
ここで注意しなければいけないのが、ネイティブアプリ(iOSやAndroidにインストールするアプリ)は変更がすぐに反映されません。
変更した内容をそれぞれのAppストアに載せるために、AppleとGoogleの審査を通過する必要があるためです。
ちょっとした変更でも、数日、長い場合には数週間待たなければいけないケースがあります。
Webブラウザで使うWebサービスであれば、完全にこちらがコントロールできます。
3. 開発費用の大部分が人件費
Webサービスの開発にかかる費用の大部分がエンジニアとデザイナーの人件費です。
その人件費は開発期間に比例します。
そして開発期間が長くなる原因のひとつが、機能が多く、複雑になること。
つまり、作る機能を絞り、シンプルな製品を作ることで開発期間を短縮できるんです。
開発期間を短縮できることで人件費を抑えられるので、開発費全体も圧縮できます。
新規事業にかける予算が決まっているのであれば、少ない開発費で何度もチャレンジしたほうが成功する可能性が高くなります。
先ほどご紹介したように、何回打席に立ったかがポイントです。
MVPを作るときにありがちなミス
MVPを作るときによく見られるミスは「最小限の製品を作ってしまうこと」です。
MVPの定義と何が違うかわかりましたか？
MVPとは「実用最小限の製品」 です。
つまり「実用的かどうか」が重要なのです。
その製品を使ってもらわなければ意味がありません。
使えないものを提供するのであればMVPではなく、画像や動画を作って説明するだけで十分。
実際に使ってもらって問題を解決できたかどうかを検証できなければMVPとは言えません。
「百聞は一見にしかず」ということで、わかりやすい例をあげます。
顧客は「歩くよりも速く移動したい」という課題を抱えているとします。
下の画像を見てください。
上の「Not like this …」のほうはMVPではありません。
なぜなら、1番目から3番目までで提供しているモノでは移動という課題を解決できていません。
4番目でやっと課題を解決できています。
一方で下の「Like this!」のほうはMVPです。
1番目のスケートボードの時点で速く移動したいという課題に対して解決策を提供しています。
もちろん、スケートボードではスピードや乗り心地などに問題があるかもしれません。
しかし「歩くよりも速く移動したい」という課題を解決するための最小限の製品を提供していますね。
スピードや乗り心地といったフィードバックを得られたら、改善をしていけば良いのです。
その結果が2番目以降で、どのステップにおいても課題を解決する方法を提供しています。
それでは実際にどのようにMVPを作るのか、その方法についてご説明します。
MVPを作る方法
MVPを作りつつ事業開発を進めるのはこの流れです。
- 仮説を立てる
- コアになる機能を定義する
- プロトタイプを作る
- フィードバックを集める
- 改善を繰り返す
このように並べると簡単そうに見えますよね？
しかし実際にやってみると意外と難しいもの。
特に2番目の「コアになる機能を定義する」で、なかなか絞りきれずに、あれもこれもと機能を追加してしまうことがあります。
心を鬼にして、この製品が成り立つために必要な最小限の機能に絞りましょう。
この流れをわかりやすくするために具体例をあげてご説明します。
MVP作りの進め方の例
MVPをどのように作るのか、具体的な例で見ていきます。
イメージしやすくするために、現在は普通に使われているWebサービスを模しています。
20年前の気持ちになって考えてみてくださいね。
A. 短い文を投稿できるSNS
ひとつめの例は「短い文を投稿できるSNS」です。
この時点で、何か思い当たるものがあるのではないでしょうか。
なお20年前のインターネットをイメージしてくださいね。
仮説：ブログは長すぎる。短い文で気軽に投稿できるSNSが欲しい
20年ほど前はインターネット上の情報はブログや個人のWebサイトが主流でした。
何かを伝えたいと思ったときにはガッツリとした文量を書くのが普通。
そうなると筆が重くなってしまいます。
もっと気軽に書ける、文字数制限があるSNSがあればコミュニケーションが活発になるのでは？
という仮説を立ててみました。
コアになる機能：最大140文字の短い文を投稿できるSNS
仮説を検証するために必要な機能は「短い文を投稿する」ということ。
長い文ではないし、画像の投稿でもありません。
確かめる必要があるのは「短い文」。それだけです。
SNSに投稿できる最大文字数を140文字に設定してみます。
これまで数千文字も書けるブログと比べて、圧倒的に短い文字数です。
英語であれば、2-3文程度の長さです。
「最大140文字の短い文を投稿できるSNS」というコアになる機能を定義し、これを作り提供していくことにします。
Twitter(現X)もMVPからスタート
ここまで書けばすでにおわかりかと思います。
この例はTwitter(現X)のMVPを模しています。
実際に2006年の一番最初のTwitterでは最大文字数が140文字で、画像は投稿できませんでした。
またリプライやリツイート(現リポスト)、いいね(FavoriteやLike)の機能はありません。
現在のフォローにあたる友達になる機能はあったようです。
これはSNSの「Social」の部分のために必要だったのでしょう。
この画像は2006年にリリースされたときのTwitterの画面です。
デザインの良し悪しはさておき、短文しか投稿できないということをわかっていただけるのではないでしょうか。
Twitter創業の話をもっと詳しく知りたい方は、創業者のひとりビズ・ストーン(Biz Stone)が書いた『ツイッターで学んだいちばん大切なこと――共同創業者の「つぶやき」』という本がおすすめです。
ちなみにビズ・ストーンはTwitterを離れてから、同じくTwitter創業者のひとりエヴァン・ウィリアムズ(Evan Williams)と共にブログサービス「Medium」を立ち上げています。
B. オンラインで買える本屋
続いての例は書店です。
本を買うには街の書店に行くしか方法がありません。(20年前の話です)
仮説：オンラインで本を買う新しい生活様式
本は生鮮食品や衣服と違い、どこで買っても同じものが手に入ります。
品質や鮮度を確認する必要はありません。
そうであれば、オンラインで買える本屋があってもいいのでは？
コアになる機能：Webサイトから本を注文できる
インターネット上に本屋を開き、注文が入ったら配送するというサービスを提供してみることにします。
このMVPで確認したいのは「人は本をオンラインで買うか？」ということ。
そのため本を買う機能以外は必要ありません。
おすすめの本を表示する機能やレビューを書く機能、本以外の商品を販売する機能はこの時点では実装しません。
Amazonの最初の商品は本のみ
ご想像の通り、これはAmazonの話です。
今やAmazonに置いていないものはないと言っても過言ではないほどの巨大企業ですが、最初の商品は本だけでした。
Amazonも一番最初に「オンラインで本を買う人はいるのか」という仮説検証からスタートしました。
人はオンラインで本を買うということを実証できたため、少量多品種の商品を扱い、街の本屋以上の品揃えを提供するというAmazonの特色が生まれました。
まとめ
「MVP」とは、「Minimum Viable Product」の略で、日本語では「実用最小限の製品」という意味です。
新規事業がWebサービスであるなら以下の理由からMVPを作るべきです。
- フィードバックを得やすい
- Webサービスは変更が容易
- 開発費用の大部分が人件費
実用的な最小限の製品を作ることが重要で、そこからフィードバックを得て改善を繰り返すことが成功の秘訣です。
具体的には以下の流れで進めます。
- 仮説を立てる
- コアになる機能を定義する
- プロトタイプを作る
- フィードバックを集める
- 改善を繰り返す
弊社ではWebサービスのMVP開発に特化したサービスを提供しています。
ぜひお気軽にご相談ください。
