納期を守るためにはバグはあってもいいか？

タイトルの質問、みなさんはどう考えるでしょうか。

まず考え方として、バグがないことを証明することはできない、という事実を認めることにしましょう。そうするとこの質問は、既知のバグがあっても納期を守るために出荷していいか、という質問に言い換えることができます。

ここでバグの内容が問題となります。

ケース１

　汎用システムの納入で、ユーザ側の動作仕様ではそのバグが絶対起きないケース。この場合はそもそもバグの個所が実行されることがないのでバグのあることが分かっていてもユーザ側ではバグが発生することはありません。修正を行なうと納期に間に合いません。

ケース２

　バグの内容がごく軽微で、ユーザにとってバグとは分からないケース。設計仕様書上は仕様とは異なる動作をするが、ユーザに提出した仕様書にはその点の動作には触れておらず、それがユーザにとって何ら不利益をもたらさない場合です。修正を行なうと納期に間に合いません。仕様が複雑になるとこうしたケースの生じる場合があります。

ケース３

　バグの内容は軽微だがユーザ側はバグと認識できる。バグ修正にはソフトウェア変更のリスクが大きく修正に多大な工数がかかるケース。ユーザには軽微な不利益が生じますが、バグをなくそうとすると納期が大幅に後ずれせざるを得ないケースです。

建前で考えると、納期を守るためにはバグはあってもいいとはもちろん言えませんね。でも実際のケースで考えると、そうとも言い切れない場合が往々にしてあるものです。

最初のケース１では、ユーザ側ではバグが発生することはないということがあらかじめ分かっているので、バグがあっても問題ないと言えるでしょう。

次のケース２では、ユーザ側でもバグは発生するが、ユーザ側でそれがバグと認識できないケースです。この場合、ユーザ側にとってその動作はバグとは認識されず、不利益も被らないわけですから、そのまま納入するほうが双方とも幸せになれます。

最後のケースでは問題が面倒です。ユーザ側からこれ位なら問題ないから納期通りに納入をしてほしいと言ってもらえれば一番簡単です。もし、ユーザ側が納得できない場合はバグを修正することになり、ではバグ修正版がいつまでなら納入できるか納期を巡ってユーザ側との折衝になります。折衝の結果、ユーザ側にとって納期の遅れによるデメリットが、軽微なバグ修正のメリットに比べて大きければそのまま納入し、後日バグ修正版と入れ替えるということになるかもしれません。

このように、納期を守るためにはバグはあってもいい、とは必ずしも正しいとは言えませんが、実際の場面ではそれが正しいこともよくあります。