↓↓↓ 現場レポートはこちら ↓↓↓

野本寿希也の感想まとめ

①   Game QA Evolution ～ゲームQAの現状と可能性～

ゲームQAの現状を整理しつつ未来のゲームQAの可能性について、事業会社、テストベンダーそれぞれの視点や知見から考えていくというセッションでした。

まず、〈ゲームQAの課題〉として以下が議論されました。

• 新しいことに挑戦できず、現在の方法に固執するメンバーが多いことや、新プロジェクト移行時の問題解決能力の不足があること

• 勉強不足や時間の制約により、コンテンツへの情熱やスキルのバランスにも課題がある。

• 個人のスキルに偏りが見られ、特定のテストや要望に特化している人もいる。

他方、テスト自動化の導入意欲は高く、プログラムのスキルがあれば導入は容易。

つづいて、〈ゲームQAの未来〉として取り上げられたのは以下のようなトピックです。

• テスト設計とプログラミングスキルを持つ人材が求められる。

• リモートワーク下ではコミュニケーションと問題追及が重要であり、生成AIテストやゲームエンジンの知識も重視される。

• 幅広い知識と柔軟な対応能力が求められる。

【感想】
ゲームQAを経験したことがなく、あまりお話を聞く機会もなかったのでとても新鮮でした。まずリモートワークの状況下では、ゲーム関連のQA育成にも含めて、いくつかの課題が存在すると感じました。

オフィスでの勤務では、常に周囲の状況を把握することで、ミスや間違いに素早く気づけるかもしれません。

しかし、リモートワークでは、ミスを確認する機会が限られるため、気づくことが難しい印象を受けました。ですので、お互いの理解度を確認するためにも、自ら質問することはもちろん、こちらから説明した内容を伝えた相手から再度説明してもらうことなどが重要だと感じました。

また、ゲームQAだけでなく、そのほかのQAでも求められるスキルが変わってきています。単にテストするだけでなく、プログラミングスキルを身につけることで、コードベースでどのようなテストが必要かを考えられ、テストケース数の削減にもつながるかもしれません。

②   UIからの自動テスト事例２選

E2Eテストの自動化に関する課題や取り組みが議論されました。

課題は「始める山」と「継続する山」として表現され、テスト自動化の導入や継続の難しさが指摘されました。テスト実装の早い段階から始めることが重要であり、テストのリファクタリングも重要です。さらに、テストはバグの発見ではなくフィードバックの取得に重点を置くべきだと言われています。具体的な課題や取り組み方についても紹介されました。

【感想】
このセッションでは、自動化テストの課題や取り組みについて考察する機会を得ました。自動化テストの導入にはスムーズなスタートや迅速な初期構築が重要であり、「自動化テストの山」と呼ばれる課題を乗り越える必要があります。

自動化テストは困難な面もありますが、これから弊社でも直面するであろう「導入から運用までの課題」の対応策を、事例を交えて紹介していただいたので、非常に勉強になりました。

③   サイボウズのQAエンジニア育成

オンボーディングの重要性が強調され、中途採用者へのオンボーディングの不十分さやオンライン環境での課題が指摘されました。

解決策として、半年のオンボーディング期間やリグレッションテストの実施などが提案されました。具体的な施策としては、質問アプリの導入やタスクのチケット化なども行われ、チームメンバーの成長と業務効率向上が図られています。入社時のオンボーディングが重要なプロセスであり、さまざまな取り組みが行われていることが示されました。

【感想】
現在、弊社のオンボーディングプロセスは十分な内容が欠けていると感じています。
このセッションで紹介されたスキルマップの作成やbacklogを活用した質問環境の構築は、弊社でも前向きに検討していきたいです。

これにより、新規参画者がスムーズに質問できる環境が整い、彼らのモチベーション向上につながることを期待します。入社された方の成長を促進し、チーム全体の効率を高めるために、これらの取り組みを積極的に推進していきたいと思います。

④組込み開発用テスト自動化環境」作製のウラ話　～はじめやすくて、つづけやすくて、ひろげやすい自動テストってなんだろう？～

組込み開発のテスト自動化における課題や今後についてのディスカッションでした。

そもそも組込み開発のテスト自動化は手作業が多く、時間と手間がかかることが話題になりました。また、自動化方法としてロボットアームや仮装ハードウエア動作模擬がありますが、導入コストが高いといった課題があるそうです。

テストケース作成や環境準備も難点ですが、スモールスタートで範囲を絞り、効果を確認することが重要とのこと。費用削減と早い結果が得られることが、スモールスタートのメリットだそうです。

また、学習コストの低いツールや操作のモジュール化も有効であることが示されました。

【感想】
他のセッションでも話題になりましたが、テスト自動化の導入ではスモールスタートが重要です。効果の確認や課題の洗い出しを目的にして、小さな範囲から始めることがおすすめされました。成功体験も得やすいため、実装した人のモチベーション向上にもつながると思います。

意外だったのは、属人化を重視する必要性です。一般的には属人化を避ける方向に進んでいますが、導入初期段階では個人が主導で進めたほうが動きやすく、知識も習得しやすいということが示唆されました。これは興味深い考え方だと感じました。

スモールスタートが成功した場合、その後のスケール拡大のためのポイントも明示されました。まずはどこまでテスト自動化を進めたいかを検討し、それに向けて次に取り組むべき箇所を決定することが重要とされました。

坂本唯子の感想まとめ

⑤組込み系システム版-失敗から学ぶ自動テストの設計プロセス

登壇者で『ソフトウエアテスト自動化の教科書 現場の失敗から学ぶ設計プロセスの』著者・林尚平さんによる、組込み系システムの自動テスト導入時における、設計プロセスについてのお話でした。
自動テストの導入は、ソフトウエアのテストでも最初はつまずくことが多いというイメージですが、組込み系システムへの導入となると特に難易度が高く、業務系と比べて成功例は多くないそうです。

実際に現場で起きた「組込み系特有の失敗」を踏まえて、どのように自動テスト導入を実現したかを細かく説明されていました。

【感想】
組込み系システムのQA経験はありませんが、テスト自動化に興味があり聴講しました。

事前にJaSSTのHPに記載されているセッション内容を拝見したものの、組込み系システムは理解が浅いため聴講する前は不安でしたが、登壇者の林さんは自動化について本を執筆されているほど経験が豊富だったため、実際のセッションは大変わかりやすく勉強になりました。

 失敗から得た「テスト自動化における注意点」の中で、印象深かったのは以下の２点です。

 ①自動化を導入・継続するために必要なコストはきちんとかける
テスト自動化を進めるにあたり、費用はもちろん、その実現には工数(人)がかかります。やみくもに進めず自動化テストについてきちんと理解している人を適切にアサインすることが大事なのだと感じました。

また、短い期間では期待している成果が見えにくいため、長い目で導入を進めなければいけないのだとも感じました。

②自動化できる機能だけ自動化をする
「自動化を導入すること」に精いっぱいになってしまい、肝心の「実際に自動化したい機能」がなかなか自動化できずに進んでしまった、という失敗談から得た注意点。

私自身も、過去、難しいことに挑戦した際、目標地までのプロセスが長かったために惰性に陥ってしまった経験があったので、このお話は非常にイメージがつきやすかったです。

まずは１番自動化したい機能を明確にし、そこに注力することが重要だと深く理解しました。

組込み系システムのお話とはいえ、ソフトウエアのテスト自動化でもつまずくことが予想される箇所は多くあり大変勉強になりました。

これからテスト自動化の導入に向けて、がぜんやる気になりました。

⑥三社三様のQAのカタチ

 事業会社・製品開発会社・テストベンダーによるパネルディスカッション。登壇したのは以下の３社です。

• 東急 URBAN HACKSさん

• サイボウズさん

• テクバンさん

 事業方針の異なる3社それぞれがQAチームや開発チームへのリソースへの向き合い方に対して、率直な意見を交換されていました。

具体的には、以下三つの議題を主軸としたディスカッションです。

• テスト実施時にバグを多発させない方法

• リソースの調整や採用について

• QA組織をこれからよくしていくためには

各社ならではの活動や悩みと、それらをどのように解決されているのかを具体的に話されており大変勉強になりました。

【感想】
講義の中で深く印象に残ったお話が二つありました。

１点目は「QAをこれからよくしていくために」という議題で東急 URBAN HACKSさんがおっしゃった「QAの理想卿をURBANに」といった言葉でした。日本では、QAエンジニアは開発エンジニアに比べまだまだなじみの薄い存在ということもあり、「QAといえば」と聞いて連想される有名企業はないように思えます。
そこで東急 URBAN HACKSさんは「QAの理想卿をURBANに」とおっしゃったわけですが、それを聞いた瞬間「自分も、『QAの理想卿はRIZAPに』と言いたい！」と思いました。 

QAエンジニア界隈もそうですが、RIZAPのQAもまだまだ発展途上の段階にあると認識しています。伸びしろしかない中で、このような言葉を聞けて大変活力になりました。

２点目はリソースの調整や採用についての議題の際に、やはり東急 URBAN HACKSさんが「新入社員（新卒）にはQAを希望する方が多数いる」とお話されていたこと。
これにはセッションに参加されていた方々も驚いた様子。もちろん私も驚きました。
日本ではまだQAエンジニアはメジャーな職種ではないと感じていたのですが、若い世代の人にはQAが浸透してきている、ということなのでしょう。

QAエンジニアとしてスキルアップする方法のみならず、「どうやったら、もっとQAエンジニアになりたい！という若者を増やせるか」といったことも考える、とてもよい機会になりました。

⑦サイボウズのQAエンジニア育成

 サイボウズの斉藤裕希さんによるセッション。
サイボウズに中途入社した際に斉藤さんが受けたオンボーディングの内容を赤裸々にお話されたほか、入社前に感じていた以下「三つの課題」をどのように改善されたか、またそれに伴い自身の気持ちがどのように変わっていったかをお話しくださいました。

三つの課題

• オンラインコミュニケーションを円滑に進めていくこと

• 自分(QA)の方が下？自信がないこと

• 二つの「苦手なこと」
  ┗ 人を頼ること
  ┗ ルールがしっかりと定まっていない仕事

【感想】
入社して数か月ではありますが、私も最近、ありがたいことに新規メンバーのオンボーディングを実施させていただく機会がありました。
受け入れが直近だったこともあり、セッション内容は共感を持って理解できましたし、「こうすればよかったのか！」という気づきもありました。

特に感銘を受けたのが「スキルマップと成長支援アプリの活用」についてのお話です。
サイボウズではmiro（オンラインホワイトボード）を使用し現在の業務内容に関するスキルレベルを表したスキルマップを作成し、不足する能力・技能について教育計画を立てていました。

また、成長支援アプリではその内容が具体的にチケット化されており、自分が次に何をできるようになればいいか、どのようにチームに貢献していけばいいのか等、自分の立ち位置が明確化されている様子でした。

 私も入社した当初は右も左もわからないことばかりで、QAの経験があってもどのようにチームに貢献していけばいいのか、明確にわかりませんでした。スキルマップによって自身の立ち位置が可視化され、なおかつ成長支援アプリによって自身ができるようになったことが視覚的にわかると、すごく自信につながるなと感じました。

われわれも、４月以降、新規メンバーが参画する際にさっそく取り入れてみたいと思いますし、その前にまず自身のスキルマップを作成したいと思いました。

⑧テスト管理ツールの向かう先

テスト管理に専用ツールを活用することでどのような価値が得られるかについて、さまざまな視点から情報を共有するディスカッションベースの講義でした。

 以下三つの議題に沿って登壇者がディスカッションを行っており、テスト管理ツール（※テストの進行状況を始めソフトウエアテストに関わる情報を一元的に管理するツール）を導入しようか悩んでいる身としては、大変勉強になる時間でした。

• テスト管理ツールが得意・苦手とする分野は？

• テスト管理の普及を阻むものとは？

• テスト管理ツールは今後どう進化していくべきか？ 

最後の議題では今できることだけではなく、「一歩先のテスト管理とは？」ということについても深掘りされ、各社さまざまな意見を聞けて興味深かったです。

【感想】
テスト管理ツールといえばExcelが多く使われている印象です。講義の中でも「あいつ」という名で多く出てきましたが、やはり手軽で誰でも使用できるという利点があります。終盤で実際に専用ツールを開発・提供している方が「あいつには勝てない・・・」と会話されるほど実用的で、テスト管理ツールとして根付いていると改めて感じました。

 ですが、「Excelでは不得意だけれど、テスト管理ツールなら得意なこと」もありました。

例えば、大規模のテスト実行の際に実行アサイン人数が多く、テストケースも1000件を超えてしまうケース。私も大規模なテスト実行に関わった際、テスト実行管理ツールではなくExcelを使用したことで、何度もファイルが落ちたり、ファイルが重すぎて開かなかったりといった大変な苦労をしました。
このとき、テスト専用管理ツールは実施用途を明確にした上で導入すれば、その利便性を100%引き出せることを実感しました。

 また、このセッションの中で個人的に１番驚いたのは、Shift社が提供しているテスト設計を行うための支援ツールがテスト管理ツールと連携できることでした。
そもそも、テスト設計支援ツールという存在を知らなかったのですが、デシジョンテーブルのパターン表を取り扱うことや、シナリオテストのパターンを作成し、実際に項目作成が簡単にできる仕様でした。

 テスト管理ツールを使用することで、テストの進展を始めさまざまな情報をシンプルに一元管理できるようになり、かつ、設計支援ツールと連携することで、テスト管理に関わる作業が効率化され、テストの負荷も大幅に軽減されるなと感じました。

（了）