バグデータを活かす
●バグデータを活かす
バグの原因はプロセスにある
バグは単に“不注意”で入り込むのではありませんし、“偶然”に入り込むのでもありません。そこで行われたプロセスに“スキ”があったから入り込んだのです。その意味では“必然”であり、入るべくして入ったのです。いや、“招き入れた”のです。だからこそ、プロセスを改善してバグの発生原因から正そうとしているのです。「次は、こういうバグが発生しないように頑張ります」といっても、実際にプロセスや成果物の構成が変わらなければ、いつも同じようなバグは発生します。プロセスとしての“習慣”が変わっていないのですから当然なのです。
実際にソースコードに対するバグの発生率を取ってみると、規模の大小に関わらず個人別にはほとんど同じような発生率を示します。これは、個人の作業の習慣が変わっていないために同じようなところでバグが発生していることを意味しています。絶対件数では見えなくても、“発生率”の形に直してみると面白いほど変わらないものです。
一般に、プロセスというものは「個人の習慣」の中にあります。早い段階で仕様化せずにいきなりソースコードを書き出すのも、工数が足りなくなるという不安から中間成果物を書くことに躊躇してソースコードを書こうとするのも、そのような作業のスタイル（プロセス）を持っているからです。つまり、要求を表現するプロセスを持っていないために“周辺の仕様”やその機能が実行する時の細かな条件の仕様がが漏れるのです。
仕様化を省いてソースコードを書いているときに気付く範囲の仕様にはパターンがあります。そのシナリオの流れの中で時間的な順序関係にある仕様は気付きやすいのですが、例外的な条件は漏れる傾向があります。また、親戚関係にある機能や依存関係にある機能、排他関係にある機能に気付くプロセスを持っていないとすれば、こうした機能間の順序関係や排他関係を制御する仕様が漏れる可能性が高くなります。派生開発でも、このような機能間の関係を表わす補助成果物を持たなかったり、変更箇所を表わすマトリクスを持たなければ、関連して変更すべき箇所があることに気付かずに変更が漏れてしまいます。
このように、必要なプロセスや成果物が省かれたことで、そのプロセスや成果物に対応する欠陥が成果物（中途半端な成果物？）に入り込むのです。その多くは、中間成果物で“不足”や“間違い”として潜入し、そのことに気付かれないままソースコードに変換されるのです。したがって、適切な中間成果物（や補助成果物）が作られていない状態では、ソースコードになるまでにこのような欠陥を発見することは難しくなります。そして、このような適切な成果物やプロセスを持たない状態が変わらない以上、本人の“意志”とは関係なく、それに関連するバグも同じように発生し続けるのです。