採用ターゲット設計における「変数」とは
「自社の採用ターゲット（採用要件）は採用難易度高いですか？」
「求人票に記載の要件だとなかなか母集団形成ができない気がして…」
という類の質問をいただくことがあります。
採用手法を選定するにも「採用ターゲット」の設定は必要です。
ただ、当初予定した採用ターゲットで進めた際に思い通りに採用活動が進まない、というケースもやや多い気がしますね。
こんにちは、ポテンシャライトの寳田です💁♀️
みなさんご存知の通り、理想としている採用ターゲットによっても採用難易度が異なります。
採用ターゲットを変更（この場合条件緩和）して進めていくのか否かは採用企業さまの状況によって選択するのが良いと思いますが、実際に採用ターゲットをどんな順序で要件を絞っていくのか、もしくは緩和していくのか。
それに伴う採用難易度は把握できると良いのでは？と感じたので今回は「採用ターゲットに伴う採用難易度」について整理していくことにしました✏️
※あくまで本noteではポテンシャライトが日々採用のご支援をさせていただく中で感じた内容を元に書いておりますので一視点として参考程度にしていただけますと嬉しいです。
それでは、はじめます！
1. はじめに
1-1. 採用活動における「採用ターゲット」の重要性について
採用職種、採用人数がfixすると「採用ターゲット」をディスカッションされるのではないでしょうか？
一般的にその職種に求めるMissionから逆算し、求人票に記載する必須要件/歓迎要件/求める人物像（人柄）などを設定していくかと思われます。
「誰に」というターゲットがない状態だと、その後の採用活動は積み木崩しになることが多いです。なぜならば、
「採用ターゲットが無いと、打ち出すメッセージ(魅力)がボヤける」
「採用ターゲットが無いと、採用マーケティング戦略も設計しにくい」
「採用ターゲットが無いと、適切な採用手法選定ができない」
「これらすべてを鑑みた際に、採用予算策定ができない」
これらが理由です。
前提として採用「職種」と採用「ターゲット」は異なります。
例えば
・採用職種
- バックエンドエンジニア
・採用ターゲット（バックエンドエンジニア）
- Web言語を用いての開発経験が2年以上ある方
- Slerでの開発経験がある方
- Web受託企業での開発経験がある方
- Webプロダクト企業での開発経験がある方
※補足
- プログラミング言語を問わない
そのため採用職種1つにつき、採用ターゲットは複数存在することがほとんどなのです。
上記採用ターゲットを見ていただくと掴んでいただけるのではと思うのですが、恐らく上記採用ターゲットの方々は転職を考える軸や志向性が多少異なります。
つまり採用ターゲットが決まると、採用戦略のあらゆることが決まっていくのです。例えば、
・ターゲットに沿ったメッセージ（魅力）設計
・ターゲットに沿った採用手法策定
・ターゲットに沿ったスカウト文章作成
など、ターゲットが起因することが多数存在します。そのため、採用職種が出たタイミングでまずは「ターゲット」を明瞭にすることをお勧めします。
1-2. 採用職種やターゲットの細分化が始まったのは「2020年ごろ」
リーマンショックを終えた2010年頃から、IT/Web業界が一気に成長速度を上げました。その他の業界/職種においても、成長速度が速い領域がちらほら発生していました。
人材業において、成長速度の速い領域に「特化」した人材企業が生まれるのは当たり前のことです。「この職種であれば、この採用媒体/エージェントを使う」というトレンドが訪れていたようです。
一方で採用ニーズが高騰した職種においては、その職種の人口も徐々に増えていき職種の歴史が長くなるにつれて「採用ターゲット」の多様化も起こってきました。それが2020年ごろかなと。
前述した通り、ターゲットによって適切な採用手法も異なります。例えば、バックエンドエンジニアを採用する場合
(1)SIerでJavaを用いた開発エンジニア経験 の場合
- エージェント
- Green
- ビズリーチ
(2)SIerでC,C++を用いた開発エンジニア経験 の場合
- エージェント
- Green
- type
(3)Web領域でPHPを用いた開発エンジニア経験 の場合
- Green
- エージェント
(4)Web領域でTypeScriptを用いた開発エンジニア経験 の場合
- Forkwell
- Findy
- 転職ドラフト
あくまで弊社側の所感で記載していますが、こんな感じかと思います。
年齢によっても多少の差は生じてきます。
下記は「プログラミング言語」×「年齢」でどの採用手法がワークするのかを表現した表になります。
繰り返しになりますが、同じ「エンジニア」という職種においても、プログラミング言語と年齢という2つの変数を入れた場合に、適切な採用手法がここまで変わるのです。
ここまで採用活動における「採用ターゲット」の重要性についてお伝えさせていただきました。
2. 採用ターゲットの要件設計する上での「変数」とは
では実際に、採用ターゲットを構成する要素（変数）についても紐解いていきましょう。基本的に採用ターゲットを設定する際に絞り込む際
・年齢
・業界経験
・経験年数
この辺りがオーソドックスな絞り込みになるのではないでしょうか？
・・・とはいえ、例えば職種や状況に合わせて「開発言語」「役職」なども異なりますね。
今回は、「エンジニア」職種とした場合にどのくらい変数があるのか。
技術/プロダクト/人・組織の3つの観点で変数を洗い出してみました✏️
Technology 〜「技術」 側面〜
変数①：開発言語
- 静的型付け言語：Python/Ruby/JavaScript/PHP
- 動的型付け言語：Java/Go/Scala/Swift
変数②：開発経験年数
- 開発経験年数「1年以上」
- 開発経験年数「3年以上」
- 開発経験年数「5年以上」
変数③：対応範囲ver1（専門技術領域の広さ）
- フルスタック
- 特定の技術だけではなく、複数の技術分野の技術・知識に精通している
Product 〜「プロダクト」側面〜
変数④：対応範囲ver2（仕様/設計など含むマネジメントスキル）
- 要件定義〜設計・企画含めたプロジェクトマネジメントスキル
- アーキテクチャ設計など
変数⑤：業界経験
- ●●業界特化に特化したプロダクト開発経験していた
- ●●業界といったドメイン知識の理解
Team 〜「人・組織」側面〜
変数⑥：開発規模
- 大規模なチーム開発の経験
- ビジネスメンバーはデザイナー他の職種と開発を進めた経験
変数⑦：マネジメント/役職の有無
- リーダー・マネジメント経験
変数⑧：英語コミュニケーション
- 英語でのコミュニケーション能力
状況によっては追加の変数（項目）が出てくるかもしれませんが、
採用ターゲットを設計していく際や、再度採用ターゲットを見直す際はぜひご参考ください。
では実際に変数①〜変数⑧をそれぞれ見ていくと
経験のありorなし/年数が長いor短いなど単純にレベル分けがしにくい変数（項目）もあるでしょう。
2-1. 「開発言語」別での採用成功率とは
例えば、開発言語。
仮に自社の開発においてバックエンドPython使用しており、Python経験のあるエンジニアを採用していた場合
・対象者が枯渇してしまった
・いよいよ採用ターゲットのチューニングをしていきたい
など意見が上がることもあるでしょう。
要件を再度設計するか否かは企業様によりますが、仮に再設計した場合にどんな順序で考えると良いのか？は採用企業様の要望ももちろんそうですが
「言語」別の採用難易度を把握しておくことも重要です。
果たしてPythonという言語を使用して開発している、現在使用している言語としてPythonをあげているエンジニアの方がどれほどいるのか。そしてどれほどの方が次の転職先含め今後Pythonを使用したいと感じているのかという観点をおさえておく必要があります。
下記ブログで以前「プログラミング言語別の採用成功率」についてアウトプットさせていただきました。
「使用言語の比率」と「希望言語の比率」を取りまとめましたが、
1つの表を羅列したいと思います。
上記は前述した「使用言語の比率」と「希望言語の比率」、そして「希望比率 − 使用比率」でまとめた表です。特に「希望比率 − 使用比率」については、
0以上を青字
0以下を赤字
にしています。ポジティブを青、ネガティヴを赤で表現しているとご理解ください。上記表を見ていくと・・・
バックエンドPythonについては少々曲がり角な傾向があります。使用比率が17.4%である一方で、今後の希望は11.5%です。JavaScriptと同様ですが、希望がそこまで高くない故に採用ターゲットは多い一方で、採用が難しい傾向が発生しています。ただ、Pythonを用いている企業でPythonを必須要件に設定している企業は少ない？所感があります。
そのため他のWeb系言語の開発経験(PHP/Python/Ruby/Perl/Go/Javaなど)を採用ターゲットにするのであれば、採用確度は上がると思います。
また、変数④としておいている「対応範囲ver2」。開発工程において、要件定義〜運用保守まで一貫して経験しているのか否か、どの範囲まで経験しているのか否か。などを要件の1つに入れていらっしゃる採用企業さまもいらっしゃるかと思います。
・要件定義、アプリケーションの設計開発運用経験をお持ちの方
・API、Webアプリケーションの設計、開発、運用のご経験をお持ちの方
と求人票に記載しているケースも見るケースがございます。
この場合は
例えば「要件定義」「設計」「運用」などの一つ一つのフローにおいてどこまで採用時に求めるのか、というレベル別に分類しておくと良いかと思います。
◆設計（例）
Lv1：
- アーキテクチャへの理解がある
過去のノウハウにあるアーキテクチャを活かすことができる
- インターフェースを自身で作成することができる
Lv2：
- MVP やMVVMなどのアーキテクチャを選別して
プロジェクトを推進することができる
Lv3：
- 自分のリードする領域でアーキテクチャ設計ができる
- アーキテクチャの設計のみならず実装ができる
最後に
皆さんいかがでしたでしょうか。
※当社の採用/人事組織系支援にご興味がある方はお気軽にお声掛けください。
今後も採用/人事系のアウトプットを続けていきます。
よろしければフォローもよろしくお願い致します(左上クリックいただき、「フォロー」ボタンがあります)👆
この記事が気に入ったらサポートをしてみませんか？