新規事業のご相談で最初に聞かれるのは、ほぼ例外なく「いくらかかりますか」です。当然の質問だと思います。稟議を通すにも、投資判断を下すにも、まず金額の見当がつかないことには何も動きません。
一方で、この質問にその場で単一の金額を返せる開発会社があるとしたら、それは相当に危うい。同じ「MVP開発」という言葉で呼ばれている案件でも、実際の工数は10倍以上ひらくことがあるからです。金額だけが一人歩きすると、着手後に「聞いていた話と違う」という最悪の入り方をしてしまいます。
そこでこの記事では、金額そのものではなく、MVP開発の費用がどういう構造で決まるのかを分解します。相場のレンジ、価格を左右する5つの要因、費用を下げる正しい方法と間違った方法、そして3ヶ月でリリースするためのスケジュールと契約形態まで。読み終えたときに、自社の案件がどのあたりに着地しそうか、自分で当たりをつけられる状態を目指します。
そもそもMVPは「安い版」ではない
費用の話に入る前に、言葉の定義を揃えさせてください。ここがズレたまま見積りを取ると、比較そのものが成立しなくなります。
MVP(Minimum Viable Product)は、事業仮説を検証するために必要な最小限の製品を指します。ポイントはMinimum(最小)とViable(実際に使える)が同時に成立していることです。
現場でよく見かける誤解は、大きく2つあります。
誤解1 — MVPとは「本番版の廉価版」である
機能を減らして値段を下げたもの、という理解です。これは順序が逆です。MVPで削るのは「まだ検証していない仮説に紐づく機能」であって、予算に合わせて機能を削るのではありません。判断基準は「この機能がないと、確かめたいことが確かめられないか」の一点です。予算起点で削ると、削ってはいけない中核機能まで削れてしまい、リリースしても何も学べないプロダクトができあがります。
誤解2 — MVPだから品質は落としていい
これも危険です。Viable、つまり実際のユーザーが実際の業務や生活のなかで使えなければ、返ってくるフィードバックは「使いにくいから使わなかった」という情報にしかなりません。検証したいのは仮説であって、品質の悪さではないはずです。機能の幅は思い切って狭く、しかしその狭い範囲は本番品質で。これがMVPの正しい削り方です。
この定義を発注側と開発側で先に握っておくと、見積りの前提が揃います。逆にここが曖昧なまま複数社に相見積りを取ると、A社は「検証用のプロトタイプ」を、B社は「本番運用に耐えるシステム」を見積もっていて、金額差が3倍ついている、といったことが平気で起きます。
費用相場は「レンジ」で見る前に、掛け算に分解する
費用を決める3つの変数
受託開発の費用は、突き詰めると次の掛け算にほぼ還元されます。
- 人月単価 — エンジニア1人が1ヶ月稼働したときの費用
- 投入人数 — 同時に動く体制の大きさ。PdM(プロダクトマネージャー)、エンジニア、デザイナーなど
- 期間 — 何ヶ月動かすか
「相場はいくらか」を調べる前に、自社の案件が何人 × 何ヶ月になりそうかを考えたほうが、はるかに早く精度の高い当たりがつきます。逆に言えば、この3つを聞かずに総額だけを提示してくる見積りは、根拠を確認したほうがよいということでもあります。
人月単価は、一般に国内の受託開発では月あたり数十万円台後半から百数十万円(おおよそ70万〜150万円)という幅で語られることが多く、シニア級エンジニアの比率や、どこまでを単価に含めるかで倍近く変わります。ただしこの幅自体に公的な出典があるわけではありません。以下も市場統計ではなく、この前提を置いた場合の試算として読んでください。
掛け算の結果として、どのあたりに着地するか
読者が自分で検算できるよう、人月数まで書きます。単価は上記の70万〜150万円を当てはめています。
- 検証に振り切った最小構成(1〜2名 × 1〜2ヶ月 = 1〜4人月) — 約70万〜600万円。ユーザー登録も決済もなく、単一の業務フローだけを動かして仮説を確かめるようなケース。
- 標準的なMVP(2〜3名 × 3ヶ月前後 = 6〜9人月) — 約420万〜1,350万円。認証があり、実ユーザーが日常的に使い、最低限の管理画面を伴うケース。
- 決済・外部連携・本格的な管理画面を伴うMVP(3名前後 × 4〜6ヶ月 = 12〜18人月) — 約840万〜2,700万円。ここまで来ると、それは本当にMVPなのか、を一度立ち止まって考える価値があります。
注意していただきたいのは、各帯の下限は「最も安い単価 × 最小の体制 × 最短の期間」が同時に成立した場合の理論値だという点です。実務でこの3つが揃うことは稀で、中央付近に寄ると見ておくほうが現実的でしょう。金額の幅そのものより、自社の案件が何人月になりそうかを先に見積もるほうが精度が高い、という点だけ持ち帰ってください。
レンジが当てにならない3つの理由
第一に、「MVP」という言葉が指す中身が案件ごとにまったく違います。前述のとおり、定義が揃っていない相見積りは比較になりません。
第二に、単価に何が含まれるかが会社ごとに違います。要件定義、UIデザイン、インフラ構築、テスト、リリース後の初期サポート。これらが単価に含まれる会社と、別見積りになる会社があります。安く見えた見積りに後から追加が積み上がる、という話の多くはここが原因です。
第三に、初期費用と運用費用が分かれています。MVPは作って終わりではなく、リリース後に学びを反映して回し続けるものです。初期費用だけで比較すると、その後の改修単価が高い会社を選んでしまうことがあります。
そのため私たちは、Webサイト上で一律の価格表を掲示していません。初回のヒアリングで検証したいことと制約を伺ったうえで概算をご提示し、フェーズごとに区切った段階見積りでお出ししています。金額の話は、前提を揃えてからのほうが結果的に早く進みます。
費用を左右する5つの要因
見積りが動く要因は無数にありますが、実務上インパクトが大きいのは次の5つです。自社の案件がどれに該当するかをチェックすると、レンジのどのあたりに着地するかが見えてきます。
1. 機能数 — 数えるべきは「機能」ではなく「画面と状態」
「機能は10個くらいです」という説明は、残念ながら見積りにはあまり効きません。工数を決めるのは機能の個数ではなく、画面の数と、その画面が取りうる状態の数だからです。
たとえば「注文管理機能」はひとつの機能ですが、実装するのは一覧・詳細・新規作成・編集・キャンセルという複数の画面であり、それぞれに「データがないとき」「読み込み中」「権限がないとき」「エラーのとき」といった状態が存在します。ここを設計せずに作ると、リリース直後に「この場合どうなるんですか」という指摘が大量に出ます。
見積りを依頼するときは、機能の箇条書きよりも、「誰が、どういう順番で、何をするか」という業務フローを1本書いて渡すほうが精度が上がります。フローが書ければ、必要な画面と状態は開発側で洗い出せます。
2. 認証と決済 — 「あるかないか」で変わるコストの段差
ユーザー認証と課金・決済は、どちらも「あるかないか」で費用の階段が明確に一段上がる領域です。
認証が入ると、権限管理、パスワードの再設定、招待、退会といった周辺の仕組みがまとめて必要になります。組織アカウントで複数ユーザーを管理する要件が入れば、さらに一段上がります。
決済はより顕著です。単発課金なのかサブスクリプションなのか、返金・解約・プラン変更・請求書払いに対応するのか、税や手数料の扱いをどうするのか。決済そのものは外部サービスを使えばよいのですが、費用がかかるのは決済の前後にある業務のほうです。「クレジットカード決済を入れたい」という一言の裏に、数週間分の設計と実装が隠れていることは珍しくありません。
MVPの段階では、「請求は当面手動で運用し、システム化はユーザーが増えてから」という判断が合理的なケースがかなりあります。
3. 管理画面 — 見落とされがちな最大の伏兵
エンドユーザー向けの画面は誰もが想像しますが、それを運用する側の画面は見積りの議論から抜け落ちがちです。実際には、管理画面がユーザー向け画面と同じかそれ以上の工数になることもあります。
問い合わせ対応でユーザーのデータを見たい、不正なデータを直したい、マスタを登録したい、実績を集計したい。運用が始まった瞬間に、これらは必ず必要になります。
ここでの現実的な打ち手は、MVPの段階では管理画面を作り込まないことです。データベースを直接参照する運用ツールで当座をしのぎ、運用が固まってから画面にする。誰が何回その操作をするのかが分からないうちに管理画面を作ると、ほぼ確実に作りすぎます。
4. デザイン要件 — 分かれ目は「どこまで独自に作るか」
デザインの費用は「きれいかどうか」ではなく、どこまでオリジナルを作るかで決まります。
既存のUIコンポーネント群をベースに、色とロゴと余白を自社仕様に整える方針であれば、費用は抑えられます。一方、ブランド体験そのものを差別化要素と位置づけ、独自のインタラクションやアニメーション、イラストレーションを起こすとなれば、専門の工数が別途必要です。
判断の軸はシンプルで、デザインが検証したい仮説の一部かどうかです。toCで「使いたくなるかどうか」自体が仮説なら、デザインには投資すべきです。業務システムで「業務が回るかどうか」が仮説なら、MVPの段階では標準的なUIで十分なことがほとんどです。
5. 体制 — 発注側が誰を出すかで決まる期間と費用
意外に思われるかもしれませんが、費用を大きく左右するのは発注側の体制です。
意思決定者が明確で、週に1回30分の意思決定に確実に出られる。仕様の疑問に1〜2営業日で回答できる。この状態なら、開発は止まりません。逆に、確認のたびに社内で1週間かかる、決裁者が途中で変わる、という状況では、待ち時間がそのまま期間になり、期間はそのまま費用になります。
私たちが毎週の定例デモを進め方の中心に置いているのは、この待ち時間を構造的に潰すためです。動くものを毎週見ながら判断すれば、認識のズレは1週間分にしか育ちません。4つの領域それぞれの進め方はサービス紹介に整理していますが、共通しているのはこの「小さく確かめて、早く直す」という原則です。
費用を下げる正しい方法と、間違った方法
MVPの費用を下げる方法は、総額を動かすものと、見かけの金額だけを動かすものに分かれます。前者はスコープと意思決定の設計に手を入れ、後者は見積書の数字を下げて総額を押し上げます。
正しい方法1 — 機能を「核」まで絞り込む
最も効果が大きく、最も実行が難しいのがこれです。
私たちが物流倉庫業の新規事業を支援したとき、最初にお預かりした構想は10機能ありました。どれも「あったほうがいい」機能で、事業として成立させるには最終的にすべて必要になるものです。
そこで最初にやったのは、実装ではなく仕分けでした。「この事業が成立するかどうかを決めるのは、どの機能か」を一つずつ問い直し、受注 → 配送指示 → 請求という最小の業務フローに絞り込みます。結果、10機能は核となる4機能に集約されました。残る6機能を捨てたわけではありません。「初期顧客が実際に使いはじめてから、必要性が確認できたものだけを作る」という順番に置き換えただけです。
体制はPdM1名とエンジニア1名。毎週の定例デモで軌道修正しながら、企画から3ヶ月で本番リリースに到達し、初期顧客3社への導入まで進みました。この会社には当時、内製のエンジニア組織がありませんでした。採用を待ってから着手していたら、市場機会そのものを逃していた可能性が高い案件です。
ここで強調したいのは、3ヶ月という期間も費用も、優れた実装スピードの結果ではなく、絞り込みという意思決定の結果だということです。10機能を3ヶ月で作る方法は存在しません。4機能に絞ったから3ヶ月で終わった。費用を下げる方法として、これ以上に効くものを私たちは知りません。
この事例は体制・期間・定量成果まで含めて実績ページに掲載しています(※スピンオフ元・衣株式会社(koromo)受託開発事業における実績)。他の事例も同じ構造で、最初に絞り込みの意思決定があります。
正しい方法2 — 段階見積りで、投資判断を区切る
もうひとつは、一度に全額を決めないことです。
私たちは、ディスカバリー(初期調査、1〜2週) → PoC(概念実証、4〜6週) → 要件定義(4〜8週) → 開発(3〜6ヶ月) → 内製化という段階に分け、フェーズごとに見積りをお出ししています。0→1のMVPではこれをさらに圧縮しますが、考え方は同じです。
この形の利点は、各フェーズの終わりが投資判断のポイントになることです。ディスカバリーの結果、「この仮説は筋が悪い」と分かったなら、そこで止められます。数百万円の学習コストで撤退できたなら、それは失敗ではなく、非常に安く買えた意思決定です。全額を先に確定させる契約では、この選択肢が構造的に失われます。
正しい方法3 — PoCを、最初の決裁材料にする
技術的な不確実性がある場合(外部システムとの連携が本当に可能か、AIの精度が業務に耐えるか、想定データ量をさばけるか)は、本開発の前にPoCを置くのが結果的に安上がりです。0→1のMVPでは2〜4週程度に圧縮することもあります。
不確実性を抱えたまま本開発に入ると、その不確実性はリスクとして見積りに乗ります。先に潰しておけば、乗せる必要がなくなります。加えて、PoCで動くものができていると、社内の決裁が驚くほど通りやすくなります。資料10枚より、動くもの1つのほうが速い。
正しい方法4 — 週次の意思決定枠を、着手前に押さえる
要因5で見た発注側の待ち時間は、裏を返せばスコープの次に効き、しかも追加費用ゼロで動かせる変数です。
やることは2つだけです。着手前に「毎週この曜日のこの30分は、決裁権のある人が必ず出る」という枠を確保すること。そして、仕様の疑問に何営業日で回答するかを決めておくこと。同じスコープ・同じ体制でも、これがあるかないかで期間は変わります。
間違った方法1 — 人月単価の安さだけで選ぶ
単価が半分の会社に頼めば費用が半分になる、とはなりません。総額は単価 × 人数 × 期間であり、単価が安い体制は往々にして人数と期間が増えるからです。
さらに見えにくいコストがあります。仕様の解釈がずれる、手戻りが増える、レビューに発注側の時間を取られる、リリース後の不具合対応に追われる。これらは見積書に載りませんが、確実に発生します。判断すべきは単価ではなく、「動くものが、いつ、どれだけの確からしさで手に入るか」です。
では単価でないなら何で選ぶのか。体制の実在性や、リリース後の引き継ぎ方といった開発会社の見極め方は、費用とは別の観点が必要になるため、別記事で改めて整理します。
間違った方法2 — 仕様を全部固めてから発注しようとする
「要件が固まっていないので、まだ相談できません」という声をよくいただきます。気持ちは分かりますが、これは費用を上げる方向に働きます。
社内だけで固めた要件は、実装可能性やコストの妥当性が検証されていません。「実はこの1機能に全体の3割の工数がかかっていた」といったことが、発注後に判明します。そして一度固めた要件は、心理的にも契約的にも動かしにくくなります。
コストの構造を知っている相手と一緒に要件を作ったほうが、結果として安く、速く終わります。私たちがRFPを必須にしていないのは、この理由です。
間違った方法3 — 相見積りで最安値に寄せる
相見積り自体は健全な手続きです。問題は、前提を揃えずに金額だけを比較することです。
同じ資料を渡しても、書かれていないリスクを織り込んで高めに出す会社と、書かれたことだけを最小限に見積もる会社に分かれます。最安値を選ぶと、その差は「書かれていなかった部分」としてすべて追加費用で後から現れます。
比較すべきは金額ではなく、前提の置き方です。「この見積りに含まれないものは何ですか」「増えるとしたらどこが増えますか」。この2問への答えの精度が、そのままその会社の実力を映します。
3ヶ月でリリースするスケジュールの分解
「最短3ヶ月」を、週単位に分解します。以下は前述の物流の事例を一般化したモデルで、案件によって前後します。
Week 1〜2 — ディスカバリー
検証したい仮説、対象ユーザー、成功の判定基準を言語化して合意します。ここで「何が確かめられたら成功か」を数字で決めておくことが、後の全判断の基準になります。
並行して、業務フローを1本書き切ります。前述のとおり、機能の箇条書きではなくフローです。このフェーズの成果物は、コードではなくスコープの合意です。
Week 3〜6 — 核となる機能の実装と、最初の動くもの
絞り込んだ核機能から着手し、3週目の終わりには何かしら動くものを触れる状態にします。画面遷移だけのプロトタイプでも構いません。触れるものがあると、議論の質が変わります。
技術的な不確実性がある場合は、この期間にPoCとして先に潰します。ここで見つかった問題は、まだ安く直せます。
Week 7〜11 — 本番品質への引き上げ
エラー処理、権限、データの整合性、運用ツールといった「地味だが必須」の部分を仕上げます。ここを削ると、リリース後に削った分を大きく上回る時間を対応に取られます。
毎週の定例デモは全期間を通じて回し続けます。10週目あたりで「やっぱりこの機能が必要」という話が出たときに、11週目に入れるのか、リリース後に回すのかを即断できるかどうかが、3ヶ月に収まるかどうかの分かれ目です。原則はリリース後に回す、です。
Week 12 — リリースと、学習の準備
本番環境へのリリースと、初期ユーザーへの導入。同時に、何をどう計測するかを仕込みます。MVPは学習のための道具なので、計測できていなければ意味がありません。
補足 — 3ヶ月に収まらないサイン
次のいずれかに当てはまる場合、3ヶ月は現実的ではありません。早めに認識を揃えておくべきです。
- 既存の基幹システムとのリアルタイム連携が必須
- 決済と請求のフルフローが初回リリースに必要
- 社内の複数部門にまたがる承認フローが仕様に含まれる
- 意思決定者が週次の判断に参加できない
- 対象業務そのものが未整理で、何を作るべきかが決まっていない
最後の項目は、実は3ヶ月に収まらない理由ではなく、ディスカバリーから始めるべき理由です。順序を変えれば進みます。
契約形態と支払いの設計
費用の話は、金額と同じくらい支払いの構造が重要です。ここを設計しないと、金額が妥当でもプロジェクトが苦しくなります。
一括請負のリスク
要件を確定させ、総額を固定して発注する形式です。発注側にとって予算が読みやすい一方、0→1のMVPとは相性がよくありません。
理由は単純で、MVPは「作りながら学ぶ」ことが目的だからです。学んだ結果として仕様を変えたくなるのは成功の証ですが、一括請負では仕様変更のたびに追加見積りと再交渉が発生します。「変更したいが言い出しにくい」空気が生まれ、学びが仕様に反映されなくなる。これはMVPとして本末転倒です。
準委任のリスク
稼働時間に対して支払う形式です。柔軟性は高いのですが、成果の定義がないまま時間だけが積み上がるリスクがあります。「何ができたら終わりなのか」が曖昧だと、発注側は費用対効果を判断できません。
なお私たちも、技術顧問・内製化支援では準委任で対応することがあります。時間を買う契約が適しているのは、成果物ではなく知見と併走が価値になる領域だからです。0→1のMVPでは、次に述べる検収基準を伴う形を基本にしています。
段階見積り + 検収基準 — リスクを1フェーズ分に限定する
私たちが基本としているのは、成果報酬型の請負契約です。ご請求は、事前に合意した検収基準を満たした成果に対してのみ発生します。加えて、前述の段階見積りでフェーズごとに投資判断を区切ります。
この2つを組み合わせると、発注側のリスクは「1フェーズ分」に限定されます。ディスカバリーだけを依頼して、進め方が合わないと感じたらそこで終える。それで構いません。実際、1〜2週間のディスカバリー単体からのご依頼も承っています。
2案件目以降の継続率は72%です(※スピンオフ元・衣株式会社(koromo)受託開発事業における実績)。これは契約で縛った結果ではなく、1フェーズ目の成果で判断していただいた結果だと考えています。
契約前に必ず握っておくべき3点
契約形態が何であれ、着手前に文書で握っておきたいのは次の3点です。
- 検収基準 — 何ができたら「完了」なのか。画面が表示されることか、実ユーザーが業務を1周回せることか。ここが曖昧だと必ず揉めます。
- 成果物の権利とソースコードの引き渡し — ソースコードの著作権が誰に帰属し、いつどう引き渡されるか。将来の内製化や開発会社の切り替えに直結します。
- リリース後の扱い — 不具合対応の範囲と期間、追加開発の単価。ここを決めずにリリースを迎えると、対応の一つひとつが交渉になります。
まとめ — 「いくら」の前に「何を検証するか」
MVP開発の費用は、人月単価 × 投入人数 × 期間という掛け算にほぼ還元されます。そしてこの3つを最も大きく動かすのは、発注側が握るスコープ、すなわち何を作らないかの意思決定です。
- MVPは廉価版ではなく、検証に必要な最小限。機能の幅は狭く、品質は本番と同水準
- 相場レンジは前提次第。確認すべきは総額より「何人 × 何ヶ月」と「何が含まれないか」
- 費用を左右する5要因は、機能数(=画面と状態の数)・認証と決済・管理画面・デザイン要件・発注側の体制
- 最も確実な打ち手は核機能への絞り込み。次に週次の意思決定枠の確保、そして段階見積りとPoC先行
- 単価の安さ・要件の先行確定・前提を揃えない相見積りは、いずれも総額を押し上げる要因
- 3ヶ月に収めるカギは、10週目以降の追加要望をリリース後に回す判断
- 契約前に文書化すべきは、検収基準・権利の帰属・リリース後の扱い
最後に、この記事の起点にあった問いに戻ります。「いくらかかりますか」への最も誠実な答えは、金額ではなく「何を検証したいか次第で、こう変わります」という構造の説明です。そして構造さえ共有できれば、金額はその場で概算まで出せます。
事業の構想段階で、まだRFPも固まった要件もない。そういう段階のご相談こそ、私たちの得意領域です。「何から手をつけるべきか分からない」「そもそも3ヶ月で作れるものなのか知りたい」といった粗い状態のままで構いません。お問い合わせフォームからご連絡いただければ、2営業日以内にご返信します。初回のご相談と概算のご提示は無償ですので、社内の検討材料としてお使いください。
