【QA】滅多に発生しない大きなバグと、頻繁に発生する小さなバグの話
リスクマネジメントについての記事を読みました。
稀な危機 vs ありふれた失敗－リスク対策の優先順位を考える - タイム・コンサルタントの日誌から
以下引用。
稀な危機と、ありふれた失敗。リスク・マネジメントではどちらを注視すべきか
標準的なリスク・マネジメントの進め方では、リスクの大小を、
（与えるインパクトの大きさ）×（発生する頻度）
のかけ算で整理する。
ありふれたトラブルの方が、稀な危機に比べて過去に学ぶ作業のコスト・パフォーマンスが高いのである。
飛行機で移動するとき、注意すべきなのは墜落事故ではなく、ありふれた遅延なのである。
トラブル事象が小さい内は、Resistance（事前対策）の方が費用が小さくすむが、あまりに大きな「想定外」のトラブル事象に対しては、もうRecovery（事後対策）を考える方が経済的である。
いろいろと引用しましたが、簡単にまとめますと、
滅多に発生しない危険に対してコストかけまくって予防するより、
頻繁に起こる小さなリスクを予防する方がコスパいいよ！
ってことです。
見た目が派手だからって地震やテロ対策ばっかり優先してたら足元すくわれるぞ。的な。
で、これって経営の話だけじゃなくて、
もっと身近な、例えばバグ修正の優先順位付けなんかにも使えるなぁと思いまして、
ブログにメモっておくことにしました。
つまり、1年に1回だけ問題が発生する大きなバグと、毎週問題が発生する軽微なバグがある時、
製品を評価する側なんかは特に、
「こんな大きなバグをほっといて小さなバグから手をつけるなんて有り得ない！」
的な考えになるかもしれませんが、
ちゃんと考えてみると、小さいバグから直す方が正しいことだって多いのですよ、ってこと。
（与えるインパクトの大きさ）×（発生する頻度）
「与えるインパクトの大きさ」をそれが発生した時にリカバリーにかかる工数とした場合、
大きなバグが小さなバグと比較して、50倍以上のリカバリー工数がかかるような時に初めて、
開発者ならびに評価者は大きなバグから手をつけることが正しくなります。
小さなバグへのリカバリーが1時間で終わるとしたら、その50倍は50時間≒5人日（1週間）。
つまり大きなバグへのリカバリー工数が1週間を超えるだろうなという場合以外は、
小さいバグから直すべきということになりますね*1。
以上、バグ修正についても、
パッと見で明らかにおかしな挙動や、データ復旧に3日かかるようなバグを優先したくなるのはわかりますが、
優先度はインパクトの大きさだけでなく、その発生頻度も考慮して決めなきゃ駄目ですよ、という話でした。
終わり。
