QAエンジニア

一言でいうと

プロダクトが要求どおりに動くことを担保する職種で、テストの設計と実施に加えて、どこに不具合が出やすいかを予測して開発プロセスに手を入れます。

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

ソフトウェアの品質保証は製造業の品質管理から派生した領域で、専任の担当を置く実務自体は長い歴史があります。職種としての国際的な整備が進んだのは2002年で、ISTQB（International Software Testing Qualifications Board）が設立され、テスト技術者の資格体系が国をまたいで共通化されました。ISTQB のシラバスは「テストの独立性」を段階で示し、開発者自身が行う形から、開発チーム内の専任テスター、独立したテストチーム、外部組織まで並べて整理しています。

国内では、JTCB が2006年5月に JSTQB（Japan Software Testing Qualifications Board）へ名称を変更し、ISTQB との相互認証のもとで資格認定を開始しました。求人票で「QAエンジニア」という職種名が広く使われるようになったのはこの前後からです。

現在の国内では、QAの置き方が会社ごとに大きく違います。エムスリーは自社のQA組織について、開発者がテストを実施しQAがレビューする形、QAがテストの一部または全部を担当する形などを比較したうえで、自社での採用形態を公開しています。同じ「QAエンジニア」でも、実務の中身は組織の形で変わります。

ミッション

QAエンジニアが揃えるのは、リリースしてよいかどうかを判断するための材料です。不具合をすべて見つけることではなく、どのリスクが残っているかを説明できる状態を作ることに成果があります。

そのため、テスト実施の件数だけでは評価できません。リリース後に発見された不具合の件数と重大度、テスト工程で検出できた割合、手戻りの発生量といった指標で見ることになります。

主な業務範囲

• テスト計画とテスト設計。仕様から観点を洗い出し、優先度をつけてテストケースに落とす
• テストの実施と不具合の管理。再現手順の記録、開発者との切り分け、修正後の確認までを担当する
• 要件レビューへの参加。仕様が固まる前に曖昧な箇所と抜けを指摘する
• リリース判定。残存リスクを整理し、出すか止めるかの判断材料を提示する
• 品質プロセスの改善。不具合の傾向を分析し、テスト以前の工程に対策を戻す

求められる能力

技術面では、テスト設計の技法（同値分割・境界値分析・状態遷移など）と、対象システムの構造を読む力が土台になります。求人票では、SQLでのデータ確認、APIテスト、テスト自動化の経験が要件に入る例が増えています。

非技術面では、仕様の曖昧さを言語化する力が重く見られます。書かれていない条件を見つけて質問に変える作業が仕事の中心にあり、開発者と対立せずに指摘を伝える姿勢も同じくらい重く見られます。

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

入口はテスターやテスト実行の委託業務が多くを占めます。テスト設計を任されるようになり、そこから計画とマネジメントへ広がる流れが一般的です。開発エンジニアから品質側へ移るケース、カスタマーサポートから不具合の切り分けを経て移るケースもあります。

そこから先は、QA Architect やQAマネージャーとして組織全体の品質を設計する道、SETとして自動化基盤の開発へ進む道、Enabling QA として開発チームの自走を支援する道に分かれます。

隣接職種との違い

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

• 求人票では、QAがどの工程から関わるかを明記してください。要件段階から参加するのか、完成後のテストだけかで、必要な経験が変わります
• 職務経歴書では、テスト設計を自分で行ったかを確認してください。渡されたケースを実行してきた人と、観点から作ってきた人が同じ職種名で応募してきます
• 自動化の経験は、書けるのか読めるのかを分けて聞いてください。ツールの利用経験とコードを書いた経験は別物です

求人・市場の傾向

母集団はQA関連の職種のなかでは厚い部類ですが、テスト実行中心の経験者が多数を占めます。設計から担当できる層は限られるため、要件を高く置くと候補者が急に減ります。実際の件数は媒体ごとの職種カテゴリの定義で変わるので、自社が使う媒体の検索結果で確認してください。

求人票では、既存のQA体制の人数、自動化の到達点、開発チームとの関わり方を書くと、候補者が自分の役割を想像しやすくなります。

関連キーワード

JSTQB / ISTQB / テスト設計技法 / シフトレフト / リリース判定 / 不具合分析 / テスト自動化 / 品質保証