ビジネス

良いエンジニアを採用するための面接のやり方

面接前に:良いエンジニアを定義する

まず良いエンジニアって何なのでしょうか。

どこの会社で採用してても「良いエンジニアが欲しい」と言われてきましたが、それが具体的にどんな要素なのかは説明されることはほとんどありませんでした。

 

エンジニアって言葉は広くて、それこそスポーツ選手ぐらいの幅広い言葉です。

野球チームでサッカー選手をとっても才能の無駄遣いですし、良い野球選手が欲しいと言っても、ピッチャーなのか、4番打者なのか、ムードメイカーなのか、監督なのか、チームによって様々です。

なのでまず、良いエンジニアとは何かを定義しましょう。

 

良いエンジニアの定義は人によって違います。

だから人によって採用基準が変わったり、採用した後に揉めたりしてしまいます。

したがって良いエンジニアの定義はチーム全体で行う必要があります。

良いエンジニアをチーム全体で定義する

何の仕事をしてもらうかを定義する

人を採用するということは何かの仕事をする人が欲しいということでして、何の仕事をしてもらうかを定義しましょう。

これは必要なスキルや特性を定義するために必要なステップです。

 

もちろん実際はやってもらうことは後付けで、「とりあえず取りたいから、取ってからやってもらうことを考える!」なんてケースもあります。

しかしこのステップを怠りすぎると採用した後に「新しく人入ったけど何やってもらうの?」なんて状況にもなってしまいます。

必要なスキルを定義する

その仕事をするために必要なスキルを定義します。

例えば優れたWebエンジニアが欲しいなどとはよく言いますが、その人はどんなスキルを持っているんでしょうか?

この辺り、「テストかける人ー」とか断片的な話はあっても実際ふわっとしてることが多いです。

ですので、具体的に全て列挙しちゃいましょう。

 

探してみるとすでに世の中にはスキルを体系化してくれてる人もいて、そういったものを参考にすると良いと思います。

マネジメントスキルなども含めて体系化できちゃうと理想ですね。

これで洗い出したスキルから逆算して質問に落とし込めば、必要なスキルを持った人を採用するフローが作れます。

 

また必要なスキルを洗い出すと、社員の評価・教育でも便利です。

「このスキル必要だよー」というのがわかりやすいので評価に納得感がありますし、社員が勉強する指針にもなるわけですね。

どのような人が欲しいかを定義する

ざっくりしてますが、どのような人が欲しいかを定義しましょう。

結果の出し方や得意なことには個性があって、それが良いか悪いかは本当にチーム次第です。

 

例えば「自律的にガンガン仕事を進めていくタイプ」がトップダウンの会社に入っても、「指示してないことをなに勝手にやってるんだ!」なんてことになってしまいかねません。

人と人との調整が得意な人にひたすら1人コーディングをやらせても、その持ち味は発揮できませんよね。

当たり前のことなんですが、割と軽視されやすい内容に思います。

 

また一見欲しい人材が定義されてるように見えて、曖昧なケースも多々あります。

特に「自律して動ける人が欲しいー」って言葉はよく聞きますが、どこまで自律して欲しいのでしょうか?

たとえば「黙って俺の言う通りの仕事だけをしてほしいが、細かいことまで説明しないから周りに聞いて欲しい」が「自律的な人材の条件」なケースもありました。

そこで「自分で問題点を探して仕事を作れる人」を採用してもマッチしないことになってしまいます。

 

それが良いとか悪いではなく、誰もが同じ人を頭に思い浮かべられるように細かく定義しないといけないわけです。

面接のための良いエンジニアの判断軸

さて、では良いエンジニアを定義した上で、どのように面接で判断すれば良いのでしょうか。

もちろんなにが良いエンジニアであるかに依存しますが、その上で指針となる考え方を「成長性」「この仕事ができそうか」の2つから考えたい思います。

 

「成長性」「この仕事ができそうか」のどちらを優先するかは状況によって異なりまして、即戦力が欲しいか教育前提でも良いかに関わってきます。

Railsの現場で「Ruby on Railsを使ったことがないけど、優秀なLaravel使い」と「Ruby on Railsを何年も使ってるけど、あまり勉強してこなかった人」のどちらが欲しいかという話ですね。

成長性:過去成長してきたか

過去成長してきたら今後も成長するだろうと言う話ですね。

わかりやすく言えば、毎年レベルが10上がってるのであれば今後もレベル10上がりそうってことです。

 

特に過去の経験と完全にマッチする職場なんて基本的にはありません。

ですので、いずれにしても環境の差異を吸収するために大なり小なり成長する必要があります。

年齢に比例したスキルを持っているか

成長性の指針となるのは年齢に対してのスキルです。

その人の経歴でスキルアップしてきたときに、どのようなスキルを持っていたら良いといえるかを考えましょう。

面接官自身の経験から、必須スキルを判断してはダメ

ここで注意しないといけないのは、自分自身の経歴からスキルを判断しないことです。

割とありがちなのが、「自分の知ってることを知らないこいつは劣ってる」と思ってしまうことです。

 

例えば自分が高負荷のサービスを経験していて負荷対策の知識があったとしても、それを知らない相手が技術的に劣っていると思ってはいけません。

相手が高負荷のサービスを経験していなければその知識はその人の経歴にとっては不要で、その時間を別の勉強に使っているかもしれません。

 

特に「自分が基礎だと思ってること」を知らないと「ダメだ」と判断しがちですが、その基礎って本当に全エンジニアにとっての基礎なんでしょうか?

何かを勉強することは何かを勉強しないことにも繋がるわけで、全てを知ることはできません。

必ず相手の立場に立って、相手を尊重してスキルを見ましょう。

成長性:地頭の良さ

曖昧な概念ですがやはり地頭の良さというのはあるわけで、地頭良い人は優秀でありやすいのは間違いないです。

 

地頭の良さの定義は人それぞれだと思いますが、私が過去読んだ本で一番しっくりきたのは「具体←→抽象の変換力」でした。

ですので、具体・抽象の変換でガンガン揺さぶっていくことで地頭の良さをみることができると考えています。

「なぜ?」「なぜ?」で具体化させていく

具体化させていくためには、回答に対して「なぜ?」「なぜ?」で掘っていくのが有用です。

これをすることで、理解力・説明力を見ることができます。

 

例えば「indexを貼ると早くなります」に対してどこまで理解しているかは人それぞれです。

「なぜindexを貼ると早くなるんですか?」「本の索引みたいになってるから」「本の索引とは具体的にどんなデータ構造でしょうか?」「うーん」

と、曖昧な理解はすぐにボロが出てきてしまうわけですね。

「要するに?」で抽象化させる

具体→抽象への変換としては、何か回答した際に「要するに?」「一言で言うと?」と要約させるのが有効です。

 

「クワガタとかカブトムシとかが好きです。」

「要するにひとことで言うと?」

「昆虫が好きです」

 

このように、「要する」ためには概念を抽象的に包みこむ言葉を使わないといけないわけですね。

つまり具体→抽象への変換力を見ることができるわけです。

この仕事ができそうか:今のスキルがマッチしているか

仕事に必要なスキルを洗い出したかと思いますので、それを持っているかどうかですね。

そのスキルを持っていると判断するには、何を質問すれば良いかを考えていきましょう。

この仕事ができそうか:人間性が職場とあっていそうか

これもどのような人が欲しいかを出しているかと思うので、それとのマッチングを見ていきます。

 

1つ注意しないといけないのは、興味範囲と業務内容の合致についてです。

ここで表面的な回答ではなく、裏の心理まで追求しましょう。

 

例えば「肉が好きだから焼肉屋で働きたい」は危ういです。

なぜなら「肉を食べるのが好きなのであれば、焼肉屋で働いてもその欲求を満たすことはできない」からです。

 

同じように「プログラミングが好き」にも理由はいっぱいあります。

 

「自分の作ったもので身近な人が喜んでくれるのが好き」

「より美しいコードを追求していくのが好き」

「パフォーマンスなど目に見える数値的な成果を出していくのが楽しい」

「お金が儲かるから好き」

「私服で自由な時間に出社したい」

 

プログラミングという体験の先に求めるものは人により異なってくるので、「じゃあプログラミングさせれば満足ね」とはならないのです。

エンジニア採用面接の質問に対する考え方

行動面接

行動面接は面接者の行動特性や思考特性を見抜くための手法です。

  • これまでの経験で、いちばん大変だった状況のことを教えてください
  • チーム/会社を良くするために主体的に行った行動はありますか。
  • 過去1年間にあなたが上司にした提案を2つ教えてください。その案はどういう経緯で出てきたのですか。その後の経過はどうでしたか。

このように過去の行動を質問し、それを掘り下げていきます。

 

行動面接手法はSTAR面接とも呼ばれ、「Situation(状況)」、「Task(職務)」、「Action(行動)」、「Result(結果)」の4つを質問により確認します。

どのような状況・職務のもと、どのような行動をとり、どのような結果になったのかを聞くわけですね。

Googleではこの行動面接手法を使い、候補者の性格を見極めていると言われています。

状況面接

状況面接はあるシチュエーションを提示し、それに対してどういうアクションを取るか聞く手法です。
実際の現場に近い状況を仮定することで、候補者が業務で実際にどういう立ち回りをするかを推測することができるわけですね。

  • あなたのチームに、バグをリリース後まで隠し通そうとする人がいます。どのように対応しますか。
  • 期限前日に仕様の認識間違いが起きて、もう間に合わないような状況になったときどうしますか。
  • チームメンバーのスキル不足が問題になっています。どのように対応しますか。

このように現実にある答えのないシチュエーションに対しての行動を聞くことで、そのまま仕事でどのような行動を取るかがわかるわけです。

これもGoogleで行動面接手法と合わせて使われる手法と言われています。

言葉の定義を問う質問

学校のテストのように、言葉の定義を問う質問はあまり良いとは思いません。

例えば「interfaceとabstractについて説明してください」というようなものですね。

 

これはなぜかというと、実際の業務で「interfaceとabstractについて説明する」場面は普通ないからです。

つまり、その回答ができるかどうかは、業務上であまり関係がないわけなんですね。

この質問に対して気の利いた回答ができるということが、「interfaceとabstractを理解して使いこなせる」ということに必ずしも一致しないわけです。

 

ですのでより業務のシチュエーションに近い形で質問した方が良いでしょう。

この場合だと、「どういうときにinterfaceを、どういうときにabstractを使用しますか?」のほうが、より業務に近い質問になります。

コーディングテスト

アルゴリズム系課題に関しては、オンラインのアルゴリズム課題系サイトから引用可能です。

とはいえこれに関しても、現場と乖離しすぎた課題はあまり意味がないのかなとは思います。

その他の質問

Qiitaの記事に書いていますので、こちらを参照ください。

エンジニア採用面接での注意点

過去行って来たことだけから判断しない

過去の経験は、嘘や誇大表現もいうことができます。

たとえ本人に悪気はなくても、できないことをできると思い込んでしまってることもあるわけです。

そのため「経験がありますか?」「できますか?」という質問だけをベースに判断するのは危険です。

必ず深掘りをして、どのように行ってきたのか、なぜそれを行ったのか、どこまで知っているのかを見極めましょう

過去の経歴の裏を読む

候補者は基本的に一番良い経歴・経験を話します。

それを聞いて「ちゃんと成果を出してそうだな」ではなくその裏を読みましょう。

 

一般的に優秀な人はどんどん仕事を任せられるため、幅広い仕事を経験することが多いといえます。

逆に言えば、一番良い経歴・経験の幅が狭い場合、それ以外の経験をやらせてもらえなかっただけの理由がある可能性が高いです。

 

同じ成功体験や作業内容についてひたすら話してる人には注意しようってわけですね。

曖昧な回答を見逃さない

面接を進めていく中で曖昧な回答があった場合、実際の仕事においても曖昧な認識のまま進めていく可能性があります。

たとえば自分の担当したプロジェクトのサーバ構成がわからない、担当した技術領域に対しての理解が甘いなどです。

 

回答としては「適当に答える<分からりませんと答える<私の推測によれば〜と分からないなりに考える」の順に良いと言われています。

一方で、「業務委託だと権限的に見れない」といったケースもあるため、その点は考慮しておきましょう。

妥協はしない

人が足りない状況だと特に、焦って妥協をしてしまうことは多々あります。

ですが人が増えることで仕事が増えることはあります。

したがって人が足りない状況だからこそ、妥協をするべきではありません

妥協をする場合は手順書がしっかりまとまった単純作業を用意しておくなど、期待値以下だった場合の受け皿も用意しておきましょう。

まとめ:良いエンジニアを採用するための面接のやり方

というわけで、良いエンジニアの採用手法について、体系的にまとめてみました。

 

具体的な質問内容についてはQiitaの記事のほうに記載しているため、そちらも合わせてご参照ください。