# 技術的負債の解消費用｜優先順位と外注方法

- 公開日: 2026-10-14
- 監修: 代表取締役 兼 StockSun創業メンバー 板橋 晟星
- URL: https://www.geek-bridge.com/public/column/technical-debt-remediation-cost

技術的負債（=短期的な開発を優先した結果、将来の改修・保守コストが増えた状態）は、全面刷新ではなく、事業影響と変更頻度で優先順位を付け、診断、小規模改善、効果測定の順で解消します。費用目安は診断50万〜200万円、小規模改善50万〜300万円、中規模改善300万〜1,500万円です。

## 技術的負債は事業への影響で判断する

結論として、古い技術や読みにくいソースコードが存在するだけで、直ちに解消すべき技術的負債とは限りません。発注者が判断すべきなのは、売上、顧客対応、セキュリティ、法令対応、新機能の提供速度にどの程度影響しているかです。

技術的負債には、次のような状態が含まれます。

- 一つの機能を修正すると、関係のない機能まで不具合が起きる
- 仕様書やテストがなく、変更の影響範囲を判断できない
- 特定の担当者や開発会社しか構造を理解していない
- ライブラリ（=再利用するソフトウェア部品）が古く、安全な更新が難しい
- 小さな画面修正でも調査と確認に数週間かかる
- 手作業でのリリースが多く、作業ミスが発生しやすい
- 外部サービスとの接続方法が複雑で、連携先を変更できない
- 障害の原因や利用状況を確認する記録が不足している

一方、古い技術を使っていても、安定稼働しており、変更予定がなく、セキュリティ更新も受けられるなら、急いで作り直す必要はありません。技術の新しさではなく、事業上の損失と改善投資を比較することが重要です。

### 解消の優先順位を決める評価軸

優先順位は、少なくとも次の4軸で評価します。各項目を1〜5点で採点すると、経営側と開発側が同じ材料で話しやすくなります。

| 評価軸 | 確認する内容 | 優先度が高い状態 |
|---|---|---|
| 事業影響 | 停止時の売上、顧客、社内業務への影響 | 基幹業務や顧客向けサービスが停止する |
| 発生可能性 | 障害や情報漏えいが起きる可能性 | 同種の障害が繰り返されている |
| 変更頻度 | 今後、その箇所を変更する回数 | 新機能開発のたびに修正対象になる |
| 解消難易度 | 費用、期間、停止時間、代替手段 | 小さな投資で大きな改善が見込める |

特に優先したいのは、「事業影響が大きい」「頻繁に変更する」「既に問題が発生している」の3条件が重なる箇所です。逆に、利用頻度が低く、変更予定がなく、問題発生時の代替手段もある箇所は保留できます。

発注のご相談を受ける立場では、「システム全体が古いので見積もってほしい」という相談をよく受けます。しかし、全体を一括評価すると対象範囲が広すぎて、見積もりに大きな予備費が含まれます。最初に重要業務、障害履歴、今後の事業計画を共有していただくと、調査範囲を絞りやすくなります。

### 技術的負債を疑うチェックリスト

次のうち複数に該当する場合は、全面刷新を決める前に現状診断を行う価値があります。

- [ ] 軽微な改修の見積もりが以前より高くなっている
- [ ] 改修期間の多くが影響調査に使われている
- [ ] 同じ原因による障害が繰り返されている
- [ ] 自動テストがなく、毎回人手で全画面を確認している
- [ ] 退職者や旧委託先にしか分からない仕様がある
- [ ] サーバーやソフトウェアのサポート終了が近い
- [ ] 開発環境を新しい担当者が再現できない
- [ ] 外部サービスの変更や停止に対応できない
- [ ] 新機能の開発より既存不具合への対応が優先されている
- [ ] 経営側が改修費用や完了時期を予測できない

## 技術的負債の解消費用と期間の目安

技術的負債の解消費用は、一般的に50万円程度の部分改善から数千万円以上の大規模な再構築まで幅があります。ソースコードの量だけでなく、仕様の明確さ、テストの有無、外部連携、データ移行、停止できる時間によって変動します。

### 規模別の費用・期間

以下はWebシステムや業務システムを外注する場合の一般的な目安です。実際の金額はシステム規模や求める品質によって異なります。

| 対応規模 | 主な内容 | 費用目安 | 期間目安 |
|---|---|---:|---:|
| 現状診断 | 構成、依存関係、テスト、障害履歴の調査 | 50万〜200万円 | 2〜6週間 |
| 小規模改善 | 一部のテスト追加、古い部品の更新、限定的な構造改善 | 50万〜300万円 | 1〜3カ月 |
| 中規模改善 | 複数機能の分離、データ構造や外部連携の見直し | 300万〜1,500万円 | 3〜9カ月 |
| 大規模改善 | 主要基盤の刷新、複数システムの再構成 | 1,500万〜5,000万円以上 | 6〜18カ月以上 |
| 継続改善 | 毎月優先順位を見直しながら段階的に改修 | 月額50万〜300万円程度 | 6カ月以上 |

小規模改善には、リファクタリング（=利用者向けの機能を変えず、内部構造を整理する作業）、自動テストの追加、利用していない機能の削除などが含まれます。

中規模以上では、API（=システム間の接続口）の整理、データベースの再設計、認証機能の変更などが対象になります。システム停止を避けながら新旧を並行稼働させる場合は、環境費用と確認工数も増えます。

### 費用を大きく左右する要因

| 変動要因 | 費用が上がりやすい状態 | 発注前にできる準備 |
|---|---|---|
| 仕様の明確さ | 現行動作を知る担当者がいない | 利用部門へのヒアリングを行う |
| テスト | 自動テストも確認項目もない | 重要業務の正常動作を一覧にする |
| 依存関係 | 一つの修正が多数の機能へ影響する | 外部連携先と関連業務を整理する |
| データ | 重複、不整合、欠損が多い | 件数、保管期間、重要項目を確認する |
| 稼働条件 | 24時間停止できない | 許容停止時間と繁忙期を共有する |
| セキュリティ | 更新できない部品や権限不備がある | アカウントと権限の管理者を明確にする |

見落とされやすいのが、発注者側の確認工数です。改善前後の業務確認、利用部門への説明、リリース判断は、開発会社だけでは完結しません。社内責任者と現場担当者の時間も予算として考える必要があります。

また、調査前に一括の固定金額を求めると、開発会社は不確実性を予備費として上乗せするか、調査・テスト・資料作成を見積もり対象外にする可能性があります。「調査」と「改善」を分けて契約したほうが、総額と優先順位を管理しやすくなります。

## 解消方法は段階改善と全面刷新を比較する

多くのシステムでは、事業を止めずに重要箇所から直す段階改善が現実的です。ただし、基盤全体が更新できない場合や、現在のシステムが事業モデルに合わない場合は、全面リプレイス（=既存システムを新しいシステムへ置き換えること）も比較対象になります。

### 4つの対応方針

| 方針 | 向いている状況 | メリット | 注意点 |
|---|---|---|---|
| 現状維持 | 変更予定と事業影響が小さい | 直近の支出を抑えられる | 監視と再評価の期限が必要 |
| 段階的な内部改善 | 機能は事業に合い、部分的に直せる | 投資を分散し、効果を確認できる | 改善中は新旧構造が混在する |
| 一部機能の再構築 | 問題箇所を他機能から分離できる | 対象範囲を限定できる | 接続部分の設計が必要 |
| 全面リプレイス | 基盤、仕様、業務適合性に全体的な問題がある | 将来像に合わせて再設計できる | 費用、移行、教育の負担が大きい |

全面刷新は、既存の問題をすべて解決できるとは限りません。現行仕様を十分に把握せず作り直すと、現場で必要だった例外処理が抜けることがあります。また、新システムにも短納期や追加要望による技術的負債が発生する可能性があります。

### 段階改善を選びやすい条件

- 現在の業務機能はおおむね事業に合っている
- 問題のある機能を他の機能から切り離せる
- 重要業務のテストを追加できる
- 数カ月単位で改善効果を測定できる
- 新旧機能の一時的な並行運用が可能である

### 全面リプレイスも検討すべき条件

- 基盤や主要部品のサポートが終了し、更新手段がない
- システム全体の依存関係が複雑で、部分変更が難しい
- 現在の業務や商品設計とシステムの構造が合っていない
- 維持費と改修費が継続的に増加している
- データ構造そのものが今後の事業要件に対応できない

判断時には、初期費用だけでなく、3〜5年程度の保守費、追加開発費、障害対応費、社内工数も比較します。全面刷新の見積もりが高く見えても、既存システムの延命に毎年大きな費用がかかるなら、一定期間の総費用では逆転する可能性があります。反対に、事業の将来像が固まっていない段階で全面刷新すると、完成時には要件が変わっていることもあります。

## 技術的負債の解消を外注する進め方

外注では、いきなり全体改修を契約せず、「調査」「試行」「段階展開」に分けることが重要です。各段階で成果物と継続条件を決めれば、効果が見えないまま投資が膨らむことを防げます。

### ステップ1：事業目標と評価指標を決める

「コードをきれいにする」だけでは、経営判断に必要な効果を測れません。次のような事業・運用上の指標へ置き換えます。

- 障害件数と復旧までの時間を減らす
- 軽微な改修の調査期間を短縮する
- リリース後に発見される不具合を減らす
- 新しい担当者が開発へ参加するまでの期間を短縮する
- セキュリティ更新を一定期間内に適用できるようにする
- 手作業のリリース回数や作業時間を減らす

改善前の数値が取れていない場合は、調査期間中に基準値を記録します。

### ステップ2：調査に必要な情報を準備する

発注前に、すべての技術資料を完成させる必要はありません。ただし、次の情報があると調査の精度が上がります。

- システムの目的と主要な利用者
- 売上や業務に直結する重要機能
- 過去1〜2年程度の障害・改修履歴
- 今後予定している新機能や制度対応
- ソースコード、サーバー、クラウドの管理権限
- 外部サービス、他システム、データ連携の一覧
- 現在の開発・保守会社との契約範囲
- システムを停止できる曜日・時間帯
- 社内の意思決定者と業務確認担当者

発注者側の役割分担が曖昧な場合は、先に[システム開発の発注者体制｜役割・工数・作り方](https://www.geek-bridge.com/column/system-development-client-team)も確認してください。技術的負債の解消では、経営判断、現場確認、技術判断を一人へ集中させないことが重要です。

### ステップ3：2〜6週間程度の現状診断を行う

診断では、ソースコードだけでなく、インフラ、データ、外部連携、障害履歴、リリース方法まで確認します。成果物として、少なくとも次を依頼します。

- システム構成図と主要な依存関係
- 技術的負債の課題一覧
- 事業影響と緊急度による優先順位
- 対応しない課題と、その判断理由
- 段階的な改善計画
- 各段階の概算費用と期間
- 想定リスクと切り戻し方法
- 改善効果を測る指標

課題一覧だけでは、発注判断には不十分です。「なぜ今直すのか」「直さない場合に何が起きるのか」「どの順番なら停止リスクを抑えられるのか」まで示してもらいます。

### ステップ4：小さな対象で試行する

最初の改善対象は、重要度が高い一方、他機能への影響を限定しやすい箇所が適しています。1〜3カ月程度で完了する範囲を選び、次を検証します。

- 調査時の想定と実際の作業量に差がないか
- テストで既存機能を守れるか
- リリースと切り戻しを安全に行えるか
- 開発速度や障害件数が改善したか
- 開発会社と自社の連携方法に問題がないか

試行後に費用対効果を評価し、次の対象と予算を決めます。この区切りを設けることで、全面契約後に想定外の問題が見つかるリスクを抑えられます。

### ステップ5：見積もりを作業量だけで比較しない

技術的負債の見積もりでは、次の項目が含まれているかを確認します。

| 見積項目 | 確認するポイント |
|---|---|
| 現状調査 | ソースコード以外にデータ、インフラ、外部連携も対象か |
| 設計 | 改善後の構成と移行手順が成果物に含まれるか |
| テスト | 既存機能への影響を確認する回帰テスト（=変更で既存機能が壊れていないか確認するテスト）があるか |
| データ対応 | 変換、整合性確認、バックアップが含まれるか |
| リリース | 切り替え、監視、問題時の切り戻しが含まれるか |
| 資料作成 | 構成図、仕様、運用手順を更新するか |
| 管理 | 進捗、課題、変更要求の管理工数が明記されているか |
| 保証・保守 | リリース後の不具合対応期間と条件が明確か |

単価が安くても、テスト、移行、資料更新が別料金なら総額は高くなる可能性があります。見積もり比較では、対象範囲、成果物、前提条件、除外項目を横並びにしてください。

### ステップ6：開発会社を実行力と引き継ぎ方針で選ぶ

技術的負債の解消を依頼する会社は、次の観点で見極めます。

- 既存システムを調査した経験がある
- すぐに全面刷新を勧めず、複数案を比較する
- 事業影響に基づいて優先順位を説明できる
- テスト、バックアップ、切り戻しを計画に含める
- 調査時点で不明な点を明確に区別する
- 改善効果を数値で確認する方法を提案する
- 構成図や運用資料を自社へ引き渡す
- 自社担当者への知識移転を計画に含める
- ソースコードやクラウド環境を発注者名義で管理できる

技術的負債の解消は、開発会社へ丸投げすると新たな依存を生みやすい取り組みです。定例会で課題、判断理由、変更内容を共有し、自社側にも知識を残してください。調査範囲や段階改善の進め方を整理したい場合は、[開発のご相談はこちら](https://www.geek-bridge.com/#contact)からご相談いただけます。

### よくある失敗と回避策

**1. 技術的に古い箇所をすべて直そうとする**

事業影響の小さい箇所まで対象にすると、予算と期間が膨らみます。重要業務、変更頻度、障害履歴から優先順位を決めてください。

**2. テストを後回しにする**

内部構造を変える作業では、利用者から見える動作を維持する必要があります。重要機能のテストを先に整備し、改善前後を比較できる状態にします。

**3. 調査前に総額と納期を確定する**

仕様不明の状態では、正確な見積もりは困難です。調査を独立した契約にし、その結果に基づいて改善費用を確定します。

**4. 現行の開発会社や担当者を排除する**

過去の判断理由や例外仕様を知る人は重要な情報源です。関係に問題がある場合でも、可能な範囲でヒアリングや資料提供を依頼します。

**5. 改善後の指標を決めない**

構造を変えただけでは、投資効果を説明できません。改修期間、障害件数、復旧時間、リリース作業時間などを改善前後で比較します。

**6. 一度のプロジェクトで終わらせる**

技術的負債は、事業上必要な短納期対応や仕様変更によって再び発生します。四半期ごとなど一定の周期で課題を見直し、重要な負債を計画へ組み込む運用が必要です。

## まとめ

- 技術的負債は、技術の古さではなく事業影響、発生可能性、変更頻度、解消難易度で評価します
- 費用の一般的な目安は、診断50万〜200万円、小規模改善50万〜300万円、中規模改善300万〜1,500万円です
- 仕様やテストが不足している場合は、調査と改善を分けて契約すると見積もりを管理しやすくなります
- 多くのシステムでは、重要箇所から直す段階改善が現実的ですが、基盤全体の問題や事業との不一致がある場合は全面リプレイスも比較します
- 外注先は、調査力、テスト・切り戻し計画、効果測定、資料作成、知識移転まで含めて選びます
- 解消後も定期的に課題を再評価し、技術的負債を事業計画と一緒に管理することが重要です

## よくある質問

### 技術的負債はすべて解消すべきですか？

いいえ。利用頻度が低く、変更予定もなく、障害時の事業影響も小さい箇所は、監視を続けながら保留する判断が合理的です。事業影響、発生可能性、変更頻度、解消費用で優先順位を付けます。

### 技術的負債の調査だけを外注できますか？

可能です。一般的には2〜6週間、50万〜200万円程度を目安に、構成・依存関係・テスト・障害履歴を調べ、課題一覧と優先順位、概算計画を作ります。規模や資料の状態によって費用と期間は変わります。

### 全面リプレイスと段階的な改善はどちらを選ぶべきですか？

既存システムが事業に適合し、部分ごとに分離して直せるなら段階的改善が向きます。基盤のサポート終了、全体的な仕様不明、事業モデルとの不一致が重なる場合は全面リプレイスも比較します。

### 仕様書やテストがなくても解消を依頼できますか？

依頼できますが、最初から改修見積もりを確定させるのは危険です。まず調査フェーズで現行動作、ソースコード、データ、外部連携を確認し、テストと仕様資料を補いながら対象範囲を確定します。