MVP開発とは？プロセスやアジャイル開発との違いを徹底解説

最近日本でもよく聞くようになったMVP開発という言葉。

言葉はよく聞くけど、そもそもMVPという言葉を知らない方やMVP開発を取り入れるメリットが分からない方向けに、MVPの意味やメリット、他の開発手法との違いについて解説していきます。

本記事でご紹介している「MVP開発」の実施をご検討されている方へ、弊社代表が無料で30分のスポットコンサルをさせていただきます。ご不明点をお気軽にご相談いただけますので、下記お問い合わせフォームよりご連絡くださいませ。

MVP開発の定義

MVP開発のMVPとは「Minimum Viable Product」の略で、必要最小限の機能を持ったプロダクトという意味です。

つまり、MVP開発とは、ユーザーが実際に使うことができる必要最小限の機能を持ったプロダクト（＝MVP）を開発することを指します。

リーンスタートアップとの関連性

MVP開発は、リーンスタートアップを進めていくための重要なプロセスの1つと言われています。

リーンスタートアップとは、可能な限り無駄を省いた新規事業を立ち上げるためのマネジメント手法のことを言います。

低コスト・短期間で最低限の機能を持った試作品を作り、実際にユーザーに使用してもらったフィードバックを基にプロダクトの改善を繰り返していきます。

何度も繰り返し提供・改善を繰り返していくことで、ユーザーが求めている価値に近づけていくことが可能です。

「最低限の機能を持った試作品を作ること」がMVP開発ですので、リーンスタートアップを進めていくうえでMVP開発は重要なプロセスなのです。

リーンスタートアップでは、仮説を立てた後に、構築・計測・学習の3つプロセスを進めていきます。それぞれのプロセスとMVPは以下のように関係しています。

構築	ターゲットを言語化して、MVPを作る。求められる機能が過不足ないように搭載する。
計測	MVPを顧客に使ってもらい、反応を計測する。
学習	計測で得たデータを元に、プロダクトを改善していく。

このようにMVP開発は、リーンスタートアップと非常に相性の良い開発手法といえるでしょう。

ウォーターフォール開発との違い

MVP開発とは、リーンスタートアップのプロセスの1つです。

一方、ウォーターフォール開発は、システムを開発するための手法の1つです。

MVP開発とウォーターフォール開発は似たような言葉ですが、全く異なるものと認識する必要があります。

ウォーターフォール開発の具体的な開発手順としては、搭載する機能や細かい仕様を全て決めてから開発がスタートします。

開発の流れは、言葉が示す通り滝のように上から下へ、つまり上流工程から下流工程へと順番に開発が進められていきます。

滝の水が上に戻らないのと同じように、基本的には前の工程に戻らないで進めていくことが特徴です。

ウォーターフォール開発のメリットは、事前に決めた仕様通りに開発を進めていくため、途中で方向性がぶれることなく仕様に沿った成果物を作れることが挙げられます。

デメリットとしては、事前に決めた仕様から変更があった場合の手戻りに対応しにくいことが挙げられます。

アジャイル開発との違い

アジャイル開発もシステムを開発するための手法の1つで、ウォーターフォール開発と同様、MVP開発と似たような言葉ですが全く異なるものです。

アジャイル開発とは、開発を素早く機敏に実行していくために、小さな機能単位で実装・テストを繰り返し行っていく開発手法のことを言います。

機能ごとに短い開発工程を繰り返すことで一つ一つの機能を開発していくため、MVP開発とアジャイル開発は非常に相性の良い関係性にあると言えます。

PoCとの違い

PoCとは、Proof of Conceptの略で「概念実証」のことです。新しいアイディアやコンセプトを実行する前に、実現の可能性を検証する「検証プロセス」を指します。PoCでは、実際に試作品の制作や実装を用いた検証を行うため、精度の高い判断ができるのです。

MVP開発とやや混同されやすい概念ですが、簡単には以下のような違いがあります。

• MVP開発の目的は、ユーザーの反応を得ること
• PoCの目的は、実現可能性を検証すること

このように、開発目的や用途が異なるといえます。

MVP開発のメリットとは？

MVP開発を取り入れるメリットとしては、以下の4つが挙げられます。

開発コスト・時間ロスの抑制

MVP開発では、ユーザーが実際に使うことができる必要最小限の機能を持ったプロダクトを開発するため開発コストを抑えることができます。

また、ユーザーの反応を確認しながら開発ができるので、プロダクトの方向性を見誤っていたとしても柔軟に方向修正ができるため手直し等の時間ロスの抑制にも繋がります。

顧客ニーズを知ることができる

MVP開発は、ユーザーの反応を確認しながら開発ができるので、社内でニーズがあると想定している機能がユーザーにとって本当に求められているか検証できます。

もしかすると、想定しているニーズはさほどなく、想定していなかった機能に本当のニーズがあることが判明するかもしれません。

その場合、MVP開発であればすぐに方向修正して、本当のニーズがある機能を搭載したプロダクトを開発・提供できます。

失敗のリスクを最小限にできる

MVP開発は、プロダクト開発の失敗のリスクを最小限にすることができます。

ここで言うプロダクト開発の失敗とは、完成したプロダクトがユーザーのニーズにマッチしておらず再開発が必要になることを指します。

MVP開発を取り入れることで、実際の顧客ニーズを基に開発を進めることができるので、ニーズにマッチしないという状態を避けることができます。

先行者利益を得ることができる

MVP開発は先行者利益を獲得しやすい開発手法とも言えます。

上記の「失敗のリスクが小さい」に付随しますが、低コスト・短期間での検証ができることで、新規市場への挑戦を積極的に行うことができます。

もし新規市場にライバルがいない場合は、その市場での先行者利益を獲得することができます。

MVP開発のデメリットとは？

MVP開発を取り入れるデメリットとしては、以下の2つが挙げられます。

• 大規模・複雑なプロダクトには向かない
• エンジニアのスキルによっては開発が難しい

大規模・複雑なプロダクトには向かない

MVP開発は必要最低限の機能を短期間かつ低コストで作るものであるため、大規模でリリースまでに時間がかかるものには不向きです。

複雑な機能を検証して大きな修正が生じてしまうと、多大なコストや時間がかかり、MVP開発のメリットが削がれてしまいます。

MVP開発において「いかに早くできるか」は重要なポイントです。明確な目安はありませんが、MVP開発であれば開発期間はおよそ1週間から1ヶ月程度が望ましいという見解もあります。したがって、大規模・複雑なプロジェクトには向きません。

エンジニアのスキルによっては開発が難しい

MVP開発は「最小限のプロダクトを早く開発できる」メリットがありますが、そのためには短期間でPDCAを回さなければなりません。

プロジェクトにおけるタスクも多く、エンジニアのスキルによってはマネジメントが難しくなる可能性もあります。このように担当エンジニアにより進捗や成否が左右されやすい点はデメリットといえるでしょう。

MVP開発の種類

MVP開発の種類には主に以下の5つがあります。

それぞれメリット・デメリットがありますので、状況に応じて使い分ける必要性があります。

プロトタイプ

試験やデモ用に制作された実験機（プロトタイプ）を用いたMVP手法です。

必要最低限の機能を持った、実際に動くプロダクトを用いて検証を行うため、実際のプロダクトに近いユーザー検証を行うことができます。

ただし、他の手法と比べ開発コストが大きくなることが懸念点として挙げられます。

スモークテスト

ユーザーがサービスに興味・関心を持ってくれるか”のみ”を調べる手法です。

スモークテストは更にサービス紹介ビデオとプレオーダーの2種類に分かれます。

実際にプロダクト開発をせずに、ユーザーの興味・関心のみを調査できる手法になります。

コンシェルジュ

コンシェルジュは、ターゲットユーザーへの聞き込みやサービスの提供等あらゆるものをマニュアルで行う手法のことを指します。

全てをマニュアルで行うが故にコストがかかりますが、ユーザーの本当のニーズを得ることができる手法と言えます。

オズの魔法使い

映画「オズの魔法使い」には、どんな願い事も叶えてくれると言われる大魔法使いが実はただの中年の男だったという場面があります。

このように見た目はしっかり見せているものの、その中身は実は違うというところから名付けられたMVP手法です。

ECサイトを例とすると、Webサイトの商品ページ（ユーザー側が見る画面など）は作成を行うが、注文後の処理（梱包や配送の手配など）はシステム化せずに人力で行うといった手法のことを言います。

注文後の処理以降のシステムを開発する必要がないので、開発にかかるコストを抑えることができます。

ランディングページ

サービスの紹介や、そのサービスによってどのようなメリットがあるかを記載したランディングページを作り、更に事前登録フォームを付けることでユーザーニーズを検証する手法です。

大規模なシステムやプロトタイプを作成せずとも、ユーザーニーズがどれくらいあるかを確認することができます。

モックアップ

もともとモックアップは「模型」を意味する言葉で、製品の外観のみを作る手法です。そのため、ユーザーからは製品の完成形のように見えますが、内部の仕組みやデータの面では簡略化されています。

デザインのイメージ共有やトンマナ確認のためだけに使われる場合もあれば、IA（情報アーキテクチャ）設計まで確認する場合まであります。

MVP開発のプロセス・進め方

MVP開発を進めるにあたって、MVPキャンバスを使うとより質の高いMVPを作成することができます。

MVPキャンバスは、MVPを作るにあたり、無駄をなくすために重要なことを整理するフレームワークでAppSociallyの高橋氏とRecruit MTLが共同で開発した思考プロセスのことです。

最小限の製品と思っていても、ついあれもこれもあった方がいいだろうと考えてしまいがちです。

重要なことが何かを可視化し、また複数メンバーで進める場合にも意識を合わせ、ぶれずに整理する事ができます。

MVPキャンバスの活用方法・作り方

MVPキャンバスには以下の10の要素があり、順に1つずつ行なっていくことになります。

1. 仮説

最も優先度の高い仮説を記載します。

明確に優先順位を決めることで、着手すべき順序が明確になります。

2. 目的

良い結果に繋がって欲しいバイアスがかかってしまいやすいため、客観的に判断するために、仮説で定義した内容を検証する理由や目的を記載します。

3. 仮説の検証方法

MVPでどのように仮説を検証するのかの検証方法を具体的に記載します。

検証方法が1つと限らない場合もあります。

その場合は、方法ごとにMVPキャンバスを作成して精査します。

4. データや条件（KPI）

仮説検証に必要な条件やデータを定義します。

実際に実用化するときを仮定して具体的な条件や数字にします。

5. MVPの機能

MVPとして作る機能を定義します。

今まで定義した条件や目的を踏まえ、最低限必要な機能に絞って作ることが重要です。

6. MVP構築に必要なコスト

MVPの構築にどのくらいコストがかかるかを記載します。

金額だけでなく、必要な工数や人員を明らかにしましょう。

お金ではなく、リソースを提供してもらうことで解決できる場合もありますので、大きな金額をかけない方法を考えましょう。

7. 実証に必要な期間

具体的に検証する期間を決めます。

母数が少な過ぎても信頼性のあるデータにならないため、条件やKPIで設定したデータが充分に集まる期間を設定しましょう。

8. 回避できる/発生するリスク

現時点で発生するリスクを想定して、事前に回避方法があるリスクは検討して整理しておきましょう。

9. 検証結果

検証の結果で得られた内容を簡潔に記載します。

目的やデータ、条件と照らし合わせて検証したかった内容を明確に記載しましょう。

10. 得た学び

検証の結果からどのような学びが得られたか、それを活かし次はどのようなアクションをするかを検討します。

クリーヴァでは、これからMVP開発に取り組みたい方へMVPキャンバスのテンプレートを無料でダウンロード配布しています。

自社で実践している手法

クリーヴァでは普段から、”言われた機能をただ作る”ではないシステム開発を実践しています。

システムを作りたい人が求めている、事業の成功や改善などをシステムで実現することがクリーヴァの価値になると考えているからです。

そのためにも、開発に入る前に「ユーザーストーリー」と「プロダクトバックログ」を作ることを特に重要視しています。

ユーザーストーリーとは、プロダクト内において「誰が・どのような理由で・何をしたいのか」を簡潔に表したものです。

具体的には、「システム管理者が・情報の掲載が不要になったので・情報を削除できる」、「ユーザーが・新しい情報を得るために・掲載を新着順に並び替えられる」などが挙げられます。

ユーザーストーリーを作ることで、ユーザーが本当に求めているものは何なのか？を突き詰めていくことができます。

プロダクトバックログとは、作成したユーザーストーリーの中で搭載すべき機能を決めて優先順位をつけることで作ることができます。

スプリントで対応が必要な機能、次回のスプリントで対応が必要な機能といったことを明確にできるだけでなく、依頼者がプロダクトの状況を把握することにも使うことができます。

「ユーザーストーリー」と「プロダクトバックログ」をしっかり作成することで、システムを使う方が本当に求めるものを見極めることができ、事業の成功に向けてより良いMVP開発を行うことができます。

MVP開発のポイント

MVP開発を取り入れる上でのポイントは、「なんのために？」「本当に必要か？」を常に考えることです。

検証することだけに集中する

そのまま事業で使えるように、「このように設計しておこう」「この機能もあった方がいい」と考えてしまうものですが、広げることは時間やお金をさらに使うことに直結します。

製品版はMVPを改修して使用するより、MVPを最小限にして作り直す方が効率的な事も多いです。

MVPでは機能を削ぎ落し、検証を早く行うことに集中します。

作る事を目的化しない

システム化してデザインの整ったページが出来るとそれだけで事業として成立しているように錯覚してしまいがちです。

形を作る事を目的にしないようにすることが大切です。

例えば、一番の確認すべき点が検証出来るなら無料のフォームで申し込みでメールでやり取りすることでも始められるのです。

注意点

MVP開発における注意点としては以下2つになります。

開発に何ヶ月もかかるプロダクトには適さない

開発期間の長い製品はMVP開発には適していません。

MVP開発は低コスト・短期間で検証と改善を繰り返すので、長くとも3ヶ月程で開発ができるプロダクトでないと、そのメリットが活かせないため注意が必要です。

開発に時間を要するプロダクトの場合は、MVP開発ではなく別の開発手法を採用するべきです。

ユーザーの意見に耳を傾けすぎない

ユーザーの意見に耳を傾けすぎることにも注意が必要です。

MVP開発においてユーザーからの意見は必須要素ですが、開発の目的はあくまでプロダクトで課題や問題を解決することだからです。

ユーザーの意見を取り入れすぎると本来必要でない機能も入ってしまう可能性があるため、よく吟味する必要があります。

開発会社を使った方が良い理由

昨今のITエンジニア不足の状況下において、MVP開発に精通したエンジニアを探す時間とコストを鑑みると、MVP開発に精通した開発会社に依頼した方が比較的安価に開発を進めることができるかもしれません。

本記事でご紹介している「MVP開発」の実施をご検討されている方へ、弊社代表が無料で30分のスポットコンサルをさせていただきます。ご不明点をお気軽にご相談いただけますので、下記お問い合わせフォームよりご連絡くださいませ。