技術上の借金は返済せよ

本番の、つまり使っている顧客がいるプロジェクトには、バグフィックスであれ、新機能の追加であれ、かならずシステム変更をしなければならないときが来ます。そのときに選べる方向は2つあります。「正しく処理する」ために必要な時間を確保するか、「ショートカット」してすぐに変更を稼働に回すかです。

一般に、ビジネスピープル(セールス/マーケティングや顧客)は、できる限り早く変更を済ませることを望みますが、デベロッパーやテスターは、変更点を正しく設計、実装、テストするだけの時間を確保してから顧客に送り届けることを望みます。

あなたは、プロジェクトのアーキテクトとして、どちらが合理的かを判断し、決定権を持つ人々にあなたのアドバイスがもっともなものだと思わせなければなりません。そして、アーキテクチャー上の問題の常として、判断にはトレードオフがあります。システムが十分安定していると判断するなら、「クイック・アンド・ダーティ」ルートで変更を早く本番に適用しでもよいかもしれません。しかし、こうする場合には、プロジェクトは「技術的な借金」を負うことになり、後でかならずその返済を迫られることになるということを覚えておかなければなりません。この場合、返済とは、変更前の状態に戻り、最初にやろうとして時間と資源がなくてできなかった正しい方法をやるということです。

さて、正しい変更をするのが今なのか後なのかという問題になってしまうのはなぜでしょうか。実は、クイック・アンド・ダーティなフィックスには見えないコストがあるのです。お金の方の借金では、「利息」という見えないコストがあります。クレジットカードを持ってる人なら、借金に払う利息がいかに高くつくかよくご存じでしょう。技術の方の借金では、利息に当たるのはシステムが不安定になること、それから適切な設計、ドキュメント、テストがないハック的な変更のために余分にかかるメンテナンスコストです。そして、借金の場合と同じように、完済するまでは元金の返済もあるのです。

技術的な借金の本当のコストについて少し理解すると、代償が高すぎてとてもそんなコストを払う余裕はないと思うかもしれません。しかし、デベロッパーたちにできる限り早くフィックスをしてもらうか、深刻な損失を覚悟するかの選択を迫られた場合は、一般に素早いフィックスを選んだ方がよいでしょう。そこで、できる限り早く本番に修正を加えるわけですが、そこで終わってしまってはなりません。

修正が本番に適用されたら、変更前の状態に戻り、そこから正しい方向に向かつてデベロッパーに修正をしてもらい、次の定期リリースにその修正を組み込むようにしましょう。これは、クレジットカードで何かを買って借金を作っても、月末に入金すれば利息を支払わなくて済むのと同じです。こうすれば、ビジネスが必要とするスピーディな変更を提供できるとともに、プロジェクトを借金地獄に追い込まなくて済むようになります。