TestonoBlog

Softwaretest,QA

【CEDEC2019】配信視聴レポ1:ゲームの開発/運営に必要なQAとは

こんにちは、とのの(@tonono2587)です。
CEDECの配信を視聴したので、そのメモと感想です!

今回のテーマ:ゲームの開発/運営に必要なQAとは ~ QAの本質・課題・未来について語る ~

セッション概要と詳細

cedec.cesa.or.jp

Greeさん、KLabさん、ミクシィさんの3社パネルディスカッションでした。
各社のQAとしての取り組み事例、開発との関わり方、QA人材の確保について、今後のQAについて、質問
などをトピックとして挙げられていました。

タグ:”#CEDEC2019qa”

メモ

(書きなぐってます)

各社QAの取り組み事例

■グリーさん

表示に特化した検証の導入
(不当表示リスク の観点でチェックをするチームを用意)

■KLabさん

ロボットアームでの検証

  • テクノプロ社 Finger1をつかっている
  • デグレ発見用

ミクシィさん

観点・機材・ツールの一元化

  • テスト実施の効率化
  • マトリクス型組織の構築化

QAチームとの正しい付き合い方は?

網羅的で効率的なテストをする必要があるが、                     
QAが関与するのはいつから??                       

ミクシィさん

運用が長いタイトルだと、「次のバージョンでこれを入れたい」といった仕様段階のレビューから参加

新規事業まわりは半年前とか、数日前などバラバラ

■グリーさん

仕様変更の大きさによる

新機能追加など、大きい場合は半年などの企画段階から参加することが多い

■KLabさん

小さく開発するのを繰り返していて、いけるとなったら実装が決まっていくような開発サイクル(意訳です。。)

■各社さん運用フェーズのテストだと?

  • イベント前はデータを流す2〜1日前というときもある
  • 1日余裕をもって終わらせる感覚
  • 「1週間前には終わってほしい」と言っているのは厳しいのかな?
  • QAインはすべてがFIXしているときから

    →新規はなるべく早く参加したい

    →最後の設定値まわりの確認はギリギリまでするしかない
  • ギリギリまでになってしまうが、そこでまだバグが出るけどどうする。。(課題)
  • 企画段階から品管が関与するのがいい
  • 企画を聞いた上で、デバッグ機能の開発の提案もできるので

開発とQAの情報連携

  • 準備段階でできるだけ情報をもらうほうがいい
  • もらわないと、その場限りの状況に合わせたテストになってしまう
  • キャラ1体追加するにもデッキを組んだり、いろんな準備が。。
  • 新機能については、必要なデバッグツールについて検討するためには手慣れたテスターさんからの情報も参考になるので、はやくから参加する
  • 運用後のQA活動については?

    →同じ不具合の再発防止

    そのためのチケット管理:「修正しました」だとわからないのでQA側からも聞くようにしている

QA人材確保の実情

■他業界からゲーム業界へ来たときのギャップ

  • デバッガー/テスターの価値観が低い
  • テスターさんの外注など、単価が低い
  • 自己投資できないからスキルが上がらない
  • 安すぎるのが原因なのでは?
  • 「ゲーム」は興味をもたれやすく、入りやすい

    ということは人が多いから、引っ張りだこすぎてみつからないんじゃないか

    →未経験でも参加してもらって、成長の促進とそれにみあった報酬にしていくように

■技術体系がないのでは?

  • 雇用側も測りづらいところがあるのでは
  • テスト管理もできて、テスト設計もできて、ゲームに精通しているひと、揃った人がなかなかいない

■みなさんはなぜゲームQAなんですか?

 - ゲーム大好きだから、そこに関わりたい
 - エンタメは楽しい
 - 組み込み系のときはコスト削減が激しく、海外へ技術融資などをした体験もあるが、それよりも日本に!
 - テスト専門会社だったら入れたから笑
→そこから、テスト業界がおもしろかったから続いた
ソフトウェアテストの経験を生かして、ゲーム業界で活かせることがあるんじゃないか
 - ゲームはテスト観点からみても非常に複雑  - 決まった内容をやるだけじゃなくて思いついたことをやって、問題をさがす

■今後のモバイルゲームQAのあり方

□QAのスキル例

|QAの対象 |人やプロセス |コードやデータ |ゲームサービス | |---|---|---|---| |アクション |タスク管理、プロセス改善 |システムテスト、シナリオテスト |ユーザーテスト、障害管理 | |スキル |PJマネジメント、スクラムマスタ |テスト設計/管理、ペルソナ分析 |官能評価設計、リスク管理 | |知識 |タスク管理、プロセス改善 |JSTQBマーケティング |消費者心理、法令/ガイドライン | (やることいっぱい。。!!)

  • さすがにこれをすべて網羅している人はなかなかいない
  • チームで動くことがほとんどなので、その中でバランスをとって配置していく
  • それをどうやって見出すか→1on1をやって、どこを伸ばしたらいいのかなど相談
  • 自己分析などで測りつつ
  • 早期開発から関わるとなると、QAとして開発や偉い人と対等に、自信を持ってお付き合いしていくコミュ力もいる
  • QA側からヒアリングしに行くようにしている
  • 週一くらいで雑談含むミーティングによって仲良くしたり、プロダクトへの想いを聞いたりする
  • 急に仕事としてぶつかり合うとなかなかうまく行かないことが多い
  • 「同じ釜の飯」作戦はけっこういい
  • シャッフルランチ:ボットがシャッフルしてランチに行く とかも試したりしてます
  • 多少無理やりでも話すきっかけをつくる

質問:どのような教育的な取り組みをしているか

■グリーさん

  • ランチ時間をつかってベテランさんからの勉強会
  • 休日をつかってテスト設計合宿
  • 知識をふやしていく、手を動かす体験、経験をつむ
  • 平日は自分の時間がなかなか持てないから、あえて休日に集中して勉強会
  • 集中して設けて、あとはがんばって。。というやり方をした

ミクシィ

  • レビューに特徴があるかもしれない
  • 「全員」レビューをする
  • 1人2人は必須でレビューし、ドキュメントをチーム内でなるべく全員が見るようにする
  • 全員が共有している場でフィードバックする
  • QA経験がない人もいるので、公開の場でフィードバックしてもらうことで勉強になる

■KLabさん

  • 先にスキルマップなどを見せる、目指すものや必要なものを自分で把握してもらう
  • ゲーム以外でのテスト業界での交流
  • 武者修行的

今後のQAのあり方

- 関連部署へは自分たちから発信すべき                       
- それを聞いた別チームとの相互作用                      
- プロダクトへの愛があるほど強いチームになれるのでは                       

- 業界の成長スピードは早い                      
- 各セクションの人々がプロとして機能しないといけない                       
    →自信がないならスキルをつけて、対等に話せるようにならないといけない                  
- QAもプロとしてプロジェクトに参加                       
- 「バグ出し」だけを切り離して考えるのは危険な業界である(観点的にも複雑だし)                        
- 品管を、テストの部門として捉えるのではなく、品質をマネジメントしてくれるチームとして接していただけるといいかも                     
- その上で、プロジェクト内でどこに有効活用できるチームとしてQAを捉えていただくか                      
- 「はやく関わりたい」のが本音                    
- 熱量を感じたい、QAも同じ熱量をもって製品をつくりあげたい                   
    →そのくらいの企画をもってきてもらいたい!                 

- プロダクトに入り込める一方で、横断的にみれる組織でもあるのがQAの強みでは                       
- プロジェクトごとに存在する文化を尊重しつつ、データの基準をあわせておけば横同士の比較はできる                        
    →ツールをあわせるのではなく、取れる数字を共通させておく。数値の持つ意味を共通化させる                                               
- こういう便利なものもありますという提案もできる                     
- 振り返り系、再発防止系は強めに提案する                     

■多言語対応について、表記のテストはどのようにやっていますか?
→多言語専用チームを構える
→LQA ローカライズQAがいます

■テスト手法を勉強する機会は多くても、テスト開発プロセスを学ぶ機会は少なく、会社特化のものを学ばないといけないことはモチベ低下につながるのでは?
- 社内特化のやり方はしないようにしている
- なるべく業界標準のものを取り入れる

まとめと感想

ツールを無理に統一化しない、というのはとても納得しました。
ツールを統一化するのを目的にするのではなく、扱う内容をあわせる方向で進めると
その先も合わせやすくなっていくんだなと思いました。
そのときに、なるべく業界標準の用語や考え方を使うといろんなコストが低くて済みそうです。。
また、「品質をマネジメントしてくれるチームとして捉えてもらう」
という考え方はヒントになりそうでした。
「バグを出す」という捉え方をされたままでは開発の早期からプロジェクトへ参加することは難しいままではないかと思いました。
いまのQAとしての自分の立場が低いとは思っていませんが、
早期から呼んではもらえないポジションにはいるかもなと思っているので
今回のディスカッション内容も参考に、プロジェクトへの関わり方を模索していけたらと思います。