LASSIC Media らしくメディア
システム改修の費用｜見積もりの4つの内訳と金額の決まり方
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- システム改修の費用は、影響調査・改修・テスト・リリースの4つに分けると内訳が読みやすくなります。
- 改修では変えていない部分の回帰テストが加わるため、直す量が小さくてもテストの費用はなくなりません。
- 金額は変える量だけでなく、設計書やテストの記録がどれだけ整っているかでも変わります。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
画面の入力項目を1つ増やすだけなのに、見積もりが思ったより高い。前回と似た改修なのに、金額が大きく違う——。稼働中の業務システムに手を入れるときは、こうした戸惑いが起こりがちです。システム改修の費用とは、いま動いているシステムの機能を変えたり加えたりするときに、調べる・直す・確かめる・本番に出すという作業にかかる費用のことです。
費用の大半は人の作業時間なので、内訳と決まり方が分かれば、見積もりの差がどこから来ているのかを読み取れます。ただし万能ではなく、設計書が古いシステムでは、調べてみるまで金額が固まらないこともあります。本記事では、稼働中のシステムの改修を発注する情報システムの担当者に向けて、新規開発との違い、費用の4つの内訳、金額の決まり方、そして外部に頼むときに確認したい点を整理します。
目次
システム改修の費用とは
IPA（情報処理推進機構）が企業から集めた開発プロジェクトのデータでは、種別の内訳で「改修・保守」が51.5％を占め、新規開発の29.1％を上回っています。*1 IPAは、新規開発が減り、改修・保守が増える傾向が続いているとも説明しています。システムにかかるお金を考えるとき、改修の見積もりを読む力は欠かせません。
- 改修の費用は「工数（作業にかかる人と時間の量）×単価」で決まります
- 工数は、直す箇所の数だけでなく、変更が及ぶ範囲を調べて確かめる作業にもかかります
- 単価は、担当する人の役割（SE・プログラマなど）やレベルで変わります*3
- 毎月の保守契約に含まれる軽い修正か、案件ごとに見積もる改修かは、契約によって分かれます
本記事では、案件ごとに見積もる改修を扱い、金額の目安ではなく見積もりの中身と決まり方に絞って整理します。毎月の保守費用の考え方はシステム保守費用の根拠と妥当性の見極め方で扱っています。
新規開発の費用との違い
改修の見積もりにも、新しく作るときと同じ工程の名前が並びます。ただし、重みのかかり方が違います。IPAのデータで基本設計から総合テストまでの5工程がそろったプロジェクトを比べると、改修・保守と拡張を合わせた改良開発580件では、総合テストが工数に占める比率の中央値が14.2％で、新規開発270件の11.9％より高くなっています。*1
| 観点 | 新規開発 | システム改修 |
|---|---|---|
| 最初の作業 | 業務と要件を決める | いまの仕組みと変更の影響を調べる |
| 作る量 | 画面や機能をすべて作る | 変える箇所と、そこにつながる箇所 |
| テスト | 作った機能を確かめる | 変えた箇所に加え、変えていない箇所が壊れていないかも確かめる |
| 費用を左右する資料 | 要件定義書 | いまの設計書、ソースコード、過去のテストの記録 |
改修では、変えていない部分が壊れていないかを確かめる回帰テスト（以前のテストをやり直す確認）が加わります。そのため、直す量が小さくても、テストの費用はなくなりません。見積もりでテストの行が大きく見えても、それだけで過大とは言えない理由がここにあります。
改修費用の4つの内訳
改修の見積もりは、作業の順に4つに分けると読みやすくなります。会社によって項目の名前は違っても、中身はおおむねこの4つに当てはまります。
| 内訳 | 含まれる作業 | 費用が増えやすい場面 |
|---|---|---|
| 1. 影響調査 | いまの設計書とソースコードを読み、変更が及ぶ画面・データ・連携先を洗い出す | 設計書が古く、ソースコードを読み解く必要があるとき |
| 2. 改修（設計と製作） | 変更する部分の設計書を直し、プログラムを書き換える | 1か所の変更が複数の画面や帳票に広がるとき |
| 3. テスト | 変えた箇所のテストと、変えていない箇所の回帰テスト | 影響範囲を絞り切れず、確かめる範囲が広がるとき |
| 4. リリース | 本番への反映の手順づくりと作業、元に戻す手順の準備、設計書の更新 | 止められる時間が短く、夜間や休日の作業が要るとき |
IPAのデータでは、改良開発の工数の比率の中央値は、製作が29.7％、結合テストが20.0％、基本設計が15.3％、詳細設計が15.2％、総合テストが14.2％でした。*1 この5工程の数字には、着手前の影響調査とリリースの作業は入っていません。見積もりを比べるときは、影響調査とリリースが別の行で計上されているか、ほかの工程に含まれているかを先に確かめます。
改修の金額はどう決まるのか
同じ「入力項目を1つ増やす」改修でも、金額はシステムの状態によって大きく変わります。デジタル庁の実践ガイドブックは、改修の見積もりを確かめる観点として、影響範囲の特定やテスト項目の見直しを挙げています。*2
- 設計書が最新か：古いと影響調査に時間がかかります。デジタル庁の標準ガイドラインの解説書は、保守を担う事業者が設計書一式を最新の状態に保つよう求めています*3
- 影響範囲を絞れるか：絞り込みが不十分だとテストの範囲が広すぎて工数が増える、と実践ガイドブックは指摘しています
- 似た画面を流用できるか：既存のひな形や似た画面と近いほど、追加の工数は少なく済むとされています
- テストの記録が残っているか：過去のテストケースやデータを整理しておくと、回帰テストを効率よく進められます
- 要件が決まっているか：未確定の部分は複数の案ごとに見積もりを取り、前提が変わったときの影響を確かめます*2
つまり改修の費用は、変える量だけでなく、いまのシステムがどれだけ調べやすく確かめやすい状態かでも決まります。設計書とテストの記録を日ごろから整えておくことが、次の改修の費用を抑える下地になります。
外部に頼むときに確認しておきたい点
改修を外部に頼むときは、合計額より先に内訳と前提を確かめます。デジタル庁の解説書は、見積もりの内訳を「一式 ○○円」といった書き方にせず、妥当性を確かめられる細かさで書くよう求めています。*3
- 内訳の分け方：影響調査・改修・テスト・リリースが分かれているか。「一式」になっていないか
- 影響調査の進め方：設計書とソースコードのどこまでを読み、結果をどんな形で示すか
- テストの範囲：回帰テストをどこまで行うか。影響調査の結果をもとに、発注側と受注側で方針を話し合えるか*2
- リリースと戻し方：本番へ反映する時間帯と、問題が起きたときに元に戻す手順
- 実績の報告：改修の規模とかかった工数の実績を報告してもらえるか
特に実績の報告は、1回目の改修では軽く見られがちです。実践ガイドブックも、改修の規模と実績の工数を報告させておくと、次に同じ規模の改修をするときに工数の妥当性を確かめられるとしています。古いシステムを丸ごと作り直す場合の考え方はレガシーシステム刷新の費用相場で扱っています。
まとめ：システム改修の費用で確かめたい3つの点
システム改修の費用を見積もりで確かめるうえで、確かめておきたい点は3つに整理できます。第一に、影響調査・改修・テスト・リリースの4つに分けて内訳を出してもらうこと。第二に、回帰テストの範囲を影響調査の結果から決め、発注側と受注側で話し合うこと。第三に、設計書とテストの記録を最新に保ち、改修ごとに実績の工数を残すことです。この3点を踏まえておけば、「小さな修正のはずが、中身の分からない見積もりのまま高い金額を払っていた」という事態を避けやすくなります。改修の範囲や見積もりの読み方に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
改修の見積もりが出るまでにどのくらいかかりますか
影響調査の深さによって変わります。設計書が最新で変更箇所が限られていれば早く出せますが、設計書が古くソースコードを読み解く必要があると時間がかかります。影響調査だけを先に小さな契約で頼み、その結果をもとに改修の見積もりを出してもらう進め方もあります。
開発した会社とは別の会社に改修を頼めますか
頼めます。ただし、設計書やソースコードを相手に渡せるかを契約で確かめておく必要があります。デジタル庁の解説書も、既存の情報システムがあるときは、秘密保持契約を結んだうえで見積もりをする事業者に設計書などを閲覧させるよう求めています。*3 最初は引き継ぎのための調査が加わるので、1回目の費用は高めになると見込んでおきます。
回帰テストを省いて費用を下げられますか
すべて省くのは勧められません。変えていない部分が壊れていても気づけなくなるためです。デジタル庁の実践ガイドブックは、影響範囲を特定して不要なテスト項目を除くことや、過去のテストシナリオの再利用、テストの自動化でテストの効率を高める方法を示しています。*2
システム改修の見積もりと進め方のご相談
影響調査から改修・テスト・リリースまで、稼働中のシステムの改修を元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：独立行政法人情報処理推進機構（IPA）「ソフトウェア開発分析データ集2022」（https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。出典：1.2.1「開発プロダクトの種別」（図1-2-1）、A3.3.8・A3.3.9「工程別工数」（表A3-3-8 新規開発・表A3-3-9 改良開発）を参照（2026年10月確認）
- *2 参考：デジタル庁「デジタル社会推進実践ガイドブック DS-120 デジタル・ガバメント推進標準ガイドライン実践ガイドブック」（2026年6月12日）（https://www.digital.go.jp/resources/standard_guidelines）。出典：第3編第3章「予算及び執行」（未確定な内容がある場合の見積り、開発生産性の精査）、第3編第9章「運用及び保守」（機能改修のテスト範囲と実績工数の報告）を参照（2026年10月確認）
- *3 参考：デジタル庁「デジタル社会推進実践ガイドブック DS-110 デジタル・ガバメント推進標準ガイドライン解説書」（2026年6月12日）（https://www.digital.go.jp/resources/standard_guidelines）。出典：第3章4「経費の見積り」（積算内訳の明確化、設計書等の閲覧）、第5章2「要件定義」（設計書一式の最新化）、第7章5「開発・テストの実施・管理」（回帰テストとテスト工程の合理化）を参照（2026年10月確認）
