バグを見つけた
営業「エンジニアに報告しなきゃ！！エンジニアさんバグです！！バグなんですよ！！バグがあったんですよ！！！」
エンジニア「せやな・・・」
営業「直さなきゃ！！今すぐ直しましょう！！」
エンジニア「ほんまやなぁ・・・」
序文は相変わらずセンスがありません。
この記事は主にディレクター・営業向けのバグ報告手法です。
こうやってバグ報告をするとスムーズに処理が出来るよってことを主に伝えられればなと思います。
もし貴社・あなたが主に行っている方法などありましたら是非教えて下さい。
バグ報告されるエンジニアの心境を理解する
バグ報告された場合エンジニアは内容にかかわらず以下の思考を考えます
- 今すぐ直すべきか
- 原因はなんだ
- どうすれば原因が特定できるか
- そもそも直せるのか
- 今日は家に帰れるだろうか
などを考えます。
ここでわかってほしいのは
テンションの上がるエンジニアはいない
ということです。
なので報告者は剣幕立てて報告すると、さらにテンションが落ちおもむろにスケジュールをこっそり後ろ倒しにします（僕はしたことはないですが）
報告する前に営業・ディレクターで出来る前調査を行う
まずバグを見つけたときに5Wを明確にすることを忘れない。
When（いつ）
- バグの発生日時はいつなのか
- バグの発見日時はいつなのか
- その機能が正常に動いているのを最後に確認したのはいつか
ここで重要なのは発生日時と発見日時を一緒に報告しない・発生日時と発見日時を明確に表記するということ。
なぜ発生日時と発見日時というと、サーバーにはだいたいアクセスログと言うものがあって、この機能をいつ使ったよなどが記録してあるファイルがあります。
このログを見て調査をし、この時間に使われたこの機能がトリガーになったんだ、と思い調査を行う可能性があるからです。
なので発生日時と発見日時を誤って伝えると、エンジニアが見当違いで無駄な調査が行われてしまう可能性があります。
あとはリリース（機能追加とか機能のアップデートとか）後にすぐに発見される場合もあるのでそのような場合は最後の、最後に動いていた日時が調査の鍵となる可能性もあります。
Who（誰が）
- ユーザー属性を明確にする
- 管理者
- 利用者
- 購入した人
- などなど
ここで重要なのはユーザーと言う言葉を使用しないということです。
ユーザーという言葉は非常に危険で、管理者のことも含める可能性があり、自分はとても曖昧な言葉だと思っています。
属性がより明確であればあるほど、調査は楽になると思います。
またここで可能であればブラウザのバージョン・なんのブラウザを使っているか・OSのバージョンはいくつか・アプリのバージョンはなにかも確認してあると、更に調査が楽になると思います。
Where（どこで）・What(何を）
- どのページのどの機能なのか
WhereとWhatは切り離して説明することができなかった・・・(´・ω・｀)
重要なポイントはどのページなのかをしっかり理解すること。
Whoでも触れましたがどのページで起きているかを把握することが大切です。
例えばECサイトで注文リストを閲覧する事ができる機能があったとします。
この注文リストで何かしらのバグが起きたとしましす、この際は以下の会話で完結してしまう可能性があります。
報告者「注文リストで○○すると☓☓されるバグがあったんや！直してや！」
わい「なんやて！今確認するからまってや！」
わい調査内容 : 管理者用の管理画面の注文リストで○○してみる
わい「バグなんてなかったやで、気のせいや」
報告者「なんや気のせいか・・・」
となり、バグは放置されてしまう可能性があります。
ここでの失敗ポイントは、実は注文リストという機能はお客様用管理画面にも注文リストという機能があり、ここの画面でのバグでしたということが、把握できなかったというポイントです。
なので上記の会話は以下のような会話がベストでした。
報告者「お客様用管理画面の注文リストで○○すると☓☓されるバグがあったんや！直してや！」
わい「なんやて！今確認するからまってや！」
わい調査内容 : お客様用の管理画面の注文リストで○○してみる
わい「ほんまやバグやな、直すでー」
報告者「お、サンキュー」
となるのです。
Why（なぜ）
- そのバグはなぜ発生したのか
- 特殊な操作
- タイミングの問題
- なぜこの操作を行ったのか
どうして起きたんや・・・ということを説明する。
ここらへんは読んで字の如くなぜそのバグが発生したかを伝える、再現手順があるとベスト。
なぜこの操作を行ったのかを書くとベストなのは、バグだと思っていたが仕様である可能性もあるので報告者は
私はこの機能で○○されることを期待したのですが、☓☓されてしまいました
というとベスト。
そうするとエンジニアは
その機能の仕様は☓☓されてしまうんや、でも勘違いする可能性もあるから説明追加、UI改善も検討するか・・・
となるのです。
本記事と話はそれますが、バグではないがUIを直しておかないと勘違いするかもしれないものの可能性もあるのです。
その他チェック項目
だらだら記事書いててそろそろエンジン切れそうなので、とりあえず箇条書きで確認しておくとスムーズにコミュニケーションが取れる項目も書いておきます。
- そのバグは再現できるのか
- 再現できるなら手順はどのような手順なのか
- ディレクター・PM向け）今すぐ直す余裕はあるのか・直すべきなのか
とかこの辺でしょうか。
この辺は書いてくれると嬉しいなぁと思うわけです。
次思いついたら報告用テンプレみたいなの作って見ようかなと思います。
皆様も良いバグ報告ライフを