レガシーシステムの改修は、困っている範囲を明確にしてから外部へ発注するのが基本です。まず現状を整理して課題に優先順位をつけ、RFP（提案依頼書）を整えます。
全面刷新には数千万円規模の投資が必要です。そこで、改修範囲を決めたうえで、費用、契約、ロックイン回避、発注先の選び方を順に確認します。
▼全体ガイドの記事
・レガシーシステム改修の完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
レガシーシステム改修の発注・外注の全体像
レガシーシステムの改修を外部に委託するといっても、範囲や進め方は一様ではありません。まずは「改修」が指すスコープを整理し、なぜ社内だけで完結させず外注するのかを言葉にしておくことが、発注の第一歩になります。
特に、全面刷新ではなく部分的な改善を選ぶ場合は、スコープの線引きが費用対効果を大きく左右します。
改修・刷新・移行の違いとスコープの考え方
レガシーシステムへの対処は、規模の違いに応じて連続したものとして捉えると整理しやすくなります。代表的な選択肢には、全面的に作り直す「刷新（モダナイゼーション）」のほか、別製品や基盤へ置き換える「リプレイス」、クラウドへ動かす「移行」があります。
- 刷新：全体を作り直すため、数千万円規模の投資が必要になる
- 改修：一部に絞って手を入れるため、投資を抑えやすい
本記事のテーマである「改修」は、既存システムを活かしながら、部分的な機能追加や不具合の解消、性能改善を行うアプローチです。改修の強みは、課題が出ている箇所だけを切り出して対応できるため、短期間で効果を得やすい点にあります。
たとえば「帳票出力の処理速度を改善したい」「特定の外部サービスとAPI連携を追加したい」といった具体的なニーズに、ピンポイントで応えられます。
一方で、改修には限界もあります。古いプログラム言語やデータモデルそのものが技術的負債となっている場合、表面的な改修を重ねるほど内部構造が複雑化し、かえって保守性が悪化することがあります。
改修の範囲を決める際は、改修対象と移行データを具体的に決めておきます。本番に移す前には、リハーサルと受入テストを行い、改修後の動きを確かめます。
改修を発注する前に、部分改修で十分か、それとも段階的な刷新を見据えるべきかを見極めることが重要です。発注時には、この見極めも含めてベンダーに相談できる体制が望ましいといえます。
外注・委託が必要になる理由
レガシーシステムの改修を外部へ委託する最大の理由は、社内のIT人材が不足していることです。IPAは約4,000社を対象に調査を行い、799社から回答を得ました。また、レガシーを放置すると、調達元や提供先にも影響が及びます。
さらに、2030年には最大で79万人のIT人材が不足すると予測されています。そのため、人海戦術による内製だけで改修を進めるのは、現実的ではなくなりつつあります。
- 人材：社内の人手だけでは、改修の体制を組みにくい
- 専門性：古い仕組みを読み解く技術を、外部から補える
加えて、レガシーシステムはブラックボックス化しているケースが少なくありません。設計書が残っておらず、開発当時の担当者も不在という状況では、改修箇所の影響範囲を正確に把握するのが難しくなります。
こうしたシステムを安全に改修するには、リバースエンジニアリングやコード解析の専門知識を持つ外部ベンダーの力が欠かせません。外注は人手を補うだけでなく、専門性とリスク分散の手段でもあります。
外注する際も、改修対象と移行データを発注側で決めておくと、ベンダーに求める範囲を正しく伝えられます。本番に切り替える前には、リハーサルと受入テストで動作を確かめます。
改修中も既存業務を止めずに進めるには、テスト環境を整え、段階的にリリースする計画が求められます。その計画を組めるかどうかで、ベンダーの経験の差が表れます。自社にない知見を外部から取り込めば、改修の成功確率を大きく高められます。
発注前の準備
改修の外注で失敗するケースの多くは、発注前の準備が足りないことに原因があります。要望が曖昧なまま見積もりを依頼すると、ベンダーごとに前提条件がばらつき、提案を正確に比べられません。
発注の質は準備の質で決まります。そのため、現状を整理してRFPをまとめることに時間をかけると、結果としてコストと手戻りを抑えられます。
現状の可視化と課題の優先順位づけ
発注準備の出発点は、いまのシステムを洗い出すことです。どの機能がどの業務で使われ、どこに不満や障害が集中しているのかを整理します。
改修は対象を絞るのが前提のため、すべての課題を一度に解決しようとせず、優先順位をつけることが肝心です。
- 業務インパクト：業務への影響が大きい課題を優先する
- 費用対効果：限られた費用で効果が大きい改修を選ぶ
このとき有効なのが、「勇気ある廃止」という発想です。長年使われていない機能や、もはや業務の実態に合わない処理は、改修の対象から外して思い切って廃止します。そうすれば、改修の範囲とコストを圧縮できます。
廃止で浮いた予算は、本当に重要な機能の改善に集中して充てられます。そのぶん、限られた投資で最大の効果を引き出せます。
社内の当事者だけで現状を整理すると、当事者バイアスで課題を見落としがちです。アセスメントの段階から外部の専門家に伴走してもらい、客観的な視点で現状を診断する方法もあります。
見積もりを読むときは、費用を人件費、開発、移行、運用に分けて確かめます。教育費や並行稼働の費用、基盤費といった隠れコストも、あわせて見込んでおきます。
改修する箇所と廃止する箇所の線を引いておくと、その後の見積もりの精度が格段に上がります。
RFP（提案依頼書）の作成ポイント
RFPは、改修の目的と要件をベンダーに伝えるための中核となる文書です。改修では、「何を」「なぜ」改善したいのかを整理し、達成したい状態を文章にすることが重要です。
たとえば「入力エラー率を現状から半減させたい」のように、ゴールを数字で示します。数字があると、ベンダーの提案を同じ条件で比べられます。
- 業務理解：対象業務と連携先の知識の深さ
- 実績確認：移行の経験と支援体制の比較
RFPには、現行システムの技術情報も可能な限り盛り込みます。使用言語、ミドルウェア、サーバー構成、外部システムとの連携状況などを開示すれば、ベンダーは改修の難易度とリスクを正確に見積もれます。情報が不足していると、ベンダーは見えない部分を見込んで見積もりを高めに出すか、後から追加費用を請求する可能性が高まります。
あわせて、納期や予算の上限、検収条件、保守運用の引き継ぎ方法といった非機能面の要件も記載しておきます。これらをRFPで明確にしておくと、提案の段階で各社の対応方針を横並びに比べられ、発注後の認識のずれも防げます。RFPの内容が詳しいほど、ベンダーの提案も精度が上がり、改修の質の向上につながります。
改修の費用相場とコストの内訳
改修を発注するうえで、最も気になるのが費用です。レガシー対処は、全面刷新の場合で500万円から2億円規模になることがあります。一方、範囲を限定した部分改修なら、難易度に応じて費用を抑えられます。
重要なのは、見積もりに表れる費用だけでなく、見落としがちな隠れコストも含めて全体像をつかむことです。
費用の内訳と人件費の考え方
システム改修の費用は、その大部分が人件費、つまり工数で構成されます。費用は「エンジニアの単価×投入工数（人月）」で算出するのが基本です。
- 難易度：改修内容の難しさによって、単価が変わる
- 技術者：古い言語や特殊な環境では対応できる人が限られ、単価が上がりやすい
改修の費用は、おおまかにアセスメント（現状調査）、設計・開発、テスト、データ移行や連携調整、リリース対応といった工程ごとに積み上がります。部分改修であっても、影響範囲の調査やテストは省けません。
とくにブラックボックス化したシステムは、改修箇所の特定と影響調査だけで相応の工数がかかるため、あらかじめ見込んでおく必要があります。
見積もりを受け取ったら、総額だけでなく工数の内訳も確かめます。どの工程に何人月を充てているかが示されていれば、価格が妥当かどうかを判断できます。一方で、内訳が不透明な「一式」見積もりは、後から追加費用が生じたり、認識のずれを招いたりしやすいため注意が必要です。
見落としがちな隠れコスト
改修費用の見積もりで見落とされやすいのが、データ移行や連携にまつわる隠れコストです。改修に伴ってデータ構造を変える場合は、既存データのクレンジングやマッピングが必要になります。
文字コードの違いや外字、長年たまった不整合データの整理は、軽く見ると予算超過に直結します。
- データ整理：外字や不整合データの手直しには、想定以上の工数がかかることが多い
- 並行稼働：新旧の両方を動かす期間の負担を、見積もりに入れておく
データ移行や連携の費用を見込むには、ベンダーが対象業務と連携先の知識をどこまで持つかを確かめ、移行の経験と支援体制を比べておきます。
新旧システムを一定期間並行稼働させる場合、見逃せないのが二重の費用です。改修版を本番に投入する前に旧環境と並べて検証する期間は、運用負荷とインフラ費用がどちらも重なります。
現場担当者への教育費や、新たに導入するツール・ライブラリのライセンス費用も、初期見積もりに含まれていないことがあります。
こうした隠れコストを抑えるには、初期費用の比較だけで発注先を決めないことが大切です。「改修後にランニングコストがいくら下がるか」を試算しておくと、判断しやすくなります。中長期の投資対効果で見れば、経営層に説明する材料にもなります。
委託の進め方と契約形態の使い分け
改修を外注する際は、見積もり金額と同じくらい契約の組み立て方が重要です。契約形態を誤ると、責任の所在が曖昧になったり、想定外の費用が生じたりして、トラブルの元になります。
工程ごとに契約形態を使い分けることが、リスクを抑えた発注の鍵になります。
準委任契約と請負契約の使い分け
システム改修の委託で押さえておきたいのが、準委任契約と請負契約の違いです。準委任契約は業務の遂行そのものを委託する形態で、完成させる責任までは負わない代わりに、柔軟に作業を進められます。
請負契約は完成を約束する形態で、納品したものに対する責任が明確になります。
- 契約の切替：段階ごとに準委任と請負を分ける
- 責任の範囲：SLAと担当範囲を文書に残す
レガシー改修では、仕様が固まりにくい現状調査やアセスメントを準委任契約とし、要件が確定した開発や実装を請負契約とする使い分けが有効です。ブラックボックス化したシステムは、事前に全容を把握しきれません。そのため、調査の段階で完成の責任を求めると、ベンダーがリスクを織り込み、見積もりが高額になりがちです。
工程ごとに契約を分ければ、発注側と開発会社の双方にとって無理のないリスク配分になります。
契約には、SLA（サービス品質保証）や責任分界点も明記しておきます。改修後の障害は、既存部分か改修部分かで責任が変わるため、ベンダーの責任範囲を区切っておくと、トラブルを避けやすくなります。
ベンダーロックインを防ぐ契約の工夫
レガシーシステムがブラックボックス化した背景には、特定ベンダーへの過度な依存、いわゆるベンダーロックインがあります。同じ轍を踏まないためには、改修を発注する段階から契約で工夫しておくことが欠かせません。
とくに、ソースコードの著作権や改修後のドキュメントについては、契約条項にはっきり盛り込んでおく必要があります。
- ソースコード：別の担当者やベンダーでも保守できる状態で受け取る
- 運用権限：本番環境へのアクセス権を発注側が持つ
契約書には、改修対象と移行データの範囲を明記しておきます。納品前のリハーサルと受入テストについても、契約で段取りを取り決めておきます。
改修で生まれたソースコードの権利が発注側に帰属するか、ベンダー側に残るかは、将来の保守や別ベンダーへの切り替えを大きく左右します。そのうえで、改修内容を記録した設計書とテスト仕様書も納品してもらいます。これにより、担当者やベンダーが変わっても引き継ぎやすくなり、ブラックボックス化を防げます。
標準的な技術やオープンな仕様を採用しているベンダーを選べば、特定の企業に縛られるリスクを下げられます。
ロックインを避けるかどうかは、目先の改修費用以上に、中長期の自由度とコストを左右します。
発注先の選定基準と失敗回避のポイント
改修の成否は、どのベンダーに発注するかで大きく変わります。安さだけで選ぶと、改修の品質や保守体制で後悔することになりかねません。
技術力や実績に加えて、自社の業務をどれだけ理解してくれるか、契約に対してどう向き合うかまで含めて総合的に評価することが、失敗を避ける近道です。
技術力と業務理解の見極め方
発注先を評価する第一の基準は、改修対象の技術への対応力です。古い言語や特殊な基盤を扱う改修では、その技術分野での実績があるかどうかが決め手になります。
過去の類似プロジェクトの事例や、対応できる技術の範囲を具体的に確かめます。レガシー解析やリバースエンジニアリングの経験があるベンダーなら、ブラックボックス化したシステムでも任せられます。
- 現状把握：業務フローと既存機能を、発注側で一覧にしておく
- 要件整理：改修の範囲と連携の条件を、ベンダーに示せる形にする
技術力と同じくらい重視したいのが、自社の業務をどれだけ理解しているかです。システムは業務を支える道具であり、業務の文脈を理解していないベンダーは、技術的には正しくても現場で使えない改修をしてしまうことがあります。
提案の段階で自社の業務課題を的確にくみ取り、踏み込んだ質問をしてくるベンダーなら、業務理解の姿勢があるといえます。
コンサルティングから開発、運用までを一貫して支援できる体制があるかどうかも、評価のポイントです。改修は単発で終わらず、その後の保守や追加の改善へ続くことが多いためです。上流の課題整理から実装、定着の支援まで通して相談できるパートナーなら、改修を起点に継続的な改善を見込めます。
よくある失敗と対策
改修発注でよくある失敗の一つが、現場からの反発です。「前のシステムではこうできた」という声に押されて既存の例外ルールをすべて残そうとすると、改修が複雑になり、費用も大きく膨らみます。
標準機能に業務を合わせるFit to Standardの発想を持つことが、コストの抑制と保守性の向上を両立させることにつながります。
- 例外ルール：残す例外は、本当に必要なものだけに限る
- データモデル：変更速度と拡張性を左右する要素
もう一つの典型的な失敗は、データモデルの見直しを後回しにしたまま、表面的な改修を重ねることです。コードだけを直しても、中身のデータ構造が古いままでは、変更速度や拡張性は改善されません。改修のたびに対応コストが増える悪循環に陥らないよう、データ構造にまで踏み込んで提案できるベンダーを選ぶことが大切です。
こうした失敗を避けるには、現場を巻き込みながら変化を進めることが欠かせません。改修の目的とメリットを丁寧に説明して現場の納得を得られると、導入後の定着がスムーズになります。
ベンダーを選ぶ段階で、対象業務と連携先の知識を持っているかを確かめ、移行の経験と支援体制を比べておくと、判断の材料がそろいます。
複数社から提案を取り、技術、業務理解、契約への姿勢を横並びで比べながら、自社の改修を任せられるパートナーを慎重に見極めます。
まとめ
外部へ発注・委託する際は、まず改修の範囲を明確にします。そのうえで、現状の整理、課題の優先順位づけ、質の高いRFPの作成に時間をかけることが成功の前提です。部分改修を選ぶからこそ、何を直し何を廃止するかの線引きが、費用対効果を大きく左右します。
費用は人件費だけでなく、データ移行、並行稼働、教育費も含めて把握します。初期費用だけでなく、運用コストの低減も試算して判断します。
契約では、準委任と請負を工程ごとに使い分け、ソースコードの権利やドキュメントの納品を盛り込みます。こうした工夫が、ベンダーロックインを回避し、中長期の自由度を守ります。
IT人材の不足は今後も続くと予測されており、レガシーの放置は自社だけでなく取引先にも影響が及びます。
技術力と業務理解、そして誠実な契約姿勢を兼ね備えたパートナーを選び、現場を巻き込みながら改修を進めれば、限られた投資で着実な成果を引き出せます。
本記事を、自社の改修発注を成功へ導く実務の指針として活用いただければ幸いです。
▼全体ガイドの記事
・レガシーシステム改修の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。