こんにちは。ケムコ社員Nです。
体調最悪です。
春先の花粉の影響で咳、たん、鼻水、のどの痛み、それらに伴う継続的な朦朧状態により仕事もあまり手に着きません。
しかしながら現在進行形で発売前デバッグの佳境を迎えているデバッガー集団を見ていると泣きごとは言っていられないという気分になります。
５年もすればこのようにハードワーカーのひしめく業界の雰囲気にすっかり染まってしまいますので好きじゃない人には向かないですよ（今さら）。
【ゲーム制作における一般的な職種一覧】
☑プランナー（企画）
☑ディレクター（監督）
☑プログラマー（制作）
☑ライター（作文）
☑グラフィッカー（作画）
☑コンポーザー（作曲）
☑ボイスキャスト（声優）
□デバッガー
□マーケター
今回はデバッガーさんです。
テストプレイヤーなどと呼ばれることもあります。既にこれまでのコラムで何回か言及されていますが、彼らはゲーム開発につきもののバグを見つける人です。
直す人ではありません。
バグを直すのはバグを生み出してしまったプログラマーの責任です。
キャラの色合いがヘンだったり話に矛盾があったり音が割れてたりするのは担当したアーティストの責任です。
そもそも仕様をミスったのはプランナーの責任です。マスターアップ直前でバグだらけなのはスケジュール管理が甘いディレクターの責任です。
だからって、だからってそんなに言わなくても・・・！！
これら全ての制作陣のうかつさを容赦なく責め立てるのがデバッガーの仕事です。
彼らももちろん開発スタッフとしてクレジットされる方々なのですが、実際に物を作るのではなく、作られたものの品質確認（Quality Assurance＝QA）を行うという意味で、少々他の制作陣と趣が異なります。
作業を開始するタイミングも違いますしね。
ここまで書けばおわかりでしょう。
デバッガーとその他の制作陣は、恒常的な交戦状態にあります。
とはいえ、デバッガーというのが一体何をするのか、分からない方がほとんどではないかと思います。
早速それに切りこんでみましょう。
最も過酷な環境で動作する、最も複雑なソフトウェア
そもそも論ですが、ゲームソフトは数あるコンピュータソフトウェアの中でも飛びぬけて複雑な構造を持つ部類に入ります。たぶんOS（Operation System = Windowsとかの基本ソフトウェア）の次くらいに複雑なのではないでしょうか。
なぜそんなことになっているのか。
基本的に業務用のソフトウェアというのはシンプルイズベスト、要件を満たす限りにおいて可能なかぎり、構造も使用方法もシンプルなのが望ましいわけです。
一般人に限りなく近いエンドユーザーに使用されるワープロソフトや表計算ソフトでも同様。基本的に立ち上げてすぐ仕事にとりかかるような仕様になっているはずです。
余計な複雑さは、そこには必要ありません。
しかしゲームは違う。
スタッフ編がひと段落する次回より後に書くつもりですが、ゲーム体験（ゲームエクスペリエンス）というものは、シンプルにゲームの中核部分を味わわせるのみで生じるものではなく、ゲームにたどり着くまでのローディングの待ち時間やその演出からすら生じるものです。
遊びだからこそ、余計な手続きが必要で、そこにも手を抜けないとくれば、モノがどんどん複雑になるだろうことは想像に難くないでしょう。
さらに、ゲームソフトウェアには他のソフトウェアにあまりない特徴があります。
乱数や複雑系の存在です。
乱数はサイコロを振って出るような数字、ようはアトランダムな、不規則な数値です。
複雑系とは乱数ではないものの、その結果が出るまでのプロセスが複雑すぎて、その原因となる個々の要素から結果を予想するのが不可能なような複雑なシステムのことです。
業務用ソフトは、基本的にサイコロに用はありませんし、「これこれこういう業務上の作業・手続きをシステム化して効率化する」という目的で作られる業務用ソフトウェアの実現すべきものは基本的にシンプルです。
しかしゲームには様々な乱数や複雑系が存在します。
この敵は1/2の確率で左へ、1/2の確率で右に行く、という乱数判断を行うこともあれば、特定のキャラクターが特定のバフ（強化）影響下で特定の武器を持って特定の敵を攻撃する、といった複雑系も多々存在します。
複雑系における要素の組み合わせパターンは天文学的なものになり、実際のところプログラム段階で組み合わせによりどんな結果が生じるかは想定しきれるものではありません。
というか、制作陣も、どこか複雑系のなかから自分たちが想定しなかった面白さをプレイヤーが見つけてくれるのではないかという期待を多かれ少なかれ持っているものです。
そのように作ったものに抜け穴があるのは当然で、その抜け穴には良性も悪性もあり得るというのもまた当然と言えるでしょう。
ところが同時に、
ゲームプログラムとは最も過酷な環境で運用されるプログラムだといえます。
どういうことか。
業務用ソフトウェアには
適切な運用という概念が存在し、
不適切な運用をすれば不具合を起こすということが（程度問題ではあるものの）ある程度共通認識としてあります。
そもそも、業務用ソフトウェアにはごく限られた「これこれこういう仕様を実現するためのもの」という目的のために作られるものです。
目的が限定されているから、作る側もシンプルにその機能を一本道で提供すればよい。
その目的を実現するためのプロセスもシンプルでよい。
しかしゲームは違うのです。
ゲームは
楽しむために遊ぶものですが、
「楽しませる」という目的をどう実現させるかは、偉い学者さんでも全然答えにたどり着いていない究極のテーマです。
事実、どんなシンプルなゲームであっても、千人のプレイヤーが一つの遊び方をするということはなく、彼ら彼女らは
自分が楽しむという目的のために千差万別の操作、戦略、思想、感想を見せてくれます。そこに適切な運用というものは存在しません。
結果、制作陣が欠いていた着眼点、制作陣が想定しなかった操作、制作陣が見落としていた抜け穴にぶちあたるプレイヤーが出てくるわけです。
また、プレイヤーはゲームで「遊ぶ」わけですが、
コラム第④回で書いたようにゲームを遊ぶということは
何らかのルールのもとに行動や選択を行い、それによって楽しむ行為です。
逆を返せば
ルールの範囲内ならば何でもできる、ルールに則しながらできる限りのことをやって目標達成を目指す、というのが
ゲームを攻略するということの本質です。
明文化されてないうえにワケのわからないルール（
「実は隠してたけど、魔王の必殺技詠唱のタイミングでAボタンを押すとゲームがクラッシュするんだ！ キミの負け！」）が存在すれば、それはゲームというものの本質を揺るがす問題になりかねないのです。
こんなハードルの高い目標を、複雑なシステムによって叶えなければならないのがゲームというものです。
故にバグというものは極めて重い問題であり、デバッガーという専門職がゲーム制作の現場に求められる要因です。
最古の大量生産ソフトウェア
もうひとつ。
ご家庭にパソコンやスマホが浸透し、多くの人がコンピュータソフトウェアを利用するようになった現代・・・よりも30年も昔に、あらゆるソフトウェアに先駆けてご家庭に持ち込まれたのがゲームソフトウェアでした。
現代のようにオンラインバックアップ等の手段をとれないため、製品版におけるバグは永遠に残ることになります。
実際はノウハウのない時代のこと、現在は考えられないような伝説的なバグ入りソフトがたくさん生まれることになりましたが、こういった背景もあり、ゲーム制作の現場では発売前のデバッグは重視される（そして発売後はできるだけ振り返りたくない）風潮はできたのではないかと思います。
またソフトウェアのエンドユーザーが、ある程度タスクの内容を理解した業務従事者ではなく、茶の間で憩う完全なる一般人であるというのもデバッグのハードルを上げていると思います。
お客様は、制作現場のつらさを鑑みての温情とか、「ああ、こういうバグやりがちだよね」といった納得の仕方を、当たり前ながら、全然してくれませんので。
ケムコでのデバッグとは
ケムコはパブリッシャーだと幾度となく言及してきましたが、実はゲーム制作においてはもう一つ、テストハウス・・・つまりデバッグ（QA）を代行する業者という顔も持っています。
ケムコから発売されるゲームは、ケムコ自身が抱えるデバッガー集団によってデバッグにかけられ、一定のクオリティーを確保されています。
これは身内びいきではなく、ガラケーにしろスマホにしろ、多数の端末間の複雑極まる機種差という、ゲーム制作には非常に厳しい条件が立ちはだかっているにも関わらず、ブランド内では基本的に最新のプラットフォーム仕様に即座に対応していく姿勢とか、落ちまくるとか消えまくるとかの致命的トラブルが（あんまり）ないとかいった点は、かなり稀有なアドバンテージだと思っています。
では、そんな我々がどんなデバッグをしているか、秘密の一端を明かしましょう。
１．ディレクターがデバッグをする
コラム第②回で「ケムコ側のゲーム制作陣とはディレクター集団である」と言いましたが、実際ゲーム制作現場での陣頭指揮は開発会社さん側でとっており、ケムコ側では発売スケジュールの調整と、デバッグの監督が大きな作業を占めることになります。
（こう書くと語弊があり、ケムコが主体になって新しいことをやったりする時はディレクターが主導的にゲームの中身作りにも多く参画することになるのですが、どうしてもデバッグの比重が大きいのであえて書いておきます）
ディレクターは全体の進展だけでなく細部の仕様も把握しているのが望ましい。
その観点からも、デバッグに参画するのは有用です。
さらにディレクターはデバッガー経験が豊富な人が多く、だいたいの場合においてデバッグ作業においても主導的な力を発揮します。
ディレクターが現場作業を行うことは他社さんや他業種では珍しいんじゃないかと思いますが、うちでは割とうまく働いています。
２．メインのデバッガー集団はアルバイト・パートさん
思い返せば
コラム第①回に書いていましたね。
デバッガーは、作業内容じたいは比較的単純なため、アルバイトさんに割り当てている会社さんは多数あるものと思います。
多数在籍し比較的様々なワーキングタイムを持つアルバイトさんを、正規労働時間でディレクターが統括するという仕組み。各デバッグ作業の進捗と、デバッガー間の作業引き継ぎなどもディレクターが中心に行います。
実際のところ
デバッグは職人芸であり、入れ替わりの激しいアルバイト軍団に気軽に任せられるようなものでもないので、コアな部分はディレクターとパートさん、人海戦術が必要な多端末検証などにはアルバイトさんが入る、というのが最近の通例になっています。
３．通しプレイ＝ゲームをクリアまでプレイしまくる
デバッグのもっとも重要な本質は、ゲームに触れること・・・すなわちゲームを遊ぶことに他なりません。
本当ならば１度は完全にプレイヤーと同じ条件で遊ぶのがベスト（開発者視点だと気づけないバグを見つけるため）なんですが、ウチは
毎月１本とか狂気のスケジュールで回しているためデバッグ期間にも限界があり、仕方ないのでネタバレ前回の地図や宝箱リスト、デバッグ用の強制勝利機能などを駆使し、スピードプレイを行います。
個々のプレイでは重点目標・・・バランスを主に見るとか、マップの抜け穴を探すとか、戦闘をしっかりやるとか・・・を設定し、それで複雑系を検証します。
ちなみにディレクターはこんなノリで５～６回通しプレイを行うので発売頃にはすっかりゲームに飽きてしまうという深刻な職業病に悩まれています。
４．データチェックを行う
ケムコ独自の呼称かもしれませんが、データチェックとは要は
仕様書と現物との照らし合わせです。
うちでは
攻略資料と呼んでいますが、マップ、魔法やスキルのデータ、敵のデータ、アイテムデータとそれがどこで手に入るかのデータ……などがまとめられた実質上の仕様書を確認しながら、それらが正しく実装できているか調べます。
一般的にソフトウェアのQAというのはこの仕様書の照らし合わせ作業のことを指すのだと思うのですが、ゲームの場合は既に書いたように組み合わせや特殊シチュエーションでの問題が起きやすいので、ここだけに時間を割くわけにも、ここだけで終わらせることもできません。
というわけでデータチェックは人海戦術でざっくりと終わらせ、再び通しプレイに戻ることになります。
５．多端末検証を行う
ケムコはスマートフォン・ガラケーを何百と保有しており、それらを使ってゲームを動作させ、正しく動作するかどうか調べます。
もうこれだけで分かると思いますが凄まじい量の作業になるため、ここも人海戦術で対応します。
デバッグで何を見るのか
データチェックで見つかるバグはまだ楽です。
仕様書という明確な指標があるため、それとの差異を見るだけで（だけ、といっても一字一句の誤字を見逃さない注意深さや、不当なパラメータが設置されていないか見分ける数字的な勘が必要なのですが）、バグを見つけることができるからです。
というか実のところ、複雑なゲームを少数精鋭のチームで高速で作り上げるフレームワークにおいて仕様書には最低限のことしか書いてないことが多いので、
後はすべてデバッガー個々人の知識と経験、バランス感覚によって「こういった所に穴があるのではないか」と探していくことになります。
例えば・・・
- 二度と戻って来ない想定のダンジョンにあえて入るとボスが復活してないか（イベントが２回発生するとそこから全てのイベント処理が狂うことも）
- 薬草をMAX99個持っているのにさらに入手できたりしないか（数値上限を超えることで不正エラー→クラッシュなど重篤な結果になりがち）
- 高負荷っぽい演出を行うスキルを連発して端末がフリーズしないか
- 急激に難易度が上昇する箇所については、それが受け入れられる作りになっているか。プレイヤーにバランス崩壊とみなされるレベルになっていないか
こういった知識に加え、
「今使っているこの端末ではしばしば普通にフリーズするからこれはバグではない」とか
「このバグっぽく見える挙動は既にバグじゃないことが開発者から報告されてるからバグではない」とかいったふるい分けを行い、しかるのちにバグとして報告することになります。
報告には、以下の情報を添えるのが鉄則です。
- 発生原因・・・どういった状況、どういった操作で発生したか
- 再現の有無・・・上記発生原因を繰り返すと毎回再現するのか、何度かに一度なのか、二度と再現しないのか
- 正確な文章表現・・・報告文に日本語的な間違いや紛らわしい表現があると分かりにくいばかりか、最悪見当違いの修正が施される。理解しやすい文章を書くのは非常に大事。
- 穏やかな文章表現・・・冒頭でも書きましたがデバッグは制作陣の間違いをあげつらいまくる行為でもあるので、少しでも言葉づかいを間違えると相手をひどく責めるような状況になりがちです。要注意。
一方ディレクターは、自らバグを探しつつ、デバッガーから上がってくるバグ報告を精査し、以下のようにカテゴライズします。
- 軽微なため、開発者に報告もしない（議論の余地がある日本語表現など）
- 軽微だが誤りのため、開発者に報告する
- 修正が必要なため、開発者に報告する
- 強制終了など致命的なトラブルが頻繁に発生しており、開発者に緊急対応を要請
この報告を受け、開発者は修正を施し、ゲームソフトの圧縮ファイル（通称ROM）を再送付します。
あとは報告と確認の繰り返しになります。
バグという文字の書き過ぎでまた具合が悪化してきたので切り上げます。
心臓に悪いなあ、バグ発生報告……
恐怖体験！ ガラケーデバッグの怖い話
このようにね、デバッグっていうのはつまるところ、勘と経験がモノを言う、まさに職人仕事なわけ。
当然ながらね、ズブのシロウトには務まらないのさ。
ところがね、恐ろしいことは起きるもんだねー。
これはあたしが６年ほど前に、広島県のとある場所で・・・仮にＨ市としときますが、そこで実際に体験した話さ。
その建物はコトブキソリューションっつってね、近所では知る人ぞ知るゲームメーカーの事務所だったの。
その数年前、そのテナントにはロー○ンが入っててさ、
酔っぱらった筆者がトイレに入ってカギかけないまま便器に跨ってたらヤンキーの兄ちゃんが入ってきて「すっすみません！！」と敬語で言われちゃったなんて曰くつきの建物なわけ。
そこに入社しちゃうんだから、縁ってのは不思議なもんさ。
しかし入ったはいいが、カエルの解剖しか能がないあたしのことだ。
上の連中もちょっと悩んだんだろうね。
とりあえず割り当てられた仕事が、デバッグだったわけ。
その時、ちょっとディレクターの島のほう見たら・・・こう、ケータイ３台くらい抱え込んで顔真っ青にした社員が２人くらいいる。
あたしにはすぐ分ったんだ、ああ、この２人、この世のモンじゃないなーって。
嫌だなー、怖いなー。
この世じゃなくて、修羅場にいるなーってさ。
某怪談で有名な方風に進めようと思いましたが、花粉症の症状がいよいよヤバくなってきて何書いてるのか分からなくなってきたのでやめます。
初のデバッグ体験から数件はどれも修羅場チックでした。
ということはきっと全ての制作は修羅場なんだろうなと理解したわけですが、
だいたいあってました。
- 残り１週間しかないのに１日１００件とかの勢いでバグが出る。心臓に悪い。
- 「ヤバいから社員入って」と言われても１～２日入ったくらいだと仕様や現状を把握するだけで精いっぱいなのでだいたい役に立たない。役に立とうとしたら週単位で入らないとならない。１日だけでいいから！ は単なる罠である。
- デバッガーの練度が足りてない場合、練度の高い社員が入ったとたんにすごい勢いで新規バグが報告されていき、計画見直しを迫られる。
今まで何をしていたのか。
- 修羅場進行ではトリアージとも呼ぶべき対応是非の取捨選択が発生する。しかし全員テンパってるので通しちゃならないものを通したり、逆もまた生じる。ミスを２～３度繰り返すとだいたいそのプロジェクトは泥沼にはまる。発売後にレビューが荒れたりもする。
- 特にヤバイのはROMの取り違え。誤って修正前のROMを修正後のつもりでインストールしてしまうと、「全然直ってません！」「直しましたってば！」という応酬になる。事実が判明したあとも禍根が残る。開発者側が送るものをミスってる可能性もあるのであらゆる可能性を考える必要がある。筆者はどっちもやった。
- 最終的に開発者側から「問題を是正できないので戦闘システムを根底から作りなおします」などととんでもない提案がきたりする。それが本気で必要なのか、開発者側が極限状態で錯乱しているのか、見分けないとならない。ちなみに実際に戦闘システムを根底から作りなおしたことはあった。
- デバッグ終了＝開発終了なので、その判断を下せるかどうかがスケジュール遵守の可否そのものにつながる。スケジュールを破ると、そのゲームの売れ行きが芳しくないとかの悪いことが全部スケジュール破ったせいにされるのでみんな絶対に避けたがる。
- しかし如何ともしがたい時もある。時間はない。デバッグは完了しない。そんなときは
えー、ついに書きながら意識を失っていたのでこの辺にしておきましょう。この辺にさせてください。
何だか後頭部がひどく痛む気がする。
気のせいだ。
闇のデバッグ秘密警察なんて存在しないんだ。
それはともかく。
以前「バグのないプログラムは存在しない」と言いました。
実のところそれは発売後のプログラムにだって言える話です。
人間はミスをおかす。
制作側もデバッグ側もミスをおかす。
故にデバッグ漏れは必ずある。
これは言い訳ではなく真理です。
バグがある証明はできますが、バグがない証明はできないのですから。
潰しては現れ、殺しては増えるバグは、制作現場のまさに悪夢そのもの。
それでも、デバッガーという職人たちは、「バグゼロ」を目指します。
それが届かない理想郷であっても。
そこに向かい続けることが、品質のよいゲームを作る唯一の方法なのだから。
今回のまとめ
- デバッグは基本とにかくゲームを触っておかしなところを挙げていく処理
- ディレクターの社員が主導し、アルバイトさんやパートさんを率いて行う
- デバッグは制作の最終工程のため瀬戸際で修羅場になりがち
次回、
マーケターについて。
えー今から言っておきますが
次回の記事は羊頭狗肉です。
ケムコにおけるマーケティング担当者たちの仕事はだいぶよそと違うはずです。
そいつを暴露することが楽しみでなりませんが、
まずちょっと横にならせていただきたい。
皆様も春先のオーバーワークにはご用心を。
※コラムへの感想はkeitai-info@kemco.jpへ、健康相談はお医者さんへ。
【09回 了】
