最終更新日: 2023年6月19日
2023年3月17日、AIQVE ONE主催の品質管理をテーマにしたセミナーイベント、QA Tech Night v ol.8を開催いたしました。
今回は、グリー株式会社 QAグループ シニアマネージャー 堀米氏、株式会社ボトルキューブ 品質管理部 部長 鏡谷氏をお招きし、AIQVE ONEの花房、桑野を交え、「ゲームＱＡ人材の育成」をテーマにパネルディスカッションを行いました。後編となる本記事では、「QA人材のキャリアプラン設計」「QA関連の資格取得は必要？」などのテーマについてお話しいただいています。
前編はこちらをご覧ください。
【QA Tech Nightレポート】これからのゲームＱＡ人材の育成～パネルディスカッション～【前編】
登壇者
・堀米 賢（ほりごめ さとし）氏
グリー株式会社 Customer & Product Satisfaction部
QAグループ シニアマネージャー
・鏡谷 陽一（かがみたに よういち）氏
株式会社ボトルキューブ 開発統括本部 品質管理部 部長
・花房 輝鑑（はなふさ てるあき）
AIQVE ONE株式会社 人材開発部 部長
・桑野 範久（くわの のりひさ）
AIQVE ONE株式会社 セールス＆マーケティング部 部長
QA人材のキャリアプラン設計
AIQVE ONE株式会社 桑野：
今、マネージャー系やスペシャリスト系に行くという話は出てきたので、テスターさんという職種がどうしたらステップアップしていくのか、逆にどう広がってくのかというところを見ていきたいと思います。最初はテスターさんから始まり、リーダーさんになったり、テスト設計者になったり、マネージャー、テスト管理者などいろいろなキャリアプランがあると思います。グリーさんやボトルキューブさんは開発部隊があるので、プランナーになりたいという方もいらっしゃいますか。
グリー株式会社 堀米氏：
グリーには社内公募制度で、そういった募集をしているポジションをオープンにして、そこに誰でも応募できる仕組みがあるんです。それは上司を通さずに誰でもできるという側面があるので、それを利用して実際に異動される方もいますし、上司と相談した上で異動していく方もいらっしゃいます。でも、QA組織からですとあまりいないですね。
桑野：
では割とテストのところでのキャリアを積んでいこうという方のほうが多い印象なのでしょうか。
堀米氏：
そうですね。恐らく、プランナーの方が実際にどういうことをやっていて、そこでのキャリアの伸ばし方があまりピンと来ていない人もいるのではないかと思っています。仕様を作るとか、システムを入稿したりとかそういう一部の業務を見ている方は結構いると思うのですが、その先のキャリアイメージが急にプロデューサーとかになるので、そこに自分がなれるのかというイメージがしづらいのではないかと思います。
桑野：
プランナーさんやディレクターさん、プロデューサーさんとか、それぞれの仕事の中身を深掘りすると全然違うことをやっていたりするから、見えないって確かにあるかもしれないですね。鏡谷さんの組織ではいかがですか。
株式会社ボトルキューブ 鏡谷氏：
社内全体でキャリアチェンジは、多分グリーさんほど活発にはないと思いますが、QA組織からプランナーになりたいっていう人はいてもおかしくないのですが、何故かいないですね。確かに将来的にはプロデューサーみたいな人を目指したいという若い子がいたりはするのですが。それ以外は、エンジニアですね。たとえばフロントエンドをやっていた人が、バックエンドをやりたいとか、アプリの方をやりたいとかはあるのですが。
桑野：
逆にゲームのアウトソースベンダーだと、常駐先で仕事を振られて、気づいたらプランナーの仕事をしていてそのままプランナーになっちゃうなど、そういうジョブチェンの仕方は割とあるのかもしれないですね。
鏡谷氏：
ゲームのプログラムをやっていた頃は、アルバイトでテスターを雇って、その子がプランナーになってディレクターになるというのは普通にありましたね。今の職場の方が逆に特殊なのかもしれません。
桑野：
違う方向に行くというキャリアもあるから難しいなと思いつつ、そもそもエンジニアって、デバッガ―とかテストエンジニアとかQAエンジニアとか、いろいろな種類があってごちゃごちゃしていると思うんです。恐らく各社で定義が違うので、どこを目指すのかという話になったときに会話がずれたりするケースもあるのではないかと思います。
テスト自動化と言ったときに大体出てくる人が、テスト設計・テスト項目を作る人と、テストを手作業で実行する人、自動化の仕組みを考える人、その自動化のスクリプトを書く人、テスト自動化効率化のツールを作る開発者、それをディレクションする人かと思います。
テスト設計・テスト実行（赤の枠線）は品質管理部やテストチームの人ができますが、それ以外（黄緑の枠線）はQAエンジニアやエンジニアなどざっくりくくられていて、1人の人がやっていたりするのではないかと思います。そして、どこからアサインされるのかという問題があって、プログラマーさんやディレクターさんがツールを作った延長線で保守までやっていることも多いので、その人が忙しくなると全然保守が回らなくなって、自動化が捨てられていくという話をよく聞きました。
わかってきたのは、赤と青と、黄緑を全部分けようということです。役割を定義して分担したら、テスト設計と仕組みを考える人は一緒にやった方がよくて、実行する人がスクリプトを書いた方がよく、作る人はまた別がいいんです。ただ各社さん、作る人が優秀すぎて全部やらされるということが起きていて、進まないことをよく見ていたので、今うちでは開発する人と実際現場に落とし込む人とを完全に分けていて、どちらかというとテスターさんが自分でスクリプトを作れるようになっていくことを今は目指しています。
と考えたときに、このプログラムの方を目指すことはあるのかなという疑問が生まれました。グリーさんにも聞きたいのですが、自動化をやりますと言ってテストの方から来た人が、テストエンジニアなど作る側になることはありますか。
堀米氏：
まだ部分的ではありますが、一部のテストで自動化の実装をするケースがあります。主にマスタデータのように数が多く、手動でのテストだと大変なところで、スプレッドシートをベースにして自動チェックするようにしています。そこの実装はテストを実行しているアルバイトメンバーにお任せすることがあります。
やってみたいと声をあげるのは、専門学校でプログラミングを勉強してきたという方が多いと思います。
桑野：
なかなかここの青の人(テスト自動化or効率化のツールを作る人)っていないんですよね。開発側でたまたまやるって言った人が自然発生的に出てきているだけで、狙ってなかなか取れないなと思うのですが、鏡谷さんは元々エンジニアなのでやろうと思えばできちゃいますか。
鏡谷氏：
やろうと思えば、頑張ればできるかもしれないですね。
桑野：
でもゼロからキャリアを作っていくとなると、なかなか難しいですよね。
鏡谷氏：
品質管理部を立ち上げた頃に、自分自身もテスト自動化ツールを実際に触ってみてはいました。そのときは導入まで至らなかったのですが、その後やはりテスト自動化というのは一つのテーマだなと思って。実際そういうことができそうなエンジニアを採用したり、新卒を1人アサインしてもらって、今もやってくれています。青の、まさに効率化の方なのですが、自分は環境エンジニアという言い方をしています。実際の運用をしているゲームのマスタデータの投入の作業を効率化するとか、ガチャシミュレータを作るとかは、開発現場の方、エンジニアが作っちゃうんです。そこから漏れるというとやっぱりテスト側ではない環境側なので、最初考えていたのはCIやCDのツールだったのですが、実際その新卒くんには、たとえばAppleからのレビューのステータスが変わったらSlackに通知を出すツールや、YouTubeをパトロールして、違法にアップロードされた弊社のゲームの動画をリストアップするツールを作ってもらいました。最終的に判断するのは人間なのですが、簡単なAIを入れて登録した検索ワードに対して一気にURLリストを吐き出すことができるので、それを使って削除依頼をすることができるようになりました。他にもアカウントの棚卸のツールを作るなど、細かいことではありますが、あると便利で、人の手でやると半日かかりそうな作業を地味に潰していくということを環境エンジニアにやってもらっています。
桑野：
それを一人でやられているのですね。うちもテスト実行をただ自動化するだけではなく、その周辺の作業で結構無駄になっていることがあるという発想は実はあったりします。
実際にQAにまつわる職種って自動化もあればエンジニアも環境エンジニアもいろいろあるというのを鏡谷さんがまとめてくれたので、ご案内してもらっていいですか。
鏡谷氏：
はい。弊社の品質管理部の組織には、ほぼテスターなのですがエンジニアもいるので、エンジニアのキャリアパスを作っています。元々エンジニアは別組織なのですが、そちらはキャリアパスがマネジメントとスペシャリストに分かれています。途中から一緒になるのですが、それも少し意識しながら作ってみました。左側がテスター、あるいはテストオペレータと言い方があるらしいのですが、それがQAリーダーになると設計などのテストデザインがあって、そこからスペシャリストとマネージャーに分かれ、上の方は、世の中にはCQOという役職があるらしいのでそれをくっつけてみました。
派生のところは、QAアナリスト(テストアナリスト)というのはJSTQBのAdvanced Levelであったりとかして、少し違う方向からQAに攻め込んでいく人、あるいはPMという立場。今はQMOという言い方もあるらしいのですが、クオリティマネジメントの世界があるからこの辺をちょっと意識したり、エバンジェリストやアンバサダーという職種がQAの世界でも出てくることを想定してみたりという夢のある話が上にあります。エンジニアの方は基本的にはエンジニアのスペシャリストもエンジニアなので置いておく。そうではない道として、先ほどお話しした環境エンジニア、それかいわゆるSET、QAエンジニア。こちらもエンジニアとしてのアナリストもありますよね。そしてエンジニアとしてのPMというふうに上がっていくと、だんだんマネジメントに寄って最終的にはCTOになるのかなとか。また、セキュリティは全然違う道になるので線を分けています。
ただ、資料タイトルの上の方に「没」とあるのですが、これは完璧だ！と思ってメンバーに見せて説明したら、全員にキョトンとされたんです。なぜかというと、ここに今いるメンバーを1人も当てはめられなかったんです。QAリーダーぐらいまでは入ったのですが。
桑野：
あと実際にモデルケースがなかなかいない。
鏡谷氏：
そうですね。モデルケースがいないので全然想像がつかないということで人事に出す手前でお蔵入りしました。そして改めて、他社さんのQA組織のキャリアパスについて調べて面白いなと思ったのが、このQMファンネルというものです。
QA界隈では電気通信大学の西さんはかなり有名なのですが、この方が考えて、しかも毎年更新されており、やはり難しいんだなと思うのと同時に、3Dと書いてあるように、いろいろな側面からキャリアを考えていかなければならないのだと思いました。「QMファンネル」で探すと出てくると思いますので、そのあたりで悩んでいる方はぜひご覧になってください。
桑野：
先人たちはちゃんと考えているんですね。
鏡谷氏：
先人の知恵ってすごいですね。自分は5年ぐらいしかQAやってなくて、勝手に作ってからこれを見たので。
桑野：
「QAエンジニアとは」というテーマではいかがですか。
鏡谷氏：
このお話を伺ったときにQAエンジニアの話があったので、そもそもQAエンジニアって、皆さんどの領域のことを言っているのかなっていうのを考えました。言葉にするのが難しかったので図にしてみたのですが、実は自分が思っていたQAエンジニアって、Aのところだけだったんです。Aというのは、まず狭義のエンジニアという定義があります。これは、基本情報技術者試験に合格できる程度のスキルと知識を有するエンジニアです。テスターではなく、プログラムを書ける人でQA関係をやっている人だと思っていたのですが、人によってはこのテスター全体（C、D、E、F）がQAエンジニアだという方もいます。あとはC、D、EあたりをまとめてQAエンジニアという人が多い印象です。これ、Twitterとかでアンケートを取ってみたいくらい人によってバラバラだと思うんです。ちゃんと定義する必要はないのかもしれませんが、理解しないでQAエンジニアを語っているともう訳がわからなくて、「QAエンジニアのキャリアとは」といったときに、キャリアの話がそもそも曖昧なのに、QAエンジニアが曖昧だったらどうにもならない。
桑野：
おっしゃる通りです。ちょっとTwitterでアンケート取りたいですね。
鏡谷氏：
そもそも、完全に個人の見解なので、広義・狭義のエンジニアが違うじゃないかっていうツッコミもあればぜひ教えてほしいです。
桑野：
ちなみにグリーさんではQAエンジニアの定義はされているのでしょうか。
堀米氏：
もしかしたらこれはゲーム業界特有なのかもしれませんが、エンジニアって入るだけで、プログラマーっぽく扱われるという雰囲気があって、QAエンジニアというともうプログラムを書ける人なんですよね。CI環境を作ったり、自動化のコードを書けたり、そういう人を指す雰囲気があるので、うちだとQAエンジニアって本当にエンジニアリングができる人ということが多いです。なので、これだとAのところがまさにそうだと思います。
鏡谷さん：
そうですね。多分ゲーム業界はそうで、ほかの業界は違う。
桑野：
ちなみにゲーム業界以外では、テスターさんのこともテストエンジニアって言ったりしますよね。
堀米氏：
言っていますね。僕はそれだと思っていました。テストエンジニアって言ったら全員そうだと思っていたら、そうじゃないという雰囲気を出されて。自分はエンジニアじゃなかったんだみたいな。
桑野：
なるほど。ゲーム業界はデバッグっていう言い方をするからゲームデバッガーとかテスターになっちゃいますもんね。
鏡谷氏：
大元で言えばテストもエンジニア、プログラムを書ける人がやっていたので、余計その辺が曖昧になっているのかなと思います。
桑野：
花房さん、うちでも採用の出し方難しくないですか。
花房：
そうですね。エンジニアと書くと、今のお話みたいにプログラムのイメージがどうしてもついてくるので、やはり出し方は考えますね。それで出した方がいいのか、逆に出さないほうがいいのか。
桑野：
わかります。各社さん、採用のときもここで悩まれると思うのですが、エンジニアだって言いたい人もいれば、エンジニアとついた途端、逆に拒否ってしまう人もいる。他の業界ではテストエンジニアさんと言ってちゃんとキャリアもあって、そこそこお給料もあってという中で、ゲーム業界ではずっとアルバイトということも多く、辛いところがあるので、そこをいろいろ変えていきたいなと思っています。
JSTQB等QA関連の資格取得は必要？
桑野：
テスター、テストエンジニア、デバッガ―などいろいろな呼び方がある中で、資格を持っているというのは一つのステータスや指標となり、胸を張って言えるところもあると思います。実際にJSTQBを取った方が優位だったりしますか。
鏡谷氏：
人によると思っていて、実際社員の中でも取ってほしいメンバーと別に取らなくていいのではないかと思うメンバーがいます。
桑野：
それはどういう差なのでしょうか。
鏡谷氏：
まず、取らなくても全然問題なくできる人。確かに持っていた方が、それこそ転職には有利だと思いますが、いわゆるマネージャークラスまでできていて、知識もあって、この人すごいってみんなわかっている場合は必要ないと思いますね。
桑野：
資格としてなくても振る舞いでわかるからということですね。
鏡谷氏：
エンジニアも情報処理技術者試験を受けていない人はいるので、資格を持ってないとできないとはならないので、いらないと思います。逆に若手にはなるべく受けてもらうようにはしています。一つは、やっぱり箔がつく。それこそ評価もしやすいですし、自信になるということと、受験すると体系的にQAについて学べるので、感覚的なところが言語化されるんですね。自分も全然知らずに取ったのですが、そういうところをやってほしいなと思って受けさせています。ただAL（Advanced Level）となるとなかなか難しいですね。
桑野：
FL（Foundation Level）は関わる人は割と受けた方がいいですね。
鏡谷氏：
FLはテストに従事する人、それこそスペシャリストの方を志向する人であれば必ず取ってほしいですね。
桑野：
花房さんから見ていかがですか。
花房：
なくてもできるという見解は一緒なのですが、資格を取らなくても、FLの内容は理解していてほしいというのはありますね。何か困ったときなどによりどころになるので、これがあるだけでだいぶテスト活動に対して意識が変わってくるのではないかと思います。
桑野：
では、堀米さんの見解を。
堀米氏：
これは絶対必要だと思います。すみません、僕JSTQBの技術委員に入っていて、問題を作る側でもあるので、こういう発言をさせてもらったのですが。冗談抜きにして、結構ゲーム開発の現場って、独自の言葉を使っていたりするんです。それこそテストではなくデバッグと言っているところが結構多いですし、テスト仕様書っていうところもあればテストケースっていうところがあったり、項目書とかチェックリストとかいろいろな呼び方があるので、違いを知るきっかけとしてもいいのかなと思っています。自社がその呼び方をしている理由を考えることで、じゃあこうした方がいいのではないかという示唆に繋がるという意味で、スタンダードというのは絶対にあった方がいいと思っていて。テストのスタンダードがまさにJSTQBなので、そういう意味でうまく使っていただくといいのではないかと思っています。
桑野：
非常にわかりやすいですね。実際、何においても型を崩すのって基本ができてからと言うじゃないですか。定義とかも各社で違うし。でもこのスタンダードがあれば割と前提条件を合わせてお客さんと話せるので、先ほどのコミュニケーションの部分でも非常に役立つのではないかと思います。なので、ぜひ推進したいと思い、うちも社内での啓蒙活動をしています。
実際にどういうことできるかというシラバスが出ていたりするので、鏡谷さんに作っていただいたのですが、基本、あった方が合わせやすいですよね。
鏡谷氏：
そうですね。これはFLのビジネス成果を達成できる要件ですよね。FLに合格できる人はこれぐらいできないと駄目ですよっていうリストで、真ん中の濃い黄色になっているところには「テストケースを仕様書から作って実行して報告する」とあります。テスターってこれだけしかやってない人も多くないですか。
桑野：
下手するとテストケース実行しかしていない人もいますよ。
鏡谷氏：
でも求められているのはもっと広いということなんです。薄い黄色ぐらいはやっている人が多いのですが、白いところ、特に7番には「リソース計画、戦略、計画、プロジェクトコントロール、リスクマネジメントに対するテストマネジメントの原則を理解する」とあります。JSTQBの勉強をすることで、まずここまで知っていなきゃいけないということに気づくことができるというのが一番大きいと思います。「逆にこれしかできてないから、皆さん給料が低いんですよ」というのを、去年のJaSSTでぶちまけたんです。
桑野：
でも実際そうなのかもしれないですね。ゲーム業界が特に。私、2年ぐらい前にJSTQBをとったとき、改めて勉強してみて、これはテストの話だけではなく、開発とか、仕事をしていく上で絶対必要な要件が全部入っているので、普通にみんな勉強すればいいのにって思ったんですよ。まずは全体を把握するということが非常に大事だと思いました。キャリアプランの初期の第一歩としては結構いいのではないかと思います。
それでは、質疑応答に移りたいと思います。
質疑応答
アルバイトスタッフの興味を喚起し、定着させるには？
質問者さん①：
貴重なお話をいただきましてありがとうございました。以前、アルバイトテスターの教育の評価のプログラムを作っていたのですが、アルバイトの人たちの興味を喚起するのがすごく難しいという悩みがありました。結果、アルバイトの方たちがゲーム業界にあまり興味が湧かなくて辞められてしまうと、その人が獲得してきたノウハウが全部外に流れてしまうので、すごく勿体ないと思っていて、どうしたら定着してくれるのかを考えていました。私がやっていたことは、その人ととにかく仲良くして、たくさん話をするということでした。結局それはプロセスとして駄目で、継続的に、定量的にやっていくのはちょっと難しく、失敗した経験がありました。じゃあどうすればいいのかというのは全然答えが出ておらず、質問をさせていただきました。
堀米氏：
これはもう給料を上げるしかない。半分本当で半分冗談ですが、評価をしているということと、本人も納得感がある形で説明するというのを個々にやっていかないと離脱してしまうことが最初は多かったです。どういう評価システムがあって、どういうところを評価して、次にどういうところを目指そうかという次の話も含めてすることで、一緒に頑張ってくれる人が増えていったと思います。
桑野：
次のところまでボーナスもらってからやめようという人は半年延びますもんね。
堀米氏：
そうですね。実際それで頑張った場合には、給料にもちゃんとフィードバックさせることもできるので、双方にとって良いことだと思っています。
桑野：
なるほど。鏡谷さんはいかがですか。
鏡谷氏：
多分ゲームに興味をもってもらうのは無理だと思っていて。うちのメンバーでも別にゲームに興味ないけど、ゲームをテストしているメンバーはいるので、そういう意味ではアルバイトのレベルからですと、QAがいかに大事な仕事かというのをまず伝えて、自信を持ってもらうことが大事なのかなと思っています。そして、その中ではこういうことができればボーナスの評価を上げる、評価の方でちゃんと評価するということを伝える感じでしょうか。
桑野：
ありがとうございます。花房さん、アウトソースベンダーは若干違うのかもしれないですけど、同じようなことはあるのでしょうか。逆にお金ではない何かってありますか。
花房：
だいぶお金ではないでしょうか。あと個人的に感じているのは、アルバイトはここまでしか駄目で、ここから先は契約社員とか正社員でなければ駄目みたいな待遇の差が多いのかなと思っていて。そうするとモチベーションも持ちづらいというのはあるのかもしれません。なるべくアルバイトには、そこの差はなくすようにしていて、チームの正社員が出るような定例会議にもしっかり参加してもらって何かあれば意見してもらったりしています。
桑野：
確かにそれは一つあるかもしれないですね。情報をどこまで出すかなどの問題もあるとは思いますが、同じチームだという環境を作っていくことはモチベーションに繋がるのではないかと思います。
QAの知識や知見のシェアを促進する仕組みを作るには？
質問者さん②：
人材を育成していくにあたってスペシャリストを目指している人に特にありがちだと思うのですが、スーパーテスターとかスペシャルテスターって属人化してしまって、技術やナレッジがその人にしかたまっていないことが結構多いと感じています。皆様の組織の中で、ゲームQAの方々の持っている知識や知見を、どのようにアウトプットを促進しているか、そういう取り組みとかをもしされていたら、教えていただきたいです。結構みんな忙しくて、次のタスクを消化するばかりで、記事を書く時間などもなかなか作れないことが多いのですが、その中でどう時間を作ってナレッジをシェアしているのかという取り組みがもしあればご紹介いただきたいです。
堀米氏：
弊社ですと、そういった知識は共通化するために標準化プロジェクトのようなものを立ち上げていまして、現場で適用している技術をリストアップして、それは共通でやった方がいいのか、このプロダクト固有なのかというところを専門チームでリストアップしてチェックしていくという取り組みをしています。そこで挙がったものをマネージャー陣に上げて、いつまでに取り組むかを決めていくという形をとっています。新しいプロダクトの開発が始まるときには、そこまでに過去のプロジェクトの失敗例を改善しなければならないので、違う事業や領域だったとしても共通化した方がいいものはリストアップして対策を取るということも、組織のルールとして取り組んでいます。
桑野：
同じ失敗をまた繰り返さないために、マネージャークラスの人がちゃんとそういう時間を取っているということですね。鏡谷さんいかがですか。
鏡谷氏：
社内のエンジニアの取り組みとして、社内のドキュメントナレッジデータベースというものがありますので、結構専門的なテスト、たとえば課金部分のテストや広告のテストなど、前準備がややこしかったり、結果が複雑だったり、技術的な知識が必要なテストを行ったメンバーには、今後のためにそのデータベースに書いてもらうということはやっています。あとは、スペシャリストこそJSTQBをとってもらって、専門的な用語ではなく標準的な用語に置き換えて説明できるような訓練をしています。実際スペシャリストがいるのですが、JSTQBの勉強会の講師にもなってもらって、社内勉強会を開催しています。
桑野：
先生役をやってもらうというのは結構いいかもしれないですね。花房さんいかがですか。
花房：
弊社の場合はまだお二人のように体系だった取り組みはあまりできていないので、これから作っていく段階にはなりますが、何かドキュメントを作るときには、なるべくそれを皆でレビューしたり、揉んだりということはやるようにしています。その中で大事にしているのが、なぜそうしたのかというところをしっかりと確認するということです。思考の部分、何を考えてそこに行き着いたのかということを複数人で話し合うことで、知見の共有をしているというのが現状です。
本日のまとめ
桑野：
なるほど、ありがとうございます。最後に、皆さんから今日の感想など、一言ずつお願いします。
堀米氏：
今回桑野さんからこのお話をいただいたときに、人材の育成って考えると改めて難しいと思いました。弊社でもいろいろ考えてやっていますということを言いましたが、実際は結構手探りでやっていることの方が多くて、うまく伸ばせられないこともあれば、なぜか育っちゃう人もいたりとかして、どうしたらうまく育てられるのかということを考えるとても良いきっかけになりました。また各社さんのお話を聞いて、悩むところは一緒だという気持ちになれたので、また改めて今日の話を振り返って、自社でどう活かしていくかを考えてみたいと思います。
鏡谷氏：
弊社はまだまだ小さい組織ですので、これから組織としても大きくしていくにあたって、特に新卒や若手の採用が必要になってくると考えたときに、今はQA志望で入ってくる人はレアだと思いますので、特に新卒の子が希望を出してもらうにはどうすればいいのか、最近悩み始めていました。今後もQA業界の様々な人たちと話をしながら、若い人たちがQAに夢を持ってもらえるようなことが将来できたらいいなと思いながら、やっていきたいと思っています。
花房：
今年に入ってから、全社的に教育の再構築に取り組んでいるのですが、メンバーにはしっかりとキャリアを順々に積んでいけるような環境を会社で整えていきたいと思っています。このロールになるには、このロールでやっていくためにはどういうスキルが必要で、テストのスキルやヒューマンスキルの定義をして、それをどういうスパンで学んでいけばいいのか、どういう研修を提供すればいいのかというところをしっかり構築していきたいと思います。まだまだできていないのですが、縁があって弊社に入社してくれたメンバーには、それをしっかりと使ってもらって、ゲームQAの世界でキャリアを積んでいけるような環境が作れたらと思っています。
桑野：
ありがとうございます。今日聞いていただいている方々も、いろいろな課題がありつつも、悩みながらいろいろ取り組んでいらっしゃると思いますが、今日のお話が少しでも参考になりましたら幸いです。
本日ご登壇いただいた3名の方、本当にありがとうございました。