プログラマが知るべき97のこと/分別のある行動
何をするにせよ、常に分別を忘れてはならない。自分のしたことがどういう結果を生むか、よく考えるのだ。
—作者不明
どんなに余裕あるように見えたスケジュールでも、実際に作業を始めれば、必ずどこかで追い詰められた状態になるものです。そして、同じことを「正しくやる方法」と「手早くやる方法」があれば、後者の方が魅力的に見えてしまうことはよくあります。後者を選べば、後で修正が必要になるとわかっていても、その時は「必ず、すぐに修正しよう」と自分に誓うでしょう。プロジェクトチームのメンバーや、顧客などに修正を約束することもあります。約束した時点ではもちろん、絶対に約束を守るつもりでいます。次のイテレーションなどが修正のチャンスなのですが、実際にイテレーションが始まると、また新たな問題が起きてそちらに注力してしまい、結局、修正が不可能になってしまうことも多いのです。このように先送りされていく修正作業のことを技術的負債(Technical debt)[1]などと呼ぶことがあります。当然、好ましいものではありません。Martin Fowlerは特に、いま述べたような技術的負債のことを故意の技術的負債と呼んでおり[2]、故意でない、不注意から発生する技術的負債とは区別すべきであると言っています。
技術的負債は、その名のとおり、借金のようなものです。短期的には利益になりますが、完済するまで利息を払い続けなくてはなりません。早くできるからと手を抜いてコードを書くと、機能追加やコードのリファクタリングが難しくなります。新たな不具合を生む温床となり、テストケースの価値を損なう原因にもなります。長く放置するほど害は大きくなるでしょう。ようやく元々の問題を解決したら、その問題が原因で生まれた新たな問題が山積みになっていた、ということになりかねません。問題が放置されていたために、正しい設計の選択ができないこともあります。リファクタリングや修正の難しいコードを仕方なく次々に書いてしまうこともあるでしょう。実のところ､事態が極端に悪化してしまい、もう他にどうすることもできない状況に陥ってはじめて、元々の問題の修正に取り組み始める、そんなことが多いのです。その頃には、修正は極めて難しくなっています。修正しようにも膨大な時間がかかるため、あるいはリスクが高すぎるため、手の打ちようがないこともよくあります。
納期に間に合わせるため、ほんの少しの機能追加のため、どうしても技術的負債が生じてしまう、ということがあります。そうならないように努力はしなくてはいけないのですが、状況によって、どうしてもそうせざるを得ないことがあります。その場合は、あえて技術的負債を抱える道をとる以外ないでしょう。しかし（ここからが何より大事です)、技術的負債の存在は常に忘れないようにし、できるだけ早く返済すべきです。さもなければ事態は急速に悪化していきます。やむなく妥協をする決断を下した時は、すぐにタスクカードに書く、問題管理システムへの登録をする、などの対処をし、技術的負債の存在が忘れられないようにしておくべきでしょう。
次のイテレーションでの返済をスケジュールに組み込むことができれば、コストは最小限に抑えられます。負債を放置すれば､利息が発生します。この利息を常にトラッキングし、コストを明確にする必要があります。そうすれば、技術的負債が事業価値にどれほど大きな影響を及ぼすかが意識され、返済のための作業の優先順位が自然に上がることになるはずです。利息の計算、トラッキングをどうするかは、プロジェクトごとに違うでしょうが、トラッキングをしなくてはならない、ということだけは、どのプロジェクトでも同じです。
技術的負債はできるだけ早く返済する。分別のある人ならそうするはずです。