1からQAエンジニア採用を始めるあなたへ【QAエンジニア採用の教科書】
直近2〜3年で、「QAエンジニア」の採用を行なっている企業が多くなっているように思います。「QAエンジニア」という職種自体は以前から存在していましたが、優れたユーザー体験や品質の高さが求められる昨今において重要性が増している職種の一つです。ゆえに、スタートアップ/ベンチャー企業様の採用支援を行う中で、「QAの採用をしたい」というニーズは日々増していると感じています。
また、QAエンジニアは一般的なWebエンジニアと比較して馴染みのない方もいらっしゃると思いますので、どのように採用するのか、そもそも転職市場にどの程度いるのか?という疑問が生まれているのでは思います。
そこで今回は、QAエンジニア採用に必要な前提情報や施策、手法について本noteで説明します。ゼロから採用を始める方にも、本noteを読んで全体感を理解していただければと思っております。
1. QAエンジニアの採用を進める前に把握しておいたほうが良いこと
QAエンジニアを採用するための手法を公開する前に、よりスムーズに採用活動を進めるために事前に把握した方が良いことをお伝えします。
1-1. QAエンジニアの採用市場
どのような職種を採用するにしても、市場にターゲットがどれくらいいて、求人数がどれくらいあるのかは大前提知る必要がありますので、まずは、QAエンジニアの市況感について説明します。
個人的にQAエンジニアが最も多く登録していると思っている採用媒体で、母集団の調査をしましたのでデータ(2023年4月調査)をご覧ください。
QAエンジニアの母集団調査のみだと、少ないのか多いのか判断がしにくいため、開発エンジニアの母集団調査も行いました。その結果が下記です。
上記のデータをご覧いただき、どのように感じられたでしょうか。
個人的にQAエンジニアは開発エンジニアより少ないだろうという感覚があったのですが、実際、3000名以上、差があり想像以上にQAエンジニアの数は少ないな…と感じました。また、QAエンジニアは求人数に対して、求職者数がほぼ 1 対 1 の結果になり、開発エンジニアと比較すると、採用する側としては難易度が高いと言えることがわかります。
1-2. QAエンジニアの業務範囲
続いて、QAエンジニアの業務範囲についてです。
QAエンジニアは一般的には、「Webサービスなどにおける開発プロセスやテスト工程、テスト結果の分析、顧客へのサービスクオリティなど、成果物に関わる全ての品質保証を担うことが役割」と言われていますが、実際に各企業ではどのような業務内容を求人票に記載しているかを10社ほど取りまとめましたので、下記をご覧ください。
上記の表を補足すると、まとめ①は主に、テストに関する業務内容で、まとめ②は主に、品質基準の策定やテスト実施後に起きる業務内容です。
これらの業務を社内のQAエンジニア、時には第三者検証企業を活用しながら分担し、一般的には品質基準の策定・テスト計画等の上流部分を社内のQAエンジニアが行い、テストの設計・実施等をアウトソーシングするケースが多い印象があります。
本項の最後に、実際にQAエンジニア採用を行う中で感じたことを2点お話すると、一人目のQAエンジニアは、品質基準の策定からテストの実施までを自ら行うため業務範囲はものすごく広く、採用難易度は高めです。
また、自社サービス企業のQAエンジニアによく求められる経験は、
・テスト計画経験があるか
・テスト結果の分析を行いレポーティング経験があるか
・品質保証に関する知見があるか等
が多い印象なので、求人票を作成する際の参考にしていただけたら幸いです。
2. QAエンジニア採用の全施策をまとめてみる
さあ、ここからが本題です。一体、QAエンジニア採用において取り組むべき施策・取り組んだほうが良い施策はいくつあるのか。まずはQAエンジニア採用において出来ることを項目別で洗い出してみました。
それがこちら👇
これをレベル別にまとめてみると・・・👇
レベル5に近づけば近づくほどQAエンジニア採用において「強者(レベル高)」になるイメージです。(個人的な所感ですが、レベル5まで到達している企業はほとんどないかと思います。)
WebエンジニアとQAエンジニアの採用の大きな違いを一つ補足すると、採用手法です。QAはコードを書くことが求められているというより、バグがなく、Webサービス/ソフトウェアが動くことや品質の向上を求められます。そのため、Webエンジニアが主に生息しているForkwell / Findy / LAPRAS / 転職ドラフトに多くの登録者がいるわけではなく、上記の媒体の運用はWant寄りの施策になっています。
3. キャリア別の採用施策
ここまでQAエンジニア採用の大枠について、触れてきました。大枠がわかっても、具体的な採用戦術や手法を理解しなければ、採用成功は難しいです。ということで、本項では上記の施策を参考にした上で、キャリア別(自社サービス企業出身と第三者検証企業出身)のQAエンジニア採用の施策について説明いたします。
キャリア別の採用施策は大きく2つに分かれます。キャリア別の魅力設計と採用手法です。魅力設計をする際に重要なことは、「ターゲットから逆算したインサイト/メッセージング設計」です。インサイトとメッセージングとは何かを下記にて紹介します。(詳細を知りたい方はこちらのブログをご覧ください。)
それでは詳細を見ていきましょう。
3-1. 自社サービス企業のQAエンジニア→自社サービス企業のQAエンジニアの人向け
まずは「現職が自社サービス企業でQAエンジニア出身→QAエンジニア」の魅力設計・採用手法から。
3-1-1. 魅力設計
上記の魅力設計について簡単に解説します。
まず、ビジネスや開発と比較して、「品質保証」に対して理解がない/薄い組織は一定数存在します。理由(仮説)は直接的に売上に関わる部分ではないためと考えています。
例えば、SaaS企業のようにサブスクリプションモデルのビジネスであれば、継続的にお客様に使っていただけることが重要になるため、品質保証を必然的に重視する必要がありますが、買い切り型モデルのビジネスであれば、品質は評判等には関わるものの直接的に売上に影響されるものではないためです。
次に、メッセージングについてですが、「品質保証について理解のあるメンバーがいるというのをどのように打ち出すか」が、今回、重要になるポイントです。いくつかメッセージングできるものはありそうですが、今回は「デイリースクラムの中でユーザー起点での品質についてディスカッションをしながら、業務を行える環境」と、お伝えしました。
これは実際にある企業のQAエンジニアにインタビューをした際にお話していたものですが、企画や要件定義等の上流から品質について他メンバーとディスカッションができると、ユーザーに使いやすい品質を届ける役割のQAエンジニアにとってバリューを発揮しやすいと話されていましたので、参考にして頂けたら幸いです。
3-1-2. 採用手法
採用手法は大項目2でもお伝えしましたが、大きく分けると以下の3つの手法になると思っています。
改めてお伝えしますが、「エンジニア = Forkwell / Findy / LAPRAS / 転職ドラフト」というイメージが強いかと思いますが、コードを書くことがメインではないQAエンジニアはWeb系エンジニアと生息している媒体が異なることをご理解いただければと思います。
3-2. 第三者検証企業のQAエンジニア→自社サービス企業のQAエンジニアの人向け
次に、第三者検証企業のQAエンジニア→自社サービス企業のQAエンジニアの人向けの魅力設計・採用手法です。
※ちなみに、第三者検証とは、「システムの開発者ではない人が、第三者の視点からシステム品質の検証・評価を行うこと」です。
3-2-1. 魅力設計
上記の魅力設計について簡単に解説します。
第三者検証企業のQAエンジニアはその名の通り、第三者になるためテスト業務を依頼される立場にあります。そうなると、自分がやりたいことをやるというより、依頼された業務範囲を正確に行うことがメインになるため、本来は品質の基準作りから事業成長に関わる品質保証の一連のフローを行いたいけれど、なかなか実現できないというインサイトを持っているケースがあります。
このインサイトは自社サービス企業であれば、メッセージングしやすいかと思いますので、ぜひご参考いただければと思います。
3-2-2. 採用手法
続いて、採用手法は自社サービス企業のQAエンジニアとほぼ変わらないため、説明は割愛します。
参考までに、いくつか第三者検証企業を紹介します。ひとえに、「第三者検証企業」といっても、それぞれの企業によって強みが異なりますので、どのような強みを持ったQAエンジニアを採用したいかによってターゲット企業を選定することもありかと思います。
4. QAエンジニア採用の落とし穴
最後に、QAエンジニア採用における落とし穴を紹介しますので、ぜひ参考にしていただけますと幸いです。
4-1. 自社サービス企業のQAエンジニアに固執した採用を続け、採用に至らない
一つ目は、自社サービス企業のQAエンジニアに固執した採用を続けるパターンです。ここでのポイントは"自社サービス企業の"という点です。
肌感覚では、自社サービス企業でQAエンジニア経験のある方を採用したいと、9割以上の企業様が思われているのではと感じています。そして、冒頭でもお伝えしましたが、QAエンジニアの数はWebエンジニアと比較しても非常に少ないという結果が出ています。(自社サービスのQAエンジニア経験者で絞るとさらに少ないです。)
つまり、自社サービス企業のQAエンジニア採用は激戦を極めます。その中でも、エンジニア採用ブランディングを構築できている企業様が優位になる可能性が高いことを考えると、なおさら難しさが増します。
急募の状況でなければ、必須要件を変えないという選択もありかと思いますが、急募の場合は「今、採用したい人は本当にQAエンジニア経験者でなければいけないのか?」ということを改めて考えてみても良いのではと思います。例えば、MustとWantでQAエンジニアに任せたいことを分けると、どのような強みを持った人を採用するべきなのかがより明確になるケースがあります。
4-2. 組織としてQAエンジニアの理解度/重要度が低く、採用に至らない
大項目3の魅力設計の際にも少し触れましたが、組織としてQAエンジニア・品質保証に対しての重要性を感じておらず、採用に至らないケースが見受けられます。(開発エンジニア・デザイナー・プロダクトマネージャーでスクラム開発を行っている企業は、比較的品質保証への理解が高いですが。)
QAエンジニアはコードを書くことが求められているというより、バグがなくWebサービス/ソフトウェアが動くことや品質の向上を求められます。つまり、バグがなく正常にWebサービス/ソフトウェアが動いている状態を目指しており、基本的にはマイナスをゼロにする役割のため、あまり目立つ役割ではありません。そのため、社内の中で開発エンジニアの方が自然と上に見られ、QAエンジニアの立ち位置が下がってしまうことがあります。
QAがなぜ必要なのか?QAがいないとどうなるのか?というのを組織全員が理解しているとQAエンジニアは働きやすいですし、そのような組織にQAエンジニアは入りたいと思っている可能性が経験上高いので、上述のような状態になっている場合は、組織として品質保証の重要性の浸透に関するアクションを行えると良いと思います。
5. 最後に
いかがでしたしょうか。
ここまでQA採用に必要な前提情報や魅力設計、採用手法に触れてきました。QA採用をこれから始めようとしている方や、悩んでいる方に読んでいただけたら嬉しいです。
私自身、QA採用について勉強中ですし、これからさらにトレンドになっていく領域だと思いますので、引き続きベンチャー/スタートアップの採用活動を行いつつ、情報をアップデートしていきたい思いが強いです。
QA採用を主導されている方、ぜひさまざまな情報交換をさせてください。
長文でしたが、最後までご覧いただき、ありがとうございました!
また、弊社の採用/人事組織系支援にご興味がある方はお気軽にお声掛けください。
ポテンシャライトのノウハウを取り入れたATS、「Opela」にご興味をお持ちの方は下記よりご連絡いただければと思います。
これから採用/人事/組織系のアウトプットを続けていきます。
よろしければフォローもよろしくお願い致します(下記クリックいいただき、「フォロー」ボタンがあります)👇