システム改修の費用相場は、軽微な修正で10万〜50万円、小規模な機能追加で50万〜150万円、中規模改修で150万〜500万円、大規模改修では500万〜1,000万円以上が一般的な目安です。実際の費用は、既存仕様の調査、影響範囲、テスト、データ移行、本番切り替えの難易度で決まります。
システム改修の費用相場と期間
システム改修では、見た目の変更量よりも「安全に変更するために確認すべき範囲」が費用を左右します。入力欄を一つ増やすだけでも、データベース、検索、帳票、権限、外部連携まで修正が必要になることがあるためです。
以下は、業務システムやWebシステムを外注する場合の一般的な目安です。金額は税別の概算であり、対象システムの状態や契約条件によって変わります。
| 改修規模 | 費用の目安 | 期間の目安 | 改修例 |
|---|---|---|---|
| 軽微な修正 | 10万〜50万円 | 数日〜3週間 | 文言・レイアウト修正、入力チェック変更、簡単な項目追加 |
| 小規模な機能追加 | 50万〜150万円 | 1〜2カ月 | 検索条件追加、CSV出力、メール通知、簡単な帳票追加 |
| 中規模な機能改修 | 150万〜500万円 | 2〜5カ月 | 承認フロー追加、権限管理、管理画面刷新、複数画面の変更 |
| 大規模な改修 | 500万〜1,000万円以上 | 4〜10カ月以上 | 基盤更新、複数業務の刷新、外部連携の再構築、性能改善 |
| 全面リニューアル | 1,000万円以上 | 6カ月以上 | 老朽化したシステムの再構築、大規模なデータ移行 |
実際には、小さな修正でも一定の最低費用がかかります。開発会社は修正作業だけでなく、環境準備、現状調査、テスト、本番反映、作業記録まで行うからです。他社が開発したシステムでは、修正そのものより事前調査のほうが大きくなる場合もあります。
見積金額の基本的な考え方
システム改修費は、主に作業量と技術者の単価から算出されます。「人月」とは、1人が1カ月稼働する作業量を表す単位です。例えば、月額100万円相当の担当者が合計3人月必要であれば、単純計算で300万円となります。
ただし、見積もりに含まれるのはプログラミングだけではありません。
- 現行システムとソースコードの調査
- 要件定義（＝作るものと対象範囲を決める工程）
- 設計、開発、レビュー
- テストデータとテスト環境の準備
- 回帰テスト（＝変更していない既存機能が壊れていないか確かめるテスト）
- データ移行、本番反映、切り戻し準備
- プロジェクト管理、打ち合わせ、報告
- マニュアルや設計書の更新
期間についても、開発作業の日数だけで判断してはいけません。発注者による確認、外部サービス事業者への問い合わせ、社内承認、本番切り替え可能日の調整などを含めると、見積書に記載された作業期間より全体日程が長くなることがあります。
先に調査だけを依頼する場合の費用
既存資料が不足している場合は、改修全体をすぐに発注せず、現状調査を独立した工程として依頼する方法があります。調査費は10万〜100万円程度が一つの目安ですが、大規模なシステムや外部連携が多いシステムでは、それ以上になることもあります。
調査を依頼するときは、次の成果物を契約前に決めてください。
- 現行システムの構成図
- 対象機能と影響範囲の一覧
- 技術上・運用上の課題一覧
- 改修案とリニューアル案の比較
- 概算費用とスケジュール
- 改修時に残るリスクと前提条件
調査結果を特定の会社だけでしか利用できない状態にしないため、成果物の利用条件も確認しておくと、その後の比較や社内説明に使いやすくなります。
改修費用を左右する要因と作り直しの判断基準
費用差が生まれる主な理由は、機能数ではなく、不明点と変更リスクの大きさです。発注のご相談を受ける開発会社の立場から見ると、特に「正しいソースコードへアクセスできるか」「現行仕様を説明できる人がいるか」「どこまでテストすべきか」の3点が見積精度に直結します。
| 費用を左右する要因 | 費用が上がりやすい状態 | 発注前に確認すること |
|---|---|---|
| 仕様書・設計書 | 資料がない、更新されていない | 画面一覧、構成図、操作マニュアルを集める |
| ソースコード | 最新版が不明、引き継げない | 保管場所、権利、動作中の版との一致を確認する |
| 影響範囲 | 複数機能が密接に結び付いている | 画面だけでなく帳票、検索、権限への影響を確認する |
| 外部連携 | 決済、会計、在庫などとの連携が多い | API（＝システム同士がデータを受け渡す仕組み）の仕様と契約を確認する |
| データ | 表記揺れ、重複、欠損が多い | データ件数だけでなく品質と変換ルールを調べる |
| 品質・セキュリティ | 個人情報や決済情報を扱う、停止できない | 必要なテスト、監査、停止可能時間を決める |
| 納期 | 短納期、夜間・休日の切り替えが必要 | 必須期限と調整可能な期限を分ける |
| 開発環境 | テスト環境がない、再現手順が不明 | 本番以外で安全に確認できる環境を準備する |
改修と全面リニューアルを比較すべきケース
改修費が高いという理由だけで、すぐに作り直す必要はありません。全面リニューアルには、データ移行、業務手順の変更、利用者教育、並行稼働などの費用が伴います。一方、老朽化したシステムへ部分改修を重ねると、将来の調査費や障害リスクが増えることがあります。
次の項目が複数当てはまる場合は、部分改修案と全面リニューアル案を同じ条件で比較してください。
- 古い技術やサポート終了済みの製品に依存している
- 対応できる技術者や保守会社が限られている
- 仕様書がなく、変更のたびに長い調査が必要になる
- 一つの修正が別機能の不具合につながりやすい
- 性能やセキュリティ上の問題を部分対応では解決できない
- 今後3〜5年で利用者や取引量が大きく増える予定がある
- 法改正や事業変更に継続的に対応する必要がある
- 改修後も高額なライセンス費や保守費が残る
判断するときは、初期費用だけでなくTCO（＝導入後の保守・運用まで含めた総費用）を比較します。
| 比較項目 | 部分改修 | 全面リニューアル |
|---|---|---|
| 初期費用 | 比較的抑えやすい | 高くなりやすい |
| 導入期間 | 短くしやすい | 長くなりやすい |
| 現場への影響 | 小さくしやすい | 操作変更や教育が必要になりやすい |
| 既存の制約 | 残る可能性がある | 解消できる可能性が高い |
| 将来の変更 | 構造によっては高コスト | 設計次第で対応しやすくなる |
| 移行リスク | 比較的小さい | データ・業務移行のリスクがある |
「改修費が新規構築費の何割なら作り直す」といった単一の基準では決められません。今後利用する年数、年間保守費、障害時の事業影響、移行費、教育費まで金額またはリスクとして並べることが重要です。
依頼前の準備とシステム改修の進め方
発注前に詳細な仕様書を完成させる必要はありません。まず整理すべきなのは、「なぜ改修するのか」「誰のどの業務を変えるのか」「予算や期限に応じて何を見送れるか」です。目的と優先順位が明確であれば、開発会社は費用を抑える代替案を提案しやすくなります。
依頼前チェックリスト
以下の情報を、分かる範囲でまとめてください。不明な項目は無理に埋めず、「不明」と明示したほうが安全です。
- 現在発生している課題と、その頻度・業務への影響
- 改修後に実現したい状態と評価方法
- 利用者の種類、人数、利用場所、利用頻度
- 必須機能と、予算次第で後回しにできる機能
- 希望予算、希望時期、法改正などの動かせない期限
- 画面一覧、操作マニュアル、設計書、過去の改修履歴
- ソースコード、サーバー、データベースへアクセスできるか
- 利用中のクラウド、ミドルウェア、外部サービスの一覧
- 現在の保守会社との契約内容、解約予告期間、引き継ぎ条件
- 個人情報、機密情報、決済情報などの取扱条件
- 本番システムを停止できる曜日・時間帯
- 発注者側の責任者、業務確認担当者、最終承認者
複数社へ同じ条件で提案を依頼する場合は、RFP（＝開発会社へ要件や提案条件を伝える依頼書）が役立ちます。作成項目や粒度は、RFPの作り方｜システム開発の依頼準備で詳しく解説しています。
改修プロジェクトの基本的な進め方
| ステップ | 実施内容 | 発注者が確認すること |
|---|---|---|
| 1. 目的整理 | 課題、予算、期限、優先順位を整理する | 改修後の成果を判断できるか |
| 2. 現状調査 | 資料、ソースコード、環境、データを調べる | 調査範囲と成果物が明確か |
| 3. 要件定義 | 対象機能、対象外、受入条件を決める | 必須要件と追加要望が分かれているか |
| 4. 設計・開発 | 変更方法を設計し、実装とレビューを行う | 重要な仕様を途中で確認できるか |
| 5. テスト | 新機能と既存機能の動作を確認する | 実際の業務パターンが含まれているか |
| 6. 受入確認 | 発注者が業務に沿って確認する | 誰がいつまでに合否を判断するか |
| 7. リリース・保守 | バックアップ後に本番反映し、監視する | 障害時の切り戻し方法があるか |
受入確認とは、納品されたシステムが発注内容を満たしているか、発注者が確認する工程です。ここで初めて操作するのではなく、設計中の画面案やテスト環境を段階的に確認すると、完成後の手戻りを減らせます。
また、本番切り替え前には次の事項を文書で確認してください。
- データとシステムのバックアップ方法
- 作業開始・終了の判断者
- 利用者への告知内容とタイミング
- 切り替え後に確認する重要機能
- 問題発生時に元の状態へ戻す条件と手順
- リリース直後の連絡先と対応時間
契約方式も不確実性に合わせる
仕様と影響範囲を十分に確定できる改修では、成果物と金額を決める請負契約が候補になります。一方、仕様書がなく調査しながら進める場合は、準委任契約（＝作業時間や専門業務の遂行に対して費用を支払う契約）で調査工程を切り出すほうが現実的なことがあります。
重要なのは、どちらが優れているかではなく、不明点が多いまま固定金額を約束させないことです。不確実性が高い案件で無理に総額を固定すると、見積もりへ大きな予備費が加算されるか、対象外項目が増える可能性があります。
見積もり・開発会社の比較方法と外注の注意点
見積もりは総額だけでなく、前提条件、対象範囲、対象外作業、追加費用の条件を比較してください。金額が安く見えても、調査、回帰テスト、データ移行、本番対応が含まれていなければ、最終的な支払額が高くなる可能性があります。
見積書で確認する項目
| 確認項目 | 見るべき内容 |
|---|---|
| 現状調査 | 対象となる資料、機能、環境、外部連携が明記されているか |
| 要件定義 | 要件の確定方法と、発注者が判断する事項が明確か |
| 設計・開発 | 対象画面、機能、帳票、権限が具体的に書かれているか |
| テスト | 新機能だけでなく既存機能の回帰テストを含むか |
| テスト環境 | 環境構築費、データ準備、利用料を含むか |
| データ移行 | 移行対象、変換、リハーサル回数、失敗時の対応を含むか |
| リリース | 本番反映、立ち会い、バックアップ、切り戻しを含むか |
| ドキュメント | 設計書、操作マニュアル、構成図を更新するか |
| 対象外 | インフラ費、外部サービス費、端末設定などが明記されているか |
| 仕様変更 | 追加費用の単価、見積方法、承認手順が決まっているか |
| 保証・保守 | 不具合の無償修正期間、受付時間、保守開始日が明確か |
相見積もりでは、全社へ同じ資料と質問回答を共有しなければ、公平な比較になりません。比較の具体的な進め方は、システム開発の相見積もり｜取り方と比較方法も参考にしてください。
開発会社を見極める質問
システム改修では、新規開発の実績だけでなく、他社開発システムの調査や引き継ぎに対応できるかが重要です。初回相談や提案時には、次の質問をしてみてください。
- 不明な仕様をどのような順序で調査しますか
- 調査後に見積金額が変わる条件は何ですか
- 変更による影響範囲をどのように特定しますか
- 既存機能の回帰テストはどこまで行いますか
- 発注者側で必要な作業と担当者は誰ですか
- プロジェクト中の課題、予算、進捗をどう共有しますか
- 担当者が交代した場合、情報をどう引き継ぎますか
- 本番反映に失敗した場合、どのように元へ戻しますか
- 改修後のソースコードと設計書はどこへ保管しますか
- 保守を別会社へ移す場合、どのような引き継ぎが可能ですか
良い提案は、要望をそのまま実装する提案とは限りません。目的を確認したうえで、既存機能の設定変更、運用変更、外部サービスの活用、段階的な改修など、費用とリスクを抑える選択肢を示してくれる会社は比較対象にしやすいでしょう。
よくある失敗と回避策
| よくある失敗 | 起こりやすい問題 | 回避策 |
|---|---|---|
| 口頭だけで依頼する | 完成条件を巡って認識がずれる | 対象範囲と受入条件を文書化する |
| 最安値だけで決める | 調査やテストが不足する | 見積範囲と前提条件をそろえて比較する |
| 機能を一度に詰め込む | 影響範囲と手戻りが増える | 優先順位を付け、段階的にリリースする |
| 現行保守会社への連絡が遅い | 資料やアクセス権を引き継げない | 契約と解約条件を早期に確認する |
| 受入担当者を決めない | 確認が遅れ、問題発見が本番後になる | 業務担当者と承認期限を先に決める |
| 本番データだけで確認する | 情報漏えいや業務停止につながる | テスト環境と加工済みデータを用意する |
| 切り戻しを準備しない | 障害時に業務を再開できない | バックアップ、判断条件、復旧手順を決める |
追加費用を完全になくすことは困難ですが、事前調査、範囲の明文化、変更管理によって抑えられます。仕様変更を依頼するときは、費用と納期への影響を確認し、責任者が承認してから着手する運用にしてください。予算にも、不明点や緊急対応に備えた予備費を確保しておくと安全です。
現行資料が少なく、改修と再構築のどちらが適切か判断できない場合は、開発のご相談はこちらからご相談いただけます。
まとめ
- システム改修の費用相場は、軽微な修正で10万〜50万円、小規模な機能追加で50万〜150万円、中規模改修で150万〜500万円、大規模改修で500万〜1,000万円以上が一般的な目安です
- 費用は変更する画面数だけでなく、現状調査、影響範囲、外部連携、データ移行、テスト、本番切り替えの難易度で決まります
- 仕様書やソースコードの状態が不明な場合は、調査工程を先に契約し、改修案と概算見積もりを作る方法が有効です
- 改修と全面リニューアルは、初期費用だけでなく、今後3〜5年の保守費、障害リスク、移行費、教育費を含むTCOで比較します
- 見積書では、調査、回帰テスト、データ移行、リリース、対象外作業、仕様変更時の精算方法を確認してください
- 開発会社は、他社システムの調査力、影響範囲の説明、切り戻し計画、引き継ぎ方針まで含めて選びます
- 業務効果の高い改修から段階的に進めると、初期費用と変更リスクを抑えやすくなります
よくある質問
システムの小さな修正はいくらから依頼できますか？
軽微な文言変更や表示修正は、10万〜50万円程度が一般的な目安です。ただし、他社が開発したシステムでは、環境準備や影響調査が必要になり、修正作業より調査費のほうが高くなる場合があります。
仕様書がなくてもシステム改修を依頼できますか？
依頼できます。ただし、ソースコード、動作環境、データ構造を確認する現状調査が必要です。まず調査工程を契約し、構成図、課題一覧、影響範囲、改修案、概算見積もりを成果物として受け取る進め方が現実的です。
改修と全面リニューアルはどう判断すればよいですか？
今後3〜5年の改修費と保守費、障害リスク、セキュリティ、データ移行費、利用者教育まで含む総費用で比較します。古い技術への依存や不具合の頻発がある場合は、部分改修案と全面リニューアル案の両方を見積もってください。
システム改修の追加費用を抑える方法はありますか？
事前調査を行い、対象範囲、対象外項目、受入条件、仕様変更時の承認手順を文書化することで抑えられます。追加要望が出た場合は、費用と納期への影響を確認し、責任者が承認してから着手する運用にしてください。
現在の保守会社とは別の会社へ改修を依頼できますか？
依頼できますが、ソースコードの権利と最新版、サーバーへのアクセス権、設計資料、外部サービスの契約情報を引き継げるか確認が必要です。現行契約の解約予告期間や引き継ぎ費用も、依頼先を決める前に確認してください。