技術的負債
"進化するプログラムが継続的に変更されると、構造の劣化を反映して複雑さが増し、それを維持したり減らしたりする作業が行われない限り、複雑さが増していく」。 - Meir Manny Lehman, 1980
マニー・リーマンの法則は、進化するプログラムは、維持するための作業を行わない限り、継続的にその複雑さと劣化した構造を増していくことをすでに示していたが、ウォード・カニンガムは、1992年の経験報告で、技術的な複雑さと負債の比較を初めて行った。
"最初のコードを出荷することは、借金をするようなものだ。少々の借金は、書き換えによって速やかに返済される限り、開発を加速させる。危険なのは、その負債が返済されないときだ。正しいとは言えないコードのために費やされた1分1秒が、その負債の利息としてカウントされるのである。オブジェクト指向であろうとなかろうと、統合されていない実装の負債の負荷によって、エンジニアリング組織全体が停止してしまう可能性があるのだ。" - 1992年、ワード・カニンガム
Joshua Kerievskyは、2004年に発表したテキスト『Refactoring to Patterns』の中で、アーキテクチャの怠慢に伴うコストを「設計負債」と表現し、同様の議論を展開している。
後回しにされる活動には、文書化、テストの作成、TODOコメントへの対応、コンパイラや静的コード解析の警告への対処などがある。また、技術的負債には、組織内で共有されていない知識や、混乱していて簡単に修正できないコードなどがある。
2014年にPHPの開発について書いたJunade Aliはこう述べている。
この技術的負債を返済しないことの代償は明らかである。
"利子の支払い"は、ローカルで必要なメンテナンスと、プロジェクトの他のユーザーがメンテナンスを行わないことの両方によって発生する。上流のプロジェクトで継続的な開発を行うと、将来的に「負債を返済する」ためのコストが増加する。完結していない作業を完了させるだけで、負債を返済することになる。
技術的負債の蓄積は、プロジェクトが納期に間に合わなくなる大きな原因となる。技術的負債を返済するために必要な作業量を正確に見積もることは困難である。変更に着手するたびに、不確実な量の未完成の作業がプロジェクトにコミットされる。プロジェクトは、未完了の作業(負債)が完了するための時間よりも多いことに気付いたときに、期限を逃してしまう。予測可能なリリーススケジュールを実現するためには、開発チームは未完成の作業(または負債)の量を常に小さくするために、進行中の作業の量を制限する必要がある。
提出の障害にならない程度の作業が完了していれば、技術的な負債が相当量残っているプロジェクトがリリースされる。このソフトウェアが本番環境に到達した場合、技術的負債を解決するためのリファクタリングを実施するリスクは劇的に高まる。本番コードの修正には、サービス停止のリスク、実際の金銭的な損失、サービス水準合意(SLA)を伴う契約の場合には法的な影響を受ける可能性もある。このような理由から、技術的負債を本番環境に持ち込むことは、ほとんど金利の上昇と同じように考えることができ、この金利が下がるのは、デプロイメントが却下されてリタイアするときだけである。
技術的負債(英語: technical debt)、または設計負債、コード負債とは、ソフトウェア開発における概念であり、時間がかかるより良いアプローチを使用する代わりに、今すぐ簡単な(限定的な)解決策を選択することで生じる追加の手直しの暗黙のコストを反映したものである。
金銭的な負債と同様に、技術的負債も返済されなければ、「利子」が蓄積され、変更の実施が困難になる。技術的負債を処理しないと、ソフトウェアのエントロピーが増大する。金銭的負債と同様に、技術的負債も必ずしも悪いものではなく、プロジェクトを前進させるために(概念実証として)必要な場合もある。一方で、「技術的負債」というメタファーは、その影響を最小限に抑える傾向があり、その結果、修正するために必要な作業の優先順位付けが不十分になると主張する専門家もいる。
コードベース上で変更が開始されると、コードベースの他の部分やドキュメントにも、他の調整された変更が必要になることがよくある。完了していない必要な変更は負債とみなされ、支払われるまでは利息が上乗せされて発生するため、プロジェクトの構築が煩雑になる。この言葉は主にソフトウェア開発で使われるが、他の職業にも適用できる。