レガシーシステム改修の発注/外注/依頼/委託方法について

長年使い続けてきた基幹システムや業務システムが、いつの間にか「触れるのが怖い存在」になっていないでしょうか。ドキュメントが残っておらず、改修できる担当者も退職し、わずかな機能追加にも見積もりが膨らむ。こうしたレガシーシステムの悩みは、いまや特定の業界に限った話ではありません。全面刷新には数千万円規模の投資が必要となるため、まずは「困っている部分だけを部分的に改修したい」「特定の機能だけ外注して直したい」と考える企業が増えています。

本記事では、レガシーシステム改修を外部のベンダーへ発注・外注・委託する具体的な方法を、実務とプロジェクトマネジメントの視点から徹底的に解説します。発注前の準備からRFPの作り方、費用相場と隠れコスト、契約形態の使い分け、ベンダーロックインの回避策、そして失敗しない発注先の選び方までを一気通貫で網羅しました。IPA（情報処理推進機構）の調査データなど一次情報も交えながら、担当者がそのまま社内で活用できる実践知をお届けします。読み終えるころには、自社の改修プロジェクトをどう発注すれば費用対効果を最大化できるのか、明確な道筋が見えるはずです。

▼全体ガイドの記事
・レガシーシステム改修の完全ガイド

レガシーシステム改修の発注・外注の全体像

レガシーシステムの改修を外部に委託すると言っても、その範囲や進め方は一様ではありません。まずは「改修」という言葉が指すスコープを整理し、なぜ自社だけで完結させずに外注するのかという前提を明確にすることが、発注成功の第一歩となります。全面刷新ではなく部分的な改善を選ぶ場合こそ、スコープの線引きが費用対効果を大きく左右します。

レガシーシステムへの対処は、その規模に応じて連続的なグラデーションで捉えると整理しやすくなります。全面的に作り直す「刷新（モダナイゼーション）」、別の製品や基盤へ置き換える「リプレイス」、データや基盤をクラウドへ動かす「移行」、そして本記事のテーマである「改修」が代表的な選択肢です。改修は、既存システムを活かしながら部分的な機能追加や不具合解消、性能改善を行うアプローチを指します。

改修の最大の特徴は、スコープを限定できる点にあります。システム全体に手を入れる刷新と異なり、課題が顕在化している箇所だけを切り出して対応するため、初期投資を抑えながら短期間で効果を出すことが可能です。たとえば「帳票出力の処理速度を改善したい」「特定の外部サービスとAPI連携を追加したい」といった具体的なニーズに、ピンポイントで応えられます。

一方で、改修には限界もあります。古いプログラム言語やデータモデルそのものが技術的負債となっている場合、表面的な改修を重ねるほど内部構造が複雑化し、かえって保守性が悪化することがあります。改修を発注する前に「これは部分改修で十分か、それとも段階的な刷新を見据えるべきか」を見極めることが重要です。発注時には、この見極めも含めてベンダーに相談できる体制が望ましいといえます。

レガシーシステムの改修を外部へ委託する最大の理由は、社内のIT人材不足です。IPAが約4,000社を対象に実施し799社から回答を得た調査でも、レガシーシステムの放置がサプライチェーン上の調達元や提供先にまで負の波及を及ぼすことが指摘されています。さらに2030年には最大で79万人のIT人材が不足すると予測されており、人海戦術による内製だけで改修を進めるのは現実的ではなくなりつつあります。

加えて、レガシーシステムはブラックボックス化しているケースが少なくありません。設計書が残っておらず、開発当時の担当者も不在という状況では、改修箇所の影響範囲を正確に把握することが困難です。こうしたシステムを安全に改修するには、リバースエンジニアリングやコード解析の専門知識を持つ外部ベンダーの力が欠かせません。

外注は単なる人手の補充ではなく、専門性とリスク分散の手段でもあります。改修中に既存業務が止まらないよう、テスト環境の構築や段階的なリリース計画を担保できるかどうかは、経験豊富なベンダーの腕の見せどころです。自社にない知見を外部から取り込むことで、改修プロジェクトの成功確率を大きく高められます。

発注前に準備すべきこと

改修の外注で失敗する多くのケースは、発注前の準備不足に起因します。曖昧な要望のまま見積もりを依頼すると、ベンダーごとに前提条件がばらつき、正確な比較ができません。発注の品質は準備の品質で決まると考え、現状の可視化とRFP（提案依頼書）の整備に時間をかけることが、結果的にコストと手戻りを抑えます。

発注準備の出発点は、現状システムの棚卸しです。どの機能がどの業務で使われ、どこに不満や障害が集中しているのかを整理します。改修はスコープ限定が前提となるため、すべての課題を一度に解決しようとせず、業務インパクトと費用対効果の観点から優先順位をつけることが肝心です。

このとき有効なのが「勇気ある廃止」という発想です。長年使われていない機能や、もはや業務実態に合わない処理を改修対象から外し、思い切って廃止することで、改修の範囲とコストを圧縮できます。浮いた予算を本当に重要な機能の改善に集中投下すれば、限られた投資で最大の効果を引き出せます。

現状可視化は社内だけで完結させようとすると、当事者バイアスで課題を見落としがちです。アセスメント段階から外部の専門家に伴走してもらい、客観的な視点で現状を診断する方法もあります。改修すべき箇所と廃止すべき箇所の線引きが明確になれば、その後の見積もり精度が格段に向上します。

RFPは、ベンダーに改修の目的と要件を伝えるための中核ドキュメントです。改修の場合は「何を」「なぜ」改善したいのか、達成したい状態を明文化することが重要です。たとえば単に「画面を直してほしい」ではなく、「入力エラー率を現状から半減させたい」というように、目指すゴールを定量的に示すと、ベンダーから具体的で比較可能な提案が得られます。

RFPには現行システムの技術情報も可能な限り盛り込みます。使用言語、ミドルウェア、サーバー構成、外部システムとの連携状況などを開示することで、ベンダーは改修の難易度とリスクを正確に見積もれます。情報が不足していると、ベンダーはリスクを織り込んで見積もりを高めに出すか、後から追加費用を請求する可能性が高くなります。

あわせて、納期や予算の上限、検収条件、保守運用の引き継ぎ方法といった非機能面の要件も記載しておきます。これらをRFPで明確にしておくと、提案段階で各社の対応方針を横並びで比較でき、発注後の認識齟齬を防げます。RFPの完成度が高いほど、ベンダーの提案も精緻になり、最終的な改修の質が向上します。

改修の費用相場とコストの内訳

改修を発注するうえで最も気になるのが費用です。レガシーシステムの対処にかかる費用は、全面刷新で500万円から2億円規模に及ぶこともありますが、スコープを限定した部分改修であれば、その範囲と難易度に応じて大きく圧縮できます。重要なのは、表に見える費用だけでなく、見落とされがちな隠れコストまで含めて全体像を把握することです。

システム改修の費用は、その大部分が人件費すなわち工数で構成されます。費用は「エンジニアの単価×投入工数（人月）」で算出されるのが基本で、改修内容の難易度と対応する技術者のスキルレベルによって単価が変動します。古い言語や特殊な環境への対応が必要な場合は、対応できる技術者が限られるため単価が上がる傾向があります。

改修の費用は、おおまかにアセスメント（現状調査）、設計・開発、テスト、データ移行や連携調整、リリース対応といった工程ごとに積み上がります。部分改修であっても、影響範囲の調査やテストは省略できません。とくにブラックボックス化したシステムでは、改修箇所の特定と影響調査だけで相応の工数を要する点を見込んでおく必要があります。

見積もりを受け取ったら、総額だけでなく工数の内訳を必ず確認します。どの工程に何人月を充てているのかが明示されていれば、価格の妥当性を判断できます。内訳が不透明な「一式」見積もりは、後の追加費用や認識齟齬の温床となりやすいため注意が必要です。

改修費用の見積もりで見落とされやすいのが、データ移行や連携にまつわる隠れコストです。改修に伴ってデータ構造を変更する場合、既存データのクレンジングやマッピングが必要になります。文字コードの差異や外字、長年蓄積された不整合データの整理には想定以上の工数がかかることが多く、ここを軽視すると予算超過に直結します。

新旧システムを一定期間並行稼働させる場合の二重コストも見逃せません。改修版を本番投入する前に旧環境と並行して検証する期間は、運用負荷とインフラ費用が二重にかかります。さらに、現場担当者への教育費や、新たに導入するツール・ライブラリのライセンス費用も、初期見積もりに含まれていないことがあります。

こうした隠れコストを抑えるには、初期費用の比較だけで発注先を決めないことが大切です。むしろ「改修後にランニングコストがどれだけ下がるか」という運用コスト低減のシミュレーションを行い、中長期の投資対効果で判断する視点が、経営層への稟議を通すうえでも説得力を持ちます。

委託の進め方と契約形態の使い分け

改修を外注する際、見積もり金額と同じくらい重要なのが契約の組み立て方です。契約形態を誤ると、責任の所在が曖昧になったり、想定外の費用が発生したりとトラブルの火種になります。改修プロジェクトの工程に応じて契約形態を適切に使い分けることが、リスクを抑えた発注の鍵となります。

システム改修の委託で押さえておきたいのが、準委任契約と請負契約の違いです。準委任契約は業務の遂行そのものを委託する形態で、成果物の完成責任は負わない代わりに、柔軟に作業を進められます。一方、請負契約は成果物の完成を約束する形態で、納品物に対して責任が明確になります。

レガシー改修では、仕様が固まりにくい現状調査やアセスメントの段階を準委任契約とし、要件が確定した開発・実装の段階を請負契約とする使い分けが有効です。ブラックボックス化したシステムは事前に全容を把握しきれないため、調査段階で完成責任を求めると、ベンダーがリスクを織り込んで高額になりがちです。工程ごとに契約を分けることで、双方にとって無理のないリスク配分が実現します。

契約には、SLA（サービス品質保証）や責任分界点も明記しておきます。改修後の障害が既存部分に起因するのか改修部分に起因するのかで責任の所在が変わるため、どこまでがベンダーの責任範囲かを線引きしておくことが、後のトラブル回避につながります。

レガシーシステムがブラックボックス化した背景には、特定ベンダーへの過度な依存、いわゆるベンダーロックインがあります。改修を発注する際に同じ轍を踏まないためには、契約段階での工夫が不可欠です。とくにソースコードの著作権や、改修後のドキュメント整備について、契約条項に明確に盛り込んでおく必要があります。

改修で生み出されたソースコードの権利が発注側に帰属するのか、ベンダー側に残るのかは、将来の保守や別ベンダーへの切り替えを大きく左右します。あわせて、改修内容を記録した設計書やテスト仕様書の納品を契約に含めておくと、次の担当者やベンダーが内容を引き継ぎやすくなり、再びブラックボックス化することを防げます。

運用権限や本番環境へのアクセス権を発注側が保持できるようにしておくことも重要です。標準的な技術やオープンな仕様を採用しているベンダーを選べば、特定企業に縛られるリスクを下げられます。ロックイン回避は、目先の改修費用以上に、中長期の自由度とコストに影響する論点です。

発注先の選定基準と失敗回避のポイント

改修の成否は、どのベンダーに発注するかで大きく変わります。安さだけで選ぶと、改修品質や保守体制で後悔することになりかねません。技術力や実績だけでなく、自社の業務をどれだけ理解してくれるか、そして契約に対する姿勢まで含めて総合的に評価することが、失敗を避ける近道です。

発注先を評価する第一の軸は、改修対象の技術への対応力です。古い言語や特殊な基盤を扱う改修では、その技術領域での実績があるかどうかが決定的に重要です。過去の類似プロジェクトの事例や、対応可能な技術スタックを具体的に確認しましょう。レガシー解析やリバースエンジニアリングの経験があるベンダーは、ブラックボックス化したシステムでも安心して任せられます。

技術力と同じくらい重視したいのが、自社の業務に対する理解度です。システムは業務を支える道具であり、業務の文脈を理解していないベンダーは、技術的には正しくても現場で使えない改修をしてしまうことがあります。提案段階で自社の業務課題を的確に汲み取り、踏み込んだ質問をしてくるベンダーは、業務理解の姿勢があると判断できます。

コンサルティングから開発、運用までを一気通貫で支援できる体制があるかどうかも、評価のポイントです。改修は単発で終わらず、その後の保守や追加改善へと続くことが多いためです。上流の課題整理から実装、定着支援までを通して相談できるパートナーであれば、改修を起点にした継続的な改善が見込めます。

改修発注でよくある失敗の一つが、現場の反発です。「前のシステムではこうできた」という声に押され、既存の例外ルールをすべて維持しようとすると、改修が複雑化して費用が膨れ上がります。標準機能に業務を合わせるFit to Standardの発想を持ち、本当に必要なカスタマイズだけに絞ることが、コスト抑制と保守性向上の両立につながります。

もう一つの典型的な失敗が、データモデルの見直しを放置したまま表面的な改修を重ねることです。コードだけを直してもデータ構造が古いままでは、変更速度や拡張性は改善されません。改修のたびに対応コストが増えていく悪循環に陥らないよう、データモデルにまで踏み込んだ提案ができるベンダーを選ぶことが大切です。

こうした失敗を避けるには、現場を巻き込んだチェンジマネジメントが欠かせません。改修の目的とメリットを丁寧に説明し、現場の納得を得ながら進めることで、導入後の定着がスムーズになります。複数社から提案を取り、技術・業務理解・契約姿勢を横並びで比較しながら、自社の改修を任せられるパートナーを慎重に見極めましょう。

まとめ

レガシーシステムの改修を外部へ発注・委託する際は、まず改修のスコープを明確にし、現状の可視化と優先順位づけ、そして質の高いRFP作成という準備工程に十分な時間をかけることが成功の前提となります。全面刷新ではなく部分改修を選ぶからこそ、何を直し何を廃止するかの線引きが、費用対効果を大きく左右します。

費用面では、表に見える人件費だけでなく、データ移行や並行稼働、教育費といった隠れコストまで含めて全体像を把握し、初期費用の比較ではなく運用コスト低減のシミュレーションで判断することが重要です。契約では準委任と請負を工程ごとに使い分け、ソースコードの権利やドキュメント納品を盛り込んでベンダーロックインを回避する工夫が、中長期の自由度を守ります。

IPAの調査が示すとおり、IT人材不足は今後さらに深刻化し、レガシーの放置は自社だけでなく取引先にも影響を及ぼします。技術力と業務理解、そして誠実な契約姿勢を兼ね備えたパートナーを選び、現場を巻き込みながら改修を進めることで、限られた投資で着実な成果を引き出せます。本記事を、自社の改修発注を成功へ導く実務の指針として活用していただければ幸いです。

▼全体ガイドの記事
・レガシーシステム改修の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。