LASSIC Media らしくメディア
技術的負債の解消を外注で進める｜リファクタリング範囲・費用対効果・進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- ユーザー企業の61%がレガシーシステムを抱え、IT予算の多くが保守に費やされている実態を公的データで確認できます。
- 技術的負債の解消を外注するときに押さえるべき「対象範囲の優先度づけ」と「費用対効果の試算方法」を解説します。
- 外注先を選ぶ際に元請（プライムベンダー）かどうかを確認すべき理由と、5ステップの進め方を紹介します。
目次
技術的負債がIT予算を侵食するメカニズム
技術的負債の解消を外注で進めるとは、コードの品質問題・設計の歪み・ドキュメントの欠如といったソフトウェア内部の「負債」を、専門知見を持つ外部パートナーに委ねてリファクタリングする取り組みです。自社エンジニアが機能開発に集中できる体制を維持しながら、蓄積した負債を計画的に解消していく手法です。
維持管理費9割超のジレンマ ― 経産省DXレポートの指摘
経済産業省が2018年に公表した「DXレポート ～ITシステム『2025年の崖』の克服とDXの本格的な展開～」では、日本企業のIT予算の大部分が既存システムの維持管理費に消えている状況が問題視されています。*1
同レポートでは、複雑化・老朽化・ブラックボックス化した既存システムが残存し続けた場合、2025年以降に年間12兆円規模の経済損失が生じる可能性があると試算しています（試算上の上限値として提示された数値）。*1
この損失の背景にあるのが技術的負債の蓄積です。短期的な視点で積み重ねた開発判断が、長期的には保守・運用コストの高騰を招き、新規投資への余力を奪っていきます。
61%の企業が抱えるレガシーシステムの実態
経済産業省とIPA（独立行政法人情報処理推進機構）が設置した「レガシーシステムモダン化委員会」は、2024年7月から2025年3月にかけて調査・討議を実施し、2025年5月に総括レポートを公表しました。*2
同レポートによると、ユーザー企業・ベンダー企業約4,000社に配布した市場動向調査（有効回答799社、調査時期2024年12月〜2025年2月）で、ユーザー企業の61%が依然としてレガシーシステムを保有していることが示されています。*2
レガシーシステムには技術的負債が蓄積しやすく、その解消を後回しにするほど改修コストと難易度は上昇します。外注を検討するなら、早い段階での着手が費用対効果の観点からも合理的です。
外注で対応すべきリファクタリングの範囲と優先度
技術的負債にはいくつかの種類があります。外注でリファクタリングを依頼する前に、どの負債を優先すべきかを整理することが、費用対効果を高める鍵になります。
コード品質負債 ― 複雑度・重複・命名の問題
コード品質負債とは、循環的複雑度（サイクロマティック複雑度）が高い関数、重複したロジック、意図が伝わらない変数名・関数名の集積です。
この種の負債は静的解析ツール（SonarQube等）で定量的に可視化しやすく、外注先と優先度を共有しやすいという利点があります。変更頻度の高いモジュールから着手すると、開発速度の改善効果を早期に実感できます。
設計負債 ― 密結合・依存関係・テスト不能構造
設計負債は、モジュール間が密結合していてテストコードを書けない状態や、依存関係が複雑に絡み合ってどこを変更すると何が壊れるかわからない状態を指します。
設計負債の解消には、依存関係の逆転（DI）・インターフェース分離・レイヤー化などの設計知識が必要です。内製チームがこのスキルを持っていない場合、経験豊富な外注パートナーへの依頼が特に有効です。
ドキュメント負債 ― 仕様書がなく属人化
仕様書がなく、コードを読まなければ動作を確認できない状態はドキュメント負債です。担当者が退職した瞬間に改修難易度が急上昇するリスクを抱えています。
外注でリファクタリングを進める際に仕様を整理する作業は副産物として発生します。この機会をドキュメント整備と組み合わせると、解消効果が持続しやすくなります。
優先度の付け方 ― ビジネス影響×変更頻度で判断
すべての負債を一度に解消しようとすると予算が膨らみ、リスクも高まります。優先度の判断には「ビジネス影響の大きさ」と「変更頻度の高さ」を掛け合わせる方法が実務的です。
収益に直結する決済・認証・在庫管理など頻繁に改修が入るモジュールは優先度が高くなります。逆に、変更がほとんど発生しない補助的な機能は、負債があっても緊急度は低いと判断できます。
| 負債の種類 | 主な症状 | 外注適性 | 優先度の目安 |
|---|---|---|---|
| コード品質負債 | 複雑度高・重複ロジック・命名不良 | 高（静的解析で定量化しやすい） | 変更頻度が高いモジュール優先 |
| 設計負債 | 密結合・テスト不能・依存関係の混乱 | 高（設計スキルが必要なため外注効果大） | 収益直結モジュール優先 |
| ドキュメント負債 | 仕様書なし・属人化・引き継ぎ困難 | 中（リファクタリング時に同時対応可能） | 退職リスク・人員異動が多い箇所優先 |
| テスト負債 | カバレッジ低・手動テスト依存・リグレッション多発 | 高（テスト設計・自動化の専門性が必要） | デプロイ頻度を上げたいシステム優先 |
リファクタリング外注の費用と費用対効果
費用感を把握してから外注先に声をかけると、見積もりの比較検討がしやすくなります。以下は市場参考値であり、一次資料による公表値ではありません。実際の費用は対象システムの規模・言語・複雑度によって大きく変動します。
費用の目安（市場参考値・一次資料ではない）
リファクタリング外注の費用は、主にエンジニアの稼働工数と単価で決まります。以下の参考値はIT業界の一般的な受託開発における工数単価をもとにした目安です。
- 小規模（数千行〜1万行程度のモジュール単位）：100〜500万円程度／1〜3か月
- 中規模（数万行の業務システム一部領域）：500〜2,000万円程度／3〜6か月
- 大規模（基幹システム全体のリファクタリング）：2,000万円〜数億円程度／6か月以上
これらはあくまで市場参考値です。実際には、対象の言語・フレームワーク・テスト環境の有無・ドキュメントの充実度によって見積もりが変動します。複数社から相見積もりをとることを推奨します。
費用対効果の測り方 ― 維持管理コストの削減幅で試算
費用対効果は「リファクタリング後に削減できる保守コスト」と「外注費用」を比較して試算します。たとえば、年間の保守費が削減された場合、何年で投資を回収できるかを見積もる方法が実務上わかりやすいです。
保守コストの削減幅を試算するには、現在の保守工数（月あたりの対応件数×平均対応時間）を記録しておく必要があります。リファクタリング前後の比較ができると、効果を定量的に説明できます。
リファクタリングの効果として現れやすいのは「障害対応時間の短縮」「機能追加の所要工数の減少」「テスト実行時間の短縮」などです。これらをKPIとして事前に設定しておくと、外注先との成果合意がしやすくなります。
内製 vs 外注のコスト比較
| 比較項目 | 内製対応 | 外注対応 |
|---|---|---|
| 人材確保のコスト | 既存エンジニアを充当するため採用費は不要だが、 機能開発との競合が発生しやすい |
外注費が発生するが、機能開発チームへの影響を抑えられる |
| 専門スキルの調達 | 設計改善・テスト自動化の知識が社内にない場合は習得コストが発生する | 専門チームに依頼できるため、即戦力のスキルを活用できる |
| リスク管理 | 社内で完結するためセキュリティリスクは低いが、 判断が甘くなりやすい |
セキュリティ・機密性の確認が必要だが、 客観的な視点での品質評価が期待できる |
| スピード | 優先度が後回しになりやすく、解消に時間がかかる傾向がある | 専任チームが集中して取り組めるため、短期間での解消が見込める |
外注で進めるリファクタリングの5ステップ
リファクタリングを外注で成功させるには、依頼前の準備と段階的な進め方が重要です。以下の5ステップは、外注先との合意形成から品質管理まで一貫した流れを示しています。
ステップ1 ― コードベース監査と負債の可視化
まず現状の技術的負債を「見える化」します。静的解析ツール（SonarQube、CodeClimate等）を使い、複雑度・重複率・カバレッジを計測します。
この段階は外注先に依頼する前に自社で実施することも、外注先に初期監査（コード診断）として依頼することもできます。監査結果が明確であるほど、後の見積もり精度が上がります。
ステップ2 ― 優先度・スコープ確定とゴール設定
監査結果をもとに、今回のリファクタリングで解消する範囲と達成目標を確定します。複雑度の上限値・テストカバレッジの目標値・ドキュメント整備の対象モジュールなどを数値で定義します。
スコープを広げすぎると費用と期間が膨らみ、管理が難しくなります。まず「一番痛い箇所」に絞り込んで着手し、成果を確認してから次のフェーズに進む段階的なアプローチが費用対効果を高めます。
ステップ3 ― テスト設計（リグレッション防止）
リファクタリングの鉄則は「外側の振る舞いを変えずに内側のコード構造を整え直す」ことです。そのためには、改修前に既存の振る舞いを保証するリグレッションテスト（回帰テスト）の設計が必要です。
テストコードが存在しないシステムの場合、まずエンドツーエンドテストで現状の動作を記録し、それをガードレールとして段階的にユニットテストを追加していく方法が実務上取りやすいです。
ステップ4 ― 段階的リファクタリングの実施
スコープを小さな単位に分割して繰り返し実施します。一度に大規模な変更を加えると、デグレード（品質低下）の原因特定が難しくなります。
外注先と短いサイクル（1〜2週間のスプリント）でレビューと確認を行うと、進捗の透明性が上がり、認識ずれを早期に発見できます。進捗管理ツール（Jira、Backlog等）での可視化も有効です。
ステップ5 ― 品質計測・残債管理と再発防止
リファクタリング完了後も技術的負債は時間とともに再蓄積します。定期的な静的解析の実施・コードレビュー基準の整備・CI/CDパイプライン（継続的インテグレーション/継続的デリバリーの自動化基盤）への品質ゲートの組み込みなど、再発防止策を外注先と合意してから引き渡しを受けることが大切です。
外注終了後に自社で管理を継続できるよう、ドキュメント・計測基準・対応手順を整備して引き継ぐことも契約事項として明確にしておきましょう。
外注先選定のチェックポイント
リファクタリング外注の失敗の多くは、外注先の選定段階で発生します。技術力・コミュニケーション・契約形態の3軸で評価することが外注成功の前提条件です。
技術スタック・言語対応の確認
リファクタリングは対象の言語・フレームワークへの習熟度が成果に直結します。PHP・Java・Pythonなどの言語別の実績、フレームワーク（Laravel・Spring Boot・Django等）への対応実績を事前に確認してください。
特に、静的解析ツールの導入経験・テスト自動化の実績・CI/CDパイプラインの構築経験は、リファクタリング専門性の指標として有効です。ポートフォリオや過去の事例（可能な範囲で）をヒアリングすることを推奨します。
元請（プライムベンダー）かSESかを見極める
外注先が元請（プライムベンダー）として責任を持って納品する体制か、SES（システムエンジニアリングサービス。エンジニアの労働力を提供する派遣形態）として人員を提供するだけかを確認することが重要です。
技術的負債の解消は単なる作業工数ではなく、設計判断・優先度選定・品質基準の策定を伴います。元請として成果物に責任を持つ体制の方が、プロジェクト全体のリスク管理がしやすくなります。
SES形態の場合、指揮命令権は自社にあるため、設計判断・進捗管理・品質レビューをすべて自社で担う必要があります。社内にその体制がない場合は、元請形態で請け負える会社を選ぶことが現実的です。
実績・コミュニケーション・セキュリティ体制の確認
ソースコードは企業の知的財産です。外注先のセキュリティ管理体制（NDA・アクセス権限管理・ソースコードの取り扱い規定）を契約前に確認することは必須です。
コミュニケーションの面では、週次での進捗報告・課題のエスカレーション経路・担当者の変更時の引き継ぎ方針なども確認しておくと、プロジェクト中断リスクを下げられます。
失敗リスクを最小化するには、いきなり大規模な外注からはじめるより、小規模なモジュールの診断・改善から試験的に依頼し、パートナーシップの質を見極めてから本格発注に移行するアプローチが有効です。
まとめ ― 外注リファクタリングの3つの判断軸
本稿では技術的負債の解消を外注で進める方法を整理しました。要点を3つに集約すると次の通りです。
第一に、優先対象の選定です。コード品質・設計・ドキュメント・テストの4種類の負債を「ビジネス影響×変更頻度」で評価し、変更頻度が高く収益直結のモジュールから着手することが費用対効果を高めます。
第二に、段階的な進め方です。一度に全負債を解消しようとせず、スコープを絞ってテスト設計→段階的改修→品質計測のサイクルを繰り返すことで、リスクを抑えながら成果を積み重ねられます。
第三に、外注先の選定です。元請（プライムベンダー）として成果物に責任を持つ体制かどうか、技術スタックの実績・セキュリティ管理・コミュニケーション体制の3点を確認することが、外注失敗を防ぐ判断軸になります。
よくある質問
リファクタリングと機能開発を並行して進めることはできますか？
並行して進めることは可能ですが、対象モジュールが重なる場合はコンフリクトのリスクがあります。外注チームと内製チームが作業する範囲を明確に分離し、ブランチ戦略・マージポリシーを事前に合意しておくと、コンフリクトを抑えて並行作業が進められます。小規模なフィーチャーフラグ（機能フラグ）を活用して段階的に切り替える方法も有効です。
外注先にソースコードを渡すことにリスクはありますか？
ソースコードの共有にはリスクが伴いますが、適切な管理により許容できるレベルに下げられます。NDA（秘密保持契約）の締結・Gitリポジトリへのアクセス権限の最小化・作業完了後のアクセス削除・監査ログの保持を外注先と取り決めることが基本的な対策です。さらに、外注先のISMS認証（情報セキュリティマネジメントシステムの国際規格）取得状況を確認することも有効です。
リファクタリング外注の期間はどのくらいかかりますか？
対象の規模と複雑度によって異なります。数千行程度の小規模モジュールであれば1〜3か月、数万行規模の業務システムの一部領域であれば3〜6か月が市場参考値の目安です（一次資料による公表値ではありません）。期間を短縮したい場合は、スコープを絞って最初のフェーズから着手し、成果確認後に次フェーズに進む段階的アプローチが現実的です。
小規模なシステムでも外注リファクタリングは費用対効果がありますか？
規模が小さくても、変更頻度が高く障害や遅延が頻発しているシステムであれば費用対効果は期待できます。まず外注先に「コード診断」（初期監査）だけを依頼し、改善余地と概算費用を試算した上で発注を判断する進め方が、リスクを最小限に抑えながら費用対効果を見極めるための手順として有効です。
外注後も技術的負債が再蓄積しないようにするにはどうすればいいですか？
再蓄積を防ぐには「仕組みとしての品質管理」が必要です。具体的には、CI/CDパイプライン（継続的インテグレーション/継続的デリバリーの自動化基盤）への静的解析ゲートの組み込み・コードレビュー基準の文書化・新規開発時の設計基準の明確化が有効です。外注先と引き渡し時に「再発防止策のドキュメント」を合意事項として含めておくことで、内製チームが継続的に管理できる体制を作れます。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：経済産業省「DXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開～」（2018年）
- *2 出典：経済産業省・IPA「レガシーシステムモダン化委員会総括レポート」（2025年5月）
