デグレ（デグレード）とは？意味や種類、起きる理由、リスクをわかりやすく解説

デグレとは、簡単にいえば、システムの改修を行った際に欠陥をつくりこみ、従来実行できていた機能が使えなくなることです。稼働中のシステムを改修してデグレが発生すると、利用者に対して迷惑をかけるだけではなく、開発者側もその対応のために通常の不具合修正よりも多大な工数を取られてしまいます。デグレを発生させないためにはいくつかの対策がありますが、どのような対策が有効とされているのでしょうか。

本記事では、デグレの概要と種類、発生する原因や防止策・対応策について解説します。

株式会社SHIFTでは、ソフトウェアテストに関して豊富な実績とテストナレッジを保有しており、あらゆるお客様のニーズを満たしたテスト・品質保証を上流～下流（テスト計画・テスト設計・テスト実行・テスト品質管理）まで一気通貫でご依頼いただけます。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

デグレとは、機能の追加や変更のために稼働中のシステムを修正した際に、それまで動作したものが動かなくなってしまうことによって発生するトラブルのことです。英語の「degrade」（低下する、下がる）の略語であり、日本のIT業界では「デグレ」という呼び方でなじみがあります。

英語圏ではデグレードという言葉はRAIDの不整合を表す時に用いられることが多く、私たちが日ごろ日本で使っている「デグレ」、すなわち「変更により引き起こされた、コンポーネントやシステムの品質の悪化」を表す言葉としては「リグレッション（regression）」という言葉を用います。

このコラムでは、以降「デグレ」という言葉を用います。なお「リグレッションテスト」についてはそのように呼びならわされていますので、この言葉を用いることにします。

＞＞リグレッションテスト（回帰テスト）とは？目的や自動化のメリットを解説

デグレにはさまざまな種類がありますが、不具合の埋め込み箇所別に3つに大別できます。

・プログラムの改修時に誤った処理が埋め込まれた
・インフラ環境の変更の影響を受けた
・データ変更の影響を受けた

それぞれの状況や不具合の詳細について解説します。

ひとつ目は、プログラムを実装・改修した際に誤ったコードが埋め込まれたことによって発生するデグレです。この種のデグレの影響範囲は、埋め込まれたコード箇所だけでなく内容によっても影響範囲が変わります。改修した機能だけでなく、変更のない機能のデグレを誘発してしまうこともあります。

具体的には、機能を改修した際に埋め込んだコードが、変更対象ではなかった入力の時に悪影響を与えて誤った結果を返してしまうなどです。改修したプログラムがその機能に閉じていると考えていたコードが、実はほかのプログラムからも使われていて、想定外の影響が出たケースもあります。

機能の追加・修正の時は、往々にして変更する機能に気を取られて、変更対象でない機能の確認が疎かになることがあります。修正や機能の追加でコードを新たに実装・改修する場合は、変更する内容だけではなく、既存の機能全体に影響確認をとる必要があります。

複数のインフラや、多数のサービスの結合で成り立っているシステムにおいて発生することがあるデグレの例です。この種のデグレは、次のようなタイミングで発生します。

・環境設定値の変更
・環境に適用しているミドルウェアやライブラリのバージョンアップ
・環境の移行

環境の変化による問題ですが、環境変化と合わせて対応しなければならない作業が漏れていると、デグレが発生します。あるいは、その変更に合わせようとプログラムを修正した結果、デグレが発生する場合があります。特に休日などの停止時間の間に作業をするなど、確認に時間が割けない場合、インフラの変更をした後にテストが不十分なまま終わってしまうケースがありますが、これがその後システムダウンにつながるなどの大きな問題に発展してしまうことがあるのです。

また、インフラ環境の変更に起因するデグレは、比較的広範囲に影響が出てしまいがちです。影響範囲が大きいことを念頭に置き、実際にデグレが発生しないことを広い範囲で確認しながら進めるような対策を講じ、慎重にリリース前の段階で想定外のデグレを防いでおくことが重要になります。

システムに機能を追加する場合は、開発を行うなかで、ソフトウェアやインフラを修正するだけでなく、新機能で使用するデータが追加で必要になる場合があります。データが増えることによる影響によっては、ソフトウェアとしての実装に問題はなくても、デグレを誘発することがあります。

例えば、データ自体やデータ間の関連が複雑になることによってデータベース操作が重たくなり、システムがスローダウンするようなケースがあげられます。また、システム改修による変化について十分な計算やシミュレーションをせずに改修を進めてしまい、想定以上にメモリやストレージを使ってしまった結果、容量不足から発生するデグレもあります。

検証環境ではデータ量が少なくて問題なく動いていたとしても、本番環境では大量のデータが使われていて、スローダウンや容量不足につながることがあります。特にインフラを変更する時はメモリの使用量が大きく変わることがあるので、注意が必要です。

対策としては、本番運用のデータ量で確認することが有効です。

デグレの種類が明確にできたところで、次にデグレが発生する原因を整理しましょう。以下の具体的な発生原因について、簡単に対応のポイントを紹介します。

・実装者のミスがあった
・仕様情報の最新化や整備がされていなかった
・コミュニケーション上でミスや不足があった

ひとつ目は、仕様理解が正しくない状態で実装や影響範囲調査を行った場合です。勘違いや思い込み、認識違いなどのヒューマンエラーが原因とされています。しかし、冷静に見てみると体制的な問題や状況的にミスを誘発しやすい状態など、個人のミスとだけはいえない課題が潜んでいる可能性もあります。

ルールの設定や体制構築などをすればある程度の効果はあるでしょう。しかし「ミス」を完全になくすことは非常にむずかしいため、完璧にミスをゼロにするのは不可能ともいえます。

したがって、「ミスが起きづらい体制と状態づくり」を先ず念頭に置きましょう。そのうえで「何らかのミスは起きる」という前提のもと、チームとしてそのミスを事前に見つけて対応できる方策を考えてみるとようにしてください。

仕様が最新の内容に整備されていないことで「正しい情報を基に正しい考慮ができない」という状況が発生しえます。仕様整備については、まずは整備ルールを設定し、それをどこまで徹底できるかが鍵です。メンバーへ呼びかけるだけでは徹底がむずかしいため、次のポイントとしておさえておくとよいでしょう。

・過度になり過ぎない程度にシステム的に更新が管理できる方法を導入する
・プロセスにルールを組み込むことで仕様書を更新しないとシステムの修正ができない状態をつくる
・ルール自体に徹底できない大きな要因となっている内容があれば見直す

このような仕組みの整備で、自然と仕様書を最新に保っていけるようになると、未整備情報を起因としたデグレを減らすことができるでしょう。

複数のチームに分かれて体制を組んでいるようなプロジェクトでは、チーム間やチームをまたいだ担当者間のコミュニケーションの課題に起因するデグレが起きる可能性があります。プロジェクトの進行はすべてが直列作業というわけではないため、どうしても仕様整備のタイミングにずれが生じ、つねに最新情報を自分だけで把握しておくのは非常に困難です。

そこで重要になるのがメンバー間のコミュニケーションです。質疑応答のすれ違いや更新情報の共有漏れなどが、デグレ発生の原因になります。影響を受ける機能担当同士での確認が不十分なまま作業が進行してしまうと、想定外のデグレにつながる可能性があります。

コミュニケーション上の課題に対してはルール整備も大事ですが、加えて以下の取り組みも重要です。

・プロジェクト内の風通しをよくすること
・情報共有や相互確認をすることがお互いにとってプラスになるといった意識がもてるような体制をつくること
・環境面や心理面でコミュニケーションをとるハードルを下げていく取り組みをすること

起きる原因はわかったとしても、何らかのきっかけでデグレは発生する可能性はあります。ここでは実際にデグレが発生してしまった場合に起きてしまうこと、そのなかでも影響が大きい、リスクが高い以下の点について解説します。

・顧客の信用を失う
・想定外の工数やコストの発生
・デグレの再発

デグレの発生は「使える想定でいたものが使えない」状況を生んでしまいます。この状況はお客さまの信用・信頼を失うことに直接つながってしまいかねません。

信用を失うと、より厳しい目でお客さまから見られることとなり、その分要求も厳しくなりがちです。また一般の消費者がお客さまの場合、デグレをきっかけにサービスの利用者が減ってしまうということにもつながりかねません。

デグレは基本的に早急な修正対応が求められます。当たり前ではあるのですが、修正の際に別のデグレが発生しないようにしなければなりません。ただ、これらの対応はそもそも想定外の作業であり、修正に伴う新たな工数の発生とコストが必要となることがあります。また作業上だけでなく、リリースや納品などの予定まで大きく狂わせる可能性があります。

そのための詳細な影響範囲の調査とテストを十分に行い、調査結果を十分とする根拠を示すための報告資料が必要となるでしょう。これ以上のデグレを発生させないためにも、調査を十分に行わなければなりません。

工数が増加した結果、期限に間に合わなくなってしまうと、受託プロジェクトであれば契約違反とみなされ請求ができない事態になる可能性があります。場合によっては損害賠償請求される可能性もあるでしょう。自社プロダクトであっても外部にステークホルダーがいてリリースが必須要件といった場合は、デグレ対策でリリースできないと同様の状況にもなりえます。

デグレ発生に対処した結果、別のデグレを誘発してしまう可能性があります。デグレが発生したということは、そもそもデグレリスクが潜んでいた箇所でリスクが顕在化してしまった結果と考えることができます。そもそもリスクが高かった箇所なのであれば、再度同じような問題も発生しやすいといえるでしょう。デグレがデグレをよぶという、いわゆる「負のスパイラル」に陥らないためにも、正確で確実な対応が必要となります。

そもそもデグレの修正には、正確さや確実性が要求されるうえに、早急な修正作業が求められます。また、対応は想定外のことでもあるため、対応する人あるいはチームに焦りを呼び込んだ結果人為的なミスも起きやすい状況となりがちです。このような場合は、さらなるデグレの再発を誘発する可能性も高まり、デグレが再発してしまうかもしれません。

苦しいところではありますが、デグレ発生時は通常時以上に正確な情報を基に、確実な修正対応をとることが肝要です。「とりあえず」の対応でその場をしのぐのはおすすめできません。

デグレの原因とあわせて簡単な対応のポイントは紹介しました。ここではもう少し具体的にデグレ対策について紹介していきます。

デグレの対策は、目的別に考えてみると、次のような2つのものに大別できます。

・デグレの発生そのものを防止する「防止策」
・デグレが発生したとしても影響を最小限にとどめるための「対応策」

一般的には事前に十分にテストを行うという前提で、デグレは起きないという前提で工数を計画しますが、万が一デグレが発生してしまった場合には追加の工数が必要となります。リスクの高いプロジェクトの場合は、「想定外の不具合やデグレは一定数発生し得るもの」という前提に立って、デグレの発生自体をおさえることを目的とした「防止策」だけでなく、デグレ発生時の影響を低減させることを目的とした「対応策」も必要だといえます。

以上に加えて、これらの策をどれだけ効果的に導入するか、戦略的にどのようにコントロール可能な状態を目指すのか、ということがとても大事な考え方です。

これらを踏まえたうえで、どんな防止策や対応策があるかを見ていきましょう。

防止策としては、基本的にデグレが発生してしまう「原因」に対して有効な手段を考えていきます。ここで紹介している策は基本的ですが重要なことです。いずれかに対応すればよいものではなく、複数（あるいは全部）に取り組むことで、よりデグレが発生しづらくなるといえます。

仕様情報を含めたバージョン管理や更新ルールを決めて運用を徹底することで、そもそもミスが起きづらい状態をつくることが必要です。具体的には、次のようなものがあげられます。

・（もしなければ）管理・更新ルールの導入
・更新時の関係者への通知方法、タイミングなどのコミュニケーションルールの策定
・更新内容に応じて影響を受ける関係者への説明機会を設けるための基準の設定
・プロジェクトのプロセス内への更新の確認やレビューの組み込み
・ルール運用の徹底をプロジェクト全体へ浸透させるためのウォッチング、呼びかけなどの活動を定常化
・可能な範囲でシステム化し、定めたルールが自然と徹底される仕組みの導入

デグレは、往々にして影響範囲の調査でミスや考慮不足が直接の原因となって発生することが多いのが実情です。

そのため影響範囲の調査という作業に対しても、ルールや方針、ミス防止の仕組みといったものを導入することもデグレ防止に有効です。具体的には次のようなものがあげられます。

・正しい仕様情報、正しい理解を基に、確実で十分な（的確な）調査の実施
・不確実な部分があれば、仕様情報にもとづく確認だけでなく現新比較を実施
・可能であれば静的解析ツールなどを用いて人的ミスの発生を抑止
・自身の理解の正しさを影響範囲の担当者とすり合わせる
・同じような処理のなかにあるわずかな「差」にこそデグレが生まれるものと考え、考慮を怠らない

対応策としては、デグレが存在していた場合でも「最終的なリリースまでにどのようなコントロールが有効か」という手段を考えます。

デグレがあったとしても、お客さまへ影響しないようにテストなどで事前に検知して対応できることが重要です。さらにそこをすり抜けたとしても、リリースへの影響を最小限にとどめるためにどんな取り組みが有効か、というような例をあげます。

以降で紹介する対応策は、デグレそのものだけでなく、結果的にシステムの品質までコントロールしやすくなるメリットもあります。ぜひ参考にしてみてください。

・リグレッションテスト
・自動テスト・CI活用
・デグレの振り返り
・リリースのコントロール

リグレッションテストとは、デグレ（英語でリグレッション）を検出したり発生しないことを確認したりするため、基本的に既存機能などテスト済みの範囲に対して行うテストです。回帰テストと呼んだり、無影響確認と呼んだりすることもあります。

リグレッションテストを行う際の対象（範囲）や優先度の考え方、気をつけるべきポイントは次のとおりです。

・「十分な影響範囲調査」結果を基に、的確な影響範囲に対してテストを行う
・リグレッションテストで重篤な問題が出た場合でもリリースまでに修正対応可能なスケジュールでテストを行う
　※リグレッションテストで検出された不具合の対応方針を決めておく（不具合の重要度などを別途定義しておき、重要度に基づいて許容可否を判定するなど）
・本番環境と極力同等の保証が可能な環境やデータにおいてテストを行う
　※環境やデータの違いで起きるデグレを見逃さない
・優先度を考慮してテスト範囲を絞り込む（影響範囲全体・全パターンのテストは工数や期間的に困難なことが多い）

＞＞リグレッションテスト（回帰テスト）とは？目的や自動化のメリットを解説

CI（Continuous Integration, 継続的インテグレーション) とは、コンパイル、テスト、デプロイといった一連の作業を任意のタイミングでも定期的にでも自動で行うことが可能な仕組みです。テストに関しては自動テストコードの実装が必要で、運用していくなかでメンテナンスも欠かせません。しかし、実装済みの自動テストは、次のような目的に対して有効な手段となります。

・リグレッションテストの効率的な実行
・検出し易いデグレの早期発見

またCIで定期的に自動テストを行うことで思わぬデグレを検出できることもあるなど、次のような場面で効果を発揮します。

・すべてのAPIの挙動変化の検出
・影響範囲外と考えていた範囲のデグレの検出
・環境や別機能の変更の影響を受け、知らぬ間に埋め込まれたデグレの検出

一方で、自動テストはテストを実装していない内容で発生するデグレは検出できません。内容によりますが、手動であるために気づける場合もあります。手動テストであれば自動テストコードの実装までは不要で、自動テストと比較すると新たな内容に対して柔軟に対応しやすいことが多いです。

上記の通り自動テストは効率的にリグレッションテストを行ううえで有効な手段ですが、プロジェクトの当初から自動テストを採用していないと、実装のコストがかかり、短期的な対応には不向きなこともあります。そのため自動テストと手動テストとをバランスよく組み合わせて活用することで、さらなる効果を発揮するものだとお考えください。

＞＞テスト自動化とは？メリットや導入の流れ・向いているテストを解説

一度発生したデグレや類似の不具合は再発しやすいものです。デグレについて吟味し、振り返ることで、その後の同じまたは類似の不具合の再発防止に有効な改善策が見つかるかもしれません。見つかった改善策は、防止策の質向上にも適用できます。デグレの振り返りをするうえでおさえておきたいポイントは次のとおりです。

・デグレの直接的な原因に留まらず、その原因を生んでしまった真因まで分析する
　＊個人のミスや問題とするのではなく、それがなぜ起きたのかまで吟味する
・改善策はプロジェクトの仕組みや取り組み上の改善となるものを念頭に、真因に対して有効な策を検討する
・改善のための具体的なアクションまで決めて導入する
・検討した改善策を導入するだけでなく、導入後の効果測定も行い、必要に応じて見直しも行う

リリース時に問題を検知してすぐに元のシステムに戻すことができれば、デグレによる影響を最小限にとどめることもできます。
特にクラウド環境では、「カナリアテスト」と「シャドーテスト」および「A/Bテスト」のような手法で直後の品質を確認しながらリリースを行うことが可能です。これらはデグレ発生時の対応策として有効なだけでなく、システム品質の安定や向上にも寄与する手段です。

・カナリアテスト
カナリアテスト、カナリアリリースと呼ばれることもありますが、これは現行のシステムと更新後の新システムを同時に稼働させて、ロードバランサーを使って利用割合をコントロールする手法です。最初はほとんどのユーザーを現行システムにルーティングし、少数のユーザーのみを新システムにルーティングします。もし新システムにデグレがあった場合は炭鉱のカナリアのように異常が検出されるので、そこですべてのユーザーを現行システムに戻します。新システムが問題なく動作しているようであれば徐々に新システムにルーティングするユーザーを増やしていき、最終的にすべてのユーザーが新システムに移行することになります。

・シャドーテスト
シャドーテストは、新システムを公開しないで、陰でシステムの挙動を確認する手法です。現行システムと新システムを同時に稼働させて、ロードバランサーで両方にユーザーの入力を配分します。ユーザーには現行システムからの出力を返却しますが、同時に新システムからの出力と現行システムからの出力を比較します。もし両者に違いがあれば、デグレの可能性が高いということで、詳細を調査するという手順になります。

この手法では純粋にデグレの確認のためだけに現新双方のシステムを稼働することになりますが、業務の実体に応じたリグレッションテストが可能になります。

・A/Bテスト
A/Bテストは、現行機能と新機能、もしくは新機能の二種類の実装を提供して、ユーザーの挙動を見て最終的にどちらを残すかを決める手法です。現行システムと新システムの場合は、両方を稼働させるのはカナリアテスト同様ですが、ユーザーを半々に分けてそれぞれにルーティングします。それぞれのユーザーをモニタリングして、新システムが良ければ新システムを残しますし、新システムに問題があれば一度新システムを閉じて現行システムに戻します。

新システムのデグレ防止というよりは、ユーザビリティなどのシステムの有効性を確認する用途で使われることが多いでしょう。

＞＞ユーザビリティテスト（ユーザビリティ評価）とは？基礎知識や具体的な方法まで解説

デグレを完全に防止することは不可能ですが、極力防止させないための対策を講じることは可能です。基本的にデグレは発生するものという認識を置いておき、発生した際の対応策を講じるとともに、できる限り発生させないためにルールや仕組みをつくるようにしましょう。

デグレの発生原因は、主に人為的なミスであり、自社のテストだけでは見抜けない場合があります。SHIFTではソフトウェアテストのみのご依頼も対応しており、第三者目線でのテストを実施することで未然にデグレが発生するであろう箇所の発見に繋がります。実際にデグレが発生した際も、豊富な開発実績を基に、再発防止を念頭に置いた修正も可能です。

自社のソフトウェアテストだけでは不安が残る、デグレが発生しないようにチェックしてほしいなどのお考えをおもちであれば、ぜひSHIFTまでお問い合わせください。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

よくある質問はこちら
＞＞ソフトウェアテストのよくある質問にお答えします。目的や種類、作業内容、外注先の選び方などを解説のページへ

大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。

担当講座