誰もが陥る初歩的なワナ

本連載ではバグ管理の手法や流れについて解説してきた。最終回の今回は、バグ管理で陥りやすいワナについて実例をもとにみていこう。

毎日残業〜入り口制御ができない

「A氏は人当たりがよく、頼まれごとをついつい聞いてしまう性格だ。プロジェクトはそれほど厳しいスケジュールではないのだが、毎日残業が続いている。話を聞いてみると、顧客の担当者から直接アプリケーションの修正依頼が投げられており、A氏はついつい引き受けてしまっていた」

この例は「第2回：紙か？ Wordか？ Excelか？ BTSか？」で解説した「入り口制御ができずバグ管理ができていない状態」である。プロジェクトメンバー間のコミュニケーションが不足していると「いつの間にか」修正を引き受けている状態になりやすい。

このような状態にならないようにバグ管理者は気をつける必要がある。また、プロジェクトメンバーや顧客担当者もプロジェクトのルールとしてしっかりと認識しておかなければならない。そうしないと効率的なバグ管理が行えなくなってしまう例である。

バグ連鎖〜バグ修正がバグを生む

「バグ票の内容を確認し、あるフラグに原因があると気づいたB氏は、影響範囲を考えないままフラグの値を逆にしてしまった。その修正により、それまで動いていた別の機能が動かなくなってしまった」

「不等号の向きが逆であった」「判定するフラグの値が異なっていた」など、修正内容が簡単であればあるほど、慎重になる必要がある。修正者だけでなく、バグ管理者もそのバグの修正がどの機能に影響を与えるのかを確認しておくことが重要だ。

最近の開発ツールは、そのロジックを利用している機能の洗い出しはやりやすくなっているが、登録済みのデータの修正が必要な場合は慎重に行うべきだ。データ修正の際には、そのデータを参照している箇所の洗い出しと修正の有無のチェックなど、影響範囲を十分確認しておく必要がある。

仕様の確認〜バグではなかった

「C氏はシステムの利用者から『ここのチェックボックスで、この値を選択したときに、ここにラジオボタンが表示されないんですよ』と、バグ報告を受けた。ユーザがそう言うのであればと、動作の正当性や過去のドキュメントをチェックをせずに、修正をほどこしたが、実は当初の動きが正しくユーザが仕様を誤解していた」

「システム利用者が言うのであれば」と何も考えることなく指摘事項に対して素直に対応していると、このような事態が発生してしまう。過去のやり取り（メールやFAXなど）やドキュメントの確認はもちろんのこと、ユーザが指摘している内容は仕様として本当に正しいのかを常に確認する必要がある。 次のページ