SDLCの工程ごとのバグ修正コストは？

ソフトウェアのバグをなくし、信頼性を高めるには、ソフトウェア開発ライフサイクル（SDLC）の明確な定義が不可欠です。シノプシスでは、手間とコストを削減するにはSDLCの早期でのバグ修正が重要であることを折に触れてお伝えしています。では、実際に、SDLCの工程によってバグ修正コストはどの程度異なるのでしょうか。この投稿では、ソフトウェアライフサイクルの各段階で発生し得るバグ修正コストに焦点を当ててこの問題を検討していきます。

予防は治療にまさる

SDLCで生じるバグやセキュリティの問題には、この有名なことわざがまさしく当てはまります。開発工程のなるべく早い段階でバグを修正する方が、後から修正する場合よりコストパフォーマンスが高く、効率的です。SDLCの工程が進むにつれ、コストは飛躍的に増大します。

その一例として、バグ修正を実装段階で行うと、そのコストは設計段階で修正した場合の約6倍に上るというIBM Systems Sciences Instituteの報告があります。また、IBMによると、テスト工程でバグが発見されると設計段階の15倍のコストがかかる可能性があります。

製品が開発ライフサイクルの終わりに近づくほど問題の修正が困難になるため、この分析結果はほとんどの場合に当てはまります。設計工程で生じたバグに開発の早期段階で対処しなければ、影響が深刻化し、問題が複雑化して解決が難しくなる可能性があるため、コストは増大します。バグ修正のための変更がアプリケーションの機能に影響することもあります。その結果、コードベースの変更を取り消すために開発者の手間が増え、最終的なコスト、時間、労力が増加する可能性があります。

たとえば、金融アプリケーションで、アプリケーションのリリース後にセキュリティの欠陥が発見されたとしましょう。大勢の人が利用する製品であるため、バグによって発生した問題の解決に多大な費用がかかる可能性があります。そうなれば、銀行は製品の開発工程の早い段階でバグを修正した場合と比べてはるかに多大な、問題解決のための労力、時間、コストの負担を強いられます。また、本番環境での変更の実装は複雑であることから、後工程での保守に伴って全体的なコストはさらに増大します。

バグ修正コストの実例

本番稼働に入ってからアプリケーションのバグが見つかった実例として、サムスンGalaxy Note7の大失態が挙げられます。Note 7で発生した問題はバッテリ管理システムが一因になっているという憶測がありました。電流を監視し、バッテリがフル充電になったところで充電を中止するシステムになっていましたが、このシステムに障害があると過充電が生じ、バッテリが不安定になって発火する可能性があります。

この故障によりサムスンはおよそ170億ドルを払うことになりました。早期段階でこの不具合に気付いていれば、サムスンは多額の費用、苦難、評判の低下から救われていたでしょう。