技術的負債

概要

技術的負債は、「今すぐ出荷するための近道」と引き換えに将来へ先送りされた、設計や実装の劣化を指すメタファーです。お金の借金と同じく、借りること自体は悪ではありません。締め切りに間に合わせるために理想的でない設計で出荷するのは、合理的な経営判断でありえます。問題は、負債には利子が付くことです。歪んだ構造の上にコードを書き足すたびに余計な手間がかかり、その「余計な手間」が利子として、返済するまで毎回の変更に課され続けます。

利子が膨らんだコードベースでは、単純な機能追加に数週間かかる、1行直すと別の場所が壊れる、怖くて誰も触れないモジュールがある、といった症状が現れます。俗に「レガシーコード」と呼ばれる状態は、負債が長期間放置されて利払いが開発速度を圧迫している状態と言えます。エンジニアとビジネス側が開発速度の低下について対話するための共通言語として、この語彙は生まれました。

なぜ生まれたか

このメタファーは1992年、Ward Cunningham が金融システムの開発報告の中で使ったのが最初です。彼が伝えたかったのは「汚いコードを書いてしまった言い訳」ではなく、その逆でした。まだ問題を完全には理解できていない段階でも、現時点の理解でコードを書いて出荷することで学びを早められる — これは借金で事業を加速するのと同じで正当な戦略である。ただし、理解が進んだら、その学びをコードに反映して負債を返済しなければならない。返済せずに借り続ければ、いずれ利払いだけで手一杯になり開発が止まる、という警告です。

つまり原義における負債とは「意図的な借り入れと、学びによる返済」のサイクルでした。当時、非エンジニアの経営層に「なぜ動いているコードを書き直す時間が必要なのか」を説明するのは困難でしたが、金融の語彙に翻訳したことで、「元本」「利子」「返済」としてビジネス側と同じ土俵で議論できるようになったのです。後にこの言葉は「単に汚いコード」全般を指すように拡大しましたが、原義の「意図性」を区別することが、負債と付き合ううえで重要になります。

詳細

負債の4象限 — どんな借り方をしたか

Martin Fowler は技術的負債を「意図的か / 無自覚か」「慎重か / 無謀か」の2軸で4象限に整理しました。同じ「良くないコード」でも、どの象限の負債かによって評価がまったく異なります。

左上の「慎重かつ意図的」だけが原義どおりの戦略的な負債です。トレードオフを理解したうえで借り、返済の当てもある。右上の「慎重だが無自覚」は、最善を尽くしても後から「ああ設計すべきだった」と分かるもので、学習する組織なら必ず発生します。危険なのは下段です。「慎重さを欠いた意図的な負債」は利子の見積もりなしの借金であり、「無自覚かつ無謀な負債」は基本スキルの不足による劣化で、そもそも借金している自覚すらありません。下段の負債はコードレビューやペアでの作業、教育によって発生自体を防ぐのが第一です。

利子の正体 — なぜ開発が遅くなるのか

負債の利子は請求書として届くわけではなく、日々の開発の中に紛れ込みます。具体的には、変更のたびに歪んだ構造を回避するコードを書き足す手間、影響範囲が読めず調査に費やす時間、修正が別の箇所を壊すリグレッション（デグレ）、そして「怖いから触らない」ことで選択肢が狭まる機会損失です。テストがないことも重大な負債の一形態です。テストという安全網がないコードは検証コストが高く、あらゆる変更の利子を押し上げます。また、負債はコードだけでなくアーキテクチャの水準でも発生します。たとえば境界設計を怠ったモノリスが「どこを触っても全体に波及する」状態に陥るのは典型的なアーキテクチャ負債で、慌ててマイクロサービスに分割しても、境界の混乱ごと分散させれば負債は減るどころか利子が上がります。

返済戦略

負債の返済とは、構造の歪みを解消すること、すなわちリファクタリングです。現実的な返済戦略にはいくつかの型があります。第一に、全部を返そうとしないこと。利子は「よく変更する場所」でしか発生しないため、変更頻度の高いホットスポットに返済を集中させ、もう触らないコードの負債は放置してよいのです。第二に、一括返済より分割払いを選ぶこと。「リファクタリング専用の1か月」を確保するのは承認も難しく失敗しやすいため、機能開発のついでに通り道を少しずつ直す方が持続します。第三に、新たな無謀な借金を止めること。レビューや CI/CD の自動チェックで品質の下限を守り、負債の増加速度を返済速度が上回る状態を作ります。

ビジネス側への説明

技術的負債の議論が失敗する典型は、エンジニアが「コードが汚いので直したい」と美意識の言葉で語ることです。ビジネス側に伝わるのは美しさではなく速度とリスクです。「この領域の変更に以前は2日だったが今は2週間かかっている」「次の機能はこのモジュールに乗るので、先に3日返済すれば実装が5日縮む」のように、利子を時間とお金の言葉に翻訳して初めて、負債メタファーは本来の力 — 技術とビジネスの共通言語 — を発揮します。逆にエンジニア側も、すべての負債返済が投資に見合うわけではないことを受け入れる必要があります。借金と同じで、問われるのはゼロにすることではなく、健全な水準で回し続けることです。