エンジニアの採用要件の作り方｜必須と歓迎を分ける基準

エンジニアの求人票の「必須要件」を見ると、十項目を超えていることがあります。言語が三つ、フレームワークが二つ、クラウドの経験、設計の経験、チームリードの経験、年数。全部を満たす人は市場にほとんどおらず、いても他社で決まっています。結論を先に書くと、エンジニアの採用要件は、必須を「入社初日にこれが無いと業務が成り立たないもの」に絞って三つ以内にし、それ以外は歓迎に回すと、母集団が生まれ、面接で見るべき点も定まります。必須が多い求人は、要件が整理されていないことの表れで、応募が来ないだけでなく、来た応募の何を見ればよいかも分からなくなります。母集団形成の全体はエンジニアの母集団形成に、代行に出す工程の線はエンジニア採用を代行に出す判断基準にまとめています。

要件が膨らむ理由

必須が十を超える求人票は、悪意でも怠慢でもなく、構造で生まれます。

一つ目は、現場の希望を全部書くことです。現場のエンジニアに「どんな人が欲しいか」と聞くと、いま困っていること全部を挙げます。この言語もこの技術もクラウドも設計も。困っていることは事実ですが、一人の人に全部を求めると、市場にいません。

二つ目は、前任者の経歴を基準にすることです。辞めた人が持っていた技術と経験を、そのまま要件にする。前任者は社内で数年かけてその経験を積んだのであって、入社時点で持っていたわけではありません。

三つ目は、失敗を避けたい気持ちです。以前に採った人が合わなかった経験があると、次は要件を厳しくして防ごうとします。ただ、合わなかった原因の多くは、技術の要件ではなく、任される範囲や進め方のずれで、要件を増やしても防げません。

四つ目は、必須と歓迎の区別を付けずに書くことです。書く側は「あれば良い」のつもりでも、必須の欄に並ぶと、候補者は全部が必須だと読み、一つでも欠けていれば応募しません。

必須と歓迎を分ける基準

必須と歓迎を分ける基準を、一つの問いにします。「入社初日に、これが無いと業務が成り立たないか」。成り立たないなら必須、無くても数か月で身に付くなら歓迎です。

基準の要点は、「経験年数を必須にしない」ことです。「三年以上」は、書きやすい代わりに、三年未満で高い技術を持つ人を弾き、三年以上で技術が伸びていない人を通します。年数の代わりに、「〇〇を一人で設計から実装まで担った経験」のように、経験の中身を書きます。

エラベルの見解

相談で多いのは、「必須を三つに絞ると、合わない人が通ってしまいませんか」というご質問です。必須を絞ることと、選考を緩めることは別です。必須は応募の入口の条件で、面接で見る点は別にあります。必須を絞ると、応募の入口が広がり、面接で見る点（歓迎の要件、任される範囲との相性、技術的な考え方）で絞る形になります。入口で全部を絞ろうとすると、入口に誰も来ません。

見ていて差がつくのは、「必須を決める打ち合わせに、現場と人事と経営が同席しているか」です。現場だけで決めると膨らみ、人事だけで決めると技術がずれ、経営だけで決めると年数と肩書になります。三者で「初日に無いと成り立たないか」を一つずつ問うと、必須は自然に三つ前後に落ちます。エラベルでは、エンジニア採用の担当者を紹介する前に、この打ち合わせを一度持っていただくようお願いしています。要件が三つに絞れていれば、担当者は最初の週から検索と文面に入れます。

必須に残す数と、その決め方

必須は三つ以内が目安です。三つに絞る手順を示します。

1. 現場の希望を全部書き出す。 十でも十五でも。ここでは絞らない。
2. 一つずつ、「初日に無いと業務が成り立たないか」を問う。 成り立たないものだけ残す。
3. 残ったものが三つを超えたら、「無い場合、社内の誰かが数か月補えるか」を問う。 補えるものは歓迎へ。
4. 残った必須を、年数ではなく経験の中身で書く。 「〇〇の設計から実装を一人で担った経験」。
5. 歓迎に回したものを、優先順位を付けて三〜五つ書く。 面接で見る点になる。
6. 必須が一つも残らない場合は、要件が決まっていない。 現場に「初日に何をしてもらうか」を聞き直す。
7. 必須が三つ以内に収まったら、現場・人事・経営で確認する。 「この三つがあれば、他は入社後に補える」と三者が言えるか。

手順の要点は、「三で、社内の誰かが補えるかを問う」ことです。必須に残っている項目の多くは、社内に教えられる人がいれば歓迎に回せます。教えられる人がいない項目だけが、本当の必須です。

経歴で確かめられる要件と、面接でしか分からない要件

要件を、確かめる方法で分けると、書類選考と面接の役割が定まります。

分け方の要点は、「経歴で分かる要件を、面接でもう一度聞かない」ことです。面接の時間は、経歴では分からないことに使います。経歴で分かることを面接で聞き直すと、面接が経歴の確認で終わり、肝心の考え方を見る時間が無くなります。

要件が決まらないときの原因

要件を決める打ち合わせを持っても決まらないことがあります。原因を整理します。

原因の要点は、「初日に何をしてもらうかが決まっていない」ことが最も多い点です。業務が決まれば、必須は自然に出ます。業務が決まらないまま要件を議論すると、希望の羅列になります。

代行に出せる工程

要件定義の工程で、代行に出せる部分と、社内で持つ部分を整理します。

分け方の要点は、「判断は社内、進行と言語化は代行」ということです。要件の中身を代行が決めることはできませんが、決めるための打ち合わせの進行、決まったものの言語化、市場との照らし合わせは、代行が担えます。要件定義そのものを外注することの是非は要件を外に出すと自社のことを分かっていない人が決めることにならないかでも触れています。

エラベルの見解

担当する側から見ると、要件が三つに絞れている会社と、十ある会社では、最初の一か月の動きが全く違います。三つなら、検索の条件が明確で、一行目に触れる経歴の一点も選びやすく、書類の一次絞りの基準も定まります。十あると、検索で誰も出てこず、文面で何を訴求すればよいか分からず、絞り込みの基準も曖昧です。担当者の力量より、要件の整理が結果を決めます。

エラベルでは、エンジニア採用の案件で、要件が整理されていない場合、担当者の最初の仕事を「要件を三つに絞る打ち合わせの進行」にすることをお勧めしています。募集が始まるのが数週間遅れますが、その数週間で、その後の数か月の結果が変わります。要件の整理を飛ばして募集を急ぐと、応募が来ないか、来ても何を見ればよいか分からない、という状態で数か月が過ぎます。

まとめ

• エンジニアの必須要件は「入社初日にこれが無いと業務が成り立たないか」で絞り、三つ以内に。それ以外は歓迎へ
• 要件が膨らむのは現場の希望を全部書く・前任者を基準にする・失敗を避けたい・必須と歓迎の区別が無いから
• 経験年数を必須にしない。年数の代わりに経験の中身を書く
• 絞る手順は全部書き出す→初日に無いと成り立つか→社内の誰かが補えるか→中身で書く→歓迎に優先順位→三者で確認
• 経歴で分かる要件は書類で、分からない要件は面接で。面接で経歴を聞き直さない
• 決まらない原因の多くは初日に何をしてもらうかが決まっていないこと。業務が決まれば必須は出る
• 代行に出せるのは進行・言語化・市場との照らし合わせ・一次絞り・面接の質問の案。判断は社内

よくある質問

必須を三つに絞ると、合わない人が通ってしまいませんか

必須は応募の入口の条件で、選考の全部ではありません。入口を三つで広げ、面接で歓迎の要件と、経歴では分からない点（技術的な考え方、任される範囲との相性）を見て絞ります。入口で全部を絞ると、入口に来る人がいなくなります。合わない人が面接まで来ることは、面接の時間を使いますが、応募が来ないことに比べれば、はるかに良い状態です。面接で見る点が定まっていれば、合わない人は面接で分かります。

他社の求人票を参考に要件を書いてはいけませんか

参考にすること自体は構いませんが、他社の要件は他社の業務に対するもので、自社の「初日に何をしてもらうか」とは違います。他社の求人票から要件を写すと、自社に要らない項目が必須に入り、自社に要る項目が抜けます。参考にするなら、要件の書き方（年数ではなく経験の中身で書いているか、技術の名前を具体的に書いているか）を見て、中身は自社の業務から出します。

要件定義を外に出すと、自社のことを分かっていない人が決めることになりませんか

要件の中身は、自社の現場でしか決められず、外部が決めることはできません。外部に出せるのは、決めるための打ち合わせの進行、決まったものを候補者に伝わる言葉にする作業、その要件で市場に何人いるかを示す作業です。外部が「この要件にすべき」と決める形になっていたら、それは要件定義の外注ではなく、要件の丸投げで、自社に合わない要件になります。進行と言語化を外に出し、判断は自社で、と分ければ、外部の経験は使えます。