最終更新日: 2021年11月9日
2021年8月4日、第5回目となるAIQVE ONE主催のオンラインセミナー、QA Tech Nightを開催いたしました。この記事では、その中で行われた、当社AIQA事業本部 技術支援部部長である花房の講演内容をお届けいたします。
＜関連記事＞
【QA Tech Nightレポート】ゲーム業界のテストエンジニア教育について(AIQVE ONE 石丸）
【QA Tech Nightレポート】パネルディスカッションー『AIQVE ONEが考える理想のテスト体制～理想と現実の落とし所～』
自己紹介
本日、私の方からは、ゲーム業界でよくあるゲームデバッグのテストのやり方や、どういうところに限界を感じているか、これからどういうテストをしていくべきかをお話ししていきます。
内容的には、ゲームテストの体質や問題点、どういった影響があるのか、そこからどういったものが求められるかというところを大きく3つに分けてお話ししていこうと思っています。
簡単に自己紹介ですが、AIQVE ONEの花房といいます、よろしくお願いいたします。
私がどういう会社にいたかをイニシャルで載せているんですが、ゲームパブリッシャーのK社からゲーム業界、テストの仕事を始めたという感じですね。
そこからゲームの業界でテストしたり非ゲームの業界でテストしたりで、行ったり来たりになっています。
2年半前にAIQVE ONEに入ってテストの技術的な支援や自動化の推進、教育の構築や研修対応などを主にやっています。
ゲームテストの旧態依然とした体質
最初に、ゲームデバッグの体質的なところのお話をしていきたいと思います。
まず、最近発表されたものですが、ご覧になられた方も多いかと思いますが、ファミ通ゲーム白書ですね。
国内のゲーム市場規模が2020年に初めて2兆円超えたということになっています。
2019年～2020年にかけて結構伸びたなというところですね。
オンラインプラットフォームというところが主にスマホゲームとかそういったもののくくりになってはいたんですけれど、この規模感が1兆3千万くらいあるということでゲーム市場規模の2/3がスマホゲームになってきているなというところです。
10年前から比べると市場規模が2.2～2.3倍くらいですかね。10年前だと家庭用ゲームとスマホゲームがほぼ1対1だったのが、1対2か1対3くらいまでだいぶ差が開いてきたという感じになってきますね。スマホゲームが出てきて、ゲーム開発やゲームビジネスがだいぶ変わってきたな、と思っています。売り方とかですね。
開発の仕方も、これまでコンシューマーゲームであればウォーターフォール型と呼ばれるのようなものが多かったかと思いますが、スマホゲームになってアジャイルが取り入れられるようになってきたという風には思っています。
約15年前のゲームテスト
それでは、ゲームのテストがどう変わっていったかを考えていきたいと思います。
15年前くらいにK社でゲームテストやってた頃は、こういったPS2とかが多かったんですが、そのときのゲームテストのやり方は、そもそもテストケースなんてなく、テストケースっ何？っていてうところですね。真ん中のゴッドハンドと呼ばれるものに依存したり、人海戦術ですね。
1個1個、簡単にご説明していこうと思います。
テストケース無し
まず、15年前なのでテストケースという概念自体がなかなかなかったというのもありますが、テストケースと呼ばれるものが全く使われていませんでした。
ただテストしたよ、という履歴は残していました。そのやり方なんですが、仕様書をコピーして別でドキュメントを用意して、仕様書の記述内容の横の欄にOK、NGなどのチェックを付けるような形ですね。
その数を数えて何パーセントぐらいテストしましたよ、という進捗の取り方をしていました。実際仕様書がない案件も多かったのですが、その場合は実機を見てそういったものを作って、というやり方をしていました。
ゴッドハンド（神デバッガ―）依存
次のゴッドハンドですが、バグを出せる人みたいなことですね。
テストケースはほぼない中なので、バグを出せるテスターに強く依存していたという形です。同じ会社内でもそういう人は取り合いになっていたりということがありました。客先常駐の場合、人によって成果が違うので人ガチャという風に呼ばれたりもしていました。
人海戦術
最後、人海戦術のところですが、バグを出せる人はごく一部限られた人達なので、他の大半のテスターはフリーテストという形でやってもユーザーと同じような行動しかとれないことが多かったりはしていました。狙ってバグを出すことはあまりできないので、ユーザープレイでもいいので、大量な時間動かしてバグが出る、出ないという形で品質を測っていました。
これもK社の事例ではあるんですが、1日に50人、100人くらいは当たり前に1つのタイトルに投入されていました。
言い方は悪いですが、アサインしておけばいい人がいるだろうという、さっきの人ガチャに通じるところだったりします。
K社にいたとき、私はサッカーゲームを担当することが多かったんですが、最近名前変えますよ、ブランド変えますよみたいな発表があったサッカーゲームですね。当時15年前くらいで、海外のプラットフォームとかでも出していたんですが、1シリーズのテストの費用がだいたい2億から3億くらいかかっていた、というのを聞いたことがあります。
たぶん、今だとテストにそんなにかけるのはなかなかないことだと思います。
少し整理していくと、昔のテストの感じはこんなんでしたね、というところで、基本的にはゲーム開発をして完成したあとにテストの活動をしていくんですけれど、テスト計画・テスト戦略というものはなくて、できたものをひたすら動かすというスタイルでやっていました。
ここ数年のゲームテスト
15年経ってどうなったかですが、最近のゲームは、ハードだとPS4・PS5・Nintendo Switchの他に、スマホでゲームするのが一般的になってきたというのが大きく違うところかと思っています。
そういったスマホ中心のゲーム時代のテストのやり方ですね、ここ2~3年くらい関わってきた中で感じているのは、ほとんど変わっていないところもあるんですが、テストケースを活用するようになったのは、1つ変わったところかなと思っています。
ですが、テストケースの内容というか作り方はあまりよくないかなと思っています。
いわゆるCPM法というテストケースの作り方をしているので、抜け漏れが多かったりすることがあります。単純に仕様書の内容をそのままコピペしてテストケースを作るようなやり方なので、どういったテストをしようかとか、観点を考えられてなかったりというところがあります。
それをカバーするためにフリーテストを多くやったり、バグを出せる人材に頼ったり、数に頼ったりというところですね。そういったやり方がまだまだ多いかなと感じています。
これが最近のテストなんですけれど、十数年前に比べると、ゲームが完成する前からテストケース、さっきのCPM法でとりあえず作るというところですね、それをもとにできたらテストを実行するという形にはなり、ちょっとはよくなった、進歩したかなというところなのですが、そもそものテスト計画・テスト戦略がないというところがまだまだ今の課題と感じています。
これまでW社でシステム検証の経験が長かったんですが、そこでの考え方、やり方と比べると、だいぶ違うというか、言葉は良くないですけれど、原始的なやり方のままだったんでショッキングなところはありました。
15年前と今とで、結構年月は経っているんですけれど、根本の部分はそれほど変わってないんだなという印象でした。
それは何故なのか考えてみたんですけれど、これは一因でしかないとは思いますが、ゲーム業界って暗黙的に開発が上、テストが下みたいな風習というか文化があるのかなと思っていて、その影響でテストの成長が阻害されているように感じています。
その原因・問題ですが、テストの方にも開発の方にも問題があると思っています。
開発の問題としては、よくある認識ではあるのですが「テストって誰でもできるよね」とか「空いた時間でやればいいじゃん」とか「とりあえず新人にやらせとけ」とか、そういった考えだったりですとか、そもそもテストを外部に発注するというところで下請け的に見ていたりということから、深層心理的に開発が上でテストが下という意識が根付いちゃったのではないかなと感じています。
テストの方は、そういった立場的なところに甘んじて、言われたとこだけやっているとか、考えた活動ができていない。あとは誰でもできるというところに甘えてしまっているかな、技術的な投資や教育があまりされていないのかなと感じています。だからゲームのテストって単価も安いのかなと感じていたりもします。
こういったところで、品質の担保に必要なテストの活動ができていないのかなと。
テストって本当は技術職なので、手に職的な活動だと思うのですが、一般的にゲーム業界の中でそうとられていないというのは、テストの活動の仕方とかアピールの仕方がまだまだなのかなと感じていて、ゲーム業界の中での文化を変えていきたいと考えているところでもあります。
ゲームデバッグの問題点と品質への影響
次にゲームデバッグの問題点と影響というところをお話ししたいと思います。
ゲームデバッグの特徴
さきほど出てきた3点ですね、これがいわゆるゲームデバッグの特徴になっています。
CPM法によるテストケース
それぞれの問題点なのですが、最初テストケースとのころですね、さきほども話しましたけれど、仕様書から転記するようなやり方なので、基本的にどうテストしようというのをあまり考えていないんですね。なので仕様書に書いてあること、目に見える情報だけ捉えてしまって考えるということを疎かにしているというのがよくないと考えています。
その影響で、たとえばテストすべき機能が漏れていたりとか、テストすべき観点が漏れていたりとか、条件・パターン・組み合わせが抜け落ちたりすることが考えられます。
あとはいわゆるチェックリストというものになってくると思うのですが、テスト手順の粒度が粗く、人によって実施するたびにテストのやり方が変わったりするところがよくないのかなと思っています。意図してそういうやり方をしていればいいと思うんですけれど、正しい動きを確認しようっていう意味合いでそういった動きになってしまうのはよくないと思います。
属人的（ゴッドハンド依存）
次が、属人的というところですね。人に依存する、バグを出せるテスターに依存するという体質のところなんですが、基本的にどういう経験してきたか、どういうバグ、どれだけバグに触れてきたか、そういったところに強く依存するということなんですけれど、あまり体系的な、JSTQBとかそういった知識がないケースが多かったりするので、なぜそういう行動したのかとか、なぜそういうバグが出たかというところの理由付けがあまりできていないのかなと感じています。なので、職人の勘みたいな言い方になったりするのかなというところですね。
経験がないと、先ほど言った通り、フリーテストをしてもユーザーと同じプレイになってしまって、そういったプレイだとバグを狙っていないので、バグが出ても偶然のようになってしまう、というところですね。
人海戦術
最後が人海戦術のところなんですが、もうごり押しみたいなところですね、とりあえずパワープレイというところなんですけれど、人が大量にいるので入社間もない人もアサインされるケースが多いかと思います。
入社間もない人というのは、研修を受けていなかったり、経験自体も少なかったり、また1日50人・100人という案件になると人の入れ替えもそれなりに出てくるため、そういった新人のトレーニングにかかるコストもかさんでしまうのかなと思っています。
短期間で大量のテストケースを消化しなければいけないというのは出てきてしまうのかなと思うんですけれど、ただフリーテストだけをするために、50人投入しますよというところだと、目的や狙いに乏しく、あまり効果的でないのかなと感じています。
そういった案件はだいたい残業や休日出勤が多く、メンバーも疲弊してしまいます。
ゲーム業界ってやはりフリーテストの意識が強いかと思うのですが、フリーテストだけに偏ってしまうと、何をどれだけテストしたのかが見えなくなってしまうので、品質の測定や分析ができなくなってしまうという懸念があります。
品質の分析ができないと、ゲーム・ソフトウェアの状態がわからないので、リリースできる状態なのか本当は判断できない、と捉えています。
じゃあよく分からない状態のままリリースしてしまったときに、もしかしたら全然リリースできる品質レベルではなかったという可能性があったとして、そのままリリースしてしまうとバグが市場流失してしまいますよね。そのリスクが高くなってしまいますよね、というところですね。あとはフリーテストに傾倒したようなやり方になっていると、人に強く依存した体制になってしまうので、替えがきかないというか、誰か1人抜けると立ち行かなくなってしまうのでそれはチームとして良くない体制かなとも感じています。
フリーテストの効果
ここでフリーテストの効果、実際どうなんだろうなと思い、弊社の事例をもとに調べてみました。
あまりサンプル数としては多くはないんですけれど、フリーテストだけをやった案件のデータを集めて分析して、そこで仮にテストケース作ってテストの実行するというやり方をしたときにどういう差が出るかを算出してみたところです。
フリーテストは実績値、スクリプトテストは完全に想定値にはなるんですけれど、フリーテストで検出されたバグは915件あるんですけれど、これを全部振り分けました。これは本当に全部フリーテストでないと検出できないものなのかテスト設計していけば拾えるものなのか全部見ました。
見た結果、777件、85％くらいは拾えるという結果になりました。
これ、どれだけテストケースがいるのかというところで、バグが5％であると仮定したときに、テストケースが18300ケース必要な計算になります。
テスト設計してテスト実行した合計のテストの工数は2806時間。
でもフリーテストはそれよりも多い4193.5時間かかっているというところで、スクリプトテストはフリーテストの7割弱くらいの工数でフリーテストの85％のバグを検出できますよ、というところですね。
フリーテストとスクリプトテストの差分、15％のバグを検出しようとしたときに、このバグを見つけようとしたときに全体の33％の工数がかかるので、ちょっと効果が低くなっているのかなというところがあります。
さきほどバグ数の差があったので条件ずれてたんですけど、同じバグ数の検出にかかる工数を出し直してみました。
さきほどのデータにプラスして138件のバグをフリーテストで見つけましょう、というところを計算して加算したものになります。
バグ1件の発見にかかる工数が3.61時間だったので、それと138件をかけただけなんですが、それでフリーテストの工数が498時間必要、というのを算出しています。
それで合計値を出すと、スクリプトテストが3304時間というところになって、同じバグ発見にかかる工数が、トータルで見てもフリーテストよりスクリプトテストのほうが少なくなっていますね。割合でいうと約21％になるんですけれど。
こうやってみると、フリーテストは重視されているんですけれど、意外とスクリプトテストで拾えるものも多かったりすることがわかります。フリーテスト自体が良くないというわけではなく、活用の仕方や、どこでどういう風にやる、というところが大事だと思っています。
さきほどの事例は、完全にフリーテストだけをやった案件でとったので、データとして比較したときにいい方に傾いたというのはあるかもしれないんですけれど、しっかりテスト設計をして、それプラス、フリーテストを要所要所で挟む方が効果は高くなるのかなと感じています。
戦略的なテストの重要性
ここまでいろいろお話はさせていただきましたけれど、本当に一番よくない問題がまだ隠れていて、それがさきほどちらっと出てきた、テスト計画やテスト戦略がないというところです。
なぜ戦略が大事なのかというところなんですが、そもそも戦略ってなんだってところを調べてみたんですけれど、これはwikiの引用なんですけれど、ざっくり言うと、「目的を達成するための方向性やシナリオ」ということですね。
戦略とあわせてよく言われるのが戦術ですが、ざっくりだと、「戦略を実現するための手段や具体的な方法」ということでした。
ではこの、戦略と戦術をテストに置き換えて考えてみたのがこれになるのですが、「新しい機能が追加されました、それの担保をしたいです」というところで、どういったテストのやり方しましょうか、進め方しましょうかというのが左上の戦略のところだと思っていて、それを実現するために具体的に何をしようかというのが戦術で書いた取り組みになるかと思っています。
仮にこういったものが全くなかったというときに、どういう進め方すればいいのか分からない、とりあえず何か活動はするけれどその活動が適切なのかわからなかったりとか、それをやった結果どうなっているかというのも、ゴールにたどり着けない道筋になってしまうのかなと思います。
ゲームのテストって行き当たりばったりとかその場のノリみたいなところも強かったりするんですけれど、それゆえに、事前にしっかり戦略や計画を考えるのが少し苦手なのかなと感じています。
なので、良くないんですけれど、適切なテストの活動ができていないと。これはテストの側にも問題があるんですけれど、一方で開発の方、プロジェクトの決裁権もつようなプロデューサーとかディレクターの方の品質への理解、テスト活動への理解というところにも大きく作用されるかなと思っています。
仮にQAの方で、きちんと計画立てましょう、きちんと戦略立てましょう、テスト設計しましょう、という話をいくらしても、プロデューサーやディレクターの方の理解が得られないと適切な活動ができないというところも実際あったりはします。なのでQAもそうなのですが、開発の方の方も品質とかテストの理解を深めていただく必要があるかなと思っています。
基本的に、ゲームのテストっていかにバグを出すかっていうところになっているのが現状です。開発の人達も、結構バグが出ないと不安になるという方が多かったりとか、どんなバグでもいいからバグが報告されてくればちょっと安心する、という心理的なところもあったりしているのかなと思ってます。なので、如何にバグを出すかというところに注力する、比重を置いているところがあるのかなと思います。
ただ、そのやり方を続けていても、品質レベルというか、より良いゲームというところになかなかレベルが上がっていかないのではないかと思っていて、これからは、プロジェクトの上流の方から、品質を向上させるような活動が必要になってくると考えています。
プロジェクトの上流になると、ゲーム自体出来上がっていないので触れる段階ではないので、たとえば仕様書のレビューするであるとか、テスト観点を共有して、そこを認識した上で実装してもらうとか、そういった構成的な活動が多くなるのかなと思っているんですけれど、そういったバグを予防するような活動が必要になってくるんじゃないかなと思っています。
ただとりあえず手を動かすということではなくて、しっかり考えて戦略とか計画を作って行動していくというところですね、そういったところが大事になってくるのではないかなと思っています。
そのためには下地となるような知識が必要になります。
よくあるのがJSTQBの知識とか、あとはそもそも精神論のとこもあるんですけれど、下請け根性的なところ、言われるがままの意識も変えていく必要があるかなと思います。その上で下地となるしっかりした知識をベースに戦略性のある提案していくということがこれから大事になるのではないかと思います。
まとめ：ゲームデバッグの限界
最後に簡単にまとめになりますが、ゲームデバッグの限界ってこんなところかなと思っています。
1つ目が、テスト戦略に乏しく、有効なアプローチができていない。
2つ目は、とりあえず手を動かすという考え方が強いので、事前のテストの検討が不十分、テストケースの内容も粗い。
3つ目が、不十分なテストケースを補完するために、フリーテストに大量の工数をかけているというところですね。
最後は、バグを見つけることに苦心し、注力してしまって、バグを予防するという取り組みが不足していると感じています。
それに対し、こういったテストをした方がいいんじゃないかとか、こういったテストが重要かなと考えている、という話をさせていただきました。
これで私の話は以上にになります。どうもありがとうございました。