ソフトウェア開発を経験した人ならば、いつまでたってもバグがなくならないという経験をした人も多いと思います。
ひとつのバグをつぶしている間に、隠れていた別のバグが見つかったりします。あるバグを修正すると、別の場所に影響を与えて新しいバグを生み出すこともあります。
これが、ソフトウェアエンジニアの深夜残業、休日出勤の増加につながっています。
ソフトウェアの基本構造が悪いと顕著です。シンプルな構造で一から作り直した方が早い場合もあります。
しかし、ソフトウェアの仕様が完全にドキュメント化されていない場合には、作り直すこともできません。
残っていたバグが仕様として利用者に理解され、運用に影響を与えていることもあります。すなわち、バグを修正すると運用に影響を与えるため、利用者に受け入れられないということが起こりえます。
ソフトウェア開発では、バグをなくすことは不可能ということが、一部では受け入れられています。Windows 10もmacOSもiOSもAndroidも、誰もバグがないなどと思っていません。実用上差支えない程度にバグがなくなっていればいいと考えられています。
ソフトウェア開発でバグをなくすことが不可能なのは、ソフトウェアは人間にとって複雑すぎるからです。
バグをなくすことは不可能だと開き直れば、優先順位をつけて対応するしかありません。
災害時医療におけるトリアージと同じです。負傷者を重症度、緊急度などによって分類し、治療や搬送の優先順位を決めています。
バグも優先順位をつけ、重大なバグがなくなった段階で出荷するという考えです。大切なことは、バグをゼロにすることではなく、重大なバグを残さないことです。
ソフトウェア開発の経験のない人には、理解できないことかもしれません。
不具合はゼロにして出荷することが当たり前で、不具合が残っていることが明らかな製品を出荷することはできないと考えます。
そこを理解させることは非常に困難です。ソフトウェア開発の経験がない人が会社のトップでは認められません。
ソフトウェア開発の経験のある人が会社のトップになって、はじめて認められることです。日本のソフトウェア開発が米国に大きく遅れた原因のひとつです。
管理者がやるべきことは、重大なバグとして何が残っていて、どのように、いつまでになくせるかを判断して、ソフトウェアの出荷を決めることです。決してバグをゼロにしろとソフトウェアエンジニアにハッパをかけることではありません。
ソフトウェアのテスト仕様書には、最低限満たすべき条件を記載し、テスト仕様書に記載のない項目に関するバグは後回しにするということがひとつの考えです。
そうは言っても、テスト仕様書に致命的なミスがある可能性が残ることが、人間の限界なのかもしれません。
