「デグレ」はソフトウェアの開発者にとって、避けては通れない馴染みのあるキーワードです。デグレによって、大きな損害を受けた企業も少なくありません。この記事では、デグレの意味や具体的な事例をはじめ、原因や対策まで解説していきます。

デグレとは？

デグレとは、ソフトウェアの不具合修正や機能追加が原因となり、以前よりソフトウェアの品質が低下することです。デグレが発生すると、修正前は正常に動作していた機能が動かなくなったり、以前に修正したはずのバグが再発してしまったりします。

デグレは「低下する」を意味する英語の「degrade（デグレード）」を略した言葉で、日本のIT業界内で使われる特有の言葉です。英語圏ではデグレの代わりに「Regression（リグレッション）」という言葉が使われています。デグレもリグレッションも、表す意味は同じです。

デグレの具体的な例

これまで、さまざまなアプリケーションやソフトウェアでデグレが発生しています。以下、デグレが発生してしまった具体的な事例をいくつかご紹介します。

【音楽管理アプリの事例】

初期バージョンでは、OSと同じ言語でインストールされる仕様だったが、バージョンアップにより、OSと異なる言語でインストールされる設定に変更されてしまう。バージョンアップ時に使うインストーラの設定ファイルが、適切に構成管理されておらずデグレの原因となったパターン。

【カーナビにインストールされたソフトウェアの事例】

あるサービスエリアの地形が複雑であることが影響し、ナビ通りにすすむと高速道路から外れて一般道を降りてしまう不具合が発生した。そのサービスエリアだけ特別な処理を入れる改修を行ったが、地図データ更新後、その地点を通るとフリーズするデグレが発生。個別対応ロジックにより、プログラムの不整合が生じたのが原因だった。

【ゲームアプリの事例】

バージョンアップによって、新イベントの報酬が過去のイベントと同じ内容にすり替わってしまった。バージョンアップ時に、参照するマスターデータが誤っていたことがデグレの原因。

【車載機器に搭載するソフトウェアの事例】

テスト機では正常に動作したものの、工場で生産された製品版で起動しない不具合が発生した。テスト機に搭載されたソフトウェアではデバックモードが存在したが、生産ラインに乗せる段階でデバックモードのソースを削除したのが原因。起動時にプログラムが読み込まれるタイミングが変更され、重要なプログラムが読み込めなくなってしまい、起動できなくなっていた。

デグレが発生してしまった場合の影響

デグレによってもたされる、ソフトウェア開発元に対する影響は小さくありません。実際にどのような影響があるかみていきましょう。

ユーザーや顧客からの信用を失う

デグレによって、これまで正常に使えていた機能に不具合が生じるなどすれば、ユーザーや顧客からの信用を失いかねません。何がしかの不具合を修正したあとに発生したデグレの場合、ユーザーは「また不具合が発生した」といった印象を受けることになります。このとき、ユーザーの開発元に対する信頼が悪化してしまう恐れがあります。

調査や修正のため、想定外の工数やコストを消費する

デグレが発生した場合、改めて発生したバグや不具合の原因を調査し修正しなくてはなりません。デグレは本来想定していないので、その分だけ余計に工数やコストを消費してしまうことになります。その結果、開発元の負担が予定外に増えてしまうわけです。

デグレが発生する主な原因

デグレが発生する原因は、いくつかの典型的なパターンがあります。以下、なかでもよくあるパターンをみていきましょう。

管理体制に不備や問題がある

一般的にプログラムの修正を行なう場合、きちんとルールを決めて行うものです。しかしルールに不備があったり反対にルールが厳しすぎて適切に守られていなかったりすると、必要な修正が適用されないなどのミスにつながります。

バージョン管理が適切でない

たとえばプログラムの修正作業時に古いソースコードを使うと、過去の修正が適用されない状態となります。この状態でソフトウェアがリリースされれば、修正された筈のバグや不具合が復活してしまうことになるのです。このように、バージョン管理が適切でないデグレのパターンも少なくありません。

情報の共有が不十分

プログラム修正に携わる関係者が増える程、情報の共有は重要です。情報の共有が不十分で漏れがある場合、担当者によって最新の修正が適用されないなどデグレを引き起こす原因になります。

周辺機能やシステムの想定していない動作

プログラムの修正がきっかけとなり、周辺機能やシステムの想定していなかった動作によってデグレが発生してしまうこともあります。たとえばバグの修正によって、従来は正常に動作していたはずの周辺機能に、不具合が生じることもあり得るのです。

その他、ソフトウェアの挙動とは直接関係がない、デバック用のシステムの不具合を誘発してしまうこともあります。たとえば、ログが必要以上に出力されるようになってシステムの安定性が悪くなり、ソフトウェアも正常に動作しなくなるといったケースです。

このように、修正対象ではない周辺機能やシステムにも目を配っておかないと、デグレを引き起こしてしまう可能性があります。

デグレによるリスクを予防するための対策

デグレを発生させてしまった場合、ユーザーや顧客の信頼を取り戻すのは簡単ではありません。デグレによるリスクを予防するには、どうすればよいでしょうか。主な対策の例をみていきましょう。

管理や情報共有の体制をしっかり整備する

デグレは管理ルールの不備や不徹底による人的ミスや、きちんと情報共有が行われていないことにより引き起こされることが多いです。裏を返せば管理ルールを適切に整備しメンバーに順守させたり、情報共有の体制を整備したりすることでデグレを予防できます。

リグレッションテストを行う

リグレッションテストとはプログラムの修正や変更によって、新たな不具合が発生していないか確認するためのテストです。修正や変更の対象となった機能だけをテストして正常と判断されても、ソフトウェア全体でデグレが発生していないとは言えません。

あらかじめリグレッションテストを行うことで、デグレが発生していてもリリース前に検知できるわけです。デグレ発生を検知すれば、リリース前にデグレを修正することもできます。

リグレッションテスト（回帰テスト）とは？行うタイミング、自動化との関係も解説

リグレッションテストは自動化に適している

プログラムの修正や変更には、納期や予算の制限があります。そのためコストや工数を確保できず、リグレッションテストを十分に行えないことでデグレを検知できないというケースも少なくありません。

リグレッションテストを自動化できれば、テストにかけるコストや工数を大幅に削減できます。テストの自動化によって納期や予算の制限に抵触せず、リグレッションテストを適切な範囲できちんと行いやすくなるわけです。

リグレッションテストによって実施されるテスト項目は、大きな変更が必要となるケースは多くありません。リグレッションテストの都度、同じテスト項目を繰り返し実行することになるので自動化に適していると言えます。

まとめ

デグレとはソフトウェアの不具合修正や機能追加の作業によって、ソフトウェアの品質が低下してしまうことです。ソフトウェアのアップデート後に、アップデートとは関連性の機能が動作しなくなるなどデグレの事例は少なくありません。

デグレはソフトウェア改修のルールに不備があったり、開発チームの情報共有が適切に行われなかったりすることで引き起こされます。裏を返せば管理ルールを整備し、きちんと情報共有を行うことで、デグレの予防が可能です。

またリグレッションテストにより、デグレの発生を事前に検知することも推奨されます。リグレッションテストは毎回テスト項目が変わらないことが多いので、自動化し負担を軽減することも可能です。