要点： 技術的負債は1992年にWard Cunninghamが作った言葉で、本来の意味は汚いコードではなく、コードと現在の理解とのギャップです。
Cunninghamは、負債戦略を機能させるには、むしろコードがきれいでなければならないと強調しました。
開発者が非開発者にリファクタリングを説明するときに使う言葉があります。技術的負債です。
前回の記事コードスメル #5から続く内容です。
今すぐ作るために借金をし、利子がついているので返す時間がほしい、という話です。
しかし、この言葉を最初に作った本人は、自分の比喩が誤って使われていると何度も説明しています。特に、汚いコードを負債と呼ぶことについてです。
1992年、Ward Cunningham
技術的負債という表現は、Ward Cunninghamが1992年に初めて使いました。OOPSLA（Object-Oriented Programming, Systems, Languages & Applications、オブジェクト指向プログラミング学会）の経験報告でのことです（論文）。
Wikiの発明者であり、エクストリームプログラミングの初期メンバーとしても知られる、あのCunninghamです。
当時、彼は金融ソフトウェアを開発していました。難しかったのはドメインです。
金融商品の構造を最初から正確に理解して始めることはできません。そこで、その時点で理解している範囲で作ってリリースし、使いながら学んだことをコードに反映し続ける方法を選びました。
彼の言う負債はここで生じます。現在のコードに含まれる理解と、チームが実際に得た現在の理解との間にある差です。
最初に書いたときは正しかった構造が、ドメインを深く理解した今見ると適切でない状態。それが負債であり、新しい理解に合わせてコードを直すことが返済です。
2009年、彼はこの比喩を改めて説明し、誤解を正す短い動画を残しました。要点は次のとおりです（Debt Metaphor）。
負債を負うのは早く学ぶための戦略であり、ひどいコードを書いてよいという許可ではありません。むしろ負債戦略を機能させるにはコードがきれいでなければなりません。
汚いコードでは、学んだことを反映する作業そのものが不可能になるからです。
ここが重要です。本来の概念では、負債はきれいに書かれたコードからも生じます。
時間とともに世界の理解の仕方が変わると、自動的に発生するからです。
一方、現在技術的負債と呼ばれているものの多くは、単に雑に書かれたコードです。Cunninghamの主張に従えば、それは負債というより単なる混乱した状態です。
Fowlerの四象限
とはいえ、「本当の負債だけが負債」と線引きすると、実務では使いにくくなります。Martin Fowlerが2009年に整理した四象限は、この隔たりをうまく埋めます（Technical Debt Quadrant）。
2つの軸を使います。意図的か偶発的か、そして無謀か慎重かです。
| 無謀 | 慎重 | |
|---|---|---|
| 意図的 | 「設計する時間がない」 | 「今リリースして代償は受け入れる」 |
| 偶発的 | 「レイヤー分離とは何ですか」 | 「今になってどうすべきだったか分かった」 |
4つのセルは、それぞれ性質が異なります。
意図的・慎重は経営上の判断です。締め切りがあり、遅れれば機会を逃す一方、後でコストを支払うことを理解したうえで選択します。
負債という比喩が最も正確に当てはまるセルです。
条件が1つあります。代償を理解していることです。
偶発的・慎重が、Cunninghamの語った本来の負債です。最善を尽くして作ったものの、6か月後にドメインをさらに理解し、よりよい構造が見えてきた状態です。
誰も間違ったことをしていなくても発生します。避けられないため、返済のサイクルを設ける以外に対策はありません。
意図的・無謀は、分かっていながら手を抜くことです。よく負債と呼ばれますが、返済計画がないという点で、負債より損失に近いものです。
偶発的・無謀は、知らなかったためにそうなったケースです。ここで必要なのはリファクタリングの予定ではなく、学習です。
同じ汚いコードでも、どのセルに属するかで対応は変わります。チームが負債について話すときに食い違うのは、異なるセルを思い浮かべていることが多いのです。
利子は何で支払うのか
金融上の負債の利子はお金ですが、技術的負債の利子は将来の変更コストです。同じ機能の追加が、負債がなければ1日、あれば3日かかるなら、2日分が利子です。
この定義から、1つの結論が導かれます。触らないコードの負債は利子がゼロです。
5年間誰も直していないモジュールがどれほど汚くても、これからも直さないなら返済する理由はありません。反対に、毎週触る画面の小さな負債には利子が発生し続けます。
負債リストを「どれだけ悪いか」で並べるチームは多いですが、本当の基準は「どれだけ頻繁に触るか」であるべきです。
前回の記事で使ったGitの変更頻度の調査は、ここでも役立ちます。頻繁に変わるファイルと品質の低いファイルが重なる場所、そこが最も金利の高い場所です。
Adam Tornhillは、この共通部分を見つけて優先順位を付けるアプローチを行動ベースのコード分析と呼んでいます。
この比喩の限界
技術的負債という言葉は便利だからこそ問題になります。何でもそこに入れられるからです。
バグも、古いライブラリも、気に入らない設計も、自分が書いていないコードも、すべて負債と呼ばれます。そうすると、この言葉は「直したいもの」の同義語になり、本来の説明力を失います。
実用上は、2つの質問を通過したものだけを負債と呼ぶのがよいでしょう。
- **何を得るために負ったのか。**時間を稼いだのか、学びを得たのかを説明できなければなりません。何も得ていないなら、それは負債ではなく失敗です。
- **どう返済するのか。**返済計画のない借金では、比喩が成り立ちません。
比喩そのものに反対する見方もあります。負債という言葉が「いつか返せばよい」という印象を与え、実際には複利で膨らんで返済不能になる状況を隠してしまうからです。
返済するものではなく、継続的に片付けるものに近いという理由から、汚染や衛生問題と呼ぼうと提案する人もいます。
ただ、負債という言葉が長く生き残っているのには理由があります。開発の外部と会話できる数少ない比喩だからです。
Cunninghamが最初にこの比喩を使った場面も、上司に手戻りの必要性を説明する文脈でした。精密な用語ではありませんが、翻訳の道具として今も価値があります。
実務での管理方法
**一覧にはしますが、イシュートラッカーに埋めません。**負債チケットだけを集めたバックログは、たいてい誰にも見られません。
代わりに、コードの近くに残す方法があります。なぜこうなっていて何が必要なのかを対象ファイルに短く書いておけば、次にそのファイルを開く人が必ず目にします。
**触るついでに返済します。**そのファイルをどうせ直すときが利子の発生する時点であり、文脈が頭にある時点でもあります。
ボーイスカウト・ルール、つまり「来たときよりきれいにして立ち去る」が、負債管理の方法として実際に有効な理由です。
**返済しないと決めることも管理です。**負債リストの半分は返済対象ではなく、記録対象です。
返済しないと明示的に決めた項目は、次回同じ議論を繰り返さずに済むようにします。
意図的に負うときは条件も一緒に記録します。「リリース後2週間以内」「ユーザーが1万人を超える前」のようにです。
時期を決めずに負った借金には、返済時期もありません。
まとめ
- 技術的負債は1992年にWard Cunninghamが作った言葉で、本来の意味は汚いコードではなく、コードと現在の理解とのギャップです。
- Cunninghamは、負債戦略を機能させるには、むしろコードがきれいでなければならないと強調しました。
- Fowlerの四象限は、意図性と慎重さで4つのセルに分けます。セルごとに対応が異なります。
- 利子は将来の変更コストです。触らないコードの負債は利子がゼロなので、返済する理由はありません。
- 何を得て、どう返済するのかを説明できないなら、それは負債ではなく単なる問題です。
次回は、負債が手に負えないほど蓄積したときの選択肢を扱います。直して使い続けるのか、新しく作り直すのか。
ソフトウェア業界で最も高価な誤答が生まれた場所でもあります。
出典と確認基準
- The WyCash Portfolio Management System — Ward Cunningham · 論文原文 · 確認 2026-08-17 · 根拠：1992年の技術的負債の比喩に関する本来の説明
- Debt Metaphor — Ward Cunningham · 著者原文 · 確認 2026-08-17 · 根拠：2009年のWard Cunninghamによる技術的負債の比喩の解説
- Technical Debt Quadrant — Martin Fowler · 著者原文 · 確認 2026-08-17 · 根拠：慎重・無謀と意図性で分類した技術的負債の四象限