doralog
面接採用

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

thumbnail

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

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

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

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

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

実際にピッチャーがほしいのにシュートの試験をして「こいつはダメだ！」と判断するような現場も見てきました。

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

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

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

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

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

人を採用するということは何かの仕事をする人が欲しいということです。

しかし日本はメンバーシップ雇用の傾向が強いため、「優秀な人をとりあえず入れたい」という発想になることも多々あります。

したがって必要なスキルや特性を定義するステップが軽視されがちです。

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

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

必要なスキルを定義する

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

たとえば優れた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を使用しますか？」や「この仕様を元にクラス設計をするとしたら、どう設計しますか？」のほうが、より業務に近い質問になります。

コーディングテスト

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

とはいえこれに関しても、現場と乖離しすぎた課題はあまり意味がありません。
アルゴリズム課題で見られるのはアルゴリズム力であり、それはエンジニアのスキルのほんのごく一部です。さらに多くの現場では使われることがありません。

たとえば次のようにアルゴリズム試験を否定してる動画もあります。

  • アルゴリズムはFANGのようなハイレベルな企業では意味があるが、一般的な企業の業務では使わない知識を問う
  • コーディングテストはIDEの補助がないので、実務でのコーディング力が見れない
  • 検索できないので、実務でのコーディング力が見れない
  • 緊張してるので、本当の実力が見れない

つまりどんな仕事をしてもらうか合わせて課題も用意するべきで、さらに本当の実力から落ちているバイアス込みで参考程度に捉えるのが良いでしょう。

その他の質問

他にも、参考になるサイトはこちら。

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

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

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

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

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

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

過去の経歴の裏を読む

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

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

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

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

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

曖昧な回答を見逃さない

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

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

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

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

妥協はしない

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

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

忙しいから人が欲しいという人ほど、教育する暇がないと言って持て余す現場をなんども見てきました。

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

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

相手は真の実力を発揮できてない

面接官は精神的にも有利な状況で、どんな質問されるか分かってない候補者より頭が回っている状態です。
そのため面接を長く続けてると、優秀と言われる人材にも面接でマウントを取れるため、いわゆる「オレツエー」状態になってしまうこともあります。

面接は、漫画的に言うと自分の固有結界・領域展開の中で戦ってるようなものです。
あくまで相手は力が発揮できてないという意識を忘れないほうが良いでしょう。

そして相手が力を発揮できるような空気づくり、相手の答えやすい質問をすることも、面接官の実力と言えるかもしれません。

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

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

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

面接採用
@dorarep
小学生の頃からフリーゲーム作ってました。今はフリーランスでフルスタックエンジニアしてます。