技術的負債

http://www.martinfowler.com/bliki/TechnicalDebt.html

システムに新しい機能を追加するとしよう。2つのやり方があるはずだ。ひとつは、早いけれど、ぐちゃぐちゃになるやり方（将来、変更が困難になることは分かっているよね）。もうひとつは、キレイな設計だけど、導入に時間のかかるやり方。

「技術的負債」とは、Ward Cunningham が作ったメタファーである。上記の問題について考える際に、この言葉が役に立つ。このメタファーを使うと、早いけれど汚い解決方法は（ファイナンスの負債と同じく）技術的な負債が発生する、ということになる。 通常の負債と同じく、こちらの負債も利子を払う必要がでてくる。 早いけれど汚い設計を選んだせいで、将来の開発において余分な労力をさかねばならなくなる、というわけだ。 これからずっと利子を払いつづけていくことも可能だし、 リファクタリングによって良い設計に修正し、元本を減らしてしまうということも可能だ。 もちろん元本を減らすのにはコストがかかる。だが、それによって将来かかる利子が減るため、結果的には得なのである。

このメタファーを使うと、早いけれど汚い方法がなぜよく使われるのか、ということを説明できる。ビジネスの世界では、市場機会の優位性を得るために負債を負うことがある。そのため、開発者たちは重要な納期に間に合わせるために、技術的負債を負う。 これはよくある問題である。開発組織は自分たちの負債をコントロールできず、将来的な開発のすべてを利子を払い続けるということに費やさねばならないわけだ。

この技術的負債にまつわるおかしな現象は、お金と違って効果を計測することが出来ない（当然）。利子によってチームの生産性は下がるが、生産性は計測することが出来ないため、技術的負債の本当の影響度は分からない。

（今言えることは、Ward が最初にこのコンセプトを発表したのは OOPSLA 1992 の事例発表のときであり、それが今なおwiki上で議論されているということだ。）

追加コメント

何人かの読者から、同じようないい言葉を教えてもらった。 David Panariti は醜悪なプログラミングを赤字プログラミングと呼んでいる。 おそらく彼は数年前から使い始めたのであろう。当時の政策をよく表している。;今もそうかもしれない。

Scott Wood はこう述べている。 「産業との互換性を失いはじめるほどまで、現在の技術レベルがあなたの製品の技術レベルを超えるとき、技術的インフレは、（あなたの生活・生産のための）地盤の喪失という形であらわれるだろう。 たとえば、言語のバージョンを例にすると、あなたのコードが主流のコンパイラと互換性が無くなるときが、それに該当する。」

• 2004-01-09 (金) 11:49:52 名無しさん? : 最後のところは（だから、いつまでも古い技術で何とかしようとせず、努力して技術的負債を返したほうが安全ですよ）という意味。
• 2005-12-06 (火) 14:17:51 名無しさん : いえ、追加コメントの中は二つとも「技術的負債」以外の"経済的な"メタファの例が挙げてあるだけで、「だから〜」という主張ではないと思います。