技術的負債を「後で直す」と言い続けて壊れた現場

「今は機能優先。負債は次の四半期で。」——その次の四半期は、だいたい来ない。来ても、さらに大きい機能が乗る。

技術的負債の議論で危ないのは、エンジニアの不満そのものではなく、改修速度が静かに死ぬことだ。経営には「まだ動いている」に見え、現場には「何を触っても怖い」が蓄積する。

本当のコストは、後から払う大きな改修費より、毎週失われる意思決定とリリースの速度だ。

典型失敗

1. 計測がない: リードタイムも障害頻度も見えず、「なんとなく辛い」だけが残る
2. 期限がない: 「いつか」は予定ではない
3. 英雄依存: 特定の人しか触れないモジュールが聖域化する
4. 美化要望の混入: 事業に効かないリライトが「負債解消」と呼ばれる
5. 外注丸投げ: 負債を知らないチームが機能だけ足し、境界がさらに濁る

列挙だけでは足りない。現場では、ある一点で取り返しがつきにくくなる。

深掘り事例：リリース直前に基盤が止まった

匿名化した一例だ。社員50名規模のSaaS。2年間、「認証まわりは後でリファクタ」が口癖だった。機能開発は止まらず、認証モジュールに条件分岐が積み上がった。触れるのは初期メンバー2名だけ。

大型顧客向けの権限追加リリースの3日前、その2名のうち1名が退職。残った1名の休暇中に、権限バグでログイン不能が断続的に発生した。緊急対応に外部を入れ、調査と応急で約6週間。予定していた機能ロードマップは四半期ごと後ろにずれた。

分岐点は、退職の前四半期にある。その時点で「認証に触れる人を3名にする」「変更のたびにテストを自動で残す」のいずれかを投資していれば、英雄依存は解けていた。経営への説明は「リファクタしたい」ではなく、バス係数とリリース止めリスクで伝える必要があった。

「後で直す」は、直す主体と期限がない限り、直さない決定と同じだ。

構造的原因

• 機能リリースは数字になりやすく、負債返済は数字になりにくい
• 意思決定者が「動いている」を安全信号だと誤読する
• 負債の定義が共有されず、好みの書き換えと混ざる

インセンティブを変えずに「意識を高く」しても、同じ四半期が繰り返される。

回避の判断軸

やる	やらない
負債をリードタイム・障害・バス係数で測る	感覚だけで大規模リライトを宣言する
四半期ごとに返済枠（時間または人数）を確保する	「余った時間で」を前提にする
事業KPIに効く負債から潰す	美しさだけの書き換えを優先する
触れる人を増やす投資を先に行う	英雄に負荷を寄せ続ける

次に確認すること

1. 負債と呼んでいるものは、指標に落ちているか
2. 今四半期の返済枠はカレンダーにあるか
3. バス係数1のモジュール一覧はあるか
4. 「後で」の期限とオーナーは名前であるか
5. 大規模刷新を初手にしていないか

まとめ

「後で直す」が続く組織の問題は、怠惰ではない。測らず、期限を置かず、英雄に寄せる構造だ。壊れる前に見えるのは、速度の低下と触れる人の減少である。そこを経営言語に翻訳できるかが、負債と付き合えるかの分岐になる。

---

技術戦略・負債の優先順位づけの相談は、お問い合わせフォーム からどうぞ。