【セッションレポート】 モバイルゲームで自動テストが効果を発揮するまで ~自動テストを「運用」するまでの組織のアプローチ~ #CEDEC2025

登壇者: 住田 直樹 (株式会社QualiArts)、田中 広海 (株式会社QualiArts)
日時: 2025 年 7 月 24 日 (木) 11:10 ～ 12:10
会場: CEDEC2025 第 5 会場
カテゴリ: PRD (プロダクション) | レギュラーセッション | 公募

概要

モバイルゲーム開発の現場では、タイトルの規模拡大やコンテンツの継続的な追加に伴い、検証工程がますます複雑になっています。人手による確認作業だけでは対応しきれない場面も増え、開発の足かせになりかねない状況が生まれています。こうした中で、自動テストの導入が一つの有効な選択肢として注目されるようになりました。

一方で、自動テストは単にツールを導入すれば効果が出るというものではありません。実装や保守には相応の工数がかかり、特に運用フェーズでは技術的な工夫と組織的な体制が欠かせません。理想とされる自動化と、現場の現実のあいだには大きなギャップがあるのが実情です。

本セッションでは、株式会社 QualiArts におけるモバイルゲームの自動テスト導入と運用の事例が紹介されました。単発的な取り組みに終わらず、実際に現場で回る仕組みとして定着させるためにどのような工夫をしてきたのか。Airtest や Anjin などの技術的選定から、組織としての取り組みまで、現実的な観点に基づいた知見が共有されました。

導入経緯とツール選定

QualiArts では、モバイルゲームの自動テストに対する取り組みを段階的に進めてきました。初期段階では、開発チームと QA チームのあいだで確認作業の効率化が課題となっており、手動での検証だけではスピードと安定性の両立が難しい状況に直面していました。特に、ゲームのチュートリアル部分はユーザー体験の入り口となる重要な箇所であり、頻繁な変更が入ることからテスト対象としても優先順位が高く、ここから自動化を試みる方針が採られました。

最初に導入されたのは Airtest でした。Airtest は UI 操作を画像ベースで記録し、簡単にスクリプトを作成できる点が利点です。特に、Poco というレイヤを通じて Unity の UI 要素を直接操作できるため、導入のハードルが低く、早期に成果を得やすい構成となっていました。Airtest の導入により、一連のチュートリアル動作を通じた回帰テストが定期的に実行できるようになり、デグレードの早期発見に一定の効果がありました。

しかし、運用を続ける中で、より高度な制御や複雑なシナリオ構成への対応が求められるようになりました。これに対応するため、後に Anjin の導入が検討されます。Anjin は Unity 上で動作する自動テストフレームワークで、コードベースで細かい挙動を指定できる点が特徴です。Airtest に比べて初期の学習コストはあるものの、継続的なメンテナンスや高度なユースケースへの対応という観点から、Anjin はより長期的な自動テスト運用に適した選択肢とされました。

こうして、QualiArts では Airtest と Anjin の特性を活かしながら、段階的に自動テストの導入と拡張を進めていきました。特定のツールに依存するのではなく、プロジェクトのフェーズや目的に応じて適切な技術を選択する姿勢が印象的でした。

継続的な運用を支える仕組み

自動テストは導入して終わりではありません。長期的に活用し、実際の開発サイクルの中で機能させていくためには、運用の安定性とチーム全体への定着が欠かせません。QualiArts ではこの課題に対し、さまざまな工夫を取り入れながら、自動テストの継続的な運用体制を構築していきました。

まず、物理デバイスの管理には STF (Smartphone Test Farm) を活用しています。これにより、社内の開発用スマートフォンをネットワーク経由で一元管理し、Airtest などのテスト実行時に安定した環境を提供できるようにしています。ただし、実運用ではテスト対象の種類や構成が変更されるたびに調整が必要であり、テスト実行のたびに実行環境を安定させることの難しさも語られていました。特に、新しいデバイスや OS バージョンへの即時対応が求められるケースでは、既存のファーム構成がボトルネックになることもあるようです。

テスト結果の可視化と共有にも工夫が施されています。具体的には、テストが実行されると Slack へ通知が飛ぶようになっており、誰でもテストの成否やログを確認できる仕組みが整えられています。また、実行結果のログやスクリーンショットは GitHub Pages 上に自動で公開され、プロジェクトメンバーが必要に応じて参照できるようになっています。こうした取り組みは、テスト結果を開発チーム全体で「見る」 「使う」文化を育てる上でも重要な意味を持っています。

組織的な課題と今後の展望

組織内で自動テストを活用する文化を築いていくうえでは、さまざまな課題にも直面しています。中でも大きかったのは、「テスト結果を見てもらえないこと」でした。せっかくテストを整備しても、結果が確認されなければ改善にはつながりません。また、テストが煩雑であればあるほど、開発者が自動テストそのものに対してネガティブな印象を持ってしまう可能性もあります。

これに対し、開発推進室では、各プロジェクトの担当者に対して定期的にユースケースのヒアリングを行い、自動テストの設計や導入方針を提案するなど、能動的な関わり方を意識しているとのことです。プロジェクト側が「必要なもの」として自然に受け入れられるよう、小さな成果を積み重ねながら信頼を築いていくスタンスが取られています。

また、自動テストの品質そのものを維持するためには、「テスタビリティ」を意識した設計が求められます。実装された機能に対してテストがしづらいと感じた場合には、開発チームにフィードバックし、改善の余地がある点について積極的に提案するようにしています。こうしたやり取りを通じて、自然と「テストしやすい設計」が意識されるようになることが、組織全体の品質向上にもつながっています。

今後も、ゲーム開発の規模がさらに大きくなり、プロジェクトの複雑さが増すことが予想されます。その中で、自動テストの役割はますます重要になる一方で、運用の難しさも増していくと考えられます。だからこそ、ツールの導入そのものを目的化せず、あくまで「品質を高めること」 「検証作業の負担を軽減すること」という本来の目的を見失わないようにすることが、長期的な成功につながるという姿勢が印象的でした。

まとめ

モバイルゲームにおける自動テストは、導入すればすぐに効果が出るものではなく、継続的な運用と組織的な定着があってはじめて力を発揮します。QualiArts の事例では、Airtest や Anjin といったツールを使い分けながら、Slack 通知や GitHub Pages による可視化、STF を活用した実行環境の整備など、運用面での工夫が積み重ねられていました。

また、開発・QA チーム間の連携やテスタビリティ改善へのフィードバックなど、組織としての取り組みにも力が注がれていました。自動テストを単なる自動化の手段ではなく、品質向上とチーム全体の開発効率を支える仕組みとして位置づける姿勢は、今後のゲーム開発においても有効なヒントになると感じられる内容でした。