「このシステム、直すべきか、いっそ作り直すべきか」。開発リーダーや CTO の方から最も多く相談されるのが、この問いです。技術的負債という言葉は広く知られるようになりましたが、いざ目の前のシステムを前にすると、どこから手をつけ、どこまで返せばよいのかが見えなくなります。そして判断がつかないまま、結局「全部作り直す」か「何もしない」かの二択に振れてしまう。本記事では、技術的負債を数値で可視化し、リファクタ・部分刷新・全面リプレイスのどれを選ぶかを分岐基準で示し、AI を使って「触ると怖いコード」を特定する手順まで、実務の判断軸に落として解説します。

結論: 技術的負債は「全額返済」ではなく「利息の高い箇所から」返す

先に結論を述べます。技術的負債への正しい向き合い方は、全額を一度に返すことでも、作り直しで一掃することでもありません。利息の高い負債から優先的に返すこと、これに尽きます。

負債という比喩が優れているのは、利息という概念を含んでいる点です。借金そのもの (=雑な実装や古い設計) が問題なのではなく、そこに発生し続ける利息こそが事業の足を引っ張ります。利息とは、その箇所を触るたびに余計にかかる時間、頻発するバグ、新しいメンバーが理解できないことによる遅延です。

ここで決定的に重要なのは、負債の量と利息の大きさは必ずしも一致しないという事実です。ひどく汚いコードでも、誰も触らず安定して動いているなら利息はほぼゼロです。逆に、見た目はそれほど悪くなくても、毎週手を入れるうえに少し変えるだけで別の場所が壊れるコードは、利息を払い続けている高金利の負債です。

だからこそ最初にやるべきは、作り直しの計画を立てることではなく、どこに利息の高い負債が眠っているかを特定することです。これを感覚ではなくデータで行うのが、後述する可視化の役割になります。

技術的負債とは何か(意図的負債と偶発的負債の違い)

技術的負債とは、短期的な都合で選んだ実装や設計が、将来の変更コストとして積み重なっていく状態を指します。広く使われるのは、負債を「意図したか」「分別があったか」の二軸で分類するフレームです。実務では、まず意図的負債と偶発的負債の違いを押さえると整理しやすくなります。

意図的負債は、トレードオフを理解したうえで、あえて引き受けた負債です。「リリース期限に間に合わせるため、今回はテストを薄くして手動確認で出す」「将来の拡張は見込めるが、まずは最小構成で作る」といった判断がこれにあたります。事業判断として合理的なことが多く、問題は負債そのものより、後で返す計画を残さないことです。

偶発的負債は、知識や経験の不足、あるいは要件の変化によって、知らないうちに溜まっていく負債です。当時はベストだった設計が、事業の成長で前提から外れていく。担当者が次々と入れ替わり、誰も全体像を把握していない。こうした負債は気づきにくく、しばしば「触ると怖いコード」として後から発覚します。

この区別が実務で効くのは、返済の打ち手が変わるからです。意図的負債は「いつ・どの条件で返すか」を最初に約束しておけば管理できます。偶発的負債は、まず存在を可視化しないと返済の俎上にすら載りません。次章で扱う可視化は、主にこの偶発的負債を表に引きずり出す作業だと考えてください。

なお、関連する論点として TDD やテスト設計があります。負債を返す過程で安全網となるテストの考え方は AI 駆動 TDD - テストを AI に先に書かせる開発フロー で詳しく扱っているので、合わせて参照してください。

負債を数値で可視化する(変更頻度×複雑度のホットスポット分析)

技術的負債の議論が空回りする最大の原因は、「なんとなく汚い」という主観で語られることです。主観は人によってばらつき、経営層への説明も通りません。そこで、負債を変更頻度と複雑度の二軸で数値化し、地図の上に落とします。これがホットスポット分析です。

変更頻度は、Git の履歴から「そのファイルが過去にどれだけ変更されたか」を数えれば求まります。複雑度は、循環的複雑度 (関数の分岐の多さ) やコード行数、依存の多さといった指標で測ります。この 2 つを掛け合わせると、ファイルやモジュールを 4 つの象限に分けられます。

  • 変更頻度・高 × 複雑度・高 … 最優先の返済対象。毎回触るのに壊れやすい、利息の塊。
  • 変更頻度・高 × 複雑度・低 … 健全。よく触るが素直なコードで、無理に手を入れない。
  • 変更頻度・低 × 複雑度・高 … いったん保留。複雑だがほぼ触らないなら利息は小さい。
  • 変更頻度・低 × 複雑度・低 … 放置でよい。安定して動いている資産。

ポイントは、複雑度だけを見て返済対象を決めないことです。複雑なコードを片端から綺麗にしたくなるのが技術者の性ですが、めったに触らない複雑なコードに工数を割いても事業への見返りは小さい。変更頻度という「実際にどれだけ痛みが発生しているか」の軸を掛けて初めて、限られた工数の投下先が定まります。

変更頻度の集計は専用ツールがなくても、git log でファイルごとの変更回数を数えるだけで概算できます。バグ修正コミットに絞れば、「直してもまた壊れる箇所」というさらに鋭い指標も取れます。複雑度は静的解析ツールで取得し、両者をスプレッドシート上で掛け合わせれば、それだけで返済すべき箇所の優先順位が一目で並びます。

AI に既存コードを読み解かせて「触ると怖いコード」を特定する

ホットスポットの座標が分かっても、「では、なぜそのモジュールは触ると怖いのか」という中身の理解には、結局コードを読み込む工数が要ります。担当者がすでに退職していたり、ドキュメントが残っていなかったりすると、ここが大きな壁になります。私たち AI 駆動開発のクリエイティブスタジオが負債の棚卸しで実際に使っているのが、この読み解きを AI に肩代わりさせる進め方です。

Claude Code のようなコーディングエージェントは、リポジトリ全体を読んだうえで、特定のモジュールについて「何をしている処理か」「どこと密結合しているか」「変更した場合に影響が及ぶ範囲はどこか」を要約できます。ホットスポット分析で特定した上位のモジュールを順に渡し、次のような観点で読み解かせると効率的です。

まず、そのモジュールの責務と入出力を平易な日本語で説明させます。次に、変更したときに壊れやすい暗黙の前提 (グローバルな状態への依存、副作用、隠れた仕様) を列挙させます。さらに、テストが存在するか、ないならどんなテストを先に書けば安全に手を入れられるかを提案させます。こうして「触ると怖い理由」を言語化すると、返済の難易度と工数が見積もれるようになります。

ここで強調したいのは、AI の出力をそのまま正解にしないことです。AI はコードの全体像を素早く掴ませる道具として極めて有効ですが、ドメインの背景や過去の事故の経緯までは知りません。AI が出した影響範囲やリスクの仮説を、人間が一次情報 (実際の挙動やログ、関係者の記憶) と突き合わせて確定させる。この役割分担を守ると、棚卸しの速度を数倍に上げつつ精度を保てます。

実際、AI に読み解きを任せると、人手では数日かかっていた既存コードの把握が数時間で済むケースが珍しくありません。負債の可視化が安価になるほど、定期的な棚卸しが回しやすくなり、負債が手遅れになる前に手を打てるようになります。

リファクタ/部分刷新/全面リプレイスの分岐フローチャート

可視化で返済対象が定まったら、次は手段の選択です。リファクタ、部分刷新、全面リプレイスの 3 つは、コストもリスクもまったく異なります。順を追って分岐していくと迷いません。

最初の問いは、今の設計の延長で直せるかです。クラスや関数の整理、命名の改善、テストの追加、重複の解消といった範囲で痛みが消えるなら、リファクタで十分です。外から見た振る舞いを変えずに内部構造だけを整えるので、リスクが最も低く、まず検討すべき第一候補になります。ホットスポット分析で上がった箇所の多くは、実はこのリファクタで利息を大きく下げられます。

次の問いは、特定のモジュールだけが設計の前提から外れているかです。たとえば認証基盤だけが古い方式に縛られている、あるいは決済まわりだけが密結合で手をつけられない、という状況です。この場合は、その境界を切り出して新しい設計で作り替える部分刷新が有効です。動いている他の部分はそのまま残せるため、全面作り直しよりリスクとコストを抑えられます。利息の高いモジュールから順に置き換えていく、いわゆる絞め殺しパターン (ストラングラーパターン) の発想です。

最後の問いは、システム全体の前提が事業に合わなくなっているかです。言語やフレームワークが EOL を迎えてサポートが切れている、土台のアーキテクチャが今の事業要件と根本的にずれている、採用市場でその技術者がほぼ確保できない。こうした症状が複数重なって初めて、全面リプレイスが現実的な選択肢に上がります。全面リプレイスの段取りそのものは システムリプレイスの進め方｜失敗しないステップ解説 で詳説しているので、判断が全面刷新に傾いた場合はそちらを参照してください。

注意したいのは、全面リプレイスは見た目ほど安全な選択肢ではない点です。動いている機能を作り直している間も事業は止められず、長年の運用で積み上がった細かな仕様 (例外処理や特殊なデータ) が抜け落ちる危険が常につきまといます。「綺麗に作り直す」という誘惑は強いものですが、まずは可視化で痛みの所在を特定し、リファクタと部分刷新で返せないかを検討する。それでも限界という結論になってから全面刷新へ進む、という順序が結果的に安全で安く済みます。実際に費用を抑えながらレガシー刷新を進めた事例は レガシーシステム刷新を半分のコストで実現した事例 にまとめています。

塩漬けシステムを放置するコストと EOL リスクの見積もり

「動いているから触らない」という塩漬けの判断は、しばしば最も高くつきます。放置のコストは目に見えにくいぶん、見積もって表に出すことが大切です。

第一のコストは、EOL (サポート終了) リスクです。言語のランタイム、フレームワーク、OS、ミドルウェアにはそれぞれサポート期限があり、これを過ぎるとセキュリティ修正が提供されなくなります。脆弱性が見つかっても公式の対策が出ず、自前で塞ぐか、最悪は事業を止めるしかなくなる。EOL の時期は事前に分かるので、いつ何のサポートが切れるかを一覧にし、対応に要するリードタイムから逆算して着手時期を決めます。

第二のコストは、人材リスクです。古い技術スタックは、それを扱える技術者の採用が年々難しくなります。属人化が進み、特定の一人しか触れない状態になると、その人が抜けた瞬間に変更不能になります。塩漬けは「変更しない」決定ではなく、「変更できなくなっていく」状態への緩やかな移行だと捉えるべきです。

第三のコストは、機会損失です。塩漬けシステムに新機能を載せようとすると、毎回過大な工数がかかり、本来できたはずの改善や新規開発が後回しになります。これは表に出ない利息で、決算書には載りませんが、競合との速度差として確実に効いてきます。

これらを見積もるときは、放置した場合の年間コスト (脆弱性対応・障害対応・割高な開発工数の合計) と、返済に必要な投資額を並べて比較します。多くの場合、数年スパンで見れば返済したほうが安いという結論になります。重要なのは、塩漬けを「コストゼロの現状維持」と錯覚しないことです。

経営層に負債返済の投資判断を通す説明の組み立て方

技術的負債の返済は、現場の技術者がいくら必要性を訴えても、経営層に響かなければ予算がつきません。説明が通らない原因のほとんどは、技術の言葉で語ってしまうことにあります。経営の言葉に翻訳して伝えます。

まず、負債を金額とリスクに変換することが起点です。「コードが汚い」では伝わりませんが、「この箇所の改修は本来の 2 倍の工数がかかっており、年間で人月いくらの無駄が出ている」「このミドルウェアは来年 EOL を迎え、放置すれば脆弱性対応ができなくなる」と言えば、経営判断の俎上に載ります。可視化で出したホットスポットの数値は、ここで強力な裏付けになります。

次に、返済を全額ではなく分割で提案することです。「全部直すのに 1 年かかります」では決裁が下りませんが、「利息の最も高い上位 3 モジュールを 1 四半期で返すと、開発速度がこれだけ戻り、障害がこれだけ減る見込みです」なら、投資対効果が読めて承認しやすくなります。小さく返して効果を実証し、次の投資を引き出す。この積み上げが現実的です。

そして、やらない場合に何が起きるかをセットで示します。投資判断は「やる効果」だけでなく「やらないリスク」で動くことが多いからです。EOL の時限、人材が抜けたときの停止リスク、機会損失の累積を時間軸で並べると、先送りが安全策ではないことが伝わります。サポート終了が迫る塩漬けシステムの刷新は EOL を迎えるシステムの移行 で具体的な進め方を整理しています。

この組み立ては、負債の棚卸しの段階から経営目線のデータを取っておくと格段に楽になります。私たちが負債診断を支援する際は、可視化の結果を技術レポートで終わらせず、投資判断に使える費用とリスクの資料まで一体で用意することを重視しています。

よくある質問

技術的負債の返済をめぐって、開発リーダーや経営層から繰り返し受ける質問を整理しておきます。

負債をゼロにすることは現実的ではなく、目指す必要もありません。要件もライブラリも変わり続けるため、負債は再び溜まります。重要なのは総量を消すことではなく、利息の高い箇所だけを返し、開発速度と品質を維持できる範囲に抑えることです。

着手の優先順位は、変更頻度と複雑度を掛け合わせたホットスポットの上位から、というのが基本です。そこに事業リスク (停止インパクト、法令期限、EOL) を重ねてスコア付けし、上から順に手をつけます。感覚ではなくデータで並べることで、工数の投下先に説明責任を持たせられます。

手段の使い分けは、設計の延長で直せるならリファクタ、特定モジュールだけが前提から外れているなら部分刷新、システム全体の前提が事業に合わなくなっていれば全面リプレイス、という順で分岐します。多くのケースは、リスクもコストも低い部分刷新で十分に返済できます。

技術的負債の返済は、作り直しという派手な一手だけが正解ではありません。まず可視化し、利息の高い箇所を見極め、最小単位で返していく。この地道な進め方こそが、限られた予算で開発の健全性を取り戻す近道です。自社のシステムのどこに利息の高い負債が眠っているのか、まずは棚卸しから始めたい方は、お問い合わせ よりご相談ください。AI を活用したホットスポット診断から投資判断の資料づくりまで、AI 駆動開発のクリエイティブスタジオとして伴走します。