QAエンジニアの大出です。今回はTalentXでQAエンジニアがチームとしてどのように自社サービスの品質保証について取り組んでいるかを説明したいと思います。

一般的には

QA組織のパターンとしては大きく分けて、QAエンジニアを開発チームに所属させて開発チームの一員として働くパターンと、QAエンジニアを独立した横断的な組織にするパターンとがあります。それぞれにメリットデメリットがあります。

開発チームに所属させる場合
- メリット
  - チームの仕様策定の早い段階から関わることができる
  - プロダクトにオーナーシップを持ちやすい
- デメリット
  - 社内の他のQAエンジニアとの連携が取りにくい
  - 1プロダクトに最低1人QAエンジニアを採用しないといけないとするとコストがかかる

それに対して

独立した組織にする場合
- メリット
  - QAエンジニア同士の連携が取りやすい
  - 客観的な視点で品質保証ができる
- デメリット
  - プロダクトにコミットしにくい
  - どのプロダクトにQAエンジニアをアサインするかの判断が難しい時がある

というようになります。

TalentXのQAチームは

それを踏まえてTalentXではどのような組織体制にしているかを説明します。前提としてはTalentXは開発チームがプロダクトごとにMyRefer、MyTalent、MyBrand、MySeriesと4つのチームに分かれています。

開発チームに所属させる場合このようになります

独立した横断的組織にする場合このようになります

TalentXでは結論から言えばTalentXではQAチームを独立した横断的組織としています。

なぜならTalentXのサービスはそれぞれが完全に独立しているわけではなく、プロダクト間でデータを連携していたりモジュールを連携したりしていることから、プロダクト単体での品質保証ではサービス全体の品質を担保できないからです。

たとえば TalentX、Myシリーズ内のモジュール連携を強化。リファラル採用「MyRefer」と採用CMS「MyBrand」の連携機能をリリースのように新しくモジュール連携が開発されたりします。そのような場合、開発が1プロダクトで完結するわけではなく、複数の開発チームが合同で開発が行われることになります。

合同プロジェクトが稼働している状況を図で表すと以下のようになります。最初の2週間をAとBの合同プロジェクトが進行し、3週目からBとCとDの合同プロジェクトが始まるような場合があり得ます。

複数のプロダクトが関わる複雑な開発を行っているチームには多めにQAエンジニアをアサインして慎重な品質保証をするべきである一方、新しい機能の開発より保守運用がメインになるチームにはQAエンジニアのアサインが不要である場合もあります。

そのような形に対応する意味でもQAチームは独立した組織でプロジェクトの体制に応じて柔軟にQAエンジニアのアサインを変えられる体制を目指していきたいと考えています。

このようにして複数プロダクトにまたがる比較的大規模な合同プロジェクトに対してもQAエンジニアとして柔軟にアサインを変更して対応することができ、結果、サービス全体としての品質を担保することができていると考えています。

まとめ

独立した横断的組織とすることによる課題もあります。一つはQAエンジニア一人一人の認知負荷の高さがあります。上記のように複数のプロダクトにアサインするには、複数のプロダクトの仕様や開発のプロセスについて十分な理解があることが必要になります。そこで重要になるのはドキュメントの整備や開発チームとの円滑なコミュニケーションです。

もう一つはQAエンジニアの評価です。 QAエンジニアが開発チームに所属している場合とは異なり、QAチームのマネージャーが各メンバーが各プロダクトでどのようなアウトプットを行ったかについて全てを把握することは難しくなります。そのような中で正当な評価をするには、事前の目標設定の調整や各プロダクトマネージャーへのヒアリングが大切になると考えています。