QAエンジニアの採用・選考 どう採るどう通る？連載の第4回です。
前回の記事では、求職者の立場から職務経歴書や面接で「採用したい」と思わせるアピール方法について解説しました。第2回・第3回は求職者側の視点での話でしたが、今回からは募集側が意識すべき、QAエンジニアの採用を成功させるためのポイントをお伝えしていきます。
- QAエンジニアの募集を出しているけれどなかなか応募が来ない
- 応募はあるけれど、求めている人材とマッチしない
といった悩みを持つ企業やエンジニア採用担当の方のお話を伺うことがあります。
市場におけるQAエンジニアの母数は開発者等に比べて少ないですし、かつ第1回でも触れたように、ハイレベルな人材が求められがちなので、結果として採用に苦労している企業が多い状況です。
本記事では、そのような状況の中で求めるQAエンジニアを採用するために必要な「QAに対する理解」を中心に説明します。
記事一覧：QAエンジニアの採用・選考［どう採る どう通る］
よくある「もったいない」パターン
私は過去に事業会社でQAエンジニアの採用を担当し、書類選考や面接を行ってきました。また、個人活動としてQA採用に悩む企業の方から相談を受けることも多くあります。その中で、「この書き方ではなかなか応募が来なさそうだな・・・」と感じる、もったいない募集のパターンがいくつかありました。
たとえば以下のようなものです。
- 業務内容が「テスト業務をお任せします」だけで具体性がない
- 必須要件が「品質評価業務の経験＊年」などふわっとしている
- プロセス改善や品質向上への取り組みに言及がない
- 「単純作業」「コツコツ作業できる人向け」などの表現が使われている
- 開発との協調や上流工程への関与について触れられていない
- 給与が開発職に比べて極端に低く設定されている
- テスト、評価、検証などの用語が混在している
類似のものや相互に関連するものも含まれますが、これらに共通しているのはQA業務や品質への理解が浅いということです。
理解が浅いままだと、QAエンジニアからは「この会社はQAのことをわかっていないな」や「リスペクトが無いな」などと判断されてしまいます。理解やリスペクトのない状況に敢えて飛び込んでいくエンジニアは、あまり多くはないでしょう。（飛び抜けて待遇が良い、などであれば別かもしれませんが・・・）
QAについて理解すべきこと
では、QAを理解するとは具体的にどういうことでしょうか。大まかに3つのポイントがあります。
QAエンジニアの業務の幅広さ
まず押さえておきたいのは、QAエンジニアの業務はテスト実行だけではない、という点です。
テストを実行するのはもちろん、テスト設計や、組織・チームにおけるテストや品質保証の方針を策定することや、テスト・QAプロセス改善、テスト自動化の推進、開発者へのテスト技術の移転、不具合分析等を通じた品質の可視化や改善アクションなどなど、QAエンジニアが担う可能性のある業務は多岐にわたります。QAエンジニアはその中で得意領域を持って開発組織に貢献したり、できること・領域自体を広げるための努力をしたりしています。
QAエンジニアは「開発の後工程でテストをする人」ではありません。
第2回で触れた”自走できる人”というキーワードも、こうした幅広い業務を自律的にこなせる人材を指しています。プロダクトのQA活動を一貫して担い、必要であれば仕事を自分で作っていく。そのような役割を期待している企業が多いですし、多くのやる気のあるQAエンジニアはそのような期待に応えようとしているはずです。
にもかかわらず「QAってテストする人でしょ？」という理解で募集をしてしまっていては、QAエンジニア側とのギャップが大きく、採用はうまく進まないと思います。
品質文化とQAの位置づけ
続いて理解しておきたいのは、品質文化とQAの位置づけです。
QAエンジニアが重視しているものの一つに、「品質は全員で作るもの」という考え方が組織に根付いているかどうかがあります。品質はQAエンジニアだけが考えるものではなく、開発チーム全体で作り込むものだという理解が前提にあるのです。
そのため、既にQAチームが存在する場合は開発とQAが対立していない環境、一緒に良いプロダクトを作る仲間として協働している環境を求めたいところです。いわゆる「上流から関われる」「開発チームとの距離が近いor開発チームの中で働いている」といった、開発プロセスに何か意見を反映できる、品質向上のための活動が尊重されるような環境かどうかを気にする人が多いでしょう。
1人目QAを募集する場合は既存のQAチームが無い状態なので、「品質文化がありますよ」「ウチは上流から関わっていますよ」といったアピールはできません。が、QAチームの体制が整った暁にはそういった協働状態を目指したいと思っているんだ、という一つの理想像として提示すると良いと思います。
QAにとってのスタンダードな考え方を理解する
もう一つ理解しておきたいのは、QA業界におけるスタンダードな考え方です。
たとえばシフトレフトやシフトレフトテストという考え方があります。開発プロセスの早い段階から品質を考えたりテスト活動を行うというアプローチで、以前はちょっとした流行り、最近よく聞くようになった言葉、といった位置づけだったように思います。しかし、今ではスタンダードな考え方として浸透しているのではないでしょうか。スタンダードとして浸透している、ということはつまり
- QAエンジニアの多くはその考え方を知っている・聞いたことがある状態であり
- （個別の賛否はあるものの）概ね皆が賛同している、取り入れたほうがいいと思っている
ということです。
テスト自動化などもそうですし、上で述べたような「QAエンジニアの業務・やれることは幅広い」や「品質はQAだけでなく皆で作るものである」なども、スタンダードな考え方と言っていいでしょう。
これらのスタンダードな考え方を知っておくことは、募集文面を書くうえでも重要です。私自身、QAの求人票を見たときに、「この会社はQA界隈の考え方などを理解しているかな」と無意識に見ています。募集側が求職者の職務経歴書を見たときに「github（正しい表記はGitHub）」のような細かいミスが多かったり、自社の事業について的はずれな理解をしていては「大丈夫か？」と思ってしまいますよね。求職者から募集側を見たときにも同じです。
逆に言えば、こうしたスタンダードな考え方が反映された募集文面は、それだけで「QAのことをわかっている会社だな」という印象を与えることができます。
理解を深めるための具体的アクション
ここまで、QAについて何を理解すればいいのかを整理してきました。しかし「理解しましょう！」だけでは実際に何をすればいいのかわかりません。ここからは、理解を深めるための具体的なアクションについて説明します。これらのアクションは主に1人目のQAを採用する際の活動が中心ですが、もちろん2人目以降の組織拡大フェーズにおいても適用できる方法だと考えています。
他社求人を参考に、自社のニーズを言語化する
まず取り組みやすいのが、他社の求人を参考にすることです。ビズリーチやFindyなどのメジャーな媒体でQAエンジニアの求人を検索すると、さまざまな企業の募集文面を確認できます。
ここで重要なのは、他社の求人を「真似る」のが目的ではないということです。他社の求人を見ることで、QAエンジニアに期待したいことや、開発プロセスをどうしていきたいのかを適切に言語化することが本来の目的です。他社の求人はそのための「ヒント」として活用するものだと考えてください。
具体的には、業務内容の書き方や使われている表現、必須要件と歓迎要件の内容とバランスなどを参考にしながら、「自社の場合はどうか？」と置き換えて考えましょう。もちろん、他社が必須や歓迎としている要素すべてが自社に必要とは限りません。プロダクトがtoBなのかtoCなのか、モバイルアプリなのか基幹システムなのか、などプロダクトやドメインの性質によって要件は変わってきます。
似た業種や規模の会社の求人を参考にし、不要な要素は除きつつ、「考えていなかったけど、確かにこういう要素もほしいな」などの気づきがあれば取り入れる。このプロセスを通じて、「QAに何を期待しているのか」「開発プロセスをどうしたいのか」が少しずつ言語化されていきます。
実際に私がお話した、QA採用に成功した企業の方も、まずは他社の求人を研究することから始めたとおっしゃっていました。そのプロセスを通じて自社のニーズが明確になり、それが募集文面に反映されたとのことです。
QAコミュニティに触れる
JaSSTやQA系のミートアップイベントなど、QAエンジニアが集まるイベントやコミュニティに参加してみることもおすすめです。QAエンジニアが何を話しているか、どんなトピックに関心を持っているかを直接知ることができます。
ただし注意点として、採用目的を前面に出した参加は避けましょう。私がお話した、QA採用に取り組んでいる方の中にも、「宣伝目的でコミュニティに参加すると、かえってQAエンジニアの間で心象を悪くしてしまうのでは」と懸念されている方がいました。これは非常にまっとうな考え方だと思います。
コミュニティへの参加はあくまでも「QA界隈の文化や考え方を学びに行く」ことや「自分たちの開発や品質保証のプロセスをよくするヒントを得にいく」ことをメインとして、結果としてつながりができたら嬉しい、というスタンスを大切にしましょう。こうした姿勢で参加することで、QAエンジニアとの自然な交流が生まれ、場合によってはカジュアル面談などにつながることもあるかもしれません。
一般にカジュアル面談では、自社に興味を持ってくれているエンジニアに対して自社のビジネスや課題感、採用にあたって期待することなどを話すと思います。しかし、採用がなかなかうまくいっていない、どうやっていけばいいかわからない、という場合は 現役のQAという立場で募集内容に対するフィードバックをくれませんか？ と素直にお伝えして、そのような意図のカジュアル面談を申し込むのも一つの手です。
自社がリーチしたい層に響く内容になっているかどうか、応募したくなるかどうか、現役のQAエンジニアの生の声を聞くことが最も確実な確認方法だと考えています。
なお、最近は複数社が合同でミートアップ形式のイベントを開催するケースも増えています。こうした場を活用して認知を広げることも一つの手ですが、そちらについては次回詳しく触れます。
社内におけるQAへの理解と、QA側の思いとのギャップを埋める
QAコミュニティに触れて学んだことと、社内での理解との間には、ギャップがある場合があります。たとえば、本記事中でも説明したような、QAは品質向上に関わる幅広い業務をスコープとして考えているけれども、開発者は「テストする人でしょ？」と思っている、などです。
このようなギャップを放置したまま採用を進めると、うまくいかないことが多いです。採用が難航するだけでなく、仮に採用できたとしても早期離職につながるリスクがあります。
そのため、採用活動と並行して社内におけるQAや品質に対する理解を得ることも大切にしてください。開発チームリーダーやプロダクトマネージャー、CTO・VPoEなど、とくに組織の文化を醸成したり広く情報を発信できる立場にある方から、「QAエンジニアという存在に対するイメージ」や「QAエンジニアに期待すること」を広めていただくのが理想です。こうした土台が整っていると、入社したQAエンジニアが力を発揮しやすい環境が生まれます。
もちろん、開発者やマネージャーなど他のロールの方に「QAエンジニアと同等の知識を身に着けてから採用活動をしてください」ということではありません。（それが実現できるならば、QAエンジニアの必要性があまりなくなってしまいますね。）
そうではなく、誤った理解を減らし、今後入社したQAエンジニアの話に耳を傾けられる姿勢を皆がもっている状態を目指しましょう、ということです。特別扱いは必要ありませんが、QAエンジニアを品質の専門家として尊重することが大切です。これが、本記事の冒頭でも用いた「リスペクト」にあたります。
副業QAに入ってもらう
最後は、現役のQAエンジニアに業務委託として入ってもらう、いわゆる「副業QA」の活用です。副業QAに文化づくりや募集文面づくりなど、採用の土台を整える活動を担ってもらうというもので、社内の品質に関する現状把握や開発プロセスの分析、募集文面の作成・レビュー、社内への品質文化の醸成、採用面接のサポートなどを依頼することが考えられます。
このアプローチが有効な理由はいくつかあります。まず、QAの専門家の視点が社内に入ることで、募集文面が「QAに刺さる」内容になります。面接での見極めもより適切になるでしょう。また、副業QAと一緒に仕事をする中で、社内のメンバーが「QAとは何か」を実際に体験できます。これが品質文化の醸成にもつながります。そして、いきなり正社員を採用するよりもリスクが低く、まず試してみることができるという点も魅力です。
とくに初めてQAエンジニアを採用しようとしている企業にとっては、こうした形でQAの専門家と関わりを持つことが、その後の正社員採用をスムーズにする近道になるのではないかと考えています。2人目以降の採用を行うにあたっても、もし既存のQAメンバーが若手中心であれば、ベテランの副業QAに入ってもらうことで刺激や学びになる部分もあります。QA採用のためには「いまいるメンバーの、同僚としての魅力」が求められる場合もあるため、その点の強化にもつながります。
副業可能なQAエンジニアとの接点としては、前述のカジュアル面談から副業の話に発展させるなどの方法があります。ほかにも、YOUTRUSTなどのサイトでは転職希望のほか副業希望の度合いもエンジニア側が設定できるので、副業を希望しているエンジニアを探すことも可能です。
まとめ
本記事では、QAエンジニアの募集でなかなか応募が来なかったり、求めている人材とマッチしなかったりする原因として、「QAへの理解不足」があることをお伝えしました。
募集文面の表現を工夫する前に、まずQAエンジニアの業務の幅広さ、品質文化とQAの位置づけ、QA業界のスタンダードな考え方を理解することが大切です。そのうえで、他社求人を参考にした自社ニーズの言語化、QAコミュニティへの参加、社内での対話、副業QAの活用といったアクションを通じて、理解を深めていきましょう。
学ぶプロセスは、単に募集文面をよくするためだけではありません。QAについて学び、社内で対話を重ねること自体が、組織の品質意識を高めることにつながります。QA採用の成功は、こうした地道な積み重ねから始まるのではないかと考えています。
次回は募集側の課題2として、QAエンジニアの中での認知を獲得するための手法についてご紹介します。
