目次
「まず小さく作って、試してから考えたい」——最近、この形のご相談が増えています。新規事業の検証、社内業務の置き換え、既存サービスの一部だけ先に作る。いずれも共通して聞かれるのが「それ、いくらぐらいでできますか」です。正直にお答えすると、MVP（検証のための最小構成のシステム。PoCと呼ばれることもあります）は、通常の開発よりも小さく収めたいところです。必要なもの次第では数十万円規模で収まることもありますし、生成AIを活用することで、以前より短く・安く対応できるケースも増えています。逆に、削らないまま進めれば、検証のはずが本開発と変わらない金額になってしまいます。その差を生むのは規模ではなく、何を削ったかです。この記事では、その削り方をお話しします。
「まず小さく作って試したい」という相談が増えている
ご相談の前に、ご自分で相場を調べてこられる方が多いのですが、たいてい答えが出ないまま来られます。無理もありません。「MVP開発の費用相場」を調べると、安いほうは十万円台から、高いほうは数千万円まで、書かれている金額が会社ごとにまったく違います。桁が2つ以上違う数字が並んでいるので、自分のケースがどこに当たるのか判断できません。どの会社も嘘を書いているわけではなく、前提にしている案件がそれぞれ違うだけです。裏を返せば、MVPの費用は「相場」という一つの数字では表せないということです。
検証フェーズのご相談には、はっきりした共通点があります。ご依頼をいただく時点で、すでに「全部は作らない」と決めている方が多いのです。使う人を一部に絞る、対応範囲を狭くする、便利機能は後回しにする。そうやって自分たちで削ったうえで、「この範囲ならいくらか」を聞いてこられます。
これは良い傾向です。というより、検証フェーズの見積は、削ったあとでないと出せません。「一通り全部入りで」というご要望のまま見積を出すと、金額は跳ね上がり、検証を始める前に企画そのものが止まります。実際に止まってしまった企画を、私たちは何度も見てきました。
ですから最初にお伝えしたいのは、費用を下げる主導権は発注者側にもある、ということです。開発会社に値切り交渉をするより、何を削るかを決めるほうが、金額へのインパクトは桁違いに大きいのです。
MVPの費用は、機能の数では決まらない
よくある誤解が「機能を10個から5個に減らせば、費用は半分になる」というものです。実際にはそうなりません。機能の数と費用は比例しないからです。
費用を大きく動かすのは、機能の数ではなく次のようなものです。扱うデータがどれだけ複雑か。関わる立場（ロール）が何種類あるか。外部のサービスや既存システムとどれだけつながるか。そして——これが一番大きいのですが——作る前にどれだけ決まっているかです。
決まっていないものを決めながら作ると、作り直しが発生します。作り直しは、最初から作るより高くつきます。検証フェーズで費用が膨らむ最大の原因は、機能の多さではなくこの決まっていなさです。だからこそ、削るという行為が効いてきます。削るというのは、機能を捨てることではなく、決めなければならないことの数を減らすことだからです。
機能を3つに分ける──最小構成に入れるのは「作らなければならない機能」だけ
では、どう削るのか。アクシアがお客様にお伝えしている分け方は、とてもシンプルです。機能を次の3つに分類してください。
両端の判断は難しくありません。作らなくて良いものは作らない。業務が成り立たないものは必ず作る。迷いは生じません。問題は真ん中の「作った方が良い機能」です。これがないと業務が回らないわけではないけれど、あると便利だろうな、という温度感のもの。検証フェーズの見積が膨らむ原因は、ほぼここに集中しています。
アクシアの結論は明快です。「作った方が良い機能」は、作らない方が良い。絶対に作った方が良いと明確に判断できるもの以外は、初期開発に入れないことをお勧めしています。理由は、実際に運用してみると使わなくなる機能が本当に多いからです。検討段階では必要に思えたのに、使ってみたら要らなかった。これは検討が甘いからではなく、使ってみないと分からないことが世の中にはたくさんあるからです。この考え方の詳しい理由は「システムでは「作った方が良い機能」は作らない方が良い理由」に書いています。
逆に言えば、何でも最初から作りましょうと提案してくる開発会社は、全く信用できないと思って良いでしょう。機能をたくさん作ってもらったほうが、その時点だけを見れば開発会社は儲かりますからね。本当は必要のない機能まで含めて何でも作りましょうと言ってくる会社は、顧客のことなど考えていません。考えているのは自分たちの売上のことだけです。発注者に残るのは、使わない機能に払ったお金と時間、そしてそのぶん遅れた運用開始です。
スモールスタートで削れるのは、機能だけではない
機能を分類してもまだ予算に収まらないとき、多くの方は機能をさらに削ろうとします。しかしスモールスタートで削れるものは機能だけではありません。機能以外に削れるものがあり、そちらのほうが痛みが少なく効果も大きいことが少なくありません。次の3つです。
1つめは、対象を絞ることです。 全社ではなく1部署だけ。全国ではなく1拠点だけ。全言語ではなく1言語だけ。全ユーザー種別ではなく1種別だけ。検証の目的が「この仕組みが機能するかを確かめること」なら、対象を狭めても検証は成立します。そして対象を絞ると、考慮すべき例外パターンが一気に減ります。費用に効くのは機能の数ではなく例外の数なので、これは効きます。
2つめは、自動化を諦めることです。 自動で振り分ける、自動でおすすめする、自動で通知する——こうした賢い挙動は、作るのに手間がかかるわりに、検証段階では「本当にその判断ロジックが正しいのか」自体が分かっていません。最初は人が手で振り分ける運用にしておき、実際のデータが溜まってから自動化する。この順番のほうが、安く、そして正しく作れます。
3つめは、作らずに済ませることです。 既製のサービスで足りる部分は、そちらを使う。管理画面を作り込まず、当面は運用側で直接データを見る。帳票は既存の表計算ソフトに出力するだけにする。「作らない」は、費用を減らす手段としてはもっとも強力です。
「作った方が良い」に見えて、実は「作らなければならない」もの
ここまで削る話をしてきましたが、削ると後で高くつくものもあります。厄介なのは、それらが一見「作った方が良い機能」に見えることです。検証フェーズだからと外してしまい、本番化のタイミングで作り直しになる——これが一番もったいないパターンです。
私たちが「これは「作らなければならない機能」の側に入れてください」とお伝えしているのは、次のようなものです。
- 誰がログインし、誰が何を見られるのか——後から権限の考え方を変えると、画面もデータの持ち方も作り直しになります
- 個人情報をどこに置き、誰が触れるのか——検証段階でも、実在の人のデータを扱うなら本番と同じ配慮が要ります
- 誰がいつ何をしたかの記録——トラブルが起きたときに、記録がないと原因を追えません。後から遡って記録することはできません
- お金に関わる数字の扱い——金額や取引の記録は、間違いが許されないうえに、あとから直すのが最も難しい部分です
共通しているのは、「あとから足せない」か「足すと全体を作り直すことになる」ものだという点です。逆に、画面の見た目、便利なショートカット、細かい検索条件、集計レポートなどは、あとから足しても土台は揺れません。あとから足せるかどうか——これが、削ってよいかどうかを見分ける実務的な基準です。
生成AIで、工数はどこまで圧縮できるのか
「生成AIを使えば安くなりますよね」というご質問も増えました。実際、私たちは開発の現場で生成AIを日常的に使っており、以前より速く作れるようになった部分は確実にあります。既存コードの解析、定型的な実装、テストの下準備、ドキュメントの整備——こうした作業は明確に短縮できます。
一方で、正直にお伝えしておきたいことがあります。AIで圧縮できるのは「作る」時間であって、「決める」時間ではありません。何を作るべきかを決める、業務の例外を洗い出す、関係者の意見を揃える。検証フェーズのプロジェクトで時間を食うのは、たいていこちら側です。ここが決まらないまま作り始めれば、AIを使っていても作り直しは発生します。
ですから「AIで何割安くなります」という言い方を、私たちはしません。案件によって、AIが効く部分の比率がまったく違うからです。見積の段階で、どこにAIが効いてどこは効かないのかを具体的にご説明します。生成AIを業務システムそのものに組み込むご相談も、あわせて承っています。
小さく作ったあと、どう育てるか
検証フェーズの話をするとき、初期費用だけに目が行きがちですが、MVPは作って終わりではありません。むしろ、小さく作る意味は「早く使い始めて、そこから学ぶこと」にあります。実際にうまくいっている会社ほど、初期開発はあっさり終わらせて、そのあとの改善を頻繁に回しています。
そのため私たちは、初期開発を最小限に抑えたうえで、そのあとを月額の定額で伴走する形をご提案することが多くなっています。大きな一括の見積を一度きり出すより、小さく始めて必要なぶんだけ積み上げていくほうが、発注者にとっても私たちにとっても健全だと考えているからです。
費用のより具体的な目安については「システム開発の費用相場は？見積書の見方と、AIで費用を抑える考え方」と料金ページをご覧ください。また、いきなり開発を発注するのではなく要件定義だけを先に依頼するという進め方もあります。オーダーメイドで作ることそのものについては「スクラッチ開発を理解する」もあわせてどうぞ。
まとめ
MVP・検証フェーズのシステム開発費用について、お伝えしたかったことをまとめます。
- 費用は機能の数ではなく、何を削ったかで決まる。削る主導権は発注者側にもある
- 機能は3つに分け、初期開発に入れるのは「作らなければならない機能」だけにする
- 機能以外にも削れるものがある——対象を絞る・自動化を諦める・作らずに済ませる
- ただしあとから足せないもの（権限・個人情報・記録・お金）は削らない。ここを削ると作り直しになる
- 生成AIで圧縮できるのは「作る」時間。「決める」時間は圧縮できない
システムは、小さく生んで大きく育てる。これが検証フェーズにおける、もっとも効率的で、もっとも失敗しにくい進め方です。
「この範囲ならいくらぐらいか」「そもそもうちのケースで受けてもらえるのか」——こうした最初の一問だけでも構いません。削り方のご相談からでもお受けしますので、お気軽にお声がけください。