Loading article…
技術的負債（設計負債[ 1 ]またはコード負債とも呼ばれる）は、システムの開発において便宜的な解決策を選択したことによって生じる、システムの維持にかかるコストを定性的に表したものである。 [ 2 ]迅速な解決策は短期的には開発を加速させる可能性があるが、結果として生じる低品質が未解決のまま放置されると、将来のコストが増加する可能性がある。[ 3 ]この用語は、情報技術、特にソフトウェア開発の文脈でよく使用される。
技術的負債は、金銭的負債と似ている点もあれば、大きく異なる点もあります。どちらも、将来の目標達成を困難にする要因となります。しかし、金銭的負債とは異なり、技術的負債は意図せず発生することが多いのです。開発時間とコストを最小限に抑えるという、ビジネスにおいて常に存在する目標が、主な要因となります。技術的負債は、一般的に開発作業後に事後的に評価されます。
技術的負債を適切に管理することは、ソフトウェアの品質と長期的な持続可能性を維持するために不可欠です。場合によっては、概念実証の提供や迅速なリリースなど、当面の目標を達成するために、技術的負債を抱えることが戦略的な選択となることもあります。しかし、負債の優先順位付けと対処を怠ると、保守性の低下、開発コストの増加、本番システムへのリスクにつながる可能性があります。[ 4 ] [ 5 ]
技術的負債は、短期的な最適化を図る設計や実装の決定によって生じるが、その代償として将来の適応性や保守性が損なわれる。技術的負債を生じさせるシステム側面は、将来の変更をよりコストのかかるものにしたり、不可能にしたりする設計や実装の構造の集合体として説明でき、主に保守性や進化性といった内部システム品質に影響を与える。[ 6 ]
ワード・カニンガムは1992年に技術的負債という用語を作り出した。[ 7 ]カニンガムは『Metaphors We Live By』を読んだ後、彼らが取り組んでいた金融商品のリファクタリングの必要性を上司に説明するために、この負債のメタファーを考案した。 [ 8 ] [ 9 ]
初めてコードを出荷することは、借金をするようなものだ。少しの借金は、すぐに書き直しで返済される限り、開発を加速させる。…危険なのは、借金が返済されない場合だ。完璧ではないコードに費やした時間はすべて、その借金の利息としてカウントされる。統合されていない実装（オブジェクト指向であろうとなかろうと）の負債負荷によって、エンジニアリング組織全体が停止してしまう可能性がある。[ 10 ]
同様の概念は以前にも存在していた。1980年、メイア・「マニー」・レーマンは、ソフトウェアの劣化する性質を「建築的メタファー」を用いて表現した同様の法則を発表した。マニーの法則は、「進化するプログラムは継続的に変更されるため、構造の劣化を反映して複雑さが増し、それを維持または削減するための作業が行われない限り、複雑さは増大する」と述べている。[ 11 ]
技術的負債の一般的な原因には、以下のようなものがあります。
技術的負債は、継続的なメンテナンスのコストを増加させることで、リリース スケジュールの予測を困難にします。「利息の支払い」は、未完了の作業と、上流プロジェクトの変更による統合コストの上昇によって発生します。複雑さの増加と未完了の作業量の増加により、労力を正確に見積もることがますます困難になり、遅延、期限の遅延、エンジニアリング チームへのストレスが発生し、スタッフの離職率の上昇につながり、問題がさらに悪化します。[ 15 ]技術的負債を本番環境に持ち込むと、サービス レベル契約違反による停止、金銭的損失、潜在的な法的問題のリスクが高まります。将来のリファクタリングは、よりリスクが高く、コストも高くなり、本番コードの変更により、より大きな混乱の可能性が生じます。
技術的負債に対処しないと、生産性が低下し、機能の提供が遅れる可能性があります。技術的負債の累積的な影響により、システムはますます脆弱になり、大胆な改善が困難になります。漸進的な変更が支配的になり、重要なリファクタリングが遅れると、一貫性のない設計のストレスのかかったシステムになり、ユーザーはパフォーマンスの低下や機能の制限に苦しみ、開発者は品質の維持に苦労します。[ 1 ] [ 16 ]
ケニー・ルービンは、技術的負債を管理するために以下のカテゴリを使用しています。[ 17 ]
技術的負債の概念は、過度に迅速な開発作業が将来追加コストを生み、その作業中に異なる決定がなされていればコストは回避できたであろうという前提に基づいています。確かにその通りですが、迅速な開発決定の潜在的なコストには他の考慮事項も影響します。たとえば、システムが次のリリースに向けて修正されるほど長く存続しない場合、迅速な開発選択による節約は将来の開発コストが発生しないため、真の節約となります。[ 18 ]将来の出来事により、迅速な「長期」設計が時代遅れになる可能性もあります。[ 19 ]新しいツールや技術によって将来の再作業のコストが削減され、現在の負債の前提が覆される可能性があります。[ 19 ]
私が上司に説明したのは、金融ソフトウェアに関するもので、私が「負債のメタファー」と呼んだ金融のアナロジーでした。それは、もし私たちが当時理解していた金融対象に関する正しい考え方にプログラムを合わせなければ、私たちはその意見の相違に常につまずき、それがローンの利息を支払うように私たちのスピードを遅くするだろう、というものでした。