技術的負債の四象限

2009年10月14日

ここ数ヶ月、技術的負債に関するいくつかの投稿があり、どのような設計上の欠陥が技術的負債に分類されるべきか、あるいは分類されるべきではないかという疑問が提起されました。

良い例として、Uncle Bobの「汚れたコードは負債ではない」という投稿があります。彼の主張は、優れた設計プラクティスを知らない人々によって作成された汚れたコードは、負債とすべきではないということです。技術的負債は、長期的に持続可能ではない設計戦略を採用するという、熟慮された決定を人々が行った場合に限定されるべきです。ただし、リリースを行うなど、短期的な利益をもたらす場合に限ります。重要なのは、負債は早く価値を生み出すが、できるだけ早く返済する必要があるということです。

私の考えでは、設計上の欠陥が負債であるかどうかという問題は、間違った問題です。技術的負債はメタファーなので、真の問題は、負債のメタファーが設計上の問題への対処方法や、その考え方を伝える方法について考えるのに役立つかどうかです。負債のメタファーの特に有益な点は、技術者以外の人々に伝えるのに非常に便利であるということです。

負債のメタファーはどちらの場合にも有効だと思います。違いは負債の性質にあります。汚れたコードは、莫大な利息の支払いや、元本を返済する長い期間をもたらす、無謀な負債です。私たちは、負債の多いコードベースを引き継いだプロジェクトをいくつか経験しており、クライアントの経営陣と、その対処方法について話し合う際に、このメタファーが非常に役立つことがわかりました。

負債のメタファーは、設計上の欠陥に関して私たちが行うことができる選択を思い出させてくれます。リリースに到達するための慎重な負債は、利息の支払いが十分に少ない場合、例えばコードベースのめったに触れられない部分にある場合は、返済する価値がないかもしれません。

したがって、有用な区別は、負債か非負債かではなく、慎重な負債か無謀な負債かです。

私が今概説した例には、もう1つの興味深い違いがあります。慎重な負債と無謀な負債の違いだけでなく、意図的な負債と意図しない負債の違いもあります。慎重な負債の例は意図的なものです。なぜなら、チームは負債を負っていることを知っており、そのため、早期リリースの利益が返済コストよりも大きいかどうかを検討するからです。設計プラクティスを知らないチームは、自分がどれだけの負債を抱えているのかを認識することすらなく、無謀な負債を負っています。

無謀な負債は、意図しないものではないかもしれません。チームは優れた設計プラクティスを知っていて、それを実践できるかもしれませんが、クリーンなコードを書くのに必要な時間をかける余裕がないと考えて、「拙速」に進むことを決定するかもしれません。人々は設計のペイオフラインがどこにあるかを過小評価しているので、これは通常、無謀な負債であるという点で、私はUncle Bobに同意します。優れた設計とクリーンなコードのポイントは、開発速度を上げることです。そうでなければ、Uncle Bob、Kent Beck、Ward Cunninghamのような人々は、それについて話す時間を費やすことはないでしょう。

負債を無謀/慎重、そして意図的/意図しないに分けると、四象限が示唆されますが、私は3つのセルについてのみ説明しました。では、慎重で意図しない負債のようなものはあるのでしょうか？そのようなものは奇妙に聞こえますが、私はそれが存在すると信じています。そして、それは優れた設計者であるチームにとって、よくあることであるだけでなく、避けられないことでもあります。

最近、同僚と彼がちょうど離れたプロジェクトについて話していました。そのプロジェクトは価値のあるソフトウェアを提供し、クライアントは満足し、コードはきれいでした。しかし、彼はコードに満足していませんでした。彼はチームが良い仕事をしたと感じましたが、今では彼らは何が最良の設計アプローチであったべきだったかを理解しています。

私は最高の開発者からいつもこれを聞いています。重要なのは、プログラミングをしている間、あなたは学習しているということです。最良の設計アプローチがどうあるべきだったかを理解するには、プロジェクトで1年間プログラミングする必要がある場合がよくあります。フレッド・ブルックスが提案したように、捨てるシステムを1年間構築して再構築するプロジェクトを計画するべきかもしれませんが、それは売り込むのが難しい計画です。代わりに、あなたが気づくのは、設計がどうあるべきだったかを理解した瞬間に、意図しない負債を抱えていることに気づくということです。これは、Wardが彼のビデオで話した種類の負債です。

利息を支払うか元本を返済するかの決定は依然として適用されるため、メタファーはこの場合にも役立ちます。しかし、この場合に負債のメタファーを使用する際の問題点は、慎重で意図しない金銭的負債との類似点を想像できないことです。結果として、なぜこの負債が発生したのかをマネージャーに説明するのは難しいと思います。私の見解では、この種の負債は避けられないため、予想されるべきです。最高のチームでさえ、プロジェクトが進むにつれて対処すべき負債を抱えることになります。これは、粗末なコードで不必要に過負荷をかけないもう1つの理由です。

2014年11月19日に再投稿