ゲームプログラミング/デバッグ

ゲームのデバッグ

映画監督の川村元気（かわむら げんき）と任天堂の宮本茂（みやもと しげる）との対談『理系に学ぶ』によると、宮本茂いわく「プログラマーはバグを出さないことに責任がある」とのことです。 なのでプランナーやディレクターなどは、「彼らにどう納得してもらえるか」に努力をすることになります。

概要

ゲームにかぎらず、一般にソフトウェアのバグを取り除く修正のことを「デバッグ」といいます。

本書では、主に、ゲームにおける主に公開ベータテストにおけるデバッグおよびテストプレイの方法を説明します。

ゲームにかぎらず「ベータ版」（β版）とは、おおむね「バグが多いかもしれないけど、とりあえずソフトウェアとして最低限は機能するバージョン」のような意味のバージョンのことです。

いっぽう、「そもそも起動しない」とか「コンパイルできない」とか、「クローズボタンを押して無いのに、いきなりアプリが異常終了する現象が頻発」とか、「画面が、ずっと、まっくら」とか「データが勝手に消える」みたいな重大バグの多いバージョンは、アルファ版（α版）というか、または、単に開発初期のバージョンです。

ベータよりも前のアルファ版は、プログラマー側だけでチーム内部でチェックしたほうが、ラクです。

いわゆる、「テストプレイヤーを広く募集してテストプレイ」という外部に体験版ゲームを公開してのテストをするには、とりあえず開発チーム内部で試しプレイとして「通しプレイ」（そのゲームをニューゲームからクリアまですること）を先にした後に、最低限1～2回の「通しプレイ」が終わってから外部へのベータ版の公開をすると良いでしょう。「通しプレイ」とは、ゲームをスタート画面の最初からエンディングの最後のクリアまで、そのゲームをプレイする事です。

ゲームに限らず、こういう、プログラマー外部のテスト者にも協力してもらって、ベータ版をテストしていくことを、「ベータテスト」（βテスト）といいます。

「ベータ版」と、商品として発売した「リリース版」との違いは、相対的なものでしかなく、実際にはリリース版であっても、バグが含まれるのが一般的です。

ゲームに限らず、現代の複雑化・高度化したソフトウェアでは、すべての潜在的なバグを発見するのは、人員の限りや時間の限りがあり、ほぼ不可能なのです。

そのため、デバッグの最終目標は、けっして「バグをゼロにする」ではなく、「もしバグが残っていても、アプリの致命傷にならないようにする」などの、フェイルセーフ（fail safe）的な方針でデバッグしていく方法になります。そのため「影響度の大きい重大バグから、潰していく」などのような方向性で仕事していくことになるでしょう。

内部テスト

公開βテストの前に、まずはチーム内部で軽く、一般プレイヤーと同じ目線で軽くプレイする事や（俗に「フリープレイ」と言います）、あるいはβ公開後でも開発チーム内部でも引き続きテストプレイを時々することを「内部テスト」などと言います。俗に「内部デバッグ」とも言いますが、「デバッグ」とは本来はプログラム修正のことなので、正確には「内部テスト」というべきでしょう。

よって順番としては、

とりあえずの体験版などの完成　→　内部テスト　→　バグ修正　→　公開βテスト　→　体験版の修正　→　リリース版にむけての作りこみ　

のような順番になります。

賃金など

ゲーム業界のテストプレイは、賃金が安いです。特に文献などは無いですが、よく「テストプレイヤーの給料は安い」と言われています。

テストプレイヤーは、比較的に就職しやすいので業界経験にはなりますが、しかしテストプレイしているだけでは、どんなに頑張っても、そこからプログラマーやプランナーなどに転職するのは容易ではありません。

分かっているとは思いますが、ゲーム業界は年功序列などのある業界ではないのです。ご参考までに。

しかし賃金が安い一方で、日本語のチェック（漢字の誤字脱字など）などもテストプレイヤーの仕事であるので、よって日本人（ここでは日本語を母語とする人の意味）がテストプレイをする必要があります。対比としてアニメ業界ならアニメでは動画は海外発注などをされますが、しかしゲームではアニメ業界とは違い、ゲームのテストプレイでは日本語チェックをするので日本国内に発注することになります。

また後述しますが、シナリオの矛盾点などもチェックする必要があるので、読解力が意外と要求されます。読解力が要求される割には、賃金が低い仕事です。

新人向けの仕事でもある

なお、ゲームに限らず、ソフトウェアのテストは、IT企業では、よく新人がやらされる仕事でもあります。新人研修に組み込まれていたり、研修明けによく与えられる仕事でもあります。 なぜなら、自社ソフトウェアの内部構造の知識が乏しくてもテスト自体は可能だからです。

ゲーム業界でも、プランナー志望の新人がよくテストプレイを任せられることが多いです。

ただし、最近はテストプレイは外注することも多いです。

プログラマー用の自分用デバッグ報告文について

まず、あなたがプログラマーだとして、自作ゲームのテストプレイで、バグを発見したとしましょう。

その修正方法がもし簡単に思いつけば、その通りに修正すればいいのです。

ですが、なかなか修正方法が思いつかなかったり、あるいは考え付いた修正方法が間違っていて上手くは修正されない場合などは、なかなか大変です。

こういう場合、どうやってバグの事態を打開するかというと、

自分で自分にバグ報告メールのような文章を書くことです。

例を示します。たとえばRPGの作成中、装備コマンドで、アイテム無限増殖のバグが起きたとしましょう。 その場合、なかなか上手く直せずに、てこずったとしましょう。

ならば、書きのように自分で自分にバグ報告メールを書くのです。（もっとも、送信の必要は無い。あくまで思考を整理するために書くだけである。）

プログラマー自身による自己確認用のバグ報告文の例

【バグ概要】
アイテムの無限増殖バグ。
装備コマンド時に、アイテム無限増殖バグが発生する。


【バグ発生条件】
装備武器と選択武器が違う場合に発生。

装備中の武器が1行目にあり、
一方で選択中の武器はアイテム欄の2行目以下にある場合に発生する。

この条件で、決定キーを押すと、バグ発生する。


【起きる結果】
選択中の武器の個数　＋１　したものが、
選択カーソルの一つ上の武器（テスト時には、決定ボタンの直前に装備していた武器）の個数としてセットされる。（これがバグ）


なお、選択中の武器の個数に関しては、正しく－１される。 


【期待される挙動】
一つ上の武器の個数（決定ボタンの直前に装備していた武器としてセットされるべきものは、
「選択中の武器の個数＋1」ではなく、
一つ上の武器（決定ボタンの直前に装備していた武器と同じ武器の個数＋1であるはず。

以上。

のように自分で書くのです。（再現性などはプログラマー自身で把握しているので、この場合（自分用の報告の場合）は書かなくていい。）

コツは、

選択カーソルの一つ上の武器（テスト時には、決定ボタンの直前に装備していた武器）の個数としてセットされる。（これがバグ）

における 「決定ボタンの直前に装備していた武器」という記載のように、文節「選択カーソルの一つ上の武器」というゲーム中で実際に起きた現象だけでなく、さらにその現象の意味することを別の言葉で説明することです。

プログラマーの書いたバグありのコードを見れば、上記メモの「起きる結果」の通りにコードが書いてあるから、バグが起きるのです。なので、「期待される挙動」に書かれている通りに、コードを直せばいいのです

つまり、「【起きる結果】」と「【期待される挙動】」の報告文の内容を、バグ修正時には修正済みコードへと置き換えることになります。

よって、プログラマー自身による自分用のバグ報告メモでは、必ずこの2つの項目が必要です。

公募プレイヤーなどのバグ報告の片寄り

公開βテストなどで募集した一般プレイヤーは、ゲーム制作においては素人・初心者だったりしますので、デバッグの手法を知りません。

このため、公募プレイヤーのバグ報告パターンには、報告されるバグに、やや片寄りがあります。

よくある片寄りとして、

1. プレイヤ－に有利なバグは報告しない。
2. クリア不能にならないバグは見つけても報告しない。
3. 開発者でないため正常な仕様を知らないので、仕様と不一致のバグに遭遇しても気づかない。

などの片寄りがあります。

たとえば、具体例として

• 本来、BGMがボス戦（中ボス用）に変わるはずのシーンなのに、小ボス用のボス戦BGMのままのバグだけど、プレイヤーは正常仕様を知らないので気づかないので報告しない。
• 誤字脱字を見つけても、プレイヤーにとってはクリアに支障ないので報告しないプレイヤーも多くいます。

のような事例が、時々よくあります。

仕様と違う挙動をするという類のバグは、ゲームの快適性を確実に下げますが、しかし、初見プレイヤーはそのバグが「これはバグである」という事自体に気づかないので、バグとして報告されないという、厄介な問題があります。

なので、テストプレイヤーの人数と、取り除けたバグの量は、必ずしも比例しません。公募プレイヤーが報告する傾向のあるバグは、たいてい、クリア不能バグの類ばかりです。

なので、そのゲームの実際のバグの合計数については、公募プレイヤーの報告しなかった細かいバグが、公募プレイヤーからの報告数の何倍やヘタしたら十数倍もゲーム内に隠れていると思ったほうが良いでしょう。

なのでゲーム作者は、自分でも体験版などをときどきテストプレイする等の自己的なチェックが必要です。

さて、大きな更新などをした直後の場合などは、デバッグモード使用などでも良いので通しプレイをすると、バグがよく見つかります。

しかも、この手の大規模更新の影響を受けて発生したような細かいバグほど、初見プレイヤーには気づきづらい細かい箇所で発生するので、初見プレイヤーが遭遇しても報告されないという傾向があります。なのでゲーム作者は、通しプレイをとにかくデバッグモードを使ってでも何でもいいので定期的または大規模更新の直後などに行うことが必要です。

デバッグモード自体のバグによるチェックミスを防ぐため、ときどきデバッグモードを使わないでの通しプレイも行ってみると良いでしょう。また、もしそのゲームがデバッグモードを使わないとプレイ時間が莫大に掛かってしまい、ときどきの通しプレイすらもしたくなくなるゲームなら、そもそも大元のバランス調整が不適切な可能性があります。

守秘義務とか

デバッグに限らず、有料ソフトウェア制作に参加する人は、仕事で知りえた非公開情報を、けっして社外やチーム外には漏らしてはいけません。

仕事における、こういう企業秘密などを守る義務のことを「守秘義務」（しゅひぎむ）と言います。もしゲームテスターのアルバイトなどをする場合、守秘義務の契約書などを書かされるでしょう。当然、守秘義務の契約は守りましょう。

ゲーム業界やIT業界に限らず、一般の商社やメーカーや小売業や土建業などでも同様に、業務上の企業秘密は漏らしてはならないですし、それらの業種でも自社および取引先の企業秘密を守る義務があって、その義務のことを「守秘義務」と言います。

ともかく、「守秘義務」は社会人の常識です。

もし守秘義務に違反すると、たとえば損害賠償などを請求されたり、場合によって刑事罰を受けて逮捕される可能性もあります。

テスターの場合、「〇〇社でテスターのバイト経験があります」程度のことなら公表しても平気でしょう（就職活動にも公表の必要な情報なので）。ですが「〇〇社の△△のゲームをテストしました」（△）のような具体的な作品名のある情報は、（ゲーム会社からの）公開許可を貰わない限り、守秘義務により秘密にすべきでしょう。

まして、「あのゲーム、実は裏仕様では□□なんだぜ」（×）的な情報は、絶対に秘密にすべきです（もし機密を漏洩したら、損害賠償などを確実に起こされるでしょう）。

テスターには多くの人数が必要なので、そのゲームのクレジット（エンディングなどで流れるスタッフ一覧）にはテスター名は載らない場合もあります。（クレジットに名前が載るテスターは、居たとしてもテストチームの代表者など一部でしょう。）

フリーゲームや同人ゲームなど

さて、フリーゲームや同人ゲームなどの場合はどうかというと、特に契約書などは書かないですが（作者も面倒ですので）、しかし社会常識的に、ゲームテストで知りえた裏仕様などの裏情報は、なるべく黙っておきましょう。特に有料同人ゲームの場合、有料である以上は、もし裏仕様やネタバレなどの漏洩をしたら損害賠償などに発展する可能性もあるでしょう。

フリーゲームでも常識的に、裏仕様などは、もしテスト中に知っても、（裏仕様を）秘密のままにしましょう。

なお、フリーゲームでもある程度の作品ならテスターは多人数に上るので、クレジットにはテスターは記載されないのが普通です。

テストプレイは開発段階によってテスト内容が異なる

開発当初は、ゲームが意図通りに動いているかを確認する目的で、プランナーやディレクターが自ら確認します。

ゲームデザイナーは、発注したものが意図どおりに制作されているかを確認するために、実際に発注素材をゲームに組み込んだ状態のものを自分でプレイして確認します

解説

同人ゲーム程度の小規模な商業ゲームや、あるいは高品質なフリーゲームなどのテストプレイをする際、開発中の中盤くらいの段階でのテストプレイか、それとも発売直前・ダウンロード公開直前かの段階かで、必要とされるテストプレイのノウハウは、大きく異なります。

その理由は、まず外注アート素材などの出来上がってくるのが、けっこう後のほうだからです。

外注イラストや音楽などは作成に時間が掛かり、またもしイラストや音楽などのアート部品にミスがあった場合には修正の手間が大きくなるので、よってイラストなどは出来上がるのが、かなり開発の後半になります。

逆に、比較的に早い段階で出来上がるのは、テキスト部分です。

このため、開発の後半になるまで、画像などの納品待ちをしてい素材などのテストプレイは、初期段階のテストプレイでは不可能になります。

ラフ画や仮音楽などを初期段階テストプレイでゲームに組み込むという方法もありますが、しかし開発後期の本番むけテストの際にも、もう本番用のイラストや音楽などに置き換えてから一度テストプレイをしなおす必要があります。

こういった事情から、チェックシートなどを使ってでの、総当り的な本格的なテストプレイは、実は開発の後期になってからになる事が考えられます。（また、このため外注テストも、後半の段階からだろうと考えられる。）

開発の前期～中期では、あまり細かくテストプレイをしすぎる必要はありません。開発の前半では、これから仕様がコロコロと変わるので、開発前半で一時的にバグがゼロになっても、これからまた仕様変更により、開発前半で確認した場所にバグがまた発生する可能性も高いからです。

もちろん、開発前半でもサラっとテストプレイをしたほうが良いのですが、でもサラッとした感じで充分です。ここら辺の感覚はゲーム開発チームで無いと分からないでしょうから、外注はされない確率が高いと思われます。

さて、開発初期～中期でのテストプレイの場合、チェックシートなどは全く出来上がってないので（そもそも仕様書（設計仕様）が未確定の可能性もありうる）、なのでテスタトではメールなどを使っての文章でのバグ報告のヤリトリが多くなるので、あまりテストプレイヤーを増やすべきではないです。（初期段階からテストプレイヤーを増やしすぎると、メール対応が大変になります。）

開発前期のテストプレイ方法

開発後半のチェックシートなどを使ってのテストプレイは、外部サイトなどで元ゲーム業界の人達がチラホラとノウハウを公開してくださってますので、ソレを参考にしてテストプレイをすると良いでしょう。

ですが、開発前期のテストプレイ方法は、なかなか公開されてません。（一応、任天堂がゼルダなどを例に手法を公開している。）

開発前期の場合、そもそもチェックシートが無い場合が普通でしょう。仕様自体が今後の仕様変更で変わる可能性もありますのでチェックシートを作るメリットも薄いです。このような事情もあり、あまり細かくチェックする必要も無いでしょう。

なので、基本的に、一般プレイヤー目線での「通しプレイ」による通常のプレイ方法を中心にしてのテストプレイをする事になります。

さて、同人ゲームやフリーゲームなどの場合、開発初期のテストプレイヤーの人数は、せいぜい4～5人など一ケタ人数になります。この程度の一ケタ人数でのテストプレイの場合、バグ報告などのヤリトリは、メールで行う場合が普通でしょう。

こういった開発初期でのテストプレイでもしバグを見つけて、これからメールでバグ報告をする場合、バグのあった箇所を報告する際に、さらにどこまでゲームを進行させたかを追記的に数行ていどで報告すると良いでしょう。

たとえば、

第4章の〇〇のシーンで、下記のバグを発見しました。
【バグ内容】
※ 中略


【追記】
第6章までクリアしました。第5話の結婚イベントのヒロイン選択では、花嫁にはビビアンを選びました。ビビアンの見た目で選びました。なぜなら金髪ツインテールは正義だから。ビビアンかわいい。

みたいにです。

このようにクリアした範囲を報告する理由としては、報告を受ける側としては、プレイヤーがどこまでプレイしたか、分からないです。

たとえば、全10章のゲームで、第4章にバグが特に多く報告されている場合、はたしてプレイヤーが

第10章まで進んでクリアした上で、第4章のバグを多く報告しているのか？、

それとも、

第4章や第5章までの前半～中版のステージでプレイヤーが行き詰ってるのか？、

といった事が、バグ現象だけの報告では不明だからです。

もし、テストプレイヤーが第4章か第5章から先に進めない場合、作者はバランス調整やヒント追加などとともに、テストプレイについても作者側で、テストプレイヤー側が未検証が第6章以降をテストプレイする必要も生じます。

また、ゲーム中のフラグ管理に大きな影響を与えそうな重大な選択肢のあるイベントなどでは、どういった選択を選んだかも追記すると、作者側と情報共有しやすいでしょう。

たとえば上記の例のゲームの「第5章」の花嫁選択の場合、たまたまテストプレイヤーが3人いる花嫁候補のうち、ビビアンばかりを選んだりするかもしれません。

なぜなら開発初期～中期のテストプレイでは、開発後期でのテストプレイとは違うので、いちいちテストプレイヤーどうしでチェック作業を分担したりしません。というか、そもそもテストプレイヤーはお互いには連絡しません。これはゲーム作者や開発チーム管理者に情報を一元的に集中させる必要があるので、テスターどうしでの情報共有は自粛すると言う側面もあるからでしょう。（伝言ゲームみたいな情報劣化を防ぐため、開発初期の小人数テストプレイでは作者と直接やりとりをするので。）

その結果、そのゲーム中に選択肢イベントのある場合、別々のテスターどうしでも重複して同じ選択肢をたまたま選ぶ場合もあります。

また、開発後半のデバッグでは、チェックリストなどを作って、「〇〇月○〇日の時点では、どこにバグが無かったか」というバグの無かった箇所も確認する必要があるのですが、しかし開発の初期で、いちいちそこまでのチェックシートを作るのは面倒ですし、開発初期は今後の仕様変更の可能性も高いのでチェックシートを初期からいきなり作っても無駄になる可能性があります。

そこで、他のバグ報告の際に、追記的に、ゲーム内でどこまで進行したかの情報も書くことにより、「どこにバグが少ないか？」という情報についてを、作者は間接的に知ることが出来るからです。

なお、バグ報告が無い場合に、いちいちプレイのたびに、「どこにバグが無かったか？」のメールを送ると、メールの量が増えたりして、読む側の作者も面倒だし、書く側のテスターも面倒です。

ただし、上記の方法は、あくまで開発初期～中期での、さらに少人数（せいぜい5人ていど）でのテストプレイの場合です。

商業ゲームのテストプレイは全くの別

プレステ作品や任天堂ゲーム機作品などの商業ゲーム作品などを作る場合は、もっと多くのテストプレイヤーが必要になりますし、「通しプレイ」だけでなくチェックリストなどを作ってのブルドーザ的な総当たりの点検も必要になってきます。

なお、商業ゲームの外注テストプレイの場合、いちいち開発メンバーにメールしません。なぜなら、普通は開発の後期に外注テストは開始され、この段階になるとテスターの人数が多いことなどや、すでにバグ報告用サーバーの投稿フォームなどが整っているので、そちらサーバー側の投稿フォームのほうに、会社などで定められた書式のとおりに投稿します。

商業ゲームのテストの場合なら、テストチームのリーダーなど現場リーダー的な人が、テスト全体の計画を考えて、部下である各テスタ－たちに指示を具体的に出しますので、テスターはその指示に従ってテストをする事になるでしょう。（テスターがいちいち、次にテストする内容を考えたりしないと思います（それを考えるのは現場リーダーの仕事だし、各テスターに考えさせると人によってテスト程度のバラツキが発生しかねないので、テスト品質を一定に保つためにあえて現場リーダーに管理を任せます）。）

部下テスターは指示されたとおりのテストが終わったら、それを現場リーダーに報告します。すると現場リーダーは、全体のテスト状況やゲーム仕様などをもとに、次のテスト内容を部下テスターに指示します。

どういった内容が次のテスト内容になるかは状況にもよりますが、よく指示で出されると言われるのは、まだテストが不足していたりして遅れている箇所の手伝いとか、そういった箇所のテストの指示が出される可能性が高いと思います。

（実は同人ゲームなどのβテストでも、テストをボランティアなどで手伝う場合、テストが遅れている箇所のテストなどを同人ゲーム作者からテスターが依頼される場合もありますが、ハナシがややこしくなるので、ここでは同人ゲームの話は省略する。）

最初から「面白いバグ」はまず無い

また、バグは原則、発見したら、なんらかの修理的な処置により直すべきです。

よく、「面白いバグは裏技として残す場合もある」と言われますが、たとえ最終的に裏技として残す場合であっても、とりあえず発見者はそのゲームの問題点のある挙動を『バグ』として報告し、判断を担当者に任せます。

そして「バグ」報告を受けた担当者は、その「バグ」をたとえ裏技として残す場合であっても、現状ではテストプレイヤー視点ではバグ的に見えるわけですから、そのゲーム中の挙動には、なんらかの修正対処が必要です。

そもそも、ゲーム開発序盤では、そのままでは「面白いバグ」というのは、ありません。

たとえ有名ゲームの面白い仕様の挙動が、バグ由来の現象でも、そのプログラムコードはゲームの実装開発中に何度も修正を受けて改善されてきています。

つまり、「改善すれば、面白くなりそうなバグ」なら、あるかもしれません。

バグ報告を受けた担当者は、そのバグが「改善すれば、面白くなりそうなバグ」なら、その挙動が一般プレイヤーにとっても面白くなるように、修正していく必要があるのです。

総論

ゲームのデバッグのためには、まずバグを発見する必要があります。

しかし、すべての潜在的なバグを発見するのは、人員の限りや時間の限りがあり、ほぼ不可能です。

なので、まず製作者は、プレイヤーのよくやる行動をゲームプレイで再現してみて、そして遭遇したバグから直しましょう。

※ 「仕様書やチェックシートなどをもとに確認しなくていいの？」と思うかもしれませんが、（想像ですが）本格的な仕様書・チェックシートが作成される時期は、ゲーム開発の中期あたりからでしょう。

なぜかというと、仕様書を作成する前にまず、試作品ゲームソフト（プロトタイプ）をある程度はキリよく遊べるところまで作ってから、その試作品にデバッグをして大きなバグや目につくバグを潰してから、通しプレイをするなどしてマトモに遊べることを確認してから、ようやく仕様書などの書類を作ることになるからです。仕様書が無い段階では当然、チェックシートなんていうモノも無いのです。

もし「仕様書」（設計書）があっても、仕様書の内容と、実際の開発版のソフトのプログラムの内容が異なっている場合も、開発初期などでは考えられます。（開発初期は仕様変更をコロコロとするので。ただし開発後半では、『仕様書』のソフト実物の内容とが一致してないとマズい。）

試作品（プロトタイプ）とは言っても、バグは早めに直しておく必要があります。そのゲームが、万が一にバグが起きてもバグを直しやすいシステムになってるかどうかを確認するのも、試作で行うべき確認事項のひとつです。しかし、試作品ですので、あまり多くの人員をテストに導入できないので、なので、プレイヤーのよくやる行動で遭遇するバグから先に潰していく必要があります。

さて、プレイヤーのよくやる行動を優先する理由は、極端な例を挙げると、例えば、もし普通のプレイヤ－のやらない行動をしてみてバグを見つけて直しても、 たとえば、RPGで、薬草の使用をキャンセルするのを20000回連続で続けると遭遇するバグがあったとして、もし製作者がそのバグを直しても一般プレイヤーは気づきません。

1960年代のような古いコンピュータのデバッグ方法と、現代のデバッグ方法は違います。

つまり、パソコン黎明期の科学計算のデバッグやファミコン黎明期（1980年代）のゲームのバグの探査方法と、現代の廉価or無料のパソコン用ゲームのバグの探査方法は、微妙に違います。

アセンブラなどをいじくる必要のあったテレビゲーム機の黎明期の時代のバグ発見の方法は、現代では、あまり向いていません。

現代のゲームでは、バグ修正は、ネットワーク通信ゲームなら、公開後にもネット経由でアップデート修正することもできます。

また、有料ゲームでも、販売前に体験版などを配布してプレイヤーにテストプレイしてもらう事で、プレイヤーの遭遇しやすそうなバグを探せます。

一方もしゲームでなく、たとえば自動車用の組み込みプログラムや、あるいは工作機械などの組み込みプログラム組み込みなどのバグ探索ならば、バグが人命の死につながりかねないので、たとえば、電源ケーブルや通信ケーブルなどの抜き差しをしたりとか不安定な状態にしてバグを探したりとか、温度をあげたり下げたりとかまでしたりとか、そういうハードウェアとの関連のありそうなバグも様々な方法で徹底的に探します。

しかし、現代のゲーム開発では、そこまでしてバグを探す必要は無いでしょう。

また、こういったハードウェア関連のバグは、ＯＳメーカーやあるいは業務用の組み込み機器メーカーなどが探すべきバグです。 けっしてPC用ゲームメーカーの探すべきバグではないです。

（もし任天堂やソニーのような、）新発売されたばかりの新ハード用の対応ゲームをハードメーカーやＯＳメーカーが制作しているならともかく、（中小ゲームメーカーのような）既存のパソコン用の無料ゲームや廉価ゲームなどでは、そこまでしてハード関連のバグを探す必要は無いでしょう。

なお、IT業界において、デバッグは一般的に品質管理（QA）部門の仕事です。（※ 異業種の人に説明する際、こう説明しよう。）

何が「バグ」か

ゲームにおける「バグ」は、クリア不能などは当然「バグ」です。

ですが、クリア可能であっても、仕様と違っていたらバグです。

仕様と違えば「バグ」

たとえば、武器「鉄の剣」を装備したとき、本来の仕様なら攻撃力が15アップなのに、攻撃力が12しかアップしなかったら、それはバグです。

なので、商業ゲームのテスターは、仕様書などを参考に、そういうパラメータもひとつひとつ、最終的に完成まではにはチェックする必要があります。

ボタン入力後の状態遷移バグ

典型的なバグとしては、連打などボタン操作による、状態遷移のミスによるバグがあります。

けっして連打そのものが目的ではなく、状態遷移ミスを見つけるのが目的ですので、目的を勘違いしないように。なので、連打中に十字キーを入力してみるとか、そういうふうに色々と確認します。

たとえば連打だけでなく、別々のボタンの同時押しなども、商業ゲームでは、よくあるバグ調査手法です。

たとえば

決定: Zボタン

キャンセル:Xボタン

などの仕様が決まっているなら、ZとXの同時押しなども確認します。

ゲームの説明書があれば、操作説明などが説明書に書いてありますが、説明書は鵜吞みにしないようにしましょう。

あるいは、画面が変わる途中（「画面遷移」）などに、何かのボタンを連打したり、色々と試してみましょう。

特に、ゲーム中で特殊なキー入力イベントがある場合、そのキー入力イベントなどでは、このようなボタン関連の状態遷移バグが多発しやすいので、要チェックでしょう。

RPGツクールなどの既製品のゲーム制作ツールでは、標準設定のUIでは、この手のバグは少ないです。しかしツクール作品などでも、作者の自作したUIなどだと、こういうバグも時々ありますので、テストプレイなどで確認してみましょう。つまり、開発で追加されたばかりの新UIがあったら、テスターはまず下記のモンキーテストによるテストを試してみましょう。

モンキーテスト

なお、キーパッドやキーボードなどのボタンをデタラメに押しても異常動作が起きないかをチェックすることを「モンキー テスト」と言います。猿のように、理解もせずにデタラメに操作するからです。

モンキーテストではデタラメに入力するので、仕様にないボタンも入力する事になります。上述のようなボタン受付のテストや状態遷移テストなどで、よくモンキーテストが使われます。

漢字ミスや誤字脱字

ゲーム制作において、誤字脱字もバグに分類します。

たとえば道具「ポーション」（potion）が「ボーション」（botion？）になってたりとか、そういうのもバグです。日本人のキーボード入力ならありえないミスですが、中国など人件費の安い海外にプログラミングを発注していると、似た文字をよく間違えます。なので、文字が正しいかもチェックします。

「エアロ」（aero）が「工ア口」（こうあろ）とかになってたりとか、字体の似ている文字どうしは要注意です。

誤字どころか、原文自体がオカシイ場合もあります。

本来なら、たとえば「さあ、行くわよ！」と女性キャラのセリフを書くべきところを、

バグでは、助詞の使い方は外国人には難しいので「わ」と「よ」が入れ替わって「さあ、行くよわ！」みたいになっている場合もあります。

他にも「い行くわよ」みたいに、フリガナを勘違いして前後に出している場合もあります。こういうのも仕事では「バグ」として種類「誤字」などとして報告します。

「気づく」が「気ずく」になってるような、「づ」と「ず」の間違いも、海外系ではチラホラあります。「貴様の殺気に築かないとでも思ったか！」みたいな「きずく」だと変換に「気づく」が出てこないので、変換に出てきた「築く」を使った誤記とか。

なのでテスターの誤字修正のための学力の要件として、最低でも中学卒業レベルの国語力は必要です。もちろん、けっして偏差値30の底辺高校の合格なんて国語力では不十分です。偏差値55くらいのそこそこ賢そうな高校に国語教科だけなら合格点を取れそうな国語力ぐらいは、大人なら習得しときましょう。

こういう仕事は一見、出版業界でいう「校正」や「校閲」の仕事に近そうですが、しかし本当は、どっちかと言うとゲームの誤字デバッグは翻訳家（外国語→日本語）のほうがイメージに近いです。ある程度、英語の勉強もしておきましょう。中学～高校初級の英語レベルは、身につけておくと便利でしょう。

世間的には「翻訳」で説明したほうが分かりやすいでしょうが、業界用語的にはゲームの「日本語ローカライズ」でしょう。たとえ日本企業のゲーム会社の作品でも、なんらかの大人の事情で、中国などに一部の工程を外注していたりする場合もあるので、テストプレイの際には日本語ローカライズみたいに文章チェックもして、誤字脱字やカタコトっぽい表現などを報告して修正させます。

さて余談ですが、出版業界の校正・校閲でも、誤字脱字は修正の対象です。日本人の作者でも、タイプミスなどで、ときどき誤字脱字をしますので。「わがはいははネコである」みたいに、日本人だって「は」を2回続けるようなタイプミスもする場合だってあります。

ですが、「校正」と言った場合、老人っぽくて若者には分かりづらい表現を現代風に言い換えさせたりとか（時代遅れの表現とか）、差別用語や放送禁止用語などが含まれているかを見つけて修正したりとか、そういうのも含みますので、誤字修正とはニュアンスが異なります。ちなみに校正や校閲も、（PCデータではなく）実際に印刷物として試し刷りした状態の印刷物（「ゲラ刷り」）で、確認をするようです。ドコの業界でも、製品に近い状態でチェックをする傾向があるようようですね。

さて、校正というほどではないですが、誤字脱字の確認のために、国語辞典が必要になります。なので、テスターには国語辞典も必要です。そもそもシナリオライターがシナリオ作成術を磨く時点で、国語辞典を活用しています。

勉強法として、普段から暇なときに国語辞典を読んでおく習慣を提唱するシナリオライターもいるくらいです。ランダムで、パラパラと空いた時間などに読むというものです。一方、1ページ目から読むと挫折するとのことです。

しかし、テスターとしては、ここで問題があるのですが、国語辞典には口語が全く掲載されていません。たとえば接続詞「あと」ですら載っていません。なのでゲーム中の会話文で口語を多用する事の多いゲームでは、国語辞典は不十分です（「なので」も載っていなかったりします）。そして困ったことに国語辞典の代わりになる『口語辞典』というものはありません。なので国語辞典の活用は、せいぜい名詞の確認ぐらいに留めておきましょう。国語辞典には、出版社によっては、どうでもいい一過性の流行語が載っているくせに、数十年前から使われている口語は載っていないなど、とてもフザケた編集姿勢です。なお「でも」や「だって」は国語辞典に普通にあります。

なので、実は海外の日本語学習者には、日本の中学校高校で教えられているような文法は、疑われています。実際、留学生や在日外国人のための日本語教科書を読むと、日本の中学高校で教わったような理論体系とは、まったく異なります。

根本的には、現代日本語は、近代英語のような文法の原理原則を先に決めたアプリオリな言語とは、文法の確立の経緯が大きく異なります。つまり日本語はけっしてアプリオリな言語ではないのです。だから辞書や教科書による日本語学習には、早いうちで限界が来ます。ですから、市井（しせい）の日本語にも耳を傾けましょう。

デバッグではないですが、そもそもシナリオライター側の時点ですでに、書籍『ゲーム作りの発想法と企画書のつくりかた』によると、ゲーム中での表示文については「正しい日本語」を書く必要がないとのことです（かぎカッコはwiki側で追記）。たとえば、ゲームの画面は本と違いますので、ゲームでは画面中に表示される行数を気にしないといけません。ゲーム画面には、こういう種類の制限や要求事項が他にも多くありますので、そういった制限などの中で、シナリオライターはプレイヤーにとってプレイしやすい文章を書かなければならないからです。

ゲーム中の文章の著作とは、けっして国語教師を目指すことではないのです。

ゲームとしての良い文章の作り方は、特にルールといったものはないですが、ともかく、ゲームのしやすさに役立つ文章でなければなりません。

シナリオライターは文系職

シナリオライターはなんだかんだで文系の人材の仕事です。

参考文献『ゲーム作りの発想法と企画書のつくりかた』では、国語辞典を使った勉強法の例として「水」「おひや」「ウォーター」という単語を上げています。

理系では「おひや」なんて単語、使う機会がないです。

（なお、声優も文系だと、よくネットの評論では言われます。脚本・台本を描くシナリオライターが文系であるのだから、その台本を読んで声を吹き込む声優も必然的にも文系的に読解力が必要になります。）

よくレポートの作文術などで「起承転結ではなく、結論から書け」の指南があります。しかしシナリオ制作では、起承転結を書かなければならない場合が多くあります。

モチはモチ屋。テスターなどの理系的な作業者は、文系の領分に踏み込まないようにするのが良いかもしれません。

もっとも、理系の知識も、たとえばロボットSF物の作品などのアドバイザーとしては役立つ場合もありますので、けっして「全く理系知識が役立たない」と悲観する必要もないです。ですが、消費者の多くは、別にゲームやアニメのロボットSF作品には、科学的な正確さを求めていません。そもそも「SFは、科学的にはウソ」という根本問題もあります。また、ロボットSFファンの客層でも、必ずしもハードSFを読みたい人だとは限りません。

リアリティとリアルは違います。

たとえばアニメのガンダムのファンの多くが、電子機械エンジニアを目指して理工学を勉強したがっているなんて事は、常識的に到底は考えられないです。

海外翻訳の実情

なお、多くの業界で翻訳の仕事は通常、翻訳先の現地の国のその言語を母語にしている現地人が、最終的に自国語に翻訳します。

たとえば、日本語に翻訳するなら日本人が最終的に翻訳します。同様に、英語に翻訳するなら、アメリカ出身のアメリカ人が翻訳するのが普通です。

この慣習はIT業界だけでなく、裁判などでも同様で、たとえばアメリカで海外展開している日本企業の裁判は、アメリカ出身で英語を母国語としている弁護士が訴訟活動を行います。たとえ日本出身の日本人弁護士がどんなに英語に堪能でも、その日本弁護士はせいぜい、アメリカ弁護士に依頼をするまでしかせず、最終的にアメリカの法廷で法廷闘争するのは、日本企業や日本人弁護士から依頼を受けたアメリカ出身弁護士です。「国際弁護士」と言う肩書きの人は、それぞれの国の現地の弁護士に依頼するのが仕事です。けっして、国際弁護士本人が、各国の法廷で直接に訴訟や弁護を展開するわけではないのです。

よく、漫画やアニメとかだと、日本人の自称「国際弁護士」がなぜかアメリカの法廷で直接に訴訟してたりしますが（たとえば実際、1990年ごろにアニメ映画版『ルパン三世』の金曜ロードショーのやつで、ヒロインの峰不二子が弁護士に経歴詐称して、アメリカで荒稼ぎしていた）、アレはフィクションです（90年代当時、流行語で「キャリアウーマン」という用語が流行してたので、そのような女性にも不二子は変装できる能力もあるという演出にすぎない）。映像的なテンポを優先しただけの演出です。けっして真に受けてはイケマセン。

弁護士の国際活動の話はあくまで類似例としての一例でして、とにかく翻訳をするのは、現地の人です。

何が「バグ」ではないか

・ゲームの難易度が、「やさしすぎる」または「難しすぎる」などの改善点は、「バグ」ではないです。

・ゲームのここが「つまらない」または「こう改善すれば、もっと面白くなる」などの改善点は、バグではないです。

「バグ」とは、明らかなミスだけが「バグ」です。具体的には、プログラムの誤動作や、漢字の誤字脱字、仕様書と実装が異なる場合など、客観的に「間違い」と誰でも判定できるのがバグです。

ゲームが「やさしい」とか「難しすぎる」とかは、個人の好き嫌いや趣味の問題なので、バグではないのです。（ただし、難易度調整のプログラム自体にミスがある場合などは例外。たとえば高難易度モードでは本来なら敵の攻撃力が1.5倍になるべき仕様のはずが、プログラム時のキーボード入力ミスで1.2倍になっていた場合とかは、バグである。）

難易度の調整は、テストやデバッグではなく、「バランス調整」という別の部署の担当業務です。

「バランス調整」と「デバッグ」との違いは把握しましょう。

優先順位づけ

ともかく、ゲーム産業にかぎらず一般のIT業界でも、発見されたバグは、修正の優先順位にもとづいて格付けをされます。

医学における、どの患者から先に治療すべきかという概念である「トリアージ」という医学用語になぞらえて、IT業界でもバグの修正対応の優先順位（priority）の格付けのことを外国でも「トリアージ」と言います。

このことは、ゲーム作家の側には「トリアージ」などの用語の暗記は不要ですが、どちらかというとプレイヤーのテスト協力者などに考え方を知ってもらう必要があるでしょう。

もし科学者が科学計算ソフトウェアで世界最先端の開発を目指すのなら、（予算が国から与えられる限り）好奇心や興味のおもむくままに研究して、「トリアージ」の概念を無視するのも可能かもしれません。しかし一般のIT産業やゲーム開発では、予算の制約が厳しく、人員や設備の制約も厳しく、そうはいかないので、「トリアージ」的な優先順位づけが必要になります。

ゲーム業界でも当然、このようなバグ修正の緊急性の格付けは行われております。（参考文献: STUDIO SHIN 著『ゲームプランナーの新しい教科書』）

デグレやエンバグなどを防ぐには

書籍『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』によれば、バグを直すためにプログラムに変更を加える場合でも、なるべく変更が少なくなるようにする必要があります。この理由は、プログラムの変更により他の部分でバグが新規に発生するのを防止するためです。

なおIT用語で、「バグを直そうとしてプログラムをいじったら、修正したつもりのコードの内容が間違っていて、別のバグを埋め込んでしまった」的なミスのことを、ニュアンスは不正確ですがIT用語では「デグレ」degrade とか「エンバグ」enbug などと言います。

3D-CGで壁CGにキャラCGが、めり込む場合

また、これとは別に、3D-CGのあるゲームなどで、人類のCG技術的な限界により、わずかにだけ人物キャラクターが壁などに数センチ程（たとえば指の長さ程度）だけ、めり込んだりとか、そういうのは「バグ」ではなく「仕様」とするのが一般的だと言われます。技術的な限界により、少々の画像めり込みは、仕方ないのです。

もっとも、（通行設定ミスなどで）壁貫通を出来たりして向こう側にキャラが行けてしまってゲームのストーリーが変わってしまうとか、そういうのは「バグ」扱いですが。

テスト用語で、ゲーム中の壁のバグなどの「通行設定ミス」という言葉がありますが、裏を返せば、壁については通行設定さえミスしてなければ、少しくらい壁にキャラが めり込んだりしてしていても、構わないわけです。

バランス調整との関係

バランス調整との違い

敵の強さなどの設定のバランス調整も、デバッグのためのテストプレイも、一見すると似ていて、ゲームを延々とプレイしたり、問題点を発見したら場合によってはレポートを書いたりして開発チームとコミュニケーションする場合もあるので、似ているかもしれません。

ですが、目的が違いますし、そして重要な相違点として、要求されるゲーム内知識が違います。

バランス調整のためのテストプレイヤーには、なるべく、そのゲームに詳しくない人のほうが最適です。（英語では「ティッシュ テスター」とか、「フレッシュミート」と言います。ティッシュとはもちろん、鼻をかむチリ紙のティッシュの事です。フレッシュミートとは「新鮮な肉」の意味です。）

そのため、バランス調整で開発者は、テストプレイヤーにあえて情報を伏せたりする事も考えられます。いっぽう、バランス調整テストプレイヤーも、あまりそのゲームの裏事情を知り過ぎないように気をつける必要があります。

ただし、バランス調整チームのリーダーだけ、そのゲームの裏事情を知ってたりします（でないと、他部門とコミュニケーションが取れなくなりかねない）。

一方、デバッグに参加している人のことを、和製英語で「デバッガー」といいます。

デバッガーは、なるべく、そのゲームの裏事情や開発事情などにも精通し、そして、そういった知識も動員しつつ、バグの起きそうな所をテストプレイで探して、バグを発見する必要があります。

※ バグの報告をする人を「テスター」という場合もありますが、本wikiではバランス調整用のテストプレイヤーとの区別のため、「デバッガー」と呼ぶことにします。また、バグ報告を受けてプログラムを修正する人だけを限定して「デバッガー」という場合もありますが、本書ではやはりバランス調整との区別のため、バグ報告マンも、バグ修正プログラムのプログラマーも、まとめて「デバッガー」と呼ぶことにします。

英語では、デバッガ debugger とは、ソフトウェアの一種で、デバッグのためにログなどをとるソフトのことです。タイプライターが人間ではなく機械なのと同様、英語の debugger は人ではなくソフトウェアです。

バグの中には、そのゲームの仕様に精通しないと気づきづらいバグもあります。気づきやすいバグというのは、たとえば「画面がノイズだらけになる」というバグなら誰でも気づきます。しかし、そういう分かりやすいバグばかりではないのです。たとえば「あるシーンでの登場人物のセリフが微妙に、前後の話の流れにあってない。特殊イベント管理フラグのミスか？」みたいなバグも起きうるのです。なので、デバッグ作業では仕様をデバッガーが知る必要があるのです。

また、似たようなプログラムを使っている2つの特殊イベントの片方にバグがあったら、もう片方にもバグがあると考えるのが自然です。デバッガーにはそういう論理性が要求されます。また、こういうデバッガーの論理思考に協力するため、プログラマーなどもデバッガーにアルゴリズムの要点などの情報提供を適度にする必要があります。

なお、初心者の視点のほうが気づきやすいバグもあるので（たとえばチュートリアル説明などのバグ）、デバッグテスターも最初は仕様の知識の無いところから始めますが、デバッグ作業の進行に応じて仕様制定者（プランナー）や上長などからデバッグ状況に応じて仕様を随時、教えてもらうことになったり、仕様書をもらいます。

このように、上長などは、デバッガー系テスターに、そのゲームの設計図や仕様の一部を随時に教える場合もあります。商業ゲームの場合なら、デバッガーは最終的には仕様書（そのゲームの設計図）を見ながら、そのゲームのすべての仕様を一通りはチェックすることになります。

一方、バランス調整テストプレイヤーでは、逆にそういうヒントは、一般プレイヤーとは異なる先入観を与えてしまう結果になってしまうので、こういうヒントは与えてはいけないのです。

デバッグの当初は、デバッガーもバランス調整テストプレイヤーも、知識が少ないとこから始めるので、知識事情が似通っていますが、次第に要求されるゲーム内知識が違ってきます。

なお、デバッグは、人数が多いほうが有利です。なるべく、異なった視点で色々なプレイするほうが、色々なバグを発見できます。

バランス調整はややコツが必要ですが、それと比較すると、バグを発見するためのプレイは、比較的にコツが少なめで済みます。

なので、もし同人サークルなどチームでゲーム製作している場合、なるべくチームメンバーの多くでデバッグしたほうが、より簡単に見つかるでしょう。

バランス調整されてからテストプレイが望ましい

基本的に、細かいテストプレイを開始するのは、バランス調整後です。

文献『ゲームプランナー入門』によれば、ゲーム制作の流れは基本的に、

プロトタイプ→アルファ版→ベータ版→調整→デバッグ

の流れです。

なお、アルファ版とは、ゲームの全体像が分かる一部分を、「商品レベル」で作ることです。

ベータ版とは、会社によって意味が多少違いますが（たとえば『ゲームデザインプロフェッショナル』と『ゲームプランナ－入門』とで微妙に違う）、おおむね、とりあえずのゲーム最初からエンディングまでの完成間近をひととおり遊べる状態のことです。

α版などのゲームのテストプレイをしていると、作者がまだバランス調整を終わってないエリアが、そのエリアの（バグ発見などの）テストもまだ終わってない場面もあります。

もしアルファ版の段階でテストプレイに協力しているなら、バランス調整のまだ終わってないエリアの存在する場合、できるだけバランス調整が終わったエリアから優先的にテストしたほうが効率的です。

というのも、せっかく仮に、ゲーム中にあるバランス調整が終わってないエリアをテストプレイをしても、バランス調整後にそのエリアにおかしな所が追加されてないかをチェックする二度手間が発生してしまうからです。

文献『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』の中盤では、アルファ版あたりの段階でのテストプレイにも言及しており、ニュアンスは本wikiのこのセクションと違いますが、文献ではこの段階でのテストプレイではゲーム全体のクオリティにも気を配る必要があると説明しています。ただし文献では、セクショナリズムに陥らないように他人の担当範囲も積極的にカバーしようという意味での「全体のクオリティ」という表現を用いています。

若干の例外

ただし、バランス調整前のテストプレイにも若干の利点もあります。作者がバランス調整すら終わってない、ほぼ未検証のエリアなので、もしかしたら大きなバグがある場合があります。そのような大バグがあるかないかを知れるのは、情報としては若干の価値があります。

とはいえ、やはり上述のように未調整エリアのテストプレイは二度手間になってしまうので、できるならば、なるべくバランス調整が終わった箇所からテストプレイでチェックしていくほうが効率的です。

無料ゲームならば、もし、なにかの締切などまでに間に合わず、バランス調整の追いつかないエリアが締切日に残ってしまったとしても、対応としては、単にその未調整エリアを一時的に封鎖する仕様にして対処すればいいだけなのです。（そして後日のアップデートで、バランス調整の終わったエリアを公開していく仕様に更新するなどの対応すれば済むので。）

なので、やはり、バランス調整しおわったエリアから順番にテストプレイするほうが、二度手間が無くなるので、効率的ではあります。

すべての組み合わせの検証は無理

たとえばRPGなら、武器や防具といった装備の組み合わせは、

もし武器（剣や槍や斧や杖や弓など）が合計で100種類、

頭防具が合計で50種類（カブトや帽子）、

胴ヨロイや服が合計で50種類、

だとしたら、組み合わせは装備だけでも合計で 100×50×50 ＝ 250000種類 （25万）にもなってします（いわゆる「組み合わせ発散」）。

つまり、もしすべての組み合わせを検証しようとすると、作業が指数的に増えてしまいます。しかし、こんなに多くの組み合わせを検証するのは個人では無理ですし、無駄です。

デバッグ検証はせいぜい、武器なら100種類の装備をすべて装備してみて、装備できるキャラクターが装備しても異常が無いかとか、戦闘で実際に攻撃を見て以上が無いかとか、そういうことを確認すればいいのです。

同様に、防具のデバッグ検証もそうです。

これなら、装備の検証作業は、100＋50＋50＝200種類なので、大幅に作業が減ります。

つまり、足し算、加算的に検証すれば、十分です。

実際の市販のRPGなら、さらに装備の数が多くなるでしょう。

また、どのキャラクターが装備するかとか、どこのエリアで装備するかとか、いろいろな組み合わせが実際のプレイにはありますが、もちろん、そんな検証をすべてするのは無理で無駄です。

上記の例ではRPGの装備システムを例にとりましたが、別にRPGやシミュレーションゲームなどのパラメータの多いジャンルのゲームに限らず、 異なるジャンルのたとえばアクションゲームやアドベンチャーゲームなどのゲーム内の各種システムでも同様です。

なのでデバッグは、ゲーム内の各種のアイテムやコマンドなどのデバッグなら、せいぜい、とりあえず、そのアイテムやコマンドなどを選択したり実行しても異常が無いかを1回だけ試せばいいのです。

そもそも、ゲームのシステムは基本的に、プレイヤーごとに異なる多様なプレイスタイルに対応するために多くのアイテムやパラメータやイベントをゲーム内部に持っていて、そういった組み合わせの意外性などをシミュレートして楽しむものです。

なので、組み合わせは膨大になるのが普通なので、全組み合わせの掛け算的な回数の検証は無理です。

テレビゲーム黎明期の1980年代なら、装備アイテムの数などが少なかったので、もしかしたら組み合わせをすべて試すのも可能だったかもしれませんが、しかし現代では、アイテムの数などは膨大に増えており、もう無理です。

なので、プログラマー視点では、もしバグがあっても、そのゲームをクリアできるようにゲームを設計する必要があります。このためにはどうするかというと、デバッグの困難な箇所は、そのゲームのクリア要件から外す、という手法で簡単に出来ます。とはいえ、イチイチ考える必要はなく、一般のゲームのクリア条件は普通、そういうふうになっています。たとえば対戦格闘ゲームなら、敵を打撃してライフをゼロにまで持っていけば、途中経過は問わないワケです。こういうふうに、クリア要件さえ満たせば途中経過は問わない、というふうにクリア要件を設定すればイイだけです。

また、現代の複雑化したゲームでは、ver1.00以降の発表後にも、アップデート修正が必要になる可能性が高いです。なので、ver1.00の発表前に事前にアップデート版の配布が可能な環境を整えておきましょう。

さらに、もし有料ゲームのアップデート配布の場合なら、なるべく

有料版ソフトを買った人だけに、無償でアップデート適用ずみのフルパッケージ版を配布できるような環境

があるかを事前に環境準備しておく必要があります（「修正パッチだけ無料公開」とかではなく、すでに修正パッチを適用した状態でのフルパッケージ版という意味。消費者が有料で購入しているのだから、修正パッチ適用などの手間を掛けさせない。）。

いちおう、差分アップデート的な修正パッチ適用という方法もありますが、しかしバグが比較的に軽微な場合にのみ有効な方法です。バグがもし致命的な場合、差分パッチでは修正が不可能になることもあります。

個人でそういう配布の環境を構築するのは困難なので、個人の場合には、ネット上のいくつかの企業がソフトウェア公開・販売環境を提供している企業がいくつかあるので、そのサービスを利用すると良いでしょう。

さらに、アップデート版のソフトウェア内部のシステムでは、過去バージョンの有料ゲームから、最新の修正後バージョンへのプレイデータの引継ぎをできるようにする必要があります（たとえばRPGの場合、プレイヤーにレベル1の序盤から再開させるワケにはいかない）。このデータ引継ぎの工夫は、ソフトウェア販売サービス提供の企業では無理なので。

（なおこのため、セーブデータの構造を変更するような修正は不可能か、大幅に制限があります。アップデートによるキャラ追加などは可能ですが、パラメータの構造そのものの変更などは、リリース後は不可能または困難でしょう。ゲーム中のシナリオ進行度合いの保管なども同様、リリース後の変更は困難です。）

もし、上述のようなアップデート配布が不可能な環境にあるのなら、そのゲームが個人製作のゲームの場合には、無料ゲームソフトにしておきましょう。

ゲームにかぎらず一般に有料ソフトを販売した場合には、開発元のメーカーは「保証期間」または「アフターサービス」のような社会的責任として、発売開始後から数年ていどは無償で不具合対応などのアップデートをすべきという社会的な責任があります。

食料品やティッシュペーパーのような消耗品でないかぎり、ソフトウェアにかぎらず一般の工業製品などでも企業は商品の有料での販売においては、発売開始後から数年は、「保証期間」などとして無償または低価格の不具合対応などの社会的責任が要求されます。

無料のソフトではそこまで保証する義務は無いですが、まあ実務の練習だと思って「保証期間」的なものも頭の片隅に意識しておいたほうが無難でしょう。

ソースファイルにモニター（監視）機能を入れる

主にアルファ版や新機能の追加時のテスト方法ですが、

もうひとつのバグ発見の方法として、「printf デバッグ」と俗に（ぞく）言われる手法があります。

これは単純で、printfなどの文字表示をするためのプログラム文で、バグに関連しそうなパラメータを画面中に表示して、異常がないかを監視する方法です。

ただし Windows のVisual C++ デスクトップアプリの場合、コンソール用の printf では文字表示できないので、 TextOut 文で表示する事になります。（※ Windows API プログラミングについては wikibooks『Windows API/文字表示の命令』などを参照せよ。） Visual C#でも命令文は異なりますが、同様に printf ではなく別の命令文ですので、それぞれのプログラム言語にあわせた文字表示命令の関数をつかうことになります。

ゲーム内のシステム内部の監視のためのデバッグ用メッセージ（「現在のパラメーター herosPower は 134 です。」のようなメッセージ）を表示するモニター的な機能は、（ユーザーに公開するゲーム実行ファイルではなく）ソースファイル側で行うとよいでしょう。

なぜなら、プレイヤーが細かいシステムメッセージを見ても退屈ですので。

一般にゲーム開発では、作者用のソースファイルと、プレイヤー用のファイルを分けるので、作者用のソースファイルにデバッグ用の機能をいくつか入れておく方法もあります。

まずテストプレイしよう

アルファ版でもベータ版でも、まずバグ発見のためには、モニター機能プログラムを書くよりも先に、まず先に実際にゲームを起動してゲームをプレイしてみることです（いわゆる「テスト プレイ」）。テストプレイで挙動のオカシイ部分があったら、そこで、ソースコードで、挙動のおかしい箇所のプログラムの近辺で、変数の内容を表示する機能のあるモニタープログラムを自分で書きます。

なお、モニタープログラムは本wiki本ページの独自用語です。ゲーム業界でどう言ってるのか知りません。

ブレークポイントは後回し

なお、WindowsのVisual Studio には、ブレークポイントという、デバッグ用にコード中に強制停止するポイントを設定する機能があり目的の箇所でコードを停止させ、変数を表示させる機能がありますが、しかしこの機能（ブレークポイント）をいきなり使うのは、ゲーム製作では、あまりオススメできないです。

なぜなら、ゲームが止まってしまうので、実際のプレイ中でのパラメータの変化が不明です（ブレーク時点での変数の値しか、分かりません。）。

ブレークポイントを使う場合は、起動そのものの不可能なバグとか、ゲームが異常停止していまうようなバグの場合などの、テストプレイそのものが困難な重篤なバグの場合にだけにしましょう。

テストプレイが可能なていどのバグなら、なるべく実際にゲームをテストプレイして、モニタープログラムでバグの性質をさぐったほうが早いです。

モニタープログラムは最小限にするのがコツ

しかし、まだバグの見つかって無い段階で、モニタープログラムを入れるのは、オススメできません。なぜなら、ソースファイルが見づらくなるからです。

だからバグが見つかってから、関連しそうな変数を表示するモニタープログラムを書きましょう。つまり、モニタープログラムは最低限にするのがコツです。

そして、バグが修正し終わったら、そのモニタープログラムのコードは、量が多くなってきたら場合は、さっさとソースコードから該当する変数のモニタープログラムをコメントアウトするなどして、非表示にしてしまいましょう。

なんでもかんでもシステム内メッセージを画面に表示したとしても、メッセージを読みきれないので無理です。

また、あまり、ソースファイル独自の機能を追加しすぎると、一般にソースコード自体が読みづらくなります。

典型的なバグ

配列のバグ

ゲームを作る場合、典型的かつ重大なバグは、配列に関するバグです。どのゲームでも、配列を使います。

極端な事を言うと、配列以外の変数名などの不一致のバグなどは、Visual C++ で作っている場合なら、変数名のバグはそもそもコンパイルできない場合が多いので、コンパイラが自動的に変数名のバグを発見してくれます。

必然的に、残されたバグは、配列のバグと、あとはゲームの仕様に一致してないという類のバグです。

仕様に一致しているかどうかは、コンパイラでは発見できないので、プログラマーやテスターなどが自力でテストプレイによって発見する必要があります。

配列のバグでよくあるバグは、下記のようなプログラムミスが多いでしょう。

• 典型例

宣言数よりも番号が多いバグ

配列で、たとえば hairetu[10] の10個までしか宣言してないのに hairetu[13] を呼び出すなどのように宣言した数以上に呼び出したり、よくあるバグです。

数え間違え

また、配列の番号は0番から数え始めるので、 hairetu[0] から hairetu[4] までの5つしか値を用意してないのに hairetu[5] を呼び出してフリーズしたりなど、よくやるミスです。

音声バグ

プログラミングは集中力を使うので音声をオフにしてプログラミングする場合もあります。

ツクールやウディタなどで制作ツールで開発している場合はそこまで集中力が無くても何とかなりますが、 しかしC++などプログラミング言語で開発している場合、かなり集中力を要します。

よって、このような場合、プログラマー側でのテストプレイ時に音声をオフにしている場合があります。

だからテスターとしては、こういう事情も見越して、音声を聞きながらテストプレイする必要があります。

特にゲーム中で1回しか起こらない特殊イベントなどは、そのプログラムを特注的にプログラマーが作っているので、 バグが混入しやすくなります。

たとえば、テスター依頼を受けたRPGで特殊イベント「封印の壁の破壊」というのがあったとして、仕様では、

貴重品アイテム「魔法の爆弾」が、

場所「封印の壁」のすぐ前で使うと「ドッカーン」と音声とともに1回だけ爆発して、

壁が崩れて通行可能になる、

という仕様だとしましょう。

この際、バグで「ドッカーン、ドッカーン、ドッカ－ン、ドッカーン（以下略）」と1個しかないのに何発も爆発する音声が流れ続けるバグなど、 ありがちです。

あるいは、最初にこの「封印の壁の破壊」イベントを実装したバージョンでは何事もなく正常でも、その後のプログラム改修によって不整合が起きて、この部分にバグが起きたとしても、プログラマー側のテストプレイではたびたび、こういう音声バグは見落とされます（集中力のため音声オフにしている場合が多いので）。

だからテスター専門として活動している場合は、必ず音声を聞きながらテストプレイしましょう。

バグの発見後の原因調査の方法

バグそのものの有無は、テストプレイによって発見できます。

ですが、そのバグを引きおこしている原因の探査は、テストプレイだけでは不可能です。

こういったミスを発見する方法も、上述のように、printfデバッグ的にモニタープログラムを書くことでパラメータの動向を追う事で、バグのありかを限定していきます。

（正常な値の数値がprintfデバッグの画面に表示されている場所にはバグがないので、つまり、まだ確認されてない残りの場所にバグが潜んでいます。）

そして、上記printfデバッグのような方法でテストプレイ中にモニタリングしつつ、バグ発生箇所の周囲でテストプレイを色々なパターンで試していくことにより、バグの発生原因などを絞り込んでいきます。

なお、通しプレイは、このプログラミング段階でのデバッグでは（通しプレイは）不要です。この場合、すでにバグの発生箇所は限定されて分かっいるので、上述のように局所的なチェックによるテストプレイをしていきます。

そして、バグ原因を突き止められてコードが修正し終わったら、コードの修正後に再度、局所的なテストプレイで何種類かの行動パターンでチェックします。ここでは、テストプレイは不要です。（通しプレイは後でまとめて行う。）

一つのゲーム開発につき、バグ発生箇所は何十個や何百個も存在しており個数が多いので、通しプレイは 後で まとめて 行いますので、この段階ではまだ通しプレイは行いません。

共通作業の自動化・省略化　

文献『ゲームデザイン プロフェッショナル』（塩川洋介 著）では、「調整」の説明ですが、「手動で毎回行っている繰り返し作業を、あらかじめ登録した一連の処理として自動的に実行するプログラム」を作っておくと、調整が効率的だと、塩川氏は述べています。

塩川氏の意見ではないですが、開発中ゲームのプログラマーによるデバッグでもこのような繰り返しの場面はよくあります。

たとえば、所持アイテム数がなぜか8品（8種類のアイテムを持っているとする）ある場合にだけ画面がフリーズするバグがあったとして、 そのゲームの初期状態では所持アイテムは0品（アイテムがない状態）だとしましょう。

プログラム修正は、けっして一度で修正できることはまずないので、五回や十回とか、何度もテストして、修正できているか確認することになります。

この場合、プログラム修正作業中のテストを何回もするたびに、いちいちアイテムを0から開始して8品目まで買い揃えたり、そのために敵を倒してゴールドを稼ぐのは、面倒です。

だから最初から、アイテム8品をもった状態のデータをゲーム中に作っておきましょう。そうすれば、テストが効率的です。要するに、テスト作業中に何度も繰り返す工程の自動化です。

すでにバグがあると分かっている箇所や、通常プレイだとテストしたい状態の準備に著しく時間が掛かる部分など（たとえばゲーム後半の状態や、やたらと長いダンジョンの出口の直前または直後の状態など）、あらかじめその直前の状態にワープできるシステムがあると、テストが効率的です。経験値やゴールドをためるのも時間が掛かるので、何らかの方法でプログラマー側では作業をカットできるようにして、つまり既に主人公が高レベルで強い状態に設定変更できるなど、そういう機能が必要になるでしょう。

ゲームのオリジナルの初期値データを書き換えると他のバグを起こして怖いので、デバッグルームにそういう機能を導入するなどして、けっしてオリジナルデータとは混在しないようにする必要があります。上手く自動化をしてください。

こういうデバッグ機能を使ったテストが、プログラマー側による局所的チェックのひとつになるでしょう。

ゲーム開発初期のデバッグでは、そこまでする必要はないでしょうが、しかしゲームの完成度がだんだん上がっていくにつれ、次第にそういう自動化の必要性が出てきます。

また、こういう設定準備の自動化の機能は、バグ修正テストだけでなくバランス調整にも活用できるので、こういった機能があると一石二鳥です。というか、もともと文献『ゲームデザイン プロフェッショナル』では、バランス調整のための機能として紹介されているくらいです。

デバッグルームなど

デバッグルームとは

ゲーム内でめったに起きないイベントなどのデバッグは、通常のプレイ方法では、めったに遭遇しないために発見が困難になります。

たとえば、ゲーム内でくじ引きがあり、1000分の1で大当たりが出るとしましょう。（※ 説明の単純化のために、極端に確率を低くしている。実際のゲーム製作では、低すぎる確率は避けたほうがデバッグしやすく安全である。）

通常のプレイでは、このくじ引きを1回だけしか出来ないとしましょう。

このようなイベントのデバッグ検証の場合、「大当たり」にバグがないかは、デバッグ用に、ゲーム作者だけ、くじびきを何百回も続けてチャレンジできるようにしたりとか、あるいは、ゲーム作者だけ、くじ引きの結果を操作できるようにして強制的に「大当たり」が出たりするようにするとか、

そういう作者だけの特殊システムが必要になります。一般プレイヤーには、デバッグルームには入れないように、対策する必要があります。

たとえばファミコン版のドラクエ2やドラクエ3には、「死のオルゴール」という、使用するとパーティが全滅するという謎のバグアイテムがあり、普通のプレイでは絶対に入手できません（バグ技などを使う必要がある）。おそらく「死のオルゴール」はデバッグ用のアイテムだろうと思われています。

これがもし「全滅スイッチ」とか「全滅ボタン」とかだったら、なんか機械的で、ドラクエの中世西洋ファンタジーの世界観に雰囲気に合いません。もしバグでプレイヤーに「全滅スイッチ」が見つかったら、プレイヤーの抱いていた世界観のイメージが崩れます。

でも「死のオルゴール」なら、もし万が一、プレイヤーが発見しても、「オルゴール」という中世からある楽器の名前なので、なんとかゴマかせます。

このような、デバッグ用の作者専用システムのことを、俗にゲーム業界では「デバッグルーム」とか「デバッグモード」とかいいます。デバッグルームとは「デバッグの部屋」という意味です。作品によっては、実際にゲーム内に「デバッグルーム」というエリア、ステージを用意する場合もあります。

この機能を作者が使うことを「デバッグルームに入る」とか「デバッグモードをオン（ON）にする」いいます。

名前こそ「デバッグルーム」や「デバッグモード」などというものの、しかし、その場所ではバグそのものの退治・修正はしないですし、そもそも、ゲーム起動中にバグ修正は不可能です。

最終的にバグを修正するには、（ゲームをシャットダウンさせてから）ソースコードを開発ツールなどで直す必要があります。

「デバッグルーム」とは、単にゲーム内でバグ探しの作業をしやすいように、プレイヤーキャラクターを強化したり、あるいは敵を弱体化させるなどの環境を調整するだけなのが、デバッグルームです。

背景として、基本的にはプレイヤーキャラクターが強めのほうが、ゲーム内世界をいろいろと探検しやすいのでバグは発見しやすくなります。

なぜならゲームでは、たとえばRPGでゲーム終盤の強敵を倒したときに発生するバグなどは、主人公がゲーム序盤の弱いキャラクターの状態では無理です。一方、ゲーム序盤の弱い敵に主人公が負けるなら、単に油断したり無防備になればいいだけなので、主人公は強いままでもデバッグ可能です。

「大は小を兼ねる」といいますが、ゲーム内では強めのキャラは弱めのキャラを兼ねます。

しかし、その逆は困難です。

なので、たとえ、デバッグ用の機能の名前に「デバッグルーム」などの名前がついていなくても、もし裏技や隠しアイテムなどでプレイヤーを強化するものがあれば、実質的にデバッグモードでしょう。

また、ゲームクリア後に、初回プレイよりも強い状態でニューゲームを出来る機能があれば（いわゆる「強くてニューゲーム」）これも実質的にデバッグ機能として活用できます。ゲーム序盤～前半のイベントに潜むバグなどを探すには、「強くてニューゲーム」のような機能があれば便利でしょう。

プレイヤーによっては、「デバッグ」などのIT用語を嫌がる人もいるので、そういうのに気をつける必要もあります。

また、ゲームのジャンルによって、近未来SFファンタジーやSFアクションなどでは、ゲーム中のシナリオにもIT用語が出てくるので、そういうのと区別するために「裏技」などの言い換えをしたほうがいいかもしれません。

デバッグルームの建築

さて、デバッグルームを建築する際は、なるべく、既にそのゲーム内にあるシステムを流用します。なるべく、一般プレイヤーにも公開されている機能を組み合わせてルームを作る必要があります。そうしないと、デバッグルーム独自機能の検証の手間が増えてしまうので、かえって、メンドウになってしまいます。

デバッグルームの中では、普通のプレイヤーが操作できないものを操作できるようにします。たとえば、RPGなら、プレイヤーキャラのレベルをある程度の上昇させたり下げたりとか、主人公の入手している武器や防具ある程度の範囲でを操作したりとかの機能が必要です（けっして、完全に数値をピッタリ調整する必要はないです。最終目的はあくまでバグ発見です。けっして数値をピッタリと調整することは目的ではないです）。

RPGなら、たとえば、強めの武器や防具をいくつかデバッグルーム内においておいたりとか、あるいは、通常プレイでは商店では非売品の武器・防具をデバッグルーム内では有料（ゲーム内の通貨）だが販売しておくとかすれば、万が一、一般プレイヤーがデバッグルーム内に進入してしまっても安全です。

あるいは、デバッグルーム内に、経験値アップや、レベルアップなどのアイテムとかをいくつか置いておくと、レベル上げの手間が減ります。

このようにデバッグルーム内に強化システムを配置しておくと、ゲーム後半のイベントなどの検証も、ラクになります（キャラクターの育成などに掛かる時間などが短くなるので）。

くじ引きの「大当たり」などのイベントをデバッグ検証で容易にしたいなら、デバッグルーム内に、たとえば「幸運のお守り」のような感じのアイテムを置いておいて、それを装備すると、ゲーム内のくじ引きなどの大当たりの確率が100％になるとか50％になるとかの機能をつけておいて、そういうふうなアイテムを作っておけば、くじ引きなどの検証がラクになります。

さて、一般プレイヤーには、デバッグルームには入れないように、対策する必要があります。

まず、デバッグフラグをオフにします。デバッグフラグがオンの状態でないとデバッグモード起動しないようにプログラムします。

しかし、それだけでなく、さらなる安全策が必要です。

たとえば、作者のファイルにだけ、デバッグルームに入れるアイテム（「デバッグルームの鍵」など）とかを、そのままの名前だと万が一プレイヤー側にバレると世界観が壊れるので、なんかファンタジーっぽい名前に変えるなどして作者データに設置するとかして、実装します。一般プレイヤーに配布するゲームデータには、デバッグルームの鍵などを与えないようにします。デバッグルームの場所は、ゲーム内の中盤や後半に隠して立てておくと安全です。

あるいは隠すのではなく正式な公開機能として、ゲームクリアしたプレイヤーに、デバッグルームの一部を開放するなどする方法もあります。こうすると、あまり気にやまなくても済みます。

または、ゲーム開始のオープニング画面中に、画面には表示されてないが実はパスワード入力を受け付けしている状態を起動させておいて、パスワードが正しければデバッグモードがオンになった状態でゲームを開始できるようにするとか、そういう方法もあります。パスワードの受付をしているのを、プレイヤーには見せないようにします。

アクションゲームなど、あまりRPGのようなアイテム配布をしづらいようなシステムの場合は、この裏技のような方法のほうが便利でしょう。

裏技システムの場合、もし一般のプレイヤーがたまたまデバッグルーム用パスワードと同じキー配列を入力しないように、パスワードは十分に複雑にしておくとかの工夫が必要です。万が一、パスワードを運よく一般プレイヤーが知らずに偶然に入力してしまってゲームを開始した場合でも、プレイヤーがゲームプレイを楽しめるように、「これは裏技モードです」とかとでも冒頭で紹介しておいて、プレイヤーキャラクターの強さを（通常モードと比べて）やや強めに変更するくらいの設定にしときましょう。

1980年代のファミコンなどの市販ゲームで、こういう「裏技」（うらわざ）がよくあります。おそらく、そのソフト開発者がデバッグ用に残した機能だったのでしょう。

プログラマーの小部屋づくり

実は、Visual C++ などのプログラミングでRPGを作るとき、

おそらく最初に作ることになるだろうマップが、

プログラマーが作成コードのデバッグ用にいろいろとキャラクターを操作するための、デバッグルーム的な小部屋です。

たとえば、その部屋の中に、位置固定のモンスターがいたり（戦闘チェック用）、武器防具屋や宿屋があったり（買物チェックおよび全回復チェック）、村人Aがいたり（会話イベントチェック）、冒険者の酒場の受付嬢がいたり（パーティ編成チェック）、とかです。

なぜモンスターと冒険者酒場の受付嬢が同じ場所にいるのか、ストーリー的には意味不明ですが、しかしプログラマーが動作確認する目的ならば何の問題もありません。

だって、たとえば戦闘のコードのテストをするのに、いちいちオープニングイベントとかを2分間も見たあとに王宮から城下町を通って洞窟に行くのを、テストのたびに繰り返すの、とても面倒じゃないですか。

あと、本編マップとか考えるのも面倒くさいです。

ツクールやウディタだけでゲーム制作していると気づきませんが、まあこういうプログラマーのための小部屋づくり（ゲーム業界で何というのか知りません）が、C言語などでのRPG制作にはあります。

さて、仮にプログラマーがデバッグ抜きでゲーム本編をとりあえず一通り作り終えたとします。

これからデバッグのために（上記のプログラマー部屋ではなく）デバッグルームを作る際、よくよく考えたらゼロからデバッグルームを作る必要はなく、以前に作ったプログラマー部屋を流用するだけで済みます。

たとえばいきなりレベル99とかにしたいなら、

すでにプログラマー部屋のほうで、どうせ戦闘デバッグ用に固定モンスター出現イベントとか作ってるので、そこに経験値999999999999とかでHP1とかHPゼロの弱いザコ敵でも置いとけば済みます。

あるいは、主人公がLv1の状態で最強武器（たとえばエクスカリバー）をいきなりゲットしたい場合でも、どうせプログラマー部屋のほうに宝箱とかあるんだから、その宝箱にエクスカリバー1本を入れとけば済みます。

とても楽チンです。

個別チェックと通しプレイ

まずは個別チェック・局所チェック

総論

ゲームで新しい機能を追加した場合、たとえばデバッグモードなどの機能を使ったりしてでもいいので、

まず、その追加したばかりの機能が実際に動作しているかを、（デバッグモードでいいので）プログラマー自体がチェックします。

もし集団作業なら、これはプログラマー本人がまず率先して、ある程度は自分たちでデバッグモードによるチェックをやる必要があるでしょう。（いちいち他の部署に作業を回すと、かえって時間が掛かってしまう。）

また、集団作業でなく個人製作でも、まずデバッグモードでも何でもいいので、追加したばかりの機能をチェックします。この個別チェックというか局所的なチェックでは、けっしてバランス調整などをする必要は無いです。

個別チェック・局所チェックと、バランス調整とは、目的が異なります。個別チェック・局所チェックでは、単に、デバッグモードなどで、その項目だけをチェックします。

もしデバッグモードの機能が無いゲームの場合や、製品に近くデバッグモード不搭載のバージョンの場合には、デバッガーは、なるべくデバッグモード利用時に近いプレイ方法で、個別にチェックしていきます。

異業種との関連

ソフトウェア業界だと、個々の部品ごとにチェックすることを「単体テスト」といいます。一方、全体的に組みたててみてチェックすることを「ビッグバンテスト」と言います。

両立するには、とりあえず「交互」

「交互」に関する余談だが、週刊少年ジャンプに2008～2010年連載していた『ヘタッピマンガ研究所R』またはジャンプ中のその関連記事では、 読者などからの相談・質問などの 「どうやったら立体感もあってデフォルメもされた絵を上手く描けますか？」 という問いに対し、回答者の漫画家・村田雄介は、おおむね「交互に、写真の精密模写と、マンガ絵のデフォルメの練習を、僕はしてきました」といったような感じの回答を言いました。

私たちのゲーム用の教訓としてこの考えをアレンジするなら、初めて挑む分野でスケジュールの配分やらの何やらの良く分からない仕事は勉強や、とりあえず「交互」にすればいいのです。あれこれ理屈ばかり悩む前に、さっさと交互に実行を始めれば済みます。

なおこの漫画家の村田氏は、子供時代にカプコンのゲーム『ロックマン』の敵ロボの募集企画に応募したハガキが採用される（「ダストマン」が採用された）ぐらいにはゲームキャラのデザインの実績ある実力者でもあります。

写実練習ついでに別の余談を話すと、同じ2008～2010年ごろ、たしか少年ジャンプあたりの雑誌で、かつてボボボーボ・ボーボボの連載してた若手（当時）の漫画家と、ハンターハンターの漫画家との対談で、

若手が「自分はデッサン練習する前に漫画家デビューしてしまいましたが、どういう練習したらデッサン力つきますか？」という内容の問いに対し、

ハンターハンター作者は「マール社のポーズカタログ集（※wiki追記: というヌードポーズ集がある）を模写するのが、おすすめだよ。あれやるだけで、僕ぐらいのマンガ絵に必要な程度のデッサン力なら、かなり近づく」というような感じのことを言いました。

そういう美術用の専門のヌードポーズ集があるのです。パンツ一丁のモデルの男女をそれぞれ別に、正面カメラ、横カメラ、斜めカメラで撮影した写真集があるのです。

だからいちいち、エロ本を購入する必要はありません。大体、エロ本なんて掲載ポーズが片寄っています。まあ当然です。ポーズ集ではないのですから。

エロ本は、不自然に腰をくねらせていたり、腹をひっこめていたり、腕を寄せて乳房を抱えていたり、ポーズが片寄っています。

しかしデッサン練習では、まずはモデルが普通に力を抜いて起立して立ってたり、あるいは普通に正座してたり体育ずわりしてたり、そういうポーズが必要なのです。そういう基本のポーズ集を模写して人体の比率を頭に叩き込むのが、漫画業界的な写実デッサン練習です。

エロ本などが必要なのは、エロマンガを描くときです。だからエロ漫画家の江川達也は、少なくとも90年代はAV（アダルトビデオ）マニアで有名です。江川のGOLDEN BOY のOVA版でも、最終話のアニメ会社勤務回では、作中のアニメーターが江川作品のアニメ製作ではエロ本を参考にしてます、とメタ発言しています。

重要なのは、ゲーム開発のデバッグにおいても、実際に「通しプレイ」というビッグバンテストが必要だという事です。「ビッグバンテスト」という名称の知識は、割とどうでもいいです（知識の無いよりかは、あるに越した事はありませんが・・・）。

本書は製造業ではなくゲーム開発の教科書なので、これ以上の製造業でのチェック方法への深入りを避けます。

演劇の世界でも、「通し稽古」（とおしけいこ、英：dress rehearsal ドレスリハーサル、ゲネプロ）と言って、劇の最初から最後まで実際に役者全員で、舞台装置も本番と同じものを可能なかぎり使って演技することで、シナリオや演出などに問題点がないことを確認します。高校生向けの演劇部の本にそう書いてありました。こういう確認作業の出来ない人は高校生以下なので、反省してください。

なお、アニメ業界でも、1990年代くらいまでは、アニメ業界での分業による生産システムを説明するのに、自動車産業などでの分業になぞらえてアニメの分業を説明したりする説明手法がよく行われていました。

デバッグではないですが、バランス調整や各種の演出・シナリオなどの面白さの確認でも、実際に通しプレイで確認する必要があります。商業ゲームでも、任天堂が『ゼルダの伝説　時のオカリナ』では、社員300人で通しプレイで最初から最後まで実際にプレイして確認したという手法でチェックしているというノウハウを公開しています。

ネットのバイト紹介記事などだと、こういう社員での通しプレイによるチェックなどは紹介されませんが、順序的には、チェックシートによる細かいチェックよりも、まず通しプレイチェックのほうが先です。

任天堂の場合も、デバッグを開発初期と終盤とで別々の方法に分けて、開発序盤からデバッグしています。（岩泉茂『【CEDEC2017】「ゼルダの伝説」作成を裏から支えたエンジニアたち　大規模プロジェクトをいかに効率的に乗り切るか』 、2017年9月4日 07:00。） 開発初期のデバッグでは、ゲームの面白さに関わる部分のデバッグを優先的に修正していきます。開発終盤では、製品化やリリースなどにむけて、今まで後回しにしていた細かいバグも修正していきます。

大規模なゲーム開発になると、開発初期からデバッグしないと、発売日・リリース予定日・公開日までに間に合いません。

しかし開発初期ではまだ全体像が出来ていないので、ゲームの土台の面白さが確認できたあとには、先にゲームの全体像を（細部はいいので）作らせることを優先します。これは任天堂だけでなく、女神転生シリーズのアトラスも類似の開発手法をとっています。アトラス社では「ゲーム全体に血を回さなければならない」という格言があります。

このように、実際にゲーム全体をゲーム序盤からエンディングまで一通り作ってみないと分からないので、まずは先にエンディングまで作ります。そのあと、細かい作りこみやデバッグなどの細部を仕上げていきます。

まとめると、順序としては、

ゲームの土台の面白さ確認（2Dなど単純なものでよい）
→ ゲーム全体を作る
→ ゲームのエンディングまでのとりあえずの完成後、細部の作りこみ

のように、段階が分かれていきます。

なので、それぞれの段階に適して調整方法なりデバッグ等の方法を変えていきます。

また、社内デバッグでは、テスター専門のヒト以外にも、各種のアーティストやプログラマーなどもテストプレイに参加しましが、彼らは本業のアート素材制作（ゲームに組み込みためのイラスト素材、音楽素材などの制作）で忙しいので、バグ報告後の次バージョンでの修正チェック確認などはテスターが受け持ちます（任天堂がそうしています）。

各論

全装備品の装備、全アイテムの使用など

たとえば、RPGの装備品のシステムが正常に動作しているかどうかを確認するためなら、とりあえず、すべての装備品をいったん装備および装備解除してみる、というような作業をします。

これは、一般プレイヤーがゲームを楽しむ方法とは、異なります。

ですが、デバッガーは、こうして確認をしていきます。

たとえばRPGなら他にも、すべての道具をとりあえず最低1回ずつは使ってみるとか、

到達可能なマップチップには、すべてのマップチップの上を歩いてみるとか、そういう事をします。

とはいえ、これらは普通のゲームプレイでも、プレイヤーによっては、アイテム効果確認や隠しエリア探索などのために、よくやる事でもありますので、これはまだ楽しいほうです。

通行止めの確認

さらに商業ゲームでは、たとえば、壁（かべ）の通行不能の処理が、本当に壁として行き止まりになっているかとか、通行止めであるかとか、そういう行き止まりチェックみたいな事も、します。

なお、この、本来なら行き止まりであるべきの壁が通れるバグのことを通称「壁抜けバグ」と言います。壁以外の海とかガケとかの行き止まりも含めて一般的な言い方をすると、「通行（つうこう）判定バグ」または「通行設定バグ」などと言います。

なお、「進行（しんこう）不能バグ」は、これとは意味が異なります。「進行不能バグ」とは、ゲームのストーリを進められなくバグのことです。

デバッグ（テストプレイ）でツライ事の一つは、この「通行（つうこう）設定バグ」の有無のチェック、つまり行き止まりチェックでしょう。

もし、スーファミ風のドラクエ・ファイファン的なゲームのようにマップがマス目で作られている2D-RPGの場合、デバッグ仕事でなら、すべての壁マスの通行設定を確認する事になります。

アクションゲームやアクションRPGの場合、すべての壁を1ドットずつ通行設定をチェックするのは、不可能です。なのでアクションゲームなどの場合、

とりあえず壁にぶつかって突進ボタンを押しつつ、横移動ボタンも押して移動するなどして、確認したりとか、

横移動ボタンを一瞬入力して少しだけ横移動した後にカベに突進、その後、また横移動ボタンを一瞬入力して横移動した後にカベに突進を繰り返す、・・・を繰り返してカベの右端から左端までチェックするのを、さらに何周も繰り返すとか、

でしょうか。(ということは、アクションRPGゲームまたはそれ風のマップ移動システム搭載のRPGでの壁通行設定チェックは、とてもハードな業務だという事になります。一方、アクションRPGでも、もし移動の単位が1ドットではなくマス単位だったら、頑張って1マスずつカベ通行設定をチェックするべきなのでしょう。)

ゲーム中で特に重要そうな壁のテストの場合、おそらく上記テストに加えてさらに、たとえば壁に向かって突進するのを何十回も、毎回微妙に突進先の位置を変えつつ突進するとか、あるいはナナメ移動とかジャンプしながら壁に突進するとか、色々と試すのかもしれません。

当然、とても面倒です。

なのでフリーゲームだと、この行き止まりチェックはよく、省略されます。なのでフリーゲームでは、ver1.00公開直後には、よくあるバグで、本来なら行き止まりのハズなのに通行可能になる壁のようなモノの存在するバグが、よくあります。

いくつかの通行バグの典型例

壁の窓や草など

壁のテストは基本的にはすべてチェックすればいいのですが、時間が無いときなどに短時間でチェックするために特にバグが発生しやすい場所をしいてあげるなら、

2D-RPGの場合、たとえば住宅の壁なら窓があったり絵が飾ってあったり、とにかく壁に何かあったら、まず通行バグを用心するのが鉄則でしょう。

屋外での崖や洞窟や壁や、海や湖などの仕様上では通行不能な場所でも、壁に石や草や花などがあったり、水辺に木片とか何か落ちてたら、まず通行バグを用心するのが鉄則です。

斜め壁のバグ

この他、テスターでない人には周知されにくい話題ですが、斜めの壁も用心です。

斜め移動システムのあるゲームの場合が問題であり、たとえ上下左右の4方向移動だけなら通行止めできていてもい、しかし斜め移動の通行止めができていないケースがあります。

具体的に言うと、下記のようなマップ配置では、斜め壁は、斜め移動で貫通できてしまいかねません。A地点からB地点に一直線に貫通できるバグが、少なからずあります。

• バグの多い例

         A
          ／壁壁壁壁
          壁／
          壁  B
          壁

だからこの場合、下記のように修正しなければなりません。

• 修正後

         A
          ／壁壁壁壁
          壁壁壁壁壁
          壁／
          壁

このように、バグ防止のために南北方向の壁の厚さが変わります。つまりRPGのマップ配置は、実はデバッグの都合によっても左右されています。

もし斜めの壁のあるマスがプログラムに絶対に通行不能な仕様なら良いのですが、しかし作品によっては立体感を出すために斜め壁のあるマスが通行可能マスになっている作品もあり、そういう作品では上記のようなバグに用心する必要があります。

斜め壁が2マス以上つづく場合の想定が必要

さて、前段落の方法とは別の解決法として、とえばA地点側にキャラがいるとき、「キャラの真下とキャラの真右が通行不能だった場合には、斜め右下には通行不可能」というプログラムを組んで、とりあえずの通行止めをしたとしましょう。

実はこの改修プログラムには欠点があります。しかし、下記マップのように、うすい壁が2つ続いている場合が想定モレであり、貫通バグの発生です。

バグあり

          A ／壁壁壁
   C      ／／       D
          壁  B
          壁  
          壁

上記マップは、たとえプログラム改修済みであってもAからBに貫通できてしまいます。なぜなら、A地点の右となりも真下も通行可能の斜め壁ですので。

なおC地点から一直線にD地点に向かっても貫通できてしまいます。

A側の壁が1つしかなければ貫通を止められるのですが、しかしA側の壁が2つ以上ある場合はもう貫通を止められません。

他の解決法としては、そもそも斜めの壁のマスを通行不能にするという方法もありますが、その場合はもう、斜めの壁に密着することはできませんので、そういう演出はできません。

あるいは、上記マップのような2マス続いている薄い壁にだけ、専用の通行判定プログラムを採用する、などの方式もあります。

結論として、どういう方式を取るにせよ、マップ配置はデバッグの影響を受けますし、マップ上で採用したいナナメ壁際でのキャラのグラフィック演出などもデバッグの影響を受けます。

創作するつもりがないなら、創作技法の余計な勉強はしないのが安全

前段落のように、ゲームの演出はデバッグの影響を受けます。だから、観客がゲームの仕組みをあまり知りすぎると、観客はゲームを素直に楽しめなくなってしまいます。手品と同じようにタネや仕掛けが分からないからこそ面白いのです。あるいは推理小説のようなもので、トリックが分からないから楽しめるのです。

ゲームにかぎらずマンガやアニメも同様でしょう。エンタメ系コンテンツの作家が仕組みや技法を黙っているのは、別に消費者への嫌がらせではなく、観客が素直に演出を楽しめるようにするために余計な情報は与えないでおこうという配慮でしょう。

ゲームに限らず、たとえばアニメ評論家の岡田斗司夫も、だいぶ昔の著作ですが1998～89年くらいに、岡田はおおむね「自分はアニメ製作の仕組みをしってしまっているので、テレビアニメを見ても、『このシーン、撮影台はこう動かしているな』とか思い浮かんでしまうので、一般の観客と同じような方法では楽しめない」という感じのことを言っています。

岡田だけに限らず、評論家以外の多くの漫画家やアニメーターも、似たようなことを言っている人は多く、程度の差はあれ、一介の観客だった時代とは大衆娯楽作品に見方が変わってしまう体験を、たびたび各所で色々な人が言及しています。

だから、あまりゲームのプログラミングに興味のない人は、この教科書『ゲームプログラミング』は読まないほうが良いでしょう。

選択肢の総確認

他にもデバッガーのすべき事は、たとえば、ゲーム中にもし、なんらかの選択肢の入力がある場合、選択肢すべての（当面の）結果を確認します。

たとえば、もしRPGのストーリー中の重要なシーンでのコマンド選択肢で、善行と悪事との選択肢があった場合、2つのセーブデータを用意して、両方の選択肢とも試してみて、とりあえず数分は動作しているかを確認します。

このように、とりあえず、どちらの選択肢を選んでも、当面の数分はバグの無く、正常に動作しているかを、（デバッグモードや、セーブデータの複数用意などで）なんらかの方法で確認します。

なお、一般ユーザーのプレイ傾向としては、もしゲーム中に選択肢で、善行と悪事の選択肢があったら、なんだかんだで普通のプレイヤ－は善行を選びます。

なので、もし普通のプレイヤーに任せていては、いつまで経ってもゲーム中では、ゲーム中の悪事の確認は、なかなか、できないです。

このためデバッガーは、意識的に、自分のプレイスタイルとは異なる悪事の選択肢でも、デバッグして動作確認する必要があります。

全滅テスト、自殺テスト

また、一般プレイヤーは、上手にプレイしたがるので、わざとゲームオーバーする自殺プレイを嫌がります。

なので、デバッガーは、ところどころで、自殺プレイをします。ゲームオーバーや全滅などのイベントが正常動作するかを、ときどき確認します。

難易度の高いゲームなら、意図的に自殺プレイしなくてもよく全滅しますが、たとい難易度の低いゲームでも、わざと自殺プレイをします。

特にボス戦などは、ソースコードでは特殊なフラグ処理が入りこんでいるのでバグの混入している可能性も高く、そのため、たとえ弱いボスであっても、ワザと敗北したりする自殺プレイが、デバッガーのすべき事です。

カウンターストップのチェック

たとえば、RPGのゲームの上限レベルが「99」の場合、きちんとレベル99で止まるかを、とりあえずデバッグモードでチェックします。

こうしたデバッグを短時間で出来る用途のために、やたらと経験値の高い敵でも一体、ゲームのソースファイルにでも混ぜて、作っておきましょう。

レベル98からレベル上げをしてみたりとか、レベル97から一気に2レベル上がったらどうなるかとか、いろいろと確認しましょう。

また、所持金や道具の個数なども同様に、上限できちんと止まることをデバッグモードなどを活用して確認します。

さて、とにかく上述のように個別デバッグ・局所デバッグをして、まずはデバッグモード（またはデバッグモードに近いプレイスタイル）で正常動作するようになるまで、まずプログラムを修正していきます。

もちろん、デバッグモードで正常動作したからといって、けっして、必ずしも通常起動のモードでも正常とは、かぎりません。

ですが、もしデバッグモードですら異常動作をするなら、これはもう通常起動時にも異常動作をするだろう事は、ほぼ確実です。（数学でいう「必要条件」と「十分条件」の関係みたいなもんです。）

なので、まずデバッグモードで正常動作するようになるまで、まずプログラムを修正していきます。

このように、追加した幾つもの機能を、それぞれデバッグモードで即座にチェックしていきます。

また、もし機能を新たに追加したい場合には、まず前の機能のデバッグモードでの正常動作を確認し終えてからにしましょう。なぜなら、こうしないと、集中力が落ちるし、また、もしバグが発生した場合の修正が、とても複雑になってしまいます。

IT業界の格言ですが、「デバッグされてないコードは、（資産ではなく）負債である」という格言があります。なので、コードを書くことよりも、自分で書いたコードをひとつずつデバッグすることのほうが重要です。

ともかく、このように、機能をひとつずつ、個別的にチェックしていきます。

ボタン連打や、壁に何度も衝突など

ボタンを1回だけなら押しても異常は無くても、ボタンを何度か押すと異常のあるバグも、ときどきあります。

とはいえ、ゲーム中の全てのシーンで何度もボタンを押していたら、ゲームが進行せずにデバッグも進行しないので、たとえばゲーム中で使用頻度の多いメニュー画面などでボタン連打するとか、あるいはイベント進行などで「ここが、もしかしたらバグが潜んでいる可能性がありそうだな」とか思ったところだけボタン連打するとか、工夫しましょう。

同様に、通行止めの壁などの場所なども、ときどき何度も壁に衝突したりしましょう。

わざと弱めのボス敵などに負ける全滅テストも、ときどき、2回以上はワザと全滅してみましょう。

壁衝突やボタン連打などのチェック中のデータは、なるべく混ぜない。

セーブ機能のあるRPGやシミュレーションや長いアクションゲームなどで、上述のようなボタン連打や壁衝突などのプレイを確認するとき、原則的にあまりセーブしないようにするほうが効率的でしょう。

なぜなら、もしそのゲームのあとのプレイで何らかのバグが発見された場合、原因として、ボタン連打などの影響を考慮する手間が増えてしまうからです。

1つのセーブデータで、複数の異常プレイの実験をしてしまうと、たといバグが発見できても、その原因が果たしてボタン連打の処理ミスなのか、それとも悪事のフラグミスなのか、ミスの箇所が不明になってしまいます。

なので、まずひとつのセーブデータでは１つの異常プレイだけにします。

もし、複数の異常プレイを一人のデバッガーがする場合には、セーブデータを別々に分ける必要があります。

同様に、ボタン連打にかぎらず、もし何らかのバグが発見された場合でも、たとい報告のためにセーブする必要があっても、そのデータはまだバグを発現していない未発症データとは分けて別データとしてセーブしましょう。

次に、通しプレイ

さて、こうして、いくつか機能をデバッグモードで局所チェックしていき追加していくのが完了したら、今度は次に、ゲームを最初から始めて、エンディングまでプレイをします。

このように、ゲームをオープニングからエンディングまでプレイすることを、「通しプレイ」（とおしプレイ）といいます。

概要

デバッグモードは原則的に封印

「通しプレイ」では、デバッグモードは原則的に使わないほうが安全です。通しプレイは、できるだけプレイ条件を一般プレイヤーに合わせる必要があります。

文献『ゲームプランナーの新しい教科書』でも、特に通しプレイとは限定していませんが、デバッグモードは限定的に用いるべきであることが巻末近くのコラムで述べられています。

RPGなら、よくある確認ミスで、たとえデバッグモード自体にはイベントなどのフラグに直接の影響を与える機能が無くても、本来なら入場不可能なゲーム内の場所にプレイヤーが入場してしまうと、その影響でフラグが変わってしまう場合もあるという、間接的にフラグに影響を与えてしまう確認ミスもあるので、なので通しプレイではなるべくデバッグモードは避けるべきです。

どうしてもデバッグモードを使う場合はファイルを分ける

どうしても通しプレイでもデバッグモードを使わざるを得ないゲーム内現象をテストのために確認したい場合は、通しプレイのゲームファイルをデバッグモード使用バージョンと非使用バージョンとに分けましょう。セーブデータ分けだけではなく、ゲームファイルごと別々に分けるのが安全です。 ｓ しかし、そこまでしてファイル分けをしても、よくあるミスで、ファイルが本来「デバッグモード使用バージョン」なのに、間違えて「デバッグモード非使用バージョン」として保管してしまうミスもあります。

後述ですが、ゲームファイルやセーブデータをプログラマーからの確認待ちなどのため、複製してファイル数が何十倍にも増えますので、ファイルが多すぎるので、よくあるミスで、デバッグモードの使用バージョンと非使用バージョンとのファイルがときどき混入してしまいます。

なので、原則的に通しプレイではデバッグモードは封印する、などの自己規律的な方針をもっておくほうが安全です。

また、デバッグモードを使わないとレベル上げなどに時間の掛かりすぎるゲームの場合、そもそも、そのゲームのゲームバランスやレベルデザインなどが調整不足で崩れている可能性があります。（ただし、バランス調整チームとテストプレイチームとは別々のチームであるのが一般的ですが。）

そういった意味合いを含めて、とにかく通しプレイではなるべくデバッグモードを封印しましょう。

保管中のゲームファイルが10～20倍に増える

また、通しプレイでは、バグ報告後のプログラマーからの返事待ちとかのゲームファイルも保管するので、1つの作品あたりゲームファイルを20個～30個くらい最終的に複製したりするので、パソコンに保管するゲームファイルの数がかなり多くなります。たとえば作品1個は500メガバイト（0.5ギガバイト）のサイズでも、保管中のゲームファイルのサイズが合計で10ギガバイト超えとかになる場合も多々あります。

フリーゲームや同人ゲームなどゲームファイルのサイズが比較的に小さい（高々1ギガ程度）なら、データの控えのための複製の際は、ゲームファイルごとセーブデータとセットで複製してしまうほうが安全です。もっとも、さすがに20ギガ以上もあるような商業ゲームの大作ではファイル複製は非効率でしょうが、しかし高々1ギガ程度の作品ならゲームファイルごと複製して通しプレイしたほうが安全です。

その他

さて、とにかく通しプレイは時間にかぎりがあるので、たとえばある程度の週の間隔を置いて、前回のクリア以降に新バージョンが出てたら行うとか、そういうふうに工夫します。（もし機能の追加のたびに通しプレイすると、時間が不足する。）

さて、商業作品の場合、通しプレイでは、けっして上手にプレイするのが目的ではないのです。

とりあえず、色々なことをそのゲーム中でしてみて、それでもバグが起きないことを確認するためのモノです。

手順

1回目の通しプレイ

とはいえ、最初の1回目の通しプレイでは、まず普通に、自分のやりたい自分本来のプレイスタイルでプレイするのもイイでしょう。（もしもゲームのクリア所要時間が長すぎる場合や、クリア困難な難易度の場合には、とりあえず数時間ほどのプレイで区切るべきだろう。）

なぜなら、世間の他人から見れば、アナタのプレイスタイルも、他人にとっては「色々なプレイスタイル」のひとつですから。

また、そのゲームの中でどういった行動が可能なのかを知るためにも、とりあえず最初の1回は、普通にプレイする必要があります。

なお、特に仕事的な規律も無く、気の向くままにプレイすることを「フリープレイ」と言います。つまり通しプレイの最初の1回目は、フリープレイ的なプレイでよいでしょう。

2回目以降の通しプレイ：パターンA

さて、とりあえずの1回目の通しプレイが終わったら、2回目以降の通しプレイでは、プレイスタイルを変えます。

けっして、通しプレイの目的は、「エンディングに最短時間で到達する」（×）とかではないし、「上手にプレイする」（×）とかでもないのです。

自分のプレイスタイルではなく、自分以外のスタイルで、他の多くのプレイヤーがやりそうなプレイをします。

とはいえ、プレイスタイルを変えてみるのも、（自分の性格にもよりますが）そんなにツマラナクは無く、1回目では見過ごしていたイベントを発見できたりとかも出来ますので、さまざまなプレイスタイルを自身で再現してみることで今後の自分のゲームとの付き合い方の勉強にもなります。（というか、コレがツマラナイと感じる人は、そもそも性格的にデバッガーに向いてないので、別の職種を頼むべきかと。）

また、1回目と同じプレイスタイルでプレイしても、どうせ1回目で見たことある現象と同じ現象しか見られないので、むしろ2回目以降はプレイスタイルを変えたほうが面白くなるでしょう。

2回目以降の通しプレイ：パターンB

普通のプレイヤーは、ある程度は上手にプレイしようと目指します。

また、ゲーム中の選択肢で、善行と悪事のどちらかを選ばせる選択肢がある場合、たいていの一般人は善行を選びます。

なので、彼ら一般人と同じプレイスタイルでは、たとえばもし、ゲーム序盤のとても弱い敵に負けた際に発生するバグがあったとしても、そういうのは発見されづらくなります。

なので、ときどき意図的にヘタな通しプレイをします。

事前のデバッグモードなどでの局所チェックでも、このような確認はしているハズですが、確認モレがあったり、あるいは通しプレイ時にしか発生しないバグなどもありうるので、念のため通しプレイでも、意図的に下手なプレイをします。

壁衝突やボタン連打などのチェック中のデータは、混ぜない。

通しプレイでも、ときどき壁衝突のテストや、ボタン連打などの異常プレイのテストは必要ですが、しかしそれらのセーブデータは、なるべく、（自分以外の）通常プレイヤーの行動再現のセーブデータには、混ぜないようにしましょう。

また、さまざまな選択肢を選んでプレイしているセーブデータにも、ボタン連打プレイなどのプレイデータは混ぜないようにしましょう。

もし今後、何らかのバグが発見された場合に、もしひとつのセーブデータにて壁衝突・ボタン連打プレイ・通常プレイヤー再現プレイ・選択肢チェックのデータをセーブしてしまうと、せっかくバグ発見できても、想定されるバグ原因としてボタン連打などの影響の可能性などが増えてしまうからです。

ただし、通しプレイの場合、さまざまなプレイスタイルの再現中に、ゲーム中の選択肢などで、やや変わった選択肢をする場合もあるし、ややゲームの苦手なプレイヤーの行動を再現する場合もあるので、（つまり、選択肢プレイと苦手プレイは）そういうのまではセーブデータを分ける必要はないでしょう。（もしそこまでセーブデータを分けると、セーブデータ数が膨大になり、管理しづらくなる。）

よほどの異常プレイでないかぎり、セーブデータを分ける必要は無いでしょう。

しかし、かなり異常なプレイを意図的にする場合には、セーブデータを分けるか、あるいはセーブしないようするなど、工夫しましょう。

バグを発見したときに、原因の特定が容易になるように、セーブデータを分類して管理しましょう。

全体の流れ

さて、一般プレイヤーの行動を再現しただけの通しプレイがなぜ重要なのかというと、コレによって、重症なバグの有無を確認できます。

「クリア不可能バグ」のような重症なバグは、実際に通しプレイをしてみないと、分かりづらいのです。

また、クリア不能バグでなくとも、もし一般プレイヤー的な通しプレイなのにバグが発見された場合、これは発生確率の高いバグなので、どちらにせよ優先的に直す必要があります。

デバッグで重要なことは、けっして単に多くのバグ報告の件数を増やすだけではないのです。

件数ではなく、重度の高そうなバグから発見する必要があります。単にバグ報告の件数を増やすだけなら、通しプレイをせずに、個別チェックだけをしたほうが、形式的にはバグ報告の件数が上がります。しかし件数だけではなく重度も気にするべきなのです。

裏を返すと、いったん、一般プレイヤーの行動を再現した通しプレイをしたら、しばらくは通しプレイをする必要は無いです。なので、個別チェックと通しプレイとを交互に繰り返すのが効率的でしょう。

よって全体の流れとしては、おおむね、

1. プログラマーなどがデバッグモードでもいいので新機能の個別チェックをして
2. 次に、通しプレイによって大きいけど少ないバグを潰し、
3. 再度の個別チェックによって、小さいけど件数の多いバグを潰します。
4. その個別チェックが終わったら、また通しプレイ。
5. 同様に、個別チェックと通しプレイとを交互に繰り返し。

のようになります。また、このようにすることで、バグの大きさと潜伏範囲とをどんどん小さく狭めていけるので、効率的にバグを潰せていきます。

個別チェック漏れのチェック

個別チェックなどで事前に、それぞれの機能のチェックをしているハズですが、 しかしチェック漏れのある場合もあります。

なので、上述の手順のように、通しプレイと個別チェックとを交互に繰り返します。

集団制作におけるソフトでのバグ報告の書式

ゲーム業界に限らず、IT業界ではバグ報告の書式がおおむね、下記のように決まっています。最低限、次の情報がまともなバグ報告には必要です。

・バグの症状 :

・バグの発生方法 :

・発生の頻度 :

・バグ発生したソフトのバージョン :

と言った情報が最低限は必要であり、その報告が『バグ報告』である事とともに伝えます。

要するに、サラリーマンの社内の『ホウ・レン・ソウ』（報告・連絡・相談）のメールやIT企業などでのバグ報告メールなどと同様の書式です。

個人作業では不要ですが、集団作業の際などに、ご参考に。

ゲーム業界に限らず、リナックスなどのオープンソースのソフトウェアなどのバグ報告サイトでも、こういったバグ管理手法をしています。（というか、そういった海外プログラマーのバグ管理手法を、日本プログラマーが真似たと思われる。）

ゲーム業界でも同様に、こういったバグ管理手法です。

つまり、会社などで業務としてバグ報告をする場合には、ダメな報告の例としては「ゲームが壊れた！ どうにかして！」とか「ゲームが止まった！ どうにかして！」みたいなのは、論外という事です。

また、誰が決定するかはともかく、

修正の優先順位

という項目も、ゲーム業界でも一般IT業界でもあります。ゲーム業界の場合、クリア不能バグや、強制終了バグなどは、優先して修正しなければなりません。

そのほか、現在の状態（手つかずか、修正中か、検証中か、など）の項目もあります。

さらに日本のゲーム業界の場合、画像のスクリーンショットも添えて説明することも多くあります。

まとめると、

・バグの症状 :

・バグの発生方法 :

・発生の頻度 :

・バグ発生したソフトのバージョン :

・修正の優先順位

・スクリーンショット

・状態

となります。

文献『ゲームプランとデザインの教科書』によると、バグが起きたときに、それを騒ぎたてる人は、開発現場では、嫌がられるようです。プログラマーは集中力を使っていたりして、神経質なのです。なので、「そっ」と教えてほしいようです。

さて、下請け仕事でデバッグをする場合、自分は客ではないので、「ゲームが壊れた！ どうにかして！」みたいな報告は論外です。

とはいえ報告の時点では、まだバグの原因が不明ですので、けっして、完全にピンポイントな原因特定をした報告は、不可能です。

なお、IT企業などでは、バグ報告については、社内サーバーに専用のページが用意されていたり、あるいは社内サーバーのバグ報告用エクセルなどに記入する方式だったりしますが、いずれの方式にせよ、上述のバグ発生方法・頻度・バージョン・症状などの記入が必要です。

「バグトラッキングシステム」（BTS）というバグ報告用の社内サーバが開発されているので(Redmine やJIRAやTracやMantisやBacklogなど)、それを設置したり、あるいはもっと単純にエクセルみたいなので代用されていたり、などです。なお、JIRAとBacklogは有料です。一方、RedmineとTracとMantisはオープンソースなので無料でも使えます。

なぜサーバが必要かというと、 2人以上の集団でのデバッグ作業の場合、自分の発見したバグを、自分よりも前に他のデバッグメンバーが発見して既に報告ずみの場合もあります。

なので、サーバでバグ情報を公開しておかないと、報告が重複してしまい、非効率になってしまいます。プログラマー側も、それぞれの報告に別個、報告するのは、とても面倒です。

2人ていどなら、まだイイですが、5人以上とかになると、まずメールなどで個別に連絡するのは無理です。

ただし、小規模なサークルでは、こういった社内サーバーの設置は難しいでしょう。とにかく、なんらかの方法で、バグ報告があまり重複しないようにしてください。このため、あまりにも開発初期の段階では、あえてデバッグメンバーを少数に限って、メールでやり取りする事もありえます。（いちおうメールにも、CC(カーボンコピー)などの機能がある。）

とはいえ、サーバ無しに他のテスターの報告状況なんて分からないので、ある程度はバグ報告が重複するのは、やむをえません。

また、時には報告の重複が役立つ場合もあります。それは解決方法がまだ不明で未解決バグになっている場合には、他人の報告による追加情報と合わせて、よりバグの原因をしぼりこめます。

さて、サーバを使う場合、自分がバグ調査して得た情報のうち、まだ報告されていない情報があれば、サーバーのバグ記入欄に追加の情報を記入するぶんには、構いません。（ゲームに限らず、GitHubなどのバグ報告欄でも同様の慣習です。）

べつに特許や発明ではないので、最初の一人だけが名誉と権限を独占する必要は無く、みんなで協力しあってバグ解決という問題解決するのが仕事です。

さて、バグ報告の手本として、もしメールで報告する場合、一例を書くと、たとえば

例

【バグ報告】 ウッキークエスト ver0.87 。ハジメガルド武器屋オヤジの会話時のキャラチップ表示ズレ

   ・[バグの症状]   ゲーム中盤でのハジメガルド武器屋の親父の会話時のキャラチップ位置表示ズレです。 

   ・[発生の頻度]  当の武器屋オヤジに話しかけるたび、毎回バグ発生です。3回、確認しました。

   ・[添付ファイルの内容] メール添付画像は、バグ発生時のオヤジ画像チップが店の壁に乗ってしまってるナゾ画像です。
    
   ・[バグの発生方法]   ゲーム序盤の第1章から行ける街・ハジメガルドの武器屋の親父に、
      ゲーム中盤の第三章になってからハジメガルドに行き、
      自軍パーティ構成が戦士・戦士・僧侶の3人パーティの
      味方平均レベル28くらいの状態で武器屋親父に話しかけると、
      なぜか親父が話しかけるたびに、
      バグによって親父のキャラチップの表示位置が1マスぶん右にズレます。

    ・[参考情報]
      私の今回のテストプレイでは、まだ「伝説の剣」は入手していません。
     「伝説の盾」は、このバグ発生の時点で入手しています。
      伝説の盾を守っている中ボス・暗黒大王も撃破してあります。
      
     今回のプレイでは、装備はまだハガネ装備です。ミスリル装備は、していない状態です。
     ミスリル鉱山の街をすでに帝国軍から解放しましたが、プレイヤー所持金を節約するためハガネ装備のままです。
     ハガネ装備のままレベル28まで上げて暗黒大王を倒しています。

みたいな感じでしょうか。（もしメール方式でなくサーバー方式の場合でも、こんな感じの書式で報告・連絡を入れる欄があるハズでしょう。サーバの場合の詳しい書式は会社によって違うので、説明は省略します。）

※ 「バグ発生原因などを報告前に特定しなくていいの？」と思うかもしれませんが、発生原因の特定は（あとで必要だけど）後回しです。先にまず、再現性のある（何度も起きる）バグを発見したことを、なるべく早く（「なるはや」で）、上司などにメールでも何でもいいので報告します（理由: 何度も起きるバグは、重要度が高いので）。なぜなら、発生原因の特定には、時間がけっこう掛かるからです。なので、まずバグ発見を報告したあと、そのあとに返事を待つ間などに、発生原因などを絞り込んで生きます。

なので、バグ報告は、1件のバグにつき基本、

1回目のバグ発見の速報（そくほう）と、

翌日（翌営業日）の2回目の詳報（しょうほう）とで、

最低でも2回以上、行うことになるのが通例です。

もし、バグ発生時の画面をキャプチャ（「スクリーンショット」ともいう）した画像があると、伝わりやすいです。

ウィンドウズでは、ショートカット・キー [Fn] + [Alt] + [Prt Sc] で選択中のアプリウィンドウごとにキャプチャでき、それをWindows アクセサリ『ペイント』のキャンバスに貼り付けしてセーブ保存すれば、キャプチャ画像が作成できます。

なので、バグ発生中のソフトのキャプチャ画像を作りましょう。

さて、バグの報告では、実際に起きたバグの症状を、主観を交えずに、見たままに報告します。

要約などを書いてもいいですが（「どこを要約すべきか」という判断も主観です）、しかし必ず報告の文中に、必ず、実際に起きた事だけを報告する段落・節などが必要です。なので、要約の文とは、段落などを分離したほうが良いかもしれません。

バグ報告に限らず、一般企業のサラリーマンのトラブル報告などの報告文などでも一般に、段落として（分析を交えずに）実際に起きた事だけを報告する専用の段落などが必要です。

なので、実際に起きたバグの症状の現状とは別に、バグ発生原因かもしれない関連情報・参考情報を併記する場合には、あくまでその関連性は推測に過ぎないので、段落を別々に分けましょう。上記の報告メール例でも、「バグの症状」と「参考情報」というふうに別々の節に分けて報告しています。

なお、報告メールの際、参考情報などで、とりあえずバランス調整に関係ありそうなテストプレイ時の行動も書いておくと、バランス調整チームがデバッグついでにバランス調整のための資料にも出来るので、一石二鳥です。また、ひょっとしたら、そのバランス関連の参考情報で書かれたテストプレイの行動も、バグ発生条件に関係しているかもしれない場合もあります。

（ただし、商業作品の場合は、バランス調整はデバッグよりも前のほうに、ある程度は終わらせておく必要があるだろう。）

しかし、あくまでバランス調整に関するテストプレイ報告については、後回しの付属的な情報です。メインに報告すべきは、バグに関係ありそうな情報から優先的に報告です。バランス報告については、せいぜい5行くらいまでで充分でしょう。

また、「バランスがイイ」だの「バランス悪い」だのといった良否の判断は、これはバランス調整者側の判断することでありますので、デバッガー分野の判断することではないです。

デバッグのついでのバランス報告では単に「レベルは○○くらいです」「装備は○○くらいです」とか「中ボスの△△戦では負けて1回全滅しました」とかプレイ事実だけを報告するべきであり、良否の判断はプレイヤー側ではしないのがポイントです。

このように、バグの発生方法についての説明は、バグが起きた時やその前にゲーム中で主人公のしていた行動を記述します。

（実際のプレイ行動だけを先に報告文面で書いた上での）追加情報として、「おそらく、バグの原因はコレだと思われます」という分析があるぶんには、構いません。

また、バグを報告する場合は、けっして即座に報告するのではなく、できれば最低限あと2回は同じ行動をしてみて（つまり合計で3回以上はしてみて）、それから同じバグが発生するかどうかを確認できたら報告します。

もし最初の1回しかバグが起きなかった場合は、もしかしたら、ソフト側ではなくハード側のその瞬間での不調などの原因も考えられますので、対応をやや後回しにできます。

ただし、ランダム性の高いバグなどの場合、本当はソフト側のバグなのに、2回目に試しても発生しない場合もあります。 なので、もし再現性が悪くても、けっして「ハード側のバグだな」と早合点せず、とりあえずは再現性の情報とともにバグ報告します。

再現性の悪いバグの場合、報告の文面では、たとえば

このバグの再現性は、3回試しましたが、1回しか発生しませんでした。

などという、再現性の悪いことを併記した説明書きとともに、バグ報告をします。

これを代わりに

1/3

みたいに分数のような書式で書く場合も、よくあります。分子がバグ発生回数、分母が試行回数です。書籍『ゲームをテストする バグのないゲームを支える知識と手法』および書籍『ゼロからはじめるゲームテスト: 壁抜けしたら無限ガチャで最強モードな件? 』で、このような表記でバグ発生回数と試行回数をまとめて表記しています。

つまり

バグ発生回数/試行回数

です。

決して約分してはいけません。回数という意味があるので、たとえば4回試して2回のバグ発生なら

2/4

のように書くことになります。

高校卒業までは分数は約分しないと減点でしたが、じつは高校卒業以降は、分数を約分しないままのほうが好まれる職種も多くあります。なぜなら、約分しないほうが計算過程も分かりやすいからです。

さて、ゲームのバグ報告の場合、もしそのバグの再現性が高い場合なら、

バグ発生の直前の行動だけでなく、バグ発生に影響のありそうな行動も報告する事になると思います。

なぜなら、RPGやシミュレーションゲームの場合なら、たとえば、「ゲーム中の中盤ストーリー中でしか起きないバグ」とか「東部地方でしか起きないバグ」のように、発生箇所や発生時点が限定されているバグもあるからです。

つまり、単に「Aボタンを押したら、こういうバグが起きました。」なんてのは論外です。

ゲーム中のどこのストーリー時点のどんな場所（マップやエリア、ステージなど）で、どんな操作キャラクターで、キャラクターに何をさせたらバグが起きたのか、といった、5W1H（いつ、どこで、だれが、なにを、どのように、どうした）のような情報を、バグ報告での発生方法では、書きましょう。

たとえば、

「ゲーム序盤の第1章から行ける街・ハジメガルドの武器屋の親父に、ゲーム中盤の第三章になってからハジメガルドに行き、自軍パーティ構成が戦士・戦士・僧侶の3人パーティの味方平均レベル28くらいの状態で武器屋親父に話しかけると、なぜか親父が話しかけるたびに、バグによって親父のキャラチップの表示位置が1マスぶん右にズレます。」

みたいに、5W1Hで報告するのです。

バグ発生時の瞬間のプレイヤー行動は単に、武器屋で話しかけるですが、しかし、発生に影響を与えてるかもしれないと思った行動など、その他の行動も報告します。

なぜなら、バグ発生の条件は、必ずしも1つとは、限りません。複数の条件が満たされた場合にだけ、バグが発生する場合もあるからです。

これがもし、

（ダメな例）「武器屋の親父に話しかけると、表示が1マス、ズレます」

だと、報告を聞いた側のプログラマーにとってはバグ発生方法がサッパリ不明です。また、ハジメガルド以外の別の街の武器屋の親父では、バグは発生しないかもしれないので、プログラマー側が再現性を確認プレイしても、 ハジメガルド以外の武器屋でプレイしてしまう可能性もあります。その場合、バグ発生を確認できないので、その結果「間違った報告」としてプログラマーに処理されかねません。

また、ダメな例として

「武器屋の親父に向かって決定ボタンを押すと、表示が1マス、ズレます」

だと、決定ボタンを押した結果、何が起きる状態なのか、やや不明です。親父に話しかけるために決定ボタンなのか、それとも、たまたま親父の前でメニューコマンドで道具を使おうとして決定ボタンなのか、解釈が分かれてしまいます。

つまり、発生方法の操作の説明は、プレイヤーの動作ではなく、なるべくゲーム中のキャラクターの動作で、バグ報告しましょう。

なお、たといこのバグの発生条件で自軍パーティ構成が結果的に無関係だとしても、報告時に「自軍パーティ構成が戦士・戦士・僧侶の3人パーティの味方平均レベル28くらいの状態で武器屋親父に話しかけると、」のような情報があるのは、構いません。

なぜなら、バグ報告の時点では、まだ自軍パーティ構成がバグ発生に影響しているかどうかは不明だから、です。

バグ発生の条件は、必ずしも1つとは限らず、複数の条件が満たされた場合にだけ、バグ発生する場合もありますので、バグ報告では「影響してそう」と思った情報も提示します。

その他、プレイヤーによって行動が分かれそうなゲーム中での過去イベントでどうしたかとか、そういうのも後に追記しましょう。

たとえば、先のバグ報告バグによって親父のキャラチップの表示位置が1マスぶん右にズレます。」の次の文で、

「私の今回のテストプレイでは、まだ「伝説の剣」は入手していません。「伝説の盾」は、このバグ発生の時点で入手しています。伝説の盾を守っている中ボス・暗黒大王も撃破してあります。」

などのようにです。

もしかしたら結果的には「伝説の剣」や「伝説の盾」の入手の有無はバグには無関係かもしれないですが、しかしバグ報告の時点ではプログラマーにすら一切、原因は不明なので、よって報告の時点では、関係ありそうだと思った追加情報を手短かに5行～10行くらいで、いくつか選んで情報を報告します。

さて、報告する側は、もし時間に余裕があるなら、次からの検証プレイではバグ発生時の行動を少し変えてみて、それでもバグが起きるかどうかを試してみると、プログラマー側の今後の検証がラクになります。

さて、ゲームに限らずパソコンソフトの場合、

たといデバッガー側で何回もバグを再現できる事を確認できたとしても、

それでも、プログラマー側の環境ではバグが起きない場合がある。

このような場合は、たとえば、ＯＳ（オペレーティングシステム）の違いによって起きる場合がある。

たとえば、Windows の特定のバージョンでしか起きないソフトバグもある。

なので、もしプログラマー側ではバグをテストしても確認できない場合、 自分のＯＳを変更してみる等して、確認する必要がある。

細かな追試プレイは後回しに

バグ報告は、発見しだい、再現性が3回くらい確認できた時点で、なるべく早めに報告したほうが、最終的に効率的です。（バグ報告は『なるはや』（「なるべく早く」の略）で、と言われます。）

再現性が確認できたら、さっさと報告しましょう。

もちろん、バグ発見箇所の周囲にも類似のバグが潜んでないかとかも、今後はチェックするわけですが（理科でいう『対照実験』みたいに比較検証プレイを、あとでする）、

しかしそんなのは、そのときにチェックすればいいのです。

どうせバグ修正後にも、バグが本当に直ってるかを確認するためのチェックプレイするのですから、

だったら早めにバグ報告して、プログラマー側にとりあえず該当部分のバグを直してもらい、

そのあとに周辺箇所をまとめて通しプレイで調べればいいのです。

仕事術としては、おそらくですが、プログラミングやゲーム産業に限らずなにか仕事で、

自社や同僚などの設計ミスのようなものが見つかったら、

再現性が取れた時点で、その後の詳細な調査は後回しにして、ひとまず、

早めに設計担当の部署に報告をするほうが効率的でしょう。

その他

会社によっては、社内サーバで、バグ報告シートと、その他のバランス調整報告シートや提案シートなどを共用している場合もあります。

その場合、報告シートに、報告の種類の分類の記入欄があるハズなので、そこに「バグ報告」と記入して、バグ報告であることをきちんと明示しましょう。

なお一般に仕事において提案する場合、その提案の思いついたキッカケになったトラブルなどを一緒に報告すると、伝わりやすいです。

たとえば集団でのゲーム製作での提案の場合なら、「現在の仕様では、テストプレイ中に○○な不都合に遭遇しました。なので提案・要望ですが仕様変更として□□な仕様に変更してほしいです」みたいに伝えると、伝わりやすいです。

バグ報告のその後

バグ報告のあとは、次のような流れになります。

1. （返事 :）とにかく、担当部署に報告を読ませ、報告を読んだかどうかの返事を書いてもらう。
2. （優先度づけ :）修正するのか、または修正の優先度などの評価の決定をして、情報の共有をする。
3. （修正 :） コード上でのバグ修正。コード上での修正が終わり、プログラマーの環境で再発しなくなれば、とりあえず「修正」として中間報告。
4. （修正確認 :） 修正版が公開・配布されてから、プログラマー以外のコンピュータ環境でもバグが再発していないか、品質管理チームなどが実際に修正版をテストプレイして確認する。

ゲームに限らず、一般のIT企業でも大抵、似たような流れになります。（というか、ゲーム会社がどうしてるのか、編集した人はあまり知りません。）

オープンソースやフリーソフトの場合などは、返事や修正確認が省略される場合もありますが、しかし有料ソフト開発では返事や修正確認は行ったほうが安全でしょう。

返事

集団作業でのバグ報告の場合、

バグ報告を受け取った側（主にプログラマー）は、

とりあえず返事をする必要があります。

プログラマーがバグ報告にもとづいて実際のプレイしてみて調査した結果として（プログラマー側でも）バグが再現できたのかとか、そういう事を社内のバグ報告用サーバーの専用ページ（あるいはバグ記入用エクセル）に記入するとか、あるいはメールでのバグ報告なら返信するとか、とりあえず、初期対応によって返事をします。

社内で情報共有する必要があるので、社内サーバーを使うのです。

さて、こういった社内サーバー経由のバグ報告では、たとい、すぐにバグが修正できなくても、とりあえず

「調査中」とか、

「プログラマー部署でもバグが再現しました」とか、あるいは「プログラマー部署ではバグが再現できませんでした」とか

とにかく、なにか現状が分かるように、バグ報告用サーバーなどにプログラマー側など返事の権限のある側が対応を記入します。

さらに企業などの場合、バグ修正後にも、

バグ記入用紙に、どのようにバグ修正のプログラムを対応したのかを、簡潔に1行～2行ていどで、バグ報告用サーバーの専用ページ（あるいはバグ記入用エクセル）に書いておきます。

したがってゲーム企業などの場合、冒頭の

・バグの発生方法 :

・発生の頻度 :

・バグ発生したソフトのバージョン :

・バグの症状 :

に加えて、さらに

・対応:

のような項目が専用ページ（あるいは記入用エクセル）に加わります。

さらに、会社によっては、

・バグの原因:

などの項目もあるかもしれないです。もちろん、バグの原因を調査するのはプログラマー側です（ソースコードを見れないとバグの原因を特定できないので、ソースコードを扱っているプログラマーなどが原因を記述する場合が多いだろう）。

もちろん、ここでいう原因は、たとえば「テンキーの1と4を押し間違えてしまい、その結果、武器IDが4番の『ハガネの剣』の番号がズレて『青銅の剣』（武器ID:1番）の攻撃力になっていました。」みたいなゲームのコードのミス内容とバグ動作の対応を特定できるような説明のことです。

けっして「寝不足だったんです」とか「風邪気味だったんです」とか、そういう情報は不要です。

ともかく、バグ報告記入シートに「原因」の項目のある場合、2行～4行ていどでバグの原因を記述しましょう。

なお、プログラマー側や管理者は、バグ発生部に関連する他の情報も知っている場合がありますが、なるべく、リリースまでは、最低限のバグに直接・一次的に関係する仕様しか情報の共有しないようにする必要があります。

つまり、デバッガーが報告した事に直接・一次的に関係する事は情報を公開、またはそのデバッガーに連絡する必要があります。

しかし、それ以外の間接的・二次的～三次的にそのバグに影響することは、あまり詳細を教えないようにする必要があります。

なぜそうするかというと、もし、間接的なことまで色々と仕様の裏側を知ってしまうと、デバッガーの次回の通しプレイからは、仕様を知ってしまってるので、自然なプレイが出来なくなってしまいます。

デバッガーによる通しプレイの際には、開発初期には、なるべく一般プレイヤーに近い予備知識の状態でいてもらい、一般プレイヤーの取りそうな行動をデバッガーに再現してもらう必要があります。（一方、開発中期ぐらいからは、デバッグ用テストプレイヤーにも裏仕様などを教えて、確認プレイしてもらう必要がある。）

なので、そのために、開発初期のうちにはデバッガーには余計な知識が無いほうが一般プレイヤーの感覚に近づくので、あえて間接的にバグに影響する仕様については、デバッガーには公開しないでガマンしてもらう必要があります。

具体例を挙げると、たとえばアクションゲームで、全10面あるゲームのうちの4面のボス「暗黒大王」との戦闘アルゴリズムにバグ報告があったとして、その報告をもとにプログラマー側は8面のボス「ゾンビ暗黒大王」にもバグをプログラマー側で別途に発見したとしましょう。

この場合、プログラマー側は、8面の「ゾンビ暗黒大王」にもバグがあることについては、デバッガー・テストプレイヤー達には、開発初期のうちは教えないでおきます。

なぜなら、報告を入れたデバッガー側・テストプレイヤー側はまだ、8面まで進んでおらず、4面ボス「暗黒大王」までしか進んでない人もいるからです。

なお、手前のステージ（この例の場合は1面～3面）のバグについては、報告したプレイヤーだけには個別にメールなどで情報共有しても構わないでしょう（ただし、共有サーバーなどは、他の人も見るので、共有サーバー側では教えないでおく必要があるだろう）。

このような場合の対応策としてオススメなのは、「合計で何個の同種のバグがあるか」という情報を情報共有することです。

たとえば例の「暗黒大王」バグと「ゾンビ暗黒大王」バグの場合なら、合計でボス2体あるいは2ステージぶん、このバグがあるわけですから。

たとえば情報共通では

4面ボス戦でバグで○○が起きてしまうバグ、およびゲーム後半ステージでの似たようなアルゴリズムのボス敵の類似バグとで、少なくとも合計2件、このバグがありました。

みたいにプログラマー側とデバッガー側とで情報共有すれば、

これはデバッガー側にもネタバレにならずに済みます。

また、万が一、デバッガー側があとから5件や10件も同種のバグを見つけたら、「合計2件」を大幅に超えてることから、プログラマー側の確認モレをデバッガー側が発見したことも分かるようになるという、情報共有の仕方です。

プログラマー側の大幅な確認モレが分かれば、デバッガー側は再度、追加報告する必要があることも、分かるようになります。

優先度づけ

この段階で、対応の優先度などのトリアージをします。

最初のバグ報告の時点ですでにとりあえずのトリアージがある場合、返事の際にトリアージの優先度を変更する場合もあるかもしれません。

修正

コードの修正は、プログラマーが実際にキーボードを使って手入力などで行います。こればかりは、自動化は出来ないのです。

修正確認

よくあるミスで、「間違えて修正前バージョンをアップロードしてしまう」、「バージョン番号は修正版になっているのに中身が修正前のまま」（あるいはその逆パターン）、などもミスもあります。

また、修正のコード自体に別のバグが新規に追加されてしまう（「エンバグ」という）場合などもあります。

「デバッグ用の文字などの消し忘れ」、「デバッグモードのオフのし忘れ」などのミスもあります。

そのようなミスが無いかは、実際にバグ報告者や品質管理チームなどがゲームの「修正版」とされるバージョンをテストプレイをして、確認します。

このため、最初のバグ報告を終えても、バグ発生版のセーブデータはなるべく消さずにセーブなどをして保管しておく必要があります。修正確認が終わるまで、バグ報告時点のプレイデータは残しておく必要があります。

バグが無かったという報告

ver0.01を最初にデバッグプレイする場合

ver0.01やver0.10のような、とても初期のバージョンをプレイする場合、

たとえバグが無い場合でも、ここには「バグが無かった」という報告をします。（ゲームにかぎらず、Linuxなど大手オープンソースソフトのテスト報告なども同様に、「〇〇にはバグが無い」という事を報告します。）

このように現状ではバグの無い、またはバグのきわめて起きづらい部分を見つけ出すことにより、裏を返すと、バグの無いことがまだ確認されていない箇所にバグが潜んでいる確率が高いわけですので、そうやってバグの居場所を突き止めていきます。

実際に商業ゲームでも、たとえば1980～1990年代のセガ（企業名）のアーケードゲーム（ゲームセンターの筐体機用のゲームという意味）では、このような方法で、バグのありかを突き止める方法が行われたらしいです。

例えるなら、プログラムの中に犯人がいて、まだ捜査をしてない場所に犯人が潜んでいる可能性が高いわけです。（参考元のセガ開発者のインタビューで、そういうふうに警察捜査に例えている。）

文献『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』でも、デバッグを「名探偵のように捜査」と図表で例えています。

なお、海外のゲーム開発者の情報ですが、欧米の海外ゲームでもLinux版ユーザーからのバグ報告は良質だと紹介したweb記事もあります（Gigazine『「Linuxゲーマーのバグ報告率は平均の6倍以上」とゲーム開発者が明かす』）。

このような海外事例もあるので、例外的にもし日本のゲーム市場が海外とよほど異質な品質管理でもしてない限り、オープンソース・コミュニティ一般でのバグ報告の様式は、ゲームのバグ報告でもおおむね通用すると見て、よろしいでしょう。

さて、ゲーム業界ではなくLinuxなどの業界でのテストの場合は、バグが無かった報告のための報告データシートなどの書式が決まっていたり、報告用にテスト操作ごとに入力チェック欄のある専用サイトなどがあったりします。

しかし、ゲームの開発初期バージョンにおける「通しプレイ」には、そんな気の聞いたシステムやサービスは、ありません。（ただし、「壁に体当たり」みたいな、どこのゲームでもチェックするようなデバッグ手法の場合には、個別チェック欄がある可能性もありうる。）

しかし、ゲーム全体の通しプレイでは、そんな個別チェック欄の存在は、まず期待できないでしょう。

なので、デバッガーは、通しプレイの報告スタイルを、自分で考える必要があるかもしれません。

『仕様書』といわれる設計図がデバッグ用のシートを兼ねる場合もありますが、しかし開発初期のほんとに初期バージョンすぎる場合、その『仕様書』そのものが不確定だったり未完成だったりします。このような事情により、IT用語でいう「探索的テスト」という方法で、ゲームの社内デバッガー/テスターはバグ報告せざるを得ない場合も多いかもしれません。ゲームテストの場合、そのゲームの実装にもとづく独自のいろいろな内部プログラムのアルゴリズム/パターンがあるので、そういうのを（開発初期に加わっている）社内デバッガーは察知して、仕様書に無いこと/そもそも仕様書が無い場合もあること、などを意識して探索的テストをする事になる場合も多々あります。

また、同人ゲームには仕様書など存在しません。

※ アルバイトなどで、デバッグ系テスターを事業としている会社のアルバイト要項などを見ると、あたかもデバッグテストは仕様書やチェックシートにもとづく行為だけかと錯覚しがちです。しかし、そういう外注企業に外注する前に、まず先に発注元のゲーム会社で大まかに通しプレイなどをしてデバッグをしていく必要があります。

発注元が仕様書そのものを策定するためにも、まず自社でのデバッグによる確認が必要なのです。

一方、のちの段階で、外注企業としてデバッグ依頼を有料で受ける場合なら、あらかじめ発注元で大まかに通しプレイをして、大まかなデバッグをしてあるハズなので、通しプレイよりも、（選択肢を全パターン確認したり、敗北時の反応を確認するなどの）局所的なチェックを優先する事が望ましい、と考えられます。（ただし、仕様の把握のために外注サイドでもテスターは一度は通しプレイをする必要があるので、程度問題です。）

ともかく、開発初期の時点のデバッガー・テスターは、プランナー（仕様の制定者。いわゆる「作者」）などとヤリトリをしていく仕事を通じて、そのゲームに適したバグ報告スタイルそのものを模索して確立していく必要が生じますので、ある程度はそのゲームを一般プレイヤーの目線でゲーム攻略的にプレイする必要があります。（ただし、短めの日数で攻略プレイを区切る。）

その後、デバッガーは開発のすごく初期の最初のバージョンでは、たといバグが無くても、「自分がプレイした範囲では、どこにバグが無いか」という事を報告する必要があります。

さて、ゲームの場合、単にけっして「どこのシーンでバグが無いか」だけを報告するのではないのです。（一般のITソフトとは、ここの仕方が違っているかもしれない。）

なぜならゲームは、そのシーンに到達する前に（重要イベントの選択肢などの選択結果によって）フラグ変数などの影響を受けているからです。だからフラグの状況によっては、他のデバッガーや開発者が追試してもバグが発生しない場合もあります。

なので、「ここにはバグが無かった」という報告をする際には、加えて、そのシーンに至るまでに、途中でどんな感じのプレイをしていたかも加えて報告する必要があります。

たとえばRPGなら、フラグに影響を与えそうな重要イベントの選択肢などでは、自分がどの選択肢を選んだかなどを、加えて報告する必要があるのでしょう。ただし、大まかに報告する必要があります。

なぜなら、ゲーム中のすべての選択を報告するのは、選択肢が膨大すぎるので、まず不可能だからです。（細かい報告をするのは、もう少し完成度の高くなった仕上げの段階からです。）

開発初期のほんと初期バージョンver0.01あたりでは、ゲーム全体に開発チームの労力を回す必要があるため、細かいデバッグは後回しにします。

さらに開発初期では、ゲーム中のどの要素が潜在しているバグに影響を与えやすいかが全く不明であり、重要イベントの選択肢 以外も潜在バグに影響を与える可能性すらありえるので、とりあえずバランス調整に必要になりそうなプレイ結果も、ついでに報告します。

たとえばRPGの新機能の公開直後なら、いくつかの重要イベントの時点でのレベルとか大まかな装備とか、どこのステージまで攻略したかとか、そういうのも初期テストでは報告します。

レベルが潜在バグに影響を与える可能性だって、開発初期では、ありえるのです。

ただし、この時点（ver0.01あたり）ではバランス調整はしません。なぜなら、ゲーム全体にチームの労力を回す必要があるからです。

なので、デバッガーは今後のバランス調整を見据えて（みすえて）、今後のバランス調整にも使えそうなプレイ結果のデータを、デバッグのテストプレイのついでに報告しとくだけです。

こういったテスト結果をもとに、数人のデバッガーが共通して、「こういうプレイをした結果、ここにはバグが無かった」という事が保証されたなら、

とりあえず、たとい もしそこにバグが潜んでいたとしても、そのバグの発生確率は（「バグが無かった」報告により、発生確率が）低い事が保証されるようになるので、開発チームは他の部分の開発に専念できます。

また、デバッガーどうしでも「〇〇にはバグ無し」情報の共有により、バグ発生確率の低いシーンの検証プレイを後回しにして、まだ未検証の部分の検証プレイに取り掛かることができるようになります。

大幅な更新の直後

ゲームのバージョン更新によって新機能が追加されたばかりの新バージョンには、バグが多く、いろいろな場所にバグが発生する場合があります。

なぜなら、その新機能が、ゲーム中のさまざまな要素に影響を与えるからです。（ゲームに限らず、ITソフトでなにか新機能が追加された場合、バグが多く発生しがちです。）

なので、大幅な機能の追加や、大幅なストーリーの追加などといった、大幅な更新があったら、たといバグが無くても、「ここにはバグ無し」系の報告の必要があります。

【デバッグ報告】「異常なし」です。
ソフト「□□□□」のver0.85で大幅にストーリー追加されたバージョンが公開されたので、このver○○で通しプレイおよび、下記の行動をしてみましたが、異常は見られませんでした。今のところ、正常です。

通しプレイ内容
重要アイテム『ヒスイの首飾り』を本イベントでマップ『隠し洞窟』の魔女から貰いました。
その後、アサシンギルドのボス『アサシンマスター』を倒したことにより、ダンジョン『アサシンギルド』を攻略しました。

通しプレイでのレベル : Lv40で突入、Lv53で本バージョン追加イベントのクリア 

確認した行為
・ △△△
・ ～～～

みたいな感じでしょうか。

他の利用者が別の利用方法をしてたらバグが見つかる場合もあるので、なので、「自分が何をしている限りは、とりあえず、このソフトにはバグが見つからない」という情報が「異常なし」報告に必要です。

こうすることで、もしバグが今後に他の場所で見つかった場合でも、ソフト作者が「異常なし」報告を受けた部分は後回しにできます。

バグが無かったという報告も時には必要

もし仕事でデバッグ依頼を受けている際、開発版ソフトウェアがバージョン更新されてデバッガーなどの協力者に限定公開された場合、デバッガーは検査のためにソフトをテスト使用するワケですが、テストの結果、バグが見つからない場合もあります。

もし仕事のデバッグ依頼を受けている場合、たといバグが見つからなかった場合でも、デバッガーからソフトウェア作者に連絡する必要があります。（ただし、仕事でないソフトの場合、いちいちソフト利用の際に報告の必要は無いし、むしろ作者の手間をかけてしまう。なぜなら、もし作者が利用者全員から報告を受けていたら、人気アプリ作者などは、多くの人から報告されてしまうので返事に手間が掛かってしまうので。）

仕事の場合、IT産業にかぎらず何かの検査では、もし検査の結果として異常が見つからなくても、「今回の何月何日の検査では、ver○○には異常が見つからなかったです」という報告が必要です。日付が必要です。翌日の検査でバグが見つかることも、よくあるので。

なので、最初から、報告レポートに日付欄（ひづけらん）を作っておくのが良いでしょう。

またレポート文中でも、「昨日の報告では」とか書くのではなく、「昨日の5月10日の報告では」みたいに、後日に日付を見ても分かるように、報告書では文中の日付も書きましょう。

ともかく、「異常なし」報告をしないと、そもそも検査の依頼の連絡がテスト者に行き届いてないのかとか、確認のための手間が、製品の作者側に掛かるからです。

さて、ソフトの「異常なし」報告をする場合、「自分はどういった作業をそのソフトウェアで何時間くらい利用していた所、今のところ、ver○○にはバグが見つかりませんでした」というように報告をする必要があります。

たとえば、一例ですが、（※ 未記述）

仕様かバクか不明な場合

ゲーム演出のなかには、一見するとバグっぽい演出もあります。

なのでデバッガーが、ゲームのテストプレイをしているときに見つけた現象が、はたしてバグなのか、それとも意図的な演出なのか、悩むこともよくあります。

このような場合でも、とりあえずはデバッガーは念のためバグかもしれないと報告を挙げておくのが、ゲーム業界での通例だと言われています（要出典）。

たとい結果的にバグではなく意図的な演出だとしても、プログラマー側にとって、ユーザー視点に近い人からの参考意見になります。

もしプログラマー側やクリエイター側は、このような仕様のつもりの部分にバグ報告を受けたら、きちんとデバッガーたちに、「この現象はバグではなく仕様です」ということを説明し、デバッガーたちとプログラマーとで情報共有する必要があります。

その他

レベル上げやノー・ミスは目的ではない

プレイするバージョンについては原則、なるべく最新バージョンをプレイします。

なぜなら、今後のプレイヤーがプレイするバージョンに、もっとも近いバージョンは、現時点での最新バージョンだからです。

なので、RPGやシミュレーションなどのデバッグをしている場合、もし最新バージョンが出たら、とりあえずセーブデータを最新版に移行可能なら、さっさと最新版に移行しましょう（念のため、古いほうのセーブデータもしばらくは残しておく）。

なお、レベル上げのバグの有無の確認については、デバッグ初期の段階で、デバッグモードなどでカンスト（カウンターストップ）チェックを行っているハズです。なので、通しプレイでは、レベル上限チェックの確認の優先順位は、低めでしょう。

とはいえ、一度は誰かが通しプレイでもレベル上げの通しプレイで最高レベル近くなどのレベルをチェックする必要がありますが、しかし時間が掛かりすぎるので、もし誰かが既に1度や2度はレベル上げのカンストのチェックしていれば、あとは他の人がレベル上げをチェックするのは不要でしょう。

このように、一応は通しプレイで誰かが最高レベルや最高スコアなどの上限を確認する必要があるので、なので自分のプレイでの最高レベルなどのセーブデータも一応は保管しておくべきでしょう。

ともかく、このようにデバッガーどうしで役割分担をしましょう（複数のデバッガーがいれば、の場合ですが）。

なお、最新バージョンにセーブデータを移行した際は、攻略の前に、まず『更新履歴』などの情報を読んで、そしてその更新したゲーム内環境の周囲に異常のないことを確認するデバッグ的に色々としてみるプレイをしましょう。

いちおうプログラマー側でも、更新箇所についてはデバッグモードなどで簡易的に確認をしているとは思いますので、この段階ではバグはあまり見つからないのが普通ですが（なので正常な動作が見れるのが普通ですが）、しかしデバッガーにとっても、まず正常な更新結果がどういう結果なのかを知る必要があるのです。

なので、まず正常な更新結果を実際にプレイでさっさと確認してから、そのあとで、通しプレイを始めたり、あるいは移行後のデータを攻略してゲームクリアしたりします。

その後にまだ次のバージョンが出てなければ、今度はニューゲームで最初から通しプレイをしましょう。

また、ノー・ミス（たとえばシューティングゲームなら敵のミサイルを一発も受けないで、全ての敵弾を避けるとか）でクリアするのが目的ではないです。

RPGなどでは、ついつい普通の感覚では、全滅したあとにアプリを保存しないでクローズ（いわゆるリセット）してしまいがちですが、しかし、なるべくデバッグの序盤では、通常のプレイ中にはリセットしないで、そのまま続けて保存してクリアを目指しましょう。なぜなら、デバッグ中にしだいにデバッガーもプレイに上達してしまうので、普通にプレイしてると全滅の回数はしだいに減っていくので、全滅時のデバッグが面倒になっていきます。

なので、ミス時や全滅時などにバグが起きないことも確認する必要があるので、プレイでミスしても、なるべくリセットしないようにしましょう。（ただし、わざと異常なプレイをしている場合には、他のバグ調査と区別するために、保存せずにリセットする場合もあります。）

バグ報告したあとのデバッガ－

バグが見つかって、報告が終わったら、デバッガー・テスターは空き時間に、類似のバグが無いかを探します。

デバッガーの手元に、バグ再現時に近いデータがありますので（しばらくセーブデータなどを残す必要があります）、ソレを使い、

報告したバグ内容に近いけど微妙に変えた操作をいろいろとしてみて、バグが起きるか起きないかを調べます。

たとえば、もし報告したバグ内容が下記の例の場合、

例

【バグ報告】 ウッキークエスト ver0.87 。ハジメガルド武器屋オヤジの会話時のキャラチップ表示ズレ

   ・[バグの症状]   ゲーム中盤でのハジメガルド武器屋の親父の会話時のキャラチップ位置表示ズレです。 

   ・[発生の頻度]  当の武器屋オヤジに話しかけるたび、毎回バグ発生です。3回、確認しました。

   ・[添付ファイルの内容] メール添付画像は、バグ発生時のオヤジ画像チップが店の壁に乗ってしまってるナゾ画像です。
    
   ・[バグの発生方法]   ゲーム序盤の第1章から行ける街・ハジメガルドの武器屋の親父に、
      ゲーム中盤の第三章になってからハジメガルドに行き、
      自軍パーティ構成が戦士・戦士・僧侶の3人パーティの
      味方平均レベル28くらいの状態で武器屋親父に話しかけると、
      なぜか親父が話しかけるたびに、
      バグによって親父のキャラチップの表示位置が1マスぶん右にズレます。

    ・[参考情報]
      私の今回のテストプレイでは、まだ「伝説の剣」は入手していません。
     「伝説の盾」は、このバグ発生の時点で入手しています。
      伝説の盾を守っている中ボス・暗黒大王も撃破してあります。
      
     今回のプレイでは、装備はまだハガネ装備です。ミスリル装備は、していない状態です。
     ミスリル鉱山の街をすでに帝国軍から解放しましたが、プレイヤー所持金を節約するためハガネ装備のままです。
     ハガネ装備のままレベル28まで上げて暗黒大王を倒しています。

上述のような報告を先にしたら、デバッガーは報告後にテストプレイで、たとえば、

ハジメガルド街の武器屋ではなく、道具屋の主人に話しかけたらどうなるかとか、あるいは宿屋の主人に話しかけた場合はどうなるかとか、

あるいは自軍パーティ構成を変えたらどうなるかとか、

あるいは、周囲の他の街の武器屋や道具屋・宿屋の主人に話しかけたらどうなるかとか、

いろいろとテストプレイで試します。（このテストには時間が掛かるので、なので先に報告しておく必要がある。）

仕様の矛盾や不具合を見つけた時の報告

概要

デバッガーは、場合によっては、バランス調整チームよりも先に、テストプレイをする場合もあります。

その場合、細かなバランス調整などはデバッガーはしないで、あとのバランス調整チームに任せます。さて、このようなデバッガー先行のテストプレイのとき、仕様（設計）そのものの問題点をデバッガーが見つける場合も、ときどきあります。

プレイヤーにとって「よかれ」と思って作られた設計が、実際にゲームに実装されてみたバージョンをプレイしたとき、その仕様のせいで他の問題点が発生していたりとか、そういう現象にデバッガーが遭遇する場合もあります。

なので、バグ報告のサーバなどは、仕様の改善案などの提出サーバなども兼ねます。

この場合、けっして単に「この仕様のここはオカシイ」とだけ報告を入れるのではなく、できれば大まかに改善案を提案し、つまり、どう直すとイイかを自分なりに考えて数パターンほどの改善案に提案すると、担当者に話が通じやすいです。

こう説明したほうが通じやすい理由は、具体例があったほうが分かりやすいから、です。提案する事自体はあまり目的ではなく、具体例で説明して分かりやすく伝える事が目的です。

シナリオなどのデバッグ

シナリオ系バグの種類

テストプレイヤーは、シナリオ検証も必要です。まず、一口に「シナリオ系のバグ」と言っても、下記のように大まかには幾つかの種類があります。

• 大元の脚本自体に矛盾があり、ストーリーなどが前半と後半で矛盾しているような場合、
• 脚本のストーリーには問題なさそうだが、ゲーム作成時のフラグ分岐などの対応用シナリオの作成漏れや内容ミス、

などです。

実際には、上の2種類のバグが融合したような、シナリオバグもあります。もしかしたら、だいたいソレかもしれません。

ともかくゲームの場合、一般の小説やマンガとは違い、プレイの結果によるフラグ分岐によってストーリーが変化するという性質があります。

このため、上記のように、フラグ分岐の数が増えたら、ゲーム内イベントなどの小ストーリーも追加して新たに作成して加える必要があります。

一つのゲーム内には、イベントがいくつもあるので、ときどき、イベント用の小シナリオ作成時にミスとして、そもそものフラグ分岐に対応し忘れたために、そもそもの分岐先シナリオが欠けてしまうバグの場合があります（もちろん、デバッグで直す必要がある。つまりデバッグとして、忘れていた分岐シナリオを作成してゲームに実装する必要がある）。

あるいは、分岐先の対応シナリオそのものは存在しているが、しかし実際のフラグ内容と、分岐シナリオのメッセージ内容がミスって不整合になっている、などのような事例です。

脚本自体のバグの場合

仮に、改善すべきシナリオバグの種類が、脚本自体のバグだとしましょう。もし、キャラクターの会話文などの表現の問題である場合、たとえば、「この性格のキャラクターが、こういう事を言うのはオカシイ」ような問題の場合なら、

改善案の提案では、具体的なセリフは書かないでおくほうが、著作権などの理由で安全な場合もあります。

たとえば、

「このシーンでなら、このキャラクターは、これこれこういう内容の発言をすべきです。なぜなら～～～」

みたいに、説明文で説明したほうが伝わりやすいです。

あまり、キャラクターの言い回しなどの具体的な表現は、デバッガー側では考えず、表現についてはシナリオライターなどの著作者に任せたほうが、お互いにラクです。

その理由は、法律の著作権などの理由もあります。著作権法では、アイデアは著作権の対象には、ならないのです。（法学の専門用度で「アイデア/表現の二分論」と言います。）

社内の権利関係の管理をラクにさせるため、著作権者はなるべくシナリオライターに統一させます。

そのため、あえてデバッガーなどは、もし表現の不整合に気づいて改善案を出す場合でも、アイデア提案までに留めたほうが良いでしょう。具体的な言いまわしなどはシナリオライターに任せたほうがいいかもしれません。

これは裏を返すと、ゲーム製作では、じつはメインのシナリオライター以外にも、プログラマーやグラフィッカーやデバッガーなどのスタッフも、テストプレイなどを通して、実は少々のシナリオ提案をしている、という事でもあります。（もちろんシナリオ作成の比率はシナリオライターのほうが高いですが）

会話文にかぎらず、ゲーム中の説明文の表示なども、実際にどう表示するかは、なるべく、それぞれの担当者に任せるのが良いでしょう。

テストプレイ中に矛盾点に気づいた場合は、具体的な表現には踏み込まないようにして、しかしアイデアは具体的に「ここでコレを表示すべきです」みたいに具体的に提案する必要があります。

このようにシナリオのデバッグをする際の注意点・留意点として、なるべくシナリオ変更のアイデアの決定権は、シナリオライターに任せます。つまり、けっして多数決には、しないほうが安全です。理由は幾つかありますが、理由のひとつとして、追加シナリオや次回作シナリオなどの今後のシナリオ作成時にも対応する必要があるから、です。

単に現時点で存在しているシナリオ案だけの一時的・一部の矛盾を直すだけなら、単なる（非シナリオライターの）テスター・デバッガーでも出来てしまいますが、しかし変更したシナリオをもとに今後のシナリオを考える事をするのはシナリオライターでないと困難です。

このため、シナリオ変更案の採用の有無の権限は、シナリオライターおよび開発リーダーなどに（採用の権限を）委ねましょう。また、けっしてシナリオライターを飛び越して開発リーダーに直訴・越訴するような事は断じて、やめましょう。

このような直訴・越訴のようなトラブルを防ぐ方法として、たとえば、最初から社内公開のサーバーで仕様変更案を受け付けるとかのように社内公開の場でのみシナリオ変更案を受け付けるなど、そういった工夫などをすると良いかもしれません。

さて、シナリオ改善案の採用の権限は、シナリオライターと開発チームリーダだけが握るのでした。

つまり、けっして小中学校の学級会のような、多数決で何でも決まるような決定方法は、行わないほうが良いでしょう。というかそもそも企業社会は基本的に、学級会のようなシステムは取っていません（たとえば株式会社における株式総会ですら、決して多数決ではありません（株数に応じて票数が割り当てられるので））。

ときどき、高校や大学を卒業したばかりの人は、ここら辺の社会常識を勘違いしている人がいます。自分がそういう勘違い人間にならないように、気をつけましょう。学級会や、現実の政治選挙のような決定システムは、社会全体で見れば、割合と特殊で異例な決定システムです。

※ マンガ業界でも、既に1990年代に漫画家の小林よしのりが造語の『学級民主主義』という表現で、彼の著書のゴーマニズム宣言の中で、上述のような若者にありがちな、ビジネスを学級会と混同するような勘違いを揶揄しています。

また、こういうことは、テスター視点ではなくゲームデザイナーなど担当者の視点から考えてみれば、デザイナーは、テスターなどからの意見は聞くが、しかし判断は絶対にゆだねず、最終的な判断はデザイナーが自己の責任をもつことを覚悟するということでもあります。書籍『ゲームデザイン プロフェッショナル』によると、書籍では文脈はやや違ってシナリオ改善案に限ったことではないですが、文献中の大見出しで「意見を聞くが、判断は決して委ねない」とあります。テスターの話に限らず、ゲーム制作のチームリーダーが『最もやってはいけないコミュニケーションのひとつが、「話を聞きすぎること」』だと著書の塩川氏は述べています」。

マンガ『ナナのリテラシー』第2巻でも、作中の老齢ゲーム作家が商業ゲーム開発を「エゴイスティック」という表現とともに、けっして皆で仲良く作るものではないと自身の体験を説明しています。

また、1995～2005年頃にゲーム評論家の阿部広樹が著書で言うには、彼はもとはゲーム会社出身でその後にゲーム評論家になったのですが、ある作品のゲーム評論にて、そのゲームは学生レベルのゲーム制作をテーマにしたシミュレーション的ゲームだったのですが（つまりゲーム内キャラがゲームを作る）、おおむね阿部は「このゲームでは、能力値の低いキャラは、仲間にしても足手まといだが、著者の経験からするとリアルである」と表現していました。

イマジニア社の1999年の作品『ゲームソフトをつくろう』というのがありますので、おそらく時期的にこれだと思います。

ともかく、多数決でのゲーム制作は、論外のようです。

なお、開発チーム内に複数人のシナリオライターがいるサークル内での場合については、その場合でも上記の開発例と同様に、なるべく、メインのシナリオライターと開発リーダーにだけシナリオ変更の採用の権限を委ねるのが、トラブルを防げて安全だと思います。（ただし、劇中劇などのように、特殊性の高い部分シナリオの場合、その劇中劇だけサブ・シナリオライターなどにも決定権を与えるのも、アリかもしれません。）

たとえば、ゲームに限らずアニメ業界などでも一昔前では、アニメ監督をしている人が、自身の監督している作品が終わった後の時代には、他のアニメ監督の下で下働きをしているような場合もありました（最近はどうか知りませんが）。

マンガ界などでも一昔前では、月刊マイナー漫画誌などで連載終了して手の空いて収入も無くなった漫画家が、別の連載作家（たいてい、終了した側の漫画家が元アシスタントをしていた作家）の連載中マンガ制作を手伝うような事も、ときどきありました。

「船頭多くして、船、山に登る」という戒め（いましめ）のコトワザがあります。

ゲーム開発でも、決して船が山に登らないようにするため、メインのシナリオライター・開発リーダーなどにシナリオ採用の権限を一元化するのが安全でしょう。

そうそう、漫画家は、会社員ではありませんので、連載やアシスタント仕事などの無い期間は、給料はゼロ円です。印税などで稼ぐしかありません。また、単行本の売り上げが少なすぎる場合、単行本化を打ち切られますので、印税の収入源も途絶えます。

世間でよくある勘違いで、「作家を、いったんプロになれば、（公務員のように）定年まで身分（および収入）が保証される」というような勘違いをしている人が多々います。しかし、全く現実に即していない勘違いですので、考えを改めましょう。漫画家の 小林よしのり も、彼は少年ジャンプでのデビュー前まで、てっきり漫画家は定年まで収入が保証されるものだと勘違いしていたと著作『ゴーマニズム宣言』で述べています。

マンガに限らずアニメでも同様です。

これはつまり、元・連載漫画家が、自身の連載終了後に他作家のアシスタントとして生計を立てている場合、当然ですが収入額はアシスタント時代にまでダウンしています。

アニメ監督が、別のアニメ監督の人の下で下働きをしている場合もおそらく同様に、給料は下働きか、せいぜい中間管理職くらいの収入額までダウンしている、という事です。

なのでゲーム会社員でも、他のシナリオライターの下でシナリオのデバッグをしている場合、当然ですが収入は（もしあるとしても）、テスター程度のものだろうという事を覚悟しなければならないかもしれません（このページ書いた人は、あまりよく知りません）。もっとも、そもそもフリーゲーム開発の場合なら、収入自体がゼロですが。

どんな矛盾がシナリオ脚本のバグか？

ゲームに限らずマンガやアニメも含めた娯楽フィクションのシナリオの場合、現実とは違って、意図的に矛盾を起こしたシナリオを使う場合があります。たとえばギャグ作品なんか、わざとトークの前後で矛盾をさせる事もよくあります。落語なども同様でしょう。

さらにファンタジー世界やSF世界などで（私たちの）現実世界とはゲーム中の物理法則や時空の法則が違っているので、現実では矛盾していても、ゲーム設定としては矛盾していない場合や、矛盾していても「演出」などとして許される場合もあります。

このため、シナリオの矛盾の報告で、修正すべき矛盾を見つけるのは、なかなか難しいです。

ゲームでは更に、テンポ感などの理由で、小さな矛盾を製作者が意図的に無視する場合すらあります。もし矛盾を修正しようとすると、ゲーム中での説明会話が長くなってしまい、「テンポ感を損ねるだろう」といった判断によって、小さなシナリオ矛盾を残すという高等的なテクニックすらあります。

例外として推理ゲームや推理イベントなどといった、けっして矛盾の許されない例外を除き、ゲームシナリオのデバッグでは必ずしも、杓子定規に全ての矛盾をゼロにするという事は、ゲーム開発では良策とは限らないのです。

アニメ業界でも、ギャグ作品ではないですが、宮崎アニメの主人公パズーの会話シーンで、実はストーリーの冒頭と中盤と後半の会話を見比べると、じつは主人公パズーの性格が微妙に一貫していない、という指摘がアニメ評論家からされた事もあります（「と学会」や「トリビアの泉」で有名な唐沢俊一が８０年代の当時、そういう指摘をしていました）。アニメでもテンポ感のために意図的に矛盾させる技法もあります。

直すべきバグとは作品テーマに反するバグ

ですが、それでもあえて、あるシナリオの矛盾を修正しなければならない場合もあります。その例の一つとしては、物語のテーマに反する誤解を与えるような矛盾のある場合です。

たとえば、物語のテーマが、「思春期の男女は、恋愛を通じて人間性も成長する」というようなテーマの場合、もし、たとえば恋愛関係にある男女（仮にボブ（男）とクレア（女）としましょう）が、本来ならボブとクレアは恋愛関係にあるのに、テンポなどの事情でセリフが削られたりして、あたかも「ボブとクレアは嫌いあってる」とか、そもそも「ボブとクレアが恋愛関係にはない、単なる同級生」のような印象をプレイヤーに与えるようなシーンがあるとしたら、おそらくそのシーンはバグと見なして修正されるべきです。

このように、物語テーマに反するシーンなどは、シナリオのバグの可能性があります。

裏テーマという存在

なお、ゲーム開発において必ずしも、いちいち「このゲームのシナリオのテーマは、〇〇です。どういうことかというと（以下略）」みたいな説明は無いことが、よくあります。

「プレイすれば、まともな感覚があれば、物語のテーマくらい分かるでしょ？　大人なんだからさぁ」みたいな感じで、いちいちシナリオテーマはデバッガーなどには説明されないでしょう。

あるいは、表向きのテーマとは別に、名言されていない裏のテーマなどが存在している場合もあります。演出などの都合で、裏テーマはあえて名言されない場合もあります。

たとえば小学生くらいの子供むけのターゲットな明るいゲーム作品などで、「良い大人になるためには、子供はどうあるべきか？」みたいなマジメなテーマは普通、名言はされないで、裏テーマに回るでしょう。

なのでシナリオのデバッグをする場合には、そういった裏テーマも読み取った上で、シナリオをデバッグする必要があります。

上記のノウハウを聞くだけなら簡単そうですが、しかし大変なのは、この「裏テーマの発見」をする事です。シナリオのデバッグ中に、けっしていきなり裏テーマにピンポイントな修正案件が見つかることはありません。

たいてい、最初に見つかるシナリオバグは、単なる設定矛盾などです。

単に仕様書などと照らし合わせれば発見できる一般的なバグとは違い、シナリオのバグの発見には作品への読解や理解が必要です。なので、けっしていきなり最初にピンポイントにシナリオの裏テーマ関連バグは見つかりません。というか、そもそも裏テーマは巧妙に隠されてるからこそ、「裏」のテーマなのです。

テスター・デバッガーたちが細かな設定矛盾などを報告してプログラマーなどが直しているうちに、たまに、ついに裏テーマにピンポイントなシナリオ矛盾をデバッグ関係者の誰かが見つけるって事が、たまにあります。

このように、けっしていきなりは、ピンポイントなシナリオ矛盾は見つかりません。

なのでまず、小さなシナリオ矛盾であっても、よほどテンポ感を下げない限りは、（なるべくテンポ感を下げないまま）とりあえずは矛盾を直していく（矛盾を小さくしていく）のが安全です。

諺（ことわざ）「将を射んと欲せば、まず馬を射よ」のようなものです。

あと、そもそもシナリオライター自身が、自身の脚本に隠れた裏テーマにあまり自覚できていない場合もあります。なのでライターに「この作品のテーマはなんですか？」とか質問しても無駄です。なのでテスターなどが頑張ってシナリオを読解・推察していくしか、裏テーマを見つけだす方法は、ありません。

なお、本wikiでは説明の都合で、あたかも報告当時に「これが裏テーマだ」と気づいたかのように説明しますが、しかし実際には「裏テーマ」として気づくのは数ヵ月後またはリリース後だったりします。

月日が経ってから、ようやく、あとで「あ、あのときシナリオ修正されたアレこそが物語の裏テーマだったんだ」と気づいていきます。

シナリオライター自身の見落としてい第3の物語テーマがテスト中に見つかる場合もありますが、これも「テーマだ」として自覚されるのは数ヵ月後だったりリリース後だったりして、リリース前のデバッグ期間中にはテーマかどうかは分からないものです。

このように、裏テーマか第三テーマかどうかは、リリース前のデバッグ期間中には判定しづらいので、あまり杓子定規には堅苦しくは考えすぎないようにして、とりあえず、ある程度はシナリオライターたちの感性に任せてシナリオ修正していくことになるでしょう。

レアケース対応漏れなどのシナリオバグの探し方

レアケース対応漏れなどといったシナリオ作成漏れのバグの探査方法は、仕様書があればそれで見つけるのも良いですが、他にもゲーム実機の実際のテストプレイなどで見つかることも多いです。

なので、テスターはまず、そのゲームの想定するシナリオを通しプレイなどでクリアして、いったんシナリオを把握します。その後、フリープレイ時やテストプレイ時などに、ついでにシナリオ上の矛盾点が見つかる場合もあります。

イベント進行などの状況によって会話などのテキストメッセージ内容が変わりゲーム作品も多くあります。もしゲーム中の説明文や会話文などのメッセージ文の内容と、イベント進行状況が組み合っていなかったりする場合には、バグとなります。

つまり、シナリオ作成時のミスで、分岐先シナリオの作成漏れが出てくる場合もあります。

このようなメッセージ内容のバグは、テスターが実際にゲームのシナリオを把握していないと、そもそも「これはバグである」とは気づかないのです。

さて、このイベント進行状況とメッセージ文の不整合により、ときどき、作品テーマに反する誤解をプレイヤーに与えてしまう場合があるのです。

たとえば、（いくつか前の段落の例での）ボブとクレアの恋人関係の例なら、ストーリー前半でクレアが主人公の仲間になっているのに、もしボブのメッセージ文がストーリー前半でのクレアのパーティ加入に対応してなかったら（もしフラグ管理ミスでストーリー中盤以降からしかクレア加入の場合にしかボブ会話文のフラグ分岐が対応してなかったら）、あたかもボブが恋人クレアをガン無視している（←フラグ上ではクレアが未加入なので. ）かのようにプレイヤーに誤解を与えてしまいかねず、ボブとクレアが不仲になったかのように誤解されかねない・・・、というワケです。

たとえば、クレアが仲間になる条件が、加入条件になっている中盤ボス（レベルはストーリー中盤相当）を倒すことだとして、一般的なプレイヤ－はゲーム中盤にそのボスを倒すので、クレアを仲間にするのも中盤になるプレイヤーが多いとしましょう。

ですが、もし（中盤ではなく）ゲーム前半でもその強ボスを倒すのが原理的に可能なプログラムになっているゲームの場合、プレイヤーの一部はストーリー前半でもそのボスを倒して、クレアを（中盤ではなく）ストーリー前半で仲間にする場合もあるのです。こういったレア目なケースは、理想的にはシナリオ作成の段階でレアケースにも対応できれば理想ですが、しかしライターやプログラマーなどの忙しさなどの関係で、レアケース対応のシナリオの執筆や実装そのものが忘れられて分岐先シナリオ自体の作成漏れというミスをしている場合があります（特にフリーゲームや同人ゲームなど）。

つまり、（「あるイベントのシナリオが仕様と不一致」ではなく）「そもそも、イベントのレアケースの場合だと、その場合のシナリオ自体が作成漏れで無い」という事例もあるのです。

しかしプログラム的に禁止されて無いプレイである限りは、どんなにレアなケースでも、プレイヤーの一部には、そのレアケースのプレイをする人も少数の割合ながら、いるのです。

このようなレアケース漏れや分岐シナリオ作成漏れを見つけるには、テスターは実際に何周もテストプレイをしてみて、様々な攻略パターンでプレイして見つけるしか、ありません。

このような事例があるので、なのでシナリオのバグの有無の確認では、（けっして脚本テキストデータの通読だけでなく、加えて）実際にゲームをプレイしてみて、ゲーム中のメッセージ文をプレイの順序どおりに読んでいくという方法により、テストプレイではバグの有無を確認していく必要があります。

RPGのシナリオは一本道

岡田斗司夫の1997年『東大オタク学講座』に書かれている事例ですが、 RPGのシナリオは実はほぼ1本道であり、アニメの作り方と似ている部分もあると言われています。

岡田は、そういう RPGの作り方を、ルナ・シルバスターストーリーなどのシリーズを作っていたゲーム会社の人から聞いたと言います。

そして岡田は、大学の講義などで、「確かに市販のRPGのシナリオ構成はそうなっていて、途中で若干の分岐がある場合もあるが、おおむね一本道のストーリーですね」と講義で学生に言っています。

特に大学生から反論が出たとかそういう話は聞かないし文中にも書かれていないので、まあ、大学生もそう思っているのでしょう。

本wikiを読めばわかると思いますが、シナリオ選択肢の自由度に限らず、ゲーム中の自由度の高さはそのままデバッグやバランス調整などの手間を二次関数的に上昇させますので、

よって、ゲーム全体でシナリオのパターンを増やすなどして自由度を高めるのは、調整などの手間が上がります。（また、それとは別理由も考えられ、単純に古いゲームは容量不足の問題もあるので、なんでもかんでも機能を詰め込みできない。）

フリーシナリオで有名なロマサガのシリーズですら、結局は最後に倒す敵は共通ですし、最後のほうに訪れる地域やダンジョンもおおむね共通です。 真・女神転生シリーズなども少なくともスーファミ版の時代は同様です。

実装の手間を無視した企画だけなら、自由度の高い作品の企画や、カスタム性の高い企画は、いくらでも出せます。しかし実際は、人件費などの制約が生じます。

ゲーム評論家の阿部弘樹も、この人はゲーム業界出身であり企画の仕事もしてたのですが、彼はゲーム会社時代の企画で「ファイナルファンタジーのようなファイナルファイト」を思いついたと言いますが、 企画当初は上司に絶賛されたものの、しかし企画を詰めていく段階でシナリオなどの実現性が困難として、仕方なく諦めざるを得なかったという体験談を、阿部の著書では述べています。

もちろん、アクションRPG自体は実現性あるジャンルであり、実際にファルコム社のイースのシリーズのようにファンタジーRPGをアクション化したものは存在します（阿部もイースに言及している）。

しかし、イースは操作キャラクターが1人（主人公アドルだけ）ですし、武器や防具の種類も少な目です（たとえばスーファミ版イース3では、武器は剣の5段階のみ。）

なのにもし、ファイファン（RPG）のようなファイナルファイト（格闘ゲーム）を作るとなると、 まず操作キャラクターの分だけ、

イース一本（アドル一人分）のシナリオ量　×　キャラクター量

のシナリオが単純計算で必要になります。

その上、ファイナルファンタジーのように多種類の武器（剣のほか槍や斧や弓やハンマーやムチや・・・）や防具の種類を作るとなると、 そのぶんの調整も、膨大に増大します。調整以前の武器の設定などを考えるのも一苦労です。

単純計算で、武器の調整だけでも、　

武器の種類分　×　イース調整　

の手間になります。

しかも、これがファイナルファイト（格闘ゲーム）のようにコマンド入力の必殺技などを用意するわけですから、 かなり製作がキツイです。

阿部らの会社は、こういう制作作業の膨大さや調整などの手間に気づき、なくなく、「ファイナルファイトのようなファイナルファンタジー」案を諦めました。

アイデアの批判をしない

ゲーム開発では、予算の問題などで不可能になるアイデアはありますが、しかしだからといって、けっして、アイデア出しの段階で、予算のことばかりを考えてはいけません。

程度問題ですが、ちょっとぐらい予算が掛かりそうでも、とりあえず色々とアイデアを考えて見ましょう。また、もしかしたら予算をかけないで上手くやる方法がそのうち見つかるかもしれません。リスクを負わなければリターン（報酬）もないのです。

「ブレイン・ストーミング」という集団でアイデアを出すための基本テクニックがあり、それによると、そもそもアイデア出しのための打ち合わせや企画前段階の時点では、批判をしません。

批判をしない、結論を出さない、

奇抜なアイデアを歓迎、

質より量。とにかく量。

他の議論参加者のアイデアの流用を歓迎、

などが、ブレイン・ストーミングの基本テクニックです。

ブレイン・ストーミングについては高校でも習うので、それを参照してください。

チェックシートを作成する場合

テストシートを作るなら

フリーゲームや小規模の同人ゲームでは不要かもしれませんが、大規模なゲームを作る場合は、テストにおいて、確認漏れの無いようチェックシートが普通は必要であり、そのような一覧表のことを「テストシート」または「テスト仕様書」などと言われます。

ここでいう「テストシート」または「テスト仕様書」とは、バグが無いかの検査するためのチェックリストの一覧表のことです。

なお、「デバッグシート」とは意味が違います。デバッグシートとは、バグが実際に発生した際、そのゲームに寄せられたバグの報告を一覧にまとめたものです。

ゲームの場合、テストシートに必要とされる項目はある程度は慣習的に決まっていて、

【前提条件】　下記の手順のための前提条件（イベントAをクリア済みとか、アイテムBを入手済みとか、）

【手順】　確認すべき手順の明記。手順が複数の段階に分かれる場合、「1番: 〇〇画面で□□のボタンを押す」「2番: △△画面で××キーを押す」のように、番号も明記しつつ、手順を確実に明記。

【期待される結果】　上記の手順の実行後に期待される、（もしバグが無い場合の）正常とされる場合の仕様の明記。

【実際の結果　手順の実行後に実際に起きた結果を、欄内にうまくまとめる。

【合格、NGの明記】　けっして文章で曖昧に長々と説明するのではなく、「合格」または「NG」などと明言する欄を設けるべきです。（「不合格」だと脱字の際に「合格」と混同の恐れあり）

【日付、確認日】　仕事の書類を作る際、後日の管理のために、確認日の日付が必要です。

【確認者】 その確認日に、確認した人物が誰なのかも明記します。順序が逆の場合もあります（先に確認者、あとに確認日の場合も）。

なお、ゲーム以外の一般のIT業界でも、テストシートの要件はおおむね上述のように「前提条件」・「手順」・「期待される結果」の3件を含んでいます。

また、数値などをチェックする際は、実際のゲーム中に表示された数値を【実際の結果】欄に書くと良いでしょう。（ゲームに限らず、製造業などの品質管理チェックシートでも同様です。）

なお、【備考欄】などが、最後の列に付く場合もよくあります。（IT業界に限らず、仕事での一覧表は、たいてい、備考欄がいちばん右にあります。）

エクセル（表計算ソフト）などで、上述のような事を、そのゲームの全ての分岐において、チェック項目として各行に記載して、シートにします。なので前提として、そのゲームの設計仕様書が出来上がっている事が望ましいです。

後日に追記したりするので、紙面ではなくパソコン上にシートを作成する必要があります。

デバッグシート（リスト）を作るなら

バグ報告とその対応をまとめた一覧表として「デバッグシート」を作成するなら、最低限、下記の3つが必要でしょう。（※　個別のバグの詳細をまとめたものもデバッグシートという場合もありますが、しかしこの節でいう「デバッグシート」とは別物です。このシートでは、いくつものバグ報告の一覧表の事を「デバッグシート」という事にします。）

【報告時のバグの内容】

【修正後にあるべき目標の正常仕様の定義】

【現在の状態】 報告内容がバグのものなら「確認中」、「修正中」、「修正済み」などの対応を明記。また、要望（※ 後述）などに対しては、採用したのか現状維持なのか等も。他、「仕様確認」などがテスターから送られてくる場合も。

後日に追記したりするので、紙面ではなくパソコン上にシートを作成する必要があります。

この他、バグの詳細説明などを書く場合もありますが、しかし、スペースの都合などもあり、なかなか記載すべきか難しいです。

とりあえず、最低でも、上記の3点（「バグ内容」「正常仕様の定義」「現在の状態」）は必要かと思われます。

また、ゲーム制作の場合、バグ発見テスターから、操作方法の改善提案などの提案や要望などが入る場合があります。

デバッグシートが、この要望リストを兼務する場合もあります。

なので、「要望」なのか「バグ報告」なのかと言った、テストチームなどからの報告の【種類】も一覧に書く必要があるかもしれません。

本来、「バグ探し」と「バランス調整」または（操作システムなどの）「開発」とは別の業務なのですが、しかしテスターが実際に発売前の開発中ゲームの制作にテスターとして参加してみると、色々とバランスや操作性などの問題点にも気がつくものらしいのです（ページ編集者はあまりよく知りません）。

テスターにどの程度の権限を与えるかは会社によって違うでしょうが、一応デバッグシート側では念のため、要望などにも対応できるように【種類】の項目を作っておくと良いでしょう。

この他、仕様書に無い実装、仕様書では不明瞭な実装について、確認の要請の報告がテスター等から送られてくる事もありますので、【種類】の項目に『仕様確認』なども入れられるようにしましょう・

その他、

【確認日】

【確認者】

なども必要かもしれません。