「見積もりを取ったら、想定の3倍の金額が出てきた」。中小企業の経営者からよく聞く話だ。なぜそうなるのか。費用の構造を理解していないと、見積もりを読む基準も、交渉の余地も見えてこない。
「システム開発はいくらかかるのか」という問いに対し、「それはケースバイケースです」という答えしか返ってこない状況は、発注者として不利だ。相場観がなければ、提示された金額が妥当かどうかを判断できない。ここでは費用の構造を分解し、規模別の目安と費用が膨らむ原因を整理する。
費用の構造を分解する
①要件定義・設計
システムを作る前に、「何を作るか」を決める工程だ。現状の業務をヒアリングし、課題を整理し、システムに落とし込む機能を決定する。設計では、画面の構成・データの持ち方・処理の流れを文書化する。
この工程を軽視する発注者は多い。しかし要件定義と設計が曖昧なまま開発に入ると、後から「やっぱりここを変えたい」が増え、最終的なコストが大きく膨らむ。投資額の15〜25%程度を要件定義・設計に使うことは、決して無駄ではない。
この工程が充実しているかどうかは、見積もりを見れば判断できる。要件定義・設計の工数が低く抑えられている見積もりは、後から変更費用が積み上がるリスクが高い。
②開発
実際にシステムを作る工程だ。エンジニアがコードを書き、画面を作り、データベースを構築する。費用全体の中で最も大きな割合を占める工程であり、機能の数・複雑さ・使用技術によって金額が変わる。
「追加機能」のコストは、単純に機能の数で計算できない。既存の構造に影響する変更は、新規開発より割高になることが多い。画面を1つ追加するだけに見えても、それに伴うデータ処理・既存機能への影響確認・テストが積み重なる。後から追加するより、最初の設計段階で必要な機能を整理しておくことが費用を抑えるポイントだ。
③テスト・修正
作ったシステムが正しく動くかを確認し、問題を修正する工程だ。テストを省略するほど、本番稼働後のトラブルが増える。「早く使いたい」という理由でテスト期間を短縮すると、稼働後の修正費用が積み上がることになる。
テストは「バグがないか確認する」だけではない。実際に業務で使うシナリオ通りに動かし、「現場の使い方で問題が起きないか」を確認する工程でもある。この観点でテストを行うには、現場スタッフのテスト参加が効果的だ。
④導入支援・教育
現場スタッフへのマニュアル作成、操作説明会、導入後のサポートが含まれる。中小企業の案件では省略されがちだが、定着率に直結する工程だ。スタッフが正しく使えなければ、システムは機能しない。
導入支援のコストを「節約できる部分」と考えると、稼働後に現場から「使い方がわからない」「こんな機能があったの知らなかった」というフィードバックが増える。最終的には経営者が対応に追われる時間が増え、節約したコストより高い代償を払うことになる。
⑤保守・運用
稼働後の継続費用だ。月額固定の場合と、都度対応の場合がある。法改正への対応、ブラウザ・OSのアップデートへの追従、不具合の修正が含まれる。「作ったら終わり」ではなく、長期にわたってコストが発生する。
見積もりに保守・運用費用が含まれていない場合、稼働後のトラブル対応が「都度見積もり・都度発注」になる。緊急対応が発生したときに費用交渉から始めることになり、解決までのタイムラグが業務影響を拡大させる。月額の保守契約はコストに見えるが、継続的な改善とトラブル対応の安心感を買うものだ。
規模別の費用目安
業務システムの規模を3段階に分けると、以下が目安になる。
小規模（機能3〜5つ程度、利用者10名以下）：50万〜200万円。顧客管理・案件管理・簡易帳票など、単機能または少数機能の組み合わせ。スモールスタートに向いており、必要に応じて機能を追加する設計が現実的だ。「まず最低限使えるものを作って、現場の反応を見ながら拡張する」という進め方が、小さな会社には合っている。
中規模（機能10前後、利用者10〜50名）：200万〜800万円。複数の業務をまたぐシステム、在庫管理・受発注管理・スケジュール管理など、業務フローと連動する設計が必要な案件。要件定義と設計に時間をかける必要があり、「何を作るかの整理」に数ヶ月かかることもある。
大規模（基幹業務全体、利用者50名以上）：800万円〜。会計・人事・製造・物流など基幹業務を統合するシステム。要件定義だけで数ヶ月かかることもある。中小企業がこの規模のシステムをゼロから作るケースは少なく、既存パッケージのカスタマイズで対応するほうが現実的なことが多い。
費用が膨らむ典型的な原因
見積もり通りに収まらない案件には、共通した原因がある。
最も多いのは「仕様変更」だ。開発中に「やっぱりここを変えたい」が増えると、その都度追加費用が発生する。要件定義を丁寧に行い、変更管理のルールを事前に決めることで、この原因は大幅に減らせる。変更を「ゼロにする」ことは難しいが、変更発生時の費用を予め合意しておくことで、争点をなくせる。
次に多いのは「要件の抜け漏れ」だ。業務の例外処理・特殊なルール・他システムとの連携が要件定義段階で漏れると、後から追加するコストが高くなる。発注者側が「言わなかった」という認識で、開発側が「聞かなかった」という認識のまま進むと、完成直前に発覚する。
また、「テストで発覚した問題の修正」も費用膨張の原因になる。開発中に発見できなかった問題がテスト段階で出ると、設計に戻って修正する工数が発生する。テスト工程を後半に詰め込むほど、修正のコストが上がる。
予算を守るための発注者側の準備
費用をコントロールするために発注者ができることは、主に3つある。
一つ目は、「作るものの優先順位を決める」ことだ。全機能を一度に作ろうとするから費用が膨らむ。まず最低限必要な機能（MVP）を決め、優先度の高いものから順に作る設計にすることで、初期費用を抑えられる。機能を削ることは妥協ではなく、リスクを管理する判断だ。
二つ目は、「変更管理のルールを契約に盛り込む」ことだ。どの規模の変更から追加費用が発生するかを明示した契約にすることで、後からの費用交渉トラブルを防げる。「小さな変更」の定義を双方で合意しておくことが重要だ。
三つ目は、「複数社から見積もりを取って比較する」ことだ。1社だけの見積もりでは相場が判断できない。同じ要件を複数社に見積もらせることで、適正価格の感覚をつかめる。金額だけでなく、見積もりの内訳の詳しさ・変更対応の方針・保守サポートの範囲を比較することが、選定の精度を上げる。
費用の構造を理解することは、発注者が対等な立場で交渉するための前提だ。「高い」「安い」ではなく、「この費用の内訳は何か」「このコストが発生する理由は何か」を問える発注者が、最終的に後悔の少ない結果を得ている。
「安い見積もり」のリスクを知っておく
複数社の見積もりを比較すると、金額に大きな差が出ることがある。「なぜこんなに安いのか」という問いを、安い見積もりを提示した会社に対して必ず投げかけるべきだ。
安さの背景には、要件定義を省略している・テスト工程が薄い・保守を含んでいない・実績の少ない会社が受注するために価格を下げている、などの理由がある場合がある。安い見積もりは、稼働後の追加費用で最終的に高くなることがある。
見積もりの比較は金額だけでなく、「なぜこの金額なのか」という根拠の確認を含めることで、発注判断の質が上がる。