「THE METHOD」は、ミクシィのさまざまなプロダクトにおいて実践されているノウハウやメソッドを惜しみなく共有するオンラインイベントです。今回の「THE METHOD」では、『モンスターストライク(以下、モンスト)』のQA(Quality Assurance)について。
『モンスト』における品質保証ってどのような仕事なの?どんな人に向いてるの?…とあまり知られていないQAの仕事を徹底解剖していきます。本記事では、「THE METHOD #9」のダイジェストをお届けします。
今回話をしてくれるのは、『モンスト』のQAグループマネージャーの福永。
司会はモンスト事業本部・事業支援室の三瓶が担当しました。
━━まずはQAの仕事について教えてください。
QAと聞くと、一般的に「リリース前の動作確認」とイメージされる方が多いのですが、これはQAが手がける業務内容の一部にすぎません。動作確認は「テスター業務」と呼ばれ、とても重要な仕事ではありますが、QAの仕事範囲はこれだけには留まらないんです。
QAは、「品質保証」を意味する「Quality Assurance」の略です。
少し硬い文章にはなりますが、私は「効率的に品質を高めるためにできることを考え、提案し、実践する活動」だと捉えています。
ですから、QAが関わる範囲はとても幅広い。例えば、仕様書や設計作成のタイミングでも、整理・確認を行い、矛盾点や気になる点があれば随時報告。変更や修正を促していきます。早い段階で、懸念点や問題点を解消し、開発の手戻りを防ぐ役割を担っているんですね。また、リリース後も問題が発覚した場合には、いち早く内容を確認し、修正や回避するために必要な手がかりをプロジェクトに提供する。被害を最小限に留め、信頼回復のサポートを行なっています。
かつての私の上司が「QAは医者のようなもの、特に”かかりつけ医”のようなものである」と言っていて、非常にしっくりきました。患者の問診・検査データから病状を確定し、病状を改善させる治療を行い、その後も予防に努める「医者」と、製品の企画や仕様を読み解き、製品に潜む不具合や課題を事前に検知し、品質を高める「QA」。双方のイメージが重なりあった記憶があります。
━━『モンスト』におけるQAグループの体制や具体的な仕事内容について教えてください。
最初にQAグループの体制についてです。
『国内モンストチーム』、『海外モンストチーム』、非ゲーム系の案件を担当する『Web&プロモチーム』、組織運営に関する支援を担当する『技術・運営支援チーム』と4つのチームに分かれていて、各チームでそれぞれの役割を持っています。ただし、状況に応じて他チームのサポートを行う場合も多くあるので、横のつながりも意識したマトリクス組織になっています。
続いて具体的な仕事内容について。
先ほど役割の異なる4つのチームを紹介しましたが、ここでは『モンスト』における品質業務にフォーカスして紹介していきます。
『モンスト』における品質業務のサイクルは、各バージョンアップが約1~1.5ヶ月周期で行われていて、その期間内で「キックオフ~テスト計画~テスト分析・設計~テスト実装・実行~リリース前後確認」を手がけています。期間でいうと、キックオフやテスト計画に1~2週間程、テスト分析・設計~テスト実装までの準備に1~2週間程、テスト実行に1週間程が目安になりますね。
各メンバーが手がける範囲でいうと、「テスト分析~リリース前後確認」を幅広く担当する体制をとっています。上流の「キックオフやテスト計画」に関しては、チームリーダーが中心ではありますが、メンバーも参加が可能です。企画や開発メンバーとコミュニケーションを取りながら、最適なテスト設計を行なうことができます。
企業によっては、各種テストをプロセス別に分けるケースもありますが『モンスト』では、その形はとっていません。“一人ひとりが全プロセスを担当できる体制”にすれば、極端な属人化を解消できますし、上流工程に関われる環境によって自身のキャリアパスにもつながっていくと考えているからです。個々でも強く、そしてチームでも強くありたいと思っています。
━━ここまで各バージョンアップに紐づく業務内容をお聞きしてきましたが、他にも業務があれば教えてください。
1つは「開発健康度の振り返り」を実施しています。これは、各部門からのデータや情報を収集して開発状況の良し悪しを確認するもの。過去のバージョンアップと比較し、順調なのかを数値で見て行き、もし問題があるならその要因を特定。最新の開発状況が健康であるよう、サポートしていきます。
他には、本番環境で不具合が発生してしまった場合の「再発防止に向けた振り返り」も重視しています。企画、開発、QAなど各部署から主要メンバーを集めて、問題の内容、経緯、各部署で考えられる原因と今後の対策を細かく話し合います。対応策が決まれば、その内容を各メンバーにも共有。情報を積み重ねていけば、テスト仕様書の精度向上にも繋がっていると考えています。
━━最後にQAのやりがい、どんな方に向いているのか教えてください。
月並みにはなってしまいますが、やはり関わった製品が世の中に出たときはこの上なく嬉しいですね。企画や開発、デザイナーなどさまざまな人たちと意見を出し合って、一つのプロダクトを創り上げていく過程に面白さを感じます。そこからさらに実際に多くのユーザーが触ってみて、ポジティブな反応をいただけたときは、もうテンションがあがります(笑)。大変なこともあるけれどやってて良かった、と心から思う瞬間です。
そして、QAに向いている方についてです。
個人的にいくつか浮かんでくるキーワードがあって、「会話(共有)」「好奇心」「想像力」「慎重」「責任感」…こういったワードにピンとくる、自身の性格や価値観にフィットする方には向いているんじゃないかなと思います。いろいろ探って、考えて、ベストな道を見つけ出す。その繰り返しの行為そのものを楽しめる方がフィットしそうです。
品質保証業務とはプロダクトやサービスを「素早く」「安全・安心」かつ「楽しく」使ってもらうためには、何をすれば良いかを考え、実行する活動だと思っています。ですから、単純に「不具合が無いかテストするだけ」ではなく「良い製品やサービスにするために何をしよう」と楽しく考える仕事だと捉えてもらえたら嬉しいですね。
最後は、質疑応答です。視聴者のみなさんから寄せられた質問にもリアルタイムで回答しました。
Q:ご自身がQAの仕事を選ばれたのは、どういう経緯ですか?
私は学校を卒業してプログラマになったんです。そのとき手がけていたのは金融系の開発でした。ですが、もともとゲームが大好きだった背景もあって、ゲームに関わる仕事がしたいなとずっと思っていたんですね。そんなときに出会ったのが、「ゲーム好きだったら大歓迎!」と書かれたテスターの仕事です。自分の好きなゲームで遊べるじゃん!ぐらいの感覚でした(笑)。取り組んでいく中で、QAそのものの仕事の奥深さに触れ、キャリアを積んできた流れになります。
Q:テスト仕様書を作成する際、担当者によって「クオリティの差」は生じないのでしょうか?何か対策はありますか?
クオリティの差は生じる可能性があります。特に『モンスト』は、長い歴史を持つ大規模なプロダクトですから、多くのドメインの知識も求められるんです。なので、私たちのグループでは「テスト観点書」を用意して、どういう観点でテスト設計をするのかリスト化して、各メンバーにも共有。この人はこういう項目で設計しているのか、このポイントが大事なんだな…など、現場で学び合える環境作りを行なっています。
Q:テスト実行期間は1週間程度とお聞きして、短いと感じました。1週間で可能なのでしょうか?
言葉を選ばずにお伝えすると、不具合は完全にはなくなりません。だからこそ、優先度をきちんと見極めて、不具合に対処する必要があります。データを分析し、プロダクトの状況に合わせた取捨選択が重要になるんです。「1週間」の期間を設けつつ、その時点でこのままいくとどのぐらいの不具合がでそうなのか、それはどのぐらいの影響があるのか…企画や開発チームと相談しながら、最終的な判断をしていきます。
Q:『モンスト』のQAグループとして、今後注力していきたい取り組みがあれば教えてください。
一番は「自動化」ですね。これは『モンスト』に限らず、QA領域における大きな課題でもあります。UIの変更によって、これまでの自動化が上手くいかないケースもありますが、「どうすれば自動化の割合を増やしていけるのか」は積極的に追求していきたいところです。
QAの仕事と聞いて、「出来上がったサービスに不具合がないかテストをする人」と捉えていましたが、それだけではありませんでした。企画や開発チームと共に上流工程から携わり、“ユーザーに喜んでもらえるサービスにするために何をしよう?”と考えていく仕事。開発者の一人として、ゲーム作りに携わっていくプロセスを存分に味わえるのだと分かりました!
※イベントページはコチラ
今後も様々な“メソッド”に焦点を当てながら、開発・制作ノウハウなどをお届けしていきます。次回もお楽しみに!