〈説明〉【テストエンジニア】ゲームの話にかこつけて仕事の話をしようかな
お仕事は何をされているんですか？
昨今、あらゆるゲーム＆システム等…製品が世に出た後に上がってくるのはユーザーからのバグ報告。
そのバグがあまりにもひどい時は口々に「これ、『テスト』したのか？」と問われます。
いやいや、してます、絶対してますって！テストをしてないなら『テストエンジニア』という職業の人たちはいないのですから。
…ですがこの人たち、外から見ると具体的にどういう職業かは不明です。何なら現場の開発者さんたちからも「ご大層な名前つけやがって、金食い虫なだけだろ…」と思われてるケースもありえます。
今回はそんな謎の職業『テストエンジニア』の説明をば。初歩の初歩の説明なので、ご存じの方には退屈に聞こえるかもしれません。
スキルがないとは言わないで
ITに関わらず、製品を取り扱う人たちは『テスト』という概念をしっかり把握しています。そればかりか、このゲーム界隈では一般のユーザー単位で『テスト』という言葉が浸透しています。
で、ゲームの開発現場の凄惨な面白エピソードを聞いたことがある方はここで「『デバッガー』と何が違うの？」と言った疑問が浮かぶことと思います。
まずは『テスター』と『デバッガー』の言葉の違いについて。
■デバッガー
辞書的な意味は、デバッグをする人たちを指します。デバッグとは、発見された製品の故障や欠陥（≒バグと思っていただければ…）を、修正する行為のことです。コードが書けないといけないので専門性は比較的高めです。
■テスター
その名の通り、テストをする人のことになります。ゲームやシステムにおける『テスト』は、製品に潜む障害を見つけ出すことを目的とし、見つかった障害の原因に応じて開発側に対応依頼を行います。テストをすることに特化した人たちです。
あれ？じゃあ開発の人（コードを書ける人たち）がテストもデバッグやれば終わりじゃん。やっぱりテストエンジニアはいらないわ〜。
…ちょ、ちょっとまって欲しい！
辞書的な意味を押さえたので次に進みます。
ここは任せて先にいけ！
開発経験のある方々はご存知だと思いますが、この業界、暗黙のお約束が多い上、システムのパーツはそれぞれ担当者に割り振られているのが常です。
作った人がそのままテストをした場合、何が起こるかといいますと、その場でデバッグによる修正をする強力なメリットが有りつつも、「思い込み」も同じぐらいの頻度で行われると思ってください。
それぞれのパーツを繋ぎ合わせたとき、他のシステムとつなぎ合わせたとき、ゲームハードとつなぎ合わせたとき、その隠れていた「思い込み」が表出することもしばしば。
ここで必要になってくるのが、「思い込み」のないテストに専念する人々、『テスター』というわけです。
『テスト』の真の目的は、出来る限り障害を市場に流さないようにすること。発売前の防波堤の役割となります。
ユーザーって基本的に開発者ではないので、開発者の当たり前が全く通用しません。この値がこう渡されてるからこの動きは当然だよね？と言われても納得なんぞしてくれないのです。
世紀末テスト
ではいよいよ、『テストエンジニア』について。
大雑把に言うと『テスト』をやるために必要なことをまとめる人たちです。製品に対して、今回は〇〇というシステムだから、こういうテストが必要だな、とコネコネする係。なんなら自身でテスターの役割も担います。
テスト、と一口に言っても様々なやり方が存在し、製品の状態、プロジェクトの状況に合わせた適切な方法をチョイスする必要があるのです。
こちら、V字モデルと呼ばれる、「プロジェクトの一生」のごときものを描いた図。
作られた製品に対して、このテストではどんな風に動いていたら合格か？を定める時のイメージをしやすいように利用されます。
例えばキャッシュディスペンサーの入出金に対してテストをするなら…
・お金を入れたり出したりできる？
→機械が動くことのテスト （単体テスト）
・お金の入れたり出したりを記録できる？
→通帳への印字のテスト （結合テスト）
・お金を預け入れ/引き出しできる？
→銀行との接続のテスト （総合テスト）
・お金の入出金の操作はやりやすい？
→UI/UX、操作性のテスト （受入テスト）
と、こんな感じにテスターの動きは入出金するだけで全然変わらないのに、テストされる部分がぜんぜん違うことが伝わりますでしょうか？
こんな感じに、その時、その場所、その機能にふさわしいテストを計画して行く人達が『テストエンジニア』です。
で、『テスト』はやったんですよね？
ゲーム開発現場には、壁の抜けを探すためにすべての壁に何回もぶつかるテストをした…みたいなお話が必ずついて回ります。
本当にあったんでしょうし、できるのならどんなプロジェクトもそういうことをやらせたいです。
…が、それを誰も許さないのが今の時代！
いつまでやるつもりなの？と会社から言われ、
こんなにやるの？とテスターから言われ、
やってなんか効果あった？と開発から言われます。対戦ゲーで全ての技組み合わせを全部テストするぜ！っていうのもやれると至上ですが、やれるわけがありません。寝言は寝て言え、と突っ返されます。
そもそもコスパがとんでもなく悪いんです。『テスト』って。
だって、開発者目線ほぼほぼ完成してる製品に対して、ここで障害が見つかったから直して―とか無邪気にのたまってくるんですもの。
しかも障害が直って世に出たのに、その障害が出ないことに対しては一切プラスに働きません。無いものを知るすべはないんです。
そんなお金をかけてマイナス要素を潰して回る作業故に、悲しい哉、現場によっては軽視されることもあります。
意外とあるのが、発売直前の最後まで開発者自身でテストしちゃうパターン。さっきも書いた通り、思い込みによるエラー周りを潰すことがむずかしい。
それでも致命的な障害は取り除かれていることがほとんどですので、実はこのパターンはそこまで悪い製品ではありません。
他には会社側の納期優先で、テストの量を減らしちゃうパターン。ビジネスなので仕方ありません。必要最小限のテストを目指すのも『テストエンジニア』の仕事です。
『テストエンジニア』の力量が試されます。本当は確認しないといけなかった部分を見逃す可能性があるなのでみんな必死です。
そして、リリースしてから直すパターン。これはそもそも現場の人手不足だったり、納期が法律や契約絡みなどでどうしても変えられなかったり、外的な要因が強いだけでテスト自体は行われています。
ユーザーから障害報告が上がったら直せばいいでしょ？って現場はまず存在しません。インディーの作者さんだって当たり前のようにテストプレイをやってる時代です。いわんや〜をや。
しかし、こんなに頑張っても障害は見つかる……。
おわりに
この業界、犯人探しはご法度です。
発売後の障害は、テストエンジニアがミスってたのかもしれないし、柔軟に動けない会社が悪かったのかも…開発者がやらかしてたのかもしれないし、最悪、ユーザー自身のせいの可能性だってあるからです。
で、あるならばテストエンジニアが頑張ることは、真因の究明と、改善の提案。そして、「次も引き続き、よろしくお願いします」を相手から引き出すことです。
この記事が気に入ったらサポートをしてみませんか？