「設計一式150万、開発一式400万、テスト一式80万」——業務システム開発の見積もり書を見ても、何にいくらかかっているのかが「一式」の壁に阻まれて見えてこない、という経営者の声をよく耳にします。本記事では、500万・1,000万・1,500万のレンジごとに、業務システム開発費の内訳を業界の実態に即した粒度で全部開示します。読み終える頃には、見積もり書の「一式」の裏側で何が起きているかが具体的に見える状態になります。
この記事の結論（3行）
- 業務システム開発費は「設計20%・開発40%・テスト15%・PM10%・運用10%・予備5%」が標準的な内訳目安
- 1,000万円の案件で純粋にコードを書く作業に振り向けられる金額は400万円程度、残り600万円は組織と保険料
- 内訳を項目別に開示できる会社ほど、契約後の追加請求が少なく、結果としてトータルコストも下がる
業務システム開発費は何で構成されているのか
業務システム開発費は、大きく6つの項目で構成されています。見積もり書に「一式」と書かれていても、内訳としてはこの6項目に必ず分解できる構造です。
- 要件定義・設計フェーズ
- 開発（コーディング）フェーズ
- テスト・品質保証フェーズ
- プロジェクト管理（PM）費用
- 導入・運用支援費用
- 予備工数（リスクバッファ）
6項目の比率は、業界の標準値で「設計20%・開発40%・テスト15%・PM10%・運用10%・予備5%」というレンジに収まる構造です。逆に言えば、この比率から大きく外れた見積もりには、構造的な歪みが潜んでいる可能性があります。例えば「開発70%・設計5%」のような偏った内訳は、要件定義を軽視した結果、後工程で問題が頻発するパターンに陥りがちです。
要件定義・設計フェーズ（総額の20%目安）
業務システム開発の最初のフェーズで、業務フローのヒアリング・データ項目の整理・画面設計・データベース設計を行います。1,000万円の案件であれば150〜250万円が振り向けられる項目で、ここの工数を削ると後工程の修正コストが跳ね上がる構造です。要件定義に十分な時間を確保している見積もりほど、最終的な総額が見積もり通りに収まる傾向にあります。
開発（コーディング）フェーズ（総額の40%目安）
実際にコードを書く工程で、フロントエンド・バックエンド・データベース・API連携などの実装が含まれます。総額に対する比率としては最も大きい項目ですが、6割を切る案件も珍しくありません。1,000万円の案件でこの項目が400万円を切る場合、組織の間接コストや中間マージンが標準より大きく乗っている構造を疑ってよいでしょう。
テスト・品質保証フェーズ（総額の15%目安）
開発完了後の単体テスト・結合テスト・運用テストを行う工程です。1,000万円の案件であれば100〜200万円が割かれます。テスト工程を軽視すると納品後のバグが頻発するため、削減対象として最後に手を付けるべき項目になります。AI駆動開発を採用している会社では、テスト自動化により工数を半減できる構造があります。
プロジェクト管理（PM）費用（総額の10%目安）
プロジェクトマネージャーの稼働費用で、進捗管理・課題管理・関係者調整・週次定例の運営などが含まれます。組織規模が大きい会社ほどこの比率が高くなり、大手SIerでは15〜20%まで上がる構造です。逆に、小規模専門会社では経営者が兼任することで5%以下に抑えられるケースもあります。
導入・運用支援費用（総額の10%目安）
納品時のデータ移行・初期設定・運用マニュアル作成・現場研修などが含まれます。1,000万円の案件で80〜120万円が割かれる項目です。ここが空欄の見積もりは、納品後に「別途お見積もり」として追加請求が発生する構造を内包しています。
予備工数（リスクバッファ、総額の5〜20%）
「あとから仕様変更が発生するかもしれない」という保険料です。要件が固まっていない案件ほどベンダー側はこのバッファを多めに積み、20〜30%まで膨らむ場合もあります。1,000万円の案件で200万円のバッファが乗っている見積もりは、要件定義を強化することで100万円以下に圧縮できる余地があります。
レンジ別の内訳目安（500万・1,000万・1,500万）
業界の標準的な見積もり構造を、3つのレンジで具体的な金額に落とし込んだ目安を整理します。手元の見積もり書と照らし合わせることで、項目別の妥当性が判断しやすくなります。
| 項目 | 500万円案件 | 1,000万円案件 | 1,500万円案件 | |---|---|---|---| | 要件定義・設計 | 80万円 | 180万円 | 280万円 | | 開発（コーディング） | 220万円 | 400万円 | 600万円 | | テスト・品質保証 | 70万円 | 150万円 | 220万円 | | プロジェクト管理 | 40万円 | 100万円 | 180万円 | | 導入・運用支援 | 50万円 | 100万円 | 150万円 | | 予備工数 | 40万円 | 70万円 | 70万円 | | 合計 | 500万円 | 1,000万円 | 1,500万円 |
純粋な開発作業（コーディング）の比率を見ると、500万円案件で44%、1,500万円案件で40%という構造になります。総額が上がっても、コーディング比率はむしろ下がる傾向にある——つまり、高額案件ほど「コードを書く以外」の比率が膨らむ構造です。手元の見積もりの項目別比率を確認したい場合は、業務改善・システム見積もりAI適正診断で内訳を整理できます。
内訳開示を求めた時の3つの反応パターン
ベンダーに「項目別の内訳を出してください」と依頼した時の反応は、おおむね3つのパターンに分かれます。反応そのものが、各社の透明性と契約後の安心感を測る指標になります。
- パターンA：項目別の金額を即日で開示する
- パターンB：項目別開示を渋り、「一式」で答え続ける
- パターンC：開示はするが、根拠を聞くと曖昧になる
3パターンのうち、安心して発注できるのはAだけです。BとCは契約後に追加請求や工数増加が発生するリスクが高い構造を持ちます。
パターンA：項目別の金額を即日で開示する
「設計150万・開発400万・テスト150万・PM100万・運用80万・予備70万」のように、即日で項目別の金額を提示できる会社は、社内で工数管理が標準化されている構造を持ちます。こうした会社は、契約後の追加請求が少なく、最終的なトータルコストも見積もり通りに収まる傾向にあります。
パターンB：項目別開示を渋り、「一式」で答え続ける
「総額で○○万円です、内訳は社内ルールで開示できません」と答える会社は、見積もり書の根拠が曖昧な構造を持っています。発注後に「追加で○○の作業が発生したため、追加でお見積もり」というやり取りが頻発するリスクが大きいパターンです。
パターンC：開示はするが、根拠を聞くと曖昧になる
「設計150万」と書かれているが、「なぜ150万なのか」を聞くと「業界相場から逆算しました」「過去案件の平均値です」のように曖昧な答えが返ってくるパターンです。項目別の金額が「過去案件の平均値」で決まっている場合、自社の案件の特性が反映されていない構造を持ちます。
経営者目線で考える「内訳開示の本質」
ここからは、技術論ではなく経営の話です。内訳開示を求める本質は、金額交渉のためではなく、「自社の業務を理解してくれているベンダーかどうか」を確認することにあります。項目別の金額を即答できる会社は、自社の業務をある程度の粒度で読み取った上で見積もりを組んでいる構造を持ちます。逆に、「一式」でしか答えられない会社は、自社の業務の特性が見積もりに反映されていない可能性が高い状態です。
中小企業の経営者として、内訳開示で見るべきポイントは3つです。第一に、業務の複雑度に対して設計フェーズの金額が妥当か。複雑な業務で設計が総額の10%しかない見積もりは、要件定義を軽視している証拠と読み取れます。第二に、運用フェーズが空欄になっていないか。納品後の不安を見積もりに含めていない会社は、納品後の対応も同様に手薄になりがちです。第三に、予備工数が過大になっていないか。総額の20%を超える予備は、要件定義を強化することで圧縮できる構造があります。
業界の標準では、項目別の内訳を「一式」で済ませる文化が10年以上続いていますが、これは業界の利益構造を守るための慣習に近い側面があります。買う側が項目別に質問し続けることで、徐々に内訳開示が標準化されていく流れも生まれつつあります。経営者として「内訳を見せてください」と当たり前に言える発注力こそが、業界の透明性を上げる第一歩になります。手元の見積もりを内訳の観点で見直したい場合は、業務改善・システム見積もりAI適正診断で項目別の妥当性を整理できます。
ぷらすわんの実例：AI-SAKU開発費の完全開示
弊社が手掛ける「AI-SAKU」というWordPress×AI記事生成SaaS（市場相場700〜1,500万円を500万円で開発）について、実際の開発費の内訳を可能な範囲で開示します。同等機能のSaaSと比較するための参考値として、業界の透明性向上に資する目的で公開する事例です。
| 項目 | AI-SAKU実費 | 業界標準（1,000万円案件） | |---|---|---| | 要件定義・設計 | 60万円（12%） | 180万円（18%） | | 開発（コーディング） | 250万円（50%） | 400万円（40%） | | テスト・品質保証 | 50万円（10%） | 150万円（15%） | | プロジェクト管理 | 30万円（6%） | 100万円（10%） | | 導入・運用支援 | 50万円（10%） | 100万円（10%） | | 予備工数 | 20万円（4%） | 70万円（7%） | | 中間マージン・間接費 | 40万円（8%） | 0万円（自社で吸収済） | | 合計 | 500万円 | 1,000万円 |
業界標準との差額500万円が、どの項目で生まれているかが具体的に見えます。設計と開発の比率を維持しつつ、PM・テスト・予備工数を圧縮できた理由は、Claude Codeを活用したAI駆動開発でテスト自動化と設計支援を実現したこと、自社エンジニアだけで完結する組織形態で中間マージンをゼロにしたこと、Next.js 16+Supabase+Stripeという既存サービスの組み合わせで開発範囲を最小化したこと——この3点に集約されます。経営者として得た学びは、内訳を開示することで「安さの構造」が他社にも参照可能な情報として共有できる、という点です。手元の見積もりを構造で読み解きたい方は、現在の見積もりを診断することで、AI-SAKU実費との比較が可能になります。
見積もり書から内訳を読み解く4つの質問
最後に、ベンダーから提示された見積もり書に対し、内訳を読み解くために投げかけたい4つの質問を整理します。
- 質問1：項目別の金額を出してください
- 質問2：人月単価はいくらですか
- 質問3：予備工数の根拠を3行で説明してください
- 質問4：運用フェーズの想定金額はいくらですか
4つの質問は、いずれも見積もり書を見るだけでは答えが出ない項目です。ベンダーに直接質問することで、各社の透明性と契約後の安心感が具体的に比較できます。
質問1：項目別の金額を出してください
「設計・開発・テスト・PM・運用・予備」の6項目で金額を分解してください、と依頼します。即日で出せる会社は工数管理が標準化されている証拠、出せない会社は契約後の追加請求リスクが高い構造を持ちます。
質問2：人月単価はいくらですか
業界の人月単価相場は、フリーランス・小規模会社で60〜80万円、中堅Web開発会社で80〜120万円、大手SIerで150万円〜という目安です。即答できないベンダーは、契約後の追加工数請求が青天井になりがちな構造を持っています。
質問3：予備工数の根拠を3行で説明してください
「○○の要件があいまいなため○○人月のバッファを置いている」と項目別に答えられる会社は、見積もりの精度が高い構造を持ちます。「リスクバッファ20%」のような曖昧な答えしか返ってこない場合、その金額は値下げ交渉の余地が大きい部分です。
質問4：運用フェーズの想定金額はいくらですか
サーバー代月3万円・保守費月5万円・年間の小規模改修50万円というように、運用フェーズの想定金額を3年分で答えられるベンダーは、納品後の責任範囲を明確に持っている構造です。空欄や「別途お見積もり」で済まされる場合、3年トータルで予想外のコストが発生するリスクが大きい状態です。手元の見積もりを4つの質問で整理したい方は、他社見積もりとの比較を依頼することで、内訳の透明性を可視化できます。
まとめ
業務システム開発費の内訳は、「設計20%・開発40%・テスト15%・PM10%・運用10%・予備5%」が業界の標準的な構造です。1,000万円の案件で純粋にコードを書く作業に振り向けられる金額は400万円程度、残り600万円は組織と保険料に消えていきます。経営者として大事なのは、見積もり書の「一式」を「項目別」に分解してもらうことから始め、各項目の比率と根拠を質問する発注力を持つことです。次に取るべき1ステップは、現在手元にある見積もり書を見て、「設計・開発・テスト・PM・運用・予備」の6項目で内訳が書かれているかを確認することになります。書かれていなければ、ベンダーに「項目別で出してください」と依頼するだけで、相見積もりの精度が一段上がります。質問の整理に迷う場合は、現在の見積もりを診断することで、聞くべき項目の優先順位を整理できます。