IGINブルネイ/syasudaの日記(MT版)

バグは計画して取り除くことができないと書きました。

これは、ある程度のレベルに達した製造業の生産ラインにおける不良発生率と似た現象と捉えることができます。あるいは、機械の故障発生率と似ているかもしれません。ただし、工業でなくて工芸であれば、通用しません。１発勝負についても考えません。

故障や不良は確率的に発生します。生産ラインや機械の調整パラメータを操作し、制御することができます。

調整パラメータは、手をかけたり、測定したり、で結局はコストをかけることになります。つまりトレードオフにもっていけるわけです。

このときの係数(かけたコストと品質の向上の比)が低ければ、商売として成り立ちませんね。

中規模以上のソフトウェアであれば、全体として、バグの発生は確率的です。それはたとえば、C言語のソース1000行あたり4件とか、Javaのソース1000行あたり10件のように測定されます。

製造業にちょっとでも足を突っ込んだ人間なら、知っていることですが、平均や中央値だけを見てはいけません。バラツキや分布を見なければなりません。汚くなろうが、全データをプロットして分布図を見なければなりません。グループごとの平均値を綺麗にプロットしたグラフには何の価値もありません。

数十万行のソース全体の３ヶ月あたりのバグ検出件数の平均を見て、競合他社と比較してだいたいレンジが同じだったら安心してしまうところに、統計というものの恐ろしさがあります。

はっきりいって、１０００行あたりのバグ発生確率なんて、どうでもいいです。窓から放り投げてしまってもいいくらいです。問題はバラツキです。ばらつきを抑えることができなければ、投下コストに比例した効果を得られませんから。

ばらつきのとり方はいろいろあります。チームやグループごとのばらつき、時期によるばらつき、言語によるばらつき。平均はどうでもいいです。しつこいですが。

とにかく、計画して取り除けないからといって、放置するのは阿呆のやることです。日々改善です。測定して、フィードバックする。基本です。計画して、実施して、測定して、チェックする。サルでもできます。このときの計画にはバグ取りは含めません。含めたって、バグは除去できませんから。

バグを出すな、という掛け声ややたら回数の多い、重箱の隅をつつくような設計検討会を繰り返したって、バグは減りません。バグを取り除くことができるのは実装の修正作業のみだからです。あらかじめ洗い出せるバグはバグではありません。ただの漏れです。細かい漏れを塞いでも、トンネル効果でバグは何もない空間からにじみ出てくるのです。

バグがなくならないのは、検討不足のせいでも、作業者のスキル不足のせいでもありません。ここに書いたバグの仕組みを理解しないこと、そしてまた客観的にバグ件数をカウントして、高校生でもできる統計処理すらおこなわないことが原因なのです。

というようなことが丁寧に説明してある本があったのですが、たんすの奥から出てきません。困りました。