ソフトウェア開発プロジェクトにおいて避けては通れないデグレ（デグレード：degrade）。
ソフトウェア開発に携わる方で、一度もデグレを経験したことがないという方はいないのではないでしょうか。
一口にデグレといっても大きなものから小さなものまで、様々な性質のデグレがありますが、時にデグレの発生がプロジェクトの運営に大きな悪影響を与えることもあります。
本記事ではデグレの概要やそのリスク、原因、そして対策について実際の事例などを踏まえながら、ご紹介いたします。

デグレ（デグレード：degrade）とは

デグレとは、プログラムの変更や修正により、その他のプログラムに意図しない影響が発生し、変更・修正前よりもソフトウェアの品質が悪化することを指します。

具体的には以下のようなことが発生することがあります。
・過去のバージョンで既に修正済の不具合の再発
・変更・修正した箇所以外での新たな不整合・不具合の発生
（変更・修正箇所が多くの機能に関連する場合、非常に広い範囲に影響が及ぶこともあります）
・更新内容の喪失　など

なお、デグレとは品質の「悪化」や「低下」を意味するデグレード （degrade）の略であり、和製英語のため日本人にしか通じない単語となります。デグレのことをデグレーション（degradation）、デグレッションと呼ぶこともあります。
英語ではRegression（リグレッション）という単語を用い、これは「後戻り」や「退行」、「回帰」を意味します。

「リグレッション」という言葉を聞いたときに「リグレッションテスト」のことを思い浮かべられるかもしれませんが、これはリグレッション（＝デグレ）を確認するテストのため、そのように呼ばれています。
一部では「リグレッションテスト」のことを「回帰テスト」と呼ぶこともありますが、これは上のようにリグレッションを和訳したものであり、「リグレッションテスト」＝「回帰テスト」と同じテストのことを指しています。

また、JSTQBの『テスト技術者資格制度 Foundation Level シラバス Version 2018V3.1.J03』によると、デグレとは以下のように定義されています。
なお、ISTQBおよびJSTQBでは、グローバルスタンダードにならい「デグレ」ではなく「リグレッション」という単語を使用しています。

こちらをシンプルにまとめると、デグレ（リグレッション）とは「コードや環境などの修正・変更によって生じた、他のコンポーネントやシステムへの意図しない副作用」と言えるでしょう。

デグレの影響やリスク

ではそのデグレが発生すると、どういった影響やリスクがあるのでしょうか。
こちらでは特に影響の大きい、主なデグレの影響とリスクについてご紹介します。

ビジネスに大きな損失が生じる可能性も

デグレの発生により、それまで動いていたシステムの動作に不具合が出ることは、ソフトウェアの品質保証（QA）業務において重大なリスクをもたらします。
例えば、運用フェーズにあるソフトウェアであれば発注元企業の業務やUX（ユーザーエクスペリエンス、顧客体験）に直接的に影響が及び、その結果として発注元企業やエンドユーザーからの信用・信頼を大きく損ねるだけでなく、場合によっては、デグレを原因としたシステムトラブルによりビジネスに大きな損失が生じれば、損害賠償請求などにも発展しかねません。

想定外の追加工数・コストの発生

デグレが発生した場合、その影響を最小化するために早急な対応が求められます。そのためデグレが影響する範囲や具体的な内容、重大性などの調査が必要となります。
さらに発注元企業への説明やそのための資料作成など、当初想定していなかった工数やコストが発生します。
デグレの影響が重大な場合はスケジュールにも影響を及ぼす可能性が高く、納品期日が契約で定められている場合は契約に関するトラブルにつながることもあります。
またデグレの発生によって顧客から徹底したリグレッションテストをリクエストされることもあり、当初の予定以上にテスト工数・コストがかさむというリスクもあります。

開発チームのモチベーションや生産性への悪影響

デグレに対して適切な対処ができない場合、開発チームの疲弊やモチベーション低下、ひいては開発者の退職リスクにもつながります。
実際、弊社SHIFT ASIAが過去にソフトウェアテストを担当した案件においても、修正済みの不具合が再発したり、不具合の修正によって新しい不具合が生じるというデグレはしばしば発生していました。

SHIFT ASIAがソフトウェアテスト担当として参画したある大規模プロジェクトでは、不具合の修正後に以前にはなかった新たな不具合がデグレによって発生するという問題に悩まされていました。
このプロジェクトでは、新たな不具合を修正すると、また別の不具合が新たに生じる、というようにデグレによる不具合の発生が連鎖して収拾がつかなくなり、結果的に開発ベンダーの変更や開発担当者の交代なども含め、プロジェクト運営に大きな影響が出ました。
このように問題が拡大してしまったのは、プログラムの修正による影響範囲の正確な把握ができていなかったり、デグレが発生した本当の原因を分析しなかったりと、場当たり的に不具合の修正を行ったことが原因でした。

また、デグレにはプロジェクトの中だけでなく、自社の経営や顧客、ユーザーにも及び得るリスクがあり、ビジネス全体に広範かつ大きな影響を与えることがあります。
その発生をできるだけ抑止し、影響を最小化するためには、デグレの原因を知り、対策を打つことが非常に重要です。

上で挙げた原因以外にもデグレが発生する主な原因はいくつかありますので、次の章で詳しくご紹介します。

デグレの原因

デグレは基本的にヒューマンエラー（人的ミス）により引き起こされると言われていますが、より具体的にどのような原因があるのかについて以下に紹介します。

プログラムの変更・修正の影響範囲の調査が不十分

変更・修正対象のプログラムが他のプログラムとどのような関係があり、修正・変更によりどういった影響を及ぼし得るのかといった事前調査の不足が主な原因の一つです。
その結果として他のプログラムに意図しない影響を及ぼしてしまうことで、デグレが発生します。
特に大規模なソフトウェアではさまざまなプログラムが複雑に絡み合っていることから、意図しない不具合を引き起こすリスクがより高まります。

ファイルの管理ルールや管理方法の不備・不徹底

ソースコードのバージョン管理が適切に行われておらず、最新ではないファイルを更新してしまうこともデグレが生じる原因の一つです。
特に修正済みの不具合の再発はこれが原因のことが多く、不具合修正前の古いファイルを誤って使用することで、既に修正したはずの不具合が再度発生するということが起こります。
また不具合の再発だけでなく、最新の他のプログラムとの不整合を起こし、新たな不具合の発生につながることもあります。

情報の共有漏れや認識の相違

プログラムの変更や修正や、仕様の変更といった情報の共有が徹底されていないケースをはじめ、開発者あるいは開発チーム間で認識の相違が存在することもリスク要因の一つです。
仮に仕様に対する理解にズレが生じたまま開発を進めれば不整合が発生することは避けられず、検出タイミングが遅れた場合、その影響はより大きなものとなり得ます。
情報の共有漏れや認識の齟齬によるデグレの発生は、複数の開発ベンダー・多くの開発者が関わる大規模なプロジェクトにおいてより発生しやすいと言えます。規模が大きい分、デグレの影響も大きくなりやすいことから、特に注意が必要です。

デグレの原因は人為的なミスが起点になっているものがほとんどであり、人間がソフトウェア開発を行う限り、デグレを完全に防止することは極めて難しいと言えます。
したがって、デグレは発生するものと認識をした上で、できるだけその抑止や影響を小さくする対策が求められます。
ではどうすればデグレ発生の抑止やその影響を最小限に抑えられるのでしょうか。

デグレの対策

デグレの対策は、「デグレの発生を抑止するアプローチ」と「発生したデグレの影響を抑えるアプローチ」の２つに大別されます。
こちらでは、それぞれの主な対策についてご紹介します。

デグレの発生を抑止するための対策

徹底した影響調査の事前実施

当たり前のことのように思われるかもしれませんが、デグレの原因でご紹介した通り影響範囲の調査が不十分であることがデグレの大きな原因の一つであることから、一定の工数はかかるものの、出来る限り客観的かつ徹底的に調査を実施することが重要です。
とはいえ、いたずらに調査を行っても負担が増大してしまうため、特に重要度の高い機能や、修正が必要なプログラムが重要な機能と紐づいている際は重点的に行うなど、重要度に応じて優先順位を決めた上で対応するのが現実的です。
また見積りの段階で、影響調査にかかる工数をあらかじめある程度織り込んでおくことで、余裕をもって調査を実施しやすくなります。

影響調査に手間をかけることがデグレの抑止に繋がり、トータルではメリットとなりやすいと言えます。
過去に不十分な影響調査が原因でデグレが生じたことがある場合は、まずは一部の重要性の高い範囲に限定した上で、実施を検討してみてはいかがでしょうか。

明確なファイル管理ルールの策定と運用の徹底

バージョン管理システムを用いたファイル管理のルールや、管理方法をプロジェクトの当初からきっちり決めておくことが重要です。
会社やプロジェクトによってルールや管理方法が異なることもあることから、資料化した上で必ず周知するようにしましょう。
管理ルールが曖昧になっていると、開発の途中でファイルの新旧・正誤が入り乱れて混乱を招き、それがデグレの温床となることがあります。

事前に管理ルールの策定・周知を徹底した上で、プロジェクトの開始後にはルールがきちんと厳守され、ルールが定着し運用にのっているかのモニタリングも並行して行う必要があります。
ルールは作成したものの、それが正しく運用にのらないというのはよくある現象の一つです。
なかなか定着しない場合は、定期的なチェックを行うなど粘り強く働きかけるようにしましょう。

発生したデグレの影響を抑えるための対策

リグレッションテスト（回帰テスト）の実施

機能の追加や不具合の修正によってプログラムの一部を変更した際に、ソフトウェアの動作に問題が生じていないことを確認するために、リグレッションテストを実施します。
補足として、リグレッションテストは回帰テストのほか「デグレードテスト」「退行テスト」などと呼ばれることもあります。

リグレッションテストでは基本的には既存の機能やフローなど、既にテストが行われた範囲に対してテストを行い、プログラムの変更がそれらの機能やフローに影響を与えていないかを確認します。
何度も繰り返し確認が必要となる重要なテストケースは自動化されることが多く、後述のように自動化されたリグレッションテストをCI（継続的インテグレーション）環境のなかで運用することが一般的な方法となってきています。

しかし自動テストには「コード通りにしかテストをしない」という特徴があることから、コストや工数を加味し、自動テストと手動テストを組み合わせることで、より効果的なリグレッションテストの運用が可能となります。

自動テストについては、テスト自動化とは｜テストを自動化するメリットと注意点の記事で、
またリグレッションテストについてもリグレッションテストとは｜その目的や重要性、実施のポイントの記事でそれぞれ詳しくご紹介しています。宜しければ合わせてご参照ください。

CI（継続的インテグレーション）環境の導入

CIとは継続的インテグレーション（Continuous Integration）のことで、開発者がコードの変更を1日に数回といった高い頻度でリポジトリにマージすることを指します。
CI環境を導入することで、任意のタイミングでコンパイルからテスト、デプロイを自動で繰り返し実行することが可能となり、テストを頻繁に行うことでデグレを早期に検出・解消しやすくなることから、開発工数の削減や品質の向上なども期待できます。

最後に

デグレは人為的なミスが主な原因である以上、常に起こり得るものである一方で、デグレの影響やリスクはときに大きくなり得るという特徴を持っています。
特にその影響はプロジェクトの中だけに留まりません。
受託開発の場合であれば顧客、さらにはその先のエンドユーザーにまで影響が及ぶ可能性があるほか、自社の信用問題にも発展しかねないリスクにつながる可能性があるとも言えます。

またテストに関しては、特に重要な機能やフローに対しては重点的にリグレッションテストを設計・実行することで、デグレを検知できる仕組みをつくることが重要です。
何度も繰り返し確認が必要な箇所については、リグレッションテストを自動化することで、より効率的な実施が可能となります。
その上でCI環境を構築し、自動化されたリグレッションテストを頻繁に実施することで、さらなるデグレの予防や早期の検出につながります。

SHIFT ASIAのソリューション：リグレッションテスト

デグレの発生を完璧に防止することはできないという前提に立ち、今回ご紹介したさまざまなアプローチをあらかじめバッファとして一定の対応工数に組み込んだ上で、事前の影響調査などを通じた抑止と、仮に発生してもその検出や原因調査をスムーズに実施し影響を抑えられる仕組みの構築がデグレの対策には肝要です。