最終更新日: 2021年11月9日
2021年8月4日、第5回目となるAIQVE ONE主催のオンラインセミナー、QA Tech Nightを開催いたしました。この記事では、その中で行われた当社の花房、石丸、桑野によるパネルディスカッションの模様をお届けいたします。
＜関連記事＞
【QA Tech Nightレポート】ゲームデバッグ体質の限界と いま求められるゲームテスト(AIQVE ONE 花房）
【QA Tech Nightレポート】ゲーム業界のテストエンジニア教育について(AIQVE ONE 石丸）
質疑応答
桑野：
テーマは一応あるのですが、まずはチャットにきている質問をひろっていきたいと思います。
「テストデザイナーとはどういった職種なんですか？」
桑野：
テスト設計者などはよく聞きますがテストデザイナーってあまり聞かないですよね。どういった感じのイメージなのでしょうか。
石丸：
テストデザイナーは、テスト設計者の上位種になります。
たとえばテスト設計者のリーダー的な扱いになるので、メンバーのマネジメントやお客様との折衝も直接できる方を想定しています。
花房：
イメージ的には、弊社でいうと『テスト設計者』というのがテスト設計する作業者という意味合いで捉えていて、『テストデザイナー』はより上位のスキルを持ち、テスト設計の工程の管理とか作業の管理をするような、テスト設計のリーダーのような立ち位置と捉えています。テストアナリストに近いイメージですね。
桑野：
ソフトウェアテストやJSTQBの流れでいうと、基本的にテストエンジニアの役割やレイヤーって割ときちんと定義されているんですよね。
ゲーム業界の今までのゲームデバッグというくくりでいうと、長年やっているリーダーさんって何でもできますというスーパーマンみたいな人で、一人でテスター、テスト設計者、リーダーの役割をやっていたりしますよね。
1人何役もやっているスペシャルな人が喜ばれるというところがあったと思うんですけれど、ソフトウェアテストの考えだと、ある程度役割を定義してその人はそれをやるみたいな感じなんですかね。
花房：
そうですね、でも案件規模によってはリーダーが設計を兼任したりというのはどうしても出てきてしまうというのはあります。そこがゲームと大きく違うのかなと思います。リーダーでも、しっかり設計のスキルを持っているというところですね。
桑野：
なるほど。他にも質問をいただいています。
「現在のゲーム開発におけるプロジェクトに関わる人数は大小様々ですが、少ないプロジェクトでもどのくらいの人数をかけているのでしょうか」
これはテストの人数のことですかね。
昔は100人を超えるようなパチンコ系案件もだとあったんですけれど、今でもコンソールの大規模案件はそのくらい動かしていると思うのですが、スマホ案件だと流石にそこまではないですね、100人とか。
花房：
テストで多くても20-30人とかですか？
桑野：
ですかね、過去にスマホで50人以上の大きな案件もやったことがありますけど、それは特殊ですね。
石丸：
自分は100人規模の案件を経験したことはないですね。
桑野：
プロジェクト全体の人数に対するテスト人数もしくは工数の内訳にも触れておきましょう。
たとえば開発に50人くらい投入していたら、テストにだいたいどのくらいかけるかという趣旨の質問ですかね。開発がどのくらい動いているかっていうのはお客様側のことなので、我々テストベンダーはわからないことが多いですね。
花房：
予算的な配分でみるとテストってだいたい2～3割ぐらいだと思うので、テストの人数の3倍から5倍くらいでしょうか。
桑野：
なるほど！肌感覚だと、だいたい10名〜20名規模の案件が最近は多い気がします。
石丸：
そうですね。波はありますよね。たとえば開発が遅れました、という感じでここまでにテストしなければならないとかになると…。
桑野：
縦積みですよね、それはありますね。運用案件のテストですと、平均して5名とか10名以下とかでまわしたり、多くて20名いくかいかないかぐらいですよね。運営で30名超えるってなかなかないですよね。
石丸：
ないですね。
桑野：
もしかしたらどこかではやっているかもしれないですけれど。プロジェクト全体とテストの内訳っていうと、開発費の2割・3割はテストに関わるというセオリー的なのがあるじゃないですか。ゲームに限らず。これってどこかに書いてあるんでしょうか？教科書的なところに。
花房：
どこかが出しているデータから推測するとそのくらいというのはありますね。
桑野：
テスト予算を組めないでどうしようかなぁというときに、だいたいそのくらい予算を取っておいてください、と言うのですけれど、明らかに少ないときに、テストの予算って削られたりするじゃないですか。その場合はどうしたらいいんでしょうか。皆さん頑張ってください、としか言えないんですけど。
花房：
でも欲張りな方が多いのかなと思っていて、予算はこのくらいしかないけど、あれもやりたい、これもやりたいという人は多い印象です。その範囲内でできることを最大限やりましょう、という考えか、本当にやりたいんだったら頑張って予算をとってください、とは思いますけれど。
「リモートワークでのテストはできるんですか？」
桑野：
リリース前のアプリの持ち出しとかはやはり難しいですよね。一応弊社はコロナ対策をしっかりして全員出社しているんですけれど、お客様先に常駐しているリーダーさんや社員はお客様先がリモートになっているので、結果その人は家でやっているんですよ。セキュリティ的な担保みたいなところもお客様のところに準拠していれば、対応させていただいていますので、一応できます。弊社もできる体制にはなっています。VPNとかひいて、デプロイゲートとかで受け渡しして。
石丸：
がっちがっちの契約書・誓約書みたいなのを書かせていますね。
桑野：
そうですね。単なるNDAではなくて、あなたの家族のとこまで行くよみたいな。
石丸：
そこまでブラックではないですけれど。
桑野：
でも書いた記憶ありますよ、以前の会社で。何かあったら親族のとこに行くの分かっているよね、みたいな感じのことを最初に言われて。ずっと「絶対に情報を漏らしてはいけない」という心理的ブロックがあったんですよ。だからむしろなんで情報漏えいが起きるのがよくわからなくて。そのあたりのリスクはありますね。でもそれはベンダーだけではなくてお客様も一緒だと思うので、そこは準拠してやらせていただいています。
「開発手法はウォーターフォールが多いですか？」
桑野：
これはゲーム業界あるあるですけど、ぎりぎりまで仕様が変わるので『なんちゃってアジャイル』みたいな感じでぐるぐるいったりとか、きっちりやる会社さんもありますけど、肌感覚ではどうですか？
花房：
大きな括りでは、リリースするまではウォーターフォールなのかなと思ってはいるんですけれど、途中途中でアルファ版・ベータ版とか入ってくる区切りがあると思うんですよね。そこに行くまではアジャル的な進み方になっているかと思いますね。
桑野：
大枠はウォーターフォールなんだけれど、個々のやつはごちゃごちゃやってるみたいな。
花房：
なので最近、テストを実行するだけの人よりはテストケースも書ける人が欲しいというニーズが増えているのは、そういうところもあるのかなという気がしています。
「アジャイルはスクラムとか作っている感じありますか？」
桑野：
これは会社さんによるんですよね、ゲームの。
今までの日本のゲーム会社さんでは、最初に一気に作ってベータ版を作って最後にデバッグ・テストをやって終わり、みたいなやり方で来てませんでした？今もそうかもしれませんけど。
石丸：
そうですね。
桑野：
アジャイルの考え方って、単体とか小さい段階でテストもして、ある程度品質を高めた段階でマージして、最後にくっつけたときにバグがないという状態が理想だと思うんですけれど、そんなにきれいにできている会社さんてあるんですかね。
花房：
どうなんですかね。ばっちりうまくいっているという話は正直あまり耳にしないのですが、各社いろいろな課題がありつつどう乗り越えていくか、というところではないでしょうか。
桑野：
中国の開発陣、ゲームが今そこまで来ているじゃないですか。すごい開発費をかけているんですけれど、デバッグ人員がいないという話を聞いたことがあります。あれだけ規模が大きいので何百人・何千人用意しているのかと思いきや、開発者の隣にQAエンジニアがいて、どんどんその場でテストしているから、くっつけたときにバクがない状態みたいな。本当にセットでQAエンジニアの人がいるようです。
石丸：
じゃあ、もう上流工程からテストしている感じなんですね。
桑野：
そうなんです。最後に一気にまとめてやる日本の今までのやり方ではないと聞いて、すごいなと思ってました。
石丸：
てっきり、最後に開発の人も一緒にテストしているというイメージがありました。
「大型タイトル、SNSとかで運用方法とか違いそうですがいかがですか」
桑野：
そうですね、最近SNSゲーム、スマホゲーム多いですね。
量としてはコンソールも全然あるんですけれど、うちは後発なので、そんなに大きいコンソールの案件はまだやれていないので、これからやっていきたいというのはあります。
ソフトウェアテスト理論の理想と現実
桑野：
せっかくお題を作ったので開発費とかテストのデザイナーってどういう定義なのという話があったので、ちょっとネタを。
僕が聞きたいことでもあるんですけれど、今日、サブタイトルに『理想と現実と落とし所』とつけさせていただいたのですが、要は、きっちりソフトウェアテスト理論を使ってやっていきましょう、昔のゲームデバッグとは違うぞという意気込みはありつつも、僕らもその狭間で苦しんでたりするじゃないですか。
理想はあって、わかってはいるんだけど、でも開発はこんなになっているし無理、みたいなことはある。
とはいえ、リリースはするのでテストは進めていかなければならない、そこをどううまく落としていくかということも聞きたいんですけれど。ソフトウェアテストの考えでしっかりテスト設計をして計画を立ててやっていきましょうと始めても、開発がどんどん遅れていて、実際にテストをする頃には時間もなくてテスト項目を作ったけど使えない、となって、人力でやるみたいなこともありますよね。
石丸：
テスト項目自体を減らしていくというパターンもありますよね。
優先度の高いものだけやっていって、細かいバグはリリースしたあとちょくちょく修正入れてバージョンアップで対応します、みたいな。
桑野：
なるほど。でもこちらが最初に計画立ててやりましょうと言ってもなかなかそうならないケースもあるんですけれど、そういったときってどうやって回避するんですか？
花房：
計画は変わるものなので状況に合わせてやることを変えていくのは大前提かと思いますけれど、その中で根拠とか考えを持っていかにできるかだと思います。たぶん、それがあまりないのが今のゲームテストのやり方なのかなと思います。
桑野：
わりと開発側に突っ込んでどんどん計画を見せてやっていかないとなかなかできない。
花房：
開発のキーとなる人たちにどれだけ理解してもらっているかということに結構大きく左右されるのかなと思っています。
桑野：
だから弊社でも、理想的なテストをやりましょうと言っても、実際はどうしてもお客様の開発状況に合わせて考えを柔軟に変えて対応しているじゃないですか。ぶっちゃけ昔ながらのやり方でお願いしますって言われたら、「ハイ分かりました」ってやると思うんですけれど、ただベースでJSTQB的なソフトウェアテストの考えがあるのは良いところなのかと思います。営業トークになってますけれど。
社内でもありますよね。弊社にも職人的なエキスパートチーム―ゴッドハンドといわれる集団がいるんですけど、全然手法が違うので話が合わないこともあると思うんですけれど、最近はどうですか？最近は社内でも話がかみ合うようになったんですか。
花房：
かみ合わないですよ。
桑野：
かみ合わないんだ。
花房：
思考回路が違うので、絶対かみ合わないと思いますよ。
桑野：
そうなんですよね。これはあるんですよ。本当に神デバッガ―・ゴッドハンドと呼ばれるスタッフのデバッグに対する考え方ってちょっと違いますよね。アプローチの仕方も違うし。いい意味でも悪い意味でも。本当にバグを出しちゃうのですごいんですけれど、全員がそういう風にはなかなかなれないですよね。
花房：
1～2年前にそういった人たちの分析をしたんですけれど、やっている観点はボタンの同時押しとか連打とかが多かったんですよね。
桑野：
まぁ、そうですよね。
石丸：
その辺て経験値とかありますもんね。自分達がやってきて蓄積してきたノウハウとか。
「ゴッドハンドとか神デバッガーさんたちの頭の中の観点を可視化してケースに落とし込むというのは？」（チャットの声）
桑野：
出来なくはないですよね。観点は共有できるのかな？
花房：
観点は共有できるとは思っており、実際にしています。 ただ、どこで何をもってそれをやろうと思ったのかという点が可視化しにくいな、と。
桑野：
確かに。根拠がなくてひらめきだったりするから。
花房：
ここ、怪しいと思ったので、みたいな。そこは経験なのかなとは思いますね。
桑野：
まぁ、できる限り観点化して皆ができるようになったらそれはいいですよね。
テスト項目をつぶすようなテストでも、合間でフリーデバッグできる人がいたら、価値としては絶対にその人の方がいいじゃないですか。両方できちゃう人の方が。よくあるのは、テストケースに沿って進めていると、最初はOKしか出ないのでバグは出ないじゃないですか。だから初期の頃は、開発部隊の人がなんでこんなにバグ出ないのかと心配になって、「ちゃんとテストしてるんですか？」って言ってくるケースがあるんです。
ケースを順番にやっていたら出ないんですけれど、そもそもそこから説明しないとわからない。
バグが出ないと不安だからということで、最初にみんなで粗々でフリーデバッグをして初期のバグを先に出して並行してテストケースも進める、ハイブリットのやり方で進めないと、やっていないんじゃないかという疑念が生まれたりするケースってありますよね。あるから言ってるんですけれど。
花房：
あるとは思いますけどね。でもそれもソフトウェアテスト的な話だとスモークテストやりましょう、というのがそれに当たるような気がしますけどね。
桑野：
そうなんですよね。結局、ちゃんとテスト理論の中に何かしら当てはまるものが今まで明文化されていなかったり、暗黙知の領域だったゲームデバッグというのが実はちゃんと理論としてあったりするんですよね。
花房：
うん、それが結び付けられていないとか知らないからしっかりしたことを言えないというのはあると思いますね。
桑野：
理論にはない完全に未知なる領域ってあるんですか？
花房：
未知・・・未知なんですかね。
桑野：
未知の領域がないなら、基本理論に当てはまるから、そういうことを教えれば皆できるんじゃないかな、と期待しているんですけど。
花房：
教えてもできない人は一定数いますよ。
桑野：
そっか～。「さわってるうちにゆらぎとかを指す、プログラムのすきまを探しイレギュラーをさしこんでいる（チャットの声）」とか、本当そうなんですよ、これ。わかる、そういう思考ができちゃうんすよ。
石丸：
普通に偶然出たんですって人もいますしね。偶然続くな、みたいな。
「アジャイルとかウォーターフォールではないゲームプロセスを定義してみては」（チャットの声）
花房：
どうでしょうね？うちとしてこういうのがいいんじゃないか、みたいなのはありますね。
桑野：
ありますよね。基本的なシナリオというか観点の可視化をされていますし、分析も分析手法ありますし、だいたいのことはできますね。
ソフトウェアテスト理論を取り入れた成功事例
桑野：
実は先日別の、僕が主催している勉強会で、ダメな例ばかり挙げる - 開発がだめだとかQA会社がダメだとか言う会があったのですが、それは結果的にそこを直していけばお互いよくなるよね、みたいな感じで落ち着いたんですが、逆に言うとそういったテスト手法をしっかりやったから品質が上がったいい事例はないのかってこないだ聞かれて。そういうことができる次世代のゲームエンジニアってどんな人なのかっていうのを定義したいんですが。
その前に…バグが出て不具合が流出しちゃったから、いわゆる人海戦術で人をとにかく投入してやってきましょうという考えで、コストだけが増大していったという事例があり、そこにソフトウェアテスト理論の考え方を取り入れたら品質が上がりましたっていう実績をちょっと紹介していいですか？
弊社には、①自動化ツールを使った効率化、②ゴッドハンドと呼ばれる専門チームがエキスパート的な観点で短期間でバグを出す手法、③JSTQBの手法にのっとった品質分析という3つの特徴があります。
外部のテスト会社さんを使われているんだけど、人数だけ増えちゃってバグがなかなか減らないっていう例があって、僕らが入ってコンサルティングというか診断をさせていただいたんですけれど、プランナーさんが書いていたテスト項目の粒度が粗いことが判明しました。ザルみたいな状態のところにいくら人を投入してもバグは出ちゃいますよね、という状態だったんです。
なので、そこを見直してテスト項目を作成し直して工数の最適化をはかったところ、それほど人数をかけなくても、テスト項目を潰していけば品質が保たれます、という状態になってうまくいった例なんです。
理想のテストエンジニアとは？
さっきの僕らが喋っていたことって、理想とかではなくてわりと普通に現実で使っていて、なんでやらないんだろうと指をくわえて待っているので、もし今日この中で、実際人だけ投入したのに品質が上がらないというお客様がいたら我々に声かけていただければ、何か答え出せると思います。
そういうことを分析できるような理想のテストエンジニア、いわゆる職人型ゲームデバッガ―ではなくて、キャリアとして将来的にこういうのが理想のテストエンジニアというのはありますか、花房さん。
花房：
理想ですか。理想言ったら設計できて管理できて分析できてって欲張りな感じですけどね。
桑野：
いるんですかね、そういう人。
花房：
まぁ、少ないですよね。
桑野：
ああ、やっぱそうなんですね。
花房：
キャリア的に管理に寄るか、設計に寄るかで大きく分かれちゃうので、どっちもできますよ、そこにさらに自動化もできますよ、という人は多くはない気がしますね。
桑野：
ゲームのテストをやっていても辞めちゃう人も多いじゃないですか、お給料とか社員になれないとかいろんな課題があって、全員が残れるわけじゃないから。でもそこにキャリア的にスキルがあれば実は残っていけるということを提示できると思うんですけど、それを今度CEDECで話すんですよね、花房さん。
花房：
教育のところですよね、はい。
桑野：
弊社の例でいいんですけど、最初はゲーム業界を知らなくて、ゲームが好きだけどこの会社に入ってテスト始めましたという人で、自動化のことも学んで、そっちのテストエンジニアというか自動化の方行ったとかやっている人っていますか？Pythonがかけるようになりました、とか。
花房：
いますよ。全然。
桑野：
その人はなんで、自動化の方に行こうとしたんですかね。
花房：
引っ張るのが苦手とか性格的なところもあると思うんですけれど、もともとそういうところに興味あったとかやってみたら面白かったというところですかね。
石丸：
ゲームもそうだし、ITに興味があって入ってくる人ってそういう人が多いですよね。自分達で開発を自ら学んでやったりする方たちは、最初から勉強意欲が違うかなって。ただ単にゲームが好きで入ってくる人とは違うかなと思いますね。
桑野：
なるほど、逆に言うと最初にテストの方で勉強してそういうことを学んでいけば、ちゃんとしたキャリア設計ができるということですよね。
石丸：
そうですね、ちゃんと目標があって、そこに方向性を結び付けてあげて。
桑野：
なるほど。
花房：
ちょっと採用にも絡んでいるので、いろんな方の経歴を見ることが多いんですけれど、ゲーム業界でずっとテストしていて40歳手前でサブリーダーまでしかしていませんでした、こういうことしてました、という方って結構いたりするんですよね。そういう人って、かわいそうだなと思ったりはするんですよ。
ちゃんとした知識や教育を受けられずに年齢的にも上がってしまって。ゲームの事業会社にいれば、給料はいい方だと思うんですけれど、何かあって転職しようと考えたときに、実際のスキルと年収が見合わなくなってきちゃうんですよね。
桑野：
それで辞めていっちゃうんですよね。もったいないですね。
最初からプログラマーで支援側にまわるっていう奇特な方もなかなかいないですよね。ゲーム業界でもQAエンジニアという職種ってなかなかいなくて。声かけると全員繋がっちゃうんですよ。人がいないから。
だからホワイトスペースって、キャリア的にはおいしいポジションなのだから、みんなやればいいのにって思うんですよ。啓蒙していきたいなと思います。
花房：
みんなやっぱり日の目をみるところとか、派手なところに行っちゃうんじゃないんですか。
桑野：
プログラマーとか、ゲーム作りたいっていっちゃうんでしょ。だから僕らみたいなテストベンダーからプログラムとかPythonとか学んで、自動化を組める人が増えて欲しいなと思いますね。
花房：
自動化ってうちのメンバーもやるまでは弱腰だったけど、やらせてみると「楽しい」っていう人は多いですけどね。
桑野：
本当ですか、ちょっとそういう現場の人の話も聞いてみたいですね。なんのプログラムの知識もなかった人がうちに入って学んで多少Pythonとかかじれることになるって素晴らしいことだと思うんですよね。
花房：
でもちょっと振ったりはしています。「Pythonとか自動化できると自分のゲーム、周回の自動化とかできるんじゃない？」みたいにちょっと誘惑したりはしています。
桑野：
確かに。でもそういうキャリア的にもいける場所があるというのは昔に比べたらいいですよね。昔は本当にアルバイトで終わっちゃう。言い方悪いけれど、プロジェクトが終わったら終了、解散みたいな。他のアルバイトやってください、というのが多かったから、それに比べたら。
「製品評価テスターからウォーターフォールテストエンジニア、スクラムの中でQAのロールやらせていただいてます(チャットの声）」という方もいますね。
石丸：
ウォーターフォールテストエンジニア、すごいですね。
桑野：
でも、この方はゲームではなく製品の方の方のようですね。
ゲームでもこういうことをぱっと言えるように浸透させていきたいですよね。ゲーム業界でも、スクラムの中でエンジニアやってますよ、って。テスターさんたちの価値も上がっていくんじゃないかな、と期待しつつ。
そんなところでいいですかね。花房さんと石丸さんありがとうございました。