技術的負債

以前、「Technical Debt」と言うことで、英語のまま引用したのですが、日本語版が出たので再度日本語版から引用します。

リーンソフトウェア開発と組織改革

• 作者: Mary and Tom Poppendieck 著、 依田光江 翻訳、 依田智夫 監訳
• 出版社/メーカー: アスキー・メディアワークス
• 発売日: 2010/10/09
• メディア: 単行本（ソフトカバー）

技術的負債
成功するソフトウェアは変化している。成功するコードは変更を受け入れやすく書かれている。コードの変更をむずかしくするものはすべて技術的負債である。技術的負債は、ソフトウェアの所有コストを容赦なく引き上げ、いずれその精算を迫られたり、システムが破綻したりする。そんなことはすべてわかっている。けれども現実は・・・・

1. 誰が引き継いでも意図が明確に伝わるコードを書こうとせずに、不明瞭なコードがあっても受け入れてしまう。開発者は、特に経験の浅い開発者は、「クリーンなコード」の書き方を訓練されるべきだ。クリーンなコードとは、わかりやすいロジックに基づく、シンプルで素直なコードだ。上級技術者は、不明瞭なコードはたとえテストをパスしたとしても、コードベースに追加させないように気をつけなければならない。
2. リファクタリングに時間を割かない。既存コードになされた変更をすっきりとまとめるリファクタリングは、イテレーティブ（反復的）な開発には欠かすことができない。既存コードに新しいフィーチャーを追加すると、複雑になったり、あいまいになったり、重複が発生したりする。リファクタリングによって、こうした負債を解消できる。
3. システムを展開する直前になって回帰テストを実行する。回帰テストは初めのうちは短時間ですむが、コードが追加されるたびに時間はどんどん長くなる。回帰テストで見つかる穴が増えるにつれて、次のリリースまでの間隔も広がる。リリースのオーバーヘッドが増え続ける悪循環から抜け出すには、回帰赤字（regression deficiti: 回帰テストをするたびに発生する結果（負債））を減らすしかない。コードベースが小さいうちに自動テストハーネスを使用し始め、コードベースへの追加と保守を行っておけば、コードへの変更がその日のうちにコードベースに反映させられるはずである。
4. 技術的負債を生み出す大きな要因は依存性である。それがわかっていながら、膨大な依存性を抱えた古いシステムのリプレースを躊躇する。依存性のなるべく小さいアーキテクチャを開発し、それに移行しなければならない。その方法は以前からよく知られている－情報隠蔽（information hiding）と関心事の分割（separation of concerns）である。
5. 安易にコードをブランチさせる。たとえば、新規開発を切り離すため、個々のアプリケーションに集中するために、フィーチャーセットを並行して開発するため、などの理由を挙げて。コードを2つにブランチ、それぞれが長くなればなるほど、後でマージするのがむずかしくなる。コードをビルドできるまでの日数が余計にかかり、さらに悪いことに、開発が終わるまでシステムのテストを遅らせる。避ける手立てがすでにあるのに、知ろうとしない。ビッグバン方式は時代遅れなのだ。

技術的負債の本当の姿を知らなければならない。負債が破綻に至らないよう、コスト上の重荷をふだんから取り除いておくべきだ。第2章で、技術的フレームを通したソフトウェア開発を取り上げ、技術的負債を避けるための実用性のあるテクニックについて説明する。

技術的負債を積み上げているソフトウェアの開発組織は、仮に新規にシステムを作り直すことを試みても、最初から技術的負債を積み上げてしまう可能性は高いです。なぜならば、ここに書かれている１から5までの問題をそもそも認識していない訳ですから、新規開発でも、再度同じことを行ってしまうことになるからです。

私自身は、過去10年間に、上記負債を最初から積み上げないようにして新たにシステムを作り直したプロジェクトを見たことがある一方で、負債を最初から積み上げてしまった結果、新たなシステムが日の目を見ないうちに終わってしまったプロジェクトも見てきました。