こんにちは。QAエンジニアの渡辺です。 1年半前にアソビューにジョインし、現在QAリーダーをさせていただいております。過去のQAチームのブログを見ると様々な掲載があり、外から見て現在の体制が分かりにくいかと思いましたので、一度、アソビューのQA体制の過去〜現在と、これからの方向性をまとめてみたいと思います。

アソビューのQAチームの紹介

アソビューのQAチームは、現在5〜6名で構成されています。各プロダクトチームに1名〜2名ずつQAメンバが入っており、横断的な業務を全員1割ほどしています。

過去〜現在のQA体制と、プロダクト成熟度の関係

過去に遡ると、2019年ぐらいからQA体制は存在しています。
tech.asoview.co.jp
3名のチームで、狩野モデルを軸にしつつQAの方向性が決まってきます。
medium.com
プロダクトライフサイクルにおけるこの時の成熟度は、成長期に当たるのかなと思います。

＜参考＞

プロダクトライフサイクルと成熟度

導入期：市場に導入されて販売が開始された時点から、徐々に販売数が伸びてゆく期間。利益はまだない。

成長期：市場で受け入れられ、大幅に利益が得られる期間。

成熟期：製品が市場の潜在的購入者のすべてに行き渡り、成長期での販売の伸びに比べて減速する期間。利益は安定的か、競争の激化によって減少。

衰退期：製品の売上が減少してゆき、利益もそれに伴って減少する期間。

引用元：

https://ja.wikipedia.org/wiki/%E8%A3%BD%E5%93%81%E3%83%A9%E3%82%A4%E3%83%95%E3%82%B5%E3%82%A4%E3%82%AF%E3%83%AB/

ですが、2021年にはQAは1名に減ってしまいます。
その後、第三者検証会社が入るようになりQA =「テストケースを作成し、テスト実施をする」の色合いが濃くなってきたように思えます。
（第三者検証会社の方が悪いというわけではなく、成長期〜成熟期のプロダクトが多くテストすべき対象も多いのでテスト中心の品質保証活動が必要だったということを補足させていただきます。）

2022年10月に私が入社したころ、私はあるローンチ前サービス（以下、サービスD）のQAに参画しました。
2023年6月までは、以下の状態でした。

サービス	プロダクト成熟度	QA体制
サービスA	成長期〜成熟期	開発チームでQAを自己組織化
サービスB	成長期〜成熟期	第三者検証会社3名
サービスC	成長期〜成熟期	第三者検証会社1名
サービスD	ローンチ前	社内QA2名、第三者検証会社4名

2023年6月以降は、サービスAがリニューアルすることと、よりシフトレフトで品質改善をしていきたい目的もあり社内QAがサービスAに増えます。
また、2024年以降はサービスDがローンチされ導入期に入り、第三者検証会社の方は抜けてQAは1~2名体制になります。
また、サービスBは事業拡大もあり、直近でも社内QAを増やしQA体制を強化しています。

サービス	プロダクト成熟度	QA体制
サービスA	成長期〜成熟期	社内QA1〜2名、第三者検証会社2名
サービスB	成長期〜成熟期	社内QA1〜3名、第三者検証会社1〜2名
サービスC	成熟期	社内QA1名
サービスD	導入期	社内QA1〜2名

現在のQA体制とQMファンネルの比較

QA領域の体制やロールとしての考え方として、QAファンネル、QMファンネルというものがJaSSTでも公開されています。
下の図は、公開されているQMファンネルの図や内容を参考に、私なりに解釈して簡略化したものです。

引用元：品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話（3D版） | PPT

QAファンネルは、QAに必要なロールを示したもののようです。
品質における領域は、最近はSREやSET(自動化)、テスト、QAなど細分化されつつあるので、 QMファンネルは、QAファンネルの5段階のロールが、PE (=SET, SRE)、TE (=テスト)、QAのそれぞれに存在するとして定義されたものです。

(補足)

QA=Quality Assurance(品質保証)
QM=Quality Management(品質管理)

ただ実際はこのすべてのロールを満たす体制は現実的ではなく、単なる細分化による分業になってしまっては品質改善はスピードアップしないと思うので、開発組織全体としてこのロールの考え方のバランスが保てればいいのではと思います。
実際、すでにQAチーム以外で担っている部分も多いです。
具体的には、PEについてはVPoT、SREチーム、開発チームが満たせている側面があります。
また、プロモーターやコンサルタントに当たる部分は、VPoT、VPoE、PdMやスクラムマスターが満たせている側面があります。

インプロセスTEとスプリットTE

QAチームとしては、主にQA、TEの領域でコーチ、コンサルタント、プロモーターの視点も必要と思いますが、

上記の通り他チームやロールで満たせている側面がある
インプロセス、スプリット（フェーズゲート）で未だ改善が必要なところが多い

ため、すでに他チームで担えている領域との整合性や情報連携を図りながら、目の前のインプロセス、スプリットの品質改善から着手していく必要があると考えています。
インプロセス、スプリットのTEとQAの領域において、QMファンネルと各プロダクトにおける現在のQA体制やQA状況を比較すると以下のようにほぼTE（=テスト）に近いのが現実です。
このTEのテスト内容自体も、プロダクトやチーム毎に、テスト戦略の有無やテスト拡充の網羅度に違いがあるのが現実です。

サービス	QMファンネルと比較したQAの現実	インプロセス	スプリット(フェーズゲート)
サービスA	インプロセスTE、スプリットTE	TEだけでなくQAを実行する転換期	TE
サービスB	インプロセスTE、スプリットTE	TEだけでなくQAを実行する転換期	TE
サービスC	インプロセスTE、(スプリットTE)	TE	TE
サービスD	インプロセスTE、スプリットTE	TE	TE
横断、その他	活動開始中	-	-

なお、横断、その他の部分は、現実はQMファンネルと比較すると必ずしも一致した内容ではありません。
JaSST'14、およびJaSST'24では、QA/テストエンジニアが個人レベルで必要な以下の4つのスキルが発表されています。

テストスキル
ソフトスキル
ITスキル
ドメイン知識

引用元：https://jasst.jp/symposium/jasst24tokyo/document/B3.pdf

このうち、ドメイン知識は当然の如く、転職やプロダクトチーム変更によりリセットされます。
ITスキルも、転職やプロダクトチーム変更により今までのITスキルと違う領域が必要な場合があります。
社内QAは新しい方の割合も多いため、まずドメイン知識は不足しています。
そのため、営業、CSからのプロダクトについての問い合わせの一次受け対応をさせていただいております。

システム障害や不具合であれば、各プロダクトチームへ依頼
仕様確認であれば、ハンドリングして回答（必要に応じて各プロダクトチームにも依頼）

をするようにし、本番で発生したシステム障害や不具合の発生状況は各プロダクトチームへフィードバックしています。
傾向を見てプロダクト品質として弱い観点をインプロセスTEのテスト設計に組み込んだり開発チームへフィードバックしたりしています。

これからのQA目標と方向性

全体的には、テストとしてのQA業務と、品質改善のための施策をバランスよく実施していくのを目標にしています。
具体的には、以下の3つの目標を持てればと考えています。

インプロセスTE、QA目標

前述の通りテストについては、テスト戦略の有無、テスト拡充の網羅度のばらつきがプロダクト毎に違います。
テスト戦略がないプロダクトはテスト戦略から行い、テスト拡充の網羅度が足りないプロダクトは網羅度を向上できればと考えています。
また、テストだけでなくテストを軸とした品質向上施策もバランスよく実施したいと考えています。

テストで気づいたプロダクト品質をもっと開発組織にフィードバック
開発プロセスやテストプロセスの中で、より品質向上するためにどの部分を改善したら良いか分析

し、本質的に必要な品質向上施策を推進できることを目標に置きたいと考えています。
テスト戦略やテスト拡充の網羅度が向上すると、テスト業務がリリースまでに回しきれない課題が出てくることが予想されるので、PEの領域で全体のテスト自動化率向上も必要となってくると考えています。

また、スクラムマスターやPdMと目線を合わせながら、これらの活動推進をしていく必要があると考えています。

スプリットTE、QA目標

リリース前テストを実行するだけでなく、リリースにおける品質基準をより明確にし基準に対してプロダクト品質が適切な状態かを測定し品質改善のフィードバックループが回るようにしたいと考えています。
品質基準については、営業やCSの問い合わせから得たサービス利用者からのフィードバックを大事にして、まずは目の前の品質改善につながることを仮説検証を繰り返しながら実施していきたいと考えています。

プロダクト成熟度や変化に応じた横断的なQA

プロダクト成熟度や組織体制などは、常に変化していくものだと思います。
その中で、QMファンネルのバランスが必要という考え方は頭に入れつつも、そのロールにこだわって目の前の品質改善がされないことがないようにしたいと考えています。
プロダクト品質の本質的な品質改善につながる部分を常に意識して、変化にも強いQAを実行することを目標に置いています。
また、各サービスやプロダクトは互いに連携もしており、互いに影響し合っている側面があります。
インプロセスだけでなく、横断的なQAやテスト業務も一定の割合でバランスよく実施が必要と考えています。