# システム開発予算の決め方｜発注前の算定手順 - 公開日: 2026-08-22 - 監修: 代表取締役 兼 StockSun創業メンバー 板橋 晟星 - URL: https://www.geek-bridge.com/column/system-development-budget-planning システム開発の予算は、開発費だけでなく、要件整理・データ移行・外部サービス・運用保守・社内工数・予備費まで含めて決めます。要件が曖昧な段階では確定額にせず、予算幅と前提条件を設定し、企画・要件定義・開発の節目で更新するのが現実的です。 ## システム開発予算は「初期費用＋運用費＋予備費」で考える システム開発の予算を決めるときは、制作物そのものの価格だけでなく、導入して使い続けるための総費用を捉える必要があります。発注前の基本式は次のとおりです。 **必要予算＝初期費用＋運用費＋社内対応コスト＋予備費** 初期費用には、企画、要件定義（＝作るものを決める工程）、設計、開発、テスト、データ移行、導入支援などが含まれます。運用費は、クラウド利用料、外部サービス利用料、監視、問い合わせ対応、障害対応、軽微な改修などです。 発注のご相談を受ける開発会社の立場から見ると、「開発に1,000万円使える」という情報だけでは、適切な提案はできません。同じ1,000万円でも、初期開発だけの予算なのか、初年度の保守費やクラウド費を含むのかによって、実装できる範囲が変わるためです。 ### 予算の対象範囲を最初に統一する 社内稟議や開発会社への相談では、少なくとも次の区分を明記しましょう。 |予算区分|主な内容|見落としやすい項目| |---|---|---| |企画・要件整理|業務調査、課題整理、要件定義、画面・業務フローの整理|現場ヒアリング、既存資料の分析| |設計・開発|画面設計、システム設計、実装、テスト|管理画面、権限管理、例外処理| |導入・移行|データ移行、操作説明、マニュアル、公開作業|データの名寄せや修正、並行稼働| |外部利用料|クラウド、SaaS、API、ドメイン、証明書|従量課金、最低利用期間| |運用保守|監視、障害対応、問い合わせ、アップデート|夜間休日対応、OSなどの更新対応| |社内コスト|会議、確認、受け入れテスト、教育|部門責任者や現場担当者の工数| |予備費|追加調査、仕様変更、想定外のデータ対応|見積もり済みのリスク費との重複| 特に注意したいのが、外注費に現れない社内コストです。システム開発では、発注側にも業務ルールの説明、仕様確認、テスト、承認などの作業が発生します。担当者が通常業務と兼任する場合は、開発の遅延や残業の増加も考慮しなければなりません。 ### 初期費用ではなく3年程度の総保有コストを見る 比較時には、TCO（Total Cost of Ownership＝導入後を含む総保有コスト）を確認します。たとえば、初期費用が安くても、月額利用料や改修費が高ければ、数年後には別案より総額が大きくなることがあります。 社内の予算表には、次のような形で年度別に記載すると判断しやすくなります。 - 初年度：企画、開発、移行、初年度の保守・利用料 - 2年目：保守、クラウド、ライセンス、追加改修 - 3年目：保守、利用料、機能拡張、更新対応 - 将来費用：データ増加、利用者増加、外部サービスの料金改定への備え 売上に直結するサービスであれば、障害時の機会損失や問い合わせ対応コストも検討対象です。一方、社内システムの場合は、作業時間の削減、入力ミスの減少、既存ツールの解約などを効果として整理します。 ## 開発費用・期間の相場は規模と不確実性で変わる システム開発費は、画面数や機能数だけでなく、既存業務の複雑さ、外部連携、データ移行、セキュリティ、利用者数、求める可用性によって変わります。そのため、発注前の相場は予算枠を検討するための参考値として使い、確定額とは考えないことが大切です。 ### 規模別の一般的な目安 以下は、企業がシステム開発を外注する場合の一般的な目安です。採用する製品、開発方式、品質基準、既存環境によって大きく変動します。 |規模・内容の例|初期費用の目安|期間の目安| |---|---:|---:| |業務調査・要件整理のみ|30万〜300万円程度|2週間〜3カ月| |小規模な業務ツール、限定的なWebシステム|300万〜800万円程度|3〜6カ月| |複数部門で使う業務システム、一般的なWebサービス|800万〜3,000万円程度|6〜12カ月| |基幹業務、複数システム連携、大規模サービス|3,000万円以上|12カ月以上| 既製のSaaS（＝インターネット経由で利用する既製サービス）を設定中心で導入できる場合は、個別開発より初期費用を抑えられることがあります。一方で、業務に合わせた大幅な追加開発や複雑なデータ移行が必要になると、想定より費用が増える場合があります。 人月（＝1人が1カ月稼働する作業量）の単価だけで予算を判断する方法にも注意が必要です。単価が低くても、管理や手戻りを含む工数が多ければ総額は下がりません。反対に、経験のある担当者が短期間で要件を整理できれば、単価が高くても総費用を抑えられることがあります。 ### 予算を押し上げやすい要件 次の項目がある場合は、同じ画面数でも費用や期間が増えやすくなります。 - 会計、決済、認証、配送など複数の外部システムと連携する - 古いシステムから大量のデータを移行する - 部門や役職ごとに細かな閲覧・操作権限を設定する - 24時間365日の利用や短時間での復旧を求める - 個人情報、決済情報、機密情報を扱う - スマートフォン、タブレット、複数ブラウザに対応する - 承認経路や料金計算などの業務ルールが複雑である - 公開後すぐに大人数が利用する 可用性（＝システムを止めずに使える度合い）、性能、セキュリティなどは非機能要件と呼ばれます。これらの決め方は、[非機能要件の決め方｜外注前チェックリスト](https://www.geek-bridge.com/column/non-functional-requirements-outsourcing)も参考にしてください。 ### 運用費の考え方 運用保守費は、初期開発費に一定の割合を掛ければ必ず算出できるものではありません。必要な対応時間、監視範囲、問い合わせ件数、クラウド構成、外部サービスの料金によって変わるため、項目ごとに見積もる方が正確です。 最低限、次の費用を確認します。 - クラウドサーバー、データベース、ストレージの利用料 - メール、SMS、地図、決済、生成AIなどの従量課金 - 監視、バックアップ、障害一次対応の費用 - 問い合わせ窓口と調査対応の費用 - セキュリティ更新、OSやライブラリの更新費用 - 軽微な修正と機能追加の費用 - AppleやGoogleなど外部プラットフォームの登録・更新費 月額固定費だけでなく、利用者数、データ量、送信件数に応じて増える変動費も試算しましょう。標準利用時と繁忙時の2パターンを作ると、運用予算の不足を防ぎやすくなります。 ## 発注前に予算を決める5つのステップ 現実的な予算を作るには、先に機能一覧を完成させるのではなく、目的、制約、優先順位、不確実性の順に整理します。要件が未確定でも、次の手順なら段階的に予算を具体化できます。 ### 1. 解決したい課題と投資上限を決める 最初に、「何を作るか」ではなく「何を改善するか」を一文で定義します。目的が曖昧なままでは、提案される機能が増え、適正予算を判断できません。 整理する項目は次のとおりです。 - 現在どの業務や顧客体験に問題があるか - 誰が、どの程度困っているか - システム導入後に何が変われば成功か - 売上増加、工数削減、ミス削減などの評価指標 - いつまでに効果を出したいか - 会社として投資できる上限額はいくらか 投資上限は、開発会社に値引きを求めるための数字ではありません。限られた予算内で優先順位を提案してもらうための制約です。「上限を伝えると、その金額いっぱいで見積もられるのでは」と懸念されることがありますが、予算を伏せると実現可能性の低い提案が出やすくなります。 予算を伝える場合は、「初期費用800万円以内、初年度運用費を含む」「開発費1,000万〜1,500万円を想定し、効果を確認できれば追加投資を検討」のように対象範囲も併記してください。 ### 2. 現行業務と制約条件を可視化する 開発会社が予算を算定するには、機能名よりも業務の流れや例外条件が重要です。発注前に、完璧でなくても次の資料を用意しましょう。 - 現在の業務フローと担当部門 - 使用中のExcel、帳票、マニュアル、既存システム - 利用者の種類と概算人数 - 取り扱うデータの種類と量 - 連携が必要な外部システム - 法令、社内規程、セキュリティ上の制約 - 希望公開日と、その日を変更できるかどうか - 既存契約や指定技術などの制約 「既存データを移行する」という一文だけでは、見積もりは安定しません。データ件数、形式、欠損、重複、文字化けの有無などによって作業量が変わるからです。可能であれば、個人情報を除いたサンプルデータを準備します。 ### 3. Must・Should・Couldに分ける すべてを必須要件にすると、予算超過時に削る判断ができません。機能や条件を次のように分類します。 |優先度|意味|判断の例| |---|---|---| |Must|初回公開に絶対必要|なければ業務やサービスが成立しない| |Should|重要だが代替手段がある|手作業で一時対応できる| |Could|余裕があれば実装|利便性は上がるが目的達成に直結しない| |Won't|今回は実装しない|将来候補として記録する| この分類はMoSCoW法と呼ばれる優先順位付けの方法です。重要なのは、Mustを増やしすぎないことです。「経営者が欲しい」「現場から要望が出た」という理由だけでなく、初回公開に必要か、代替手段があるかで判断します。 発注相談では、要望がすべて同じ優先度で並んでいるケースが少なくありません。その状態では、開発会社は安全を見て全機能を含めるため、見積額が高くなります。反対に、優先順位が明確なら、予算に応じて段階的な提案を作りやすくなります。 ### 4. 概算見積もりを取り、予算幅を更新する 概算見積もり（＝詳細設計前に出す大まかな金額）は、稟議用の確定価格ではなく、実現方法と予算規模を確認するために使います。要件が曖昧な段階では、「800万〜1,300万円」のような幅がある方が誠実な場合もあります。 概算見積もりを依頼するときは、次の情報を同じ条件で渡します。 - 解決したい課題と成功条件 - 想定予算と公開希望時期 - Must・Should・Couldの分類 - 利用者数、データ量、連携先 - 既存資料とサンプルデータ - 見積もりに含めてほしい範囲 - 予算幅が変動する条件 初期段階では、以下の3つの予算案を出してもらう方法も有効です。 |案|目的|内容の考え方| |---|---|---| |最小案|早期に効果を確認する|Mustに絞り、手作業も一部残す| |標準案|主要業務を安定して運用する|Mustと重要なShouldを含める| |拡張案|将来の成長や効率化に備える|自動化、分析、追加連携も含める| 複数社を比較する場合は、価格だけでなく、課題理解、提案範囲、体制、品質管理、保守条件を確認します。具体的な比較軸は、[システム開発会社の選び方｜発注前の比較ポイント](https://www.geek-bridge.com/column/system-development-company-selection)で解説しています。 ### 5. フェーズごとに予算承認の節目を設ける 要件が固まっていないのに全工程を固定価格で契約すると、発注側と開発会社の双方が大きなリスクを負います。最初から全額を確定させるのではなく、次のように段階を分ける方法があります。 1. 業務調査・企画の予算を承認する 2. 要件定義の成果物を確認する 3. 開発・テスト費を再見積もりする 4. 投資対効果とリスクを再評価する 5. 開発着手を承認する 6. 公開後の保守・改善予算を更新する この進め方には、調査後に予算が増える可能性を早く把握できる利点があります。予算に収まらない場合も、開発着手前なら、対象業務の縮小、既製サービスの利用、段階導入などを選択できます。 企画段階から予算策定や開発範囲の整理を外部に相談したい場合は、[開発のご相談はこちら](https://www.geek-bridge.com/#contact)からお問い合わせください。 ## 見積もりの見方と予算超過を防ぐポイント 予算超過を防ぐには、最安値を選ぶことよりも、見積もりの前提と除外範囲を明らかにすることが重要です。合計額が安く見えても、必要作業が別料金なら最終費用は高くなります。 ### 見積書で確認するチェックリスト 見積書を受け取ったら、次の項目を確認してください。 - [ ] 要件定義、設計、開発、テストの各工程が含まれている - [ ] 画面、機能、帳票、外部連携の対象範囲が記載されている - [ ] データ移行の件数、形式、回数、移行後の確認範囲が明確である - [ ] テストの種類、対応端末、対象ブラウザが書かれている - [ ] クラウド、ライセンス、外部APIの費用が区別されている - [ ] プロジェクト管理、会議、資料作成の費用が含まれている - [ ] 操作マニュアル、教育、公開作業の有無が明確である - [ ] 保守開始日、対応時間、対応範囲、月額費がわかる - [ ] 仕様変更時の見積もり・承認手順が定められている - [ ] 成果物、検収条件、支払時期が明確である - [ ] 見積もりの有効期限と前提条件が書かれている - [ ] 「含まれない作業」が具体的に記載されている 「一式」という記載が多い場合は、内訳を質問しましょう。一式表記そのものが問題なのではなく、対象範囲や数量が不明なまま契約することが問題です。 ### 安い見積もりでは除外事項を確認する 他社より大幅に安い見積もりには、合理的な理由がある場合と、単に範囲が不足している場合があります。次のような違いを確認してください。 - 要件定義を発注者側が行う前提になっている - テスト端末や対象ブラウザが限定されている - データ移行や移行後の確認が含まれていない - プロジェクト管理や定例会が最小限である - デザインや原稿作成が発注者対応になっている - 公開後の不具合対応期間が短い - 海外や別会社への再委託を前提としている - 保守やクラウド構築が別契約になっている 提案内容と条件が同等なら、価格は重要な比較要素です。しかし、範囲が違う見積もりを合計額だけで比較してはいけません。 ### 予備費は不確実性に応じて設定する 一般的な検討目安として、要件が比較的明確な案件では開発予算の10〜20％、新規事業や複雑なデータ移行など不確定要素が多い案件では20〜30％程度の予備費を検討します。これは統計的な確定値ではなく、予算管理上の目安です。 予備費を使う条件も決めておきましょう。 - 法令や外部サービスの仕様変更への対応 - 調査で判明したデータ不備への対応 - 事前に予測できなかった既存システムの制約 - 事業上の優先度が高い追加要件 - テストで判明した重大な業務上の不足 一方、「希望が出た機能を何でも追加するための資金」にしてはいけません。予備費の利用には、目的、金額、納期への影響、代替案を記録し、責任者が承認するルールを設けます。 なお、開発会社の見積もりにリスク対応工数が含まれている場合、発注側の予備費と二重になる可能性があります。どのリスクを誰が負担するのか確認してください。 ### よくある予算策定の失敗と回避策 |失敗|起きること|回避策| |---|---|---| |初期開発費だけで稟議を通す|公開後の保守費を確保できない|初年度と3年間のTCOを示す| |全機能を必須にする|予算超過時に削れない|Must・Should・Couldに分類する| |要件未確定で確定価格を求める|高いリスク費が乗るか、変更費が増える|要件整理と開発を段階契約にする| |データ移行を軽視する|公開直前に追加費用と遅延が発生する|件数、品質、移行回数を事前調査する| |最安値だけで選ぶ|必要工程が見積もりから漏れる|範囲、成果物、除外事項を比較する| |社内工数を考慮しない|確認が遅れ、開発が止まる|担当者と承認者の稼働時間を確保する| |予備費を用途なく使う|優先度の低い追加開発で不足する|利用条件と承認ルールを決める| 予算管理は、開発会社だけの仕事ではありません。発注者側でも、仕様変更の承認者、予算残高、決定期限を明確にする必要があります。追加要望が出たときは、「追加するか」だけでなく、「何を外すか」「公開日を変えるか」「予備費を使うか」をセットで判断しましょう。 ## まとめ - システム開発予算は、初期費用だけでなく、運用費、社内コスト、予備費まで含めて考えます - 要件が曖昧な段階では確定額にせず、前提条件を付けた予算幅として設定します - 小規模開発は300万〜800万円程度、中規模は800万〜3,000万円程度が一般的な検討目安ですが、連携、移行、品質基準によって大きく変わります - 目的と投資上限を決め、現行業務を整理してから、Must・Should・Couldで優先順位を付けます - 企画、要件定義、開発の節目で再見積もりと予算承認を行うと、不確実性を管理しやすくなります - 見積もりは合計額だけでなく、成果物、前提条件、除外事項、テスト、移行、保守まで確認します - 予備費は一般的に10〜20％、不確定要素が多い場合は20〜30％程度を検討し、利用条件を決めて管理します - 公開後を含む3年程度のTCOを比較すると、初期費用だけでは見えない投資負担を把握できます ## よくある質問 ### 要件が固まっていなくても予算を決められますか？ 決められます。ただし、単一の確定額ではなく、前提条件を付けた予算幅として設定することが重要です。最初に企画・要件整理の予算を確保し、その成果をもとに開発費を再見積もりすると精度を高められます。 ### システム開発の予備費は何％必要ですか？ 一般的には、要件が比較的明確なら開発予算の10〜20％、不確定要素が多い場合は20〜30％程度が検討の目安です。ただし、見積もりにリスク対応費が含まれている場合は二重計上にならないよう確認してください。 ### 開発会社によって見積金額が大きく違うのはなぜですか？ 対象範囲、品質基準、開発体制、再委託の有無、テスト範囲、保守対応などの前提が異なるためです。合計金額だけでなく、成果物・除外事項・工数・単価・前提条件をそろえて比較する必要があります。 ### 社内担当者の人件費も予算に含めるべきですか？ 含めることをおすすめします。業務整理、資料作成、会議、受け入れテスト、データ確認、社内教育には相応の時間が必要です。外注費だけで投資判断をすると、実際の総コストや必要な社内体制を過小評価しやすくなります。