技術的負債とは

技術的負債とは

技術的負債はソフトウェアの内部の作りに不備が残り、機能の追加や修正で本来より多くの手間を要する状態を借金になぞらえた言葉です。後回しにした手直しが元本にあたり、手直しを済ませるまで変更のたびに余分にかかる手間が利子にあたります。

増築を重ねて図面と実物が合わなくなった建物に近いです。住むぶんには困りませんが、壁を1枚動かすたびに配管や配線の調査から始めます。

利用者に表示される画面や機能が正常に動作していても、負債は蓄積します。事業側は開発の遅れや不具合の増加として表れて初めて気づきます。

借金にたとえる理由

把握しにくい手直しの費用を、元本と利子という事業側と同じ尺度で話すためのたとえです。早めに作りを改修して返済すれば開発は速くなります。返済せずに放置すると利子がかさみ、開発全体が身動きを取れなくなります。理解が深まるたびに作りを改修していく前提の言葉で、雑なコードを記述してよいという意味ではありません。作りを改善する作業はリファクタリングと呼びます。

利子は手を入れる箇所でしか発生しません。変更の多い箇所の負債ほど高くつき、触らない箇所の負債は放っておいても損が出にくいです。この性質はお金の借金と違うため、手直しする箇所は変更の多さで選定します。

負債ができる経緯

負債は意図して負ったかどうかと、慎重だったか無謀だったかの2軸で4つに分類できます。組み合わせごとの場面と扱いは次のとおりです。

意図	慎重さ	よくある場面	事業側の扱い
意図した	慎重	発売日に間に合わせるため手直しを後に回し、返済の時期も定めておく	事業判断として正当になりうる
意図した	無謀	時間がないことを理由に設計を考えずに開発する	多くの場合すぐに開発が遅くなり、得られる時間より失う時間が大きい
意図していない	無謀	設計の知識がないまま開発し、負債だと認識していない	開発体制そのものの問題と位置づける
意図していない	慎重	開発して運用した後で、本来あるべき作りが分かる	優れたチームでも避けられない

意図して負う利点

• 市場に早く投入し、売れるかどうかを先に確認できる
• 作り込みの一部を後に回して、定められた納期を守れる
• 要件が確定する前の作り込みを抑え、後で破棄する部分への費用を回避できる

コストとリスク

負債を放置したときの損失

• 同じ規模の機能追加にかかる期間が延び、見積もりも外れやすくなる
• ある箇所の修正が別の箇所に不具合を生み、リリース後の不具合や障害が増加する
• 特定の担当者しか触れない箇所が増加し、退職や担当交代で保守が停滞する
• 古いライブラリや基盤の更新を先送りすると、セキュリティの修正を適用できなくなる
• 新しく加わった開発者や引き継いだ開発会社が全体を把握するまでの期間が延びる
• 開発者の時間の多くが回避策に取られる。Stripeが2018年に公表した開発者調査の報告書では、回答者は開発者の週41.1時間の労働のうち平均13.5時間を技術的負債への対処に費やしていると見積もった。数値は回答者の見積もりで、調査は生成AIの普及前に実施された
• 開発を外注していると返済の工数は保守費や改修の見積もりに紛れ、発注側は改修のたびに見積もりが膨らむ形でしか把握できない

負債の返済にかかる費用

• 自動テストのない箇所の手直しは、それ自体が新しい不具合を生みやすい
• 返済している間は新機能の開発が遅れ、その期間の機会損失が生じる

よくある誤解

技術的負債はエンジニアの手抜きの結果

手抜きで生まれる負債もありますが、すべてではありません。発売を優先して意図的に負う負債もあれば、開発して運用した後で初めて分かる負債もあります。負債の有無で開発者を評価せず、どう負ってどう返済しているかを重視します。

生成AIでコードを作成すれば負債は溜まりにくい

コードを記述する速度は向上します。一方で、生成されたコードを十分に確認しないまま取り込む開発者が増え、負債は蓄積しやすくなります。GitClearが2020〜2024年の約2億行の変更を分析した調査は、生成AIの利用が広がった時期の変化を示しています。既存のコードを複製した行の割合は2021年の8.3%から2024年の12.3%に増加し、既存のコードを整理し直した行は25%から10%未満に減少しました。同じ処理が複数の箇所にあると、変更のたびに修正する箇所も増えます。生成AIを活用する開発でも、返済の時間は別に確保します。

再構築すれば負債はなくなる

再構築した直後は負債が減少します。それでも事業に合わせてシステムを変更し続ける限り、新しい負債は蓄積していきます。継続的に少しずつ返済する仕組みがないまま再構築すると、数年後に同じ状態へ回帰します。