こんにちは、トミセン(@tomisenblog)です。
「デグレ」って言葉知っていますか？
この言葉は、技術者として絶対知っていなければいけない言葉です。
なぜなら、これを起こすと技術者としての評価を大きく下げることになるからです。
いったい、なぜそうなるのか？
そこで今回は、プログラマーなら知っておかなければいけない「デグレ」の意味と、起こしてはいけない理由を解説していきます。
デグレとは何か？
デグレとは、「新しくリリースされたシステム（＝ソフトウェア）の品質が、以前より悪くなること」です。
つまり、「できていたことが、できなくなること」を言います。
そして多くの場合、新しくリリースしたシステムの直した箇所とは違う箇所で問題が起きることを指します。
同じ意味で使われる言葉に以下のようなものがあります。
同じ意味で使われる言葉
- デグレード【degrade】
- デグレーション 【degradation】
- リグレッション【regression】
英語で言うと「リグレッション」が正しいようですが、日本では「デグレ」が一般的になってしまったようです。
やってはいけない理由が想像ついてきますよね？
次では、デグレを起こしてはいけない理由を見ていきましょう。
デグレが発生すると、まぜまずいのか？
何度も言ってしまいますがデグレは本当にまずいです。エンジニアとして起こしてはいけない不具合の第一位です。
そんなデグレを起こしてしまうとどうなるのか？
本当は思い出したくもないですが、皆さんのためにご紹介していきましょう。
顧客からの信用がなくなる
圧倒的に顧客からの信用がなくなります。
できていたことができなくなるわけですから、顧客にも目に見えて分かるからです。
例えばこんな感じです。
↓
いままで使えていた機能が使えなくなる
↓
リリースされたシステムに問題があったのでは？
クライアントはその機能がいままで使えたことを知っていますから、使えなくなれば100％気づきます。
そしてそれが新しいバージョンで直した箇所じゃないところで起きるわけですから、「どうなっているの？」となるわけです。
いわば「水道が止まらなくて修理屋を呼んだら、水は止まったけど水道が出なくなった。」みたいな話しなわけですから、
「いやいや、それじゃ意味ないでしょ」
「プロなんだから、そこも考えて直してよ」
って、なりますよね？
直した箇所にミスがあるのはまだ許せても、それ以外のところを壊したら「他を依頼したら、また何か壊されるかも？」と思われてしまいます。
つまり、顧客にプロ失格の烙印を押されてしまいます。
だからデグレは起こしてはいけないのです。
後始末に本来必要なかった作業が発生する
もう1つ大変なことが起きます。後始末が必要になるということです。
本来は起きるはずのない不具合ですから、説明資料作成を求められたり、デグレが起きた箇所を含めた再テストを求められます。
一度デグレが発生した以上、中途半端な調査やテストでは済まされませんからお客様が納得するまで対応が必要になります。それらは想定していなかった工数やコストとなってきます。
そして、本来不要な工数をかけた結果、スケジュールの遅延や予算オーバーになる可能性が高いでしょう。さらには本来開発すべきシステムに手が回らずにリリースができないということにもなりかねません。
もしそんな事態になったら、最悪は契約違反とされて、損害賠償に発展するかもしれません。
デグレの具体的な例は？
デグレは起こしてはいけないことはわかっていただけたと思います。起こさないためには起きやすいポイントを理解しておかなければいけません。
そこで、どういうところでデグレが起きやすいのか具体的な例を見ていきましょう。
プログラム修正によるデグレ
まずは、プログラム修正により他のプログラムに影響を与えてしまうデグレです。
例えば、画面ロジック → 共通ロジック → ＳＱＬなどデータ取得部分などのように奥に行けば行くほどロジックが共有され呼び出し箇所が増えていきます。
自身の修正したい箇所だけを考えて修正してしまうことで、他の箇所に影響してしまい動かなくなったり、想定外の動きをしてしまいます。
管理のミスによるデグレ
そして次のデグレは、開発しているソースコードを誤って上書きしてしまうことにより発生するデグレです。
開発の現場でＡ君と、Ｂ君が同じソースを修正しています。Ａ君が修正したソースをＢ君が更新した時、Ａ君の修正をＢ君が自分の修正で上書きしてしまいました。Ａ君はテストが終わっているのでもうソースを見ることはありません。Ｂ君はＡ君の修正をちゃんと反映していると思っているので気にすることもありません。
通常はリリースの前にいくつかあるテストの中で確認ができるべきですが、そのテストで想定していないケースだったりすると問題が発見されないままリリースとなってしまうことがあります。
デグレを起こさないためには？
デグレが発生する原因、発生する例を見てきました。
それでは、実際にデグレを起こさないようにする対策を見ていきましょう。
調査を徹底すること
デグレを防ぐための1つ目の方法は、調査を徹底することです。
修正箇所が網羅されていれば対応が漏れるはずはありません。
「大丈夫だろう」という感覚で修正するのではなく、「問題があるかもしれしない」という意識で問題を漏れなく調査するようにします。
実際のコーディングのシーンでは、コンパイルエラーになる箇所は問題ないですが、コンパイルに引っかからない箇所を注意するようにします。
Visual Studioなら、CodeLens（＝呼び出し元を表示する機能）や「呼び出し階層の表示」で確認ができます。
修正する前に使用されている箇所を漏れなく確認してください。
技術者あるあるでいうと、リフレクションを使用している箇所やdynamicなどを使用している箇所はコンパイルエラーにならないので注意が必要です。
dll参照をしているところなども同様に漏れやすいです。
デグレを防ぐためには、なるべくコンパイルエラーになる作りにしてあげることが理想です。そういうコーディングができるとデグレが起きにくくなるので、意識して欲しいポイントです。
コンパイルエラーになるコーディングの例は「C# nameofの使い方は？」の記事をどうぞ。
修正後のリグレッションテストをきちんとすること
2つ目の方法は、修正後のリグレッションテストをきちんとすることです。
リグレッションテストは「回帰テスト」「退行テスト」とも言いますが、予想外のところを壊していないかという確認を行うテストです。
具体的には、目的の修正が思った通りに動くテストをすることはもちろん、修正したことによる影響範囲をすべてテストすることによって、今回の修正が他の箇所に影響を与えていないか確認します。
「そんな時間ないよ」といって、この数時間のテストを削ってしまうと、先ほど出てきたような後始末に何日もとられることになるので決して削らないようにしてください。
まとめ
デグレの意味と起こしてはいけない理由を見てきました。
デグレは技術者として起こしてはいけないものです。
原因と対策を理解して、デグレを起こさないようにしましょう！
それでは、また。
こちらの記事も読まれています！
」…39歳まで転職保証されるスクール！「TechAcademy Pro
」…現役が講師のコスパ最強オンラインスクール！「DMM WEBCAMP COMMIT
」…給付金の対象講座もある実力派スクール！