こんにちは。株式会社ハイヤールー代表の葛岡(@kkosukeee)です。毎週、失敗しないエンジニア採用についてオウンドメディアに記事を投稿しています。第十三弾は選考プロセスに関する最後の記事で、第十一弾から第十二弾に渡ってご紹介した選考で見るべき技術的/非技術的指標のまとめと、採用プロセス編まとめとしてやるべきこと（DO’s）・やらないべきこと（DON’Ts）をまとめます。
エンジニア採用に関わる人事の方、これからエンジニア組織を作っていく経営者の方などに参考となる記事になっていますので是非ご一読下さい。
（これまでの記事はコチラ👇）
- 第一弾: エンジニアレベルの定義について
- 第二弾: エンジニア採用媒体について
- 第三弾: 採用マーケティングについて
- 第四弾: 採用マーケティング事例
- 第五弾: タレントプール、DOs/DON’Ts
- 第六弾: 選考手法の紹介
- 第七弾: Google選考事例
- 第八弾: Facebook選考事例
- 第九弾: ディー・エヌ・エー選考事例
- 第十弾: メルカリ選考事例
- 第十一弾: 選考で評価すべき3つの技術的指標
- 第十二弾: 選考で評価すべき3つの非技術的指標
選考で評価するべき項目まとめ
前回、前々回の記事でエンジニア採用において見るべきポイントを6つほど紹介しました。本記事はそれらの6つのポイントの復習と、どのように活用できるかをご紹介します。まずは復習で、以下がエンジニア採用時に見るべき6つの技術的/非技術的なポイントです。
| 悪い | 普通 | 良い | 非常に良い | |
|---|---|---|---|---|
| コーディングスキル | 基礎的な文法やデータ構造を理解しておらず、問題を正しく解くことができない。コードにはバグが含まれ実行が不可能。 | 愚直な解法で問題を解くことはできるが、計算量等は特に考慮されておらず、エッジケースの考慮などもかけている。 | 愚直な解法をバグなしで実装できボトルネックを把握した上、与えたヒントを元に最適化することができる。 | 計算量やメモリ使用量、各解法のトレードオフを考慮した上最適解を高い可読性のコードで実装することができる。 |
| 専門知識（iOS, ML） | 基礎的な対象技術に関する知識が欠落しており、最低限の実装ができない。 | 基礎的な対象技術に関する知識はあり、いくつか問題はあるが最低限の実装が愚直にできる。 | 細かいパフォーマンスのチューニングなどは考慮されていないが複雑な実装をすることができる。 | 対象技術の原理を理解しており、細かいパフォーマンスのチューニング等を考慮した複雑な実装をすることができる。 |
| 設計力 | システムに関する基礎的な知識が欠落しており、最低限の条件を満たすシステムを設計ができない。 | スケーラビリティや問題の本質を考慮できていないが、最低限要件を満たすシステムを設計することができる。 | スケーラビリティや問題の本質を考慮し、要件を満たすシステムを設計することができるが、信頼性や一貫性には少し改善の余地がある。 | 問題の本質を理解し、要件を満たすべく適材適所最適な技術選定を行い、信頼性、一貫性、スケーラビリティを考慮したシステムを設計することができる。 |
| 思考プロセス・地頭 | 複雑な問題を段階的に解くなど建設的な思考もみられず、ヒントなどを与えても即座に反応がなく、問題解決に至らない。 | 思考プロセスの言語化はできていないが、複雑な問題に対し都度ヒントを貰いながら徐々に問題を解くことができる。 | 与えたヒントに即座に反応し複雑な問題を解くことができるが思考プロセスの言語化はいくつか気になるところがある。 | 思考プロセスを的確に言語化できており、与えられたヒント等に即座に反応し複雑な問題を建設的に解くことができる。 |
| コミュニケーション能力 | 他人の意見や助言を求めようとせず、一人で議論を進める。意見や助言等を与えても自分のアイデアに固着し建設的な議論ができない。 | 他人の意見や助言を自分から求めることはないが、与えた意見や助言に対して耳を傾ける姿勢を持ち議論を進めることができる。 | 自分から進んで意見や助言を求め議論を進め、聞く姿勢もしっかり持っている。時折意見を押し切る傾向があるが建設的な議論を進めることができる。 | 積極的に自分から意見や助言を求め建設的に議論を進めることができる。相手の意見に対して聞く姿勢を持ち、適切なコミュニケーションがとれ議論を先導することができる。 |
| カルチャーフィット | ミッション、バリューへの共感がみられず社内での活躍が懸念視される。過去の経歴にもバリューを体現した様子は見られない。 | ミッション、バリューへの共感は見られるが過去の経歴からではバリューを体現している様子は見られない。 | ミッション、バリューへの共感が見られ、過去の行動からいくつかのバリューを体現している様子が見られるが同時に体現していないバリューもみられる。 | 過去の経歴や行動などが全てのバリューを体現している。またミッションやバリューへの深い共感がみられ社内での活躍への不安要素がない。 |
弊社のエンジニア採用では、実際にこの評価テーブルを用いて、候補者であるエンジニアを評価しています。より具体的に、弊社のエンジニア採用プロセスを以下ご紹介します。選考プロセスには書類選考はなく、選考回数は計3回で、それらを通して全ての項目を評価し、採用の合否が決まります。
※太字は重点的に見ているポイント、細字は副次的に見ているポイント
1. オンラインスクリーニング
内容
自社コーディング試験サービスのHireRooを用いて、それぞれ20分ほどの問題を計2,3問出題。問題はアルゴリズムの知識を要する問題から、専門知識を問うクイズ形式の問題、ポジションによってはシステムデザイン形式の問題等。全てオンライン上で完結し、候補者が提出した後、自社で定量的な採点結果と過程など含めた定性的な評価項目を用いて評価した後、GO / NO GOの判断が下される。
評価項目
- コーディングスキル
- 専門知識
- システムデザイン力
2. 対話式コーディングテスト
内容
自社コーディング試験サービスのHireRooを用いて、それぞれ45分ほどのオンライン上での面談を実施。Meet、またはZoomを用いて対話しながら、試験を実施（HireRoo上で共同編集等がサポートされているため）。出題内容はコーディング問題1問、システムデザイン問題1問の計2問で、主に対話を通してコミュニケーション能力や、思考プロセスなどを重点的に評価する。試験終了後、定量結果と過程などをもとに定性評価し、GO / NO GOの判断が下される。
評価項目
- コミュニケーション能力
- 思考プロセス・地頭力
- システムデザイン力
- コーディングスキル
3. 代表面接
内容
Meet、またはZoomを用いて、オンラインで45分ほど実施。代表（筆者）が自社のバリューである「Fail Fast（失敗を恐れずに）」、「Issue Drive（コトに向かう）」等観点で、候補者の過去の行動を元に評価をする行動面接形式で行う。実施中は音声録音、またはメモを取り、過去候補者が直面した課題に対する行動などからバリューの体現度合いを評価する。
評価項目
- カルチャーフィット
- コミュニケーション能力
弊社では以上のプロセスを通して、候補者からシグナルを受け取り、全て終わった段階で評価テーブルと照らし合わせそれぞれ四段階で評価しています。四段階評価はそれぞれ、悪いが1点、普通が2点、良いが3点、非常に良いが4点と点数を振り、それぞれの点数の平均が3.0以上であれば採用の対象に入ります（時期等により評価の比重が変わることはありますが、平均して3.0が合格ライン）。
採用が決まればその後オファー面談を実施し、年収などを提示した上、条件面の話をすると言った流れです。このように自社でも評価テーブルの項目などを少し変えたりした上で運用することで、構造化された一貫性のある採用プロセスを実施することができるため、おすすめです（強く勧めます！！）。
採用プロセスDOs/DON’Ts
これまで採用プロセス編の記事で、選考手法の紹介や、実際の事例等を交えた見るべきポイントを紹介しました。以下はそれらをまとめた、DOs（すべき）、DON’Ts（しないべき）なアクションを一部ノウハウ集より抜粋いたします。自社でDON’Tsをしている場合は見直しを、DOsができていない場合は実践してみることをお勧めします（中長期的に必ず効果が現れるはずです）。
（以下ノウハウ集抜粋）
DOs👍
- 事前に評価項目を洗い出しておく
- 面接官の属人的な評価を排除し他の面接官、人事と評価を合わせる際に必ず役立つ。適切に評価項目が定義されていない場合、なんとなく気に入ったからや（同じ大学を出ているから等）、潜在的なバイアスを排除することは難しい。理想的には一次面接では評価項目AとBを、二次面接ではCとDといった形で補完しながら多角的に評価できるとよい。
- リクルーターからの素早いレスポンス
- 選考の結果がどうであれ、候補者は企業からの連絡を待っている。結果が出ていない際はしょうがないが、必要以上に候補者を待たせると候補者は不安を感じる。結果が少し遅れそうな場合、「面接官からのフィードバックをもとに選考中なので後一週間待ってください」などと一通メールするだけでも候補者体験はかなり異なるため、迅速なレスポンスを心がけるべき。
- 選考プロセスの事前共有
- 候補者にコーディング試験やリファレンスチェックなど負荷がかかる選考プロセスを実施する際は必ずカジュアル面談や、人事面談で今後のプロセスを伝えオンボーディングするべき。いきなり聞いてもいない試験等を受けろと言われると辞退者が増えたりするため、JD等に含んでおくでも良い。
- 候補者から面接官へのフィードバック
- 面接官も候補者から評価されることで面接の質が上がり、結果として候補者の経験がより高くなる。Google Forms等を用いて、「適切な言語で対話していたか」、「候補者の話に耳を適切に傾けたか」等を選考後評価してもらう。360度フィードバックのように、定期的に面接官にフィードバックを与え、トレーニングをすることで面接の質が必ず上がる。
DON’Ts👎
- 必要以上に長い選考プロセス
- 選考プロセスは候補者にとっても負担がかかるものであり、数ヶ月かかるような選考プロセスは非常にストレスがかかる。評価項目が事前に定まっていないため、何回面接しても採用が決まらない場合等に多くなる傾向がある。理想は2,3回の面接で採用の合否が決まるように設計すべき。※Googleは創業初期30回以上面接をしていたが、調査の結果、4回目以降の面接は判断精度を高めることに1%程度しか寄与しないことがわかり上限を5回にした。
- 準備不十分の面接官のアサイン
- 質問する内容が全く決まっていないケース等は候補者側からしても一目瞭然。なんとなくよくある質問をするのではなく、事前に定めた評価項目に対して想定質問等をまとめておくことで準備ができ、質の高い面接になる。DOsで紹介した面接官へのフィードバック等を適切に行うことで準備不十分な面接官のアサインは減り、質の高い面接を実施できる。
- フィードバックなしで候補者を見送り
- 選考の結果見送りになった際、候補者に判断の理由を伝えるのと伝えないのとでは候補者体験は大きく変わる。見送りの理由として技術力は問題ないと判断したが、バリューであるAに対して体現できるシグナルを十分に選考を通して感じれなかったなどのフィードバックがあると候補者は選考の結果に納得するため、可能な範囲でフィードバックを与えるべき（業界は狭いので悪い噂はすぐに広がるため）。
※詳細はエリック・シュミット著、How Google Worksの161ページを参照
まとめ
最後まで読んでいただきありがとうございます。本記事では前回、前々回の記事で紹介した採用を通して見るべき6つの点について、それらを組み合わせどのように選考を通して評価するべきかの事例の紹介と、これまでの記事を元に採用プロセスでやるべきこと（DOs）とやらないべきこと（DON’Ts）を理由と一緒に説明しました。
次回の記事以降は、採用後に焦点を当て、どのように社内でエンジニアを評価すべきか、どのように育成すべきか等を、社内評価編としてご紹介しますので、そちらも乞うご期待ください。
また弊社が提供するコーディング試験サービス『HireRoo（ハイヤールー）』では、本記事で紹介した思考プロセスや地頭を評価するためのアルゴリズム形式問題から、専門知識を問う技術特化形式問題や選択形式問題、更には設計力を評価するシステムデザイン形式問題まで、全てがAll in Oneで一つのツールでお使いいただけます。
もし読者の方で「選考時に候補者の技術力を測れない」、「過去にミスマッチが起きて、もう絶対起こしたくない！」等の課題を持たれている方がおられましたら、お気軽にお問い合わせください。それではまた次回！