ソフトウェア開発でいわれるデグレードとは、あるバグ修正の際に別のバグを混入させてしまうことを意味します。デグレと呼ばれているのをよく聞かれるのではないでしょうか。たとえば、文字列の長さをカウントする機能において、日本語（2バイト文字列）の長さを調べるコードのバグを修正したら、それまで期待通りに動いていた英数字（1バイトのASCII文字列）の長さを間違えて数えるようになった、というようなものです。
デグレの回避策としては、回帰テスト（修正部分の確認テスト以外に既存の機能が期待どおり動いているかを確認するテスト）があります。ただ修正のたびに広範囲な手動の回帰テストをやるわけにもいかず、テストの自動化にも限度があります。結果として、バグが起こったときのリスクの深刻さを勘案して回帰テストの実行ポリシーを決めたり、実行する回帰テストを選択（減少させる）して実行したり、自動化したテストプログラムの再利用性や規模を勘案して自動化の範囲を決めたりしていると思います。プログラム設計やテスト設計の時点で機能毎にどういうやり方にするか簡単な運用ルールを決めておくこともあると思います。
特に個別の請負開発システムや自社サービスなど修正が即座にできるもので現実に起こりうる状況としては、リリース後の運用中に事故が起こり、不具合を急いで対処し、デグレードが起こってしまうパターンがあります。一刻を争う状況で、冷静になるというのは相当に難しいのですが、事前に判断のフローを作っておいて急いでいても粛々とそれに従う、チェックを複数人の手に委ねるくらいしかなさそうです。実際にその状況に置かれるとなかなかそうもいかないのですが．．．
回帰テストのタイミングと範囲のポリシー決めはコスト投下に対する効果がそれなりによいと思っています。もしもまだであれば一度試してみてみる価値はあると思います。
Special
- PR -
あなたが常に持ち歩く防災グッズは？
富士通元社長の山本卓眞氏が残した次代へのメッセージ
東北をコットンの生産地としてブランディングしたい──リー・ジャパン・細川取締役
東北から始まるイノベーション
貧困国の雇用を創出する印刷屋、丸吉日新堂印刷の挑戦