最終更新日: 2021年12月3日

2021年8月に行われたCEDEC2021にて、弊社技術支援部 部長の花房が登壇いたしました。『ゲーム業界でテスト従事者としてキャリアを築いていくための組織的な教育』と題した講演内容をお届けいたします。

ゲーム業界でテスト従事者としてキャリアを築いていくための組織的な教育

このセッションでは、ゲーム業界で、テスト従事者としてキャリアを築いていくための組織的な教育として、弊社の教育に関する取り組みをいくつかご紹介したいと思っています。

自己紹介

まずは自己紹介をさせていただきます。

AIQVE ONEの花房と申します。よろしくお願いいたします。
スライドにもありますが、コンシューマーゲームやスマホゲームなどのゲーム系のテスト、Web系(サイトやシステム系などの非ゲーム系)のテストを、だいたい半々くらいで経験しています。テストはK社から始めたのですが、これまでにテスターからテストマネージャーまでだいたい一通りの役割は経験してきました。2019年にAIQVE ONEの前身の会社に入社し、今は技術支援部という部署で、テスト設計やテスト自動化、TRCといったガイドラインなどの技術的な支援活動を行っています。また、次世代ゲームテスト研究所という技術ブログの監修もしております。

※保有資格については、JSTQB FL(Foundation level)とIVECハイレベル5に加え、今年(2021年)8月にはJSTQB AL(Advanced level)TMにも合格

会社紹介

次に、弊社の紹介をさせていただきます。

AIQVE ONEは、2021年2月にmonoAI technology(モノアイテクノロジー)という会社から事業分割して誕生した会社ですが、そのためQA事業の活動年数と会社自体の活動年数に少し乖離が出ています。QA事業は通算すると3年が経過したところです。
社員数が今150人強くらいいるのですが、アルバイトはほぼいなくて9割方が契約社員以上となっています。事業はQA事業、一般的に言う第三者検証会社となります。ソフトウェアテストの知識や技術を軸としてテスト活動を行ってはいるのですが、あわせて先端技術を活用し、人力のテストをいかに効率化するかというところにもチャレンジしています。去年、一昨年のCEDECで、弊社の取締役の本城が、「AIにゲームをデバッグさせることはできるのか?」という講演をしているのですが、こういった取り組みがその一つになっています。

本日お話しする内容ですが、こちらになります。

・はじめに
・取り組み1 ソフトウェアテストの学習
・取り組み2 テスト計画=スケジュールからの脱却
・取り組み3 チェックリスト作成からテスト設計へ
・取り組み4 テスト自動化の理解・実践
・さいごに

本日は、弊社のテストスキルに関する教育の取り組みを4つご紹介したいと思っています。2つ目の取り組みであるテスト計画の部分については、リーダー向けにはなるのですが、それ以外の取り組みに関しては、テスターからすべて対象となるようなものになっています。

弊社の教育に対する思い

はじめに、弊社の教育に対する思いを簡単にお話しさせていただきます。ゲーム業界では、テストのことをゲームデバッグと呼んでいますが、このゲームデバッグの特徴は、ご覧のようであると考えています。

テストや品質に関する体系的な知識に乏しくて、人海戦術であるとか属人的な側面が強くて、ゲームができたらとりあえず動かしてバグが出るか出ないかを確認するようなやり方ですね。主にフリーテストの形で行われることが多く、そのためメトリクスの収集であるとか、品質の可視化が難しく、その活動の効果が見えづらいと感じています。また、バグを探す活動に特化しているため、品質への貢献には限界があると考えていて、テストに関する知識や技術面も決して高いとは言えないため、ゲームデバッグのやり方では、待遇面やキャリアの面でも限界があると考えています。

そのゲームデバッグですが、属人志向であり、アサインされる人員によってテスト内容やその結果が大きく左右されるため、さながらガチャのようにも考えられるかなと思っています。たとえばレア度がSSRのような希少ないい人がアサインされた場合は、テストが楽に問題なく進んで、逆にレア度がノーマルみたいな人がアサインされた場合は、仮にテストのやり方や進め方を工夫しても、なかなかうまく進まないといった感じです。
組織的にも現場的にも教育といったものがほとんど行われず、その人自身の素質と経験値でやっているような形のため、このようにガチャのようにもたとえられるのかなと思っています。本来、テストは専門性の高いものだと思うのですが、これでは専門性が高いことを示せないのではないかと思っていて、専門性を示すには、知識や技術などが必要であると考えています。

弊社では、ソフトウェアテストの体系的な知識や技術、考え方をもとにテスト活動を行っています。

これは、さきほどのゲームデバッグとは逆の性質を持っていると考えていて、そもそものテストの計画であるとか、テストの戦略を考えるところから始まっていきます。テスト実行にあたっても、テスト技法を活用してテストケースを作成したり、テストの活動中も、メトリクスを収集して、品質の可視化と分析を行っていきます。経験であるとか直感といった曖昧であやふやなものに頼るのではなく、体系的な知識やデータを活用して、根拠をもってテスト活動を行っていくような形です。

ゲームデバッグの特性上、雇用形態はアルバイトが多く、時給も最低時給に近いことが多い印象です。リーダーになれば時給も上がると思いますが、社員化できずにアルバイトのままであるケースも多いのかなと思います。アルバイトから社員への登用も極端に少ないと考えていて、そのため、結婚や出産といったライフステージの変化によって、続けたくても辞めざるを得ないような状況になってしまうことが多いのではないかと考えています。

しかし弊社では、「ソフトウェアテスト」というテストの専門的な知識を身に着けてもらうことで、知識に裏打ちされた技術力をさらに身に着けて、待遇面のギャップであるとか、キャリアアップの後押しをしていきたいと考えております。

取り組み1 ソフトウェアテストの学習

それでは取り組みの紹介に移りたいと思います。まず一つ目は、ソフトウェアテストの学習についてです。
テスト対象がゲームであるので、テストのポイントもゲームという部分に着目してしまいがちではありますが、ゲームソフト自体はあくまでもソフトウェアの一つとして捉えることができます。そのため、大前提として、ソフトウェアに関するテストの知識や技術が不可欠だと考えていて、弊社ではこのソフトウェアテストのレベルを上げるための活動をしています。

弊社では新入社員に対して入社時に1週間程度の研修を行っているのですが、その中でソフトウェアテストについての研修も行っています。この入社時の研修の中では、ソフトウェアテストの考え方であるとか、テストの目的とか、テストの7原則といった基本的な部分を教えるようにしています。テストはバグを検出してそれを修正することによって品質を上げるという活動のイメージが強いのですが、それ以外にもテスト活動で得られるいろいろな情報から品質レベルの確認をするなど、そもそもバグを生み出さないようにするための活動も重要ですよ、ということも教えています。

ソフトウェアテストの学習方法の一つとして、社内の勉強会を開催していて、これはJSTQBを取得したメンバーが講師となって、その知識を社内に拡散していくような形ですね。実際に教える側に立つことによって、自身の理解がより深まったりするので、教える側も教わる側も両面での学習効果が期待できると考えています。JSTQBのFL(Foundation Level)のシラバスが6章仕立てになっているので、その章ごとに担当者を決めて、勉強会もその章ごとに分けて開催する形をとっています。この勉強会は、ASTERという団体が公開している「ASTERセミナー標準テキスト」というのを資料のベースにしていて、その資料を講師自身が内容を改変して勉強会で活用しています。この資料が、結構小難しい書き方というか、わからない人にはわからない表現が多いので、そういった表現を改変し、伝わりやすい表現であるとか、理解しやすい文章に変えたりとか、噛み砕くような形に改変しています。

また弊社では、2週間に1度、5問の小テストを行っています。これもJSTQBのFLのシラバスを対象としていて、シラバスの章ごとに小テストの開催をしています。つまり3か月に1サイクルまわるような形ですね。小テスト自体は、このテストスキルの部分以外に、ビジネススキルやセキュリティといった軸でも行っているので、このテストスキルに関しては、今2サイクル目が終わったところですね。1サイクル目と2サイクル目の平均得点はこのような形にはなっているのですが、2サイクル目の平均は全体的に約10%程度の得点アップになっていて、これらの勉強会や小テストの取り組みを通して、ソフトウェアテストの理解が進んできていることがあらわれていると考えています。ちなみにこの小テストの得点は社内で公開されていて、一定回数連続で満点をとったらちょっとしたご褒美もあります。

また、このJSTQBの試験自体ですが、2021年2月の試験では、弊社は13人受けて、8人合格しています。合格率でみると、61.5%ですね。率だけ見るとまずまずといったところですが、そもそも弊社は、テスト未経験者の採用割合がだいたい約90%くらいなんですね。またそれに近しい割合でIT系の仕事が初めてという人がいるので、そういった事情を踏まえると、成長スピードは結構速いと感じています。8月の試験では、14人受験をしていて、今回も前回と同じくらいの合格率になるのかなと見込んでいます。(※)今回合格したメンバーがまたソフトウェアテスト勉強会の講師を行って、また知識を拡散して、合格者が増えていく、そういったサイクルがまわっていくといいかなと考えています。

(※)追記:2021年8月のJSTQB試験の結果は、下記のとおりとなり、全体の合格率である69.0%を上回りました。
 
受験者:12人
合格者:9人
合格率:75%

~フリーテストとソフトウェアテストではどちらが良いのか~

これは余談になるのですが、以前から気になっていた部分で、ゲームのテストでは、フリーテストの割合が結構多いと感じていて、極端な話では、フリーテストしかしていない組織もあると思います。しかし実際のところその効果はどうなのかということが気になっていて、今回、フリーテストのみのテスト活動と、ソフトウェアテストでのテスト活動を分析してみました。

本日は結論だけになってしまうのですが、ソフトウェアテスト活動では、フリーテストのみよりも、約20%の工数の効率化が見込まれるということがわかりました。今回は、フリーテストの実績から検出された900件というバグ数をもとに、このバグをソフトウェアテストの活動で検出するにはどのくらいの工数がかかるのか、という試算を行いました。この900件のバグを分析していくと、その85%はテストケースの活用で拾える内容のバグで、残りの15%のバグをフリーテストで検出していくような形ですね。そのシミュレーションをしたところ、約20%の工数の効率化が可能という結果になりました。テストケースを作成することによって、テスト内容やテスト結果が可視化でき、テストの自動化にもつながりやすくなったりするので、こういった要件ベースでのテストの有効性は高いと考えています。また、フリーテストという対照的なテストのやり方ですね、これはそれ単体だけを行うよりも、何かを補完するような形で行う方が効果的と考えていて、テストケースの消化が終わったあとに、強化テストという位置付けで実施するのが効果的であると考えています。

取り組み2:テスト計画=スケジュールからの脱却

次に2つ目の取り組みになるのですが、テスト計画についてです。
テスト計画といっても、実際にはその内容を見てみるとテストスケジュールしかないということが結構多く、テスト計画というものの、その体を成していないというケースも結構見てきました。テストスケジュール自体もテスト計画の一つの要素であると考えているのですが、それ以外にも、テスト活動をする上で必要な要素は他にもあると考えています。

そもそもテスト計画とは何かというところですが、テストの目的や戦略、それ以外にもテスト活動に必要な要素を洗い出して、方針をまとめたものです。何をするのかゴールを定めて、そのゴールに進むための道筋や手段を考えて整理しておくといったことですね。このテスト計画がしっかりしていないと、行き当たりばったりのテストの運営になってしまって、トラブルの絶えないプロジェクトになってしまいます。テスト計画では、具体的にこのような要素を考慮したり検討したりする必要があるので、研修の中でもこれらの要素のことを教えています。たとえばテストアイテムであれば、対象のソフトウェア、ゲームにはどのような機能が実装されているのかを整理して、その全体像を把握した上で、テストの対象範囲はどこか、非対象の範囲はどこか、そういったことを明確にしていきます。あとはテスト計画の中で、リスクの部分も識別をしていきます。どういったリスクが想定されるのか、そのリスクを回避、軽減するためにはどういった活動をしていくのかというところの方針を立てて、備えておく形ですね。それが、リスクが現実化したときの影響を最小限にとどめるというところにつながってきます。

何かが起きてから対処するのではなく、何が起きるかを事前に想定して対策を講じておくことが非常に重要となってきて、プロジェクトの成否にも大きく関わってくると考えています。テスト計画の内容を理解した後は、ケーススタディを通して実践をしていく形をとっています。

これは一例です。この例だと、仮想空間プラットフォームの新規開発で、システムテストのテスト計画を作成してみましょう、というものですね。こういった形でなるべく実案件に近いシチュエーションを作って、状況に合わせたテスト計画の作成を実践していくことで、実務力の向上を狙っています。

【関連記事】テスト計画書とは?目的や要件をわかりやすく解説します

取り組み3:チェックリスト作成からテスト設計への進化

次がテスト設計についてです。
ゲーム業界でのテスト設計の成果物なのですが、中身を見てみると、チェックリストと呼べるような内容であることが多い印象です。適切なテスト設計ができていないことが多いと感じているのですが、意図してこの粒度でやっているのであれば問題ないのですが、そうでないケースのほうが圧倒的に多いとも感じています。そのテスト設計のやり方についても、仕様書をコピペして作成するようなCPM法と呼ばれる手法で作成されていることが多い印象で、仕様書からコピペして作成されてくるため、テスト分析はされていず、テスト観点や組み合わせなどの検討といったこともあまり行われていません。

このようにテスト内容が検討されていないので、テストすべき機能や観点が漏れてしまっていて、バグが市場流出する可能性につながってしまいます。これを防ぐために、フリーテストを行っていくと思うのですが、そもそもフリーテストでは、どこをどれだけやったかとか、品質レベルの可視化自体が難しく、また必要以上に工数を使ってしまうといった問題もあるのかなと思っています。そもそもフリーテストで補完するということが、根本的な解決にはなっていないのではないかと思います。

弊社のテスト設計ですが、テスト分析、テスト設計、テスト実装と、一般的なテスト設計の形で行っています。ただテスター視点でみると、このテスト設計というのが何をするのか想像がつかず未知のものになっていて、チャレンジするにあたっての心理的ハードルが高くなってしまっている傾向があります。この3つの工程で具体的に何をするのかわからず不安になってしまうので、それぞれどういったことをするのか具体的に見えるようにして、具体的な手順の説明から始めています。

たとえばテスト分析であれば、最初にプロジェクトの概要や背景、テストの目的などの把握を行っていくのですが、ここではテスト計画書の内容確認であるとか、テストリーダーへのヒアリングなどを行って、プロジェクトの状況や目的を把握するように伝えています。

テスト設計で一番気を付けている点は、機能ベースで考えていくということですね。画面UIに着目して考えていくと、どうしても目に見える範囲でしか考えられなくなってしまうので、機能に着目して考えていくということを教えています。

テスト設計の演習のレベルですが、このような形で上げていくようにしています。なるべく簡単な機能からしっかりとした成果物を作成できるようにしていって、成果物のクオリティが上がっていったら、より複雑な機能にチャレンジしていく形ですね。まずはチェックリストレベルの作成から入って、テストケースを作ること自体に慣れることから始めています。
ある程度慣れてきたあと、テスト設計レベルで、一連のテスト設計の作業を体験していく形になります。そこでマインドマップなどを活用して、テスト対象の機能構造を整理したり、テスト観点や組みや合わせなどの検討を行い、そのあと具体的なテストの手順や期待結果を作っていくというところですね。そういった経験を積んでいってもらっています。

こちらは弊社で実際に行っている研修の内容の一部になりますが、その中で、ソフトウェアテスト技法練習帳という書籍も活用してテスト技法の研修も行っています。弊社では初めてテスト設計にチャレンジする人には、2週間程度のテスト設計の研修を行っていて、その中でテスト設計の基礎的な部分を教えています。ある程度慣れてきたら、いろいろな課題を通して実務力を上げるという取り組みをしています。

【関連記事】はじめてのテスト設計入門

取り組み4:テスト自動化の理解・実践

最後の取り組みは、テスト自動化です。

弊社はテスト設計の他に、テスト自動化も重要視していて、テスト設計で最適なテストケースを作成して、それを手動もしくは自動でテスト実行していきます。オートテスターという弊社独自の自動化ツールをテスト実行に活用してはいるのですが、これはコード記述でのスクリプトの他に、ビジュアルスクリプトというものが可能な点が特徴になっています。テスト自動化の教育では、まずはテスト自動化の概要ですね、その学習をしてもらっています。その中でテスト自動化の8原則というものも活用しています。テスト自動化については、結構夢を見る人も多いのですが、短期間で効果が出るものでもなく、テストのすべてを自動化することもできないので、まずはテスト自動化の現実を知るところから始めています。

テスト自動化の教育ですが、流れとしてはご覧の形になっています。まずは自動化に関する知識を身に着けて、そのあとはテスト自動化するにあたってのシナリオであるとか、フローチャートの作成を学んでいきます。そのあとはビジュアルスクリプトを組んで実際にテスト自動化を実現していくという形ですね。ビジュアルスクリプトのあとは、一段階上のところで、Pythonを使ったコード記述のスクリプトを体験していくという形になります。

こちらはテスト自動化の課題の一例ではあるのですが、どういう自動化をするのかというお題を出されて、あとは個人で試行錯誤をしてスクリプトを作って自動化の実現をしていくという形ですね。こういった取り組みをしていく中で、テスターがテスト実行の中で自律的にテスト自動化を行える体制の構築を目指しています。

【関連記事】<初心者向け>テストの自動化の基本について知ろう

今後の取り組み

今後の取り組みについて簡単にお話したいと思っています。

弊社の教育は、ご覧の3つの軸をのばすような研修を行っていて、本日お話ししたテストスキルの部分以外に、ビジネススキル、ドメインスキルの軸でも研修を行うようにしています。
ドメインスキルは、ゲームそのものや、ゲーム開発、テスト対象自体やそれに関係するものの周辺的な知識ですね。キャリアアップにはこの3つの軸の向上が必要と考えていて、ビジネススキルとドメインスキルの教育を強化していきたいと考えています。テストスキルの部分に関しては、テストのモデリングを取り入れて、テスト技術の向上をはかったり、ゲーム開発を通して、単体テストや結合テストの理解も深めたいと考えています。さらにTRCといったガイドラインに関する部分の教育も考えていて、ガイドラインチェック項目の中には、たとえば解像度ごとの確認であるとか、トロフィーの全取得であるとか、ゲーム全体を通して確認が必要なものもありますので、これらをテスターが理解した上でテストを行うことで、リジェクトされる可能性を軽減し、予定通りのリリースに繋がるのではないかと考えています。

以上で本日の講演を終了いたします。ご視聴ありがとうございました。