デグレとは？意味や原因・対策方を事例や具体例を交えて紹介

デグレとはデグレーションの略語で「プログラム修正による性能劣化・品質劣化」のことです。

システム開発の現場では、プログラムの修正・改善をしリリースした後に想定外の不具合が発生したとき「デグれった」「デグレが発生した」と表現しています。

大規模なシステムや複雑なシステムでは修正による影響を把握しきれいないケースがあります。

その結果、デグレ（性能劣化・品質劣化）が起こることになります。

この記事ではデグレの意味はもちろん、以下の内容についていも解説していきます。

ソフトウェアはQCD（品質・価格・納期）が重要です。

筆者は大手SIerからベンチャーまで経験し様々な現場・開発者に接してきましたが、品質を計画的に作り込むエンジニアは少ないように感じます。

特に中小規模・ベンチャーでは場当たり的に対応しているイメージがあります。

品質が悪いと手戻りが発生し利益率も悪くなります。

負債となる開発チケットも多くなりますのでぜひ最後までお読みいただきデグレ対策を進めましょう。

デグレとは？

「デグレ」（デグレーションの略語）とは、プログラム改修に伴う性能劣化・品質劣化のことです。

開発者であれば誰もが経験しているのではないでしょうか。

パフォーマンスが劣化することもあれば、「バグが発生して品質が劣化すること」を示すこともあります。

ほとんどの場合で、変更の要求仕様は満たしたが、後続の機能(後工程業務の機能)で不具合が発生してデグレとなることが多いです。

なお、変更の要求仕様さえ満たしていない場合は、顧客からテスト不足を疑われ、品質に関する信頼を失うことになるため要注意です。

【事例】筆者が経験したデグレの事例

筆者はデグレがよく起きる事象としては以下のようなことをよく経験しました。

システムが大きくなるほど、古くなるほど考慮すべき範囲が広くなりデグレが起きやすくなる傾向です。

デグレが起きる原因は変更箇所による影響を想定できないため

デグレは、開発以降の運用フェーズにおけるシステム改修で、頻発します。

それは、開発プロジェクトの体制が縮小されるため、主要な開発メンバーがプロジェクトからはずれることから始まります。

開発メンバーの立場からすると、自担当の範囲外の機能改修とメンテナンスを任されることになるので、とっても心細いですよね。

本題の「変更箇所による影響を想定できない」ということですが、大規模プロジェクトの場合は、設計担当者とプログラム担当者は明確に役割を分けることが多いことが要因です。

プログラム担当者は設計書に基づき、コーディングします。

そのため、なぜこのようなプログラム改修をするのか理解せずに作業をしていることが多いです。

もちろん、小規模のプロジェクトであれば、設計者とプログラマがコミュニケーションをとって意思疎通を図っているという方もいるでしょうが、大規模なプロジェクトの場合は、外部設計をプロパーで行い、製造部分の内部設計からプログラムは業務委託や派遣に依頼することもありえるでしょう。

「変更箇所による影響を想定できない」のは、業務を理解して設計書を作成するSEと、業務を理解せず設計書を基にコーディングするプログラマとのコミュニケーション不足が大きな要因です。

そのため、上流工程のSEは、コミュニケーション力を問われるのです。

一度よく考えてみてほしいのですが、業務委託や派遣(もしくは、若手SE)の立場で、あいまいな記述があったからといって、何度も設計者に質問できるでしょうか？

それは、設計不足が原因ですので、設計者に「設計不足ですよ！」(設計ミスですよ)と言っていることに等しいのです。

【事例】筆者が経験したデグレの原因

私が経験したことのあるデグレの一つの事象として、レスポンス(パフォーマンス)劣化がありました。

機能改修を実施して、最新モジュールを本番運用したのち、利用者数(アクセス数)が増えてくると、機能改修した箇所のレスポンスが遅くなるという事象が発生しました。

単体で動作確認しても、再現できない現象で、調べていくとサーバ上のウィルス対策ソフトのリアルタイム保護を解除したときに、レスポンスが改善されました。

さらに、調べていくと、プログラム作成担当者がデバッグ用にログを大量に出力していたことが、真の原因であることが分かりました。

おそらく、そのログファイルをウィルス対策ソフトがチェックしていたのでしょう。

この事象では、経験の浅いプログラム担当者が、共通プログラムとして作成したLoggerクラス(ログレベル：DEBUG,INFO,WARN,ERROR,FATAL)のDEBUGを利用して出力していれば、本番環境ではINFOレベル以上しか出力しないため発生しない問題でした。

これは、プロジェクトで定めたプログラム作成規約・基準が守られず、ループ処理の中にデバッグ目的でのINFOログのプログラムが実装されており、ログファイルのサイズが肥大化していました。

本来であれば、このようなコーディングミスは、プログラムレビューで見つかるべきですが、全てのプログラムをレビューすることは現実的ではありません。

このようなケースのデグレを防ぐためには、次のような対策が有効です。

昨今であれば、開発プログラムは、バージョン管理システム「‎Git、Subversion等」で管理しているかと思います。

そのため、プロジェクトの開発リーダーが、本番環境のモジュールを作成するため、最新バージョンのソースコードを取得したときに、前回バージョンとの差分を確認していれば、今回のようなケアレスミスは、発見することができたはずです。(ただし、初期導入時は、変更もモジュールが多くなるため、この対策は現実的ではありません)

コラム：本質的にデグレを完全に防止をするのはほぼ不可能？

デグレーションは、いわゆる不具合と同じで、完全に防止することは不可能です。

多くの開発現場では、ステップ数によるバグ検出数の基準を設けて、品質を検査しています。

読者のなかには、そんなことを考えているのは、時代遅れと考えている方もいらっしゃるかと思いますが、現在も重要視されています。

それでも違うというのであれば、そのシステムは、顧客の基幹業務のシステムではないのかもしれません。

顧客は、基幹業務システムがストップすると、時間単位で損害が発生します。

顧客に安心してもらうためには、しっかりと業務を想定したテスト(例外も含む)を行い、バグを修正して欲しいのです。

証拠を示して安心させて欲しいのです。

しかし、デグレを完全に防止することは不可能ですが、できるだけ抑止することは可能です。

次では、具体的なデグレを抑止する方法を説明します。

デグレを抑止する対策方法3個

では、デグレを抑止するためには、どのような対策が必要でしょうか。

デグレは、事前対応と事後対応に分かれます。

事前対応の場合は、プロセスの見直しとテストが有効です。

また、事後対応は、徹底的な原因分析を行い、再発防止をすべきです。

次では、私の経験から、システム開発の現場で実際に実施されている対策方法を3つ説明させていただきます。

方法1：デグレが生じた真因をあぶり出し再発の対策をうつ

デグレの真の原因は何だったのでしょうか。

「なぜなぜ」で考えてみてください。

1.改修の影響範囲は正しかったのか

上流工程の外部設計で、改修機能の影響範囲を特定できていたのか検証が必要です。

この時点で、想定範囲外に影響があれば、その部分はテスト無しで本番環境にリリースしたことになります。

2.設計書は正しかったのか

開発以降の運用フェーズでのデグレーションであれば、DB出力項目やファイル出力項目の誤りなどがあります。

運用フェーズまで残っているプログラマーであれば、熟練者が多いためプログラムミスよりも、設計書の誤りの方が多いのではないでしょうか。

もしかしたら、曖昧な表現があったかもしれません。

運用フェーズのシステム改修では、小規模な改善が多く、外部設計書への記述も1行、2行程度で簡単に指示していないでしょうか。

その場合でも、しっかりと内部設計者やプログラム担当者にしっかりと仕様説明をして、考慮漏れ等がないか確認しましょう。

また、複雑なシステムともなればコードレベルで大きく影響をし合う可能性も出てきます。

とくに改修を重ねたシステムは要注意です。

仕様の隙間を狙った改修が幾度となく行われた結果、非常に改修しづらいプログラムになっているケースが多いです。

コードレベルの影響を設計書で反映するのは非常に難しく、再発防止としてはテストケースを追加するといった場当たり的な対処になりがちでしょう。

3.人為的なケアレスミスで、避けられなかったのか

開発ソースプログラムをバージョン管理システム「‎Git、Subversion等」で管理しており、開発途中のコードをアップしてしまった。もしくは、衝突したファイルをマージした際に、不具合を混入させた可能性もあります。

上記の1～3は、普通のことのようで、よく起こりえるケースです。

デグレ対策では、テスト工程よりも、積極的に上流工程に焦点を当てて、見直しを図るべきです。

開発以降の運用フェーズでは、小規模な機能改善が多いため、テスト工程は縮小される傾向があります。

リリース前のテスト項目を増やすことで対策とすることは、真因を潰すことにならず、デグレは抑止できません。

【コラム】リリース前のテスト項目が増えるだけの対策は最悪・・・

デグレが発生すると、対策としてテスト項目を増やすというプロジェクトマネージャーがいます。

真因を確認せず、とりあえずパターンを網羅するテスト項目を増やして、不具合を減らそうとするものです。

確かにテスト項目を増やせば、デグレが減る可能性もあります。

しかし、これは対策ではありません。

私が経験したことのあるテストは、テスト仕様書をマトリクス形式で作成し、入力・操作・出力結果を縦軸に並べ、横軸にテストケースのバリエーションをずらっと並べて網羅テストするものです。

このようなテストは、開発以降の運用フェーズでは実施されるべきではありません。

不必要なテストケースが混入し、テストを実施する担当者は意味の無いテストと分かっていながら作業をするため、見逃す可能性もありますし生産性もあがりません。

デグレが発生する真因を潰さず、リリース前に力ずくでテストをして防止するのは、開発現場が疲弊します。

対策がリリース前のチェックばかりになっていたらイエローカードです。

真因を潰すように考え直してみてください。

方法2：レグレッションテスト(回帰テスト)を実施する

修正を加えたら変更による不具合がないかをテストするといった方法です。

当たり前のようですが短納期であるケースや属人性が高くプロセスを大切にしていない企業では適切にテストされないケースがあります。

大手SIerでは、このようなテストも手を抜かないための見積り金額も高くなるといったことがあります。

方法3：安易にCI環境を導入せず、開発チームの規模や形態に合わせてテストを実施する

デグレ抑制のために継続的インテグレーション（CI：Continuous Integration）の導入を検討している人も多いでしょう。

継続的インテグレーションでは、常にビルドとテストを行いデグレを検知する開発方法です。

GitとSubversionでコミットをするとCIツールと呼ばれるフレームワークがバックエンドでビルドとテストコードを実行しレポートを出力します。

これによりデグレにいち早く気づけるのです。

ただし、全方位の不具合を予期してテストコードを用意するのは不可能と言って良いでしょう。

不具合はいつも「想定外」だから発生しているためです。

すべての想定外を想定するテストコードの準備には膨大な時間もかかるでしょう。

そのため、以下のような割り切ったテスト環境が必要となります。

システムの複雑度、確保すべき品質、開発メンバーのスキル・経験にあわせてバランスのよいCI環境を導入していきましょう。

まとめ

最後までお読みいただきありがとうございます。

ここまで、デグレーションが発生した後の対応について説明させていただきましたが、実はデグレーションの防止の肝は、「標準化」です。

え？これまでの説明はなんだったの？と思われた方、ごめんなさい。

「標準化」は、すべてのプロジェクト開発で効果を発揮しますが、特に、以下の項目は、最初から手を抜くべきではありません。

なぜ、「標準化」という言葉がたくさん出てくるかというと、標準化することにより、運用フェーズ以降で、メンテナンス及びシステム改修するときに、自担当以外でも標準化されているため、比較的品質を維持してプログラム改修することができます。

ぜひ、読者の皆様のプロジェクトでも、標準化に力を入れてみてください。