レガシーコード改善の外注｜全面刷新を避ける判断軸と進め方

「このコードは触ると壊れるので、改修には時間とお金がかかります」——システムの改修を依頼するたびに、ベンダーや社内のエンジニアからこう言われていないでしょうか。古いソースコードが積み重なり、見積もりも工期も読めない。それでも経営層からは「いい加減に何とかしてほしい」と迫られる。コードを書けない立場だと、何から手をつければよいのか見当もつきません。

多くの発注担当者がこの段階で「いっそ全面的に作り直すしかないのか」と考えます。しかし全面刷新は数千万円規模の投資と長い開発期間を伴い、失敗すれば事業そのものが止まりかねない選択です。予算も工期も怖くて踏み出せず、結局また改修を先送りする——この堂々巡りに陥っている方は少なくありません。

本当に難しいのは「技術」ではなく「発注の意思決定」です。何をどこまで外注すべきか、誰に頼めばよいのか、いくらかかるのか。これらの判断材料がそろわない限り、社内でも経営層でも合意は取れません。逆に言えば、判断軸さえ整理できれば、いきなり全面刷新に飛びつかずに、現状把握から小さく始める発注計画を描けるようになります。

本記事では、コードを書けない発注者の立場から、レガシーコード改善を外注する際の判断軸と進め方を整理します。外注すべきかの判断、現状把握（コード診断）の依頼方法、外注先と契約形態の選び方、費用と期間の見立て方まで、発注計画の骨子を組み立てられるよう順を追って解説します。

レガシーコードの改善を外注する前に整理すべきこと

外注先を探し始める前に、まず「自社が今どんな状態にあるのか」を発注者自身の言葉で整理しておくことが大切です。ここを飛ばして見積もりを取りに行くと、業者ごとにバラバラの前提で提案が返ってきて、比較すらできなくなります。

レガシーコードとは（保守性・技術的負債を発注者目線で説明）

レガシーコードとは、長年の改修の積み重ねによって構造が複雑になり、変更や保守が難しくなった古いソースコードを指します。エンジニアの間では「テストがなく、安心して手を入れられないコード」と表現されることもあります。

非エンジニアの方は、家のリフォームをイメージすると理解しやすいでしょう。建てた当初は問題なかった家でも、増築や配管の継ぎ足しを繰り返すうちに、どこをいじると何に影響するか分からなくなります。この「あとから直しにくくなった度合い」を、開発の世界では技術的負債（ぎじゅつてきふさい：その場しのぎの実装が将来の改修コストとして蓄積したもの）と呼びます。

技術的負債がたまったコードは、見た目には動いていても、内部では「一か所を直すと別の場所が壊れる」状態になっています。これが「触ると壊れる」と言われる正体であり、改修のたびに見積もりと工期が膨らむ原因です。

放置するとどうなるか（改修費用・属人化・2025年の崖の文脈）

レガシーコードを放置すると、主に3つの問題が深刻化します。

第一に、改修費用と期間が雪だるま式に増えます。負債がたまるほど「壊さずに直す」ための調査と検証に時間がかかり、同じ規模の改修でも年々コストが上がっていきます。

第二に、属人化が進みます。コードの中身を理解している人が限られ、その担当者が退職するとブラックボックス化が決定的になります。社内エンジニアが少数、あるいはすでに退職してしまった企業では、誰も全体像を把握できない状態に陥りがちです。

第三に、障害リスクとビジネス機会の損失です。古いシステムは新しいサービスとの連携が難しく、市場の変化に追随できなくなります。

この問題は一企業にとどまりません。経済産業省は2018年の「DXレポート」で、老朽化・複雑化した既存システム（レガシーシステム）を放置した場合、2025年以降に最大で年間12兆円の経済損失が生じる可能性があると試算し、これを「2025年の崖」と呼びました（2025年の崖｜NTTドコモビジネス）。さらに2025年5月に公表された「レガシーシステムモダン化委員会総括レポート」では、ユーザー企業の61％でいまだにレガシーシステムが残存しているという調査結果が示されています（レガシーシステムモダン化委員会総括レポート｜経済産業省）。

こうした公的機関のデータは、社内や経営層に「なぜ今、コード改善に投資すべきか」を説明する際の客観的な根拠として活用できます。

「全面作り直し」を最初の選択肢にしない理由

経営会議で「対応方針」を問われると、つい「全面的に作り直します」と答えたくなります。話がシンプルで、ひとまずの安心感もあるからです。しかし、最初の選択肢として全面刷新を選ぶことには大きなリスクがあります。

全面刷新は、動いている現行システムをゼロから再構築する大規模プロジェクトです。多額の投資と長い開発期間を要し、その間も現行システムは運用し続けなければなりません。完成までに事業の前提が変わってしまったり、移行に失敗して業務が止まったりする事例も少なくありません。

そもそも、ブラックボックス化したコードの全体像が分からないまま「全部作り直す」と決めても、何をどこまで作るのかが定義できず、見積もりも工期も精度が出ません。これが「予算も工期も怖い」という不安の根本原因です。

現実的なのは、現状を把握したうえで、問題の大きい箇所から段階的に改善していく進め方です。本記事では一貫してこの「段階改善」を前提に、発注の進め方を整理していきます。なお、全面刷新・延命・段階改善のどれを選ぶかという上位の判断については、レガシーシステム刷新の判断フレームワークで詳しく整理しています。

外注すべきか自社対応か｜レガシーコード改善の判断軸

段階改善で進めると方針が決まったら、次の分岐は「社内のエンジニアで進めるか、外注するか」です。ここを感覚で決めず、いくつかの観点で整理すると、社内でも合意を取りやすくなります。

外注が向くケース・自社対応が向くケース

判断のポイントは、主に次の4つの観点です。

• 社内リソース: コード改善に割けるエンジニアが社内に十分いるか
• ドメイン知識: そのコードの背景や業務知識を理解している人が社内に残っているか
• コードのブラックボックス度合い: 中身を把握している人がいるか、ドキュメントが残っているか
• 緊急度: いつまでに改善する必要があるか

これらを踏まえると、おおむね次のように整理できます。

完全にどちらか一方に振り切るのではなく、診断や設計は外部の専門家に依頼し、運用に近い部分は社内が担う、といった役割分担も現実的な選択肢です。社内にドメイン知識を持つ人が残っているなら、その人を外注先との橋渡し役に据えると進めやすくなります。

全面刷新・延命・段階改善のどれを選ぶか

外注で進める場合でも、その手前で「そもそもどう改善するか」という方針が定まっていることが前提です。大きく分けると、現行システムを延命させる、段階的に改善する、全面的に刷新する、という選択肢があります。

本記事は段階改善を前提に進め方を解説していますが、自社の状況によっては延命や刷新が適しているケースもあります。この上位判断の進め方はレガシーシステム刷新の判断フレームワークで、システムレベルでの具体的な改善方法はレガシーシステムの改善方法で整理しています。刷新そのものの全体像から押さえたい場合は、レガシーシステム刷新とはもあわせてご覧ください。

現状把握（コード診断）の進め方と外注の依頼方法

段階改善を外注で進めるとき、最初の一歩は「いきなり改修を発注すること」ではありません。まずは現状を把握する診断から始めます。ここを最初の小さな発注として切り出すことが、予算も工期も怖いという不安を和らげる最大のポイントです。

コード診断で分かること（負債の所在・優先度）

コード診断とは、外部の専門家に既存コードを調査してもらい、どこにどんな問題が潜んでいるかを可視化する作業です。診断によって、おおむね次のようなことが分かります。

• どの部分の負債が大きいか（負債の所在）
• どこから手をつけると効果が高いか（改善の優先度）
• ブラックボックスの正体（仕様が不明だった処理の把握）
• 改善に必要なおおよその規模感

診断のアウトプットは、負債の所在を地図のように示した資料（負債マップ）や、改善優先度の一覧として返ってくることが一般的です。これがあると、闇雲に「全部直す」のではなく、「ここから直せば効果が大きい」という根拠を持って計画を立てられます。

診断を外注するときに準備するもの・依頼の流れ

診断を依頼するとき、発注者側がそろえておくと話が早い情報があります。すべてが完璧にそろっている必要はありませんが、分かる範囲で用意しておくと診断の精度が上がります。

• システムの概要（何のためのシステムか、誰が使うか）
• 使われている技術や開発時期（分かる範囲で）
• 現在困っていること（改修が遅い、障害が多い、特定の機能が不安定など）
• 既存のドキュメントや過去の改修履歴（あれば）
• ソースコードへのアクセス手段

依頼の流れは、おおまかに「相談・ヒアリング → 診断範囲の合意 → 診断の実施 → 報告（負債マップ・優先度）→ 改善計画の提案」という形になります。ここで重要なのは、診断と本改修を分けて発注することです。

段階改善の進め方（優先度の高い箇所から漸進的に）

診断と本改修を分けて発注するメリットは、小さく始めてリスクを抑えられる点にあります。まず診断という比較的小さな投資で全体像を把握し、その結果を見てから本改修の範囲・予算・期間を判断できます。診断の結果次第では「思ったほど深刻ではなかった」「特定の機能だけ直せば十分」と分かることもあり、いきなり全面刷新を発注するより無駄な投資を避けられます。

本改修に進む際も、一度にすべてを改善しようとせず、診断で示された優先度の高い箇所から漸進的に進めます。動いている部分を残しながら、問題の大きい箇所を少しずつ置き換えていく進め方は、現行業務への影響を最小限に抑えられます。一区切りごとに成果を確認できるため、経営層への報告もしやすくなります。

レガシーコード改善の外注先の選び方

診断から段階改善へと進める方針が固まったら、次は「誰に頼むか」です。レガシーコードの改善は、新規開発とは異なる難しさがあるため、選定の基準も変わってきます。

外注先のタイプと向き不向き

外注先には大きく分けて次のタイプがあり、それぞれ向き不向きがあります。

レガシー改善で重要なのは「規模が大きいから開発会社」と短絡的に決めないことです。コードの背景を深く理解しながら丁寧に進める必要があるため、技術力が高く、レガシー特有の進め方を理解している相手を選ぶことが、タイプの違い以上に重要になります。社内にドメイン知識を持つ人が残っているなら、その人と密に連携できる体制を組める相手が望ましいでしょう。

なお、SESや業務委託で個人に依頼する場合は、契約形態によっては「指揮命令」の扱いに注意が必要です。この点は後述の契約形態の章でも触れます。

レガシー改善で特に確認すべき選定基準

新規開発の外注先を選ぶときと違い、レガシー改善では次のような点を特に確認すると失敗しにくくなります。

• 既存技術スタックの経験: 自社のシステムで使われている言語やフレームワーク（古いものを含む）に対応できるか
• テスト整備への姿勢: 「壊さずに直す」ための土台となるテスト整備を提案に含めているか
• ドキュメント化の姿勢: ブラックボックスを解消するため、調査結果や設計を文書として残してくれるか
• 引き継ぎを前提とした体制: 改善後に社内や別の業者へ引き継げる形で進めてくれるか
• 段階改善への理解: 「まず全部作り直しましょう」と即答せず、診断や優先度づけから提案できるか

これらは、外注先比較サイトのランキングや料金表だけでは見えてきません。診断フェーズを一緒に進めてみて、その姿勢や提案の質を見極めてから本改修を任せる、という進め方が、相手を見極めるうえでも理にかなっています。

契約形態の選び方｜請負と準委任の使い分け

レガシー改善は、新規開発に比べて「やってみないと範囲が分からない」性質が強い領域です。そのため、契約形態の選び方が成否を大きく左右します。ここを誤ると、想定外の追加費用や、業者との認識のズレによるトラブルにつながります。

請負契約と準委任契約の違い

外注の契約形態は、大きく請負契約と準委任契約に分かれます。発注者の立場では、次の違いを押さえておくと判断しやすくなります。

請負契約は「決まったものを完成させて納品してもらう」契約で、ゴールが明確なときに向いています。一方、準委任契約は「専門的な業務を遂行してもらう」契約で、成果物の完成責任ではなく、業務に取り組むこと自体に対して費用を払う形です。範囲がはっきり決まっていない作業に適しています。

フェーズごとの契約形態の使い分け

レガシー改善では、フェーズによって「範囲がどれだけ固まっているか」が変わります。そこで、フェーズごとに契約形態を使い分けるのが現実的です。

• 診断フェーズ: この段階では、何が問題でどこを直すべきかがまだ分かっていません。完成すべき成果物を事前に定義できないため、準委任契約が適しています。工数の上限を合意しておくと、費用が膨らむリスクを抑えられます。
• 本改修フェーズ: 診断によって改修範囲が固まったら、「ここをこう直す」という成果物を定義しやすくなります。範囲が明確な部分は請負契約にすることで、費用と納品物を確定させられます。
• 継続的な改善・運用: 改善を継続的に回していく場合は、再び準委任契約で柔軟に対応する形が向いています。

つまり、範囲が曖昧な段階は準委任で小さく探り、固まったら請負で確定させる、という流れが、予算と工期の読めなさに対処する基本の型です。

最後に注意点として、フリーランスや業務委託のエンジニアに依頼する場合、発注者が日々の作業を細かく指示・管理してしまうと、本来は雇用関係でない人を指揮命令下に置く「偽装請負」とみなされるおそれがあります。準委任・請負のいずれであっても、作業の進め方は受託側の裁量に委ね、発注者は成果や進捗の確認にとどめる、という線引きを意識しておくことが大切です。

レガシーコード改善の費用と期間の見立て方

「結局いくらかかるのか」は、発注を判断するうえで最も気になる点でしょう。レガシー改善は費用が読みにくい領域ですが、それでも発注者自身が概算を立て、予算を管理する考え方は持てます。ここでは具体的な金額を断定するのではなく、見積もりをどう読み、どう管理するかという枠組みを示します。

費用が変動する要因

レガシー改善の費用は、同じ「改修」でも案件によって大きく変動します。主な要因は次のとおりです。

• コード規模: コードの量が多いほど、調査・改修の工数が増えます
• ブラックボックス度: 中身が分からない部分が多いほど、調査に時間がかかります
• テストの有無: テストがないと「壊さずに直す」ための検証コストが上乗せされます
• ドキュメントの有無: 仕様書や設計書がないと、仕様を読み解く工数が増えます
• 改善範囲: 一部の機能だけか、システム全体かで規模が変わります

これらの要因が重なると、見積もりは膨らみやすくなります。逆に言えば、診断によってこれらの要因を早めに把握すれば、費用の見通しが立てやすくなります。

予算超過を防ぐ進め方（フェーズ分割・上限合意・見積もりの読み方）

費用が読みにくいレガシー改善で予算超過を防ぐには、次の3つの考え方が有効です。

1. フェーズ分割で投資を区切る: 診断・本改修・継続改善とフェーズを分け、各フェーズで予算を区切ります。診断という小さな投資で全体像を把握してから本改修の予算を決めることで、いきなり大きな予算をコミットせずに済みます。
2. 工数の上限を合意しておく: 範囲が曖昧な準委任フェーズでは、「ここまでで一度区切る」という工数の上限を事前に合意しておきます。これにより、青天井で費用が増えるリスクを抑えられます。
3. 見積もりの根拠を確認する: 金額の大小だけでなく、「何にどれだけの工数を見込んでいるか」という根拠を確認します。レガシー改善では調査やテスト整備の工数が成否を分けるため、これらが見積もりに含まれているかを確かめることが大切です。

複数の業者から見積もりを取る（相見積もり）場合も、金額だけを並べて比較するのは禁物です。前提とする改善範囲や、テスト・ドキュメントへの考え方が業者ごとに違えば、安く見える見積もりが実は必要な作業を含んでいない、ということも起こります。診断結果という共通の前提を全社に渡したうえで見積もりを依頼すると、同じ土俵で比較できます。

期間についても同様で、診断は比較的短期間で、本改修は範囲に応じて段階的に、という見立てになります。一度にすべてを終わらせようとせず、優先度の高い箇所から区切って進めることで、期間の見通しも立てやすくなります。

まとめ｜段階改善で進めるレガシーコード改善の発注計画

ここまでの内容を、発注計画の流れとして整理します。レガシーコード改善の外注は、次のステップで進めると、いきなり全面刷新に飛びつくリスクを避けながら、社内・経営層に説明できる計画に落とし込めます。

1. 現状把握: 「レガシーコードが限界」という状態を発注者の言葉で整理し、放置コストを経営層に説明する根拠（2025年の崖など）をそろえる
2. 判断: 社内対応か外注か、延命・段階改善・刷新のどれで進めるかを観点に沿って判断する
3. 診断: いきなり本改修ではなく、コード診断から小さく始め、負債の所在と優先度を可視化する
4. 外注先選定: レガシー改善特有の基準（既存技術の経験・テスト整備・ドキュメント化・引き継ぎ）で相手を見極める
5. 契約設計: 範囲が曖昧な診断は準委任、固まった改修は請負、と使い分けて予算と工期の読めなさに対処する
6. 費用見立て: フェーズ分割と工数上限の合意で予算を管理し、見積もりは根拠まで確認する

レガシーコード改善の発注で最も大切なのは、「全部を一度に決めようとしないこと」です。最初の一歩は、診断という小さな発注から始めることです。診断結果という客観的な材料があれば、その後の判断も、社内説明も、業者の比較も、すべてが格段にやりやすくなります。

予算も工期も怖くて踏み出せなかった段階から、「まず診断から、優先度の高い箇所から段階的に」という現実的な発注計画へ。本記事がその第一歩を描くための材料になれば幸いです。外部のエンジニアに依頼してレガシー改善を進める際の体制づくりや進捗管理の実務については、業務委託エンジニアのマネジメント実践ガイドが具体的な進め方の参考になります。