技術的負債

ソフトウェアシステムは、クラスト（システムの修正や拡張を理想よりも困難にする内部品質の欠陥）が蓄積しやすい傾向があります。技術的負債とは、Ward Cunninghamによって造られたメタファーであり、このクラストへの対処方法を、財務負債のように考えるための枠組みを提供します。新しい機能を追加するために必要な追加の労力は、負債に対する利息の支払いに相当します。

私のコードベースに分かりにくいモジュール構造があると想像してみてください。新しい機能を追加する必要があります。モジュール構造が明確であれば、機能の追加には4日間かかりますが、このクラストがあると6日間かかります。2日間の差は、負債の利息です。

この負債のメタファーで私が最も魅力を感じるのは、このクラストへの対処方法を考えるための枠組みを提供してくれることです。モジュール構造をクリーンアップし、クラストを取り除くことに5日間を費やすことができます。これは、借金を返済することに相当します。この1つの機能のためだけにこれを行うと、9日間ではなく6日間かかるため、利益はありません。しかし、今後同様の機能がさらに2つ追加される場合、最初にクラストを取り除く方が最終的には速くなります。

このように述べると、これは単に数字を計算する問題のように聞こえ、スプレッドシートを使えるマネージャーなら誰でも選択肢を理解できるはずです。残念ながら、私たちは生産性を測定できないため、これらのコストは客観的に測定できません。機能の実装にかかる時間、クラストが除去された場合の状況、クラストの除去にかかるコストを推定することはできます。しかし、このような推定の精度はかなり低いです。

これを考えると、通常は財務負債の場合と同様に、元本を徐々に返済するのが最善の方法です。最初の機能では、クラストの一部を取り除くために2、3日余分に時間を費やします。これだけで、将来の機能拡張の金利を1日にまで削減できるかもしれません。それでも余分な時間はかかりますが、クラストを取り除くことで、このコードの将来の変更をより安価にしています。このような段階的な改善の大きな利点は、頻繁に変更するコードベースの領域、つまりクラストの除去が最も必要な領域に、より多くの時間を費やすことになるということです。

これを利息の支払い対元本の返済と考えると、どのクラストに取り組むべきかを判断するのに役立ちます。変更するのが悪夢のような、ひどいコードベースの領域がある場合、変更する必要がなければ問題ありません。ソフトウェアのその部分で作業する必要がある場合にのみ、利息の支払いが発生します（これは、財務上の利息の支払いは時間の経過によって発生するため、メタファーが当てはまらないところです）。そのため、クラストが多いが安定したコード領域はそのままにしておくことができます。一方、アクティビティの高い領域では、クラストに対してゼロトレランスの姿勢をとる必要があります。これは、利息の支払いが非常に高額になるためです。これは特に、開発者が内部品質に注意を払わずに変更を行うと、クラストが蓄積されるため重要です。変更が多いほど、クラストが蓄積されるリスクが高くなります。

負債のメタファーは、内部品質の軽視を正当化するために使用されることがあります。緊急に必要な新機能がある場合、負債を受け入れ、将来この負債を管理しなければならないことを受け入れる方が最善かもしれません、という議論です。

ここでの危険性は、ほとんどの場合、この分析が適切に行われていないことです。クラストはすぐに影響を及ぼし、すぐに必要となるまさにその新機能の開発を遅らせます。これを行うチームは、すべてのクレジットカードを使い果たしてしまい、それでも内部品質を高めるために努力した場合よりも遅れてしまいます。ここでは、このメタファーはしばしば人々を誤解に導きます。なぜなら、そのダイナミクスは財務ローンのダイナミクスとは実際には一致しないからです。デザインスタミナ仮説の設計ペイオフラインを下回っている場合にのみ、納期を早めるために負債を引き受けることは有効ですが、チームは何ヶ月もかけるのではなく、数週間でそのラインに到達してしまいます。

さまざまな種類のクラストを負債と見なすべきかどうかについては、定期的に議論が行われています。私は、負債が意図的に発生したものかどうか、そしてそれが慎重なものか無謀なものかを考えることが有用だと感じました。それが技術的負債クアドラントにつながりました。