1ヶ月も空いてしまいましたが、今回はソフトウエア開発の中でもかなり肝になること、「バグを計画する」というテーマで書きます。

そもそも一般的には「ソフトウエアバグ」というものは悪いイメージを持つ方が多く、”そんなもの無い方が良い”、”なんでゼロにできないの？”、という声をよく聞きます。

おっしゃる通り、無い方が良いし、ゼロにできたらこんな楽なものはない、のです。
がしかし、開発中のプロセスではこの議論は全くナンセンスで、開発中にバグが全く出ないということはあり得ません。
プログラミングしてみて、→動かしてみて、→想定通り動かない、→修正する、のが当たり前です。

であるならば、逆に「開発成果物」と捉えて、その発生件数を計画するという発想です。
★時系列で何件ぐらい発生する（発見する）べきか
という計画を作ります。

一般的にバグの発生件数は信頼度成長曲線（時間が経てば経つほど発生件数が減っていく）になります。
開発末期になると発生件数が減っていくという意味です。

テスト工程を見てみると、
・単体テスト
・結合テスト
・システムテスト
・運用テスト
という順番で徐々にテストが細部から全体へと進みますが、バグの発生件数は徐々に減っていきます。
分かり易くするために、仮の数値を入れてみます。
①単体テスト：　200件
②結合テスト：　100件
③システムテスト：　50件
④運用テスト：　10件
全体は360件出ると計画します。

これに対して単体テストフェーズが終了時点で、例えば100件しか出ていなかったらどのように考察するべきでしょうか？
これには大きく2つの考え方があると思います。

①ソフトウエアの品質が良いと判断する
これは全体で360件という計画に自信がない場合です。

②何らかの原因でとても進捗が悪いと判断する
これは全体で360件という計画に自信がある場合です。

さて、皆さんの現場ではいかがでしょうか？
私の場合は確実に②の判断でした。
それだけ計画に自信が持てるようにプロジェクトを何度も回してナレッジを蓄積してきたので、大きく外れないという実績がありました。

となると、バグ発生の計画と実績が、「進捗を判断するのに使える」、となるわけです。
しかもこの判断は、進捗管理の目的で書きました、
早期発見→早期治療
にもってこいなわけです。

次回はバグの発生件数とコストの関係を書こうと思います。