絶対に起こしてはいけないデグレとは？

みなさん、「デグレ」という言葉は聞いたことがありませんか？

ソフトウェア業界に関りがない人にとってはあまりなじみがない言葉かもしれません。

しかし、これからソフトウェア業界に限らず、IT業界で働くと決めているなら知っておかなかければならない言葉です。

今回は、デグレの概要から起こさないための方法を紹介します。

デグレとは

デグレとは、「デグレード」の略称で新しくリリースされたソフトウェアが以前より悪くなっていることを指します。

新しくリリースした部分が既存のプログラムに悪影響を及ぼしているパターンがほとんどです。

具体的な例を挙げると、以下のような3つがあります。

このようにデグレが起きてしまうと、システムとして破綻してしまうものまで存在するので避けなければなりません。

次にデグレが起こったらどうなるのか見ていきましょう。

先ほど説明したデグレはなぜ起きるのでしょうか。

デグレが起きてしまう原因をここでは3つ紹介します。

既存のシステムに対して新規機能を追加しようとすると、多岐にわたってテストをする必要があります。

既存のシステム、新規機能、既存システムと新規機能の共通部分は必ずテストをしなければなりません。

この3つの部分でテストが不十分だと、作成した部分も含めてチェックできていない部分が存在し、それに気付くことが出来るタイミングがリリースを行ってからになります。

リリースを行ってからバグに気付いてもシステムは動いてしまっているので、最悪の場合損害賠償を払わなければなりません。

開発しているソースコードを誤って上書きしてしまうことです。

2人が同じソースコード修正しており、1人目の修正が終わったものを既存システムにマージしたとします。

もう一人の人が1人目が修正する前のものを基に改修プログラムを実装しマージしてしまうと1人目の修正したものが消えることになってしまいます。

この場合はテストで気付くことがほとんどですが、せっかく修正したものがなくなってしまうのは悲しいですよね。

新規機能の追加や既存システムの改修を行う際には必ず事前調査を行います。

事前調査を行った人が既存のシステムを全て把握していなかったり、設計書を基に調査を行ったところ設計書自体が古く最新のものになっていなかったために調査漏れが発生します。

調査している人は設計書を最新のものだと思ってやっていますし、調査をしている本人が気付くことはなかなか厳しいです。

デグレが起こる原因を紹介したので次に防ぐ方法を紹介します。

このようなことを言ってしまうと元も子もないですが、基本的にドキュメントは信用できません。

金融系やきっちりしているとこでさえ最新の設計書になっていないことや予算や工数の兼ね合いによって、設計書の修正は次に回しますなど色々な理由によって修正されていない場合があります。

しかし、ソースコードは嘘をつきません。

既存のシステムは動いているものなので、ソースコードから影響調査を行うことによってある程度防ぐことが可能です。

改修したプログラムが自分の実装した通りに動いているか、修正した箇所が影響する部分を全てテストすることです。

テストの工程は一番大事なはずですが、よく時間がないからと言って適当にやってしまう人が多くいます。

一番最悪なのは、テストしている人がバグを発見したにもかかわらず修正する時間がないからわざと見逃してしまうことです。

絶対にやってはいけないことなので、この記事を読んだ方はバグを見つけたらしっかりと申告するようにしてください。

今回は、デグレの概要から起こさないための方法を紹介しました。

IT業界では頻繁にデグレは起こっており、そのたびに損害賠償などの事例に発展してしまいます。

デグレは起こってはならないものなので十分に注意して作業を行いましょう。