最終更新日: 2024年2月19日
自動化人員についての取り組み
桑野：
僕も、注意したほうがいいポイントで、いろいろなお客様に言っているネタがあるので、少しだけ紹介します。
自動化人員の取り組みというところで、今もいろいろな話で出てきましたが、ツールの開発、コンテンツ自体の開発、テスターさん、スクリプトを書く人など、自動化っていろいろな人が出てくるんですよ。
そこを整理していないと大変になってしまうので、これからやる方に向けてこうしたらいいのではないかというお話です。
先ほど高橋さんにも少し話していただきましたが、工数削減、品質向上、検証期間圧縮など、目的をしっかり決めることが大切です。それに見合わなければ手動でやった方が早いということもあるので、全体の品質を上げるための手段でしかないというのを決めることと、全自動は無理なので、それはわきまえてやりましょうということです。
自動化に関わる人は、QAエンジニア、テスト自動化エンジニア、ツール開発プログラマーなど、いろいろな人が出てきて、それが1人のときもあればQAエンジニアと呼ばれる人が全部やっている場合もあるし、“ツールは他のところからもってくるけれど、そのスクリプトを考える人”をエンジニアと言っている場合もあったりします。
コンソールのゲーム業界では、開発側のプログラマーさんがQAエンジニアとして下支えしてやるということで、品管側ではなく開発側にいることが多く、少人数でやっているので、その人のタスクがオーバーするとなかなか進まないというケースもあったりします。
QAエンジニアとテスト自動化エンジニアの業務領域は不明確で、品管やテストチームからアサインされる人にテスト設計者やテスト実行者がいて、では自動化を作る人はどこからアサインされるのかという疑問があると思います。開発側なのか、とか。
自動化できる部分をちゃんと仕分けしてコントロールできる人と、実際そのスクリプトを組んでくれる人、そのツール自体を改修する人、ツールのプログラマーっていうのも実は全部ばらばらなんです。
そのあたりの役割を整理し、分けることで、ツール開発する人はツール開発に専念し、テスト自動化を考える人は考えることに専念し、スクリプトを書く人は書くことに専念し、実際スクリプトをメンテナンスしたいとか実際に使う人は、うちの実行者が行うという風に分けました。
ですので全体を考える部分と、テスト設計できる人、自動で仕分けする人、開発に携わる人と、この画像の真ん中の赤い枠の中の人が、弊社の場合1テスターさんが今ここの人材になりつつあると思っています。ここのグレーなゾーンの人がいな過ぎて、いろいろ進まなかったのではないかと思っています。QAエンジニアと呼ばれる人に全部やらせてしまうと、絶対に進まないと思います。分けた方がいいと思うのですが、仲さん、この赤枠の部分の人が結構増えてきている印象があるのですが、いかがでしょうか。
仲：
そうですね。スクリプト作成は、当然、もともと開発者として動いているスタッフがやっているのですが、テスト実行者が開発側と話せるという状況になってきているので、そういった意味で浸透が早くなったっていうのはかなり効果が大きいと思います。
桑野：
わかりました。高橋さんが直接うちの自動化ツール（オートテスター）を使っている開発者と話すことはありましたか？
高橋様：
直接はなかったです。実際のメンバーは開発者の方と課題会などのミーティングで数回お話しさせていただきました。
桑野：
基本、テストの方に入ったらツール開発した部分は入ってこないで普段のテスト業務の人たちとしか会話していないけれど、テスト自動化が進むようになっていくようになったということですよね。ツール開発の人は改修のときだけ出てきて。
高橋様：
そうですね。
桑野：
なるほど。ある程度仕上がってきたら、今まで通りのデバッグ会社に発注して、デバッグ会社のテスターさんのような感じで自動化まで進めるようになっているから、新たな人が出てくるということもなくなって普段の日常会話のなかで自動化が進むようになったということで合っていますか？
高橋様：
その通りです。
桑野：
そうですね、今お話にありましたように、ここを分離してやっていただけるといいと思いますし、結構よく聞くのが、社内で自動化を進めているけど、「メンテナンスする人材がいなくて止まっちゃって」とか、「いろいろやれていたんだけど、ここの人材いないんだよね」みたいな話です。
僕らは、スクリプトを書ける人とか、QAエンジニアや自動化テストやっていこうという人たち-プログラマーではないけれど、テスト側から開発の方へ寄っていくような人材をこれから増やしていきたいなと思っています。
質疑応答
桑野：
では最後に、参加されている皆さんからの質問に答えていきたいと思います。
質問①
『自動化して失敗して辛い点がありましたか。自動化によって増えるコストって無視できないと思いますがいかがですか』
仲：
まず自動化を導入するにあたって必要なコストは、スクリプトを組むためのスクリプターというコスト、これはスクリプターが1名つくイメージで、スタート時点では1名増になります。
今回試しながらだったので導入にお時間とられてしまったのですが、弊社としては、通常は1名のスクリプターが組んだ自動化で、1.5～2名は削れるくらいを目指して進めていくので、たとえば半年間スクリプターがついて、だいたいの検証のスクリプト、自動化を組み上げたあとは、1.5～2人分、自動化のスクリプトが動く想定になりますので、そこからはその分が減っていくという計算になります。
弊社側からも高橋さんにお伺いしたいのですが、導入して失敗したなと思ったことはございますか？
高橋：
導入して失敗した点は特にないですね。もちろん運用に乗せるのは結構大変だと思いましたけれど、慣れてくれば、テストは成功していますし、失敗したなということはないですね。ただ、運用までいくのが大変だとは思います。
質問②
『自動化とは関係ないのですが、仕様の洗い出しについてお聞きしたいです。ざっくりとした仕様でつくられた部分が不安定で早期にテスト導入しないとまずいとなった場合に、急がば回れで仕様を固めてからテストをしたほうがいいのでしょうか？』
桑野
そうですね、ゲームのテストだとなかなか仕様が固まらないけどある程度機能ができたところからテストを走らせたりするじゃないですか。そういうことだと思うのですが、これはやはりケースバイケースでしょうか。ボルテージさんの場合はいかがですか？仕様が固まってからテストに入ることが多いですか？
高橋様：
いや、そんなこともないかもしれないですね。ある程度ざっくりした仕様がきてというのがほとんどのケースなので、そこからあらかじめテスト設計しだすこともあると思います。
大きな機能を作るとき、弊社だとアジャイル開発といいまして少しずつ少しずつ作っていくというのがありますので、ざっくりとした仕様の部分を、まずは大きな機能を作って少しテストして、だんだん雪だるま式に増やしていって、最後完璧なテストをするみたいな。テストをちょくちょく入れていくことはあると思います。
桑野：
ありがとうございます。仲さんにも伺いたいのですが、ゲームのテストの場合、がっちり仕様があって全部最初からテスト仕様書を作れてそのままきれいにいくってないと思うんですよ。やはり、できているところから触っていきましょうとなるので、いきなり全部テスト項目を作れるかというと、そうではないケースの方が多いですよね。
仲：
はい。今に近い相談を受けることもあって、仕様は決まっていないけれど時間は迫ってきているので、とりあえず根幹の部分、いわゆるシステムに関わる部分や、クライアントシステムに関わる部分は検証してほしいというのと、あわせて決まっていない部分を1回見て欲しいというお話が来るので。
弊社のテスターが通常のテスト以外にレビュー観点でテストも行うので、テスター目線でこういう仕様になっていたけどこうじゃない方がいいかもしれないという提案ベースの成果物も提出するような形もできるので、後ろのスケジュールに合わせて変わってくるかなと思います。
桑野：
なるほど。やはり状況に合わせて柔軟に対応できるようにはなっているということですよね。
仲：
そうですね。今の状態だとこういう状態でしたという報告と、それに対してのテスター側の所感みたいなものをつけて報告をして、後ろのスケジュールと合わせてどうするか決めていただくという提案はできるかと思います。
桑野：
ボルテージさんもそういう思想で、ソフトウェアテストのノウハウを用いてやられていますが、ソフトウェアテストのノウハウに忠実にやると、しっかり最初の仕様書があってそこからドキュメントを作ってそこから実行してというのが本来の流れじゃないですか。
それ通りにやっていると、いつまで経ってもできなくて、お客様から「ずっとテスト項目を作っているけどいつテストが始まるの」みたいなことを言われることも結構ありました。
この3年やらせていただく中でどんどん変わってきていて、試行錯誤して結構柔軟に対応できるようになってきたのかなというのを今の話を聞いて思いました。
質問③
『自動化の提案をエンジニアさんへ行う際、自動化の開発工数と削減効果が見合わなさそうで提案止まりになってしまうことがあるのですが、そういう場合もありますか。そういう場合はやはり開発を行うような結論になりますか』
桑野：
これは見極めが非常に難しいですよね。やってみないとわからないじゃないですか。高橋さんは撤退ラインって決めていたのでしょうか。
高橋様：
撤退ラインはある程度決めていました。ここまでいって削減できなくてコストに見合わなかったら、あくまで検証導入っていう形も、本導入に向けていくのは当然だったのですが、コストに見合うかどうかを判断するためにある程度スケジュールは見ていました。
桑野：
そうですよね。実際テスト自動化から入ると、やってみないと分からないので、コストをかけてやってダメだったら、それでできないという決断になってその会社では先に進まないということになったりするので、実は弊社はそういったことを防ぐために、最初に自動化を提案することはしないんですよね。普通にテストを依頼していただいて人力でやり、その中からテストできそうなことを試しに動かしてみて、いけそうだったら提案するというやり方をしています。割と弊社の中でコストを持つので、お客様からするとゼロは言い過ぎなのですが、通常のテストの人員分だけでおまけで自動化がついてくるという感覚でできるので、失敗しにくいやり方をしています。ハードルを下げているということですね。
やろうとしたけど、実際に難しくてできなかったこともありますよね、仲さん。
仲：
はい、恐らくそちらの方が多かったです。できてはいるのですが、お客様の求めるクオリティに達してないとか、思った以上にお客様側がもっとコスト削減を狙っていたとか、そういった意味で導入見送りとなったケースは結構多いですね。
桑野：
ありますよね、期待値が高過ぎてしまって合わない場合もあるし、コンテンツ自体がアクション性が高くて自動化に向いてない、そもそも人でやった方が早い場合もありますよね。
ですので弊社では、ずっと繰り返し長いことやっていて、人じゃなくてもいい部分をなるべく自動化にして、通常は人でやるということで、『人が主導してAIが補う』という言い方をしているんですけど、いきなりハードルを上げて『できませんでした』ではなく、じわじわ攻めていくというアプローチを普段はしています。
ご質問ありがとうございました。
では、最後に一言ずつお願いします。
仲：
今自動化のお話させていただいて、現状メインで対応できているのがスマートフォンアプリになっていまして、とはいえコンシューマーが徐々に元気になってきているので、そういった部分にも広げていきたいと思っています。近々恐らくSwitchに対応できるようになるのではないかと思います。そういった形でゲーム全般、ゆくゆくは自動化を自動で作れるみたいなところまでいけたら、もう少しいろいろなことができるのではないかと思っているので、これから先もそういった部分を追求していけたらと思っております。
桑野：
乞うご期待ですね。ありがとうございます。高橋さんも最後にお願いします。
高橋様：
今回の発表が、こういうところに自動化テスト入れられるという契機に少しでもなるといいなと思います。テスト自動化っていうのはどんどん広まっていくと思いますので、そのあたりもAIQVE ONEさんと一緒にいろいろなところに入れていけたらなと思っております。本日はありがとうございました。
桑野：
ありがとうございました。それでは高橋さん、長い時間お話いただいてありがとうございました。仲さんもありがとうございました。みなさんも今日聞いていただきありがとうございました。