チェック表を利用してバグの優先順位を決める

バグが発生したらチェック表の各項目の優先度を判定し、優先順位を決定する。

今回は「バグA：FireFoxでは各画面右上の『ログアウト』リンクが表示されない」と、「バグB：マスタデータメンテナンス画面（年に1度利用）で、『〜』文字が文字化けして登録される」を例に解説していこう。

まずそれぞれをチェック表にあてはめる。バグAは、「影響範囲：低」「データ更新の有無：低」「発生頻度：高」「関連するバグの数：低」となる。バグBは、「影響範囲：低」「データ更新の有無：中」「発生頻度：低」「関連するバグの数：低」となる。

そして、判定した優先度の中でもっとも高いものをそのバグの優先度とする。バグAは「影響範囲」と「発生頻度」が「高」なので優先度は「高」となる。バグBは「データ更新の有無」が「中」なので、優先度は「中」となる。この例ではバグAが優先順位が「高」となる。

優先順位が同じ場合

もし、同じレベルの優先順位のバグがあった場合には、優先度「高」の数で判断する。それも同じであれば、優先度「中」の数で優先順位を決める。

ではバグCとして「影響範囲：高」「データ更新の有無：低」「発生頻度：高」「関連するバグの数：中」を例にみていこう。このバグCも優先順位は「高」となる。しかし、優先度「高」の数がバグAに比べて多いので、優先順位はバグCの方が高くなる。

バグのレベルを判定する際、このように優先順位を決めると判断に悩む時間が少なくなるだろう。何を優先して修正するかはプロジェクトごとに異なるため、このチェック表をベースにして独自の表を拡張して作成してもよい。注意点として、あまりに細かく優先順位を決めることに執着しても効率が悪くなるので、優先順位をざっくり決める客観的基準と考えるのがよいだろう。

また運用のポイントとして、このチェック表を印刷して見えるところに貼っておくことで必要なときにさっと確認できて便利である。

バグの優先順位付けの例外

最後にチェック表が適用されない例外について解説する。このようなケースでは柔軟に優先順位を変更することをお勧めする。

同じソースを修正する

これはバグAとバグBで、同じソースファイルを修正する必要がある場合だ。ソース管理にSVNやCVSなどのソース管理ツールを利用している場合はあまり意識しなくてもよいかもしれないが、ソースの修正箇所が衝突した際はマージ作業にことのほか手間取る可能性がある。

特に、修正範囲が大きい場合には、同じ担当者に修正を依頼するか、別の担当者に修正のタイミングを少しずらして割り振るとよいだろう。

顧客からの要望がある

業務に精通しているとはいえ、常に開発現場が想定している利用法をユーザが行っているとは限らない。

自分で優先順位が低いと判断しても、顧客から至急修正してほしいと頼まれた場合は、無下に断ったり無条件で引き受けるのではなく、優先順位を上げる必要がある理由を聞いたほうがよい。

その理由が納得できる内容であれば速やかに優先順位を高くしよう。逆に、優先順位を高くする必要性がないと思った場合は、その旨を顧客に伝え、残存バグの中での優先順位を顧客と検討することも重要である。

どの類のバグを優先して修正するかについて、関係者の中で共通認識がないと現場に混乱が生じる危険性があるので、優先順位を変更する際は注意が必要だ。

次回は

今回は、バグの優先順位を決める方法について解説した。次回は、バグ管理を行う中で陥りやすいミスなどを、実例を出しながら解説していこう。 タイトルへ戻る