たとえるなら
家のリフォームで新しい棚を取り付けたら、隣のドアが棚にぶつかって開かなくなった——そんな出来事です。新しくした場所そのものは問題なくても、まわりの「今まで普通に使えていた場所」に思わぬ影響が出てしまうことがあるのです。
もう少しくわしく
デグレは「デグレード（degrade: 品質が下がる）」を略した和製の現場用語で、修正や機能追加のせいで、これまで正しく動いていた機能が壊れてしまうことを指します。「先祖返り」と呼ばれることもあり、英語圏ではリグレッション（regression: 後戻り）という言葉が同じ意味で使われます。どの現場でも通じる言葉なので、早めに覚えておくと会話に困りません。
なぜこんなことが起きるのでしょうか。プログラムの部品は互いに影響し合っていて、一見関係なさそうな場所同士が裏でつながっていることが珍しくないからです。ログイン画面を直したつもりが、同じ部品を使っていた会員登録画面まで動かなくなる。共通の部品に手を入れたときだけでなく、共有している設定やデータの形を変えたときにも起きます。つながりをすべて覚えておくことは誰にもできません。
ふつうのバグとの違いは「前は動いていたか」の一点です。新しく作った機能が最初から動かないのは、ただのバグ。以前は問題なく使えていた機能が、別の作業をきっかけに動かなくなったものがデグレです。この区別が大事なのは、原因の探し方が変わるからです。デグレなら直前の変更のどれかが引き金と分かっているので、履歴をさかのぼれば突き止められます。壊れた時点を見つけられるかどうかが、解決までの時間を大きく左右します。
現場ではデグレを仕組みで捕まえます。代表が、修正のたびに既存の機能が壊れていないかを確かめ直すリグレッションテスト（回帰テスト）です。これをプログラムで自動化しておけば、何百項目もの確認を機械が数分で済ませてくれます。見つかったときは、変更履歴（Git）から「どの変更から壊れたか」を絞り込み、影響の大きさを見て、修正するか前の状態に戻すかを決めます。
落とし穴の代表は、「触っていないから大丈夫」という思い込みです。裏でつながっている以上、触っていない機能こそ確認が必要です。次に多いのが、納期に追われて確認の範囲を削ること。そしてリリース直前の駆け込み修正。急いで入れた小さな修正がデグレを呼び、かえって公開を延ばす結果になるのは、どの現場でも見かける光景です。急ぎの変更こそ、確認の時間を必要とします。
働きはじめたばかりの人は、デグレを出したこと自体より、隠すことのほうが問題だと覚えておいてください。気づいた時点で「自分の変更で別の機能を壊したかもしれません」と言えれば、被害は最小で終わります。エンジニアではない立場の人は、不具合に気づいたときに「前は動いていました」と付け足すだけで、原因の調査が大きく早まります。細かい条件まで分からなくても、気づいたことをそのまま伝えれば十分です。
デグレが多い現場は、担当者の実力不足というより安全網が足りていない状態と見るのが妥当です。自動テストを書く時間は一見遠回りですが、修正のたびの確認を機械に任せられるようになると、開発そのものの速さが上がります。逆に、人の注意深さだけで防ごうとすると、機能が増えるほど確認が追いつかなくなり、いつか必ず取りこぼします。安全網は個人の努力ではなく、チームで決める投資です。
現場での使われ方
「この修正、デグレってないよね？」
直した箇所以外の機能が巻き添えで壊れていないか、確認したかを問う定番のやりとりです。現場では「デグレる」と動詞にして、こう気軽に確認されます。
「デグレが見つかったので、リリースは延期です」
公開前の最終確認で、以前は動いていた機能の不具合が見つかった状況です。出してから慌てるより延ばすほうが安全という、苦渋の判断としてよくある場面です。
「先週までは使えていたので、たぶんデグレですね」
以前は動いていたという情報から、最近の変更が原因だろうと見当をつけている発言です。調査の入口を教えてくれる、価値の高い一言になります。いつから、という情報は必ず添えたい点です。
「どの変更でデグレしたか、履歴をさかのぼって調べます」
変更履歴を古いほうへたどり、動いていた時点と壊れた時点の境目を探す作業です。壊れていない時点が分かれば、応急の対応もしやすくなります。地道ですが確実な方法です。
よくある質問
デグレとバグの違いは何ですか？
デグレもバグの一種です。バグはプログラムの誤り全般を指し、そのうち「前は正しく動いていたのに、修正や機能追加のせいで壊れたもの」を特にデグレと呼びます。新しく作った機能が最初から動かないのは単なるバグで、呼び分けるのは原因の探し方が変わるからです。
デグレとリグレッションは同じ意味ですか？
ほぼ同じ意味です。デグレは日本の現場で定着した略語で、英語としてはそのまま通じません。英語圏ではリグレッション（regression）と言います。既存の機能が壊れていないか確かめるテストは、日本でも「リグレッションテスト（回帰テスト）」と呼ぶのが一般的です。
デグレはどうすれば防げますか？
完全には防げませんが、見つける仕組みは作れます。修正のたびに既存の機能を確かめ直す自動テスト、変更内容を別の人が読むコードレビュー、そして変更履歴をきちんと残すこと。この3つが定番の備えで、どれも一度整えれば以後ずっと効き続けます。整える順番は、自動テストからが効果的です。
テストをしたのにデグレが起きるのはなぜですか？
テストで確かめられるのは、あらかじめ用意した項目の範囲だけだからです。「今回直した機能」は丁寧に確かめても、裏でつながっていた別の機能まで毎回すべて確かめるのは手作業では追いつきません。項目を作った時点で想定していなかった経路は、どうしても抜けます。
自分の修正でデグレを出してしまったらどうすればいいですか？
すぐ報告するのが正解です。隠して様子を見るのが、いちばん被害を広げます。影響の範囲と、いつの変更が原因かを伝えれば、修正するか前の状態に戻すかをチームで判断できます。どこを壊した可能性があるかまで添えられると、さらに助かります。早く言うほど、選べる手が多く残ります。
