はじめまして、ココネのQAディレクターのSです。経歴としては芸術系の大学を卒業後、フリーで映画の仕事をした後にQA業界に入り今年で10年目、ココネに入社して5年目となりました。

現在QA室内のQA第２チームという部署に所属しており、主に新規アプリ開発のQAディレクターとして品質保証業務のディレクションを行なっております。

今回はココネの新規アプリ開発向けの「新規立上げQA」って何をやってるの？を話していければなと考えております！

どうぞよろしくお願いします。

立上げQAロードマップ

まずはQA準備開始からアプリリリースまでのざっくりQAのロードマップになります。

タイトルの規模にもよりますが、QAディレクターはリリース予定の6ヶ月前にはアプリ開発チームに合流していることになりますが、アプリ開発の規模によって合流タイミングは前後します。

・QA準備期間①：仕様把握とQA観点出しと、MECE化
・QA準備期間②：工数出し、QAスケジュール作成、外部QA会社さんの調整
・QA開始準備：テスト項目書準備、QA時に必要なものの準備
・QA検証中：QA進行とそれに伴う課題解決
・審査〜リリース期間：審査提出とリリース対応、運用体制の準備

QA準備期間①

まずは新規リリースを予定しているアプリの仕様を把握するところから始まります。

・アプリの仕様把握：アプリの仕様書の確認、QAが必要となる機能のリストアップ
・開発メンバー（クライアント、サーバー）への開発進捗の確認：単体機能のQAや統合QAの開始時期の相談、開発スケジュール把握
・情報収集：仕様書をQAのための情報の基準としつつ、最新の情報はSlackやワイヤー、Figamaなどのツールから集める

上記で書いたことはこの期間だけということはありませんが、まずはここからという感じです。
特にここで意識して行うことは「QAが必要となる機能のリストアップ」となります。
QAがテスト設計をするにあたり、一つの項目書でテストが必要となってくる機能の範囲がバラバラになって被ってしまうのを防ぐために、整理することを目的としています。

この時に注意する部分は「どのテスト項目書でどの機能を担保しているかを整理すること」です。

後に項目書の１つ１つを独立してレビューした場合に、その機能ごとに網羅されていることの確認はできるが、一部の機能が複数の項目書で全く同じチェックをしてしまうかもしれない、という無駄は残るかも知れないが、まずはざっくりですがどちらでその機能を担保すべきなのかは整理しておきます。
またココネでは外部協力会社さんと協力してテストの設計を行いますので、明確にどの項目書でどの機能の確認を行うかは明記しています。

QA準備期間②

前の工程で準備の土台はできたので、ここからは整理した情報を元に本格的にQAに必要なものを準備していきます。

・工数出し
・QAスケジュール作成
・協力会社さんの調整・合流

工数出し→QAスケジュール作成→協力会社さんの調整・合流※という順序になっています
※実際は工数出しぐらいのタイミングで外部協力会社さんには頭出しを行っています

工数出しに関しては、前述の工程で仕様把握は行っているのである程度イメージできています。具体的に数字を置いてあげることをこの工程では行います。

そして工数を元にしたQAスケジュールの作成です。
スケジュール作成時に意識することは2つ

・開発の進行状況
・各機能の影響範囲

前者に関してはそのままで、開発が終了していないものをQAで確認はできていないので、開発スケジュールと相談が必要です。
特に開発的にも早めに見て欲しいもの・QA的にも早めに見たいものはスケジュールの前半に持ってきて大きめの不具合は早めに検出するようにします。
課金機能などがその内の一つで、社内の別のチーム（決済担当チーム）も関わるので早めに不具合を検出しておかないとスケジュールが間に合わなくなります。

機能の影響範囲に関しては、機能として独立していて他の機能に影響が少ないものを前半に持ってきて、ブラッシュアップで変更が入る箇所やメイン（コア）体験の部分は後ろのスケジュールになることが多いです。
またブラッシュアップで変わる部分は先に企画者にヒアリングし、それがメイン機能に大きく関わりそうな場合、開発と相談して影響範囲が広い部分は早めに対応してもらえるように調整します。

ココネでは一部QA業務を外部の協力会社さんと共に行っておりますのでこのタイミングで各社さんにお声がけし、リリースするタイトルに合う会社さんに合流してもらいます。

QA開始準備

テスト設計〜レビュー、アイテムQA項目書のテンプレの準備を行います。

内部にいる設計者や協力会社さんに設計を依頼しており、作成された項目書に対するレビューをQAディレクターは行っています。
立ち上げQA時の項目レビューで気にして確認するのは、「どの項目書で何の機能をどこまで確認しているか」の部分です。

例えば、「課金機能」と「ガチャ機能」があるアプリで
「課金機能」の項目書作成者は、課金ができることの確認をホーム画面（トップ画面）でしか確認していなかったとすると
「ガチャ機能」の項目作成時には、ガチャ画面での課金実施や一次通貨不足時の課金誘導の確認を入れなければいけなくなります。

設計を始める前にある程度擦り合わせは行いますが、レビュー時にもしっかり確認しておかないとQA終了時に確認漏れが発生してしまいます。

またこのQA検証開始直前になってくるとQAディレクターは実機でテストできる状態であるかを確認することが増えていきます。開発は機能の作成を終えると、次の機能の開発をしているので実際に検証開始してみると動かないってことはザラにあります。
新規立上げ時に工数が無限にあるわけではないので、現状のアプリの状態をアプリ開発の責任者に伝えQAができる状態に修正してもらうことも必要になってきます。

最後にテストに必要なものの準備もこのタイミングで行っていきます。

・デバッグ機能の相談
・検証端末の準備
・テスト環境準備（開発相談）
・各種アカウント準備
・QA用のSlack窓の準備
・QA用のJIRAプロジェクトの準備
などなど

QA検証中

単体機能QA→統合QA→審査対応QA
で進めることが多いです。

・単体QA：一部の機能が確認することのできるクライアント（開発が進むと複数の機能が入った状態でビルドされます）
・統合QA：全ての機能が実装されているクライアント
であり、特に新規立上げ時には単体QA時に一通りの機能が動いていることを確認し、統合QA時には他の機能と掛け合わせた時に問題なく動いているかの確認を行っています。

QAディレクターはQA進行とそれに伴う課題解決を行います。
・全体進捗把握
・不具合内容把握
・開発折衝（テスターもやるが大きめのものはQAディレクターが対応）

起票されているバグを全て修正しないとリリースできない！という訳ではありません、アプリ開発責任者と相談してリリースできる品質をコントロールするのも（その交渉スキルも含めて）QAディレクターの仕事の一つかと思います。

プライオリティーが高いバグ（進行不能や機能が正常に動かないなど）の修正を開発には優先してもらい、プライオリティーが低いバグの中からQAとして修正してもらわないとリリースできないものをアプリ開発責任者と相談してプライオリティーを上げていきます。

実際この作業を行うと開発は優先度が高いものからドンドン修正を行い、軽微な不具合は最後まで残り、結果としてリリース時の品質は高くなっていきます。

また期間内でQAを完了させないといけないので以下の部分は注意します。

・項目に沿ったテストを進行させること
・不具合の再現に時間を取らないこと
・テストのブロッカーは早めに解消してもらうこと

項目に沿わずに寄り道をしてしまうと項目の消化がされない、不具合の再現に時間を取られると項目の消化が進まない、ブロッカーを解決しないと項目が進行できない、とわかるようにとにかく「項目進捗を優先」しないとリリースを行えなくなってしまいます。

期間内にテスト環境でのQAを全て完了させると審査提出準備に入ります。

審査〜リリース期間

審査提出を行う前に、もちろんですが本番環境で最終のQA確認を行います。
審査提出とは App Store や Google Play でアプリを公開する前に行わる各社のガイドラインや規約にしたがっているかの審査に提出することです
またストアのガイドライン準拠に対応できているかの確認も審査提出前にテストを行います。
通しチェックや貫通テストなど色々言い方はあると思いますが、ほとんどの機能が一通り触れるような項目書を作成しテストを行います。
ここでは機能が正常に動いていることを確認できれば問題ないので、細かくは確認は行いません。

QAの最終確認が終われば審査提出です！
これでQAの仕事も終わり！というわけではなく…審査が終わっても

・リリース時に必要なサーバー設定の確認
・アイテムQAの検証
・次の審査バージョンのQA検証
・運用系施策のテンプレート項目書の準備

とまだまだやることはありまして
問題がなければこのあと本番リリースを行い、一旦ここで新規立上げQAは終了になります！

まとめ

今回の内容はざっくりの新規立上げQAの流れなので、細かいところまでは書ききれておりませんが、少しでも参考になると良いなと思います。
立上げQAを行っている際にQAディレクターって何やってるんだっけな？を整理しながら臨んだおかげで頭が整理できて自分にとってプラスになりました。

実際は開発の状況やブラッシュアップの状況により現場で臨機応変に対応しなければならず、ほぼスケジュール通りには動けなかったので、ここら辺の情報を早めに取りに行ってQA検証がスケジュール通りに動けるようにトライしてみたいです。（難しいのはわかってる）

という訳で、ココネでは今後も新規アプリの開発をドンドン行っていく予定でいますので、新規立上げのQAディレクターの仕事やインハウスのQAに興味のある方は是非、ココネのQA室に遊びに来てください！

QAに関する過去のブログも参考にどうぞ。

ソフトウェアの品質向上のためのQA手法
サービス品質と向き合い続けるインハウスのQAについて語ってみる
問い合わせを翻訳するのにGASのWebアプリ＋DeepL APIを使ったらお手軽でいい感じだった話