開発チームから激モテ！ネイティブゲーム時代の愛されQA
haruna nishiwakiはじめまして、Quality Assurance部ネイティブゲームQAチームの13新卒トリオ、
@haruna_nishi・@fujiemon_828・@hujuu ※注1です。
このエントリーは「GREE Advent Calendar 2014」21日目の記事です。
「GREE Advent Calendar 2014」13日目の山本さんの記事で弊社のQA体制についてご紹介したばかりですが、そちらの記事はテストエンジニアリングチームの取り組みが主なテーマだったので、当記事ではネイティブゲームQAチームの体制や取り組みについてもう少し踏み込んでご紹介したいと思います。
激モテ！愛されQAと題したからには、開発チームからモテるためにどのようなQAを行っているのかを主眼に置いてレポート致します。
表舞台には出ることが少ない部署ですが、当記事で少しでも雰囲気をつかんでいただければ嬉しく思います。
グリーのネイティブゲームQAの体制について
まずは、ネイティブゲームQAがどんな組織なのかをご紹介致します。
13日目の記事で既出の通り、グリーのQA部は、ネイティブゲーム、ウェブゲーム、ガレージスタジオ＆プラットフォーム、テストエンジニアリングの4つのチームに分かれています。その中でもネイティブゲームQAチームは、2013年11月頃に2名で発足した比較的新しいチームです。
現在は9名まで増員され、ネイティブゲームの品質を高めるために日々働いています。
今回は、我々が普段開発チームに愛される（必要とされる）ために行っているQAのポリシーや方法を、「愛されポイント」と題してご紹介致します。
愛されポイント1. 開発初期段階から開発チームに入る・開発チームごとに担当制
恋愛において、距離が近い人ほど好きになりやすいという現象は、どなたにも感覚的に理解していただけるかと思います。対人心理学では「近接の効果」と呼ばれるように、やはり近くに居る・毎日顔を合わす人間の方が仲良くなりやすいようです。
我々QAもそれを狙って…いるわけではなく、ゲームの品質を開発初期段階から高めるために、本開発が承認された段階～開発中期までに担当するメンバーを決定し、開発チームの中に入ります。
現在、グリーのネイティブゲーム開発は、チームごとに多少やり方に違いはありますが、ほとんどのチームがアジャイル開発のスクラムという手法を導入しています（スクラムの説明は本記事のカバー範囲ではないので、割愛します）。
QAもその開発チームの体制に合わせ、テストケース作成、テスト実施、テストケース修正（追って機能が追加されていくため）を短いサイクル（現在自分が担当しているチームでは１週間です）でずっとまわし続けるという手法でテストを行っています。
そうすることにより、バグを埋め込んでしまったり、仕様と違う動作などが実装されてしまってもすぐに発見することができ、手戻りを最小限にすることが可能です。
また、昨今のスマートフォン向けネイティブゲームは、のせるプラットフォームにもよりますが審査に時間がかかるため、リリース後の運用中に致命的なバグが発生した場合、1日で修正することができたとしても審査にかかる時間（１週間以上かかることも多々あります）だけゲームのサービス自体を止めなければならないといった事態が発生してしまいます。
そのような事態を防ぐため、ネイティブゲームQAチームでは、従来ウェブゲームなどで行っていたリリース前のQAだけではなく、開発している間も継続的にテストを実施しています。
継続的にテストを実施するため、「GREE Advent Calendar 2014」18日目の西田君の記事でも触れられているように、開発がどの段階であろうとシミュレータ上だけではなく常に端末上で最新状態のゲームがプレイできる状態にしておくという、かなり負担のかかることを開発チームのエンジニアの方々にお願いしています。
しかし、副次的な効果として開発チームのディレクターやプランナー、アートの方々も常にゲームをプレイすることが可能になり、ゲームの機能がどこまで出来ているのか、ゲームバランスは端末上でどのように感じるのか（フリック・スワイプなどマウスでは難しい操作も端末上では簡単なのでシミュレータでは正確な操作感はわかりません）、UIは端末上でどのように見えるのかなどを確認することができ、結果的に不具合を早期発見する以外にも開発に良い影響があると考えています。
愛されポイント2. 開発チームの要望に最大限答える
ゲームのリリース前にはある程度期間を設け、協力会社の方々の力をお借りしてある程度の人数でQAを実施するのですが、開発の状況によっては、通常想定しているほど期間を設けることができない場合があります。そのような際にも最大限開発チームの要望に答え、短期間で最大限の効率でQAを実施しています。
例えば、先日CMが放映されておりました「消滅都市」は、バトルの際にパーティを最大6人（自分のパーティー5人＋別ユーザーのリーダー1人）のキャラクターで構成することができるのですが、キャラクターにはそれぞれ「パーティーのリーダーのときあるいはゲーム内フレンドのキャラクターである場合のみ有効化するリーダースキル」と「（リーダーあってもなくても）バトル中に利用できるスキル」が存在します。
リリース時点でのリーダースキルの種類は8種類、スキルの種類は12種類あったため、重複組み合わせが130万通り以上存在することになります。
キャラクターはそれぞれバトル時に使用することができるスキルとリーダースキルを持っている
最大6人編成のパーティーなのでスキルの重複組み合わせが130万通り以上存在する
そこで、限られた期間の中で効率的にテストを行うため、組み合わせテストを効率的に行うことが出来る「オールペア法」というテスト手法を用いてテストを実施しました。
オールペア法とは、2つの因子について、それらの値の組み合わせをすべてテストする手法です。
単純な組み合わせテストでは因子すべてを組み合わせますが、「多くの欠陥（バグ）は2つの要因の組み合わせで発生する [1] 」という調査に基づいてオールペア法を採用することで、211通りに組み合わせを抑えることができました（組み合わせの算出には、「PICT」※注2 というソフトウェアを利用しました）。
実際に上記の手法で、同じリーダースキル（例えば、味方の火属性タマシイ（キャラクター）の攻撃力が2倍になるなど）を持つキャラクターがパーティーに2人居たときに、攻撃力が4倍になるはずが2倍のままといったバグなどを見つけることができ、限られた時間と人的リソースの中でQAを実施することができました。
また、通常の機能テスト以外にも、開発チームがテストをしたいことがあれば随時要望にお答えしています。
例えば、消滅都市と同じく Wright Flyer Studios からリリースされました「天と大地と女神の魔法」のテスト行程では、フィールドワークも行いました。
残念ながら先日サービスを終了することが発表された当ゲームですが、このゲームは最大4人でのマルチプレイが可能なリアルタイムストラテジーと呼ばれるジャンルのゲームです。
このようなジャンルのゲームは端末の通信状態がユーザー体験に直結するような性格を持ちます。そのため、想定しているプレイ環境で問題なくプレイできるのかを確認するため、実際に地下鉄に乗って4人でマルチプレイすることが可能かを検証しました。
愛されポイント3. 新しい取り組みを積極的に行う
メンバーが増員されてから、エンジニアとして開発経験のあるメンバーはエンジニア視点でのテストを実施することができるようになりました。
ネイティブゲームQAのエンジニアは、上述の通り開発の初期段階からチームに参加し、リリースまで通常のQAとテストエンジニアリング両方の観点からテストを実施します。
始めたばかりなのでまだ実施対象になっていないチームも多いですが、不具合を見つけたときに修正のpull requestを出したり、受け入れテストの自動化なども取り組みとして行っています。
今後は開発チームによりゲーム開発に集中してもらうため、Jenkinsの立ち上げやメンテナンスなど、テストや継続的インテグレーションに関わる領域でエンジニアリングの知識が必要ではありますが開発の本質ではない作業も、テストエンジニアが担うという取り組みも行う予定です。
また、Fun QAと呼ばれる考え方の一つ、ゲームの「面白さ」についてのフィードバックなども行うなど、よりゲーム開発に特化したQAも行っており、メンバーがそれぞれ得意な分野、スキルを用いて新しい取り組みを行っています。
まとめ
以上の3つの「愛されポイント」を実施しているからこそ、様々なチームから「開発初期段階でチームにQAメンバーを迎えたい」といったような積極的な要望を頂けているのだと自負しています。
スマートフォンにおけるネイティブゲームのテスト手法はまだまだ確立されていないことが多く、悪戦苦闘することも多いですが、記事タイトルのような開発チームとの良好な関係があってこそ、よりよいQAを目指すための様々な新しい取り組みができているのだと思います。
開発チームの方々にはこの場をお借りしてお礼申し上げます。これからもよろしくお願い致します！
最後に、この記事を読んで少しでも弊社のネイティブゲームQA体制についてご興味をもたれましたら、ぜひこちらへご連絡ください。我々ネイティブQAチームでは、業界におけるQAのプレゼンスを高めるための活動や、様々な会社の方と情報交換をしたいと思っております。
それでは明日は同期の（色んな意味で）釣り師、二宮君による『釣りスタ』チームにおけるエンジニアの生存戦略についての記事です。お楽しみに！
※注1：@hujuuはこの記事を書いている間に開発チームへ異動になりましたが、内容の監修をしていただいているので当初の予定通り連名にさせていただきました。ありがとうございました！
※注2：「PICT」はこちらのトップページの Available Tools からダウンロード可能です。
[1] D. Richard Kuhn, Dolores R. Wallace, and Albert M. Gallo Jr, "Software Fault Interactions and Implications for Software Testing", IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL.30, NO.6, JUNE 2004.