システム改修・開発保守の外注【2026年版】｜費用相場、見積もりの読み方、頼み先5タイプと「続く改修」を専属チームで持つ方法

「小さな修正なのに、見積もりが100万円を超えた」「当時の開発会社の担当者が辞めて、誰もシステムの中身を分からない」——既存システムの改修や保守を外注しようとした方から、こうした相談をよく受けます。困りごとははっきりしているのに、いざ頼もうとすると「誰に、いくらで、どう頼めばよいか」が見えない。改修は新規開発と違う難しさを抱えていて、これは発注側の準備不足ではありません。

結論から言うと、改修の見積もりが高く見えるのは、小さな修正ほど「現状調査」のコストの比率が高くなり、開発会社側にも最低受注額と大型案件優先の事情があるからです。費用は改修規模と「安全に変更するために確認すべき範囲」で決まり、見積もりは「調査・回帰テスト・切り戻しが含まれるか」で読んでください。そして、改修や保守が「続く」ものなら、単発の請負を繰り返すより、専属チームを月額固定で持つほうが総額も社内の負担も小さくなります。

構造が分かれば、頼み先を「元の開発会社か新しい開発会社か」の2択から広げられます。単発の軽微な修正はスポットやフリーランス、まとまった改修は開発会社、続く改修と保守は専属チーム。規模に合った頼み先を選べば、毎回の見積もりと稟議と立ち上げに疲弊する状態から抜けられます。

本記事では、開発・運用・保守の違いと改修が頼みづらい3つの構造、規模別の費用相場と見積もりの読み方、改修か作り直しかの判断、頼み先5タイプの使い分けと第6の選択肢(オフショアのラボ型で保守・改修チームを持つ)、相談前に聞く10の質問、よくある質問の順に解説します。費用表と頼み先の比較表は、稟議の資料にそのまま使える形にしました。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。改修・保守の相談で共通するのは「続く仕事を、毎回ゼロから頼んでいる」ことです。この記事を読み終えるころには、自社の改修の規模に合った頼み先と、稟議を通せる費用感がつかめているはずです。

システム改修・開発保守とは——開発・運用・保守の違いと、改修が「頼みづらい」3つの構造

「改修」と「保守」と「運用」は現場では混ざって使われますが、外注するときには切り分けが要ります。頼む内容が違えば、頼み先も契約も費用も変わるからです。ここでは3つの違いを表で整理し、次に、なぜ改修の外注は新規開発より頼みづらいのかを構造として言語化します。構造が分かれば、詰まりは自分の準備不足ではないと分かり、次の一手に進めます。

開発・運用・保守の違い(表)

コウェルの解説では「運用は現状維持を支える縁の下の力持ち、保守はシステムの進化と安定性の向上」と整理されています。本記事で扱う「システム改修」は、保守のうち機能追加・修正・変更にあたる作業です。新規開発と違い、すでに動いているシステムの理解と履歴の把握が必要になる点が、費用と頼み方を難しくしています。

改修が頼みづらい3つの構造——元の会社に頼みづらい、小さい案件で相性が悪い、社内に人がいない

私が相談で見てきた実態を整理すると、改修の外注には3つの構造的な詰まりがあります。

1つ目は、元の開発会社に頼みづらいことです。仕様を知っているはずの元の会社に頼むと、「現状を把握する工数」を乗せた高額な見積もりが返ってくる。担当者が異動・退職していれば引き継ぎ資料の読み込みも加わります。小規模な会社なら事業転換や廃業で連絡がつかないこともあり、会社が存続していても作ったエンジニアが辞めていれば、システムはブラックボックスです。この状態では、元の会社でも新しい会社でも調査コストは変わりません。

2つ目は、改修が「小さい案件」ゆえに開発会社と相性が悪いことです。「ボタンを1つ足したい」「帳票のレイアウトを直したい」といった限定的な作業でも、開発会社は営業・要件定義・設計・開発・テスト・PMの体制を動かすため固定費がかかり、最低受注額を設けています。加えて、既存システムがどう動いているかを把握する初期調査は作業の大小にかかわらず一定の工数が要るため、小さな改修ほど調査コストの比率が高く、割高に見えます。社内では大型の新規案件が優先され、小さな改修は着手まで2〜3か月待たされることもあります。

3つ目は、社内に改修できるエンジニアがいないことです。中小企業では情報システム担当が総務と兼任で、ソースコードを読める人がいない。だから外に頼むしかないのに、外に頼むと上の2つに当たる。これが「誰に、いくらで、どう頼めばよいか分からない」の正体です。

開発・運用・保守を分離すると起きること——「納品して終わり」と改善の停滞

もう1つ、頼み方の設計で押さえておきたいのは、開発と運用・保守を別の会社や別のチームに分けたときに起きる問題です。ハイブリッドテクノロジーズの解説は、開発側に「納品したら仕事は完了」というスタンスが生まれ、バグが残っていても保守側に任せればよいという投げやりさにつながること、業務が分離して連携がないと顧客のニーズを汲み取る力が弱まることを指摘しています。納品はスタートにすぎず、納品したものをどれだけ顧客のニーズに合わせて改善できるかが重要だ、という趣旨です。

私が2018年からホーチミンで約100社の相談を受けてきた中で、改修・保守の相談には2つの型があります。1つは「元の会社に頼んだら、小さな修正に100万円の調査費と言われた」。もう1つは「保守を担当していたエンジニアが退職して、改修が止まった」。どちらも、改修や保守が「続く仕事」なのに、単発の仕事として毎回ゼロから頼んでいることが根にあります。当社が支援している決済アプリは、新規開発を担当したチームがそのまま週次のリリースで保守と改修を続けており、調査コストが発生しません。この違いは体制の設計で決まります。では、外注するといくらかかり、見積もりはどう読めばよいのか。次章で整理します。

システム改修・保守の外注費用の相場と見積もりの読み方、改修か作り直しかの判断

改修費用は「見た目の変更量」ではなく「安全に変更するために確認すべき範囲」で決まります。入力欄を1つ増やすだけでも、データベース、検索、帳票、権限、外部連携まで修正が要ることがあるからです。ここでは規模別の相場、見積もりの内訳と確認項目、費用を左右する要因と契約方式、改修を続けるか作り直すかの判断を整理します。金額はいずれも税別の概算で、対象システムの状態と契約条件で変わります。

規模別の費用相場(表)

金額そのものは、一次統計にあたる公的な相場データが存在しないため掲載していません。費用のほとんどは人件費で、「人月単価×期間×人数」に諸経費が乗る構造です。小さな修正でも一定の最低費用がかかるのは、環境準備・現状調査・テスト・本番反映・作業記録まで行うからです。参考までに、当社のベトナム人エンジニアの単価は実務3年目安で1,500USD(約22.5万円)、5年で2,000USD、10年・ブリッジSEで3,000USDです(1USD=150円換算目安)。

見積もりの内訳と確認項目——含まれていないものが総額を決める

改修の見積もりは、現状調査・分析、要件定義、設計・開発・レビュー、テスト環境とテストデータの準備、回帰テスト(変更していない既存機能が壊れていないかの確認)、データ移行、本番反映と切り戻し準備、プロジェクト管理と報告、設計書・マニュアルの更新で構成されます。新規開発と比べて改修費用が読みにくいのは、最初の「現状調査」のコストが事前に見えないからです。設計書がない、コメントがない、作った人がいない状況では、中身を読み解くだけで相当な工数がかかり、初回の見積もりが「調査後に改修費用は別途」という二段階になることもあります。

見積書を受け取ったら、次を確認してください。

• 現状調査: 対象となる資料・機能・環境・外部連携が明記されているか
• テスト: 新機能だけでなく既存機能の回帰テストを含むか。テスト環境の構築費とデータ準備を含むか
• データ移行: 移行対象・変換・リハーサル回数・失敗時の対応を含むか
• リリース: 本番反映・立ち会い・バックアップ・切り戻しを含むか
• ドキュメント: 設計書・操作マニュアル・構成図を更新するか
• 対象外と追加費用: インフラ費・外部サービス費が対象外か、仕様変更時の単価と承認手順が決まっているか
• 保証・保守: 不具合の無償修正期間、受付時間、保守開始日

安く見える見積もりでも、調査・回帰テスト・データ移行・本番対応が含まれていなければ、最終的な支払額は高くなります。相見積もりは、全社に同じ資料と質問回答を共有して初めて公平になる、というのが実情です。

費用を左右する要因と契約方式——仕様確定なら請負、調査しながらなら準委任

費用差が生まれるのは機能数ではなく、不明点と変更リスクの大きさです。見積精度に直結するのは「正しいソースコードにアクセスできるか」「現行仕様を説明できる人がいるか」「どこまでテストすべきか」の3点です。仕様書がない、最新のソースコードが不明、複数機能が密接に結び付いている、決済・会計・在庫との外部連携が多い、データに表記揺れや重複が多い、個人情報や決済情報を扱う、短納期や夜間切り替えが要る、テスト環境がない。これらは費用が上がる状態で、発注前に資料・保管場所・停止可能時間を確認しておくと見積もりの幅が縮みます。

契約方式は不確実性に合わせます。仕様と影響範囲を確定できる改修なら、成果物と金額を決める請負契約が候補です。仕様書がなく調査しながら進めるなら、調査工程を準委任契約で切り出すほうが現実的です。不明点が多いまま固定金額を約束させると、大きな予備費が加算されるか、対象外項目が増えます。契約形態の違いは「準委任 請負 違い」の記事で整理しています。

改修を続けるか作り直すか——ブラックボックス化、保守単価の上昇、サポート終了

改修を重ねるうちにシステムが複雑化し、1回の改修コストがかさむようになると、「作り直したほうが結果的に安い」逆転が起きます。判断軸は3つです。設計書も担当者もいないブラックボックス化の度合い、COBOLやVB6など古い言語で扱えるエンジニアが減り保守単価が上がっていること、OSやミドルウェアのサポート終了です。経済産業省のDXレポートは、レガシーシステムを放置した場合に2025年以降で年間最大12兆円の経済損失が生じうると試算し、21年以上稼働する基幹システムが2025年に約6割を占めると指摘しました。

ただし、改修費が高いという理由だけで作り直す必要はありません。全面リニューアルにはデータ移行、業務手順の変更、利用者教育、並行稼働の費用が伴います。初期費用だけでなく、今後使う年数、年間保守費、障害時の事業影響、移行費、教育費を並べたTCO(総費用)で比較してください。判断が難しければ、まず現状調査だけを独立発注し、改修案とリニューアル案の比較を成果物として受け取る。これが、私が相談者にお伝えしている教訓です。

外注先5タイプの使い分けと第6の選択肢——「続く改修・保守」は専属チームで持つ(当社の答え)、相談前に聞く10の質問

頼み先を「元の開発会社か、新しい開発会社か」の2択で考えると詰まります。改修の外注先は5つのタイプに分かれ、規模・費用感・スピードで使い分けられます。ここでは5タイプの比較表、私が第6の選択肢としてお勧めしている「続く改修・保守を専属チームで持つ」形、相談前に聞く10の質問とよくある失敗を整理します。

頼み先5タイプ(表)

当社の整理です。中〜大規模で保守まで一体で任せたいなら開発会社系、継続的に体制を持ちたいならSES、小〜中規模でスポット・コスト重視ならクラウドソーシングやフリーランス、という住み分けになります。同じ改修でも頼み先で費用が変わるのは、中間マージン・体制コスト・最低受注額の3つが違うからです。

第6の選択肢——オフショアのラボ型で保守・改修チームを月額固定で持つ

5タイプに私が加えているのが、オフショアのラボ型で保守・改修の専属チームを持つ形です。改修や保守が「続く」ものなら、単発の請負を繰り返すたびに調査コスト・見積もり・稟議・立ち上げが発生します。同じチームが業務とコードベースを理解した状態を保てば、調査コストが消え、発注側は優先順位を決めるだけで改修が回ります。ハイブリッドテクノロジーズが指摘する「開発と保守の分離による責任放棄」も、同じチームが持ち続ければ起きません。

当社が支援している決済アプリでは、Stripe決済・二要素認証・ウォレット・PDF出力を含む新規開発の後、同じチームが週次のリリースで保守と改修を続けています。介護記録SaaS「CareViewer」では、日本語ブリッジSE1名とフルスタックエンジニア2名で、要件が動く改修を週次の優先順位判断で回し、従来の半分以下のコストで継続しています。当社は2,000名以上のIT人財データベースから直接アサインするため仲介マージンが乗らず、日本人PMをフロントに置くチームを1名から最短2週間で組め、実務3年目安1,500USD(約22.5万円)から単価を公開しています。仕様書がないシステムでも、引き継ぎのための現状調査から始められます。品質は日本人PMの設計レビュー、Gitプルリクエストによるコードレビュー、リリース前ダブルチェックで担保し、AIを活用した既存コードの解析も取り入れています。

ただし、月30万円以下の単発の軽微な修正や、年に数回しか手を入れないシステムには、専属チームは向きません。その場合はフリーランスやスポットの請負のほうが合うとお伝えしています。保守の稼働時間は、ベトナムとの時差2時間と祝日(2026年で年12日。労働法112条の法定は11日で、2026年からベトナム文化の日が加わる。加えてテト休暇)を踏まえてコアタイムと障害対応の受付時間を契約で決めます。

開発会社を見極める10の質問と、よくある失敗

改修では新規開発の実績だけでなく、他社が開発したシステムの調査や引き継ぎに対応できるかが重要です。GeekBridgeの質問リストを、当社が相談時にお答えしている形で整理しました。

1. 不明な仕様をどのような順序で調査しますか
2. 調査後に見積金額が変わる条件は何ですか
3. 変更による影響範囲をどのように特定しますか
4. 既存機能の回帰テストはどこまで行いますか
5. 発注者側で必要な作業と担当者は誰ですか
6. 課題・予算・進捗をどう共有しますか
7. 担当者が交代した場合、情報をどう引き継ぎますか
8. 本番反映に失敗した場合、どのように元へ戻しますか
9. 改修後のソースコードと設計書はどこへ保管しますか
10. 保守を別の会社へ移す場合、どのような引き継ぎが可能ですか

よくある失敗は、口頭だけで依頼して完成条件がずれる、最安値だけで決めて調査とテストが不足する、機能を一度に詰め込んで影響範囲と手戻りが増える、現行保守会社への連絡が遅れて資料とアクセス権を引き継げない、受入担当者を決めずに問題発見が本番後になる、本番データだけで確認して情報漏えいや業務停止につながる、切り戻しを準備せず障害時に再開できない、の7つです。とくに現行保守会社との契約内容と解約予告期間は、年度末の更新前に確認してください。あなたの改修は、単発の仕事でしょうか、それとも続く仕事でしょうか。

システム改修・開発保守の外注でよくある質問

改修・保守の外注について、相談の場で繰り返し聞かれる質問を5つにまとめました。稟議や相見積もりの準備にお使いください。

Q1. 小さな修正はいくらから頼めますか?

改修規模としては最も小さい部類ですが、一律の下限額はありません。修正そのものは小さくても、環境準備・現状調査・テスト・本番反映・作業記録が要るため最低費用がかかります。他社が作ったシステムでは、修正より調査のほうが大きくなることもあります。

Q2. 仕様書がなくても頼めますか?

頼めます。ただし現状調査の工数が増えるため、調査を独立した工程として先に発注し、構成図・影響範囲・改修案とリニューアル案の比較を成果物として受け取るのが安全です。当社も引き継ぎ調査から始められます。

Q3. 現在の保守会社とは別の会社に改修を頼めますか?

頼めます。ただし、ソースコードの権利と保管場所、アクセス権、現行保守契約の解約予告期間と引き継ぎ条件を先に確認してください。連絡が遅れると資料とアクセス権を引き継げず、調査コストが膨らみます。

Q4. オフショアで保守は成立しますか?

成立します。時差2時間で日本の日中とベトナムの稼働が重なり、日本人PMをフロントに置けば日本語で運用できます。当社は決済アプリの週次保守やSaaSの継続改修を専属チームで続けています。障害対応の受付時間と祝日の扱いは契約で決めます。

Q5. 改修と作り直しはどう判断すればよいですか?

ブラックボックス化の度合い、対応できるエンジニアの減少と保守単価の上昇、基盤のサポート終了の3つが重なっていれば作り直しの検討時期です。初期費用ではなく、今後使う年数・年間保守費・移行費・教育費を並べたTCOで比較する判断。

まとめ: 改修・保守は規模に合った頼み先で詰まりが解ける——単発はスポット、続くなら専属チーム

既存システムの改修や開発保守の外注で「誰に、いくらで、どう頼めばよいか」が見えないのは、改修という案件の性質(小さくて調査コストが読めない)と、開発会社のビジネスモデル(最低受注額・大型案件優先)のミスマッチが原因です。元の開発会社も担当者が退職していればブラックボックスで、新規の会社と調査コストは変わりません。運用(監視・定型)と保守(不具合修正・機能追加・アップデート)を切り分け、改修は保守の一部として「続く仕事」と捉えてください。

費用は、軽微な修正・小規模な機能追加・中規模な機能改修・大規模な改修・全面リニューアルの順に大きくなり、現状調査だけなら改修本体より小さく収まります。見積もりは総額ではなく、現状調査・回帰テスト・データ移行・本番反映と切り戻し・ドキュメント更新が含まれるかで読み、仕様が確定していれば請負、調査しながら進めるなら準委任で契約します。改修を続けるか作り直すかは、ブラックボックス化・保守単価の上昇・サポート終了の3つと、移行費や教育費を含めたTCOで判断してください。

頼み先は、元の開発会社・新規の開発会社・SES・クラウドソーシング・フリーランスの5タイプに、続く改修・保守を専属チームで持つオフショアのラボ型を加えた6つから、規模と継続性で選びます。当社は2,000名以上の人財データベースから直接アサインし、日本人PMをフロントに置く保守・改修チームを1名から最短2週間、公開単価で組み、仕様書がないシステムの引き継ぎ調査からも始められます。単発の軽微な修正にはスポットをお勧めします。契約形態の違いは準委任と請負の違い、専属チームの仕組みはラボ型開発とはもあわせてご覧ください。現在のシステムの状態と改修の内容をお聞かせいただければ、調査から始めるか、チームで持つかの判断と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。