ソフトウェアシステムでは、クラフト（出来の悪いもの）が生まれやすい。システムの修正や拡張をしようとしても、内部品質の欠如がそれを難しくしている。「技術的負債」とは、Ward Cunninghamが作ったメタファーである。ファイナンスの負債のように考えることで、こうしたクラフトの扱いのことを考えやすくなる。たとえば、新機能の追加にかかる余分な労力は、負債の返済にかかる利子である。

あらゆるソフトウェアシステムには、タスクを実行するために必要とされる「本質的な」複雑さが一定量含まれている…… ……だが、ほとんどのシステムには「クラフト」が存在しており、理解を難しくしている。

クラフトがあると、変更するのに余分な労力がかかる。

技術的負債のメタファーは、こうしたクラフトを「負債」として扱う。変更に必要な余分な労力は、負債の利子の返済に相当する。

私のコードのモジュール構造が複雑だったとしよう。ここに新機能を追加したい。モジュール構造が明確ならば、4日で終わるだろう。だが、クラフトがあるので6日もかかってしまう。この2日の違いが、負債の利子である。

私が負債のメタファーを気に入っているのは、こうしたクラフトの扱いのことを考えやすくしてくれるところだ。たとえば、クラフトを削除してモジュール構造をクリーンにするのに5日かかるとしよう。負債のメタファーを使えば、元本を返済していることになる。だが、この機能のためだけにやったとすると、何の得も得られない。本来なら6日で終わるところが、9日もかかっているからだ。だが、似たような機能が他に2つあったとすれば、先にクラフトを削除することで、日数が短縮されただろう。

このように言うと、数字をいじるだけの簡単なことのように聞こえる。スプレッドシートを操作するマネージャーが選択すればいいだけのようにも思える。だが、残念ながら生産性は計測できないので、これらのコストも客観的にはわからない。ある機能に必要な工数、クラフトを削除したあとにかかる工数、クラフトの削除にかかる工数を見積もることはできる。だが、こうした見積もりの正確度はかなり低い。

以上を踏まえると、我々がファイナンスの負債でやっているように、元本を少しずつ返済していくのが最善の道筋になるだろう。最初の機能については、余分な日数をかけてクラフトを削除する。これで新規に機能追加するときに、金利が1日くらいに下がるだろう。これでもまだ余分な時間はかかるだろうが、クラフトを削除したことで、これからコードを変更するときに安価にできる。このように少しずつ改善する大きな利点は、頻繁に修正する部分のクラフトの削除に時間をかけられるということだ。これは、コードから最もクラフトを削除したい部分でもある。

利子を返済するのか、それとも元本を返済するのかを考えれば、どのクラフトに対処すべきかを決定しやすくなる。コードにひどい部分があり、変更するのは悪夢のようだと思っていても、修正する必要がなければ問題にはなることはない。この部分に手を入れることがあっても、利子を支払えば済む（ファイナンスの利子は時間経過によって発生するので、ここはメタファーがうまく機能していない）。したがって、クラフトはあるが安定している部分が残る。一方、変更が激しい部分ではクラフトを容認できない。利子の支払いが異常に高くなるからだ。ここは特に重要である。開発者が内部品質に注意を払わずに変更を加えていると、クラフトが累積していくからだ。つまり、変更を加えていけば、クラフトが増加するリスクが高まるのである。

負債のメタファーは、内部品質に対する無視を正当化するために使われることがある。クラフトが増えないようにするには、時間も労力もかかるという主張だ。緊急で必要な新機能があったときに、これから管理しなければいけないことを受け入れながら、負債を背負うこともあるだろう。

ここで危険なのは、分析が十分ではないことが多いことだ。クラフトの影響はすぐに出る。緊急で必要な新機能を遅延させてしまうのだ。クレジットカードの限度額いっぱいまで使ってしまったチームは、内部品質を高めるために労力をかけたときよりもデリバリーが遅い。こうしたダイナミクスはファイナンスのローンとは一致していないため、メタファーを使っているとよくわからなくなってくる。負債を抱えることでデリバリーを加速できるのは、設計＝スタミナ仮説の設計損益ラインを下回っているときだけである。そして、この設計損益ラインに到達するのは数か月ではなく数週間以内である。

クラフトの種類によって負債とそれ以外に分けるべきか、という議論が定期的に起こる。私としては、その負債が「意図的」なものか、「慎重」なのか「無鉄砲」なのかで考えることが有益であると思っている。このことについては、技術的負債の四象限にまとめた。

さらに詳しく知るために

私の知る限り、Wardが最初にこの概念を提供したのは、OOPSLA 1992の体験レポートだった。今でもWikiで議論が続いている。

Ward Cunninghamは、彼の作ったこのメタファーについて動画で語っている。

Dave Nicoletteは、Wardの技術的負債の考えを拡張し、優れたケーススタディとしてまとめている。私はこれを「慎重かつ不注意」型と呼んでいる。

数名の読者から同様のいい名前が送られてきた。David Panaritiは、醜悪なプログラミングのことを「赤字プログラミング」と呼んでいる。彼は数年前から使い始めたようだが、当時の政策をよく表している。今でも自然に使える名前だ。

Scott Woodは「現在の技術レベルがプロダクトの基盤のレベルを上回り、業界との互換性が失われるようになると、こうした基盤の喪失は『技術的インフレ』と見なせるだろう。言語のバージョンを例にすると、あなたのコードと主流のコンパイラとの互換性がなくなるようなことである」と提案している。

Steve McConnellは、技術的負債の優れたポイントをいくつか明らかにしている。たとえば、意図しない負債を抑えておくことで、便利な負債を意図的に受け入れる余裕を残す方法を述べている。彼の「最低限の返済」の考えも好きだ（ウェブサイトとは違い、組込みシステムで問題を修正するのは非常に高い）。

Aaron Ericksonは、エンロンの財務管理について語っている。

Henrik Knibergは、最大の問題を引き起こすのは最古の技術的負債であると主張している。そして、こうした負債を管理するには、質的に上限を設けるべきだと述べている。

Erik Dietrichは、技術的負債の人的コスト（チーム内の紛争、スキルの退化、疲弊）について説明している。

履歴

最初に投稿したのは2003年10月1日である。2019年4月に大幅に書き換えた。（訳注：過去のバージョンはgithubの履歴でたどれます）