GreenでQAエンジニアを採る｜品質の役割を求人票で伝える

QAエンジニアの求人票を開いた候補者が最初に確かめるのは、その会社で品質保証がどんな役割を任されているかです。リリース直前にテストケースを消化する係なのか、開発の早い段階から品質のつくり方を決める立場なのか。ここが読み取れない求人票は、経験のある候補者から見送られやすくなります。この記事では、Greenで中途のQAエンジニアを採るときに、品質の役割をどう言葉にし、スカウトと選考にどうつなげるかを整理します。Greenは、IT・Web業界の中途採用を中心とする求人サイトで、株式会社アトラエが運営しています。

QAエンジニアの候補者が気にしていること

QAの経験者が転職を考える理由として多いのは、「品質について意見を言っても、開発の後ろで受け止めるだけになっていた」というものです。そのため、求人票では次の点が見られています。

• 関わるタイミング：仕様を決める段階から入るのか、実装が終わってから入るのか
• 開発チームとの関係：同じチームに属するのか、別の部署として検証を受け持つのか
• 自動化の位置づけ：テスト自動化に時間を使えるのか、手動の検証が中心なのか
• リリースを止める権限：重大な不具合が見つかったとき、誰がどう判断するのか

最後の点は求人票で触れない会社が多いのですが、経験者ほど気にします。「品質の判断はQAと開発責任者が一緒に行う」のように一文あるだけで、組織の中での立ち位置が伝わります。

品質の役割を3段階で書き分ける

自社のQAが今どの段階にあり、入社する人にどこまで期待するのかを、求人票の冒頭近くで示します。

段階を書くときは、現状と、入社後に目指す段階の両方を示すと伝わりやすくなります。「現在は検証中心だが、一年をかけて仕組みづくりに移したい」と書けば、それに関わりたい候補者が集まります。

テストの対象（Webアプリ、スマートフォンアプリ、API、業務システムなど）とリリースの頻度も添えます。同じQAでも、毎日リリースする環境と、数か月ごとにまとめてリリースする環境では、仕事の組み立てがまったく違うからです。

エージェントベストの見解

QAエンジニアの求人を出す前に、先に開発責任者と決めておきたいのは「QAの指摘で、予定していたリリースを延ばすことがあるか」です。これが決まっていないまま採用すると、入社した人は不具合を見つけても判断を委ねる先がなく、結局は「見つけて報告する係」にとどまります。経験のある人ほどそのことに早く気づきます。当社が求人票の作成を手伝うときは、この問いへの答えを開発責任者から直接もらい、求人票の「チームの体制」の欄に反映します。答えが「延ばさない」であっても構いません。そう書いたうえで、検証の効率化や自動化に重きを置く人を対象にすればよいのです。役割の大きさより、書いてあることと実際が一致していることのほうが、入社後の定着に効きます。

対象の絞り方と「気になる」の使い方

Greenでは、企業から候補者へ「気になる」やスカウトを送れます。QAエンジニアの候補者を探すときは、職種名だけでなく、前職での立ち位置に注目します。

1. 自社の段階と同じか、一つ先の段階を経験した人を優先する：検証中心の会社が仕組みづくりを進めたいなら、自動化の導入経験がある人
2. 開発経験のある人も対象に入れる：テスト自動化を進めたい会社では、開発者からQAに移りたい人が合うことがある
3. ドメイン経験は歓迎条件にとどめる：金融や医療など規制のある分野を除き、業界知識は入社後に補える

開発経験者に送る場合は、スカウト文面で「なぜQAとして声をかけたのか」を書きます。開発職の募集と混同されると、候補者が戸惑います。「コードを書ける人が品質の仕組みを作ることに、当社は価値を感じている」と一文添えるだけで、意図が伝わります。

「気になる」は、反応を見るための軽い接点として使えます。開発経験者のように、QAへの関心が経歴から読み取りにくい相手には、いきなり長いスカウトを送るより、まず「気になる」で様子を見て、反応があった人に役割を詳しく書いた文面を送るほうが、お互いの負担が小さく済みます。

選考では「品質をどう説明するか」を見る

QAエンジニアの選考では、テスト技法の知識を確かめることも大切ですが、それ以上に、品質の問題を開発チームにどう伝えてきたかを聞くと、入社後の働き方が見えます。

• 不具合が多いと分かったとき、誰に、どんな形で伝えたか
• 自動化を進めようとして、うまくいかなかった経験と、その理由
• 品質の状態を、開発以外の人（営業や経営）にどう説明したか

実技を確かめたい場合は、自社のサービスの一画面を見せて「この画面をテストするなら、何から確かめるか」を口頭で話してもらう方法があります。準備の負担が小さく、テストの観点の広さや優先順位のつけ方がよく表れます。仕様書が手元にない状態で、どんな質問を返してくるかも見どころです。品質保証の仕事では、分からないことを分からないと言い、確かめに行けるかどうかが成果を左右するからです。

面接官には開発責任者が入るのが望ましいです。QAと開発の関係は、入社後の働きやすさを大きく左右するため、候補者も開発側の人と話したいと考えています。

エージェントベストの見解

QAエンジニアをGreenで募集したあと、運用が止まりやすいのは、応募数が少ないときに求人票の条件をゆるめる方向に動いてしまうケースです。応募が来ないと「自動化の経験」を必須から外し、「未経験可」に書き換えたくなります。しかし、条件をゆるめると応募は増えても、仕組みづくりを任せたいという本来の目的に合う人が減ります。当社が運用を見るときは、条件を変える前に、まず「気になる」とスカウトの送り先を見直します。待っている間に、自動化の経験がある開発者や、別業界のQA経験者へ声をかける範囲を広げるほうが、求人票の軸を保ったまま候補者に会えます。条件を変えるのは、送り先を広げても反応がないと分かってからでも遅くありません。

まとめ

• QAエンジニアの候補者は、品質保証がどんな役割を任されているかを見ている
• 検証中心・仕組みづくり・組織への浸透のどこにいて、どこを目指すかを書く
• リリースの判断に誰が関わるかを一文でも書くと、組織の中での立ち位置が伝わる
• 対象は前職での立ち位置で選び、開発経験者にも声をかける
• 応募が少ないときは、条件をゆるめる前に送り先を見直す

よくある質問

テスト自動化だけを担当する人を募集してもよいですか

問題ありません。その場合は「テスト自動化エンジニア」のように職種名で役割を明確にし、手動の検証をどの程度担うかも書いておきます。自動化専任のつもりで入社した人が、手動の検証に多くの時間を取られると、期待とのずれが生まれます。

QAの経験がない人を採用して育てることはできますか

できますが、社内に教える人がいるかどうかが前提になります。一人目のQAを未経験で採ると、本人が手探りで仕組みを作ることになり、負担が大きくなります。教える人がいない段階では、経験者を先に採る順番を検討します。

品質管理と品質保証は、求人票で区別したほうがよいですか

ソフトウェアの会社では「QA」「品質保証」と書くのが一般的です。製造業の品質管理と混同されないよう、扱う対象がソフトウェアであることを職種名か冒頭で明示すると、応募の行き違いを防げます。