デグレード
修正・更新によって、以前は動いていた機能が動かなくなる回帰現象。「デグレ」とも略す。「リグレッション(regression)」と同義で、英語圏では regression が一般的。リニューアル直後・修正適用直後・プラグイン更新直後に起きやすく、本人は意識せず別箇所を壊している、というのが特徴。
本書のスタンス(Lesson 5-6 / 8-1)は「公開直前の修正は新規バグだけでなくデグレードも呼ぶため、致命的なら公開日を動かす判断を推奨」。リグレッションテスト(以前の機能の再検証)で予防するが、完全には防げないので運用設計が必要。「公開を動かさない選択」と「致命的なデグレを残す選択」のどちらが事業損失が大きいかを判断材料に。
予防の実務:テストケースを 1 枚で管理(主要 CV 経路 + 公開後の運用フロー)、本番反映前のリグレッションテスト、ステージング環境での通し試験、ロールバック([[rollback]])手順の事前確認、本番反映直後の Smoke Test(主要動線を 5〜10 分で通す)、計測タグ([[tracking-tag]])発火確認、CMS 更新・プラグイン更新を本番直接ではなくステージングで先に通す。
落とし穴は、「ちょっと直すだけ」で他箇所を壊す、CSS の !important 一つで予期せぬ箇所が崩れる、JavaScript の依存関係を変えて GTM タグが発火しなくなる、CMS のプラグイン更新で WP テーマと衝突、PHP バージョンアップで CMS の機能が落ちる、サーバ設定変更でメール送信が止まる、リニューアル後の SP 表示崩れに気付かず数日放置。
言葉をよく利用する人
- コーダー / フロントエンドエンジニア
- インフラエンジニア
- Web 担当者(発注側)
- ディレクター
- プロデューサー
会話上での使用例
リニューアル後の小修正でデグレが発覚した場面
-
Web 担当者
タイトル文言変更後、フォーム送信が動きません
-
コーダー
タイトル変更でテンプレ全体に CSS が影響していました。デグレードです。ステージングで再現できなかった環境固有の問題。緊急ロールバック → 修正版を再反映の手順で
WordPress プラグイン更新後の表示崩れ
-
Web 担当者
プラグイン更新したら、TOP のスライダーが消えました
-
コーダー
プラグインの仕様変更によるデグレードです。プラグイン側のバージョンダウンか、新仕様に合わせた CSS / PHP 修正の二択。本番ロールバック → 検証 → 修正版反映、の順序で