技術的負債の管理 ― 「今直すもの」と「許容するもの」

📖この章のキーワード

用語	意味	なぜ重要か
技術的負債	短期判断で生まれた将来の修正コスト	借金と同じ。返済計画が重要
トリアージ	優先順位をつけて限られたリソースで対応する手法	全部直すのではなく分類して判断
リグレッション	修正により既存の正常動作が壊れること	大規模修正の隠れたコスト
返済計画	負債をいつ、どの順序で解消するかの計画	計画なき負債が真の問題

負債は悪ではない

技術的負債は「借金」です。借金は悪ではありません。返済計画なしの借金が悪 です。

この教材で見てきた LIBOT のコードにも負債があります。

負債	件数	状態
`DB::raw`	約 212 箇所	段階的に移行中
`v-html`	約 104 箇所	リスク分類して対応中
署名比較の `==`	一部箇所	`hash_equals()` への移行対象

「全部直す」が間違いである理由

コスト: 212 箇所を直すのに数週間。その間、新機能開発は止まる
リスク: 動いているコードを変えること自体がリグレッションリスク
優先度: 全てが同じ危険度ではない

正しいアプローチ: トリアージ

Step 1: 分類

優先度	基準	対応
P0	ユーザー入力が関わるセキュリティ問題	即座に修正
P1	運用に影響する品質問題	次スプリントで対応
P2	改善すべきだが緊急ではない	バックログに積む
P3	ベストプラクティス違反だが影響が小さい	時間があれば

Step 2: ルール化

新規コード: DB::raw 禁止。Eloquent / Query Builder 必須
既存コード: P0 から段階的に移行。触ったファイルは改善する

Step 3: 計測

指標	計測方法	目標
P0 件数	月次スキャン	ゼロ
全体件数	月次スキャン	減少傾向
新規追加	PR レビュー	ゼロ

この教材で身につけたこと

Part 0-10 を通じて、あなたは以下の力を訓練しました。

力	Part
リクエストを疑う	Part 1
データを守る	Part 2
複雑さを管理する	Part 3
非同期で障害に耐える	Part 4
イベントで疎結合にする	Part 5
外部依存と付き合う	Part 6
キャッシュで速くする	Part 7
セキュリティを判断する	Part 8
壊れる前提で設計する	Part 9
AI コードをレビューする	Part 10

AI が 30 秒でコードを生成する時代に、あなたは「これを本番に入れるか？」に自信を持って答える力を手に入れました。

それがサンドイッチ・ワークフローの「下のパン」― 判断する力です。