サービス品質と向き合い続けるインハウスのQAについて語ってみる

2020年12月21日

はじめまして！ QA チームの杉本です。
ゲーム業界・オンラインエンタメ業界で開発・ディレクション・企画運営・PM・CX・QA と、色々やってきました。
QA って総合力勝負だったりするので、どの経験も役に立ってますね。無駄なことなどないらしい。

そして振り返ると、ココネに入社して 5 年経ちました。
あっという間ですね、おかげさまで 35 年の住宅ローン組みました、ありがとうございます。

さて、今回テックブログ編集長から QA の話を書いてよという話があり、何を書こうかなぁと考えたんですが、自分自身が QA という仕事に関わることになってから、色々と分かったことや感じたことを添えつつ、ココネの QA のやり方とか、 QA に求められるスキルとか、その辺りをカジュアルに書いていこうと思います。よかったら最後まで読んでください。

（急げば）1 分くらいで読めます。よろしくお願いします。

① そもそも QA ってなんぞ？

QA とは Quality Assurance = 品質保証、だったりしますが、わかりやすく言えば「提供するサービスに不備がないことを確認して保証する役割」ですかね。
質の高いサービスを提供するために存在しています。すべてはお客さまのため。

② QA って何やってるの？

いろいろな手法がありますけど、ベースは「テスト項目書」を作って、テスト項目を１つ１つ確認して、項目書がすべて「OK」になれば QA 完了、というやり方です。

勘のいい方は気づいたと思いますが、だとするとこの「テスト項目書」の質が QA の質を決めるんじゃないのか、という話ですが、その通りです。
QA したのにリリース後にバグ出てるじゃん、の多くは項目書の問題です。

③ テスト項目書の質…というと？

ですよね、項目書って外から見ると結構ブラックボックスで、質の評価とか、どうやって質を上げるのかとか分かりにくいと思います。
なので、ココネの QA チームで実践してるやり方をいくつか紹介します。

テスト項目書は、以下の 3 分類を網羅するようにしています。

A. 仕様書の通りに動作することを確認する項目
B. 仕様書に書かれていない箇所を明確にしつつ確認する項目
C. 既存機能への影響が無いかを確認する項目

あれ？ B って必要？と思うかもですが、特殊な条件や組み合わせまで含めた全仕様が網羅されている仕様書というのはほぼ存在しないので、テスト項目書を起こすタイミングで、ここを洗い出します。QA の腕の見せ所その 1 。

C も B に似てますが、いわゆるデグレ（デグレード＝これまで動いていた機能に問題が発生すること）とかリグレッションとか言われる分類です。その時に実装した箇所が影響するであろう場所を特定して項目を起こします。 QA の腕の見せどころその 2 。

で、実際には C はサービスごと（製品ごと）に特性や特徴があるので、その特徴をまとめて「影響範囲チェックシート（通称、QA 虎の巻）」として管理・運用しています。仕組み化重要。

QA虎の巻（影響範囲チェックシート）の一部。一般的な注意点（値がゼロの時も確認せよとか、ページ内で期限切れした後の処理を確認せよとか）も書いてあるけど、重要なのは「このサービス固有の注意するべきチェック観点」ですね。

ちなみに、リグレッションテストとして、全機能を一通り洗い直すテストをする所も多いと思いますが、ココネではなるべくやらないようにしています。費用対効果が良くないので。
荒い網で魚をすくって取り逃すより、魚がいるであろうポイントを絞って一本釣りするスタイルです（なぜ釣り）。

④ 他に QA の品質を決めるポイントは？

もちろんテスト担当者のスキルも重要ですが、事前準備としてのリスクマネジメントとスケジューリングが肝要ですね。

QA 担当者は PM 的な思考が必要で、見えているリスク・見えていないリスクも想定した上で、企画者や開発者と相談して、それらのリスクをいかに最小限に抑えるか、リリースまでに安全に QA を完了するためにどれだけの日数が必要かを見積もる必要があります。

QA 工程のよくある誤解で、テスト項目数を見て、これなら 1 日で済むのになんで 3 日かかるの？みたいな話がありますけど、不具合が見つかれば修正する時間も要るし、設定を変更してもらいながらテストする場合はテスト担当者だけの時間軸ではテストは進行しないのです。修正ペースも人によって違いますからね。

⑤ QA ってどういうスキルが必要なの？

結構難しくてクリエイティブさが求められる仕事です。
JSTQB も良いですが、ことゲーム系 / エンタメ系の QA においては、問題解決を中心としたビジネススキルの方が重要だったりします。~~偉い人にはそれがわからんのです（~~

多岐にわたるビジネススキル（情報整理、問題解決、ロジカルシンキング、文書化、コミュニケーション、折衝、プロジェクト管理、etc.）
アプリ・サービスの仕組みを理解する力（開発経験は無くても大丈夫）
テスト実施フェーズでは、進め方を組み立てて準備して無駄なく最短距離で進める力（ゲームが上手い人はこれも上手い）

タイプ的には、この辺りにピンと来る方が向いてる気がします（もちろん一例）

問題解決や情報整理が得意
曖昧さよりも厳密さを好む
事前準備とか仕組みが好き
何事も改善することが楽しい
好きなゲームの wiki とか作れる
効率プレイが得意
集中力を維持できる
チームプレイが好き

⑥ QA チームとプロジェクトや他部署との関わり方は？

各プロジェクトチームに QA 担当者としてアサインされる形でプロジェクトに参加しています。
担当プロジェクトは基本的には 1 つで、掛け持ちは品質も不安定になるし、責任の所在が曖昧になるので、なるべく避けています。仕事において責任の所在、はとても大事。

ちなみに QA チームは開発部に所属していて、ゆえに開発者との距離が近くて相談しやすいですし、開発者の QA 工程に対する理解も深く、とても協力的です。控えめに言って神。この辺りはココネの社風でもありますね。

⑦ もうちょっと詳しく話を聞けます？

よろこんで！

他にも、各サービスの品質を「品質KPI」という指標にして品質の比較〜維持向上を目指したり、Android 端末を遠隔操作できる Open STF を導入してコロナ時代（リモートワーク時代）に対応したり、Airtest を使った自動テストを導入したり、…と色々やっていますが、書ききれないので、興味をお持ちの方は是非気軽に遊びに来てください。