MVP開発の進め方｜作る前の確認から試作・内製外注の切り分けまで4段階

MVP開発は、顧客について確かめたいことを一つ決め、それを確かめられる最小の形を作る進め方です。機能を減らすのが目的ではなく、作る前と作った後に「学べること」を最大にします。順番は、作る前の確認、最小の範囲決め、試作（内製か外注かの切り分けを含む）、検証の4段階です。

この記事は、新規事業を任された担当者と中小企業の経営者に向けて、開発会社に頼む前に自社で決める範囲を説明します。英語資料の日本語訳は当社によるものです。

株式会社01STARTの芝先です。生成AI研修と新規事業の支援をしています。

MVP開発とは何か｜学びを最大にする作り方

MVP（Minimum Viable Product）は、新製品の最初の版です。少ない労力で、顧客についての検証された学びを最大限集められるものを指します。

Eric Riesが2009年8月3日の記事で、この趣旨を書きました。原文は次の一節です。”the maximum amount of validated learning about customers with the least effort”。定義の中心は学びの量です。機能が少なくても顧客の反応が分からなければ、MVPとして役に立ちません。

MVPの元の定義を示したのはFrank Robinsonです。広めたのがRiesだと、Ash Mauryaが「Moving beyond MVP」に書いています。Mauryaはこの記事で、定義が広がりすぎたとも指摘しました。顧客から学ぶのに使うものは、ほぼ何でもMVPと呼べてしまう、という問題意識です。

Mauryaの別の記事にも定義があります。作れる最小のものは、顧客に価値を届け、その価値の一部を取り戻せるもの。感想を聞くだけでなく、価値の一部が返ってくるかまで見る定義です。

MVP・PoC・プロトタイプの違い

似た言葉と混同されやすいので、当社の整理で違いを表にします。

顧客の反応が知りたいときはMVP、技術の見通しが知りたいときはPoCを選びます。

4段階の進み方

この記事では、MVP開発を次の4段階で進めます。

期間の目安は、公的な根拠のない私の見方です。事業や体制で大きく変わります。検証の相手が集まるまでの日数で決まる部分が大きいので、作業量だけで見積もらないでください。

アジャイル開発との関係

アジャイル開発は、小さく作って確かめながら進める開発の進め方です。MVPは「何を作るか」の考え方で、アジャイルは「どう作り進めるか」の方法と整理できます。

MVPを1回作って終わりにせず、検証の結果を受けて直す。この繰り返しにアジャイルの進め方が合います。外注するときの契約の形は、後の章で扱います。

事業全体の前提を1枚にまとめるなら、リーンキャンバスの作り方が入口になります。

作る前に確かめる範囲｜ランディングページと動画

開発に入る前に、需要の有無を作らずに確かめられる場合があります。最初に試したいのは、ランディングページ（商品の案内を1枚にまとめたWebページ）です。

Riesは2009年3月の記事で、広告つきのランディングページを先に作ればよかったという振り返りを書いています。やり方は4つです。

• 解決する課題と、提供する価値を1枚に書く
• 申し込みか事前登録のボタンを置く
• 想定する顧客が集まる場所に、少額の広告や直接の案内で届ける
• 反応した人の数と、その後の問い合わせを数える

動画で試したDropboxの例

作る前に反応を確かめた例として、Dropboxが知られています。2015年2月5日のFirst Round Reviewの記事によると、創業者のDrew Houstonは動画を2本作りました。どちらも3分間のデモ動画です。

2本目はDiggとRedditに投稿されました。1日で待機リストが5,000人から75,000人に増えています。動画の作りに加えて、初期の利用者が集まる場所を選んだことが効いた、と本人は語っています。

規模や対象は違いますが、自社の顧客が同じ場所にいるとは限りません。展示会、業界団体、既存の取引先など、事業ごとに集まる場所は違います。

どの仮説にどの型を選ぶか

作る前の確認には、いくつかの型があります。確かめたい仮説で選びます。

試す前に書いておくこと

作る前の確認を始める前に、次の2つを書き出します。

1. 確かめたいことを1文にする。例：「製造業の購買担当者が、月額で見積もり自動化を申し込む」

2. 成功の基準を、試す前に数字で決める。例：案内した10社のうち、3社が申し込む

基準を後から決めると、結果に合わせて解釈してしまいます。人物像が曖昧なら、先にペルソナの作り方で絞ってください。課題の見つけ方は生成AIでビジネスアイデアを生み出す方法にまとめています。

最小に作る範囲の決め方｜機能を3つに仕分ける

作ると決めたら、機能を「確かめたいことに必要か」で3つに仕分けます。判断軸は、これがないと確かめたいことが確かめられないか、です。

手作業で代替する場合は、自動で処理しているように見せかけません。人が顧客の個人情報を扱うときは、利用目的を本人に示し、同意が要る場面では同意を得ます。取扱いの範囲は、先に決めておきます。

顧客から見えない部分を人が補うと、開発の量を大きく減らしやすくなります。検証に使う人数と期間も絞ります。目安として、顧客3〜5社に使ってもらう形から始めると扱いやすいです。

人に何を残すか｜作らない範囲の決め方

私は、自社サイトのAIアバターに講座の問い合わせ対応を任せて試しています。2026年7月の対応ログに残る1件では、質問への回答から無料相談の予約同意まで、一つの会話で完結しました。

LINE側では、確信度の点数付きの自動回答を、人が承認または修正して送る形で試しています。確信度の点数とは、AIが自分の回答にどれだけ自信があるかを表した数字です。

何を機械に任せ、何を人に残すか。この線引きが、MVPで作らない範囲を決める作業そのものです。

検証結果の読み方

試作を使ってもらったら、最初に決めた成功基準と照らします。見るのは、使った人の数よりも、使い続けた人と対価を払う意思を示した人の数です。

基準に届いた場合は、必ず作る機能を1つ足して、もう一度確かめます。届かなかった場合は、機能を増やす前に、課題の捉え方か届け方を疑います。顧客がどの場面で止まったかは、カスタマージャーニーマップの作り方で場面ごとに整理すると見つけやすくなります。

やめる判断も、検証の成果の一つです。作り込む前にやめられれば、時間と費用を次の案に回せます。

生成AI・ノーコードで内製するには

内製（自社で作ること）には、生成AIとノーコードツールが使えます。ノーコードツールは、プログラムを書かずにアプリを組み立てる道具です。試作品は短期間で作れるようになり、詰まる箇所は「何を試すか」に移っています。

Steve Blankは、シリコンバレーの企業で21年働いた起業家で、現在は起業家教育者です。1996年にE.piphanyを共同創業し、1999年に退いたあと、『Four Steps to the Epiphany』を書きました。既存の会社は事業モデルを実行し、スタートアップはそれを探す、という区別を示した本です。スタンフォード大学の起業講座の教材にもなっています。経歴は本人のサイトの紹介によります。

Blankは2026年3月17日の記事で、AIコーディングツールを取り上げました。MVPは数日、ときには数時間で作れると書いています。

続く一文は次のとおりです。”An MVP is no longer proof of your team’s competency”。作れたこと自体は、もうチームの力の証明にならないという意味です。この記事は米国の起業家教育の文脈で書かれており、日本の中小企業にそのまま当てはまるとは限りません。

日本の公的資料にも、近い考え方があります。経済産業省のDX推進の手引き2025は、身近で取りかかりやすいところから始める企業が多いと書いています。例は、基幹データベースをノーコードで作り、属人化した作業を自動化する取り組みです。SaaS（月額などで使うクラウドの業務ソフト）も使われています。

2025年版の中小企業白書は、DXの問題点に費用負担と人材不足を挙げる事業者が多いと示しました。事例の倉岡紙工は、必要最小限から始める「身の丈DX」に取り組んでいます。どちらの資料も、MVPという語は使っていません。

内製の最小手順

内製に向くのは、確かめたいことが1つに絞れていて、画面が数枚で済む場合です。顧客データなど扱いに注意が要る情報は、最初は載せません。手順は次の5つです。

1. 必ず作る機能の画面を、紙に手で描く

2. 用途に合うツールの種類を選ぶ。申込みや問い合わせを集めるならフォーム型、一覧や集計が要るならデータベース型、画面を組むならアプリ型

3. 画面を1つずつ作り、そのつど自分で触って確かめる

4. 顧客3〜5社に使ってもらい、使った場面を横で見るか、聞き取る

5. 成功基準と照らして、続ける、直す、やめるを決める

内製した試作品は、検証用と割り切ります。動いたからといって、本番の運用に耐えるとは限りません。

外注するなら何を決め、何を確認するか

外注するかどうかは、開発の難しさでは決まりません。その部分が事業の競争力に関わるかで分けます。

IPAのDX動向2025（2025年版、2025年6月26日公開）によると、日本では外部委託が4割弱で最多でした。競争力の源になるコア事業の開発についての回答です。必要な部分は内製化済みと答えた日本の企業は16.7%で、国別の回答のため中小企業の実態とは読めません。

外注と内製の切り分け

競争力に関わらない部分は、開発せず既存のSaaSで済ませる選択肢もあります。

頼む前に決める4点

開発会社に相談する前に、次の4点を自社で書いておきます。

1. 確かめたいことと、成功の基準

2. 必ず作る機能と、作らない機能の仕分け

3. 検証が終わったときに、続けるかやめるかを決める人

4. 顧客データを扱うかどうかと、扱う場合の責任者

この4点が書けていれば、見積もりの前提が揃います。書けていないまま頼むと、依頼の範囲が膨らみやすくなります。

見積もりを頼むときに開発会社へ確認する点

見積もりを依頼する前後に、次の4点を確認します。

• MVPや新規事業の検証版を作った経験があるか
• 準委任契約での進め方を説明できるか
• 検証の結果を受けて範囲を変えるとき、どう対応するか
• 作った成果物の権利が、どちらに帰属するか

経験の有無は、似た案件の進め方を具体的に聞けば分かります。「御社なら何から作りますか」と尋ねて、機能の仕分けから話が始まる会社は、MVPに慣れている可能性が高い目安になります。

MVP開発の費用は何で決まるか

費用の相場を示す公的な統計は見つかりませんでした。ここでは金額でなく、費用を決める要因を挙げます。

• 画面の数。検証に必要な画面が増えるほど、作る量が増えます
• 認証と決済の有無。会員の登録や支払いを扱うと、安全面の作り込みが増えます
• 連携先の数。既存の顧客管理や会計のシステムと連携すると、確認すべき項目が増えます
• 体制。発注側がどれだけ関わるかで、開発会社側の確認や調整の量が変わります

検証用の版と本番運用の版では、費用の桁が変わりやすいです。検証用の版は画面も連携も絞れますが、本番では認証、権限、障害への備えが加わります。

金額を知る手順は次のとおりです。まず、頼む前に決める4点を同じ資料にして、2〜3社に相見積もりを依頼します。そのとき、検証版と本番版を分けて見積もってもらいます。内訳の差から、どの要因が効いているかが読み取れます。

契約の形

IPAのアジャイル開発版モデル契約は、「MVP開発」を説明しています。実用最小限の製品（Minimum Viable Product）を開発することだと言います。契約は準委任を前提としています。

準委任は、開発会社が専門家として業務を行うこと自体に対価を払う契約です。完成物を納めることに対価を払う請負型とは、対価の根拠が違います。

発注側が任せきりにせず、主体的に関わることも示されています。契約の前に、アジャイルの考え方を双方で共有することも同じ資料にあります。

準委任は成果物の完成を約束する契約ではありません。そのため、発注側が進め方を管理する負担が増えます。契約の条項は、IPAのひな形を参考にしつつ、弁護士や法務の担当者に確認してください。

MVPは作る範囲が途中で変わる前提です。私は、範囲を最初に固定する請負型より、月ごとに範囲を見直せる形のほうが合いやすいと考えています。ただしこれは私見で、公的資料が請負を否定しているわけではありません。

外注した後の進め方

外注した後も、発注側の仕事は残ります。週に1回など決まった頻度で、作った画面を触り、確かめたいことに近づいているかを開発会社と見直します。

範囲を変えるときは、何を足して何を外すかを1つずつ決めます。足すだけの変更は、費用と期間を押し上げます。顧客の声を聞く場には、開発会社の担当者にも同席してもらうと、仕様の意図が伝わりやすくなります。

MVP開発でよくある失敗4つ

失敗には型があります。それぞれに避け方を添えます。

• 機能を盛りすぎる：公開が遅れ、検証が始まりません。「作らない」機能を先に書き出して避けます。
• 成功基準を決めずに作る：感想を聞いて終わります。作る前に、基準を数字で決めます。
• 作り込んでから見せる：外れたときの損失が大きくなります。紙の画面や動画の段階で、顧客に見せます。
• 開発会社に任せきりにする：範囲が膨らみ、学びが残りません。検証の結果を見る場に、発注側が必ず入ります。

DX全般で取り組みが進まない理由は、DXの成功と失敗を整理した記事にまとめています。MVPの失敗にも通じる点が多いので、あわせて読んでください。

MVP開発の進め方まとめ｜要点5つ

• MVP開発は、確かめたいことを一つ決め、最小の形で作る進め方です
• 作る前に、ランディングページや動画で反応を確かめられる場合があります
• 機能は3つに仕分け、何を人に残すかも先に決めます
• 内製は検証用と割り切り、外注するなら頼む前の4点を書いておきます
• 費用は、画面数、認証と決済、連携先、体制で決まります

今日書く3点

今日、次の3点を紙に書いてください。

• [ ] 確かめたいこと（1文）
• [ ] 成功の基準（数字）
• [ ] 必ず作る機能（最大3つ）

この3点が書ければ、内製でも外注でも、依頼や作業の範囲がぶれにくくなります。新規事業の検証の進め方を相談したい場合は、資料請求からサービス資料をご覧ください。

著者の登壇実績です。生成AI活用セミナーの累計参加者は、1万人以上です。MVPの開発実績を示すものではありません。