デバッグ報告は、伝える側が正しい報告をしないと、現場が混乱します。如何に必要な情報のみを簡潔に報告するのが肝要となります。ここでは、どのようにデバッグを行い、どう報告して、最後にどう決着するのかまでを解説します。


  • バグを見つける
バグ。名前だけは有名になり、誰もがバグバグと叫ぶ世の中ですが、このバグ、簡単に言えば制作者が意図しない動作を指します。例え問題なく動いていたとしても、制作者が意図していなければ、それはバグなのです。そのため、バグの発見には対象のシステムの仕様を正しく理解する必要があります。

また、事前に何を調査するのか、表にまとめておくと良いでしょう。行き当たりばったりでバグを探しても、最初は出るかもしれませんが、そのうちバグが見つからなくなっていきます。100個のアイテムがあったとして、99個まで正常でも、最後の1個で問題が出る、それがバグなのです。
…寧ろその最後の1個はバグが出やすいです。

バグが出やすい箇所はあります。それはリミットチェックと呼ばれる方法であぶり出します。リミットチェックとは、例えばアイテムの所持最大数が 100個とすると -1, 0, 1, 99, 100, 101 に相当する、アイテム数が変化するタイミングを確認する方法です。100個までなら 101 はないだろうと思うかもしれませんが、99個のアイテムを所持しているときに、一気にアイテムを 2個手に入れたら、その瞬間は 101個になります。このように下限値と上限値の数値近辺が最もバグが出やすいのです。

また、時間によるバグも出やすいです。エージングチェックと呼ばれる方法です。デバッグ方法も単純で、電源を入れてから長時間ぶっ通しでプレーし続ける等です。メモリの限界を超えて暴走する系のバグは、このエージングチェックで発見されます。このようにバグの発見にはいくつかのやり方があります。慣れてくると、動いているゲームを見ているだけで匂うようになってきます。こうなるとシメたものです。
※本屋で見かけて以来、めっちゃ気になってます。

  • バグを報告する
バグ報告で大切なのは客観的事実だけを報告する事に他なりません。ここに、報告者の意見や感想や想像を入れないように意識するのが大切です。ここにバグがあるかどうかは、最終的にはプログラマじゃないと分かりません。どうしても自分の意見を入れたければ、それをちゃんと明記してください。私はここにこういうバグがあると思いますとか。ただ、それを読み取るプログラマには余分な誘因になる可能性がある事は理解してください。

さて、客観的事実でプログラマが欲しい情報は以下の通りです。
  1. バージョン番号
  2. 発生機種
  3. 発生した箇所
  4. 何が問題なのか
  5. 再現させる手順と再現率
  6. 影響範囲(深刻度)
報告者毎に形式がバラバラだと、プログラマの確認時に余計な時間を使ってしまいますので、通常は何かしらのデバッグ報告ツールを使用します。よくあるのは redmine というツールを使う事でしょうか。お金がない同人ソフト系であれば、報告定型テキストを元に、ネットワーク共有フォルダに「報告」「処理」「修正」「解決」というフォルダを作って、そのフォルダ内を1テキスト1バグ報告としてファイルコピーしながら、経過を記入していくなんて方法もあります。

バージョン番号がアプリにない場合は、そのデバッグしているアプリの作成年月日-時間をバージョン番号の代わりとします。例えば、2021/12/25 11:45 に作成されたアプリであれば、バージョン番号は 20211225-1145 とします。バージョン番号は、プログラマが既に手元では直しているのに、もう一度チェックする時間的な無駄を省くために必要です。

再現手順と再現率は最重要です。言ってしまえば、プログラマの手元で再現出来るのであれば、そのバグはほぼ取れたも同然です。時間を掛ければ必ず取れるバグという事になります。厄介なのは再現する方法がないバグ報告です。これは、バグ修正が困難な上に、修正出来たとしてもそれを確認する方法がありません。このような再現不能なバグを防ぐため、デバッグする人は自分のデバッグをフルタイムでビデオ撮影するのがベストだと言えます。プログラマなら見れば分かる事も多々あるためです。

深刻度は報告者の感性で最初は付与されます。私は以下のような区分としています。

 [S] :進行不能(例/フリーズする)
 [A] :ゲームの進行に問題が出る(例/手に入るべきアイテムが出ない)
 [B] :ゲームは進行するが問題である(例/本来行けないはずの場所に入れる)
 [C] :要望や改善、あるいは見た目だけ等(例/画面の縁にノイズが出る)

この深刻度は、 ディレクターやプログラマも確認変更します。ディレクターは好きに弄れますが、プログラマは深刻度を深くする変更だけとする等のローカルルールが存在する事があります。

最後に状況報告ですが、感覚的な内容は避けて、客観的情報を元にします。例えば「高速スクロールが遅い」という報告は、件名であれば良いのですが、報告内容に記載するには情報が曖昧です。具体的に記述するのであれば、「通常時 30FPSだが小惑星帯に突入すると 15FPS前後まで処理が落ち込む」等と記載します。重いと言われても実際どうなのかと分からないものなのです。
※ こいつ…動くぞ!

  • バグを修正する
報告を受けたプログラマがバグを修正します。複数のバグ報告が、実は原因が同じという事も多々あります。報告者はバグの客観的事実だけを元にしてますので、これは当然と言えます。逆に言えば、報告者はこれは以前の報告とバグと同じだと安易に決めつけてはいけません。100% 同じと確信出来たとしても、先に報告した内容に追記してどのような形であれ報告するべきです。もしかすると致命的な問題を見逃す事にもなりかねません。

プログラマは、バグ報告の再現手順を自分の環境で再発するか確認するところから始めます。再現した場合は、ほぼ間違いなく同時にデバッガで内容を追っていますので、バグの原因はその時点で大方判明する事になります。厄介なのは、バグが出た時点で、既に何かが壊れていた等です。これは、バグがしばらく潜在化していたことを意味します。本当の発生源を見つけるのは容易ではありません。

このような場合は、プログラマはテストケースをいくつか用意して、その結果の違いからバグの場所を推察する方法を採ります。それでもダメな場合は、バグが置きそうな場所にトラップやログを仕掛けたりと、プログラマの技量が試される事になります。…と、創意工夫でバグの場所を探し出して、見つけた時は単純なタイピングミスというのもよくある話です

バグを修正したら、次の更新タイミングでバージョンを更新の上、再度修正が正しく行われたかどうかを、バグ情報システムから依頼します。このとき、同時にチェックして欲しい事項もデバッガー向けに記載する事もあります。


  • バグが修正されたか確認する
修正済み確認依頼となった場合は、デバッガーは以前の再現手順で再発するか確認します。問題が起きてしまった場合は再発として、プログラマに状況報告します。問題が無かったとしても、すぐさま修正OKにはしません。関連するであろう別の手順であるとか、別の機種であるとか等、デバッガーの想像力が試される事になります。それでもバグが出ないと確信して、始めて完了として、このバグ報告は終了となります。

最後ですが、バグ報告と要望は分けて考えろとは最初に書いてますが、明らかな要望を [A] バグと称して報告する事例が後を絶ちません。たぶん、その報告者の中では [A] バグなんだろうと、今では私は諦めて、プログラマにバグ報告を見せる前に、私がフィルタリングしてから渡すようにしています。まあ、たまに要望に本物のバグ報告が混じっている事もありますし…。