はじめに
近年、技術的負債というキーワードが広まっているものの、そこには明確な定義が無く、理解が曖昧なまま用いることでトラブルになっているような話を聞きます。
私自身もざっくりとしたイメージしかなかったので、改めて調べてみました。本記事はそのまとめです。
"技術的負債"の誕生
初出（1992年）
Ward Cunningham 氏が生みの親という話は聞きますが、最初に"負債"という言葉を用いたのは OOPSLA '92 の Experience Report のようです。
Shipping first time code is like going into debt.
訳）初めてコードを出荷することは、借金をするようなものです。
「技術的負債の生みの親」と聞きますが、上の一文を含めレポート全体を見ても debt（負債） としか行っておらず、 technical（技術的） は付いていません。
Ward Cunningham 氏 本人による説明（2009年）
レポートの背景について説明した動画がYouTubeに投稿されています。
（同じく本人による文字起こし記事と、t_wadaさんによる翻訳記事）
説明の中で、負債（Debt）のメタファーが生まれた背景として次のように語っています。
The explanation I gave to my boss, and this was financial software, was a financial analogy I called "the debt metaphor".
訳）私が上司にした説明は、これは金融ソフトなのですが、私が「負債のメタファー」と呼んでいる金融の例え話でした。
つまり、学術的に何かを負債と定義したのではなく、職場でのコミュニケーションでお互い理解がある金融のキーワードを使った例え話から生まれたものです。（もしプロダクトが金融系でなければ、負債ではなかったかもしれませんね）
そういった背景なので、単に debt（負債） だけで、technical（技術的） は付いていないのでしょう。
"技術的"負債の生まれは？
では"技術的"が付いたのどういった経緯なのか？
実際のところはわかりませんが、最古のwiki（C2wiki）の TechnicalDebt は Dave Smith という方が書いたようです。
TechnicalDebt is a measure of how untidy or out-of-date the development work area for a product is. --DaveSmith
訳）技術的負債は、ある製品の開発作業領域がどれだけ整理整頓されているか、あるいは古くなっているかを示す指標である。 --デイヴ・スミス
負債とはどんなものか
負債のメタファーが生まれた経緯についてはわかったので、次のその中身を見ていきます。
Ward Cunningham 氏の負債
Ward Cunningham 氏の説明動画からです。
訳）ソフトウエアを急いで出して、いろいろなことを学んでも、その学びをプログラムに還元しないケースはたくさんあったと思います。それは例えるなら、返済の必要がないと思ってお金を借りるようなものです。もちろん、そんなことをしたら、たとえばクレジットカードの場合、最終的には収入がすべて利息に消えて、購買力がゼロになってしまいます。
技術的負債に抱く私のイメージはもっとネガティブなものだったのですが、この説明からはそのようなイメージはありません。よく聞くのは「スピードのために質をトレードオフした結果」のような話ですが、”コードを貧弱に書くことには決して賛成ではない"と語っています。
訳）負債のメタファーは、負債を返済する力であり、それを上手く活用できるかどうかは問題を理解したときにリファクタリングできるようなきれいなコードを書けるかどうかにかかっています。
このように、あくまでリファクタリング可能な十分に設計されたコードを前提に話しているのであり、「不摂生により病気になってしまった」ようなネガティブなイメージではなく、「成長して身体に合わなくなった服や靴を替える」ような状況をイメージします。
"負債"に抱くイメージ
『エンジニアリング組織論への招待』の著者、広木 大地さんの記事からです。
経営者ではない多くの人々にとって、「放っていてはいけない」「定期的に返済すべきもの」として、負債という言葉が用いられています。
経営者にとっての「負債」という言葉には、資本としての意味合いもあります。～中略～。負債を多く借り入れることができることは、信用度の高さを意味していて、決して「借金」という日常語的な理解よりもポジティブな意味合いを見出しています。
積み重なった複雑なコードに向き合っているエンジニアとって、負債はまさに「放っていてはいけない」ものというイメージであり、目の前の状況を説明するのに適当な言葉に思えます。
しかしここで思い出すのが、 Ward Cunningham 氏が負債という言葉で例え話をしたのは「金融系のプロダクトを開発している」という土台があったからです。
その土台がない状態で安易に技術的負債という言葉を使用した結果、負債に抱くイメージの違いから誤解が生じてしまうことが想像できます。
乱雑は技術的負債ではない
『Clean Architecture』などのCleanシリーズでお馴染みのボブおじさん（Robert C. Matin 氏）の技術的負債についての投稿です。
訳）乱雑は技術的負債ではありません。乱雑はただの乱雑です。技術的負債の決定は、実際のプロジェクトの制約に基づいて行われます。リスクはありますが、有益な場合もあります。乱雑にする決定は決して合理的ではなく、常に怠慢と非専門家精神に基づいており、将来的に報われる見込みはないのです。
Ward Cunningham 氏と同じように雑なコードには賛成しておらず、"技術的負債は必要かもしれないが、クリーンでなければならない！"と語っています。
"技術的負債"という言葉との向き合い方
ここまでで、技術的負債（または負債）に明確な定義はなく、人によって様々な捉え方がされるものだとわかりました。
ではどのように向き合っていくのが良いのでしょうか。
万能なメタファーではない
Martin Fowler 氏の技術的負債についての投稿です。（日本語訳）
Martin Fowler 氏は負債のメタファーについて、 "クラフト（出来の悪いもの）の扱いのことを考えやすくしてくれる"としていますが、一方で次のようにも述べています。
訳）負債のメタファーは、内部品質に対する無視を正当化するために使われることがある。クラフトが増えないようにするには、時間も労力もかかるという主張だ。
ここで危険なのは、分析が十分ではないことが多いことだ。クラフトの影響はすぐに出る。緊急で必要な新機能を遅延させてしまうのだ。クレジットカードの限度額いっぱいまで使ってしまったチームは、内部品質を高めるために労力をかけたときよりもデリバリーが遅い。こうしたダイナミクスはファイナンスのローンとは一致していないため、メタファーを使っているとよくわからなくなってくる。
ソフトウェア開発における生産性や品質は計測するのが難しく、全て金融の仕組みで説明できるものではない、ということでしょう。1
技術的負債という言葉はあくまで理解を得るための例え話として使い、過度に頼らずコミュニケーションを重ねる必要があると考えます。負債という言葉に馴染みがなければ、自分たちにとって身近な言葉に置き換えても良いと思います。
「何が負債か？」より「助けになるか？」
さらに Martin Fowler 氏は「負債とは何か？」という議論について、次の記事を書いています。（日本語訳）
訳）設計の不備が負債かそうじゃないかなんて考えることが、そもそも間違ってると思う。 技術的負債というのはメタファなのだから、 ここで問うべきなのは「負債のメタファは、 設計上の問題を考える助けになるだろうか？ そして、他人と意見交換しやすくなるだろうか？」だ。 負債のメタファを使う大きなメリットは、 技術者以外にも話が通じやすくなることだろう。
ソフトウェアの状況をコードを書かない関係者に説明するのは難しいものです。負債に対するイメージの違いによって誤解が生じてしまう懸念はありますが、話し合いの取っ掛かりとしては有用でしょう。
さらに負債とは何であるかについて、"負債かそうじゃないかという区別はあまり意味がなく、 慎重に考えた上での負債なのか、無鉄砲な負債なのかのほうが大事だ"として、「無鉄砲／慎重」と「意図的／不注意」の基準で分類した 技術的負債の四象限 について説明しています。
これを用いて振り返ると、世の中に広まっている技術的負債のイメージは「無鉄砲（とりわけ不注意）な負債」で、Ward Cunningham 氏の語る負債は「慎重で不注意な負債」に当たりそうです。
このように技術的負債の四象限を用いて、問題を感じているコードがどの負債に当てはまるのか分析し、それを元に対応を議論したほうが、何が負債かを議論するよりも解決につながりそうです。例えば「慎重で不注意な負債」なら利子を払うか元本を返済するかを考えるでしょうし、「無鉄砲で不注意な負債」なら設計の効果や良い設計を学ぶといったことが考えられます。
まとめ
言葉の生まれから調べることで、どのように捉えて向き合っていけばよいのかが、より明確になりました。
負債のメタファーは手っ取り早くソフトウェア開発の状況を説明するのに役立ちますが、万能ではありません。金融の負債に対するイメージは人それぞれであり、ソフトウェア開発の全てを金融の仕組みに置き換えることはできません。負債という言葉に囚われることなくコードの問題を分析し、コミュニケーションを重ねることが大切なのだと思います。