「QAが積極的に入っていけるから、開発サイクルも早くなる」　“モンスターストライクのかかりつけ医”のチーム構成と業務サイクル

QAのイメージと実際にかかわる工程

福永裕幸氏：では、最初にお品書きです。今回は、全体像を伝えるところを目的としています。1つ目は、品質保証業務とは何か。2つ目に、『モンスターストライク』ではどういった業務が行われているか。3つ目に、業務のやりがいや向いている人について簡単にお話しできればと思っています。

はじめに、「品質保証業務とは」というところをお話しします。よく「完成直前の製品がちゃんと動くかテストする人たち」というイメージがあるかと思います。そのイメージを次のスライドで図にしてみました。

（スライドを示して）この図は、新しいゲームが企画・立案されて発売されるまでのおおまかな流れの一部を示したものです。スタートは矢印部分の一番左ですね。企画検討から始まり、そこで世の中で求められている作り出したいゲームが何かを分析調査して、作るゲームの内容の方向性とかスケジュールなど、さまざまなものを見積もっていきます。

次に仕様書作成です。検討したゲームの内容に基づいて、詳細な内容を決めていきます。ゲームの設計図にあたる部分です。その次が、素材やプログラム。もちろんほかにもいろいろありますが、仕様書をもとに実際に動かす素材であったり、実機上で動くプログラムを作成していきます。

そこから先、製品版となるまでに、“制作初期段階”と言われるようなα版とか、一通りの機能が入ったβ版。あとは「出荷候補だよね」といった最終段階になるRC（Release Candidate）版が続きます。

QAという言葉でイメージされやすいのが、右下のイラストがついている部分です。見聞きする中では、β版とかRC版で動作確認する人たちというイメージを持たれていると思っています。

ただ、実際にはβ版やRC版で実際の動作を確認する人はQAの仕事の1つでもありますが、基本的には“テスター”と言われる業務になります。

動作確認をする業務ももちろん重要であり、ここだけでもかなり重要で十分なタスクがあるんですが、品質保証という業務でいうと、これだけにはとどまらないということを最初にお伝えしたいです。

QAは“かかりつけ医”と似ている

QAがどういった仕事か、まずは一般的な定義をお伝えします。（スライドを示して）Wikipediaから引用しました。「品質保証とは、効率と品質が求められるあらゆる活動において、それらに保証を与えるのに必要な証拠を提供する活動一般を指します」とあります。

ちょっと堅苦しい言い回しではありますが、先ほどの図で業務範囲を示すと、次のスライドのようになります。

下のアイコンがあるところです。先ほどの説明のように、QAは「効率的に品質を高めるためにできることを考えて、根拠を集めて提案して、実践して保証する」活動なので、そのために、QAとしては早い段階から各タイミングにかかわることが重要になります。

例えば、実際にプレイできるアプリが出来上がる前まででも、仕様書とか設計書、あとは素材をQAのメンバーが確認して、時にはドキュメントを整理したり、もしくは矛盾点や気になるところがあれば随時報告して、ものが出来上がる前から懸念や問題点を修正してもらうことは、非常に重要になります。

早い段階で懸念や問題を報告することで、開発の手戻りが防げるんです。なにか問題を解決するために、1つ前あるいは2つ前以上の段階からやり直すことがなくなるので、やはり効率的になります。

問題点を修正するとなると、後の段階になればなるほど追加で必要になる時間やお金、いわゆるコストが膨大になってきます。時には対応コストの確保がすでに難しい、時間がないとなると、「もうそのままリリースするしかない」という判断をしなければいけないこともあります。

以上のことから、QAとしても最初の段階からかかわって、ちゃんと手を入れていきましょうということです。

あとは、リリース後もけっこう重要で、リリースできたら終わりではなく、リリース後も問題が発生する場合があります。

発覚した場合にいち早く内容を確認して、修正や回避するために必要な手がかりをプロジェクト側に提供して、被害を最小限にとどめたり、お客さまの信頼の回復のサポートを行うなど、QAは最初から最後まで、かかわれる範囲はけっこう大きい仕事になります。

余談にはなりますが、QAはあまり表に出てこない職業でもあるので一般的にはイメージしにくいですが、いわゆる私の師匠である前任のマネージャーが言っていた言葉が、すごく身にしみるなと思っています。

「QAは医者のようなもので、特にかかりつけ医のようなものである」と言っていて、これはすごく納得がいきました。「似てるかも？？？」と書きましたが、お医者さんって、患者の容体とか問診とか検査データとかで病名などを確定して、投薬とか手術とかでその症状を改善させて治療を行う。その後、予防に努める仕事とも言えるんですよね。

QAとしても、やはり製品の規格とか仕様を読み解いて、製品に潜む不具合とか課題を事前に検知して品質を高める仕事とも言えるというところでは、“お医者さんみたいなもの”と言うとけっこうイメージしやすいかなと思ったりもしたことがあります。

QA組織のあり方のパターン

そういったQA組織のあり方もいくつかパターンがあります。1つの会社で1個だけではなくいろいろな製品とかを作っている会社さんもありますが、そういったプロジェクトを横断的に1つの組織で担当するというやり方や、いくつかあるプロジェクトに対して、それぞれにちゃんとQAチームが存在するやり方とか。細かいところでいうと、開発にかかわる関係者、いわゆる企画、開発、QA、デザイナーなどが1つの場所で集まるタイプもあります。

各部署で開発場所が違う。それこそQAは、東京ではなく沖縄で、別のラボでやるみたいなところもあったりします。

QAの作業に絞っても分かれていることがあり、テスト仕様書を作るチーム、テスト仕様書を実行するチームが分かれていたり。もしくは、これらがハイブリッドで混ざっているような現場とか、さまざまな組織の存在があります。

ということで、軽くではありますが、品質業務が、どういった仕事で、どういう形態かをつかんでもらったところで、次のお題目に進みたいと思います。

「モンスト」におけるQAチームの構成

モンストでの品質業務がどんな状況かを説明します。まずは、先ほどお話ししたQA業務がかかわるタイミングの幅です。基本的に（かかわる幅が）最初から最後まである前提でお話ししますが、まずは組織編制からです。

規模感は月によって多少増減はありますが、我々のグループでは今全体で55名のQAスタッフが存在しています。マネージャーである私が1人いて、チームリーダーが4名いる体制で、役割的には大きく4つのチームに分かれています。

まず1つ目が、国内モンストチームです。こちらがだいたい20名強のチームで、中にはアウトゲーム班、インゲーム班みたいな感じで分かれてはいますが、基本的には国内版のモンスターストライクのゲームアプリの専用のQAチームです。

もう1つが、海外版モンスターストライク。香港、台湾、マカオに配信をしていますが、こちらがだいたい15名前後ぐらいのチーム規模となっています。こちらもちょっと名称は違いますが、内部的にはクライアント班とデータ班の2つのユニットに分かれています。

こちらは、海外版がメインで担当はしていますが、国内版と同じ内容のものも多いので、国内版のサポートも行うようなチームとなっています。

その次に、Web＆プロモーションチームがあります。こちらはゲームアプリ以外のモンストに関する案件のすべてを担当するチームです。例えば、モンスターストライクのWebサイトや、「XFLAG PARK」といったオンライン、オフラインのイベントがある時に、特設サイトやちょっとしたWebアプリを担当してくれるチームです。

4つ目に技術・運営支援チームというのがあります。こちらは特定のなにかのプロダクトの専門ではありませんが、前述の3つのチームに関して、QA業務のお手伝いとかをしながら技術検証をしていくところで、自動化とか組織運営の改善を支援するチームとなっています。

我々のグループには55名いるという話はしましたが、スタッフさんの7、8割が協力会社さんになっていて、10社以上で成り立っているグループになります。

また、チームとしては分かれていますが、先ほど海外モンストチームが国内版のサポートも行う、技術・運営支援チームはほかのチームを全部手伝うといったように、兼務としてほかのチームのサポートを行うことも多いので、横のつながりも意識したマトリクス組織の編制に近い組織になっています。

そのため、チームが異なってもグループ全体が1つの場所に集まって仕事をしているというのが我々の組織形態です。特にモンストのアプリの開発に関しては、QAグループ以外も、いわゆる企画さん、開発さんとかの開発者関係は、基本的に1つのフロアに集まって配置されているので、コミュニケーションがすごく取りやすい現場です。やはり気軽に聞けるのはありがたいですね。

ただ、現在はリモートワークの対応が進んでいるので、任意で選べますが、だいたいの人たちが週3から週4はリモートで、自宅から業務する人が多くなっています。

国内モンストチームの業務サイクル

組織編制はこんな感じで、次は業務サイクルですね。今回は国内モンストチームを例にして説明をします。（スライドを示して）モンストは運営期のタイトルのため、一番上の段のバージョンアップが、だいたい1ヶ月から1.5ヶ月ぐらいの周期でされています。

1つのバージョンアップの内容を2行目に持ってきていますが、QAプロセスとしては、最初にキックオフやテスト計画を、1～2週間ぐらいかけて進めていきます。

それらで仕様を把握しながら、テスト分析やテスト実装までを、だいたい1～2週間。テスト実行に1週間を目安に1つのバージョンを進めています。リリースされたらまた次のバージョンの準備に取りかかる感じですね。

もちろん、運用中のタイトルですので、並行して運用のデータQAも走っています。（スライドを示して）そこが3行目の青色の帯の部分です。運用データに関しては、週2～3回ぐらい更新が入るので、ほぼ毎日なにかしらのデータをチェックしている感じです。

基本的に、モンストに関してはリリース日が先に決まっていて、逆算して各セクションの開発期間を調整しています。もちろんメジャーバージョンなど大きく重い案件、いわゆる新しい遊びが開発される場合には、1バージョンだけでは開発やQAが重かったりするので、そういった時には2バージョン開発など、複数の期間で開発することもある感じです。

QAメンバーに関しては、各種機能のキックオフから参加し始めることで、早めに情報の共有ができるので、開発の難しそうな案件などは事前の把握が非常にしやすい環境になっています。

開発中もビジネスチャットツールの「Slack」で案件部屋と呼ばれるチャンネルを使っているんですが、そちらにもQAメンバーがそれぞれ入っていけるため仕様の変更点などを自らキャッチアップしやすく、QAも積極的に動けば、スケジュールが多少変わったとしても、調整しやすい組織運用になっています。

国内モンストチームのメンバーの動き

続いて、各メンバーの動きにも軽く触れていければと思います。（スライドを示して）各メンバーの業務としては、先ほどのテストプロセスを1行目にそのまま持ってきていますが、前提として、テスト分析からリリース前後確認を、全メンバーが機能別に担当していきます。

そのため、先ほど言った「テスト項目書を作るチームと、テスト実施するチームが分かれている」という現場ではありません。基本的には1つのチームで、一人ひとりが両方できる環境を目指しています。

各種のプロセス別、例えばテスト仕様書作成者やテスト実行者には分かれていないので、各メンバーは一つひとつの案件（機能）ごとに両方を受け持つことになりますが、案件の数もやはり多いので、基本的に1メンバーあたり複数案件の担当者となっています。

担当者となって何をするかというと仕様書を読んでテスト項目書を作っていきます。中には不明点が出てくるものもあるので、その機能を企画した人、その機能を作っている開発者さんともそれぞれコミュニケーションを取りつつ、最適なテスト設計を行っています。

1人がテスト分析からテスト実装・実行まで担当するのは、メリット・デメリット両方があります。（スライドを示して）大きな理由としては、枠内にも書いてあるとおり、誰もがひとおとりの業務を行えることで、極端な属人化の解消を行いましょうということです。

例えば有給を取りたいとか、突発的なお休みが発生することもあるので、そういった時でも短いスケジュールに影響がないように、ほかの人がすぐにカバーに入れるような自由度の高い体制です。

あとは本人の希望とスキルが整えばというところですが、メンターや企画キックオフへの参加などの上流工程にもかかわって、自身のキャリアパスにも寄与できるように間口を広げ、積極性の向上を促進することにもメリットがあるかなと感じていて。そういったことを活用しながら、個々でも強く、チームとしても強くを目指しています。

これらをサポートするために、今度は個々ではなく、チームや組織単位で行っていることの一部を次のスライドで紹介します。

チーム・組織単位で行っている取り組み

こちらは取り組みの一部として基本的なところになります。QAチーム内ではもちろんですが、企画・開発など別のセクションの協力のもと、不具合の再発防止や、定期的な振り返りを実施して全体に共有しています。

また、QAで取得できる情報もいろいろあるので、蓄積して、開発状況の良し悪しを確認したり、QA期間中のチームの動きを変えたりというところにもつなげています。そういった内容の実際の事例を、次のスライドでも紹介していこうかなと思っています。

こちらは不具合が本番環境で発生してしまった時の、再発防止に向けた記録の1つですね。ユーザーさんには本当にごめんなさいと思うところなんですけれど。

問題が発生したら、企画・開発・QAといった各セクションの人たちの主要メンバーをいったん集めます。いつどんな問題が発生したのか、各部署で考えられる原因、「どこかに原因があるよね」とかではなくて、それぞれの部署で原因につながるものがなかったかを考えてもらって、今後の対策をどうすればいいかを話し合います。

（スライドを示して）対応策が決まったら、左側にあるようなドキュメントにいったん起こして、それを各セクションに持ち帰り、スタッフさんそれぞれに行き渡るように共有を行います。

QAでも一つひとつの共有を積み重ねることで、今後作るテスト観点の蓄積にもつながりますし、各スタッフが作成するテスト仕様書の精度の向上にもつながるので、再発防止以外にも、ほかの人が出してしまった不具合とかも確認しつつ向上していきましょうということを進めています。

QAから見る開発状況と検証環境の調整

次は、QAから見る開発状況の確認とか、蓄積の部分について軽く触れたいと思います。

（スライドを示して）先ほど言った、バージョンアップの時のテスト期間中に集計されるグラフで、新機能ごとにテストの進捗を日々集計しているグラフの一部となります。

こちらで、テストケースの進みが遅かったり、もしくは不具合が多数出て想定外のことが起きていないかを確認します。

ざっくりとグラフの説明をすると、縦軸がテストの進捗率や不具合の数です。横軸は日付になっています。薄い青で塗り潰されたエリアが後半部分にあると思いますが、これが実際のQA期間という感じです。

あとは、オレンジ色の折れ線グラフが実際のテスト進捗で、0パーセントから始まり、頭が上に着けば100パーセントというものです。

右下のグラフは棒グラフで赤いのとか黒いのが見えていると思いますが、こちらが不具合レポートの数です。赤いものが不具合が起票された数。黒いものが、その不具合が修正されて「問題ありません」とクローズになった数です。

こういったものを作り、テスト期間中でも懸念があればアラートを上げたり、状況を確認しながらフリーチェックと言われるものよりもう少し計画的な、探索的テストに人をどれだけ割くかというリソース配分などを検討しています。

（スライドを示して）この画像で軽く話をすると、背景が白い部分、いわゆるテスト期間中ではない部分から、オレンジの進捗率が上がっているグラフがあります。これは開発者さんがQAに「もうQA開始していいですよ」と回してくれて早めにテスト着手できたものが（データとして）いくつかあるというのが見て取れています。

特に2行目の右2つは、白い期間にもけっこう進捗が上がってきて、テスト開始する時には終わっている。こういう環境って本当にありがたいですね（笑）。

ということから、後半にはテスト仕様書の実行は完了できて、懸念ある機能の探索的テストを重点的にできるということを勘案できたりします。

（スライドを示して）例えば右下のグラフであれば、赤い棒グラフが伸びているのが見えています。そういったところは不具合の検出が上昇しているところなので、テスト仕様書のチェックが完了した後も探索的テスト、フリーチェックに注力したほうがいいというポイントです。

余裕を持って完了できたテストのところから人を回すとか、足りなくても「ちょっとここに注力してみようか」という感じで、チームリーダーと話をして必要であれば動いてもらったりということに使っています。これを全体的に見たグラフもあり、それが次のページです。

（スライドを示して）こちらはテスト進捗とか、不具合レポート数を全体で集計しているグラフの一部です。

左上のいろいろと線がごっちゃに描いてあるほうは、上はテスト仕様書の進捗率です。過去の何年か分のバージョンと比較して、どのような伸びになっているかを表しています。

左側の下のほうは不具合の報告数です。過去のバージョンと比較して、今回のバージョンは不具合が多いのか少ないのかを計っています。

真ん中のピンクの塗り潰し、青い塗り潰しがあるグラフは過去の平均値、塗り潰していない線グラフのところが今回のバージョンです。

上はテストの進捗なので、テスト進捗は平均的よりぜんぜんいいけれど、下の不具合の数を見ると、いつものバージョンの平均的な数より不具合が上がっているというところで、探索的テストを続けたほうがいいのかとか。そういった検討に使っている感じです。

こういった状況を見ながら、最新の開発状況が順調であるかを確認しています。このような情報をチームや組織に共有して、テストが終わった後も振り返り続けることで、よりよい開発環境を維持するためのサポートを行っています。

触れ忘れましたが、右側の円グラフは、各機能別でどれぐらい不具合が出たかです。そのため、面が広いエリアは、全体的に見ても不具合が多く注視すべき対象です。

次は、検証環境の調整をどういうふうにやっているかについても一部触れてみたいと思います。

（スライドを示して）こちらは、モンストをプレイされている実際のユーザーさんが利用している携帯端末が、どういったOSバージョンでプレイしているのか。もしくはどんな機種でプレイしているかを、QAとは別の解析グループから実際の生ログをいただいて、QAグループで月別に集計しているものの一部です。アクティブユーザー数だけは黒線で隠しています。

左上の図が、OS別バージョンの集計です。先ほど言ったアクティブユーザーの数であったり、全体から見た割合や前月からの変動率がどういったものかを集計しています。2022年2月のデータですが、iOS 15系がとても多いですね。

この集計にはAndroidも入っているのですが、モンストをプレイしてくれているユーザーさんは、この月はiOS 14以上が7割を超えている感じです。

右下の図は機種別の集計です。これは機種別ごとにアクティブユーザーさんの数であったり、全体から見た割合。前月からの変動率は先ほどと一緒ですが、そこに加えて、QAグループがその端末を所有している端末かどうか、あとその他簡単な機種性能を記載しています。

世の中の携帯機種もかなりな数になっていますし、モンストの最低動作環境も、やはり古いアプリではあるのでけっこう低めです。昔の機種でもけっこう動くので、カバーしなければならない範囲は本当に広いです。

先ほどのQA期間はだいたい1週間という話だったので、あの人数で期間内に検証を行うには、どうしても取捨選択が必要になります。そういった時に「じゃあ何を重要視すべきなのか」という時にこういったデータを活用しています。

OS機種固有の不具合が起きた場合のリスクは、どの機種やどのOSバージョンがどれぐらい使われているのかなどが確認できるので、QAで次に購入しなければいけない端末、故障してもちゃんと補充しなきゃいけない端末はどういったものかとか、あとはテストに使用する端末の優先度など、環境面整備のために利用しているグラフです。

これらの集計データも基本的にはオープンにしておいて、メンバーそれぞれも見ようと思ったら見れる状態にしています。

なので、リーダーからの依頼でテスト観点として取り入れるだけではなく、各スタッフの間でもテスト設計の際のネタとして活用してもらいたい背景から、こういったものを用意している感じですね。

QA業務で感じるやりがい

それでは最後の項目に移りたいと思います。このようなQA業務ですが、このQA業務で感じるやりがいとか向いている人ってどんな人かをお話しできればと思います。

やりがいというところ。月並みではありますが、かかわった製品が世に出た時、触っていただいた方の反応が見えた時。それがポジティブな意見の時は、非常にやりがいがあります。「やった！」と思いますね。

ただもちろん、テストはしていても不具合が発生しユーザーから「これテストしてないでしょう？」という意見もいただくこともあり、そういった場合は、本当にごめんなさいと。ここで本当に土下座したいレベルでごめんなさいとヘコみます。けれど、「次こそは」と思ったりもします。なので「ダメじゃん」という意見もありがたいと思うことはあります。

あとは、社外だけではなく、社内でQA側を信じてプロダクトのテストを任せてもらえていると感じている時とか、いろいろな意見をQAだけではなく企画さん、開発さんと出し合ってリリースに持っていく過程でも、今回この場で触れていない職種の人たちもいますが、そういった人たちを交えて1つのものを作っていると感じる時も、非常にやりがいは感じます。

そういったことを感じつつもサービスを止めずに、みなさんに安心・安全なアプリを届けられるという状況も、また1つやりがいを感じているというところです。

QA業務に向いている人

次に、簡単に「どういう人がQAに向いているのか」と個人的に思うところですが、キーワードとしては、「会話」。共有し合うことが好きな人とか、「好奇心」「想像力」「慎重」「責任感」などは、けっこう向いている人、もしくは持っている人が多いと感じます。

いろいろ考えて、探って、見つけ出すこと。それを繰り返すのが好きな人は向いている気がしています。けっこう無理矢理ですが、ゲームやパズルが好きな人には相性いいかなと思います。

QA業界は実は未経験で入ってくる人もけっこうな割合でいますし、間口が広いかなと思っています。かつ、開発過程でかかわる業務の幅が本当に広いです。なので思っているよりさまざまな経験ができると思います。また企画を始めとして別職種に進まれる方もいたりするので、少しでも興味を持ってくださる方がいれば、QA業界をのぞいていただけるとうれしいなと思ったりします。