MVP開発とは何か ― 進め方、費用の考え方、PoCとの違い

「新規事業の企画は通った。ただ、最初に何をどこまで作ればいいのかが社内で決まらない」

「まず小さく作ろうと言われて小さくした。できたものは、誰にも刺さらなかった」

「見積もりを3社から取ったら、300万円から1,200万円まで開いた。同じものを頼んだつもりなのに、何が違うのか分からない」

新規事業の開発でご相談をいただくとき、入口になるのはこうした声です。いずれも「MVP開発」という言葉の理解がずれていることから起きています。

MVP開発とは、Minimum Viable Product（実用最小限の製品）の略で、事業の仮説を検証するために必要最小限の機能だけを備えた製品を作り、実際のユーザーの反応で判断する進め方です。リーンスタートアップの考え方を製品づくりに落とし込んだもので、検証するのは「使い続ける理由があるか」という価値仮説と、「届けられる市場があるか」という市場仮説の2つです。

この記事では、MVP開発とは何か、PoCやプロトタイプと何が違うのか、どう進めるのか、そして費用相場と期間は何で決まるのかを、支援する側の視点から整理します。あわせて、AI駆動開発が当たり前になったことでMVP開発の前提がどう変わったのかも書きます。ここはWT（wesionaryTEAM）が自社でAIの業務ツールを作った経験から書ける部分です。

MVP開発とは ―「最小限」の意味を取り違えない

MVPは Minimum Viable Product の略で、日本語では「実用最小限の製品」と訳されます。ユーザーに価値が届く最小限の形まで作り、事業の仮説が正しいかどうかを実際の反応で確かめる進め方です。

つまずきの多くは、この「最小限」を完成品を安く小さく作ることだと受け取ってしまうところから始まります。それだと、機能を削っただけの中途半端な製品ができます。冒頭の「小さくしすぎて誰にも刺さらなかった」は、この受け取り方から生まれます。

正しくは、検証したい仮説を1つに絞り、その仮説を確かめるために必要な部分だけを、届く品質で作ることです。削る基準は「安いかどうか」ではなく「その仮説の検証に要るかどうか」です。

たとえば「店舗のスタッフは、紙の日報をスマートフォンから入力してくれるか」を確かめたいなら、必要なのは入力画面と保存の仕組みだけです。管理者の集計画面も、権限管理も、他システムとの連携も、この仮説の検証には要りません。逆に、入力画面の使い心地を手抜きすると、仮説そのものが検証できなくなります。削ってよいのは範囲であって、品質ではありません。

MVP・試験導入（PoC）・プロトタイプの違い

この3つは現場でよく混ざります。目的が違うので、混ぜると判断を誤ります。ごく短く言えば、PoCは「作れるか」、プロトタイプは「使えるか」、MVPは「使われるか」を確かめる手法です。

アジャイル開発と並べて語られることもありますが、こちらは別の軸です。MVP開発が「何を検証するか」という目的の話であるのに対し、アジャイル開発は「どう作り進めるか」という進め方の話です。MVP開発をアジャイル開発で進めることもあれば、そうでないこともあります。対立する概念ではありません。

PoC は Proof of Concept の略で、「その方式で本当に実現できるのか」を試すものです。たとえば、手書き伝票をAIで読み取れるか、既存の基幹システムからデータを取り出せるか、といった技術的な確認がこれにあたります。

見落とされやすいのは、PoCが成功しても事業になるとは限らないことです。技術的に読み取れることと、現場が使い続けてくれることは別の問いです。PoCで止まってしまう案件の多くは、最初から検証する問いが技術側に寄っていて、事業側の問いが立てられていません。

順番としては、技術に不確実さがあるならPoC、事業性に不確実さがあるならMVP、見た目や操作の流れに迷いがあるならプロトタイプです。3つを順番に全部やる必要はありません。いま一番大きい不確実さは何かで選びます。

MVPの作り方は、コードを書くだけではない

MVPというと最初から開発に入る前提で考えがちですが、仮説によっては、製品を作らずに検証できます。実際に使われる手法を、作る量の少ない順に挙げます。

告知ページだけを作る方法 ― サービスの説明ページと申し込みフォームだけを公開し、どれだけの人が申し込むかを見ます。「この課題にお金を払う人がいるか」を確かめたいときに使います。作るのは1ページです。

人が裏側で手作業する方法 ― 利用者からはシステムが処理しているように見えますが、実際には担当者が手で処理します。たとえばマッチングの仕組みなら、最初は担当者が手で組み合わせを作って返します。「この提案に価値を感じてもらえるか」を、仕組みを作る前に確かめられます。

既存のツールを組み合わせる方法 ― フォーム、表計算、チャットツールなど、既にあるものをつないで運用します。業務の流れそのものが成立するかを確かめたいときに有効です。

機能を1つだけ作る方法 ― 中核となる機能だけを実装します。ここまで来ると通常の開発になりますが、範囲は絞られています。

上の3つは、開発費をかけずに事業側の仮説を確かめられます。いきなり4つ目から始めていないかは、最初に立ち止まって確認する価値があります。冒頭に挙げた「小さくしすぎて誰にも刺さらなかった」という失敗は、4つ目のやり方で機能を削った結果として起きることが多く、上の3つを試していれば別の学びが得られていた場合があります。

MVP開発の進め方

1. 検証したい仮説を1つに決める

「誰の、どんな課題を、どう解決するか」を1文で書けるところまで絞ります。ここが複数あると、あとの判断がすべてぶれます。

先に挙げた2つのうち、先に確かめるのは価値仮説です。使い続ける理由がない製品は、市場が大きくても伸びません。市場仮説の検証は、価値仮説が通ってからで間に合います。

この段階で決めておくのは、仮説だけではありません。何が起きたら成功とみなすかも先に決めます。「登録した店舗の6割が、2週目も日報を入力している」のように、後から解釈が割れない形にします。この基準がないと、リリース後に「まあまあ使われている」で議論が終わり、次の判断ができなくなります。

基準を決めるときは、数字と期限の両方を入れます。「6割」だけでは、いつ時点の6割かで解釈が割れます。また、母数も先に決めます。「登録した店舗のうち」なのか「声をかけた店舗のうち」なのかで、同じ6割でも意味が変わります。

ここまで決めると、検証に必要な計測も見えてきます。日報の入力回数を記録する仕組みが要る、といった具合です。計測の仕組みはMVPの範囲に入ります。測れないものは検証できません。ここを削ってしまい、公開後に「使われている感じはするが、数字が無い」となる例をよく見ます。

2. 仮説の検証に要る機能だけを選ぶ

機能を一覧にして、1つずつ「これが無いと仮説を検証できないか」を問います。「あった方がいい」は全部落とします。この作業は発注する側と作る側が一緒にやるのが早いです。作る側だけで判断すると事業の意図が抜け、発注する側だけで判断すると実装量の見立てが抜けます。

3. 作る

MVPの実装で重要なのは速度ですが、後で捨てられる形で作ることも同じくらい重要です。検証の結果、方向転換することは珍しくありません。そのときに「せっかく作ったから」と引きずられない構造にしておきます。

具体的には、検証したい部分と、そうでない部分を分けて作ります。認証やデータの保存のように、方向転換しても使い回せる部分は既存の仕組みを使う。逆に、仮説の中心にあたる部分は、作り替えることを前提に、他と切り離しておきます。

この段階で発注する側にお願いしたいのは、判断を止めないことです。MVPの開発期間が延びる原因の多くは、実装ではなく「確認待ち」です。週に一度は動くものを見て、その場で決める体制を作れるかどうかが、期間を大きく左右します。

4. 実際のユーザーに使ってもらう

社内テストで終わらせないことです。社内の人は文脈を知っているので、分かりにくい画面でも使えてしまいます。「使えた」という感想は、外部のユーザーが同じように使えることを意味しません。

人数は多くなくて構いません。10人から20人でも、使われ方の傾向は見えます。重要なのは人数より、その人たちが本当に想定している利用者かどうかです。知り合いに頼んで使ってもらうと、好意的な反応が返ってくるため、判断を誤ります。

このとき、数字だけでなく、使っている場面も見ます。どこで手が止まったか、何を飛ばしたか。数字は何が起きたかを教えてくれますが、なぜ起きたかは教えてくれません。

5. 判断する

1で決めた基準に照らして、続けるか、変えるか、やめるかを決めます。やめるという判断ができることが、MVP開発の価値です。そのために最初の投資を小さくしています。

判断の会議では、基準を後から動かさないことが肝心です。「6割には届かなかったが、伸びている」という議論が始まったら、それは基準の作り直しです。伸びを見たいなら、最初から「4週目までに6割」と決めておきます。

続ける場合も、次に何を検証するかを決めてから進みます。ここを決めずに「そのまま作り込む」に移ると、以降は仮説のない開発になります。

費用と期間 ― 金額を決めているもの

冒頭の「300万円から1,200万円まで開いた」という話に戻ります。

MVP開発の費用相場は、公開されている情報を並べるだけでも大きく食い違います。下の表は、2026年時点で各社が公開している目安をそのまま並べたものです。

※ 出典元の記事はAIを使った開発を別項目として分けていますが、AIを使うかどうかは作り方の違いであって開発手法の区分ではないため、ここではスクラッチ開発にまとめ、両方を合わせた幅を記載しています。

同じ「ノーコードでのMVP開発」でも、10万円と書かれている記事と500万円と書かれている記事があります。どちらかが間違っているのではありません。MVPという言葉が指す範囲が、書き手ごとに違うのです。冒頭の「300万円から1,200万円まで開いた」も、これと同じことが1つの案件の中で起きた状態です。

なお運用費は別にかかります。クラウドの利用料、データベース、決済サービスの手数料などで、公開されている目安では小規模なもので月数万円から、規模が大きくなると月数十万円という記載が見られます。検証期間中の運用費まで含めて予算を置いておくと、検証の途中で止まる事態を避けられます。

金額を動かしている主な要素は次のとおりです。見積もりを比べるときは、金額そのものより、各社がこの前提をどう置いたかを見た方が判断できます。

• 画面数 ― 最も素直に効きます。3画面と30画面では別の話になります
• ユーザーの種類 ― 一般利用者だけか、管理者や承認者もいるか。権限の考え方が入ると設計の量が変わります
• 外部システムとの連携 ― 決済、認証、地図、既存の基幹システム。連携先が1つ増えるごとに、仕様確認と例外処理が増えます
• 既存データの移行 ― 移行の有無で前提が変わります。既存データの品質が悪い場合、移行そのものが一つのプロジェクトになります
• 対応する端末 ― Webだけか、スマートフォンアプリも要るか。アプリを出すなら審査の期間も見込みます
• 止まってはいけない度合い ― 検証段階で高い可用性や監査ログまで求めると、MVPの範囲を超えます
• 公開後の運用体制 ― 誰が問い合わせを受け、誰が直すのか。ここを決めずに進むと、公開後に止まります

同じ企画でも、範囲の置き方で別物になる

先ほどの日報アプリを例に、2つの見積もりを並べてみます。

範囲A（仮説の検証に絞る） スタッフ用の入力画面1つ、写真の添付、保存、入力状況を確認する簡易な一覧。ログインは既存のアカウント基盤を使う。対象は自社の3店舗。集計は表計算に書き出して手作業で行う。

範囲B（社内から要望を集めた結果） Aに加えて、管理者用の集計画面、店舗ごとの権限管理、承認の流れ、既存の勤怠システムとの連携、過去2年分の紙の日報のデータ化、iOSとAndroidのアプリ提供、監査ログ。

どちらも「日報アプリのMVP」と呼ばれます。しかし作る量は数倍違い、確認すべき仕様の数はそれ以上に違います。冒頭の「300万円から1,200万円まで開いた」は、多くの場合こういう状態です。各社が悪意なく、違う範囲を見積もっています。

比較するときは、金額の内訳を並べる前に、上に挙げた要素について各社の前提を揃えてください。それだけで、比較できる見積もりになります。

なお範囲Bの項目は、不要だという意味ではありません。検証を通過した後に必要になるものです。順番の問題です。

期間について

範囲を絞れていれば数週間から3か月程度が一つの目安です。ただし期間を延ばしている要因は、実装の重さより仕様が決まらない待ち時間であることが多いです。次の章はその話です。

自社でprojectAIを作って、MVP開発の前提はどう変わったか

WTは自社で、プロジェクトの進行を支援するAI業務ツール「projectAI」を作って、社内で日常的に使っています。2026年7月に公開したとおり、約4.5か月で73画面、31のAI機能を実装しました。複数のAIエージェントをまとめて動かす「cockpit」という社内ツールも作り、開発そのものをAIで進めています。

この経験から言えることは、はっきりしています。

実装が速くなった分、仕様のあるべき姿を考えることに時間を使えるようになりました。

以前は、時間の大半を実装が占めていました。何を作るべきかの議論は、限られた時間の中で切り上げるしかなく、「まずこれで作ってみて、後で直す」という判断を何度もしてきました。その配分が逆になっています。作る時間が短くなった分を、そのまま「これは本当に必要か」「もっと良い形はないか」を検討する時間に回せるようになりました。

結果として、作るものの質が上がったという実感があります。急いで決めた仕様のまま作り切ってしまう、ということが減りました。

同時に、注意も必要になりました。以前は、機能を1つ足すかどうかの議論に、実装の重さという歯止めがありました。「それを入れると2週間伸びます」という一言が、範囲を絞る力になっていた。その歯止めは弱くなっています。空いた時間をあるべき姿の検討に使うのか、作れるものを増やすことに使うのかで、結果は大きく変わります。

WTでは前者に使うと決めています。何を作らないかを決めることに時間を使い、作る作業は速く終わらせる。この配分にしています。

もう一つ変わったのは、捨てる判断がしやすくなったことです。作り直しの負担が下がったので、検証の結果を受けて方向転換する心理的な障壁が小さくなりました。MVP開発の本来の目的である「早く学んで、早く変える」に、実態が追いついてきたと感じています。

三つ目に、検証の質を上げる余地が広がりました。以前は工数の都合で諦めていた計測や、利用状況の分析を、MVPの段階から入れられるようになっています。検証が目的である以上、ここに手が回るようになった影響は小さくありません。

一方で変わらないものもあります。ユーザーが何に価値を感じるかは、作ってみないと分かりません。ここはAIでは短縮できません。同じように、社内で誰が意思決定するのか、現場が新しいやり方を受け入れられるのかも、開発の速度とは無関係です。

MVP開発の期間を実際に決めているのは、この人間側の部分です。ここで区別しておきたいのは、あるべき姿を検討している時間と、確認待ちで止まっている時間です。前者は成果物の質に返ってきますが、後者は何も生みません。実装が3週間で終わる案件で、検討に2週間かけるのは投資です。決裁の順番待ちで2か月止まるのは、そうではありません。

AIで実装が速くなったからこそ、この2つの差がそのまま期間と品質に出るようになりました。

WTはこの考え方を「AIが拡張し、人が圧縮する」と表現しています。詳しくはAI導入に対する考え方と進め方にも書いています。

MVP開発でよくある失敗

仮説が複数ある ― 検証したいことが3つあると、結果を見ても何が効いたのか分かりません。1つに絞れないときは、事業の設計そのものがまだ決まっていない可能性があります。

成功の基準を後から決める ― リリース後に基準を作ると、出た数字に合わせた解釈になります。

社内評価で終える ― 社内の反応は参考情報です。判断材料にはなりません。

MVPを完成品の第一版として作る ― 捨てられない構造で作ると、方向転換のたびに「作り直しのコスト」が判断に混ざります。

運用を決めずに公開する ― 実際のユーザーに使ってもらう以上、問い合わせは来ます。誰が受けるかを決めていないと、公開直後に止まります。

発注先に仮説の設計まで任せる ― 何を検証するかは事業側の判断です。ここを外部に委ねると、作る側にとって都合のよい範囲に収まります。作る側は、事業の勝ち筋について発注側ほどの情報を持っていません。

計測を入れ忘れる ― 公開後に「使われている実感はあるが、数字が出せない」となる例です。何をもって成功とするかを決めた時点で、それを測る仕組みも範囲に入れます。

関係者が多すぎる ― 範囲を絞る作業は、参加者が増えるほど難しくなります。それぞれが自分の担当領域の要望を出すため、削る判断ができなくなります。決める人を1人に定めておくと進みます。

MVP開発の外注先・開発会社の選び方

MVP開発を外注するとき、効いてくるのは作る力より範囲を一緒に絞れるかです。開発会社を比べるときに確認するとよい点を挙げます。

• 要求されたものをそのまま見積もるのではなく、「それは今回の検証に要りますか」と聞き返してくるか
• 検証の結果、作ったものを捨てる可能性を前提に話ができるか
• 公開後の運用と、その後の作り替えまで含めて設計するか
• 自社で作って運用した経験があるか。受託だけの経験だと、公開後に何が起きるかの肌感が薄くなります
• 検証の結果を、事業の言葉で報告してくれるか。実装した機能の一覧ではなく、仮説がどうなったかを話せるか
• AIをどう使っているかを具体的に説明できるか。速くなる部分と、速くならない部分を切り分けて話せるかどうかが目安になります

WTは事業共創パートナーとして、PoCやMVPの段階から一緒に仮説を絞るところに関わっています。要件定義から運用まで一貫して担当するシステム開発、AIの導入を検証段階から支援するAI導入支援も、同じ考え方で進めています。これまでの開発事例も公開しています。

AI導入の文脈で似た失敗が起きる構図は、AI導入でよくある失敗と、実際にいただくご相談に詳しく書きました。

よくあるご質問

MVP開発とPoC・アジャイル開発の違いは？

PoC（試験導入）は技術的に実現できるかを確かめるもの、MVP開発は事業として成立するかを確かめるものです。確かめる相手も違い、PoCは社内で完結しますが、MVP開発は実際のユーザーに使ってもらって初めて成立します。アジャイル開発はそもそも軸が違い、「何を検証するか」ではなく「どう作り進めるか」の話です。MVP開発をアジャイル開発で進めることもあります。

MVPとプロトタイプの違いは？

プロトタイプは見え方や操作の流れを社内で確認するための試作で、動かないこともあります。MVPは実際のユーザーに使ってもらう製品で、価値が届く品質まで作ります。

MVP開発の期間はどのくらいですか？

範囲を絞れていれば数週間から3か月程度が一つの目安です。公開されている各社の記載もおおむねこの範囲に収まります。ただし期間が伸びる主因は実装量よりも仕様が決まらない待ち時間であることが多く、検証したい仮説を1つに絞れているかが期間を左右します。

MVP開発の費用を抑えるには？

機能を削るより先に、作り方を変えられないかを検討してください。告知ページだけ、人が裏側で手作業する、既存のツールを組み合わせる、といった方法で確かめられる仮説であれば、開発費をかけずに検証できます。開発に入る場合も、検証に要らない機能を落とすことが最も効きます。

MVP開発は社内で作るべきですか、外注すべきですか？

社内にエンジニアがいて、事業側と同じ場所で判断できるなら社内が速いです。外注する場合も、何を検証するかという判断は事業側に残してください。ここまで委ねると、検証したかったことがずれたまま進む可能性があります。

MVP開発だけを開発会社に依頼できますか？

依頼できます。ただし検証の結果によっては作り替えや中止もあり得るため、その前提を共有できる相手かどうかを先に確認しておくと、後の判断がしやすくなります。

MVP開発で失敗しやすいパターンは？

検証したい仮説が複数ある、成功の基準を後から決める、社内評価で終える、捨てられない構造で作る、計測を入れ忘れる、の5つがよく見られます。詳しくは本文の「MVP開発でよくある失敗」に書きました。

MVPで作ったものは、そのまま本番で使えますか？

使える場合と、使えない場合があります。MVP開発は検証が目的なので、利用者数の増加や、止まってはいけない度合いへの備えは最小限にしていることが多いです。検証を通過した後に、どこを作り替えるかを決めるのが一般的な進め方です。

まとめ

MVP開発は、安く小さく作る手法ではありません。検証したい仮説を1つに絞り、その検証に要る部分だけを、届く品質で作る進め方です。

AIによって実装は速くなりました。その結果、範囲を絞る判断の重みが増しています。作れてしまうからこそ、何を作らないかを決める作業が、以前より効くようになりました。

新規事業の最初の一歩をどう置くかでお困りでしたら、お問い合わせからご相談ください。何を検証すべきかの整理からご一緒します。