MVP開発とは？
MVP開発とは、事業のアイデアや仮説を確かめるために、最初の版を作って使ってもらう進め方です。プロトタイプやPoCとの違い、作る前に決めること、費用の幅が決まる要因、外注先に確かめたいことを、作らずに確かめる選択肢も含めて整理します。
新しい事業や業務のアイデアがあるとき、「まずは MVP で」と言われることがあります。MVP は日本語で「実用最小限の製品」と訳されます。「最小限」に目が行きがちですが、中心にあるのは「実用」の方で、確かめたいことを、できるだけ少ない手間で確かめるために、実際に使える状態で作る最初の版を指します。
自分たちの場合は何を確かめるために、どこまで作ればいいのか。作らずに済むのか。その判断に使える材料を残すつもりで書きました。
MVP開発とは
MVP の意味
MVP は Minimum Viable Product の略です。言葉そのものは 2001 年ごろに、SyncDev 社の Frank Robinson が使い始めたとされています。広く知られるようになったのは、Eric Ries がブログや著書『リーン・スタートアップ』（原著 2011 年）で取り上げてからです。
Ries は MVP を、次のように定義しています。
新しい製品のうち、最小の労力で、顧客についての検証された学びを最大限集められる版
（訳は TamaT。原文: "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort"）
ここでいう「検証された学び」は、聞き取りで得た意見ではなく、利用者の実際の行動で確かめられたことを指します。「MVPとは」と調べると、「必要最低限の機能だけを持つ製品」という説明がよく出てきます。間違いではありませんが、この定義の中心は「学び」です。機能の数は、何を学びたいかによって後から決まります。
MVP開発は、この最初の版を作り、実際に使ってもらい、その結果から次の一手を決めるまでの一連の進め方を指します。
「小さく作る」ことが目的ではない
Ries 自身も、MVP は名前に反して最小の製品を作ることではない、と書いています。
機能を削ること自体を目的にすると、よくあるのは「削った結果、何も確かめられない版」ができることです。たとえば、利用者が続けて使ってくれるかを確かめたいのに、2 回目以降の利用に必要な機能まで削ってしまうと、結果が出ても判断に使えません。
逆に、確かめたいことがはっきりしていれば、作る範囲は思ったより狭くて済むことがあります。作らずに済むこともあります。MVP開発で最初に考えるのは「何を削るか」ではなく「何を確かめるか」です。
MVP・プロトタイプ・PoC の違い
何を確かめるかで分ける
3 つの言葉は混ざって使われがちです。違いは、確かめたいことと、それを触る人にあります。下の表は TamaT での使い分けです。会社や文脈によって定義の幅があるので、社内で話すときは最初にそろえておいてください。
確かめたいこと | 主に触る人 | 作る範囲 | |
|---|---|---|---|
PoC（概念実証） | 技術的に実現できるか | 開発者・社内の担当者 | 実現が不確かな部分だけ |
プロトタイプ | 形や操作の流れが伝わるか、使いやすいか | 社内の関係者、一部の利用者候補 | 画面や操作の流れ。中身は仮でもよい |
MVP | 利用者が実際に使うか、価値を感じるか | 実際の利用者 | 確かめたいことに必要な機能が、本当に動く状態 |
大きな違いは、MVP が「実際の利用者に、本当に使ってもらう」前提にあることです。プロトタイプは見た目や流れを確かめるので、裏側が動いていなくても役目を果たせます。MVP は、使ってもらった結果から判断するため、確かめたい範囲は実際に動いている必要があります。
順番に進めることもあります。技術的な不安があれば PoC を先に、画面の流れに迷いがあればプロトタイプを先に作り、それから MVP に進む、という具合です。全部を通る必要はありません。
作る前に決めること
確かめたい仮説を 1 つに絞る
ここでいう仮説は「確かめたいこと」と言い換えて構いません。最初の版で確かめられることは、多くありません。「利用者はこの課題に困っているか」「この方法なら使い続けてくれるか」「お金を払ってくれるか」は、それぞれ別の問いです。全部を一度に確かめようとすると、作る範囲が広がり、結果が出ても何が効いたのかが分かりにくくなります。
まずは「これが外れていたら、事業そのものを見直す」という仮説を 1 つ選びます。残りは、その仮説が確かめられてから順に扱います。
何が分かれば次に進むかを先に決める
仮説と一緒に、判断の条件も決めておきます。「誰が、どのくらいの期間使って、どうなっていれば次に進むか。どうなっていたら方向を変えるか」です。
条件は作る前に書き出しておきます。作った後で決めると、手元の結果に合わせて基準を緩めてしまいがちです。数字で決められない場合は、「現場の担当者が、紙の記録に戻らずに 1 か月使い続けられたか」のような、観察できる形にしておきます。
作らずに確かめられないかを比べる
仮説と判断の条件が決まったら、それを確かめる手段を比べます。ソフトウェアを作ることは、選択肢の 1 つにすぎません。
手段 | 確かめやすいこと | 確かめにくいこと | 結果が出るまでの手間（時間と費用） |
|---|---|---|---|
聞き取り | 課題があるか、今どうしているか | 実際に使うか、払うか（言うことと行動がずれやすい） | 小さい |
紙やスプレッドシートでの運用 | 業務の流れが回るか、必要な項目は何か | 利用者が増えたとき、操作のしやすさ | 小さい〜中くらい |
既存サービスの組み合わせ（入力フォーム、プログラムを書かずに画面を作れるノーコードツールなど） | 一連の流れを利用者が使うか | 独自の処理、細かな権限、既存システムとのつなぎ | 中くらい |
試作開発（MVP） | 利用者が実際に使い続けるか、業務に合うか | 作らなかった機能が要るかどうか | 大きい |
表の下に行くほど、手間は大きくなります。仮説が「課題があるか」なら、聞き取りで足りることが多いと TamaT は見ています。「業務の流れが回るか」なら、スプレッドシートでしばらく運用してみる方が早く分かります。
作る価値があるのは、作らないと確かめられない仮説が残ったときです。たとえば、複数の人が同時に記録して集計まで自動で回るか、権限ごとに見える情報を分けたときに現場が回るか、といったことです。これは紙や表計算では再現しにくいです。
比べた結果、作らないと決めることもあります。それも MVP開発の前段で出てよい結論です。
MVP開発の進め方
作ると決めたら、進め方はおおむね 4 段です。
1. 仮説と検証の目的をそろえる
前の章で決めた仮説と判断の条件を、紙 1 枚程度に書いて、開発に関わる人と、結果を見て判断する人の両方で共有します。判断する人が最初の打ち合わせにいないと、結果が出たあとで条件が変わりがちです。開発の途中で「この機能も必要では」という話が出たときに戻る場所にもなります。
2. 機能と範囲を決める
機能を洗い出したら、1 つずつ「これがないと判断の条件を確かめられないか」で残すかどうかを決めます。見落としやすいのは、ログイン、権限、データの出力のような地味な機能です。検証の結果を集めるのにデータの出力が要る、ということはよくあります。
3. 設計して開発する
範囲が決まったら設計と開発に進みます。最初の版は、後から作り直すことも、作り足すこともあります。どちらに進んでもよいように、データの持ち方や画面の分け方は作り足しやすい形にしておきます。
4. 使ってもらい、次の一手を決める
実際の利用者に使ってもらい、決めておいた条件に照らして判断します。次に進む、方向を変える、やめる、のどれかです。続ける場合は、使って分かったことをもとに、次に確かめる仮説と作り足す機能の優先順位を決めます。
TamaT のサービスページでは、MVP開発を「試作開発」とも呼んでいます。進め方の 4 段と相談の流れは、MVP開発（試作開発）のサービス内容で紹介しています。
MVP開発の事例：「呼及舎」様 | 介護・福祉の勤怠・実績管理システム
TamaT が開発した、介護・福祉サービスの事業者向けの勤怠・実績管理システムです。使うのはお客様である事業者で、自社の業務のためのシステムです。
障害福祉・介護サービスにおける日々の記録や、請求に必要な複雑な実績票等の作成に向けて、従業員の出勤簿の入力、サービス種別ごとの実績票の作成、制度上必要な月ごとの記録のExcel 出力など、日々の記録と月末の書類づくりに使う機能を持っています。
重度訪問介護といった、より専門的な介護事業においては、制度上必要な記録の要件も独特で、既存の勤怠・実績管理システムでは対応しきれないという課題がありました。
記録・管理要件に合わせるために、従来はGoogleフォームやスプレッドシートを掛け合わせて運用を行なっていましたが、手動の運用の手間を大幅に省きたいというご要望があり、フルスクラッチでの Webアプリ開発のご相談を受けました。
最初の版で確かめたかったのは、まず既存の運用をトレースできるかどうかでした。
Googleフォームの項目や出力先のシートの構成をWebアプリで再現し、従来の記録・管理の要件は保ったまま、作業コストの削減を実現しました。
運用していく中で、より良い使い勝手や、便利な機能の追加も、段階的に行なっていきました。
例えば、スマートフォンやWebアプリの操作への慣れに個人差がある中で、従業員の方が慣れないWebアプリを追加したりログインする際の課題への対応や、従業員・利用者管理のような新規機能の追加、あるいは、記録・管理要件によりマッチする形での入力・出力項目のアップデートを行いました。
運用は軌道にのり、すでに3年ほど実運用を行なっています。将来的には、このサービス外で管理している記録・管理要項にも対応できるようなさらなる拡張を行なっていくビジョンもあります。
MVP開発では、既存の市場のパッケージでは痒いところに手が届かない業界独自の要件に対して、まずはミニマルなプロダクトからフルスタックアプリを導入し、検証を行います。検証の中で機能改善や課題の解消を進めていき、最終的には同業に対して横展開できるレベルのプロダクトの開発も見込むことができます。
費用の幅が決まる要因
MVP開発の費用は、作る範囲によって大きく変わります。「相場はいくら」と一言では言えません。見積もりの幅を左右するのは、主に次の要因です。
要因 | 費用に効くところ |
|---|---|
作る範囲 | 確かめたい仮説が 1 つに絞れているほど、作る機能は少なくなる。前の章で仮説と判断の条件を決めておくことが、そのまま費用を抑えることにつながる |
外部とのつなぎ | 決済、既存の社内システム、外部サービスの API（ほかのサービスとデータをやり取りする窓口）などとつなぐと、つなぐ先の仕様の確認や動作確認の手間が加わる |
権限と利用者の種類 | スタッフ・責任者・管理者のように、見える情報や操作を分けると設計と確認の手間が増える |
データの移行 | 今のスプレッドシートや別のシステムにあるデータを最初から入れるなら、整理と移行の作業が要る |
検証後のこと | 最初の版を作って終わりか、検証の支援やその後の作り足しまで含めるかで、見積もりの組み方が変わる |
開発期間も、同じく検証の目的、必要な機能、利用者数、外部とのつなぎで決まります。
TamaT の案件ごとの費用の考え方は開発費用と見積もりのページにあります。条件を入力すると初期費用と月額費用の概算が出る見積もりシミュレーターも置いています。MVP開発で初期費用と運用費をどう分けて見積もるかは、MVP開発（試作開発）の費用の考え方にまとめています。
外注するときに確かめたいこと
MVP開発を外部に頼む場合、技術力や価格と並べて、話の早い段階で確かめておきたいことが 3 つあります。進め方の相性が分かるところです。
仮説の整理から一緒に考えてくれるか。 機能一覧を渡せばすぐ見積もりが出る相手は、手早い反面、「その機能で何を確かめるのか」を一緒に考える機会がありません。最初の打ち合わせで、作るものより先に、確かめたいことを聞いてくれるかを見ておくとよいです。
作らない提案をしてくれるか。 作らずに確かめられる仮説なら、そう言ってくれる相手の方が、結果として無駄な開発を避けられます。「この部分はスプレッドシートで始めませんか」といった提案が出るかどうかは、ひとつの目安になります。
検証の後をどう考えているか。 使った結果を見て作り足すにしても、作り直すにしても、その判断に付き合ってくれるか。作り足しやすい形で作ってくれるかも、最初に確かめておきたい点です。
TamaT がこの 3 点にどう対応しているかは、MVP開発（試作開発）のサービス内容とよくある質問に書いています。
まとめ
MVP開発で迷ったときの判断の軸は 3 つです。
- 確かめたい仮説は 1 つに絞れているか。 絞れていなければ、作る前にそこを詰めます。
- 作らないと確かめられないか。 聞き取りやスプレッドシート、既存サービスで確かめられるなら、そちらが先です。
- 何が分かれば次に進むかを、先に決めてあるか。 決めていれば、最初の版の範囲は自然に決まります。
3 つとも「はい」なら、MVP として最初の版を作る段階です。どれかに迷いがあるなら、作る前の整理から始めるのがよいと TamaT は考えています。
アイデアの検証を相談する
新しい事業のアイデアも、社内の業務を変えるアイデアも、何を確かめたいのか、作るべきかどうかの段階からご相談いただけます。
→ MVP開発（試作開発）について見る