既存 warning を抱えたまま進む時の安全運転

なぜ書いたか

レガシー移行の現場では、既存のwarningが数十〜数百件あるのが普通です。「全部直してから進める」だと永遠に着手できません。今回は、warningと付き合いながら新規悪化を防ぐ運用にした話です。

やったこと

3つだけです。

1. 基準線（baseline）を測る: 移行開始時点のwarning件数とリストを記録する
2. 新規warningを許さない: 各スライスのbuildログを基準線と比較し、増えていたら追加されたwarningを直してから次に進む
3. 既存warningは別タスクで管理: 「既存warning撲滅」を独立したスライスとして切り、業務スライスに混ぜない

警告ゼロを目指すのではなく、警告予算（warning budget） という考え方に切り替えました。

なぜこれが効くか

• 既存warningは触ると依存関係に飛び火することが多い。業務スライスと混ぜるとレビューが膨らむ
• 新規warningだけ止めれば、コードベースは少なくとも「これ以上悪化しない」状態を保てる
• 既存warningの撲滅は別スライスなので、優先度を独立して判断できる

ありがちな落とし穴

• AIに「warningを直して」と頼むと、関係ない範囲まで触ってくる。指示は「このスライスで増えたwarningだけ」と明示する
• 基準線の更新を忘れる。既存warningを1件直したら、基準線も1件下げる。下げないと「今回直した分」が次のスライスの新規扱いになる
• 古い SYSLIB0021 のような廃止予定APIの警告は、SDKアップデートで増減する。SDK更新時は基準線を取り直す

わかったこと

• 警告ゼロは理想だが、移行中は 新規悪化を止める で十分。完璧主義より持続可能性
• 既存warningは 可視化されているだけマシ。隠さない、消さない、別タスクで管理する
• AIレビューでも「新規warningが出ていないか」を固定観点にすると、検出が安定します

次にやること / 未解決の問題

• 基準線の自動チェックをCIに組みたい。今は手でbuildログを比較している
• SYSLIB0021 のような外部要因のwarningは、抑制属性で隠すか直すかの判断がまだ揺れている
• 既存warning撲滅の優先度を、影響度（実行時バグの可能性）で並べ替える運用がまだない