LASSIC Media らしくメディア
システム開発で予算超過が起きる3つの原因と発注側の止め方
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- システム開発の予算超過は、計画時の考慮不足・現行システムの複雑さ・仕様変更の多発が主な要因です。
- 要件定義の段階の見積もりは確定見積ではなく、外部設計の承認後に見積もりなおすのが基本です。
- 仕様の変更は書面で出し、費用と期間への影響を確かめてから決めると、予算の膨らみを止めやすくなります。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
見積もりの範囲に収まっていたはずなのに、開発の途中で追加の費用を求められた。理由を尋ねても「仕様が変わったので」と言われるだけで、どこで増えたのかが分からない——。システム開発を外部に頼む会社では、こうした予算の食い違いが起こりがちです。システム開発の予算超過とは、開発にかかる費用が、計画のときに確保した予算を上回ってしまうことを指します。
予算超過は開発会社の見積もりの問題に見えますが、発注する側が防げる部分も少なくありません。ただし万能な防ぎ方はなく、最初の金額をすべて固定できるわけでもありません。本記事では、システム開発を発注する情報システムの担当者に向けて、見積もりの段階ごとの違い、予算超過が起きる3つの原因、発注側の止め方、そして外部に頼むときに確認したい点を整理します。
予算超過とは
予算超過を考えるときは、まず「予算」と「見積もり」を分けて捉えます。2つは同じ金額から始まることが多いものの、決める人と時点が違います。
- 予算：発注する側が、計画のときに社内で確保した金額
- 見積もり：開発会社が、その時点で分かっている前提をもとに出す金額
- 予算超過：開発が進むなかで費用が増え、確保した予算を上回ること
一般社団法人日本情報システム・ユーザー協会（JUAS）が東証上場企業などのIT部門長に行った2025年度の調査では、システム開発の予算について「予定より超過」と答えた割合をプロジェクトの規模ごとに比べています。10人月未満のプロジェクトでは10.0％を下回る一方、500人月以上では42.2％でした。*1 人月は、1人が1か月働く作業量を表す単位です。
概算見積と確定見積の違い
IPA（情報処理推進機構）の「情報システム・モデル取引・契約書」は、開発の段階によって見積もりの精度が違うと整理しています。構想や計画の段階の見積もりは、完成した姿をはっきり決めにくいため「参考値として取り扱われるべきもの」とされ、要件定義の段階の見積もりも「確定見積」ではないとしています。*2
| 段階 | 見積もりの呼び方 | 金額の扱い |
|---|---|---|
| システム化構想 | 仮試算見積 | 予算計画を立てるための参考値 |
| システム化計画 | 試算見積 | 仮試算より精度は上がるが、まだ参考値 |
| 要件定義 | 概算見積 | 目的と範囲は明確だが、細部は固まっていない |
| 外部設計の承認後 | 確定見積 | 以後の追加や変更は、手続きを経て再見積もり |
外部設計は、画面や帳票の形を決める工程です。つまり、要件定義を終えた時点の金額にも、まだ動く余地があります。性能や運用、セキュリティといった機能以外の条件（非機能要件）は、設計を進めるなかで新たに出てくる場合があるとも書かれています。*2 早い段階の金額をそのまま予算の上限にすると、確定見積との差が、そのまま予算超過として表れてしまいます。
予算超過が起きる3つの原因
JUASの同じ調査では、予算が「予定より超過」と答えた企業に、予定どおりにならなかった要因を複数回答で聞いています（回答245社）。割合が高かったのは次の3つで、どれも5割前後に達しました。*1
| 原因 | 割合 | よくある場面 |
|---|---|---|
| 想定以上の現行業務・システムの複雑さ | 51.4％ | 古いシステムの仕様が文書に残っておらず、作り直す途中で隠れた処理が見つかる |
| 計画時の考慮不足 | 51.0％ | データの移行やテスト、運用の準備など、見積もりの前提に入っていない作業が後から出てくる |
| 仕様変更の多発 | 48.6％ | 画面や帳票を決めた後に、追加や変更の要望が続く |
1つ目について、IPAのモデル取引・契約書の解説も、システムの作り直しでは長年の運用で業務やシステムの仕様が不完全になっていることが多く、要件を決める前に現行システムの調査が必要になると述べています。*2 3つ目の仕様変更は、発注する側の要望から生まれる原因です。社員のスキル不足（31.8％）、ベンダーのスキル不足（27.8％）も挙がっていますが、上位の3つとは差があります。*1
発注側はどう止めるのか
3つの原因のうち、発注する側が手を打ちやすいのは見積もりの前提と仕様変更です。IPAのモデル取引・契約書は、工程ごとに契約を結ぶ「多段階契約」と、あいまいさが残る段階の見積もりを要件がはっきりした段階で見積もりなおす「再見積り」の考え方をとっています。*2 これに沿うと、発注側の止め方は次の4つのステップに整理できます。
- ステップ1：工程ごとに契約し、要件定義が終わった時点と外部設計が承認された時点で見積もりなおす
- ステップ2：決めきれない事項は、内容と決める予定の時期、決まったときに費用や期間が変わりうることを書面に残す*2
- ステップ3：仕様の変更は、内容と理由を書いた変更提案書で出し、費用やスケジュールへの影響を書いた変更管理書をもとに協議して決める*2
- ステップ4：全体の予算を見ながら要望に優先順位をつけ、後の工程にしわ寄せが出ないようにする
ステップ3の変更管理書には、変更の理由や詳細のほか、「変更のために費用を要する場合はその額」と、作業期間や委託料など契約の条件への影響を書く欄があります。*2 費用の増え方を要望ごとに見える形にしておけば、小さな変更が積み重なって予算を使い切る流れを止めやすくなります。
外部に頼むときに確認しておきたい点
予算超過を避けるには、契約を結ぶ前に、見積もりの中身と変更の扱いを開発会社と確かめておくことが大切です。IPAの解説は、仕様を変えないと合意した後に大量の追加要望を出して開発を遅らせたとして、発注した側の責任が認められた裁判例も紹介しています。*2 要望を出す側にも、手続きを守ることが求められます。
- 見積もりの前提：どの段階の見積もりか。前提にした機能の範囲と、含まれていない作業（移行・テスト・運用の準備など）が書かれているか
- 現行システムの調査：作り直しなら、要件を決める前に今の仕様を調べる工程が入っているか
- 変更の手続き：変更提案書と変更管理書の形、協議する場、承認する責任者が決まっているか
- 再見積もりの時期：どの工程の終わりで見積もりなおすか
- 運用後の見直し：完了後に、見積もりと実績の差を振り返る場を設けるか
年度ごとの予算の組み方はIT予算の立て方と配分の考え方で、改修にかかる費用の内訳はシステム改修の費用で扱っています。
まとめ：予算超過で確かめておきたい3つの点
システム開発の予算超過を防ぐうえで、確かめておきたい点は3つに整理できます。第一に、早い段階の見積もりは参考値として扱い、外部設計の承認後に出る確定見積で予算を見直すこと。第二に、現行システムの調査やデータの移行など、見積もりの前提に入っていない作業を洗い出しておくこと。第三に、仕様の変更は書面で出し、費用と期間への影響を確かめてから決めることです。この3点を踏まえておけば、「小さな変更を重ねるうちに、気づいたら予算を使い切っていた」という事態を避けやすくなります。見積もりの読み方や変更の進め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
予算を超えそうなときに開発を止めることはできますか
IPAのモデル取引・契約書では、変更の協議の結果、費用や期間などの条件に影響が出るため続けないと決めた場合、発注する側は終わっていない部分の契約を解約できるとしています。*2 ただし、それまでの作業の委託料と、解約で相手に生じた損害は支払う形です。実際の扱いは契約によって変わるため、契約書の条項を確かめておきます。
開発会社から追加費用を求められたらそのまま払うのですか
モデル取引・契約書では、変更は双方の責任者が変更管理書を承認して確定し、費用などの条件に影響する場合は変更契約を結んで確定するとしています。*2 まずは変更管理書で金額と理由を確かめ、協議の場で決める流れになります。支払いの義務の有無は契約ごとに違うため、判断に迷うときは契約書と専門家に確かめてください。
見積もりの精度は発注する側の努力でも上がりますか
上がります。IPAの解説は、発注する側ができるだけ早く要件を確定することが正確な見積もりに必要だとし、開発会社には見積もりの精度を高める取り組みと十分な説明が欠かせないとしています。*2 要件を固める作業を開発会社任せにしないことが、予算超過を防ぐ近道です。
システム開発の予算と見積もりのご相談
見積もりの前提の整理から、変更管理の手続きづくり、開発と運用の体制まで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：一般社団法人日本情報システム・ユーザー協会（JUAS）「企業IT動向調査報告書2026」（https://juas.or.jp/cms/media/2026/04/JUAS_IT2026.pdf）。出典：7章「システム開発」の図表7-1-4（プロジェクト規模別のQCD遵守状況）と図表7-1-7（予算が予定どおりにならなかった要因）を参照。2025年9月5日〜10月24日に東証上場企業とそれに準じる企業のIT部門長を対象に実施（2026年10月確認）
- *2 参考：独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）＜第二版＞」（2025年4月8日更新）（https://www.ipa.go.jp/digital/model/model20201222.html）。出典：開発見積の段階（仮試算・試算・概算・確定）の解説、多段階契約と再見積り、第34条（システム仕様書等の変更）・第36条（未確定事項の取扱い）・第37条（変更管理手続）・第38条（変更の協議不調に伴う契約終了）とその解説を参照（2026年10月確認）
