技術負債（Technical debt）

技術負債（Technical debt）

技術負債：開発過程で即時的な要求事項を満たすために目の前のプロジェクトをより早く完了できる近道を選ぶことで、後に支払わなければならない代価

会計上の負債（debt）を負って金を借りれば、すぐに必要な場所に迅速に投資できますが、財務的な圧迫を受け、元金に利子をつけて支払わなければならないように、目の前の要求事項を解決するために多少汚くても迅速に開発を進めると、コードが複雑になり重複しながら、後に新しい機能を実装したり拡張したりする際に困難が生じます。

企業が負債を通じてより多くの投資を適時に執行し、新製品を開発して市場シェアを高めたり、個人がローンを通じて家を契約したりするように、技術負債を負って新しい機能を迅速に実装することが無条件に悪いわけではありません。ただし、技術負債が蓄積されるのを減らし、管理可能なレベルで管理することが望ましいです。

技術負債が発生する理由

開発者の能力が十分であっても、ソフトウェアを制作する過程で技術負債は必然的に発生し、根本的に防ぐことは不可能です。 サービスが発展する過程で既存に設計したコードでは限界に直面すると、元々は読みやすく上手く動作していたコードであっても、既存の設計を修正しなければならない場合があります。 また、技術自体が発展するにつれて、以前は主流だったライブラリ/フレームワークをあまり使用しなくなると、技術スタックを他のライブラリ/フレームワークに変更することを決心する場合があり、この場合も既存に作成したコードが一種の技術負債となります。

その他にも、次のような理由で技術負債が発生する可能性があります。

• プロジェクトを進めながら設計したものをタイムリーに文書化しないため、他の人や時間が経った後で自分自身が再びそのコードを見たときに解釈に困難を感じる場合
• もはや使用しない変数やDBの項目を削除しない場合
• 繰り返し作業（デプロイ/ビルドなど）を自動化しないため、毎回追加の時間と労力がかかる場合
• 緊急な仕様変更

技術負債を最小限に抑える方法

開発者間のルール（Convention）設定

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

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

• 既存のコードが汚くて開発の妨げになる場合、コード構造をきれいに変更するリファクタリングを通じて技術負債を清算できる
• 当然、既存のコードが汚いスパゲッティコードであるほどリファクタリングの難易度は高くなる
• できる限り最初から読みやすく保守が容易なコードを書こうと努力すべき