概要
たまには、具体的な実装や運用の話ではなく、理論の話を書いてみようと思います。（ポエムかもしれない）
技術的負債とよく言いますが、そのままだと曖昧なので実害まで掘り下げると意外に効果があるよという話です。
最初に結論まとめ
- 技術的負債かどうかの議論では、次のような実害が出るかどうかまで掘り下げるというアプローチが有効だと思う
- 期待通りに動かないバグが出たときに、原因が追いづらいこと
- 想定外の場所に影響が出るリグレッションを検出しづらいこと
- これをプログラマが「コードが汚い」と表現してしまうと、ビジネス側へは必要性がちゃんと伝わらない。簡単な言葉に逃げずに、何が起きるのかを言語化しよう
- 言語化してみると、コードを直す以外の選択肢も見つかるかも？
説明
少し前に「技術的負債に向き合うConference 2026」というイベントがあり、久々にその単語について考えてみました。
技術的負債という用語は、ビジネスや開発規模によってかなり意味合いが違ってくると思います。
プログラマからよく聞くのは「コードが汚くて変更の手間が掛かる」「コードがちゃんと分割されていなくて見通しが悪い」
ので
「リファクタリングしたい！」
ですが、これだと実害がよく分かりません。それは本当に負債なのか？返す必要があるのか？という議論も抽象的になりがちです。
掘り下げて言語化してみよう
ここをもう少し掘り下げてみて、次のような実害が出るかまで言語化してみるのがお勧めです。
- 期待通りに動かないバグが出たときに、原因が追いづらいこと
- 変更時に、想定外の場所に影響が出るリグレッションを検出しづらいこと
これが実害ということは、コードだけの問題とは限りません。ドキュメントやテストの整備などが不足している場合もこれは起きます。そうした広い要素が関わるのが技術的負債の実態だと考えています。ということは、対策もリファクタリングだけとは限りません。
多分、言っているプログラマ自身はそれを分かっています。文字通りの意味ではなく、上記のような実害が起きる匂いを感じ取っていると思います。それを、もう少し突き詰めて言語化してみましょう！
実際に有った例
例えば以前に、コードが全体に分散していて、どの処理も機能の実現に責任を持っていないというコードがありました。これはまさに「コードが汚い」のでリファクタリングで解決したくなります。
しかし今の実害が何かを掘り下げてみると、最大のものは「エラー発生時に、発生箇所やエラー情報を特定できなくて困る」でした。これならば、主要な入り口と出口にログを追加するという選択肢も出てきます。それはそれで手間がかかりますが、リグレッションのリスクはだいぶ低いので、比較する価値はある案です。
また、その表現であればビジネス側の人にもどういう問題が有るのかを理解してもらいやすかったと思います。
まとめ
まとめると、「技術的負債」とか「コードが汚い」という言葉に安易に逃げず、もっと掘り下げた言語化をしてみるのがお勧めです。それにより、意外とコードを直す以外の選択肢が見つかったりしますし、ビジネス側との齟齬も起きづらくなります。