お久しぶりです。セガの阪上です。前回の記事「QAエンジニアってどんな仕事？～ゲーム開発におけるテストの世界～」を寄稿してから6年が経ちました。今回は、前回の記事以降に発表した講演内容を振り返りつつ、前回紹介したQAエンジニアという職種から、クオリティエンジニアに役割を再定義した経緯について紹介します。
また、今年のCEDEC2024の講演『「龍が如く」も「スーパーモンキーボール」も自動化！クオリティエンジニアリングチームによるマルチゲームエンジン対応で進化した「龍が如くスタジオ」のテスト自動化環境について』は楽しんでいただけたでしょうか？
マルチゲームエンジン対応となったテスト自動化環境について、説明しきれなかった内容も補足しますので、最後まで楽しんで読んでいただけたら幸いです。
目次
- 目次
- 「QAエンジニア」から「クオリティエンジニア」になった経緯
- (2018年~)開発・QAにおける自動化ワークフローの確立と、クオリティエンジニアの育成
- (2020年~)マルチプラットフォーム・多言語対応による多拠点の自動化・効率化
- (2022年~)マルチゲームエンジンに対応した自動化とクオリティエンジニアリングチームの誕生
- クオリティエンジニアのモチベーションの源泉には何があるのか？
- クオリティエンジニアの新たな挑戦
「QAエンジニア」から「クオリティエンジニア」になった経緯
まず、今回のタイトルにもあるクオリティエンジニアの説明から始めます。ゲーム業界では、他のソフトウェア業界と同様に、開発環境やQA（Quality Assurance/品質保証）環境の自動化を推進していく潮流があり、その中で、主に開発環境を自動化するビルドエンジニアと、主にQA環境を自動化するQAエンジニアに細分化が進んでいました。しかしながら、開発とQAは密接に関わっており、別々の担当者がそれぞれの視点で自動化することは、それぞれの担当範囲の間に立ちはだかる課題を解決する上での障壁となり、必ずしもプロジェクト全体の効率化につながらないということが分かってきました。そこで、開発・QAの環境の自動化・効率化を横断して行うために、クオリティエンジニアという職種を新たに定義することにしました。クオリティエンジニアの具体的な業務内容をまとめると、下記になります。
- アセットやパッケージのビルドの自動化
- QAの自動化・効率化
- 開発・QA・LQA（ローカライズQA）を含めた拠点間のデータデリバリーの自動化
- プロジェクトのワークフローに適合したチケット管理システムの構築・運用、チケット処理フローの自動化
1と2は分業でも対応ができますが、3と4については、分業だとなかなか対応ができず、そもそも問題に気付けないということにもなりかねません。次項からは、このクオリティエンジニア誕生までの軌跡を、前回のブログ投稿時（2018年8月）をスタート地点として、過去の講演を振り返りながら、ビルドとQAの両方の視点を合わせないとできないプロジェクト全体の自動化・効率化の事例として、先ほど挙げた業務内容の3と4を中心に紹介していきます。
(2018年~)開発・QAにおける自動化ワークフローの確立と、クオリティエンジニアの育成
当時QAエンジニアを名乗っていた私は、前回の記事以降に発売となった「JUDGE EYES：死神の遺言」「龍が如く７ 光と闇の行方」のプロジェクトを通して、今までの自動化技術の集大成として、自動化ワークフローの確立に取り掛かりました。その結果生まれたのが「全自動バグ取りシステム」です。
このシステムを構築することで、パッケージ作成などのビルドの自動化だけではなく、ゲームでは難しいとされてきたテスト自動化の手法についても確立することができました。
「全自動バグ取りシステム」の詳細は、CEDEC2020の講演資料をご覧ください。
そして、この自動化ワークフローを支えるために、テスト自動化チームを結成しました。これは、クオリティエンジニアによって実装されたテスト自動化フレームワークを使いこなして、自動テストの作成・運用を行うチームです。専任のクオリティエンジニア以外に、新人などの若手のプログラマーも参加します。「龍が如くスタジオ」では、2017年ごろから、新人研修の一環(※)として、テスト自動化チームに入って、自動テストの作成や、デバッグの手法を学びます。これらの経験は、その後の自身で実装したゲームの自動テストを自ら作成するなど、ゲーム開発に生かされますし、クオリティエンジニアの育成にもつながる取り組みになります。（※新人研修では、もちろんゲーム制作についても学びます）
この若手育成の取り組みやテスト自動化フレームワークの詳細については、下記の講演資料・講演動画で詳しく説明しています。
この取り組みが功を奏して、クオリティエンジニアも徐々に増えていきました。次項からは、私一人では成し遂げられなかったことばかりですので、一人称も「私」から「私たち」に変更します。（やったね！）
(2020年~)マルチプラットフォーム・多言語対応による多拠点の自動化・効率化
「LOST JUDGMENT：裁かれざる記憶」の開発のころから、マルチプラットフォームで世界同時発売を前提としたプロジェクトが増えてきました。これは、各プラットフォームで動かせるようにして、各言語に翻訳をすればよいというものではありません。ここでは、これらの対応における問題点を開発環境やテストに絞った上で、私たちがどのように解決したかを説明します。
マルチプラットフォーム対応においては、主にアセットビルドやパッケージの作成が各プラットフォーム分必要になってくるという点が挙げられます。単に Jenkins などのCIツール上に接続するPCを増やして並列実行させればよいだけではないかと思う方もいると思いますが、それらがエラーになった時などのメンテナンスコストはプラットフォームの数に比例して増えていきますし、最近の大規模タイトルだと、1プラットフォーム当たりのパッケージのサイズが50GBから100GB程度に拡大し、さらにこのパッケージを高速に配布しなければならないため、そのデリバリー時間（アップロード、ダウンロード、インストール、動作確認を含めた時間）についても、意識して対応する必要があります。また、多言語対応については、開発・QA・翻訳・LQAを行うメンバーの拠点が国をまたいでいることが多く、時差や言語の壁により、拠点間のコミュニケーションに時間やコストがかかることも問題になります。そして、特定のプラットフォームや言語の不具合も同時に増えていきます。
私たちは、この複数の問題を自動化のアイデアで解決することにしました。まず、マルチプラットフォームのパッケージの作成と提出（アップロード）を自動化しましたが、これだけでは足りませんでした。なぜかというと、プラットフォームが増えて、対応言語も増えた結果、それぞれの環境での動作確認を開発側でカバーすることができず、特定のプラットフォームや特定の言語でだけ、ゲームの起動すらできない、という不具合が頻発しました。初めは手動で行っていましたが、複数名が動作確認に時間を取られることになるため、自動化することにしました。そこで導入したのが、全プラットフォームで実施する言語切り替えテストの自動化です。最新のパッケージが作成されると、各プラットフォームの開発機に自動でインストールして、ゲームを起動し、すべての言語に切り替えて正常に動作するかを確認します。それと同時に、各プラットフォームで可能な限りの言語に切り替えて、メインストーリーをクリアする自動テストも動かすことで、日々更新されるパッケージの動作確認を自動化することができました。ここまでがCEDEC2022での講演内容になります。
これですべて解決・・・と言いたいところだったのですが、実際にはここまでやっても足りないことがありました。
残っていた問題は、拠点間の時差を含めたデリバリー時間の肥大化です。手動テストを行っているQAチームが、パッケージの数とサイズの肥大化により、手動でダウンロードしてインストールを行うのにとても時間がかかっているという相談を受けました。詳しく調査してみたところ、開発側が想定しているよりも時間がかかっていることがわかりました。これは、古いパッケージでテストが行われるため、すでに最新パッケージで修正しているバグの報告が届くことになり、開発チームにも悪影響があります。
さらに詳しく調査したところ、自動化ワークフローにも問題がありました。自動テストは、当たり前ですが自動で実行され、自動で結果も集計されるのですが、その結果をテスト自動化チーム側で分析してパッケージの安定性を各拠点（開発・QA・翻訳・LQA）に連絡するという作業は手動でした。これは時間にすると2時間程度でしたが、手動テストの部隊を2時間待たせることになりますし、翻訳やLQAを行う海外拠点だと、時差の関係で、タイミングが悪いと結果の伝達に丸1日かかるなど、テスト自動化チームがボトルネックになっていました。図にまとめると下記のようなワークフロー上の問題がありました。
問題点を整理すると、まず、デリバリーの自動化は、アップロードだけでなく、ダウンロードやインストールにも注視する必要があるということです。わかってしまえば当たり前のことですが、開発チームとしては、パッケージをリリースすればOKという認識になりがちですし、QAチーム側も仕方ないものとして、なかなか開発チームに相談できないケースが多いのではないかと思います。クオリティエンジニアが普段から開発チームとQAチームを横断して自動化・効率化を行っているのは、こういった拠点間・チーム間の課題を見つけるためでもあります。これは、自動テストに協力しているQA部門のメンバーがすでに使っていたパッケージの自動ダウンロード・インストールツールをQA拠点全体に展開してもらうことで解決できました。
1つ目の問題点が解決したので、もう1つのテスト結果の伝達によりテスト自動化チームがボトルネックになっている問題に取り掛かりました。これは、プロジェクトの自動化・効率化が目的のチームなのに、とても皮肉なことですね。しかし、私たちは悲観することなく、この問題の原因調査を行いました。
そもそもなぜテスト自動化チームが自動テストの結果を分析して、それを各拠点に伝える作業をしていて、時間もかかっていたのでしょうか？原因は2点ありました。
１つ目は、自動テストのカバー範囲が拡大した結果、テスト結果が膨大になって、可視化したグラフを一通り確認するだけでも時間がかかっていることが分かりました。これは、可視化を整理することで解決できそうです。
2つ目は、各拠点で安定しているパッケージとみなす条件が異なり、常にその条件が変化するという点です。開発チームは致命的ですぐ修正すべき不具合が何かという情報を必要としていますが、これは自動化ワークフローによって自動で集計されるため、時間をそれほど要しません。しかし、QA・LQAのチームは手動でその日にテストしようとしているテストケースが最新のパッケージで動作するか、バグがあるにしても、最低限起動するかどうかなどの情報を必要としており、常にテストケースの実施範囲は変化するため、日々の自動テストの結果の細かい箇所を調査して伝える必要がありました。完全にすべてが安定したパッケージを毎日作成できれば良いのですが、開発中はどうしても新規に実装することで新しい不具合が出てしまうため、どこが安定していて、どこに致命的な不具合があるかを見極めて伝達する必要があります。極端な例ですが、QAの場合、ボス敵のテストに集中している時は、ザコ敵と戦えないような致命的な不具合があっても、その日のテスト作業に影響は出ません。また、LQAの場合は、フランス語のテストに集中している時は、必ずしも全言語で安定している必要はありません。このように、テスト自動化チーム側で各拠点の進捗を把握して、その上で必要な自動テストの結果をまとめて伝えていたので、時間がかかっていたわけです。
私たちは、この2つの問題を解決するために、自動テストの結果の伝達方法についても自動化しました。それが下記の図になります。
まず、可視化の一番重要なものを１ページにまとめたサマリーを作って、簡単に最新パッケージの安定性を確認できるようにしました。そのうえで、個々の拠点が必要としている分析結果を別のページにまとめて、その確認方法も各拠点に説明して、最新パッケージを使ってテストするかどうかを拠点ごとに各自で判断してもらうことにしました。さらに、夜間のQA環境を利用して、開発チームだけでなく、手動のQAチームにも自動テスト実行に協力してもらうことにしました。自動テストを実行する過程で最新のパッケージが自動でインストールされていますので、手動のQAチームのメンバーは、始業して自動テストの結果を確認したら、すぐに最新のパッケージに切り替えて手動テストを実施することができるようになりました。これらの自動化とワークフローの変更により、最大7時間程度かかっていたのが、11分に大幅に短縮することができました。
また、前項で誕生したテスト自動化チームは、このタイミングでQA部門のメンバーが加入することになりました。開発とQAが協力したテスト自動化チームを結成することで、QA部門側からも、開発の中を含めたプロジェクト全体を横断する視点が生まれました。これは、QAテスターの新しいキャリアパスを生むことにつながりました。QAテスターだったメンバーが、テスト自動化エンジニアになり、さらにクオリティエンジニアに成長して、開発側の環境もサポートするようになったケースが実際に生まれています。今後は、QA部門での新しいキャリアの選択肢となっていくことに期待しています。
(2022年~)マルチゲームエンジンに対応した自動化とクオリティエンジニアリングチームの誕生
前項で述べた事例のように、プロジェクト全体を横断して自動化・効率化する重要性の高まりに合わせて、クオリティエンジニアの需要も増えていきました。
今までの若手育成の取り組みにより、クオリティエンジニアを各プロジェクトに1名ずつアサインできるようになってきていたため、まさに満を持したタイミングになりますが、各クオリティエンジニアは、日々の業務を行えるスキルを身に着けているものの、そのスキルレベルにはばらつきがあり、異なるゲームエンジンの情報や、お互いの技術・知見を共有する場が必要でした。また、適切なワークバランスの確保のため、バックアップ体制も整えておく必要がありました。そこで、クオリティエンジニアについても、自動テストの作成・運用を行うテスト自動化チームのように、チームを結成することにしました。クオリティエンジニアリングチームの誕生です。
出来たばかりのクオリティエンジニアリングチームには、マルチゲームエンジンに対応した自動化環境の整備という新たな課題がありました。内製エンジンのドラゴンエンジン以外に、Unreal Engine、Unityのテスト自動化環境を用意したのが、下記のCEDEC2024の講演資料になります。ドラゴンエンジンのテスト自動化のフレームワークを各ゲームエンジンに適した形で移植することで、共通のテスト自動化のフレームワークとして実装・運用し、それぞれのゲームエンジンを使用したタイトルで、開発スピードやゲームの品質の向上に貢献することができました。
ここでは、講演で詳細に説明しきれなかった点を補足したいと思います。各ゲームエンジンの開発では、チケット管理システムの運用にも影響がありました。チケット管理システムでは、バグやタスクを管理していますが、そのステータスの遷移であるチケットのワークフローは、各プロジェクトのワークフローに沿ったものが必要です。ゲームエンジンの特性はこのプロジェクトのワークフローに影響があるため、チケット管理システムにも影響が出てくることになります。ドラゴンエンジンには、アセットやパッケージのビルド後にチケットを自動遷移する「コンバート予約」という仕組みがあるのですが、この自動遷移するステータスを見直す必要がありました。
ドラゴンエンジンの場合は、各アセットを中間データで管理しており、この中間データをコンバートすることでゲームのパッケージに反映される仕組みです。このコンバートにより、共通の中間データから各プラットフォームに最適なデータに変換する作業が自動化されるだけでなく、アセット単体のバリデーションテストを行うことで、データのバグの混入を未然に防ぐというメリットもあります。しかし、自分が作成・修正したアセットが、いつゲームに反映されるかを知る方法が複雑で、バグの場合は特に報告者がどのパッケージで修正を確認すればいいのか迷ってしまう状態になります。この問題を解決するために導入したのがコンバート予約という仕組みです。ドラゴンエンジンでは、「コンバート待ち」「パッケージ更新待ち」というステータスを用意して、各コンバートやパッケージのビルドが完了すると、チケットのステータスを、最新パッケージで修正確認が可能な「確認待ち」のステータスに自動遷移します。このタイミングで、修正が反映されたタイミングが分かるのと同時に、どのビルド番号のパッケージに反映されたかを確認することができるため、手戻りや待ち時間を削減することができます。
これがUnreal EngineやUnityの場合は、アセットをコミットすることで、直接Editor上に反映され、即時確認ができるという点で異なっていました。さらにUnreal Engineでは、プログラム（C++）の修正を加えた場合にEditor用のDLLを更新する必要があります。大枠のチケットワークフローは統一しつつ、これらのゲームエンジンの違いに寄り添ったのが下記の図です。
Unreal Engineでは「DLL更新待ち」というステータスを追加して、Editorへの反映も通知できるようにしました。そのうえで、ゲームエンジンごとにステータスの意味の定義を見直して、UnityやUnreal Engineでは、「パッケージ更新待ち」の時点で「Editor上で修正を確認可能」という意味に再定義しました。この柔軟な取り組みによって、基本的なチケットワークフローを統一しつつ、それぞれのゲームエンジンに最適かつ最速なチケットワークフローを構築することができました。
また、ここまで説明してきたテスト自動化の様々な取り組みは、クオリティエンジニアの頑張りだけではなく、開発チームの協力も欠かせません。例えば、プログラマーに積極的にアサーションを組み込んでもらうことで、適切なタイミングでエラーを検知することが可能になります。プロジェクトのメンバーに自動化の仕組みを理解してもらい、最大限活用してもらうことで初めて成果を出すことができるのです。
私たちは、様々な自動化の環境を実装・導入・運用するだけでなく、それらを普及させることも活動内容の一つです。そのためには、プロジェクトにアサインされて、より深くプロジェクトの状況を把握する必要があります。これもプロジェクトに1名ずつクオリティエンジニアが必要な理由の一つになります。
クオリティエンジニアのモチベーションの源泉には何があるのか？
ここまで読み進めていただいた方の中には、なぜここまでやるのか、どこからそのモチベーションが生まれてくるのか、疑問に思われる方もいらっしゃるかもしれません。私たちクオリティエンジニアは、ゲームを開発する人、ゲームをテストする人、ゲームをローカライズする人、それぞれと同様に、そして彼らと共にゲームを作っているという認識で取り組んでいます。より面白く、より高品質なゲームを、より早くユーザーの方たちに届けたいという思いも同じです。ただ、その目的を達成するための手段や役割が異なるだけなのです。
私たちクオリティエンジニアは、開発者を最大限リスペクトして、彼らがゲームを面白くすることだけに集中できる環境作りを目指しています。自動化・効率化を行う際は、ルールを極力増やさずに、自動化・効率化したワークフローを自然に受け入れてもらえるように気をつけながら、「ゲームを面白くすること以外は、私たちが全部自動化するんだ！」という気概で取り組んでいます。
クオリティエンジニアの新たな挑戦
最後に、再び一人称を阪上のみの「私」に戻します。このような経緯で、クオリティエンジニアとクオリティエンジニアリングチームが誕生したわけですが、これはあくまで「龍が如くスタジオ」の中だけの話でした。この取り組みは、高品質なゲームをより早くユーザーに届けることに一丸となる「龍が如くスタジオ」の組織文化があったからこそ生まれたと言えますが、 同様の体制を構築することは、どのチーム・スタジオ・会社でも実現できるのではないかと私は考えました。そこで、私個人は、セガのグループ内のすべてのゲームプロジェクトを自動化・効率化するため、グループ全体の技術サポートを行う部署に異動することにしました。まだ始めたばかりの取り組みですが、共通化や汎用化を進めつつも、各プロジェクトに寄り添った形で自動化・効率化を進めるという基本な考え方は同じです。この新たなチャレンジの成果の発表は、またの機会を楽しみにしていてもらえればと思います。
しかしながら、セガのグループ全体の自動化・効率化となると、圧倒的に人手が足りません。ここまで読んでいただいた方の中には、クオリティエンジニアに興味を持っていただけた方もいるのではないかと思います。セガのグループ内の様々なゲームプロジェクトを自動化・効率化するクオリティエンジニアは絶賛募集中ですので、ぜひご検討ください。
https://hrmos.co/pages/sega/jobs/174
また、このような自動化・効率化が行われている「龍が如くスタジオ」の環境で働いてみたいという方も募集していますので、こちらもよろしくお願いします。
