MVP開発の費用は「条件」を決めるまで比べられない
MVP開発の費用は、一つの金額では示せません。MVPという言葉が指す範囲が案件ごとに違うためです。画面が数枚の予約受付と、複数の利用者区分があり既存システムとつながる業務サービスでは、同じMVPでも作業の量がまったく違います。
そのため、この記事では市場の相場は示しません。代わりに、費用を動かす条件を五つに分け、それぞれ何を決めれば見積もりが安定するのかを説明します。最後に、Otsumu自身の参考価格を、自社の情報として記載します。
費用を動かす条件は次の五つです。
- 機能数と画面数
- 外部連携
- 権限と利用者区分
- セキュリティ要件
- 公開後の運用
機能数と外部連携は、流れと例外の数で見る
機能数と画面数。費用にもっとも直接的に効くのは、作る機能と画面の数です。ただし、数えるべきなのは機能の名前の数ではなく、利用者の操作の流れと、その例外の数です。「予約ができる」という一つの機能でも、変更、取り消し、重複の防止、締め切り後の扱いを含めるかどうかで、作業の量は変わります。
見積もりを依頼するときは、機能の一覧よりも、利用者が価値を得るまでの流れを一本書き、どの例外まで対応するかを添えるほうが、受ける側は正確に見積もれます。管理者側の画面も忘れやすい部分です。顧客向けの画面だけを数えていて、運営者がデータを確認・修正する画面が抜けていると、後から追加になります。顧客が少ないうちは、管理画面を作らず、開発者がデータを直接確認する運用で代用する選択もあります。
外部連携。決済、認証、メールや通知の送信、地図、既存の業務システムとのデータ連携などです。連携は、一つごとに調査、実装、異常時の処理、試験が必要になり、相手側の仕様や審査の日程に左右されます。費用だけでなく期間の不確かさも増やす要素です。
MVPの段階では、次の順で検討します。
- その連携がないと、仮説を確かめられないか。
- ファイルの受け渡しや手作業での転記で代用できないか。
- 連携する場合、相手側の仕様書と試験用の環境は手に入るか。
既存の業務システムと連携する場合は、社内の担当部門の協力が得られる時期も、見積もりの前提になります。
権限とセキュリティ要件は、対象と扱う情報で決まる
権限と利用者区分。利用者の種類が増えるほど、費用は増えます。一般の利用者と運営者の二種類であれば単純ですが、組織の管理者、部門の担当者、閲覧だけの人、のように区分が増え、誰が何を見られて何を変えられるかが細かくなると、設計と試験の量が増えます。法人向けのサービスでは、顧客の組織ごとにデータを分けて見せる仕組みが必要になり、これも費用に効きます。
MVPでは、対象の顧客を絞ることで区分を減らせないかを先に考えます。たとえば、最初の対象を小規模な組織に限れば、部門ごとの権限は不要にできる場合があります。
セキュリティ要件。扱う情報の種類と、顧客や社内から求められる基準で決まります。個人情報や機密性の高い情報を扱う場合、あるいは顧客が法人で、導入前に安全性の確認を求められる場合は、通信や保存時の保護、操作の記録、脆弱性の検査、運用の手順書などが必要になります。
ここは、MVPだからといって一律に削れる部分ではありません。削ってよい範囲は扱う情報によって変わります。まず、MVPで扱う情報を最小限にできないかを考えます。取得しない情報は守る必要がありません。考え方はMVPの公開前に権限・復旧・連絡を実際に試す方法を参照してください。社内に情報セキュリティの審査がある場合は、その基準を見積もりの前に入手し、依頼先に渡します。
公開後の運用をどこまで含めるか
見積もりの比較で見落とされやすいのが、公開した後の費用です。MVPは公開してからが本番であり、使われ方を見て直す期間がなければ、作った意味が薄れます。次の点を、開発の見積もりに含めるのか、別にするのかを確認します。
- 公開後の不具合対応と、小さな改善の期間と範囲
- 利用状況を計測する仕組みと、その結果を見る場
- クラウドや外部サービスの利用料（誰の名義で契約し、誰が支払うか）
- 障害が起きたときの連絡先と対応時間
- 引き継ぎ。設計の資料、プログラム、各種の管理権限を、どの形で受け取るか
とくに引き継ぎは、検証の後に自社で開発を続ける場合や、別の会社に依頼する場合に効いてきます。受け取るものが決まっていないと、次の段階で作り直しに近い費用がかかることがあります。契約面での確認点は開発契約を変更と引き継ぎまで含む運用ルールにする考え方にまとめています。
見積もりを比べる前に、条件をそろえる
複数の会社から見積もりを取ると、金額に大きな差が出ることがあります。その差は、単価の違いよりも、各社が想定した範囲の違いから生まれている場合があります。条件が曖昧な依頼に対しては、ある会社は最小限を想定し、別の会社は安全を見て広めに想定するためです。
比べられる見積もりを得るには、依頼書に次の内容を書きます。
- 確かめたい仮説と、対象の顧客
- 利用者が価値を得るまでの流れと、対応する例外の範囲
- 今回は作らないもの、人の手で代用するもの
- 外部連携の有無と、相手側の情報
- 利用者区分と権限
- 扱う情報の種類と、求められるセキュリティの基準
- 公開後に含めたい支援と、引き継ぎで受け取りたいもの
- 希望する時期と、予算の目安
- 見積もりに書いてほしい内訳と、前提にした条件
最後の項目が重要です。前提にした条件を各社に書いてもらうと、金額の差がどこから来ているのかを読み取れます。依頼書の作成には、無料のMVP見積依頼書テンプレートも使えます。依頼先の比べ方は見積もりを比べる前に発注の条件をそろえる方法でも扱っています。
よくある質問
Q. 予算の目安は、依頼先に伝えたほうがよいですか。
伝えることをおすすめします。目安が分かれば、依頼先はその範囲で仮説を確かめられる構成を提案できます。伝えない場合、範囲の違う提案が並び、比べにくくなります。伝えたうえで、その金額で何を作り、何を作らないのかを明示してもらってください。
Q. もっとも安い見積もりを選ぶと、何が起きやすいですか。
安いこと自体は問題ではありません。確認すべきは、安い理由です。想定した範囲が狭い、公開後の対応が含まれていない、引き継ぎの資料がない、といった理由であれば、後から追加の費用が発生します。前提にした条件を並べて比べ、同じ範囲にそろえたうえで判断します。
Q. ノーコードの道具を使えば、費用は下がりますか。
下がる場合があります。画面と処理が単純で、連携や権限の要件が軽いMVPには向いています。一方、要件が道具の得意な範囲を超えると、かえって手間が増えます。検証の後にどう移行するかも含めて判断してください。詳しくはノーコードMVPを検証後に困らない形で組み立てる方法を参照してください。
Otsumuに相談できること
ここからは相場ではなく、Otsumu自身の参考価格です。PoC / MVP Sprintは税別300万円〜で、6週間を目安に設計します。300〜800万円程度を検討の目安とし、機能数・外部連携・セキュリティ要件で変動します。クラウド利用料等は別途です。成果物は、検証目的・機能範囲の合意、主要画面と利用シナリオ、検証用のPoC / MVPシステム、効果測定の項目・計測設計、公開・運用に向けた引き継ぎ、検証結果と次フェーズの改善方針です。公開後も継続して支援する場合は、月額50〜150万円程度（税別）を参考に、体制と支援範囲に応じて個別に見積もります。いずれも正式な見積もりは相談後にお出しします。契約・検収の条件や成果物の取り扱いは、相談時に確認のうえ合意します。
依頼書を自社で書け、比べる観点も定まっているなら、相談は不要です。条件のどこが決まっていないのかを整理したい場合は、30分の無料診断をご利用ください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。記載の価格はOtsumuの税別・参考価格で、正式なお見積もりはご相談後にご案内します。法務・税務・会計・補助金などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.09.21