はじめに
今までに、いろいろな求人媒体経由（Wantedly, Green, 人材紹介会社, YOUTRUST, リファラル etc）でエンジニアの採用を行ってきたが（面接だと100名以上）、もちろん良かったこともあれば、ミスマッチでうまくいかなかった事例もある。
今回は、エンジニア採用（業務委託含む）を振り返ってみての、今まで失敗した例と今後の改善策について備忘録的に残しておく。
Wantedlyでのエンジニア募集方法に関する記事はこちら。
エンジニア採用費の高騰（2023年後半〜現在）
まず前提として、現在2024年1月だが、2023年後半くらいから日本のエンジニアの採用難易度が上がり、給与も高騰してきている。
これは単純に、需要と供給のバランスで、有効求人倍率が上昇していることより。
特にバックエンドよりもフロントエンドのエンジニアの給与が上がってきている。
さらに、2023年10月に始まったインボイス制度により、業務委託のエンジニア採用の場合には、消費税の申告分（免税事業者から課税事業者へと変更した場合。免税事業者のままだと発注を受けづらくなるため、課税事業者へと変更するケースが増えている）をサービス単価に上乗せして発注元に請求する方向にシフトするため、こちらも採用単価が上昇してくる。
日本の場合は、人材紹介会社への手数料として30-35%程度とそもそも多い手数料を払う相場になっているが、エンジニアの場合さらにこの手数料を上げてでも獲得する会社も出てきている（そうせざるを得ない）ので、採用競争は激化している。
というわけで、エンジニアの採用難易度は上がってきているので、できるだけ採用後のミスマッチは避けたいものである。
エンジニア採用の失敗談
ほとんどの失敗は、スキルとコミュニケーションミスマッチに集約される。
エンジニアは特に頭脳労働であるので、スキルの差により、生産性が5-10倍以上も開いたりする。
スキルのミスマッチ
- 面接の時に期待していたほどのプログラミングスキルがない。
- 最初の要件定義のところでガチガチに決めなければならない＝コミュニケーションコストが発生する
- Pull Requestのレビューが大変になる。手直しが多くなる
このプログラミングスキルが足りないにもレベル感があり
- そもそも既存のコードのルール（命名規則や関数宣言など）を無視して開発してしまう。すでに既存のコードで同じような機能があるものを参照してコピーして必要部分だけ修正すれば良いのに、ゼロから自前で実装してしまい、整合性が取れなくなる
- コードは一旦動くものの、共通化されていなかったり、不必要に回りくどいロジックで描かれていたりして汚い＝構造的に物事を捉える能力が足りない
- 仕様がカッチリ決まったものに関してはアウトプットできるが、自由度が高くなるとできなくなる
- 経験のあるプログラミング言語だとできるが、新しい言語や概念になるとできなくなる。自分の経験の枠組みで問題を解こうとする。スタートアップだと特に使用する技術や言語もどんどん変わる可能性があるので、それに臨機応変に対応し楽しめられるかどうか
- （これはプロダクトマネージャーの仕事の範囲内でもあるが）ゴールを設定したときに、もっと楽な方法で実装できないかを絶えず考えられるか。技術重視になって、より難しい技術を使うことに意識が向いてそこに満足感を覚えるエンジニアも一定数いるが、本末転倒になってしまう。
などなど。
コミュニケーションミスマッチ
海外のエンジニアに経験上多かったが（たまたまかもしれない）、とりあえず動くコードの段階で、できた！とコードを挙げてくることが多い。これ自体は悪いことではない（むしろそのマインドのおかげで早くサービスをリリースできることもある）が、実際には細かいバグが発生していたりエラーの考慮漏れが多かったりで、手直しが発生したケースが多かった。
コードに詰まった時に、すぐに相談するタイプかそうではないタイプか。
これは社内の文化にもよると思うが、基本的には「15分ググっても分からなければ、気軽に相談」する方が、全体としてスピード感が早まるし、サポートもしやすい。
人間、基本的には相談された方が嬉しい生き物なので、それを有効活用（というと表現が多少ゲスいが）しない手はない。むやみやたらに質問しすぎるのは問題だが、（こんな簡単なことで相談してしまうと舐められないか）という自分のプライドを捨てて、ガンガン質問しながらフィードバックをもらって成長していけば良いと個人的には思う。
相談力はスキルと個人的には考えていて、下記2点を意識すれば身につけられるスキル。
・マインド：自分に意識を置くのではなく（自分に意識が向くと、こんなことで相談して良いのだろうかというありもしない邪推が働く。悪くいえば自意識過剰状態）、ゴールに意識を向ける。
・スキル：相談するときに、「すみませんが。簡単な内容で申し訳ないのですが」ではじめて、相談が解決したら「勉強になりました。ありがとうございました。」
もちろん、相談しやすい社内風土を醸成するのも併せて重要。
少し話が脱線したが、あとは、エラーと思って本人が見ているところが違っているだけで時間を費やしてしまっている（開発していてバイアスが入り込んでいる）ケースも多分にあるので、そういう場合は、コードをフレッシュな状態で見れる第三者に相談した方が、「ここのタイポが原因ではない？」とかすぐにわかる事もある。
と、スキルとコミュニケーションのそれぞれにおいてミスマッチ状態が発生しうるのだが、まず、スキル評価に関しては、個人的にはコーディングテストを挟まないと、面接と履歴書だけで評価するのはたとえエンジニアがいたとしても厳しいと結論づけた。
履歴書では、なんとでも書けるので、サービス開発の一部のみを担当していたとしても、そのサービスの主要機能をあたかも自分が担当していたかのように書けてしまう（Rubyのメジャーバージョンアップデートの一部のgemの対応をしただけでも、履歴書には「Rubyの5.1→6.0のバージョンアップを担当」と書ける）。
これに関して、面接時点で深掘りして聞くことも可能ではあるが、限られた面接時間で回答を元に評価は難しい。
あとは、今までの本人のコーディングを、本人のgithubアカウントで確認するという方法もあるが、基本的には会社に所属して作成したコードに関してはprivate repository配下にあるので閲覧できないので、評価できない。個人開発も趣味でやっているエンジニアの場合には、githubアカウントでコード見る事もできるのだが、そうしたエンジニアは多くない。
デザイナーであれば、自分のポートフォリオを見せていただくことが可能（webサイトに公開しているデザイナーも多い）なのだが、エンジニアはそれが難しい。
というわけで、スキルとコミュニケーションミスマッチの課題により、今まで採用がうまくいかなかった経験も多かった（もちろんうまくいった例も多かった）ので、今行っている対策についても記載する。
スキルミスマッチ対策：コーディングチェックの導入
エンジニアの技術力評価として「Track Test」というコーディング試験を導入。
コメント