応募しようとしている求人の必須要件に、一つだけ満たしていないものがある。応募していいのか、やめておいたほうがいいのか。ここで止まることがあると思います。
私は、その要件を決めている側にいます。エンジニアのポジションで、何を必須要件に入れて何を歓迎要件に回すかを決め、そのうえで応募してきた方の書類を読んでいます。
その立場から書くと、必須要件の中には、代えがきくものと、きかないものが混ざっています。応募する側からは、同じ箇条書きに並んでいるので、その区別が見えません。
以下はすべて、私が担当している範囲での話です。要件の決め方は会社や部署によって違います。
目次
Open 目次
必須要件は、今そこで使っている技術から来ている
まず、要件がどう決まっているかから。
必須要件に入るのは、今のプロダクトやプロジェクトで使用されている技術です。 そこで動いているものが、そのまま要件になります。
歓迎要件のほうには、ポジションより上のスキルや、他のプロダクトへ横に利用できるスキルが入ります。
つまり必須要件は、今そこで使われているものから来ています。
記載が無ければ、その場で見送るものはある
ただし、全部が融通のきくものではありません。
絶対に必要だと思っているものについては、記載が無い場合は即落とすようにしています。 書類の段階で終わります。
一方で、代替スキルでも構わない場合は、面接で確認することがあります。実際に、面接で確認したことがあります。
同じ「必須」の欄に並んでいても、この二つは扱いが違います。
代えがきくほう — 技術の名前
どちらに当たるのかを、具体的に書きます。
言語が一つ指定されていたとしても、他の言語で長い経験がある場合や、ソフトウェアエンジニアリングに精通している場合は、キャッチアップしてもらえばいいだけだと考えています。 そのため、書かれている技術名が一致しているかだけでなく、オーバーオールな経験を見ることがあります。
指定された技術の名前が一致していないことは、それ自体で終わりにはなりません。
ただし、置き換えて考えられるだけのものが、書類から読み取れる必要はあります。技術名が並んでいるだけでは、どれくらい使えるのかまでは読み取れません。そのことはスキルシートに技術名を並べても、深さは伝わらないに書きました。
代えがきかないほう — 経験年数とチームでの開発
逆に、「これが無いなら無理」と考えているのは、開発の経験年数や、チームでの開発経験です。
技術の名前とは、扱いが違います。前の章が代えのきく側だとすれば、こちらはそうではない側です。
歓迎要件は、別の読み方ができるかもしれない
歓迎要件のほうは、応募の可否とは別の使い方ができるかもしれないと思っています。
キャリアのマイルストーンという使い方もできるかもしれません。 今後はこういうスキルが求められているんだな、と受け取ってもらえるといいのかもしれない、という程度の話です。
満たしているかより、その先を見られている
要件を満たしている場合についても、書いておきます。
要件を満たしていたとして、そこから安定して貢献できる程度であるかも見られます。 これは書類でも見ますし、面接でも確認するポイントになります。
ですので、要件の項目を一つずつ照合して、揃っているかどうかだけで決めなくてもいいと思います。十分に自信があるのなら、進んでもいけると思います。
書類のどこが読まれているかは職務経歴書が通らないとき、読む側が探しているものに書きました。
三つに絞ると
- 必須要件は、今そこで使われている技術から来ている。 歓迎要件のほうには、ポジションより上のスキルや、横に利用できるスキルが入ります
- 技術の名前は代えがきくことがある。 指定された言語でなくても、他の言語での長い経験やソフトウェアエンジニアリングへの精通があれば、キャッチアップ前提で見ることがあります。一方で、開発の経験年数とチームでの開発経験は、そうはいきません
- 満たしているかどうかだけで決めなくていい。 満たしたうえで安定して貢献できるかも見られています
繰り返しになりますが、これは私が担当している範囲での話です。要件の決め方も、どこまで融通をきかせるかも、会社や部署によって変わります。