"技術的負債"という言葉はWard Cunningham氏によって作られた。この言葉が表すのは、短期的には簡単に実装できるが長期的には大きな悪影響を生み出すような設計上の方法を採用してしまったがために、開発チームが引き受けざるを得ない義務のことだ。技術的負債をどう考えるべきか、どのように分類できるか、についてアジャイルを実践する人々がそれぞれの見解を表明している。
Martin Fowler氏は技術的負債について次のように定義している。
技術的負債は金融の負債と似ています。金融の負債と同じように、技術的負債にも利息を支払わなければなりません。この支払いは、将来の開発で必ず発生する余計な努力というかたちで支払うことになるでしょう。原因は、素早いが汚い設計をしてしまったことにあります。コツコツと利子を返していくという選択肢もありますが、この素早いが汚い設計をリファクタリングして良い設計にすることで元金を返済することもできます。もちろん元金を返済するにはコストがかかりますが、将来の利息の支払いは少なくなるでしょう。
Steve McConnell氏は技術的負債をふたつの種類に分類している。
- 偶発的 – 若い開発者が、経験不足なため汚いコードを書いてしまう。
- 意図的 - チームで議論し、合意のもとにある設計を選択する。この設計を選んだことで、チームの方針は将来のことよりも現在の作業効率を最適化することに決まる。その結果、設計は素早くできるが汚いものになってしまう。
Uncle Bob氏は、プロジェクトが陥る混乱状態も技術的負債だと考えられていることもあるが、それは間違っていると指摘している。氏によれば、
混乱状態は技術的負債ではなく、単なる混乱状態にすぎません。技術的負債を生み出す意思決定は実際のプロジェクトが持つ制約の下で行われます。この意思決定は確かに危険なものですが、利益を生み出す可能性もあります。他方、混乱を生み出す意思決定は決して理性的ではなく、怠惰や職業意識の欠如の下で行われます。将来的に挽回することもできません。混乱とは常に損失なのです。
Uncle Bob氏が指摘するのは、巨大な不動産抵当負債を背負った人にはより強い規律が必要になるように、技術的負債もコードをきれいにすることの必要性を生み出す、ということだ。一度チームが技術的負債を引き受けることが決まれば、可能な限りコードをきれいに保つことがなおさら重要になる。きれいに保たなければ、すぐに状況は悪化し、負債を返済するのはさらに難しくなるだろう。
Martin Fowler氏の見解では、混乱状態もまた技術的負債のひとつであるがその種類は異なっている。氏は、混乱状態とは、いわば無鉄砲な借金で生活苦を拡大するようなものであり、よく考えて良識的にする借金と対比して考えられる、と説明している
Martin Fowler氏は次のような例を示して、技術的負債を四象限に分類している。
- 無鉄砲 - 意図的 – チームには設計をしている時間がない。品質を犠牲にして、汚くても素早くソリューションを提供する必要がある。
- 良識的 - 意図的 – チームは今すぐ製品を出荷しなければならないが、その製品には既知の欠点がある。発送した結果が招く問題についても先手を打っておく。
- 無鉄砲 - 偶発的 – チームは基本的な設計原則について意識していない。なので混乱状態が生まれつつあることにも気付いていない。
- 良識的 - 偶発的 – 確かに優秀な設計者がいて、その設計者はビジネス価値を生み出すソリューションを納品する。しかし、ソリューションが完成した後になって、最良の設計手法が何だったのかを理解する。
このように、プロジェクトが技術的負債を抱え込んでしまうのは避け難いし、ある程度予測しておくべきだろう。 鍵になるのは、チームのメンバが無鉄砲な借金を決してしないようにすることだ。無鉄砲な借金は、不可能ではないにしろ非常に扱いづらい混乱状態を引き起こすのだから。