WORK LIFE
STORY
スクウェア・エニックスで「働く」ストーリー
こんにちは、スクウェア・エニックス 人事部 採用担当 長澤です。
CEDEC2020で行われたセッションで、『FINAL FANTASY VII REMAKE』で導入された自動QAシステムのデータ構造と実行メカニズムについて発表されました。
本インタビューでは、その自動QAシステムの導入について、品質管理部と開発部門の立場から、座談会を通じて検証をしています。
自動QAが『FINAL FANTASY VII REMAKE』のプロジェクトにおいて実際どの程度有効だったのか、導入における失敗談や今後の課題など、社内でしか聞けない本音もお伺いしました。
このセッションについてはこちら。
*QA：Quality Assuranceの略
※こちらは2020年秋に行われた対談となります。
座談会出席者プロフィール
(写真：左端)北出 智 第一開発事業本部 ディビジョン1
プログラマーとして、「小さな王様と約束の国 ファイナルファンタジー・クリスタルクロニクル」、「FINAL FANTASY XV」「FFVII REMAKE」等の開発に関わる。著書：「Squirrelゲームプログラミング 組み込みスクリプト言語による実践テクニック」
(写真：左から2番目)波能 智人 第一開発事業本部 ディビジョン1
KH HD2.8でAIシステム、KHⅢ、FFⅦ REMAKEでシステムプログラムを担当。KHⅢでの自動QAの知見からFFⅦ REMAKEで自動QAの開発をサポート。
(写真：左から3番目)小池 いかる 品質管理部
「KINGDOM HEARTS III」「FINAL FANTASY VII REMAKE」のQAを担当100名を超えるテスター管理及び、開発/プロジェクトと発売に向けたスケジュール調整に携わる。
(写真：左から4番目)グラヴォ ファビアン 品質管理部
2011年よりAIリサーチャーとして入社。前職ではロボットの人工知能や自動走行の業務に携わる。「FINAL FANTASY XIV」と「FINAL FANTASY XV」でナビゲーション・メッシュを担当する。フランス出身。
(写真：左から5番目) 太田 健一郎 品質管理部
前職で業務システムやWebシステムの自動化などを経験し、2年前にスクウェア・エニックスに入社。コンソールゲームの自動QAに携わる。
まず初めに自動ＱAを開発・導入した今回の取り組みを通して、
品質管理部が目指したことと、開発が目指したことを教えてください。
ファビアンさん（品質管理部、以下品管）：このプロジェクトはQAの効率化を図るために研究を始めたのが始まりでした。色々な技術の応用を検討し、例えば画像から抽出したデータを機械学習させることなども考えましたが、そういったやり方を実際に運用レベルにまで持って行くのはまだ先になると判断したので、これまでの研究成果を『FINAL FANTASY VII REMAKE』向けにカスタマイズしたプログラムを作り運用することにしました。
そこで、AI Unit内で特別のチームを組み、私をリーダーとして、レアンドロさんがコアロジックと全体設計、並木さんが各種BOTとアナライザー組込、太田さんがQAシステムのインフラ構築とバグ分析を担当しました。ネットワーク全般に関しては、オンラインユニットの重国さんのお世話になりました。
北出さん（開発）：開発としては、確か2019年の4月か5月くらいにデモを見せていただき、何を自動QAのメインターゲットとしてやるかを検討するミーティングをしたのが始まりでした。テクノロジー推進部からコリジョンチェックやバトルチェックなどを提案いただきましたが、開発からは通しプレイが一番の希望でした。
波能さん（開発）：実際にはゲーム自体が開発中のため安定していない状態だったこともあり、まずは一番安定していた最初の章に注力していただいて、自動QAシステムがより安定するように開発していただきました。
時間的にも余裕がなかったため、進捗的に進んでいる所から実装を進めていただき、最後に自動QAシステム自体がある程度完成に近づいた時点で、開発として一番バグを検出してほしい章に自動QAシステムを入れていただくという流れでした。
太田さん（品管）：自動QA技術については、これまでも研究の段階やモバイルベースでは成果が出ていましたが、「コンソールゲームの各プロジェクトで使え、コスト削減の成果をしっかり出せる、QAさんや開発の方が使いやすいツール」にすることが今の我々の目標です。まだQAさんが簡単に使えるレベルには到達していないので、それに向けて現在も開発を継続しています。
なるほど、自動QAツールはまだまだ進化中のものなんですね。
太田さん（品管）：そうです。検出できるバグについては後ほどお話しますが、今回一番QAさんにとって厳しかった所は2点あります。ひとつはバグらしきものが出ても、それが本当にバグなのかを、このツールやゲームの内部のことをある程度分かっていないと検証できないことです。もうひとつは、ゲーム側の変更が大きい場合、変更点のみになりますが、テストスクリプトを取り直しする必要があることです。
取り直しをする時にその部分だけ取って組み合わせられるツールはありますが、それもまたデータ構造に対する理解と判断力が求められる場合があるので、やはりプログラミングやツール内部の知識が必要になってしまいます。ですからAdobeのツールのように「こことここを組み合わせれば互換性がある」という設計にできれば、QAさんの誰もが使えるようになると思います。
CEDECで講演された「"FINAL FANTASY VII REMAKE"における自動QAシステムの構築と運用」の内容について簡単に教えてください。
太田さん（品管）：ゲームの開発を進めているとバランス調整や仕様の変更などでゲーム側が変わっていったり、カットシーンやバトルの順番が記録時と再生時で入れ替わったりすることもあります。そのような場合にも対応できるQAの仕組みをどのような形で作ったかという説明とレイヤーについての解説をセッションで行いました。
プラットフォームのレイヤーとゲーム独自のレイヤーを、サーバとクライアントに分ける形にすることで、自動QAシステムは『FINAL FANTASY VII REMAKE』向けには作っているものの、コアの部分はタイトルに依存しない汎用的な作りになっています。
CEDEC講演時に公開された、自動QA作動中の様子資料内の動画
実際にどれくらいの期間やコストで、どの程度バグを発見できたのでしょうか？
太田さん（品管）：最終的に目指していたのは、色々な種類のバグを検出できるシステムを作ることでしたが、比較的高い頻度で出てしまう誤検知との戦いでもあったので『FINAL FANTASY VII REMAKE』ではバグ検知の領域をかなり絞りました。
チーム内では自動QAで常に並列実行していましたが、開発チームとQAの方に自動連絡する仕組みを実行させるのは、3並列ともクラッシュバグで落ちた場合に限定していました。それ以外で出てきたものについては、自動QA担当の人が分析をして、再現スクリプトと再現動画を出し、『FINAL FANTASY VII REMAKE』のプログラマーの方に連絡をするというフローで進めました。
今年9月以降はクラッシュバグ以外のバグも色々な情報を使って自動検出して分類して報告できるバグクラフィケーションというシステムの開発に注力しています。開発側にメールが届いた時点でデバッグに必要な情報がそろっている自動報告ができることを目指していますが、そこまでは『FINAL FANTASY VII REMAKE』の時はできていなかったのが現実です。
ファビアンさん（品管）：数字について補足しますと、実行されたジョブは1日あたり200くらいでした。今回は分割された3つの自動テストプレイを並列的に行ったので1日あたり最大600くらいです。
太田さん（品管）：追加開発したものとして、発生頻度の低いレアバグを検知するためにバグが出るまで無限にリプレイする機能もあります。例えば260回中2回の発生頻度だとしても、100万人のユーザーのうち8,000人前後がそのバグに遭遇する可能性があります。無限リプレイでバグが出たら、その画面でデバッグできる形で止まるようにして実際運用したところ、開始から4日後に検知できるものが出てきました。つまりその場合は24時間4日回してようやくバグが発見できたということになります。
自動QA開発の際に、品管や開発へのヒアリングをもとに追加した機能や修正したところはありましたか？
太田さん（品管）：初動は小池さん（品質管理部）にUIについての改善点を伺いながら進めましたが、中盤くらいから波能さん（開発）から具体的に、「こういうことができたらいい」とか「これは困る」といった具体的なお話を伺って、それをベースに機能として作り込んでいきました。
例えばメモリ破壊を検出するアドレスサニタイザーのエラー調査に対応するものや、ギリギリで修正をかけると自分の手元では動くけど、いざパッケージにしたら壊れてしまった場合、ビルドを追いかけることでパッケージができていなくても新しいコミットに対してテストする仕組みも作りました。QAさんが仕事をする以前にそもそもスタートできない、あるいは特定の章が通しプレイできない状態だったというお話は、実際にQAを回している人から出てくることなので、そういった要望に応じて作っていきました。
ファビアンさん（品管）：今回は『FINAL FANTASY VII REMAKE』のための通しプレイのシステムを作りましたが、コリジョンチェックやマップを作るシステムも含まれているので、そこから他のバグを探すなど、できることを増やしていくことはできると思います。
太田さん（品管）：マスターアップ後にもずっと章の追加や開発は続けていました。例えば1章から18章までの通しプレイも今はできている形です。それをさらにバージョンアップさせたのが3周回しという自動リプレイのシステムもあります。
実際に自動QAを使ってみて、品質管理部として良かった点と悪かった点を教えてください。
小池さん（品管）：今回は品質管理部として具体的な要望を出しながら開発を進めていただきました。ゲームを作っている最中に品質管理が最初に求めるのは安定化です。
第一段階として、実装が終わっているはずの所が本当に壊れていないかを見てもらうために通しプレイをやってもらう。後はマスターアップ前の確認ですね。ユーザーさんが触って問題ないかを検証するためにプレイしてもらったり、電源を切らずに何周やっても変な問題が起きないかの確認をしていただこうと思っていました。
今回良かった所はQAの現場への負担がなかったことです。『KINGDOM HEARTS III』の開発時は、どこでどう自動プレイを始めるかを判断しながらセットして、クラッシュしたらそのエラーファイルを回収して、開発の人に渡して調べてもらって...ということを自分たちでやりましたが、今回はそのような作業負担がなかったことが本当に良かったです。
悪かった所は、ゲームを作っている最中は色々な箇所が壊れてしまうこともあり、テクノロジー推進部で作っていただいた自動化の運用もうまくいかないことがありました。QAとしては6割くらいの達成度かなという所ですが、今回『FINAL FANTASY VII REMAKE』が終わって通しプレイなど色々できるようになったというお話なので、次のタイトルで有効活用をしていただければ良い成果が出るのかなと思っています。
今回誤検知など自動QA自体のバグが厳しいところだったとのことですが、振り返ってみて不具合判定の難しさの原因はどういうところにあったと思いますか？
小池さん（品管）：それについては、主にゲーム側の開発の進み具合や各部署のスケジュールに起因することだったと思います。QA側が通しプレイをできるようにしてほしいというお願いをしたとしても、ゲーム側がそもそも安定していないとその作業も進みません。
ファビアンさん（品管）：それに問題が生じた時にゲーム側の問題か自動QAシステムの問題かの判断も難しかったですね。
太田さん（品管）：そうですね。最初から最後まで通しでやると、どうしても不具合が起きやすいので、今回新たに通しプレイが可能になったというのは、3つに分割して3分の1通しプレイみたいな形で、それを後でつなげるというようにしています。
では開発の方はいかがでしたでしょうか？良かった点と悪かった点を教えてください。
北出さん（開発）：最初は開発側が安定しないという問題もありましたが、自動QAシステムの誤検出によって正しくない情報がメールで送られてくることで開発側の時間と労力のロスにつながってしまうこともありました。届いた情報からバグの原因について開発で調べていくのですが、初めの頃は、ゲーム側の問題ではなく自動QA側の問題だったことがしばしばありました。
一方、自動QAシステムで回数をたくさんこなしてもらえたことで珍しいバグを発見してもらえたことと、深夜QAが稼働していないタイミングでバグを発見できたことは良かったと思います。ただ、速さという点では、部内QAさんがすぐにプログラムを取得して、新しいビルドを手元で作って実行することを繰り返しているので、昼間はそういった方が先にバグを発見してしまいます。それはそれでいいのですが、現時点では昼間は人間の方が速度も精度も良いという結果になっています。大規模プロジェクトならではかもしれないですけど、そういった面はありました。
最初設定していた目標をどの程度達成できたと思いますか？
北出さん（開発）：通しプレイに関しては当初全チャプターで行う予定でしたが、途中までしかできなかったのは残念でした。一方で、レアケースのバグなどを発見できたのは自動QAならではなので、そういった部分は達成できたと思います。
今後はソフトウェアとして使いやすいパッケージになっていけば導入しやすくなると思います。もともと大きなプロジェクトであれば、多少なりとも自動テストのようなものをプログラマーが作ります。自動QAのパッケージがあれば、そういうものを作らなくても、少なくとも簡単に起動テストくらいは深夜にできますし、繰り返しプレイも簡単にできるようになると思います。
波能さん（開発）：中小規模のプロジェクトのように部内にQAを置くことは難しいようなプロジェクトこそ、自動QAが望まれてはいると思うので、使い勝手が良いものが求められると思います。Unreal Engineに特化した部分が汎用化されていけば、色々なプロジェクトで使われていくのではないでしょうか。そういう意味でも、『FINAL FANTASY VII REMAKE』のようなプロジェクトで、ある程度の通しプレイを実行できたことは今後の土台となる成果になったと思います。
今後、他のプロジェクトなどでこの技術を導入する場合、
どういうものであればコストの削減やバグ発見の効果が得やすいのでしょうか？
ファビアンさん（品管）：まだ現在のリソースでは他のタイトルへの運用は少しやりにくいと思いますが、基本的には今回作ったものがUnreal Engineで動いているのでUnreal Engineで作っているゲームなら比較的楽に使えるようにできると思います。今の時点での達成点は、新しいシステムを作って実際に運用しバグを見つけることができると証明できたことです。これをベースに同じ方針で開発をすることで今後改善ができるはずです。
ただ、今回は開発側のリクエストに応じることに注力していたので、QA側での利便性の向上は十分にできなかったという感触はあります。ですから今度は本当にQAで実用的な価値があるものを作りたいと思います。
太田さん（品管）：そうですね。QAさんにとって実際に役立つツールにするために手始めにするべきことは、例えば再現性の難しいバグが出て来たときにそれを自動QAのツールで一度記録して、夜間にぐるぐる回してどれだけ失敗したかの再現性を検出したものを、次の日バグチケットに「これだけの回数再現しました」と補足情報として付け加えることができるようにすることだと思います。夜間もそうですし、昼間作業している横で動かしておくなど。まずはそのレベルで使っていただけるところを目指すのが現実的かなと思います。
数年前までの構想の段階ではAIを活用した自動QAシステムは、デジタルエンターテイメント業界で年々巨大化するコンシューマーゲームの開発コストを劇的に軽減させる福音のように思われていた節がありました。しかし、今回具体的な実装段階に入ったことで、可能性とともにいくつものシビアな課題が見えてきたことも、ここまで読んでいただいた方には理解いただけたかと思います。
課題はありますが、それらを一つひとつ解決することで、より良いゲーム開発環境というゴールへと向かう道筋をつないでいくことができ、それこそがスクエニの、ひいてはデジタルゲームの歴史の中で新しい技術を切り開く醍醐味なのかもしれませんね。
