QAエンジニアってどんな仕事?~ゲーム開発におけるテストの世界~

はじめまして。 

セガゲームス「龍が如くスタジオ」専属QAエンジニアの阪上と申します。 

今回は、QAエンジニアという職種の紹介とゲーム開発におけるテストの話を、「龍が如くスタジオ」での開発の歴史を振り返りながらご紹介したいと思います。

目次

ゲームのテストって何をするの? 

本題に入る前に、QAエンジニアのQAとは何なのかを説明しておこうと思います。QAは 「Quality Assurance」の略で、日本語では品質保証という意味です。ゲーム開発においては、ゲームが正しく動作しているか、バグがないか、ゲームが製品クオリティに達しているかなどを検証する仕事・部門・チームのことを指します。

QAがわかったところで、ではゲーム開発でテストとは何をするのかというと、ゲームを実際にプレイして、バグを見つけて修正することを指すことが多いです。(システム開発等で行われている単体テストやスモークテストなどもありますが、こちらは後半で説明します。) 

発売前のゲームをプレイして、バグがないか、仕様書通り動作するか、製品としての基準を満たしているか、ゲームとして面白いかどうかを検査する仕事を、テスターやデバッガーと呼ばれる職種の人が担当します。 壁にぶつかって抜けないかをテストする単純なものから、複雑な手順やシビアなタイミングで起こる不具合を見つけたり、物理的にケーブルを抜き差しするテストなど、その仕事は多岐に渡ります。 

ゲームのテストというと、バグを見つけるだけの仕事と思われがちですが、バグを見つけることは過程であって、最終的にゲームが正しく動作していることを確認した上で、品質や面白さを保証することが最終的な目的です。 

つまり、この工程がないと、ゲームは完成しないというくらい重要なものになります。 

QAエンジニアの仕事内容 

近年のゲーム開発は、大規模化の一途をたどっているため、先ほど説明しましたテストや開発そのものをすべて手動で行うことが困難になりつつあります。このような状況をエンジニアリングのアプローチから改善するために生まれたのが、私のようなQAエンジニアという職種です。組織によって具体的な業務内容には違いがあると思いますが、「龍が如くスタジオ」では、開発環境やQAの自動化・効率化を行うことを日々の仕事としています。

開発環境については、ビルドやデータコンバートの自動化、Redmine等のチケット管理システムのワークフローの効率化などを行っています。これらを仕事とする人を、より細分化してビルドエンジニアと呼ぶ場合もありますが、「龍が如くスタジオ」では、QAエンジニアである私が兼任したり、各ツールの担当者や他部署の協力を得るなどして、これらの自動化を行ってます。 

今回はテストの話が中心ですので、開発環境の自動化については簡単な説明にとどめていますが、詳しく知りたい方は、ソフトウェアテストシンポジウム 2016 東京(JaSST'16 Tokyo)の講演資料をご覧ください。 

「龍が如く」の高速デバッグ術~そびえ立つバグの山を踏破するための弾丸ワークフロー~(JaSST'16 Tokyo) 

(2009年~) 自動プレイテスト

ここからは、QAエンジニアの主な仕事の一つであるテストの自動化について、「龍が如く」シリーズの開発の歴史とともにご紹介したいと思います。

「龍が如くスタジオ」は、大規模なゲームを高速でリリースするために、個々やチーム全体で開発環境を積極的に自動化・効率化していこうとする組織風土がありました。このような環境だからこそ生まれたといえるものの一つが、自動プレイテストです。

PS3世代のタイトルを開発するようになったころから、オートテストという独自の自動プレイテストを開発し、運用を始めました。 開発メンバーが帰ったあとの開発環境(PCや開発機)を利用して、深夜に自動的にゲームをプレイして、エラーを検知するシステムです。  

下図のような仕組みで、最新ビルドのゲームを取得した上で自動的にゲームを起動して、QA専用のプレイヤーAI(ボットのようなもの)がゲームパッドの疑似入力を行い、実際にゲームを自動でプレイします。

 

オートテストの仕組み

f:id:sgtech:20180827092145p:plain

 ※図中の「エラー送信」は、「龍が如くスタジオ」独自のクラッシュレポート機能です。

 

ランダムにプレイヤーを移動させ、壁にぶつかり続けてコリジョン抜けを探すところから始めて、現在は、事前に用意したパス(操作手順をコマンド化したもの)に従ってゲームのメインシナリオをクリアすることもできるようになり、より広範囲のテストをオートテストで行えるようになりました。

オートテストの機能はその後も進化を続け、「龍が如くスタジオ」制作の「北斗が如く」(2018年発売)では、下図のようにメインシナリオをクリアするテストを行っていましたが、会話中は○ボタンで会話を進め、敵とバトルになった場合はバトル用のボットAIに切り替えて戦うなど、ゲーム内の状況に合わせたきめ細かい自動テスト機能を追加し、様々なバグを検出することができるようになっています。

 

オートテストの動作例(北斗が如く)

f:id:sgtech:20180827092140p:plain

 

また、上記に加えて、組み合わせが多すぎて手動でテストしきれないものをオートテストが専任で行うなど、手動テストとの協力体制ができつつあります。 

このように、自動プレイテストの取り組みは、近年のAIの台頭によって、AIに取って代わられる仕事と見られることがありますが、オートテストはあくまで手動テストの補助を目的としています。簡単に見つかるバグはできるだけAIにまかせて、手動テストでは、より複雑な条件のバグを探したり、ゲームの品質や面白さの向上に注力してほしいという思いで、日々オートテストの改良を続けています。 

(2013年~) QAエンジニアの誕生と加速するテスト環境の自動化

このように、「龍が如スタジオ」では、シリーズの開発を重ねるごとに、開発とQA環境の自動化が進んできたわけですが、開発のスピードアップやゲームの品質向上に貢献する反面、自動化した仕組みの維持が開発チームの負担となってきたため、「龍が如く 維新!」(2014年発売)の開発から、私が専属でQAエンジニアリングを担当することになりました。

専属のQAエンジニアを開発チームに置くことで、今までの自動化環境を維持しやすいように整理した上で一元管理したり、前述のオートテストの機能拡張や後述するログ分析などの新機能を実装することができるようになり、このころから、「龍が如くスタジオ」のQAエンジニアリング技術が劇的な進化を始めます。

(2015年~) テストの結果分析

テストを自動化して、QAエンジニアを専任化しましたが、それで終わりではありません。自動化のツールとしてよく使われているJenkinsでは、テスト結果の成功・失敗がわかりますが、自動テストの結果をもっと詳しく知りたいという要望が寄せられるようになりました。そこで、「龍が如く 極」(2016年発売)での試験運用を経て、ドラゴンエンジンでの開発となった「龍が如く6 命の詩。」(2016年発売)より導入したのがログ分析機能です。 

下図は、オートテスト実行中のゲーム内のVRAM(Video RAM、グラフィックスメモリ)の使用量を収集し、ヒートマップで見える化したものになります。

 

VRAMヒートマップ(北斗が如く)

エデンという街のVRAM使用率を、ヒートマップで見える化したもの。

赤くなっているところが使用率が高く、Xが100%を超えているので修正必須な地点。

f:id:sgtech:20180827092149j:plain

 

コリジョン抜けマップ(北斗が如く)

荒野という広大なマップのコリジョン抜けを見える化したもの。

f:id:sgtech:20180827092151j:plain

 

ゲームを自動でプレイしているわけですから、明確なエラー(例外やASSERT)以外の警告レベルの不具合も、通常のゲームプレイと同様に発生しますし、パフォーマンス計測も可能です。 これらをログとして収集し見える化することで、問題箇所を探す手間が省けるので、修正を正確かつ迅速に行えるようになりました。 

さらに、手動テストのプレイログも分析して、ゲームバランスの調整に使ったりと、まさにゲームの品質(面白さ)の向上にも活用できるようになりました。 以下は、手動テストやオートテストのログを分析して、ゲームバランスの調整に活用した事例です。

 

プレイヤーがゲームオーバーになった場所(龍が如く6 命の詩。)

手動テストでプレイヤーのHPが0(ゲームオーバー)になった地点を可視化して、ゲームバランスの調整に活用。

f:id:sgtech:20180827092136p:plain

 

アイテムドロップ率(北斗が如く)

敵が落とすアイテムのドロップ率を計測し、仕様通りの確率でアイテムを排出しているか、レアアイテムが本当に排出されているかをオートテストを使って計測。

f:id:sgtech:20180827092220p:plain

 

今回ご紹介したオートテストとログ分析は、ソフトウェアテストシンポジウム 2018 東京(JaSST '18 Tokyo) で講演させていただいたときの資料でより詳しく説明していますので、 ご興味がある方はご覧ください。(オープンソースを組み合わせて構築しているので、気軽に試すことができます。) 

無料で始める!「龍が如く」を面白くするための高速デバッグログ分析と自動化(JaSST'18 Tokyo)

(2018年~) テストピラミッドの考察とQAエンジニアリングの未来

自動化して結果を分析できるようになっても、QA環境を快適にする取り組みには終わりがありません。 現在は、どの業界でもAI活用がトレンドですが、今まで行ってきた自動化やログ分析を基礎として、AIを活用したさらなる自動化・効率化が期待されています。 

先週開催されたCEDEC 2018では、「次世代QAとAI 〜ゲーム開発におけるAI活用に正しく向き合うために〜」というセッションに、QAの今後の進化、AIの活用の未来というテーマで、パネリストとして参加させていただきました。今回は、CEDEC 2018で紹介したテストピラミッドについて、フォローアップしたいと思います。  

テストピラミッドとは、テストを自動化・効率化する上で、その考え方のベースによく使われています。一般的なシステムやWeb系の開発では、以下のようなテストピラミッドになることを理想としています。 

 

一般的なテストピラミッド

f:id:sgtech:20180827092217p:plain

UIテスト 最終的な製品に近いテストのことで、高コストで自動化するのが難しいテスト。
結合テスト 機能ごとに実装したものを結合して、問題がないか動作確認等を行うもの。
単体テスト ユニットテストとも呼ばれる機能ごとのテスト。一番低コスト。

 

より低コストな単体テストを増やして、自動化することで、コストを抑えつつ効率化することができるようになります。 では、ゲーム開発のテストピラミッドはどうなるかというと、 現状は以下のような状況にある場合が多いのではないでしょうか。

 

ゲーム開発のテストピラミッド(現実)

f:id:sgtech:20180827092214p:plain

手動プレイテスト 人が実際にゲームをプレイするテスト。
スモークテスト

ゲームの起動や各モードが正しい動作しているかを簡易的に調べるテスト。最新ビルドをリリースする時に最低限の動作を保証するためのテストなので、なるべく短い方がいい。(1~5分程度)

エンジン・ライブラリテスト

ライブラリやエンジンを社内開発している場合は、サンプル等が正常に動作しているかをテストする。
データテスト

モデル・テクスチャ・レベルデザインなどのデータファイルが正しくゲーム内で動作するかを個別にテスト。ゲーム内で動的に描画テストを行ったり、コンバートの時に静的チェックを行う。

 

上図では、最終的な製品に近い状態での手動テストの割合が高く、高コストなので、ピラミッドのバランスが非常に悪くなっています。 高コスト体質な上に人に依存するテストなので、昨今の人手不足によりスケールアップが困難になる恐れがあります。 

また、ゲーム開発では、データドリブンな仕組みを採用している場合が多いため、データのバグが非常に多い構造になっています。(場合によってはプログラムのバグよりも多いことがあります。) 

単体テストと言われると、ピンとこないかもしれませんが、一つ一つのデータの不具合や整合性のテストを、 最終的な製品のテストの前に検出できれば、手戻りコストを含めてどれだけの手間が減るかは想像に難くないと思います。  

「龍が如くスタジオ」では、今回ご紹介したオートテストとログ分析以外にも、データコンバート時のエラー検出の強化やスモークテストを増やすなどの改良を加えて、逆ピラミッドから以下のような正しいピラミッドになるように、日々改善を行っています。 

 

ゲーム開発のテストピラミッド(理想)

f:id:sgtech:20180827092211p:plain

 

ここまで読み進めていただいた方なら、もしかしたら理想のピラミッド図を見て、疑問に思われるかもしれません。 なぜ一番高コストであるプレイテストを自動化することから始めたのか? 

これは、「ゲームという特性上、単体テストでの結果が画像出力しかない場合が多く、画像の差分は閾値(しきいち)が安定しないので成否の判定が難しいこと」、「自動テストのエラーをエラーとして開発メンバーに受け入れてもらうこと」の二つの理由があります。

特に後者が重要で、エラーが出たらそれを修正してもらう必要がありますが、自動テストのエラーに対する信頼性が低いと、「このエラーは製品でも起きるの?」と言われて修正されないまま放置されてしまい、テスト自体の意味もなくなってしまいます。 まずは自動テストを通常のゲームに限りなく近い状態で実行することで信頼してもらい、そして自動テストのエラーは即時修正するというチーム文化を作ることが重要です。 

「龍が如くスタジオ」では、自動プレイテストをチームに受け入れてもらった上で、現在進行形でより低コストな自動テストを増やしているところです。 自動テストを一から導入することをお考えの方は、ランダムにプレイヤーが動く自動プレイテストを作ってみて、チームのメンバーにみてもらうところから始めてみてはいかがでしょうか。 

 

まとめ

このように、QAエンジニアリングは、ゲーム開発とQAにとってとても重要な技術で、 今後さらなる技術向上と成長が望まれている分野であることが、おわかりいただけたのではないかと思います。 

私は元々ゲームプログラマからキャリアをスタートしましたが、ゲームの開発やQAを開発者の立場で経験したことで、 何を自動化すればいいのか、どういったことが望まれているのかが具体的に分かるので、その経験は非常に役立っています。 そういった意味で、QAエンジニアは、ゲームプログラマやテスターの方にとって入りやすい職種だと思います。

また、QAエンジニアが開発現場にいることで、開発する側にとっても快適な環境を目指して日々改善しておりますので、ご興味がありましたら、セガで一緒に働いてみませんか? 

採用情報 | セガ企業情報サイト 

 

参考資料 

※この記事は、JaSST'18 TokyoとCEDEC 2018、セガの社内勉強会であるSDC(SEGA Developer's Conference)の講演内容をベースに作成しました。 

※本記事で使用しているゲーム画像は、すべて開発中のもので製品とは異なります。

英語版はこちら

 ©SEGA

Powered by はてなブログ