Product QA Engineer

一言でいうと

担当プロダクトの品質に一貫して責任を持つQAで、仕様が固まる前の段階から関わり、利用者にとって何が問題になるかという観点で判断します。

この職種の出自と登場時期

役割の原型は Google の TE（Test Engineer）です。2011年の「How Google Tests Software」は、SET がテスト基盤を作る開発者であるのに対し、TE を「プロダクト全体を見て、利用者への影響と周辺のソフトウェアとの関係を考える役割」と位置づけました。テストの実装ではなく、プロダクトの立場から品質を判断する担当を分けた点が、この職種の出発点です。

国内で「プロダクトQA」という呼称が使われ始めたのは2020年前後です。SaaS企業でQA組織の立ち上げが相次ぎ、その報告のなかでプロダクト単位に担当を置く形が語られるようになりました。Sansan は2020年にQAグループを再出発させた経緯を公開しており、QA組織の作り方を扱う連載記事も国内で継続的に出ています。

現在の求人票では、受託のテスト業務と区別する意図でこの呼称が使われる例が目立ちます。仕様が決まってからテストする役割ではなく、プロダクトの意思決定に品質の観点で加わる役割という位置づけです。

ミッション

責任範囲は、担当プロダクトが利用者にとって使える状態で出ることです。不具合の有無だけでなく、仕様そのものが利用者の目的に合っているか、運用に無理がないかまでを含めて判断します。

そのため、PdM・デザイナー・開発者と同じ場で議論する前提に立ちます。リリース後の不具合件数に加えて、問い合わせの発生量や解約理由の内訳まで品質の指標として扱う組織が増えています。

主な業務範囲

• 要件定義とデザインレビューへの参加。仕様の抜けと運用上のリスクを、実装が始まる前に指摘する
• 品質基準の設定。担当プロダクトでどこまでを許容するかを、PdMと合意して明文化する
• テスト設計と実施。リリース単位のテスト計画を立て、優先度をつけて実行する
• リリース判定と説明。残っているリスクを言語化し、出す判断の材料を提示する
• 不具合と問い合わせの分析。プロダクトの弱い箇所を特定し、改善の優先順位づけに反映する

求められる能力

前提として求められるのは、テスト設計技法と、対象プロダクトのドメイン知識と業務フローの理解です。SQLでのデータ確認、APIの挙動確認、ログの読み取りができると、開発者との切り分けが速くなります。

技術以外では、利用者の立場で仕様に異議を唱えられるかどうかで差が出ます。仕様どおりに動くことと、利用者にとって問題がないことは別だと説明し、優先度の議論に持ち込む必要があります。

この職種に就く人のキャリア経路

多いのはQAエンジニアからの移行です。テスト実施の実績を積んだうえで、上流工程に関わる範囲を広げる流れです。カスタマーサクセスやサポートから、プロダクト理解を武器に移るケースもあります。

その後は、QA Architect やQAマネージャーとして組織の品質を設計する道、プロダクトマネージャーへ移る道に分かれます。プロダクトの意思決定に近い位置にいるため、後者の経路は国内でも実例が増えています。

隣接職種との違い

採用担当の見極めポイント

• 求人票では、上流工程にどこまで関わるかを具体的に書いてください。要件レビューに入るのか、テスト工程だけかで、応募してくる層が変わります
• 職務経歴書を見るときは、仕様に対して指摘した経験を確認してください。テストを実施した経験だけでは、この役割の中心部分を判断できません
• PdMや開発チームがQAの意見を扱う用意があるかどうかを、募集前に確認してください。判断に加われない体制のまま採ると、テスト実施の担当として終わります

求人・市場の傾向

呼称としては新しく、「QAエンジニア」の求人と混在しています。母集団を作るなら、上流工程の経験があるQAエンジニアまで広げないと件数が作れません。そのうえで、要件レビューに参加した経験と、仕様に対して指摘した経験の有無で絞ってください。

求人票では、担当してもらうプロダクトの利用者像と開発体制の人数を書くと、候補者が関わり方を想像できます。

関連キーワード

シフトレフト / 要件レビュー / 品質基準 / リリース判定 / ドメイン知識 / プロダクトマネジメント / 顧客体験