「困った」バグレポートの数々から得た「正しい」レポートのための教訓とは

説明が不十分

再現方法や期待する動作との違いの説明が不十分で、何が問題かがわからないバグレポートです。後で述べる「バグとは関係のないことが書かれている」パターンと組合せとなっていることが多く、それなりの記述量がありながら、バグ修正に必要な肝心な内容が書かれていないということがあります。

説明が不十分なバグレポートの例を見ていきましょう。

「A画面が表示されない」（再現の方法や条件が書かれていない）

「画面Xに入力値tを与えると期待通りの動作になりません。直してください」（期待通りの動作として何を想定しているのかわからない）

「サブシステムYとの連携について、設計レビューでの検討結果を反映していない」（設計レビューでどのような検討がされ、どうなるべきかが書かれていない）

いかがでしょう。心当たりはありましたか？バグレポートを書き終えたら、プログラマがレポートだけでバグを再現でき、修正の糸口を得られるかを再度確認しましょう。それだけで初歩的なミスは防げます。バグレポートを書いてから日を変える等、少し時間を置くだけで客観的に読むことができます。時間がなければ、印刷して紙面で読む、PDFに変換して読む、エディタにペーストしてフォントを変えて読む等、少しの工夫で客観的に読めるようになります。

モチベーションを下げる

バグレポート自体、モチベーションを上げにくいものですが、ぐっとモチベーションを下げる記述内容もあります。相手への配慮が足りないものが中心です。

1. 要求は明確だが理由がない

「X画面がとにかくわかりにくいので、「集計」ボタンの位置を右側にずらしてください。45ピクセル右側でとなりのボタンの位置との間は20ピクセル程度で」とあるような場合です。

同様に「Z例外が起きたときにエラーメッセージが表示されず、正常終了とユーザが勘違いしてしまうように思います。～の修正は3日以内でお願いします。できない場合は理由書の提出をお願いします。」といった場合もあります。

両方とも、GUI部品の配置や修正日数について細かい指定があるのですが、理由は書かれていません。「となりのボタンの位置と近いと誤ってボタンを押してしまう頻度が非常に高く訂正が大変なので」といった補足説明があったほうが解決策の選択肢が広がり、より適切かつ簡便な解決策をみつけられるかもしれません。また、3日以内というのは何らかの事情で守らないといけないのでしょうが、「他サブシステムを含めたフィールドテストが5日後なので」等3日以内の理由を付記しておく必要がないと非常に一方的な感触を与えてしまいます。

2. イヤミや個人攻撃の記述

少し極端な例ではありますが、バグの症状として「これが単体テスト終了後のものか不思議ですが、電話番号の欄に漢字を入力しても登録できます。仕様通り、数字かハイフン以外は受け付けないようにしてください。仕様はそちらで書いたんですよね？」のような記述です。「これが単体テスト終了後のものか不思議ですが、」と「仕様はそちらで書いたんですよね？」はバグ修正には必要のない記述です。どうしても伝えたいのであれば、別の手段を考えます。

一方的な都合やお願いを押しつけていないか、お願いする場合には、理由や背景も伝えられているか確認する必要があるでしょう。

次ページでは4つめの「必要のない情報が多い」パターンを紹介して、これら4つをはじめとした対策を述べます。