絶対に起こしてはいけないデグレード

「デグレード」という言葉はソフトウェア業界に関わりがない人にとってあまりなじみがない言葉だろう。しかし、ソフトウェア開発やテストをする人間にとって「デグレード」は恐怖であり、絶対に起こしていけないものなのである。

ソフトウェア業界にとって「デグレード」とはどのようなものなのだろうか。

デグレードとは

デグレードについてIT用語辞典というサイトで下記のように説明されている。
デグレード【degrade】デグレ/リグレッション/ regression /先祖返り/リグレ
デグレードとは、新しいバージョンのソフトウェアの品質が、以前より悪くなること。また、以前修正した不具合やバグが再発・復活すること。また、新しいファイルなどを古い内容で上書きしてしまい、更新内容が失われること。

出典: IT用語辞典e-Words

つまり、ソフトウェアを更新したにもかかわらず、何らかの原因で以前は正常に動いていた機能にバクや不具合が生じて、品質が悪くなってしまうことをデグレードと呼ぶ。ちなみにこの事象を英語では本来リグレッション(Regression)と言うのだが、なぜか日本では「デグレード」で定着してしまった。そのため、日本のソフトウェア業界でしか通じない業界用語と化している。

デグレードを絶対に起こしたくない理由

ソフトウェア開発に於いてバグはつきものであり、バグのないソフトウェアなどありえない。しかしその中でも、特に大きな問題になるのがデグレードである。なぜなのだろうか。

1. これまで正常に動いていたプログラムの不具合は利用者側の心証が悪い

ソフトウェアの更新は以前のバージョンよりも性能や機能がよくなることを期待される。しかし、更新後にデグレードが見つかってしまうと、利用者側の期待や信用を裏切ることになってしまう。既に利用者が使用しているシステムであれば、その作業にも支障が出てしまう可能性があるため、必ずテスト段階でデグレードを発見し修正しなければならない。

2.デグレードの発見にはコストがかかる

デグレードを全て見つけ出そうとするのであれば、どこで発生しているのかわからないため全機能に対して回帰テスト(リグレッションテスト、退行テストとも言う)を実施しなければならない。ソフトウェアの規模が大きくなればなるほど、多大なコスト、時間、労力を要する。これが一度だけでなく、ソフトウェア更新のたびに実施しなければならないため、QCD (品質・コスト・納期)のバランスが難しくなっている。つまり完全網羅が不可能な以上、適切な密度でテストを実施するほかなく、それでいて予算や残期間との兼ね合いで十分なテストを実施できるとは限らないからである。

デクレードの原因

デグレードは当然ソフトウェアの更新、変更によって発生する。もちろん、毎回起きるわけではないので、発生した原因を考えると、主に以下のような理由が挙げられる。

1.新たに追加された機能のテストやデバッグが不十分でバグや不具合が多い

新規機能がソフトウェアに与える影響は大きく、そのため十分な量と密度のテストを実施しなければならない。しかしテストが不十分であれば、デバッグされることなくバグが残ってしまう。テスト後にバグが発見されると修正に多大な工数がかかってしまう。

2.バージョン管理に失敗してバグ修正前の古いソースコードやドキュメントを開発時に使用してしまった

開発者側の運用ミスが原因によるもの。開発時に間違えて古いソースコードを使えば、過去の修正がなかったことになってしまう。開発チームまた個人の両方がコードの管理を徹底していなかったがために起こってしまう事象である。また仕様書などのドキュメントの取り違えなどによって起こる認識の齟齬、ドキュメント更新の連携漏れもデグレードを引き起こす原因の一つである。

3.ある機能に対する修正が別の機能に悪影響を与えている

バグのないプログラムはないため、常に修正は行われている。その中で、あるバグに対する修正がほかの機能に不具合を起こしてしまうことがある。修正時にはそのバグが修正されたのかどうかのみを確認するため、他の機能に及ぼしている悪影響を見つけるのは難しい。

デグレードの発生原因は単純なミスばかりではない。そのため、ソフトウェア更新のための開発やテストには細心の注意を払う必要があるのだ。

厄介なデグレードの対策とは

ここまでデグレードとはどういうものか、どうして厄介なのかを説明してきたが、それではどのように対策をすればよいだろうか。

ここでデグレードに対して「予防」と「検出」の二つの観点で考えてみる。

デグレードを予防

管理ミスによるデグレードの発生は事前に管理体制を整えることで未然に防ぐことが可能である。こうした管理体制の改善が一番のコスト削減につながるのである。

・新機能の情報共有を開発チーム全体で行う

ソフトウェアの規模が大きくなればなるほど開発チームが機能ごとに分かれるなど細分化されることが多い。そのため、自分の所属するチーム以外の機能について疎くなってしまいがちである。開発者がすべての機能について詳細に把握することは難しいので、新たに開発する機能をどのように設計するか管理者同士が情報共有することで、他の機能への影響を把握することができる。これはデグレード発見時の原因究明のスヒードアップにもつながるだろう。

・ソースコードの管理者やライブラリの管理者を置き管理ルールを徹底する

開発者間でルールが共有されていたとしても、それを管理、チェックする人間がいなければいつしかゆるみが出てきてミスが生まれてしまう。誤ったソースコードを選ばないようにフォルダ分けやファイル名のルールが正しく実施されているかを定期的にチェックすることが必要である。またソースコードをロックして修正が必要なファイルのみに使用許可を出すような仕組みも一つの案である。

デグレードを検出

上記の予防策を実施しても、予期しないところでデグレードは発生してしまうものである。そこでソフトウェアのリリースまでの限られた期間でもデグレードを発見できるような施策をとらなければならない。

・回帰テストの項目に優先度を付ける

これまでにも書いたように、デグレードを全件発見しようと思えば、回帰テストを全機能に対して実施しなければならない。しかし、納期、費用は限られているため単純な全件実施は難しい。そのためテスト項目に優先度を設定し、優先度の高い機能は入念に、低い機能は必要なところだけを確認すればよい。これによって少なくとも、リリース後に作業ができなくなるといった事態は防ぐことができる。また変更を加えたことによって影響がでそうな機能についても優先度を高くしたほうがよいだろう。これも開発チームで情報共有を行って見当違いなことにならないように正しく見積もる必要がある。

・回帰テストを自動テストで実施する

基本的に回帰テストで実施する項目の内容に大きな変更が加わることは少ない。複数回同じテストを実施するのであれば自動テストが向いている。自動化できそうなテストケースは自動化して、テストの工数を下げるべきである。もし継続して更新が必要なソフトウェアだとわかっているならば、自動テストの経験があるエンジニアとテストツールを準備することで滞りなく進めることができるだろう。テスト期間中で準備もなくいきなり自動化をするというのは不可能に近い上に失敗した際のリスクが大きすぎる。

まとめ

デグレードはソフトウェアが大規模化すればするほど発生しやすく、見落としてしまいがちである。ソフトウェアの品質を保つためには、相応の準備や対策が必要となるのである。もしソフトウェア開発の現場でデグレードに対して上記のような対策ができていないのであれば、すぐにでも対策をとる必要があるだろう。顧客から失った信頼は簡単には取り戻せないのだから。