応募要件を緩和したのに応募者が増えない?要件緩和後に気をつけたいポイント

「母集団形成に苦戦しているため、応募要件を広げたが、更に応募が集まらなくなった」

一見矛盾している話ですが、実はこのようなご相談をよくいただきます。
「応募要件を広げる=対象の転職者数は増える」ため、なぜこのようなことが起きているか原因が分からない、という方も多いようです。

今回は実際にいただいた相談事例を元に、なぜそのようなことが起きるのか(原因)、また要件緩和後に注意すべき求人票記載のポイントについて解説します。

目次

ケース事例

年商300億円のグローバルメーカーでの事例です。同社ではWeb系のエンジニアを募集していましたが、なかなか採用ができず、何度か採用部門と要件緩和を行い、求人票もその都度書き換えを行っていました。
しかし、一年経っても採用が決まらず、採用ターゲットの見直しをするため、どのように要件緩和すれば母集団形成できるか?といったご相談をいただきました。

打ち合わせの際に共有いただいた求人内容の一部を下記に抜粋します。

<求人名>
Webエンジニア 

<仕事内容>
同社が提供するWebサービスの企画・設計開発をご担当いただきます。本サービスは正式ローンチから3年で〇〇万人のユーザー獲得。月次で◯万人ベースで新規利用者が増えており、加速度的にサービスの追加開発を進めています。仕事のメインは開発ベンダー管理となりますが、新機能の企画立案やEコマースの立ち上げにも携わっていただく予定です。

<応募要件>
♯必須スキル
 ・何らかのWebサービスの企画or開発経験
 ・ベンダー管理の経験
♯歓迎スキル
 ・eコマースの構築経験
 ・IoT機器のシステム要件定義、開発・設計の実務経験
 ・クラウドサービスの知見
 ・ビジネスレベルの英語力
♯歓迎される開発言語
 ・PHP、Java、JavaScript、Python

応募数が少ない状況が続いたため、上記内容に必須条件を広げたが、一向に状況は改善されない。採用部門からのニーズも高いため、次はどの条件を広げればよいか?と採用ターゲットを広げることを前提に、悩んでいる様子でした。

さて、上記求人内容を見て、どのような印象を皆さんはお持ちですか?
内容を伺った私は下記のような疑問を持ちました。

・Webサービスであれば何でも良いのか?
・新機能はどんなものなのか?新機能の一つがECなのか
・求められる役割は、新機能の企画なのか?設計開発なのか?
・歓迎条件に記載がある内容は、優先順位が高い順に並んでいるのか?

さらに、ターゲットは「自社EC立ち上げ経験があるWebエンジニア」が欲しいのかなと想定し、話を進めました。

しかし、募集開始時の求人票(下記)を見せていただいたタイミングで、私は大きな誤解をしていることに気づきました。下記が変更前(=募集開始時)の求人内容の一部抜粋です。

変更前

<求人名>
クラウドサービスに関わるWebサービスの設計開発(PL) 

<仕事内容>
同社が提供するtoC向けWebサービスの主にサーバーサイドの設計・開発をご担当いただきます。2020年度に外部サービスとの拡張性向上を目的に、サーバー運用を完全にクラウドへ移行しました。それによってサーバーサイドが絡む機能開発ボリュームが増えております。直近の開発は一時的に外部ベンダーへの依存が大きいですが、早期に内製化したい計画です。短期ではサーバーサイド開発における外注リソースを含めたプロジェクトマネジメント、中長期的にはバックエンドチームのチームをリーティングいただくことを期待しています。なお、並行してEコマース立ち上げも進めています。

<応募要件>
♯必須スキル
 ・クラウドを活用したサーバーサイドアプリケーションの設計・実装経験
 ・プロジェクトマネジメントの経験(規模や人数は不問)
♯歓迎スキル
 ・AWSの知見
 ・JavaまたはPythonを使用した開発経験
 ・ビジネスレベルの英語力
♯歓迎される開発言語
 ・Java、Python

ITエンジニアに詳しい人事の方ならお気づきかと思います。本求人はEC立ち上げ経験ではなく、Webエンジニアの中でも、単純にサーバーサイドのエンジニアが欲しい、という求人でした。

すでにサービスの利用人数も多く、新規機能開発のプロジェクト規模が大きいため、突貫的に外部ベンダーを使った開発を余儀なくされ、歓迎条件としてプロジェクトマネジメントの経験が必要。あくまでもクラウドサーバー(特にAWS)の知見が無い方には務まらない仕事で、優先すべきはクラウドサーバーの知見を持っていることでした。

数少ない応募者の属性を伺ったところ、クラウドサーバーの知見を持つ方は皆無で、デジタルマーケティングの方や、ECサイトの運用経験をお持ちの方が大半でした。

ではなぜこのようなことが起きてしまったのでしょうか?

応募が集まらなくなった原因(仮説①)

要件を広げすぎたことによって、本来ターゲットゾーンの転職者が仕事イメージを持ちにくくなっている

転職者は自分に適している仕事かどうか、自分にもできる仕事であるかを判断したいと考えます。できるできないの判断をするために、業務内容と応募要件(必須/歓迎)を照らし合わして求人票を見る方も多いです。
そのため、応募要件に書いている内容と自身の経験に乖離があるほど、応募を躊躇する傾向にあります。

今回のケース(変更後の求人票)では、最も必要なAWSに関わる記載が一切なく、他方で「企画or開発経験」「ベンダー管理」といった、抽象的で個人によって解釈が分かれる表現があったため、「企画経験が乏しいAWSエンジニア」「プロジェクトマネジメントは行っているが、開発は内製化していてベンダーマネジメントは行っていない方」からの応募が集まりにくくなったことが想定されます。

応募が集まらなくなった原因(仮説②)

必須/歓迎条件の内容とその記載する順番から、(エージェントに対して)異なる採用ターゲット像を想起させている

人事にヒアリングしたところ、歓迎スキルや開発言語の記載順番について、特段意識せずに記載していたようです。
応募が集まらないため、人事としては少しでもターゲットを広げよう、という意図から可能性のある開発言語を採用部門に聞き、追加したとのことでしたが、かえって誤った採用ターゲットを想起させる原因になっていました。

もし私が求人票を修正するのであれば、「プロジェクトの体制と各チームの役割」を求人票に追記上で、本ポジションに求める役割を優先度が高い順番に記載するでしょう。

注意すべきポイント

では応募要件を広げた場合、具体的にどのような点に気をつけて求人票(求人情報)を作るべきなのでしょうか?

① 解釈が分かれる言葉、表現はできるだけ使わない

悪い例:大規模プロジェクトのマネジメント経験

良い例:30人月以上が携わる開発プロジェクトのマネジメント経験

応募要件を広く記載する場合は、最も必要な経験スキルも合わせて求人票に記載する

悪い例:サーバーサイドの何らかの知見

良い例:サーバーサイドの何らかの知見※AWS/GCP/Azure等のクラウドサーバーの知見をお持ちの方は歓迎します。

③ 応募要件の内容は、記載する順番や優先度をわかりやすいように記載する

悪い例:(応募要件)
 ・大規模プロジェクトのマネジメントの経験
 ・サーバーサイドの何らかの知見
 ・AWS等、クラウドサーバーの知見

良い例:
(必須要件)
 ・サーバーの何らかの知見
(歓迎条件)※下記いずれかのご経験をお持ちの方を歓迎します。
 ・クラウドサーバーの知見(AWSの知見をお持ちであることが最も望ましいですが、GCPやAzureでも歓迎します。)
 ・大規模プロジェクト(目安30人月以上が携わる開発プロジェクト)

④ むやみやたらに歓迎条件の項目を増やさない

転職サイトを見ていると、10項目以上の歓迎条件を記載している求人票も一部見られます。外部人材に期待する気持ちはわかりますが、転職者やエージェントを混乱させる原因にもなります。もし採用したいターゲットのペルソナが複数ある場合は、求人票を分けて作成することも一つの手です。

いかがでしたでしょうか?
自社の中途採用経験が長い人事の方であれば、どのようなスペックに要件を落とし込めば応募が集まりやすいか、感覚的に理解している方も多いかと思います。一方で、中途採用経験が浅い方や、初めて採用する職種で職種理解が浅い場合、このようなことが発生しがちです。
もし、長らく採用が決まらない求人があれば、注意すべきポイントを確認し、求人を見直してみましょう。

  • Paddleでは企業の中途採用のお手伝いをしています。
    ぜひお気軽にご相談ください。

よかったらシェアしてね!
目次
閉じる