スキルの高いエンジニアを採用する方法について考えてみた

　いままでにエンジニア採用をしたり、逆に採用を受けたりしたので、「スキルの高いエンジニアを採る」という観点で、経験したことのある方法についてメリット・デメリットを走り書きでまとめてみたいと思います。
　方法は一つを用いるというよりは、組み合わせることもできるかと思います。

　媒体やエージェントを選んだ経験はないので、そのあたりによってもまた変わってくるかもしれません。

　GitHubのアカウントを提出してもらって、書類審査などをする方法です。

メリット
- コーディングのスタイルがよくわかり、エンジニアなら誰が見てもレベル感もなんとなく把握しやすい。
デメリット
- GitHubをアクティブに更新している人が少ない
- 使っていても、ちょっとしたプログラムしか置いてなかったりする
- そのような人でも、バリバリ書ける人は結構いる

　候補者の方に、コーディング課題を課す方法です。

メリット
- 課題をこなすだけの具体的な能力があるかが把握できる
- どのようなコードを書く人なのかを把握できる
- コーディング課題を課す外部のサービスもある
デメリット
- (時間的な制約を考えると、)十分な難しさの問題を出すことが難しい
  - 特に、設計の能力を確認することが難しい
- 簡単な問題を課すと、十分な実務スキルがない人でも通ってしまう
- 課題の作成に、スキルと手間がかかる
- 候補者を時間的に拘束してしまう

　足切りとしては有効かもしれないと思っています。

　候補者の方に、コードをお渡しして、コードのレビューをする課題を課す方法です。
　コードにはあえてツッコみどころを入れておき、それをツッコんでもらうようなイメージです。

　結構いいかもしれないと、思いはじめています。

　面接を通して、スキルを把握する。（面接の目的は他にもありますが、ここではスキルの把握に絞って書きます）

　質問すべき項目を蓄積しておき、面接前にある程度決めておくことで、かなり精度を上げることはでき、質問事項をブラッシュアップしていくことができます。

　他の方法でもそうかと思いますが、面接の担当者と採用の責任者で、採用する人に必要なスキル感の認識が合っていないと、ひどいことになります。

　事前に課題を課すのではなく、直接お会いして、その場で課題をこなしてもらう方法です。

メリット
- 課題をこなすだけの能力があるかが把握できる
- 課題の結果だけではなく、そのプロセスを見ることができる
- (課題の設計によっては)設計の能力を見ることもできる
デメリット
- 非常に短い時間で解ける課題しか課すことができない
- ディスカッションが必要な課題になると、面接の担当者のスキルに結果が大きく左右される

　目の前でFizzBuzzを問いてもらった経験がありますが、今考えるとあまり精度の高い方法ではなかったと思います。簡単な課題をやってもらうのは時間がもったいないと思いますが、設計課題をディスカッションしながら行うのは、設計力が見れていいかもしれないです。

メリット
- スキルが、最終的なアウトプットとして見ることができる
- 作られたアプリやサービスの複雑さや斬新さによっても、能力をある程度把握することができる
- (他社案件ではなく、個人制作の場合) アプリやサービスをまるっと作れるだけの広い（≠深い）知識や経験を持っていることがわかる
デメリット
- (個人制作の場合、)他人が要件定義をした場合に、スキル的に要求水準が満たせない場合がある
- (他社案件の場合、)見せてもらった画面や機能が、他の人が担当していた箇所だったり、一部修正しただけというパターンもあるので、確認が必要
- 守秘義務や、サービス期間の関係で、必ずしも見せられるものがあるとは限らない

　昔は、ハズレがない方法と思っていましたが、意外と落とし穴があります・・・