ソフトウェア開発にデグレードは付き物です。
ソフトウェア開発経験が長ければ長いほどデグレードを発生させてしまったことがあるのではないでしょうか？
本記事ではデグレードが発生してしまったその後、どのように対応していけば良いかを記載します。
#デグレードとは
客先リリース後にソフトウェアの変更を行い、修正モジュールをリリースする際に
対応による影響範囲から外れたところに思わぬ影響があり、
結果、新たに不具合があるままのソフトウェアをリリースしてしまうこと。
例えば・・・・
「昨日までは動いてたけど、リリース後に動かなくなった」
「iPhoneのアプリをアップデートしたら起動しなくなった」
#なぜデグレードすると怒られるのか
お客さんからすればソフトウェアの構成などは知らぬ話。
例えば、ベンツSクラスを点検に出して、返ってきた車がAクラスに変わってたら・・・？
一方、ソフトウェア技術者的には「すぐ直る」話なので深刻に考えない。
両者のギャップが怒りに繋がる。
#なぜグレードが起こるのか
- プログラムが密に構成されていて、再利用部分が多岐に渡っている。結果、プログラムの修正の際に影響範囲を特定しきれず、意図しない変更部分が発生する。
- ソース管理が不十分であり、他者が行った修正を上書きしてしまった。
- リリースの管理が不十分であり、リリースすべきモジュールがリリースされなかった。
- 利用しているモジュールのアップグレードによる仕様変更で、自開発のモジュールが正常に動かなくなった。
- 利用している計算機資源の設定変更により、自開発のモジュールが正常に動かなくなった。
#デグレードが発生した場合にすべき対応
以下の順で対応を行う。
- 問題が発覚した部分を早急に修正する
- お客さんに報告の上、暫定リリースを行う。
- 問題が発覚した部分の原因を調べる（＝ここで初めてデグレードだとわかる状態）
- デグレード原因となった変更に関連する部分のテストを早急に行う
- 追加で修正が必要であれば修正を行う。
- 追加対応分についてお客さんと協議を行う。（次回リリースで修正か、早急に修正するか決める）
- お客さんに正式報告と謝罪を行う。
- 損害賠償等があれば対応を行う。
- デグレードが発生した時に気がつける仕組みを作る（テストコード作成の強化など）
- デグレードが発生した時に気がつけるルールを作る
#デグレードを発生させない対処法
####プログラムが密に構成されていて、再利用部分が多岐に渡っている。結果プログラムの修正の際に影響範囲を特定しきれず、意図しない変更部分が発生する。
- テストコードを作成する。テスト密度を高くする。
- コミット前にリグレッションテストをする。
- 密になりすぎていて弊害がある場合は疎にする。ただしこの変更で新たなデグレードが発生しないように十分考慮する。
ソース管理が不十分であり、他者が行った修正を上書きしてしまった。
- gitを使う。衝突時のルールを決めておく。
- コミット時の差分チェックを行う。
- マージ時の差分チェックを行う。
リリースの管理が不十分であり、リリースすべきモジュールがリリースされなかった。
- 個別の環境でビルドしているケースがないか確認する。ビルド専用環境を作成する
- リリース手順を確立する。
- 作成したモジュールに対してリグレッションテストを行う
利用しているモジュールのアップグレードによる仕様変更で、自開発のモジュールが正常に動かなくなった。
- 設計段階から使用するモジュールのバージョンを固定しておく。必要のないアップグレードはダウングレードを行う。
- アップグレードが必要なモジュールの場合、検証環境を用いて全件再テスト（単体、結合テスト）を行い、その後本番環境へ適応する。
- アップグレードが必要ないモジュールの場合、アップグレードを行わない。
利用している計算機資源の設定変更により、自開発のモジュールが正常に動かなくなった。
- 計算機資源の設定ファイルに依存するプログラムを作成しない。
- 計算機資源の設定ファイルを変更した場合、関連するモジュールの動作確認テストを行う。
- 計算機資源の設定ファイルを元に戻す。