http://martinfowler.com/bliki/TechnicalDebtQuadrant.html

ここ数ヶ月の間に、 技術的負債 に関する投稿がいくつかあった。設計上の不備の中で、技術的負債と呼ぶべきものは何か？ 逆に、そう呼ぶべきでないものは何か？といった疑問が挙げられていた。

その一例が、アンクル・ボブの投稿「a mess is not a debt（散乱は負債ではない）」だ。 彼の意見は、次のようなものである。 良い設計方法を知らない人が書いた単に汚いだけのコードを負債と呼ぶべきではない。 長期的な持続性はなくても、 リリースなどの短期的な利益を生み出す設計指針をあえて選択することがあるが、 技術的負債はそのような特別な場合に使うべきである。 要するに、負債を抱えれば早めに価値を生み出すことができるが、 負債はできるだけ早く返済する必要がある。

だが私は、 設計の不備が負債かそうじゃないかなんて考えることが、そもそも間違ってると思う。 技術的負債というのはメタファなのだから、 ここで問うべきなのは「負債のメタファは、 設計上の問題を考える助けになるだろうか？ そして、他人と意見交換しやすくなるだろうか？」だ。 負債のメタファを使う大きなメリットは、 技術者以外にも話が通じやすくなることだろう。

設計上の不備も、検討の末の判断も、 どちらも負債のメタファがうまく当てはまると思う。 ただ、負債の性質が違うというだけのことだ。 きたないコードは無鉄砲な（reckless）負債だ。 結果として利子の支払いが不能になったり、 いくら払っても元金が減らなかったりすることになる。 私たちのプロジェクトの中にも、 コードベースが負債まみれになっているものがいくつかある。 その対策についてクライアントの担当者と話し合うときに、 このメタファはとても便利だ。

負債のメタファを聞いて思い出すのが、 設計上の不備に対して私たちがとれる選択肢のことだ。 慎重に（prudent）考えた結果として負債を抱えたリリースをした場合、 支払う利子が無視できるほど小さいならば、その返済はしなくてもかまわないだろう。 たとえば、めったに使われることのない部分などがこれにあたる。

つまり、負債かそうじゃないかという区別はあまり意味がなく、 慎重に考えた上での負債なのか、無鉄砲な負債なのかのほうが大事だ。

今あげた例について、もうひとつ別の切り口で区別することもできる。 無鉄砲な負債（reckless）か慎重な負債（prudent）かという違いのほかに、 意図的な負債（deliberate）なのか不注意な負債（inadvertent）なのかという区別があるのだ。 慎重な負債の例は、この区別では意図的な負債にあたる。 チームはそれが負債であることを認識しており、早めにリリースすることで 十分元が取れるという判断をしたわけだ。 設計について無関心なチームは、無意識のうちに負債を抱えてしまうことがある。 いったいどれだけのものを質入れしているのかを認識することもない。

無鉄砲な負債は、必ずしも不注意なものばかりというわけではない。 設計の重要性をきちんと理解していて実践できるチームでも、あえて 「間に合わせの適当な」設計を選ぶこともある。 たとえば、クリーンなコードを書くだけの余裕がないと判断した場合などがそうだ。 このような場合は、ほとんど無鉄砲な負債になるということについては、私もアンクル・ボブに同意する。 人はみな、設計損益ラインを過小評価するものだからだ。 よい設計とクリーンなコードの本質は、開発をすばやく進められるようにすることだ。 そうでもなければ、アンクル・ボブやケント・ベックそしてウォード・カニンガムといった面々が、わざわざ時間をかけて議論することもないだろう。

「無鉄砲／慎重」と「意図的／不注意」の2つの基準を使うと、 負債を四象限に分類できることになる。 ここまでで議論したのは、その中の3つの部分だ。 残りの1つ、つまり「慎重かつ不注意な」負債については何が言えるだろう？ ちょっと奇妙な感じもするが、私はこれもアリだと思う。 普通にあり得る話というだけではなく、よくできる設計者が集ったチームでは避けられない事態だ。

私の同僚と、彼が最近リリースしたプロジェクトのことについて話をした。 彼が言うには、そのプロジェクトは価値のあるソフトウェアを提供できたし、 顧客も喜んでくれたし、そしてコードもクリーンだった。 でも、なぜか彼はそのコードに満足していなかった。 自分のチームがいい仕事をしてくれたというのはわかっている。 でも、今になって「あそこはこうしておくべきだった」ということがわかってきたというのだ。

デキる開発者たちは、いつもこんなことを言っている。 要するに、プログラミングをしているときには、同時に学んでもいるということだ。 何かのプロジェクトに参加して1年ほどプログラミングをし続けて、 ようやくその課題に対する最善のアプローチを理解したりするってことも珍しくない。 おそらく、最初からそれを見越した計画を立てるべきなんだろう。 最初の1年で組み立てたシステムをいったん破棄して最初から作り直すということだ。 かつてフレッド・ブルックスもそんな提案をしていた。 だが、なかなかそんなことも言っていられない。 本来そうすべきだった設計を発見した時点で、 あなたは不注意な負債を抱えたことを自覚することになる。 これはある意味、ウォードがこの映像で話している負債みたいなものだ。

利子を払うことを選ぶか元本を返済することを選ぶかという判断がここでもあてはまる。 今回の場合も、このメタファが使えるだろう。 だが、このメタファにも問題はある。 というのは、 「慎重かつ不注意な」型の負債というのは、 実際の財務では想像できないからだ。 なので、なぜこんな負債が発生することになったのかを上司に説明しづらくなる。 個人的には、この手の負債は避けられないものなのだから、あらかじめ想定しておくべきだと考える。 どんなにすばらしいチームだって、 プロジェクトが進むにつれて負債を抱えることになる。 そうしないで無茶をすれば、質の悪いコードに押しつぶされてしまうからだ。

  • Reckless(無鉄砲な) / Prudent(慎重な)
  • Deliberate(意図的な) / Inadvertent(不注意な)

技術的負債の四象限

  • reckless-deliberate 「設計する時間がないんだからしょうがない」
  • prudent-deliberate 「今すぐリリースしないといけない。あとでどうにかしよう」
  • reckless-inadvertent 「レイヤー化？なにそれ？」
  • prudent-inadvertent 「もっとこうすべきだったなあ」

first translated by m-takagi