技術的負債（Technical debt）

技術的負債

技術的負債（Technical debt）
開発過程で差し迫った要件を満たすため、目の前のプロジェクトを素早く終わらせる近道を取ることで、後で支払うことになる対価

会計上の負債（debt）を負って資金を借りれば、当面必要なところに素早く投資できる一方で、財務的な圧迫を受け、元本に利息を付けて返済しなければならないのと同様に、目先の要件を片付けるために多少雑でも素早く開発を進めると、コードは複雑化・重複化し、後々新機能の実装や拡張が難しくなる。

企業が負債を活用して適時に投資を増やし新製品を開発して市場シェアを伸ばしたり、個人がローンで住宅を購入したりするのと同様に、技術的負債を受け入れて新機能を素早く実装すること自体が必ずしも悪いわけではない。重要なのは、技術的負債の積み上がりを抑え、許容可能な水準で管理することだ。

技術的負債が発生する理由

開発者の能力が十分であっても、開発過程で技術的負債は必然的に生じ、根絶することは不可能だ。 サービスが成長する過程で、従来の設計では限界に突き当たると、当初は可読性も高く正常に動いていたコードであっても、設計の見直しが必要になることがある。 また、技術そのものの進歩により、かつて主流だったライブラリ／フレームワークを使わなくなり、技術スタックを別のライブラリ／フレームワークへ乗り換える決断をすることもある。その場合も、既存コードは一種の技術的負債となる。

このほかにも次のような理由で技術的負債が発生しうる。

• プロジェクト進行中に設計内容を適時ドキュメント化せず、他者や、時間が経って自分自身が読み返したときに解釈に苦しむ場合
• もはや使われていない変数やDB項目を削除しない場合
• 反復作業（デプロイ／ビルド等）を自動化せず、毎回余計な時間と労力がかかる場合
• 緊急の仕様変更

技術的負債を最小化する方法

開発者間の規約（Convention）の設定

• 単独開発でない場合、円滑な協業のために、使用言語や技術スタック、プロジェクトのディレクトリ構成、開発スタイル等について合意が必要
• どこまで方式を統一し、どこからを個人の裁量に委ねるかを決めておく
• コードレビューを通じて互いの開発スタイルを把握し、意見交換することが必要

クリーンコード（Clean Code）の作成＆リファクタリング（Refactoring）

• 既存コードが散らかって開発の妨げになっているなら、コード構造を整えるリファクタリングによって技術的負債を清算できる
• 当然ながら、既存コードが汚いスパゲッティコードであるほどリファクタリングの難易度は上がり、極端な場合はリファクタリングを断念して既存コードを廃棄し、最初から作り直すこともある
• 可能な限り、当初から可読性が高く保守しやすいコードを書くよう努めるべき