技術的負債は、かなり使える考え方である。 しかし、負債がどれくらいあるかなんて、どうやったら分かるのだろう。 残念ながら金融の負債とは違い、どれだけ技術的負債があるのかは分かりづらい （とはいえ、最近は金融の負債だって分かりにくくなっているようだけど）。

たとえば、こんなのはどうだろう。 チームがある機能を完成させたときに、どれだけ時間がかかったかを聞く（実値）。 それから、もし仮にシステムがきれいだったとしたら、どれだけ時間がかかったかを聞く。 この2つの違いが技術的負債の利息である （たとえば、実際の作業に5日かかって、きれなシステムなら3日だとすれば、2日分の作業を技術的負債の利息として支払ったことになる）。

これにはいくつかの深刻な問題がある。 きれいなシステムならどれくらいかかったかというのは、想像上のシステムの状態に対する見積りを基にしたものだということだ——客観的とは言いがたい。 客観的な情報を得ようとすると、収集がつかなくなることだろう。 しかし、客観的なデータではないにせよ、非技術スタッフの目にも見える形でコードの状態の全体図を表すことができる。

さらに、元本を払うかどうかの判断にも役立つ。 「技術的負債ストーリー」をプロダクトバックログに追加するチームがある——負債を取り除くのにかかる時間を見積っているのだ。 これも見積もりに過ぎないが、どのくらい負債が積み上がっているのかが分かる。 このストーリーに作業を割り当てることで、利息の支払いがうまくできるかもしれない（ダメダメなモジュールがあったから、この機能には作業日を追加した、とかね）。 利息の支払いと元本の支払いを比べれば、どちらに支払えばいいのかが分かるだろう。

最近、このようなことに挑戦し、役に立つと分かったという人に出会った。 しかし、私が考えていたこととはちょっと違っていた。 きっと何か問題があるのだろう——だが、負債が少なければ、試してみる価値はある。

更新

最近行った議論から別の支払利息の計算方法が分かった。ふりかえり（賢いチームはイテレーションの終わりに行っている）のときに、システムの各問題領域に対する支払い利息の見積りを行うというのである。最近完了した作業を見積るほうが、これから実装するストーリーを見積もるよりも簡単だ。