『龍が如く』シリーズの開発では、通常終盤に実施するテストとバグ修正が“開発初期段階”からされている、だからたくさんのコンテンツを作れる。テスト自動化がもたらした、かけがえのない産物 – AUTOMATON

セガが手がける『龍が如く』シリーズ。「龍が如くスタジオ」が手がける同シリーズは、大ボリュームでありながら、リリースペースが速いというのがひとつの特徴だ。そうした大ボリューム・ハイペースリリースにあたっては、テストとデバッグの効率化が不可欠である。

通常、ゲーム開発においては、テストやデバッグは終盤におこなうものである。コンテンツを作り終える、あるいは作り終える直前のタイミングからスタートし、テストとデバッグを行う期間が設けられ、完成する。しかし「龍が如くスタジオ」では、このテストとデバッグの作業が開発初期段階からスタートし、ゲームづくりと並行して進行するというのだ。そのおかげでより多くのゲームコンテンツが作れるという。

なぜそんなことができるのか。それは「龍が如くスタジオ」あるいはセガで培われてきた「テスト自動化」技術が鍵を握っているだろう。今回はセガのクオリティエンジニア（テスト自動化を含めた品質に関わるあらゆる問題を技術で解決するエンジニア）の阪上直樹氏・並木勇人氏・桑原和人氏に話を訊いた。「龍が如くスタジオ」あるいはセガが誇るテスト自動化の試みを、掘り下げていく。

──自己紹介をお願いします。

並木勇人氏（以下、並木氏）：
セガ第1事業部の並木です。2016年入社で、今年で入社9年目になります。もともとは「龍が如くスタジオ」所属で、『龍が如く６ 命の詩。（以下、龍が如く６）』の頃からプログラマーとして開発に関わっていました。いろんな街遊びのプログラミングやシステムの制作で経験を積んだあとは、『モンキーボール』シリーズのUIやローカライズのプログラマーを務めました。シリーズ最新作となる『スーパーモンキーボール バナナランブル』ではクオリティエンジニアリングチームチームに参加してクオリティエンジニアを担当しています。

桑原和人氏（以下、桑原氏）：
セガ第1事業部の桑原です。2018年入社で、今年で入社7年目になります。自分も最初はゲームプログラマーとして入社したあと、『龍が如く７ 光と闇の行方（以下、龍が如く７）』と『LOST JUDGMENT：裁かれざる記憶（以下、ロストジャッジメント）』のアドベンチャーパートやミニゲームなどを担当していました。そこから徐々にクオリティエンジニアの業務の方に携わらせてもらうようになって、『龍が如く８』ではクオリティエンジニアリングチームのリーダーを務めさせていただいています。

阪上直樹氏：
セガグループの技術的なサポートをする、開発技術部という部署にいる阪上です。2004年入社なので、もう20年選手ですね（笑）私ももともとゲームプログラマーとしてセガに入社して、『プロサッカークラブをつくろう!』シリーズなどを作っていました。『龍が如く』シリーズの開発には『龍が如く３』から参加しています。最初に参加したときはテスト自動化には携わっていなくて、ステージの描画や時間経過による昼夜の変化の研究などをしていました。これは後任に引き継がれ、『龍が如く８』のドンドコ島のシームレスな時間経過の基礎になったものですね。そのあとテスト自動化に目覚めまして（笑）今は開発技術部でセガタイトル全般へのテスト自動化の導入に注力しています。

テスト自動化とは何なのか？

──テスト自動化とはそもそもなんでしょうか。

阪上氏：
少し長くなりますが説明させてください。ゲーム開発においては、テストとデバッグという作業があります。テストは、ゲームの仕様書からテストする項目を計画し、その計画を元にゲームをプレイ（テスト）してバグを見つける。バグを報告し、修正されたらそれを確認する。これがQAテスターの仕事です。一方でデバッグでは、見つけられたバグの原因を調査し、バグを修正する。プログラマーを中心とした開発メンバーの仕事です。これらの主にテスト部分を自動化してしまうというのが、テスト自動化です。画像を見ていただくといいかもしれません。

さらに、龍が如くスタジオでは、テスト自動化の範疇を超えて、ゲーム開発の環境全般を自動化しています。開発環境で初期の段階からゲームのパッケージ化（ゲームの実行に必要なデータを1つにまとめること）の自動化もやっています。

パッケージ化の自動化の延長線上として、テストの際に必要なパッケージを自動的にインストールしてテスト環境を整える作業も自動化しています。自動テストに焦点が当たりがちなんですが、テスト項目の設定の自動化もしています。実際にはそういった仕事の方も大変なんです。内容がキャッチーなこともあって、講演では自動でゲームをクリアするところに注目が集まることが多いんですけど（笑）

──キャッチーな講演といえば、少し前のCEDECで「ほぼ全自動のバグ取りシステム」というテーマで発表されたのがみなさんの記憶に強そうです（ファミ通.com）。テスト自動化はいつから研究されていたのでしょうか。

阪上氏：
かなり昔から研究はしていました。最初はパッケージ化の自動化やエラー検知の自動化だけだったんですが、『龍が如く６』の時にゲーム内のログの分析やバグやタスクなどを管理するチケット管理システムの自動処理を始めたあたりからツールが揃ってきて。2020年発売の『龍が如く７』の時に、あのキャッチーな名前の「全自動バグ取りシステム」ができて……（笑）

仕組みとしては、手動でプレイした行動履歴（どこに移動したか、誰に話しかけたか、どのアイテムを使ったかなどの単位）をコマンド化した上で記録して、リプレイデータ（スクリプト）として自動出力して、それを手直しを入れながら作成したものを自動テストとして実行します。そして、自動テスト実行時にもリプレイデータを記録しておき、自動テストでバグを検出した場合にはそのリプレイデータを保存しておいて、あとでリプレイデータを実行すれば実際にそのバグに遭遇できるという流れです。あるあるなのが、バグが起こった座標にポンとワープするだけだとバグの再現ができない可能性が結構ありまして。その座標へ向かう途中の手順も必要なんです。そのため、「どういう手順で再現するか」を記録しておくのも重要です。

またテスト自動化は導入しただけではあまり意味がないんです。「ただテストを自動化しました」「結果はわかりません」という状況になってしまいがちで。そういう意味でも、バグを検知するためのクラッシュレポートの機能が必要でした。バグを検知したら調査するための情報を記録しておく機能もあって、最終的にはテストに成功した状況も確認できるようになっています。加えて、パフォーマンスを可視化するシステムと組み合わせて効率的にイテレーション（ソフトウェア開発において特定のテストを短期間に繰り返すこと）を回せるので、開発の効率が上がります。

どのような効果があるのか？

──テスト自動化を導入して、実際にどれぐらいの成果がでましたか。

阪上氏：
かなり出ています。講演では、毎回数値の面でアピールをしています（笑））『龍が如く０ 誓いの場所』の時は1000件に満たないぐらいだったエラー検知数が、プログラムの改善でいろいろさまざまなテストをできるようになったことでどんどん上昇していて、『龍が如く８』だと6万件ぐらいですね。特に自動テストがエラーを見つける割合はどんどん上がっていて、現在は80%を超えています。

テストの稼働時間もどんどん増えていて、『龍が如く８』だと、メイン・サブシナリオの通しテストやミニゲームのテストを各言語、各プラットフォームで日々実行した結果、累計で70万時間ぐらいのテストを夜間動かしていました。24時間自動化されたテストを回す台も増えてきて、朝動かした台が昼過ぎにもうエラー出しているような状況になってきています。

『龍が如く８』だとテスト稼働した70万時間の100分の1以下の5000時間程度でテスト自動化の仕組みの実装や自動テストの作成・運用を行いました。それでこれだけの実績を出したので、1人当たり100人分以上の仕事をしていることになりますね（笑）ただこういう言い方をするとすごいコストを削減できるみたいなイメージが先行してしまうので強調しておきたいんですが、仕組みの改善の積み重ねによってできたことであって、最初からこの効率ではなかったですね。

『スーパーモンキーボール バナナランブル』はシリーズ初めての導入だったので、人力の10倍ぐらいの効率でしたが、10倍でも予想よりも大きい数字です。『龍が如く』シリーズの仕組みの一部を流用して実装できたので、このぐらいの数字が実現できました。テスト自動化を導入する場合、最初のうちはコスト削減よりも品質向上の効果の方が大きいかなと思います。

──かなりの工数削減ですね。

阪上氏：
それとテストといえば、開発の終盤にやるものだというイメージかもしれません。しかし「龍が如くスタジオ」では、これまでの経験を活かして前作の仕組みを早い段階で導入し、ベータではなくアルファやプロトの段階からテストをおこなうこともあります。

──え、開発初期段階からテストを並行して進めているんですか……？

阪上氏：
開発の行動をかけ始めたら、テストの準備を始めるという感じですね。

──それは驚きました。龍が如くチームでは、テスト期間は設けないのでしょうか。

阪上氏：
もちろん、最終的な手動の確認のためのテストとデバッグを行う期間は終盤にあります。その期間までに致命的なバグを残しておきたくないので、あらかじめ対処をしているわけですね。特定の座標に行くとアプリケーションが落ちるバグやオブジェクトの衝突判定が抜けているバグなどの分かりやすいバグは、早めに直しておきたいんですよ。たとえば、昨日の夜に出たバグならみんな覚えているんですけど、発生から一か月経ってからバグを報告されるともうどれのことかわからなかったり、そのバグが違うバグを生んでいたりなんていうことがあるので、早く対処しておくとコストがかからないんです。

──たしかに、はやいうちにバグ潰ししておくにこしたことはないです。

並木氏：
テスト自動化導入前は、バグの発見から対処までの期間が長くて。いざデバッグをしようとなってもバグが発生した状況の調査に時間を取られてしまって開発速度が遅くなってしまっていました。専念したい作業があっても、そこに差し込みでバグ調査や修正が入ってくるので。

テスト自動化を導入してからはバグの情報がまとまって送られてくるので、夜間に見つけたバグをその日の昼にはもう直して、夜にはまた自動でパッケージを作って翌朝には直っているというサイクルが出来上がったんですね。そうすると今までとは全然違う速度でゲームが開発されていくんですよ。バグの直りが速くなって、時間が空くので、その空いた時間でいろんな機能を作れてどんどんゲームが組み上がっていく。テスト自動化を入れる前と後では開発速度が変わっていて、あっという間にゲームができていく光景を見た時には「テスト自動化ってすごいんだな」という実感がありました。

桑原氏：
進行不能などの致命的なバグは、開発終盤に1つでも出てしまうとマズいんです。テスト自動化を導入することで開発終盤は毎日「メインシナリオもサブシナリオも全部クリアしてあります、ミニゲームもきちんとできています」という状態を保証できるので、安心感がありますね。空いた分の時間をクオリティアップや新機能の実装に割けているという実感もあります。

阪上氏：
ほかには、手動のテストをやっているチームやローカライズのテストをやっているチームもあり、その人たちに自動テストの結果を共有できるのもすごく大きいメリットですね。たとえば、パッケージが特定の言語で動かない不具合って割と起きがちだったりします。そういうときに自動テストの結果を見てもらって、各自でテストで使うパッケージを判断してもらえるところはすごくいいところなのかなと思います。

海外の方とのやり取りは時差の関係でリアルタイムではできないこともあって、情報がうまく伝わらずに動かないパッケージを選んでしまうということが起きていたんですが、テスト自動化の導入でそれも解決しました。バグ対応のコミュニケーションにも時間的なコストがかかりますし、こちらの昼はむこうの夜中ですからあまりよくない働き方にもつながってしまう上、放置もできない問題ですから解決できたメリットは大きいです。

テスト自動化がもたらしたものは、「効率」だけじゃない

──『龍が如く』シリーズでは、これまでどういうバグが起こりがちだったんでしょうか。

阪上氏：
タイトルによってどういうバグが起こりやすくて、それに対してどういうテストが必要かということを考えておくことが大事ですよね。『龍が如く』シリーズの場合は、ゲームの要素ごとの接続部分が大変です。メインシナリオを中心に、サブシナリオやミニゲームなどの差し込みの遊びがちりばめられた構造になっています。そういう作りだと、メインシナリオとミニゲームのつなぎの部分でエラーがでてしまうことがどうしても多いんです。

ミニゲームが終わった後にプレイヤーが変な座標にワープしてそのままゲームが落ちる、みたいなケースですね。こういう場合はその不具合を解消するまでメインシナリオの開発が進まなくなってしまいます。ですので、『龍が如く』シリーズの場合はメインシナリオのテストを通しで行うことがすごく重要なんです。『龍が如く８』の場合は、メインシナリオ中にドンドコ島やクレイジーデリバリーなどの必須イベントが入ってきたりするので、そのあたりが干渉しないかを見るのがより重要でした。

──ゲーム内時間の経過やイベントなどでNPCの場所が入れ替わることもありますし、『龍が如く』シリーズはテストが大変そうです。

阪上氏：
メインシナリオのキャラクターとサブシナリオのキャラクターの距離が近いと問題が起きやすいので、そういったところは重点的に調べますね。自動でゲームをクリアする仕組みは『龍が如く６』から追加されました。それまでは、手動でテストを行うチームにパッケージを提出するたびに、みんなで1章から最終章まで通しでテストをやっていました。1章ごとに担当を決めて手動でやっていたんですけど、自動でクリアできるようにすることで、この作業から解放されました（笑）今でも最終的には人の目で確認しなきゃいけないのですが、繰り返し行う確認作業を何度もやらなくていいという功績は大きいですね。

──『モンキーボール』のテストはどの部分が大変なのでしょうか。

並木氏：
『モンキーボール』は『龍が如く』と比べるとゲーム性がシンプルでコンパクトにまとまっていることに加えて、ボールの動きなどの物理挙動のルールは長い歴史のなかでかなり堅牢に作られていますので、プログラムの根幹部分よりは、背景やステージなどのグラフィック部分や新しいギミックの動作のチェックを重点的に行いました。

もう1つ大事なことがあって……。『モンキーボール』って、実はとても難しいんです。各ステージのテスト担当を割り振る形を取ると、後半ステージを担当する人たちの心が挫けちゃうんですよ（笑）テスト自動化導入前の『たべごろ！スーパーモンキーボール 1＆2リメイク』の開発時も全ステージをクリアできるのが開発チーム内に1人2人しかいなかったんです。後半ステージのテストはほぼその人たちとQAテスターの人たちに頼り切っている状況だったので、まずそこを無人化しなければいけないというのがテスト自動化の発端でもありました。

──そんなことはありえないですが、テストができないまま発売して、「難しいステージ、実はバグがありました！」なんていうことになったら製品として問題がありますもんね。

並木氏：
そうなんですよ！とはいえ、『龍が如く』シリーズとは自動テストの内容もまた違うんです。ゲーム性の違いで大変だったこととして、『龍が如く』シリーズみたいなゲームだと、ランダム入力をしても、ある程度敵を倒してくれたりして、テストとして有効なんですが、『モンキーボール』でランダム入力をしてもすぐにステージから落ちてしまうだけでテストにならないんですよ（笑）なので、『モンキーボール』向けに、ランダム入力ではなくAIで行動を制御したテストを行いました。

もともとのゴールに向かっていく1人用のモードに加えて、今回の『スーパーモンキーボール バナナランブル』では最大16人のオンラインバトルモードや複数のルール、アイテムの要素も追加されていたので、テストするだけで一苦労なんです。特に16人で遊ぶモードを手動でテストするのは相当大変でした。一応隙を見てチーム内でもやってはいたんですけど、チームのみなさんも忙しいので週に2回やれるかどうかぐらいで。そういうテストは本当にテスト自動化でかなり助けられましたね。

──『龍が如く』はコンテンツのバリエーションや量の面で、『モンキーボール』はゲームの難しさの面で、それぞれ開発が大変なんですね。

並木氏：
『モンキーボール』については、私よりも自動テストのほうが上手いです……（笑）

一同：
（笑）

──テスト自動化が実用化に至るまでの歴史が気になります。テストの完全自動化システムが完成する前は、どのようにテストをしていたんですか。

阪上氏：
私が龍が如くチームに入った『龍が如く３』の開発時には、すでにテスト自動化の原型がありました。もともとはCEDEC2010の講演の通り（資料）当時のメインプログラマーが片手間で作っていたものがありまして、もうテスト自動化の原型がここでできていました（資料）。

これが『龍が如く4 伝説を継ぐもの（以下、龍が如く4）』ですね。『龍が如く３』まではまだテスト環境を自動で作るサイクルはなかったんですけど、自動でプレイする仕組みだけはあったんです。みんな帰る時には自分のPCでゲームを起動するようにして、プレミアムアドベンチャーでランダム入力を繰り返すように設定しておきます。そして朝来たらバグを確認して、プログラマー同士でワイワイ話し合いながらそれを直すという、半自動の形でテストをおこなっていました。

その試みを、『龍が如く4』の時にシステム化しました。ワンボタン押すだけで自動化されたテストを起動できるようになったので、退社時にはテストを起動してから帰りましょうという文化が生まれていきました。

──テスト自動化のアイデア自体は昔からあったものなんですね。

阪上氏：
実は、アーケードゲームの開発がテスト自動化の基礎になっているんです。龍が如くチームの源流を辿っていくと、もともとアーケードゲームを作っていた方が結構多いんですね。アーケードゲームにはアドバタイズと呼ばれる、コインを入れていないときに流れるデモ映像がありますよね。あれって、単なるムービーではなく、実際にゲームを動かして出している映像なんです。アドバタイズを作るようなことをみなさん経験していたので、コンソールゲームの開発にあたっても「なんか自動で動かしときたいよね」という文化が自然に生まれてきたんだと思います。

──それは面白いですね。アーケードから脈々と受け継がれてきた血があると。

阪上氏：
ただ、アーケードゲームとコンソールゲームではプレイ時間も違いますし、テストしたい項目もどうしても違ってくるので、ランダムで動かすだけだと達成できない部分も多いんです。それを解決するため、条件やテスト内容をちゃんと設定できるような仕組みを追加しながら今の形になっていきました。

──阪上さんを中心にコツコツ積み上げてきたものなんですね。テスト自動化がある程度パッケージング化できたのはどのタイトルでしょうか。

阪上氏：
『龍が如く4』のころからメインプログラマーが片手間で行っていたものを私が引き取り、テスト自動化の専任者となったころから、本格的な取り組みになっていきました。そのタイトルは、実は『バイナリー ドメイン』（龍が如くスタジオ開発のTPS）なんです。CEDEC等の講演では、主に『龍が如く』シリーズの事例として発表しているため、そのイメージが強いかと思いますが、私としては『バイナリー ドメイン』からテスト自動化を本格的に始めたので、このタイトルが特に印象に残っています。

なぜクオリティエンジニアの道を選んだのか

──阪上さんはすでにCEDECなどでテスト自動化のセッションをたびたびしており、業界の知名度も高いです。一方でばりばりプログラマーだった桑原さんと並木さんが、クオリティエンジニアへの道に進もうと思ったきっかけを教えて下さい。

桑原氏：
自分はプログラマーとして活動する中で、『JUDGE EYES：死神の遺言（以下、ジャッジアイズ）』の時にスクリプトの作成やドローンレースの自動操作プログラムを担当して、テスト自動化のお手伝いをしていました。シナリオやコンテンツを自動で遊んでバグを見つけてくれるところが面白いと思って興味をもちましたね。

その後、『龍が如く７』と『LOST JUDGMENT：裁かれざる記憶』の開発でもログ分析の活用や自分で作ったミニゲームのテスト自動化などをしていました。その後クオリティエンジニアの方面に進みたいという自分のアピールもあって、『龍が如く８』でクオリティエンジニアリングチームのリーダーを任せていただけることになりました。

──たしかに『JUDGE EYES：死神の遺言』および『LOST JUDGMENT 裁かれざる記憶』のドローンレースは衝突の判定などが複雑そうで、バグが多くなりそうです。

阪上氏：
ちょうどこちらの資料にありますね。ドローンレースのメモリ使用率を可視化したものです。ドローンの場合、空中の高いところからマップを見下ろすので結構メモリがカツカツになってしまうんですね。桑原君には新人の頃、そういったデータの可視化などをやってもらっていました。

──『ロストジャッジメント』のドローン、上空のオブジェクトの衝突判定が甘くなってないか、壁抜けできないか調べるという意地悪なことをしたのですが、壁抜けできず感心した記憶があります。

阪上氏：
……（笑）ドローンレースにはかなり時間をかけましたね。数十台のマシンを使って、壁を含めたいろんなオブジェクトにぶつかるテストをしていました。室外機などにもそれぞれちゃんとコリジョンがついているのでいろんな角度からぶつかる必要がありまして、そのような自動テストをおこなっていました。

──並木さんは、なぜクオリティエンジニアになられたのでしょうか。

並木氏：
クオリティエンジニアリングチームに入ったのは、だいたい2年前ぐらいです。ちょうど『たべごろ！スーパーモンキーボール 1＆2リメイク』のプログラマーをやっていたころで、その仕事が一区切りついたタイミングで阪上さんから声をかけていただいたんです。その時に『モンキーボール』シリーズの開発環境に『龍が如く』シリーズのテスト自動化を導入してみたら面白そうだなと感じて、チャレンジ精神からチームに参加させてもらって今に至ります。

プログラマーの普通の業務はゲーム内の仕組みや遊びの部分の作成がメインなんですが、テスト自動化となるとそれぞれのゲーム機や開発機、PCなどに対応したツールも作ることになります。加えてチーム内のデータのやりとりや、開発の各サーバーに情報を流すためのセットアップやメンテナンスなども必要で、当時はまったく知らない世界に飛び込んでしまった感じでした……（笑）これまでとは全然違うフィールドで戦う感覚でした。

てんやわんやしながらもいろんな人に話を聞きつつ、勉強と作業を同時に並行していました。なかなか大変でしたがやっていくうちにどんどんハマっていって、『スーパーモンキーボール バナナランブル』では実績として残せるテスト自動化ツールを実装できました。

──大変ですね。テスト自動化を仕込む側は、ツールを作成し、ツールの実装をし、実装したものがきちんと作動するかのチェック、これらの工程をすべてこなさないといけないですもんね。

並木氏：
それまではツールなどを利用する側だったのですが、作る側になって「今までこれ使っていたけど、どうやって作るんだろう」って悩んでしまって（笑）個人的には新しい問題にぶつかると解決方法を探し求めてしまうタイプなので、そうやっているうちにテスト自動化の沼にずっぷりとハマってしまって、今はチームの一員として活躍させてもらっているという感じです。

阪上氏：
並木君の場合は、ゲームのエンジンの仕組みやデバッグの手法などを探求するタイプなので、そういうところもテスト自動化に向いていますね。メモリが枯渇している時に何が原因かを調査する仕組みを準備して、デバッグしやすくするところとか。

並木氏：
『たべごろ！スーパーモンキーボール 1＆2リメイク』時代にローカライズプログラマーをやっていたんですが、そのころからシステムを自作してUnity上で動かすことをやっていたので、エンジンレイヤーの知識には結構自信があったんです。ただ、それでも『モンキーボール』開発へのテスト自動化の導入には結構苦労しましたね（笑）

それまでのテスト自動化は『龍が如く』シリーズに合わせて作られていたので、ドラゴンエンジンかつPlayStationでの開発から始まったハイエンドコンテンツ向けのものだったんです。ところが『モンキーボール』の場合はUnityかつNintendo Switch向けにカジュアルなコンテンツを開発をする必要があって、さらに『龍が如く』シリーズはオフラインでシナリオを遊ぶゲームですが、今回の『モンキーボール』はオンラインでマルチプレイのバトルロイヤルゲームとジャンルもまったく違ったので、とにかく新しいことづくしで（笑）お互いのチームの知見を組み合わせて、なんとか形になりました。

──専門性が高い。

阪上氏：
実際は広く多様な知識があることの方が重要だったりしますね。

────テスト自動化という仕事は、ほかの部署やチームからどのように理解されているのでしょうか。

阪上氏：
開発の現場からの支持は得られていますね。単純に我々みたいなテスト自動化を行うエンジニアだけでなく、いろんな人が使えるのも大きいかなと。たとえば、ミニゲームを担当しているプログラマーがいて、その人が自分のマシンで自動テストを作って実行する。そうすると自分の担当するミニゲームがちゃんと動いていない場合に一目でわかるんですよ。便利であることが支持や理解につながっているのかなと思います。

桑原君も、自分の作ったミニゲームのテストを自分で自動化して、それを夜間動かして見つけたバグを昼に直すというようなことをしていましたね。それと、プログラマーはみんな新人研修でテスト自動化を経験していて扱いもわかっているのも大きいかなと。

──朝会社にきて、夜のテストの時に自分のプログラムのバグが見つかっているというのは、どういう気分なんですか？

並木氏：
嬉しいといえば嬉しいです。バグがきちんと直されるところまで確認できて、ようやく嬉しいと感じますね。それまでは1つ1つのエラーでしかないので。

桑原氏：
……嬉しいですが、バグレポートがまとめて届くと困りますね（笑）

一同：
（笑）

──単純に仕事が増えるってことですもんね（笑）

桑原氏：
『龍が如く７』のサバイバル缶拾いも自分でプログラミングと自動テストをやっていたんですが、朝来たらおかしなところを見つけてくれていたという経験があります。バグの発見から対応のレスポンスを改善できたので、あれはめちゃくちゃありがたかったですね。

阪上氏：
ちょうど資料がありました（資料）。このミニゲームはメインシナリオの途中にある関係でちゃんとチュートリアルをクリアしないとメインシナリオを先に進められないため、ここの自動テストは絶対に必要でした。

──スキップできないミニゲームだと、より細心のテストとデバッグが必要になりますよね。

阪上氏：
（資料）ミニゲームのテストにおいてはプログラムがきちんと動くかという部分を重点的に見てしまいがちなんですが、実際にはミニゲームが発生する地点までの道のりを歩いてミニゲームをプレイしたあとメインゲームに戻ってくるところも含めてのテストなので、テスト自動化はそういうところを補ってくれています。

桑原氏：
テスト自動化の場合、普通にプレイしてもなかなか遭遇しないレアなバグが見つかったりするので、そういうところも利点ですね。

──人間ではこんなプレイしないだろうというようなプレイもテストしてくれますしね。

桑原氏：
人力でやろうとするとかなり回数を重ねなければいけないところを、テスト自動化ならテストの数の優位性と特殊性の両方が確保できますね。

──テスト自動化は多方面に意義がありますね。

別記事では、そもそもバグを起こさない取り組みについても語ってもらった。そちらは後日公開する。

[執筆・編集：Daijiro Akiyama]
[聞き手・編集：Ayuo Kawase]