「後で直す」は来ない
プロジェクトには必ず、こんなコードが存在します。
// TODO: あとでちゃんと実装する
const result = data.filter(x => x.status === 1 && x.type !== 3 && !x.deleted);最初はちょっとした妥協だったはずです。しかし半年後、誰もそのコードの意図が分からなくなっています。変更するのが怖いので誰も触らない。機能追加のたびに似たような条件分岐が増えていく——これが技術的負債の典型的なパターンです。
「後で直す時間を作れるはずだった」という思い込みが、多くのチームを苦しめています。
技術的負債とは何か
「技術的負債」という言葉は広義に使われますが、本来の定義は明確です。
ウォード・カニンガム（Wikiの発明者）が提唱したこの概念は、**「今の問題を解決するために、将来の変更コストを借金している状態」**を指します。
技術的負債には2種類あります。
| 種類 | 性質 | 例 |
|---|---|---|
| 意図的な負債 | 意識的な選択。後で返済するつもり | MVP優先でテストを省く |
| 非意図的な負債 | 知識不足・判断ミスによる偶発的な蓄積 | 設計原則を知らずに書いたコード |
問題になりやすいのは後者です。非意図的な負債は「そもそも負債だと気づかれていない」ケースが多い。
なぜ放置されるのか
技術的負債の厄介さは、返済しても機能上の変化が見えにくい点にあります。
ユーザには何も変わらない。画面の動きも同じ。しかし内部コードは大きく改善されている——このような変更は、ビジネス側から価値が見えません。
結果として次のサイクルに陥ります。
- 機能追加の優先度が常に高い
- リファクタリングの時間が取れない
- コードがさらに複雑になる
- 機能追加がさらに遅くなる
この悪循環を断ち切るには、リファクタリングを「別の作業」として切り出さず、日常の開発フローに組み込むことが重要です。
リファクタリングをチームで進める3ステップ
Step 1：見える化する
改善したい箇所を「感覚」ではなく「事実」として共有します。
有効な指標の例：
- 循環的複雑度：条件分岐の多さ（10以上は要注意）
- 変更頻度とバグ率の相関：よく壊れるファイルは設計に問題がある可能性が高い
- テストカバレッジ：低い箇所は変更リスクが高い
これらを可視化するだけで、「なんとなく怖い」という感覚が「具体的に何が問題か」に変わります。
Step 2：粒度を小さくする
「大規模リファクタリング」は高リスクです。代わりに**Boy Scout Rule（ボーイスカウトルール）**を適用します。
コードを触ったら、触る前より少しだけきれいにして去る
PR の中に、本来の変更と合わせて小さな改善を含める習慣です。命名を直す、メソッドを分割する、不要なコメントを削除する——こうした小さな改善の積み重ねが、大きな変化をもたらします。
Step 3：テストで安全網を作る
リファクタリングを安全に行うには、変更前後で動作が変わらないことを確認できるテストが必要です。
既存コードにテストがない場合は、リファクタリングの前にテストを書くことを優先します。「特性テスト（Characterization Test）」と呼ばれるアプローチが有効です——まず現状の振る舞いを記録するテストを書き、それを守りながら内部を改善します。
安全にリファクタリングを進める原則
コードを改善する際は、以下の順番を守ってください。
1. 外部から見た振る舞いを変えない
リファクタリングとバグ修正、機能追加は別のコミットにします。混在すると、問題が起きたときに原因の切り分けができません。
2. 小さいステップで進める
「一気に書き直す」は禁物です。意味のある最小単位で変更し、テストを通してから次に進みます。
3. レビューを省略しない
「リファクタリングだから動作は変わらないはず」という油断が、障害の原因になります。変更はすべてレビューを通す習慣を守ります。
経営層・PMへの説明の仕方
技術的負債の返済に時間を確保するには、技術者でない人を動かす必要があります。
「コードをきれいにしたい」という説明は機能しません。次のような言い換えが有効です。
| 技術的な表現 | ビジネスの言葉 |
|---|---|
| 循環的複雑度が高い | 仕様変更のたびに予期しないバグが出る状態 |
| テストカバレッジが低い | 変更のたびに手動確認コストが発生している |
| 密結合な設計 | 機能Aを修正すると機能Bが壊れる危険がある |
具体的な過去の障害事例と結びつけると、より説得力が増します。「先月の障害は、このコードが複雑になりすぎていたことが根本原因でした」という形です。
まとめ
技術的負債は「放置すれば消える問題」ではありません。むしろ放置するほど返済コストが高くなります。
重要なのは以下の3点です。
- 定量化して見える化する——感覚の議論をやめる
- 小さく継続的に改善する——大規模リファクタリングより日常的な改善を優先する
- ビジネス言語で伝える——時間を確保するために、経営層・PMを動かす
コードは資産です。丁寧にメンテナンスされたコードベースは、チームの生産性を長期的に支えます。「直したいのに直せない」という状況を変えるのは、技術力よりもチームの文化と習慣です。