イントロダクション
いきなりですが、弊社のゲームQAの体制面についてお話ししたい。
全てのタイトルに当てはまるわけでは無く、また「運用安定後」という認識の上、下記の図をご覧頂きたい。
《要点》
・開発とQAはそれぞれ独立した組織
・開発チームとメインでやり取りを行うのは、協力会社（常駐者）の方
・社内アルバイト、スタジオメンバーについては、テストの実施を担当
《協力会社（常駐者）のオシゴト》
・定常で回している施策のすり合わせ（プロダクト⇔QAの仕様共有）
・テストケース作成や部分的改修、項目削減
・社内アルバイトやスタジオメンバーとの業務やり取り（橋渡し）
これだけで見たら、ある1つの疑問に行き渡る。
####社員は一体何をやっているんだ!? と
事実、定常的な施策を回すだけであれば、QA体制の中の「社員」という立場の人間はいらないともいえるし
いなくても回るように、設計されているのである。
もちろんこの体制を築くのが社員のオシゴトとも言えるが、それはまた別の機会に。
#####それじゃあ安定したんだからやることないだろうし、毎日寝そべってただゲームをやってるだけなんでしょ？
と思われた方。お待ちください。そういった方も居るかもしれないが、少なくとも私はそうではない。
ではいったい何をやっているのか、という点について本記事で紹介していきたいと思う。
なお、今回はザックリとした紹介であるため、詳細な取り組み内容等は別の機会で紹介したい。
###【オシゴト１：業務の効率化、標準化】
業務とは下記一連の流れを示す。
※あくまで業務の一例となる図式のためご留意頂きたい。
この流れの中において、手がかかっている箇所を効率化、あるいは複雑なフローを経ている箇所を
標準化したりするのが社員のオシゴトである。
###【オシゴト２：検証の効率化】
人によってはオシゴト１の業務効率化にも入る話ではあるが、今回は分けて記載させていただく。
検証とはテスト実施のことである。つまり、テスト実施において手がかかっている箇所を減らす手法を考え、
取り入れるように動いていくことが社員のオシゴトである。
例で挙げるならば、実機で確認をしていた箇所を減らすために、設定値（データ）を直接見て確認する検証に
変えたりするよう取り組む、などである。
###【オシゴト３：障害の分析】
障害が発生するメカニズムには複数の要因が絡んでいる。
弊社ではその複数の要因に対した分類を用意し、定常的にその分類分けを行っている。
その分類分けが正しく行われているか確認することが社員のオシゴトの１つではあるが、
もちろん分ければ満足という訳ではない。
さらに踏み込んで、分類した障害を分析し、どのような施策で、どのような箇所に多く見られるかなど、
傾向を掴み、品質向上や検証効率化に向けた対策を練って取り組むこともオシゴトである。
※分析は開発の方で行っているという会社も多いかと思うが、弊社ではQAを担当する社員のオシゴトにあたる。
###【オシゴト４：開発への業務改善提案】
冒頭の体制図でお話した通り、弊社では開発とQAの部署は独立している。
その為、開発を外（別の部署）から見ることが出来るため、開発工程における非効率的箇所や
品質低下を招きかねない箇所、あるいは品質向上を目論める箇所など、客観的な視点にたって見ることができる。
そこで発見した改善点を、開発に提案するのが社員のオシゴトだ。
例えば、リリース前の本番反映作業の工程で設定値を弄っているなどあれば、
QA後の設定値変更は障害発生リスクが高いため無くすように指摘するなどだ。
開発チームの内部に居れば、当たり前の認識になっていることも、外から見たらそれはリスクの高い行いをしているということは往々にしてありえることだ。
もちろん、別の部署ということは、開発内での作業工程全てを把握しづらく、
リスクの高い作業に対して逐一指摘することが難しくなってくるのも事実だ。
品質管理の独立性などについては、JSTQB のシラバスに記載されているので、そちらを参照してほしい。
##まとめ
弊社QA体制における「社員」のオシゴトを色々と紹介してきたわけだが、
もちろんこれは一例にすぎず、他社においては体制含め、オシゴトの内容や取り組み方は違っているかと思う。
ゆえに、これを読んでいただいた方には、ぜひ貴社におけるオシゴトをコメントいただけると嬉しい。
そのオシゴトは、「その会社にしかあてはまらない」というものもあるかもしれないが、同時に新たな発見につながる可能性もあると筆者は考える。
本記事を通じて、より多くのゲームQAのオシゴトを共有できたらと思う。