ソフトウェアの負債というのは様々なかたちで存在している。技術的負債は広く知られているし、他の形態としては能力的負債とか品質的負債というものがある。ソフトウェアの負債はプロダクトの維持管理コストを増やし、開発者の気持ちを落ち込ませうるものだ。ソフトウェアの負債を扱うためにはいくつかの解決法がある。
Niklas Björnerstedt氏はブログ記事「技術的負債のその他いろいろ」の中で「能力的負債」に触れている。彼はこう定義する。
自分たちのコードベースにあるものと、そのうち実際に自分たちが理解しているものとのギャップ。
ソフトウェア維持管理の手間を低く保つためには、技術的負債と能力的負債のどちらにも注意を払わなくてはならないと、Niklas氏は説明する。
努力しないでいると技術的負債が時間とともに容赦なく増えるのとまさに同じで、能力的負債もまた時間とともに増えていきます。2種類の負債の大きな違いは、技術的負債の増加が早くなればなるほどコードベースをいじることも増えますが、コードベースをいじるのをやめた途端に能力的負債の増加の速度は増すということです！ それゆえ、活発な開発が終了したあとの落ち着いたシステムにおいては、能力的負債がもっとも深刻な問題となるのです。
Niklas氏は、負債を減らすための2つのテクニックを提案している。それは、ペアプログラミングとコードのリファクタリングだ。
私にとってペアプログラミングの実質的価値は、技術的負債と能力的負債のどちらをも減らすことにあります。ペアになることによって、チームメンバーは熟知するコードベースのエリアを広げ、オーバーラップする部分を増やします。同じように、リファクタリングの価値は、技術的負債を減らすことだけではありません。リファクタリングは能力的負債を減らすための素晴らしい方法でもあります。システムを変更できてはじめて、そのシステムを真に理解できるのです。
能力的負債が発生すると、システムをメンテナンスするにはますます大変なエネルギーが必要になる。そしてついに組織はシステムのリプレースを考え始めるのだ。
人々は旧システムの維持管理は不可能だと主張してききませんでしたが、それがどう動いているのかがわかっていないということが本質的な問題でした。入り組んだコードと自動テストの不足がシステムを理解するときの頭痛の種となり、それゆえ技術的負債が事態をより悪化させていたのです。残された初期開発メンバーがあまりに少なく、習得が可能もしくは習得に前向きな新メンバーを見つけられないとき、書き直したいという衝動が生じるのはよくあることです。
Mike Hustler氏は「もっともアジャイルな技術的負債のマネジメント方法」というブログ記事を書き、プロダクトの機能の開発と技術的負債のやりくりとのバランスの取り方について考察している。彼は、プロダクトを保守チームに引き渡すことが、いかに技術的負債や能力的負債の増加につながるか説明している。
私は組織が保守チーム、たとえば新規開発の半分のサイズで別のチームを作る、というのを見たことがあります。（少なくとも一緒に働くチームのサイズについてだけでも）これは正しくないやり方だと私は思います。（中略）オーナーシップを誇りに最後までやり通す、ということがなくなります。なぜなら、他の人、つまり他のチームが作ったバグに誰か他の人が対応しているからです。密なコミュニケーションがなければ、なぜ最初にそのやり方が採用されたのかという背景の話が失われるのです。ドメイン知識がなければ、問題点を修正するにも効率が悪くなります。さらに悪いことに、経験の浅い開発者からなる保守チームが問題の根本的原因を特定するのに苦労した挙句、むしろ作り替えたほうがいいくらいの応急処置を施して終わり、というのを見たことがあります。
技術的負債は開発者を意気消沈させ、彼らは会社を辞めることを決意する、そしてそれが能力的負債を増大させるのだ、とCory House氏は彼のブログ記事「クリーンコードが重要な7つの理由」の中で説明している。
ずさんだったりわかりにくいコードを書くことは、自分たちのプロジェクトに技術的負債を持ち込むことになります。そして、前後の事情を考慮しながら慎重に検討するようなときには技術的負債は役に立ちますが、その一方、度を超えた技術的負債はやる気を失わさせ、才能を持った人を組織から去らせてしまいます。簡単なことが難しくなったとき、開発者は自分の退席によって反対の意思表示をし、どこか他へ行ってしまいます。開発者は仕事の量よりも質から、より多くの働きがいを得るものです。技術的負債は再利用の機会を減らし、残りのコードベース全体の品質指標を低くしていまいます。
David Hammerslag氏はブログ記事「予測能力が欲しい？ 品質的負債を回避せよ」を書き、コードの中に未解決で発見された欠陥を放置しておくことの影響について考察している。彼の定義する品質的負債とはこれだ。
品質的負債とは、ソフトウェアプロダクトの中にどの時点でも存在する欠陥を修正する手間の尺度です。
彼は品質的負債と技術的負債を比較している。
技術的負債は設計とコードの品質の尺度であって、ソフトウェアの内部品質です。品質的負債とはコードの外部品質の尺度であり、ユーザーが目にし体験するものです。ユーザーは技術的負債を（直接）目にすることは絶対にありません。
プログラムは、品質的負債がひとつもなく、技術的負債が山のようにあるという状態になりえます。要求され期待された機能性をすべて正確に実装することも、完璧に動作することもできるでしょう。しかし技術的負債が膨大になり、あなたが想像しうるあらゆる粗末な設計や実装を示すこともあるのです。その一方で、最良の設計の神々しいまでに洗練されたコードでも、間違った結果を生じたり機能性に欠けることだってありえるのです。
David氏は、品質的負債は無視されるべきではないと説明する。
品質的負債は借金と非常によく似ています。なぜなら、古くなればなるほど返済が難しくなるからです。最悪の場合、開発が終わるまでプロジェクトはテストを先延ばしにします。欠陥は寝かせば寝かすほど直すのが難しくなるということは定説です。仮に多くの欠陥が（既知だろうが未知だろうが）存在し続ければ、欠陥はお互いを隠しあいながら影響は深刻化し、いくつもの修正が同じコードに影響するようになるのです。
David氏は、欠陥をうまく扱い品質的負債を少なく保つために使えるいくつかのアジャイルプラクティスを提案している。
- 完成の定義
- BDD / 受け入れテストの自動化
- 継続的インテグレーション
- 自動テスト
- 割れ窓を放置しない