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エンジニアの間で心象を悪くしてしまうのでは」と懸念されている方がいました。これは非常にまっとうな考え方だと思います。
続きを読むにはログインが必要です。
ご利用は無料ですので、ぜひご登録ください。
