雨漏りを応急処置で済ませる。古くなった配線を見て見ぬふりをする。使いにくい間取りのまま何年も暮らす。それでも家には住み続けられます。けれど、ある日「全面的に直さないと限界」となったとき、早めに直していれば安く済んだはずの費用が何倍にも膨らんでいます。
技術的負債は、短期的な都合でコードや設計を妥協した結果として積み上がる、将来の改修や保守にかかる余分なコストです。借金と同じで、返済を後回しにするほど利息が増えていきます。
「あとで直す」が積み上がると
その場しのぎの実装、同じ処理のコピー、意味の分かりにくい名前。一つひとつは小さな妥協でも、積み重なると、新しい機能を足すたびに「どこを触ればいいか分からない」「ここを変えると別の場所が壊れる」という状態になっていきます。
開発を頼む側から見ると、たとえばこんなやり取りになって現れます。
ご依頼の画面の項目追加ですが、見積もりは1か月になります。
前に似た変更をお願いしたときは、1週間でしたよね？
その後に継ぎ足した部分が絡んでいて、今は触る範囲がかなり広がっているんです。
見積もりが、以前の感覚より急に膨らむ。小さな修正のたびに、関係のない場所で不具合が出る。「あとで直す」と言われたまま何年も放置されている箇所がある。こうした兆候は、負債の利息を払っているサインです。
借りてよい負債と気づかず膨らむ負債
妥協すること自体が悪いわけではありません。リリースを急ぐために設計を簡単にする、人手や時間が足りずにテストや文書を後回しにする。事業の都合として、あえて借りる判断もあります。技術的負債は、悪い開発者がいるから生まれるものではなく、締め切り、人手、情報の制約の中で判断した結果として自然に積み上がるものです。
問題になるのは、借りた自覚がないまま、返す予定も持たずに積み上げることです。古いシステムに新しい機能を継ぎ足し続けて全体の構造がぼろぼろになる、というのが典型です。
ちなみに、意図しない動作そのものである「バグ」とは別物です。技術的負債は、今は動いているけれど、将来の変更を難しくしている設計上の問題を指します。
どこから返すか
負債がゼロのシステムは、ほぼ存在しません。目指すのは、完全になくすことではなく、管理できる量に保つことです。
まず、負債がどこにあるかを把握します。そのうえで、開発の計画に返済の時間をあらかじめ組み込む。動きを変えずにコードの構造を整える「リファクタリング」を、新機能の追加と並行して少しずつ進める。大きな負債の返済では、マイグレーションを伴う構造の見直しが必要になることもあります。
開発チームの側は、負債の大きさを、エンジニアではない人にも説明できるようにしておくと、返済の時間を確保するための理解を得やすくなります。依頼する側は、新機能だけでなく返済の時間も計画に入っているかを確かめてください。