困った時の自分用メモ

読んだ本を考察してメモったり、自分でいじった物の感想をメモったりする場。週1更新を目指します。

仕事の話~エンジニア目線から見た、バグ報告の仕方~

ゲーム開発をしていると、当然バグが発生する。
バグは直さなければならないとされている(このような言い方をしているのにも理由がある)

さて、皆さんのプロジェクトでは、バグの管理はどのように行っているだろうか。
筆者も10年近くゲーム業界でプロジェクトに従事しているので、様々なバグの管理方法を見てきた。

このエントリは、筆者が経験してきた「良くないバグ報告」と「バグ報告の提案」についての話である。

 

〇それ以前に、それは本当にバグなの?
皆さんは、以下のようなバグ報告を受けたら、どう感じるだろうか?

「タイトル画面のゲームを始めるボタンがおかしい」

さて、この文章だけで読者の方はバグ修正が出来るだろうか。
もし出来ると答えた方が居たら、その方は自身の勝手な思い込みで仕様を改変し、さらにその修正によって起こりうる不利益の責任を全て負う、という事を行っているのだが、その認識で間違いないだろうか?

 

バグがバグとして確定するのは

「その動作を定めた(=責任を持つ)人が、その想定の挙動をしていないと認めた時」

なのだ。

それまでは、いかに変な挙動だったとしても「バグ未遂の挙動」でしかない。

(まぁ、アプリがクラッシュするだとか、見た目がどう考えてもおかしいなど、誰が見てもバグとわかるような物は有ると筆者も当然認識しているが、その基準は個人が勝手に判断してはいけないという事だ。基本は、バグ認定は勝手にしてはいけないというスタンスが望ましい)

 

つまり、この報告がタイトル画面の仕様を定めた人ではない人から送られてきていた場合は、それはタイトル画面の仕様を定めた人がまず確認すべきであり、エンジニアはこれの修正に着手してはいけないのである。

もしかしたら、見た目がおかしくても、仕様を定めた人が想定した動きだからかもしれないからだ。

まずは、本当にバグなのかどうか、きちんと確認・確定をしてから動くことだ。

冒頭で、バグは直さなければならない物とされている、と言ったのは、それが本当にバグなのかどうかちゃんと確認しようという意味合いが含まれている。

 

〇良くないバグ報告
ちなみに、

「タイトル画面のゲームを始めるボタンがおかしい」

という報告だが、仕様を定めた人が確認する際の一次情報としては、ギリギリ許容してもいいレベルだが、はっきり言って不親切極まりない報告だ。

少なくても、エンジニア側に修正を依頼するのであれば、以下の情報は必須だ。

・バグと思われる挙動の詳細(おかしい、ではなく、どうおかしいのか、という事)
・再現手順(これも大事。バグを発生させるための方法)
・再現頻度(3/3回など)
・バージョン(GITやSUBVERSION、またはアプリのバイナリバージョン等の情報。バージョン違いで発生したりしなかったりは日常茶飯事)
・実行環境(PC、Android実機、IPHONE実機など、どれなのか。PCで起きてAndroidでは起きないなども当然起きる)
・望まれるべき挙動(これが一番大事。どう直して欲しいのか記載がないと、直しようがない)
・備考(例えば、あなたがエンジニアで内部データに誤りがありそうなことが、仮説として想定できるのであれば、その辺りの追記情報を書いてあげれば、直す側の人の時間を短縮してあげられるのではないだろうか)

 

ここで、望まれるべき挙動に関して、仕様を書いたプランナーさん等は、「仕様にちゃんと書いてあるんだから、それをきちんと読めばわかるだろう」という反論があるかもしれないが、あえて反論させてもらうと、それは本当にわかりやすい仕様書になっていると自信を持って言えるだろうか?

当然、エンジニア側も仕様書をきちんと読まずに実装を始めてしまうという人間は居るかもしれないが、それはお互い様なのだ。

なので、面倒でもバグ報告に望まれる挙動は記載して欲しい。もしくは、仕様書へのリンクを載せてもらいたい。

再現手順は、バグが本当に直ったかどうかを確認する際に必要だ。これが無いと、何を根拠にバグが直ったといえるのかわからなくなる。

 

 筆者は、現在進行形でこの不親切極まりないバグ報告だけを受けてバグ修正のタスクを割り振られているが、その都度詳細を口頭で聞きに行っている。

じゃぁ良いじゃんと思った方は居るかもしれないが、口頭のメリットは詳細を手短に簡潔に伝えられる点だが、デメリットは、その内容が短時間で忘れ去られることだ。

つまり、言った言わないの不毛な話になってしまうので、どっちかやればいいのではなく、どっちもやるのが正しいと思っている。

 

〇ここでも出てくる無意味なアルファベット優先度
別のエントリで、優先度についての説明をしたかと思うが、このバグ報告でも同じ事が言える。
たまに、エンジニアに優先度を参考にバグ修正をしてくれなんていう指示があるが、バグの優先度が必要なのは、せいぜいそれを管理しているディレクターが自分の中での対応優先度を忘れないように付けるに過ぎない。

エンジニアに必要なのは、「いつまでにやるか」「やらないか」だけだ。そして、その優先度はエンジニアやプランナー、ましてはバグ報告者が勝手に決めていい物ではない。

 

〇あとがき
こんな物も、何度も言っているが思考停止状態に陥らなければ、普通は疑問に思えるものなのだ。

読者の方のプロジェクトがこのようなバグ報告をしているのだとしたら、苦労をしなくて済むようになりそうだったら、参考にしてもらえたら幸いである。

まずは、面倒でも知りたい情報のフォーマットをテンプレート化し、そのフォーマットで報告してくれとお願いするところから始めてみるといい。それがダメなら、口頭で確認した物をあなた自身の手で情報をまとめ、全員の目に付くところに備忘し管理しておくといいだろう。

このような積み重ねが、いつかあなたを救うかもしれない。