ゲームテスターという仕事 #1
このnoteの目的
実はゲーム業界でテスト業務を18年近くやってました。
ここ数年はテスターというよりも、管理業務がメインでスケジュール管理や設計をやっていたので現場仕事はほぼやっていません。
そんな自分も色々考えた末に今年からゲーム業界を離れることになり、今は別の業界で働いています。
ところが知り合いのゲーマーがテスターのアルバイトしている＆したいと考えている人が結構いたので、そんな人達に役立てばいいなぁというぼんやりとした考えで、今までやってきた事を整理し、今働いている＆これから働こうかなと考えている人の手助けになればと思いnoteに書くことにしました。
ただ、ゲームに携わる仕事の中でテスターって仕事は結構地味です。どちらかというと裏方に入る仕事だと思います。
もちろん良い点もありますし、この記事を読んでやるかやらないか決めてもらえたらいいな、と思っています。
また、本記事では表題にもあるとおり、デバッグという表現ではなく表題の通りテスト、もしくはテスターという表現を用いて説明します。
それではよろしくお願いします。
テスターってどんな仕事？デバッガーとは違うの？
ゲーム業界でいう「テスター」「デバッガー（デバッグ）」という言葉の指す意味はまあ大体同じです。所属する部署は品質管理部とかそんな名前が多いです。
この二つの呼び名は厳密な意味で見ると違います、、が会社単位でその呼び方が変わったりします。体感ではコンシューマーのゲーム会社だとデバッグ、スマホゲームだとテストと呼ぶ傾向が強い気がしています。
この言葉だけでなく、テスト手法やテストのカテゴリー名も会社によって呼び方が違ったりします。(齟齬が生まれるから本当はよくありませんが)
具体的な意味を知るのは仕事を始めてからさらに深く知りたい、と考えてからで構わないので今回の記事では割愛します。
さて、どんな仕事というと、大まかに分けてこんな感じです。
①開発中のゲームの仕様を把握した上でゲーム内の挙動が正しく動作しているかを確認し、不具合があれば報告する。修正されたら修正されていることを確認する
②開発中のゲームにおいて、仕様に書かれていない部分の挙動を検証し、不具合があれば報告する。修正されたら修正されていることを確認する
主にこういった事をするのが仕事になります。
どちらも実施する目的は不具合がないことを確認することです。
細かい分類はもう少し色々あるのですが一旦割愛します。
基本的な流れとしては①で問題なければ②を行なって、より品質を高めるといった流れになります。
次はこの①と②についてザックリと説明します。
①開発中のゲームの仕様を把握した上でゲーム内の挙動が正しく動作しているかを確認し、不具合があれば報告する。修正されたら修正されていることを確認する について
①はただプレイするのではなく、「ゲーム内にある全機能が開発者が定めた通りの挙動で動作するか」を確認します。
一般的には機能テスト（ほんとはもっと細かい区分もあったりするけど）とかそんな名称で呼ばれたりします。この工程でしっかり不具合を出して直さないと②の工程に行くことが出来ないため、ここでつまずくとリリースが遅れる場合もあります。
このテストはテスターにアドリブで考えさせるわけではなく、どんなテストをしなければいけないかを事前に整理した上でテストしていきます。
その整理した内容をまとめたものは「テスト項目書」「テストケース」「チェックシート」みたいな名称で呼ばれています。
どんなテストをしたかを履歴に残すためにこのようなものを作ります。
このテスト項目書に関してはどこか別の機会に説明出来ればと思います。
この機能テストの「機能」という言葉でピンとこない人が大多数だと思うので、具体的に説明すると大まかに以下のようなテストをします。
表示周りの確認画面上の表示物が正しく表示されているか
ゲーム内の文言に誤字脱字などがないか
キャラクターのモーションが想定通りに表示されているか
ゲームの動作確認ボタンやリンク押下後に正しく画面を遷移するか
ソート/フィルターが正しく機能しているか
ストーリーを進行して、進行不能にならないか
内部的な設定されているデータの確認
設定したガチャの獲得率やドロップ率がゲーム上で正しく反映されているか
設定したバトル中のダメージ計算式がゲーム上で正しく反映されているか
本当にざっくりですが主にこのようなテストをして、正しい表示か、正しい動作かなどをチェックしていきます。
そして、テストを実施する上で重要なのが、「正しい」というのは何をもって正しいとするのかということです。次はその説明をしていきます。
何をもって正しいか、何をもって不具合とするかを最初に確認する
当たり前の話ですが、ゲームを開発する上で誰かが「こういうゲームを作りたい」と考える人が必要になります。
そして、それを一人で全て作るというわけではなく、たくさんの人が関わります。それを説明するために資料が作られます。
その資料を一般的には「仕様書」と呼びます。その「仕様書」に記載されていることを正とした上でテストを行います。
つまり
「自分はこっちの方がいいと思う」
「他のゲームではこうだからこうしたほうがいい」
という考えはゲームをよりよくするための意見としては問題ないのですが、テストをした結果として報告する内容としてはよろしくありません。
なので、「仕様書ではこう書かれているが実際はこうなっている」と報告する形が基本となります。
よくある悪い例として
テスター「リーダー、やばいです」
リーダー「やばいって何がやばいんですか？(イラっ」
テスター「いや、とにかくやばいんすよ」
リーダー「いや、だからさ‥（イライライラっ」
と、こんな抽象的な報告もよくあります。
こうじゃなくても「これがこうなってるんですけど」と説明したところで「そうなんだ、で、そこは仕様書にはなんて説明されてたの？」と聞かれることになり、
内容によってはあくまで個人的におかしいと思っただけで不具合ではなかった、みたいな場合もあります。
まとめると不具合かどうかを判断する際に仕様書に目を通す必要があるため、ん？おかしいなと思ったら仕様書を見てみる、という癖をつけるとよいと思います。
ただし、注意点があります。
プロジェクトによって仕様書は必ずしも正しいとは限らないし、仕様書そのものが存在しない場合もあります。
例えばですが
仕様はプランナーの頭の中にしかまとめられていない
仕様書はあるが、書かれている内容が最新の内容じゃない
口頭のやり取りで取り決められた仕様だった
そもそもない
など。
仕様書は作成するだけでなく更新するのも時間がかかりますし、資料の作成よりも開発することを優先する場合（基本それが当たり前ではあります）、このような問題が起きます。
テスターからすると何が正しいかもわかりにくい状態は自分達のミスにも繋がりますし「勘弁してくれ」と言いたいところなのですが、
それを改善してもらうと約束したところで業務フローを見直すところからスタートしたりするので直近の問題は解決できません。
こんな時は「どうすればいいかわからない」とならず、「何が正しいんですか？」と聞く相手を探すしかありません。
それをやってもいいのかわからない場合はリーダーなり近くの人にどうするの？って確認しましょう。
大事なのは「自分の考えだけで判断して行動しない」ことです。
質問しにくい雰囲気の人もいるでしょうし、誰に聞けばいいか分からない場合もあると思いますが、自身の判断だけで行動した結果が事故になる場合もあるので意識したほうがよいと思います。
大体の場合基本的にリーダーがわかんなかったら聞いてくれと言ってくれると思います。
②開発中のゲームにおいて、仕様に書かれていない部分の挙動を検証し、不具合があれば報告する。修正されたら修正されていることを確認する について
②は一般的にはフリーテスト（フリーデバッグ）とか呼ばれるもので、皆さんが何となくイメージするそれに近いものかと思います。
①と比較すると資料に書かれた内容以外を試す場合が多いため、テスターの知見や経験をもとにテストするイメージです。
？？？となる人もいると思うので砕いて説明すると、ゲームや仕様書に対して意地悪な質問をするとか揚げ足取りをするといえばいいでしょうか。
それでもふんわりしてピンとこない方もいると思うので簡単な例を挙げると、
RPGの仕様書に以下のような仕様が書かれているとします。
アイテム所持数上限は100個とする
敵を倒した際にドロップしたアイテムは直接アイテム所持欄に送られる
ストーリー9に進むにはAというアイテムが必要になる
Aはストーリー8の甲という敵を倒した時に必ずドロップする
しかしながら、この仕様書には以下の事が書かれていません。
「アイテム所持数が上限の100個に到達した状態で甲を倒したらどうなるのか？」
これを試しにやってみて動作を確認するようなイメージです。
所持アイテム数が100個の状態でドロップアイテムを獲得した場合において、所持アイテムをどう処理するのかが仕様書に具体的に書かれていれば①でテストされています。
仕様書に書かれていなかった場合、項目書を作成する人が気を利かせてテスト項目に追加していない状態でかつ、②のテストでそこを誰も試さなかったらバグが残ったままリリースする可能性もあります。
例に挙げたようなものは一般的な観点なので、①の工程でテストしているものなのですが、仕様書に書かれてない部分をテストするっていう考え方で分かりやすいと思ったので挙げてみました。
読んで「だるいな〜」とか考える人もいるかもしれませんが、基本的には「定められたレールの上を歩く、わからなかったら聞く」を意識すれば十分だと思うし、これはどの仕事も変わらないと思うのて興味が湧いたら是非バイトしてみてください。
少し長くなりましたが、次は仕事内容と同じくらい気になるであろう働きやすさとかについても触れます
プロジェクト内でのテスターの立ち位置は？
冒頭にも言ったように裏方になります。
プランナーやエンジニアのように僕らは0から何かを作り出すわけではなく、作られたものを第三者視点で確認する仕事になるためゲームの売り上げにも間接的に貢献する形になります。
この「自分たちは0から何かを作れる立場ではないがゲームを作る一員である」ことを忘れている、もしくは認識していないテスターは少なからずいるので忘れないようにしたいところです。
こうなってしまう理由は環境やテスターの教育にも問題があるのですが、言い出したらキリがないのでここでは触れません。
ただ、ここを意識していないと開発陣とQAの間にどんどん歪みが生まれたりするので大事な意識だと思います。
次はだれもが気になる働く上でのメリット、デメリットについて触れようかと思います。
働くメリット
ゲーム業界で働くという目的を達成する観点なら敷居が低く働きやすい。一定のコミュニケーションが取れればどんな人間でも働くことが出来ます。そこにPCの基本的なスキルや、ゲーム経験が豊富だとさらによいです。ちょっと興味ある、というなら登録制のアルバイトでもしてみてどんな感じか試してもよいと思います。
服装、髪型、ネイルなどは基本自由
ゲーム業界全般がこの風潮なのであまり指摘をされません。自分も普段着で通勤してましたし、髭も伸ばしています。
ただし、自由でも不潔なのはNGですし顧客にテスターを派遣するタイプの会社だとそれなりの身だしなみを求められる場合があります。
今までのゲーム経験が活かせる
「ああ、このゲームは○○に似ているな」
「あのゲームはこうだったのにこのゲームだと〜」
のような視点で考えられるのはテストの結果として報告するのはよくないのですが、そういう考え方が出来るのはかなりよいことです。
客観的な視点はゲーム開発にはとても重要なので「俺の意見なんか〜」とはならずに、
意見を言える機会がある時に整理できているといいかもしれません。
意外と時間の融通はきく仕事
基本的にほぼ土日休みで残業も少なめです。
理由としてはテスト関連の業務は直接的に売り上げを出す仕事ではなく、コストを消費するだけの業務になるため残業や休日出勤をすればするほど会社に負荷がかかるためです。
なので、会社側としては、残業や土日出勤をさせるという選択を出来る限り取りたがりません。
ただし、納期が迫ったり、人が足りないみたいな場合はやらざる得ない場合はもちろんあります。
忙しいか忙しくないかは担当するプロジェクトによります。
テスターからキャリアアップしていく流れが少しずつ出来ている。
自分はゲーム業界でほぼ最初から最後までこの仕事でしたが、プランナーになる道を選ぶ人もいればプロジェクトリーダーになる人もいます。
テスターという仕事は専門的な知識は身につきますが、スキルを身につけられるかというとそうではない場合が大半なのが現状です。
なので、キャリアアップを望むのであれば新しい事を1から覚えなければいけないことを考えると、なかなか大変かなと思います。
また、近年は少しずつQAという仕事自体を専門職と考える人も増えてきているので10〜20年前のようにテスターから何も広がらない、といった状況ではありません。
また、テスターとしてキャリアアップも出来ます。
例を挙げると
テストの現場の管理をするリーダー
テスト項目書を作成するテスト設計者(リーダーが兼任する場合もあります)
テストの全体を把握したり、方針を決める管理者
などですね。
テストを実施する仕事とは毛色が変わるので向き不向きがより出やすくなると思いますが、そこは働いてみてどうなりたいか考えればよいかと思います。
働くデメリット
好きなジャンルのゲームの仕事が必ずしも出来るわけではない
「自分は○○が好きなので〜」というアピールはできますが、
自分が作ったゲームではないので必ずしも好きなゲームや面白いゲーム、特定の会社のゲームに出会えるわけではありません。
好きなゲームしかしたくない、という考えだと中々ストレスが溜まると思うのでやめたほうがいいかな、と思います。
一応言っておくとその傾向があった人だとしても、過去にそういった不満を言う人はあまりいなかった気がするので問題ないかもしれませんが。
雇用形態によっては収入は安定しない
ゲームテスターはアルバイト雇用が大多数です。
会社によっては登録制で働きたい日に登録する場合もありますし、週5日固定の場合もあります。
登録制の場合、本人の希望を汲むだけでなく会社側でアサインするかどうかを選定するので会社が呼びたくなる人材にならないと、働きたい日に働けない場合もあります。
じゃあどんな人を呼びたいか、となるのですがイメージはこんな感じです。
・当欠がなく勤怠が安定している
・最低限のコミュニケーション（挨拶、質問、終わりましたとかの報連相）がきちんと出来る
・PCの基本的操作ができる
・やべーやつじゃない（結構重要）
まあ当たり前の話だと思うので、社会人経験をしている人はそこまで不安にならなくてもいいかな、と思います。
正社員の道は結構遠い
最初は1つ1つのテスト項目を消化していく立場であっても昇給はしていきますが、
最終的には、自分がいかにコストパフォーマンスが高い人材であるかが重要視されることになります。
つまり、「自分は人の〇倍働けますよ」ということを証明する必要があるってことですね。
具体的な例をあげると複数の案件を管理できるとか、他の人が1日かかるものを0.5日で完了できるとかそんな感じです。
バグをたくさん見つけるとかでも評価される場合もあるかもしれません。
なので、アルバイトから正社員になるというのは結構大変かなあと思っていますが頑張る人は応援します。
相談があればどんどんしてもらえれば答えます。
出来ればTwitterのDMとかがいいかもしれません。
こんな感じで今回は基本的なことを書いてみました。
需要があればどんどん書いていこうと思います。よろしくお願いいたします。
この記事が気に入ったらサポートをしてみませんか？