プロトタイプとMVP・モックの違いを整理｜新規事業の使い分け

この記事では、プロトタイプ・MVP・モック（モックアップ）の違いを、「何を確かめるために作るのか」という視点で整理します。3つは似た場面で使われますが、目的も、見せる相手も、作る範囲も異なります。新規事業でどの順に、どう使い分けるとよいかまで分かります。

3つの言葉は「確かめたいこと」が違う

新規事業のシステム開発を考え始めると、「まずモックを作ろう」「いや、MVPで出してみよう」「プロトタイプで見せたほうが早い」と、似た言葉が混ざって出てきます。社内の会話や開発会社との打ち合わせで、同じ言葉を違う意味で使っていて話が噛み合わない、ということも珍しくありません。

違いを一言で言えば、次のとおりです。

• モック：見た目と画面の流れを確かめるためのもの
• プロトタイプ：仕組みや使い勝手、実現できるかを確かめるための試作品
• MVP：顧客が価値を感じるかを確かめるための、最小限の製品

なお、これらの言葉の定義は、会社や業界、チームによって幅があります。たとえば「プロトタイプ」を広い意味で使い、モックやMVPまで含めて呼ぶ場面もあります。この記事では、使い分けを考えやすいように、上のように整理して説明します。大切なのは言葉の正解を覚えることではなく、プロジェクトの最初に「私たちはこの言葉を、この意味で使う」とそろえておくことです。

モック・プロトタイプ・MVPそれぞれの意味

モック（モックアップ）とは

モックは、完成品の見た目を再現した見本です。システム開発では、画面のデザインや、画面から画面へ移る流れを示すために作ります。ボタンを押すと次の画面に切り替わる程度の動きはあっても、裏側のデータ処理や計算は動かないのが一般的です。

モックの良さは、短い時間で全体の見た目を共有できることです。「この画面にこの情報を載せる」「この順番で操作する」といったイメージを、文章よりもはるかに具体的に伝えられます。一方で、モックから分かるのは「見た目」までです。本当に使いやすいか、データを入れたときにどう動くか、技術的に実現できるかは、モックでは確かめられません。

プロトタイプとは

プロトタイプは、本番の製品に近い形で、主要な部分を実際に動かしてみる試作品です。ここで重要なのは「動く」という点です。入力したデータが処理され、結果が返ってくるところまでを実際に体験できるものを指すことが多くあります。

プロトタイプで確かめたいことは、たとえば次のようなものです。

• 想定した業務や体験の流れが、実際に操作してみて自然か
• 中核となる機能が、技術的に実現できるか
• 関係者が触ってみて、「これじゃない」と感じる点はどこか

作る範囲は、すべての機能ではありません。確かめたい中核部分に絞るのが基本です。また、プロトタイプはあくまで検証のための試作品です。そのまま本番の製品として公開することを前提にしない場合も多くあります。

MVPとは

MVPは「Minimum Viable Product（実用最小限の製品）」の略です。「リーン・スタートアップ」という考え方を紹介したエリック・リース氏の著書などで広く知られるようになった言葉で、顧客に価値を届けられる最小限の機能を備えた製品を、早く市場に出して反応を見る、という使い方をします。

プロトタイプとの大きな違いは、見せる相手と目的です。プロトタイプが主に社内の関係者や限られた利用者に見せて「作れるか・使えるか」を確かめるのに対し、MVPは実際の顧客に使ってもらい、「本当に求められているか、使い続けてもらえるか」を確かめます。顧客が実際に使うため、機能は最小限であっても、動作の安定性やデータの扱いには、本番の製品としての責任が伴います。

「最小限」という言葉から、「粗くてもよい」と受け取られることがあります。しかし実際には、「検証したい価値を届けるために必要な機能に絞る」という意味であり、品質を落としてよいという意味ではありません。

並べて比べると何が違うのか

3つを同じ軸で並べると、次のようになります。

	モック	プロトタイプ	MVP
主な目的	見た目・画面の流れの確認	仕組み・使い勝手・実現性の確認	顧客が価値を感じるかの確認
動き	動かない、または画面遷移のみ	主要な機能が実際に動く	実際に使え、顧客に提供できる
主に見せる相手	社内・制作関係者	決裁者・現場・限られた利用者	実際の顧客・ユーザー
作る範囲	画面	検証したい中核部分	価値を届けるのに必要な最小限の機能一式
主な問い	この見た目・流れでよいか	本当に動くか、使えるか	求められているか、使い続けられるか

この表から分かるように、3つは「どれが優れているか」を比べるものではありません。確かめたいことが違うので、それぞれに向く場面があります。

もうひとつの見方として、「失敗したときの学びの種類」で考えることもできます。モックで外れたときは、見せ方の問題が分かります。プロトタイプで外れたときは、仕組みや業務の流れ、技術面の問題が分かります。MVPで外れたときは、市場や顧客の求めるものと、事業の仮説とのズレが分かります。どの段階の失敗を、どれだけ小さなコストで経験したいかによって、選ぶものが変わります。

新規事業ではどう使い分けるか

一番不確かなことは何かを先に決める

新規事業では、不確かなことが同時にいくつもあります。顧客は本当にこれを求めているのか。システムとして作れるのか。社内の決裁者に価値が伝わるのか。すべてを一度に確かめようとすると、どれも中途半端になりがちです。

そこで、今の段階で一番不確かなことは何かを先に決めて、それを確かめるのに最も小さな形を選びます。

• 画面のイメージや情報の見せ方がまだ曖昧：モックが向いています。
• 「何ができるのか」を、決裁者や現場に伝えきれていない：プロトタイプが向いています。
• 技術的に実現できるか、使い勝手が成り立つか不安：プロトタイプが向いています。
• 顧客が本当に使い続けてくれるかが最大の不安：MVPが向いています。

必ずしも、モック、プロトタイプ、MVPの順に進めるとは限りません。たとえば画面イメージがすでにはっきりしているなら、モックを飛ばしてプロトタイプから始めてもよいでしょう。

決裁・社内合意の場面ではプロトタイプが効きやすい

新規事業の立ち上げでは、企画書だけで決裁を得るのが難しい場面があります。企画書は、文章と図で「こういう事業になる」と説明するものです。しかし、システムが事業の中心になる場合、読む人によって思い浮かべるものが違い、「結局、何ができるのか」が伝わりにくくなります。この点は、新規事業の決裁を企画書だけで取るのが難しい理由でも詳しく整理しています。

また、経営陣と現場は同じ目的を見ているのに、判断の材料と進める速度が違うために話が噛み合わないことがあります。ズレているのは目的ではなく、進め方であることが多いのです。詳しくは新規事業で経営陣と現場がすれ違う原因は進め方のズレで扱っています。

こうした場面では、動くプロトタイプを同じ画面で一緒に触りながら話すと、「何ができるのか」を同じ実物で確認できます。モックでも見た目は共有できますが、「実際に動かすとこうなる」という感触までは伝わりにくいものです。動くものを前にすると、「この操作はこうしたい」「ここは不要だ」といった具体的な指摘が出やすくなります。

顧客の反応を見る段階ではMVPが向く

プロトタイプで「作れる」「使える」と判断できたあとに、実際の顧客に価値があるのかを確かめる段階では、MVPが力を発揮します。この段階では、社内の人の感想よりも、顧客の実際の行動が重要です。登録してくれるか、繰り返し使うか、困りごとが本当に解消されているか、といった点です。

ただし、顧客に出す以上、品質や安全面への配慮は欠かせません。個人情報を扱うなら、その保護は最小限であっても省略できません。「小さく作る」と「雑に作る」は別のことです。

MVP・プロトタイプの全体的な進め方や判断の考え方は、MVP開発・プロトタイプ開発の進め方｜新規事業の判断法にまとめています。また、アイデアを動くシステムで確かめる具体的な手順は、新規事業のアイデア検証方法｜動くシステムで確かめる手順で扱っています。

システムが事業そのものになる場合

新規事業の中には、システムが商品やサービスの中心そのものになるものがあります。たとえば、あるデータを集めて価値のある形に加工し、会員に提供するようなサービスです。この場合、システムの動きそのものが顧客に届ける価値になります。

こうした事業では、画面のイメージだけでは、価値の核心である「動き」や「結果の出方」が確認できません。見た目が整っていても、肝心の中身が期待どおりに動くかは別問題です。動くプロトタイプで早めに確かめる意味は、一般に大きいといえます。

混同で起きやすい失敗と防ぎ方

3つの言葉を混同したまま進めると、次のような行き違いが起こりやすくなります。

モックで合意したつもりが、動かしてみたら違った

画面の見た目に全員が賛成し、安心して開発を進めたところ、実際に動かしてみると、操作の流れや処理の結果が想定と違っていた、というケースです。言葉や静止した画面だけで要件を決めると、認識違いが残りやすくなります。実物を触りながら「ここはこう」と指摘できる形にしておくと、このズレは早めに見つけやすくなります。具体的な考え方はシステム開発の認識のズレを防ぐ、実物を見ながらのすり合わせで紹介しています。

プロトタイプをそのまま本番にしてしまう

検証のために素早く作ったものを、そのまま本番の製品として使い続けると、後から品質面や保守性で困ることがあります。プロトタイプを「検証用」と位置づけるのか、「本番へ育てる土台」と位置づけるのかを、あらかじめ決めておくと混乱を避けられます。

MVPを「機能を削った製品」としか見ない

MVPの目的は、機能を減らすことではなく、検証したい仮説を確かめることです。何を確かめたいのかが決まらないまま機能だけを削ると、結果が出ても、何が分かったのか判断できません。作る前に「この結果が出たら続ける、出なければ見直す」という基準を、言葉にしておくことが重要です。

目的を決めずに作り始める

どの形を選ぶにしても、「誰に、何を確かめてもらうために作るのか」が曖昧だと、検証になりません。要件の抜け漏れや食い違いを防ぐ進め方については、要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方が参考になります。

AI駆動開発で変わること、変わらないこと

近年は、AIを開発工程に取り入れる「AI駆動開発」が広がり、試作品を作るまでの手間が小さくなってきています。以前は、動くものを作るには相応の時間がかかるため、まず見た目だけのモックで進める選択が自然でした。AIの活用が進むにつれて、モックを作る代わりに、最初から動くプロトタイプで確かめるという選択肢が現実的になりつつあります。

ただし、AIが作ったものであっても、「何を作るのか」を決めることと、品質の最終的な判断は、人が担う必要があります。プロトタイプの目的を決めるのも、結果を見て続けるかどうかを判断するのも、人の仕事です。この点はAI開発でも品質には人の確認が必要な理由で詳しく説明しています。AI駆動開発での人とAIの役割分担や発注側の要点を知りたい場合は、AI駆動開発とは｜AIと人の役割分担と発注側の要点も参考になります。

つまり、作る速度が上がっても、「何を確かめるために作るのか」を先に決めるという基本は変わりません。むしろ、手軽に作れるようになったからこそ、目的を決めずに作り始めてしまわないよう、私たちは気をつける必要があります。

まとめ

プロトタイプ・MVP・モックの違いを、あらためて整理します。

• モックは、見た目と画面の流れを確かめるためのものです。動きまでは確認できません。
• プロトタイプは、仕組みや使い勝手、実現性を確かめるために、主要な部分を実際に動かす試作品です。決裁者や現場と同じ実物を見ながら話すのに向いています。
• MVPは、実際の顧客に価値を届け、使い続けてもらえるかを確かめるための最小限の製品です。品質を落としてよいという意味ではありません。
• 選び方の基準は、今の段階で一番不確かなことは何か、という点です。順番は固定ではなく、不確かなことに応じて選びます。
• 言葉の使い方はチームによって幅があるため、プロジェクトの最初に意味をそろえておくと、行き違いを減らせます。

新規事業では、「作ってから考える」のではなく、「何を確かめたいかを決めてから作る」ことで、判断の精度が上がります。

JustFitは、株式会社LEGAREAが運営する受託開発サービスで、「先に作って、後から決める（PROTOTYPE FIRST）」という考え方をとっています。構想をもとに約1ヶ月で実際に動くプロトタイプを開発し、実物を見てから契約するかを判断できる進め方です。仕様が固まっていない段階や、稟議を通す前の段階でも相談できます。詳しくはJustFitのサービス紹介をご覧ください。