##はじめに
ゲームのQA
の役務といえば、もちろんゲームの品質を保つために、バグを見つけたり動作確認をしたりすることが
主な役務です。
その為、プロデューサーやディレクターの次にゲーム全体の仕様を把握していると言っても
過言ではありません。
また、業務はQAのみで完結せず、必ず様々な部署との関わりが発生します。
今回は弊社で運営しているゲームにおいて、
QAが他部署とどのように関わっているか、紹介したいと思います。
ところで
あなたの部署の執務室（仕事場）は、他部署と同じ空間にありますでしょうか？
部屋が違う？
または、階が違う？
もしかして、ビルが違う？
社内の環境はそれぞれ違うとは思いますが、
弊社の場合はオープンオフィスとなっており、今から紹介する部署についてもQAと同じ空間で働いています。
ですので、以下の内容はオープンオフィスをイメージしながら読んで頂ければと思います。
それでは、QAが各部署に対してどのようなコミュニケーションをしているのか、紹介致します。
##プランナー
ざっくり言うと、ゲームのイベント内容やキャラクター、ステージ、を考える企画職です。
QAと一番関わりが深いのがプランナーです。
毎日のように施策やスケジュールなどの情報を共有してもらい、QAからもテスト結果の報告や懸念事項を伝えたりしています。
例えば、
・この施策はいつリリースするのか？情報の公開はいつか？
・いつからQA開始可能か、いつまでにQA完了すべきか？
・キャラクターの特徴は？ウリは何か？
・ステージの特徴は？注意点はあるか？
・そもそもこれはどうやってユーザーが楽しむのか、どんな意味があるのか？
といった質問を投げかけ、リリース時の状況を想定し、テスト内容に反映させます。
スケジュールが過密であることが多いので、要件を捉え、場合によってはスケジュールを調整・変更してもらうこともあります。
プランナーが
データを作るため、バグ票の確認、その修正もするのもプランナーです。
プランナーも各部署と関わりが多い部署のため。負荷がかかりやすいです。
プランナーが判断しやすいように、情報を整理することを心掛けています。
##デザイナー
ゲーム内のキャラクターやUI、エフェクトの面でのQAについて会話します。
QAとしてはデザインを見たり触ったりした感想を話すこともありますが、
主には懸念事項を伝えることが多いです。
例えば、
・FIXした画像データはいつ完成するか？（スケジュール確認）
・使われているデザイン、意匠は法的に問題ないか？
・実機上のデザインは意図通りになっているか？（未完成版が誤って納品されていないか？）
・〇〇について分かりづらく感じるが問題はないか？
ユーザーが一番最初に目に入るのが各デザインについて、
QAとしても一ユーザーとしてゲームを触り、違和感を感じたり、よく見るとこれって変じゃない？
といった箇所がないかチェックします。
コアなユーザーなほど、じっくりデザインを見るので、第一印象だけでなく細かいところまで注意が必要です。
##エンジニア・プログラマー
プランナーが考え、デザイナーが描いたものをまとめ作り上げるのが、エンジニア・プログラマーです。
動作検証中に未知のエラーがあれば、サーバまたはクライアントの担当と会話して問題を解決します。
主に新機能開発（バージョンアップ）で、密にやり取りします。
例えば、
・新機能について、どのような判定・処理を行っているか？（QAにも分かる範囲での説明をもらいます）
・どんなデータによって制御できるのか？
・既存の機能への影響はあるか？
また、
弊社では週１回、流出不具合の再発防止を目的とした会議を開いています。
そこでは業務フローの改善だけでなく、機械的にミスに気付ける仕組みや、
デバッグコマンドも必要に応じて追加実装してもらうこともあります。
##カスタマーサポート
カスタマーサポートの負担を減らすため、
ユーザーから問い合わせが来るであろう仕様について、事前に共有したり
ユーザーからの不具合報告の検証についてやり取りを行います。
例えば、
・〇〇について、△△のパターンでは◇◇となってしまうのは仕様である。
・✖✖のバグについて、再現が取れないので〇〇について詳細な情報がもらえないか？
・Twitterでこんなバグ報告を見つけたが、問い合わせは何件来ているか？
カスタマーサポートでは、ユーザーの要望についてレポートとしてまとめてくれています。
ユーザーが今感じていることを把握することも、QAの大切な業務です。
##宣伝
ゲーム内お知らせ・公式サイト・Twitter・動画といった各媒体で
ゲームの情報を発信するのが宣伝です。
ゲーム外についてはQAを通さず、その媒体をつくる部署とプランナーの間でやり取りが完結し、リリースすることが多いです。
しかし、"目"を増やすためにQAもフォローとしてチェックを行います。
宣伝に対してはバグ報告が多い印象です。
例えば、
・〇〇について、仕様と異なる記述になっている
・〇〇について、ユーザーの環境ではあり得ない状態の画像が使用されている。
##ところで運営支配型QAとは・・？
QAは工程としては下流であり、最終関門です。QAを無事突破しない限り、ゲームはリリースされません。
QAは全体を見渡し、部署と部署と間に立ってやり取りすることも多く、潤滑油のような存在でもあります。
広い意味では全体を支配・掌握できる立場でもある、といっても過言ではありません。
弊社では幸い、QAの地位が不当に低いことはありません。
ただ、会社によってはパワーバランスが異なり、スケジュール優先になりQAがおざなりになったり、
はたまたバグが市場に流出しても、QAにばかり責任や負担が押し付けられることもあるかもしれません。
でも、本当は部署に上も下もありません。対等です。
バグが市場に流出しても、QAだけの責任ではありません。
個人的な意見となりますが、QAはさまざまな部署と関わりあうため、
関わる人全員が気持ちよく働けるように、フォローできるところは惜しみなくしたいと考えています。
QAはテストを行う、という当たり前の役務ですが、テストだけに捉われず、
品質を下げずむしろ上げるための提案は、
どの工程、どの部署に対しても、いつでも出来るのがQAだと思います。
##あとがき
本エントリーを閲覧くださり、ありがとうございました！
最近読む本はソフトウェアテスト関連のものより
コミュニケーション術などのビジネス書を読む時間の方が多いです。
これからも上流工程からQAとして介入することで
当初の想定よりも品質を上げてリリースできることを目指していきたいと思っています。