よい人材と巡り会えなくても、選考レベルは下げない　エンジニア採用で大切にすべきこと

「魔法のような手段はない」

山根：では、ここからはみなさまでけっこうな量の質問をいただいているので、ぜひ触れていけたらなと思ってます。

今、私がザッと見ながらいくつか触れさせていただく部分もありつつ、もしこの場で挙手して先に聞いておきたいみたいな方がいたら、挙手でも受け付けます。もしあれば、ぜひ手を挙げていただけたらなと思うんですけども、いかがでしょう？

（会場挙手）

山根：では、前の方どうぞ。

今日は採用というところで、1つは評価する部分をメインで話されていたと思うんですけれども。それにプラス、自分たちがほしいと思っている人物に受けてもらうためのアクションも採用の一環だと思っています。そこに対する工夫や取り組みを、なにかいい話があればシェアしていただけるとうれしいです。

山根：じゃあ、庄司さん。

庄司：それ、よく聞かれるんですけども、なんか元も子もないことを言います。はっきり言うと、魔法のような手段はないです。なにもないです。地道にやっていくしかないです。

だから、うちも技術ブログを出したり、こういうイベントに登壇したり、いろんなエンジニアがいろんなイベントで発表するっていうのも含めて、クックパッドっていう会社がちゃんと技術に真摯に向き合っていますっていうのをやっていくしかないですね。

そういうことが効いてくるのは2年後とか3年後なので、端的にポンって効く施策は一切ないです。そうやって地道にやっていくしかないっていうのが正直なところです。

山根：高橋さんはいかがでしょうか？

高橋：まあ、今、宣伝っていうか、そういうのももちろん重要っていうか、それがたぶん重要だと思います。僕はどちらかというと、Webのテストは始めたばかりなので、そこだけちょっと言わせてもらうと。

今までやっぱり遠くから、東京の近郊じゃない人からの試験って、ペーパーでやってたんで全員うちの会社に呼んでやってたんですけど、「通過しました」って出しても遠いと来ないんですよね。

それをSkype面談、ネットを使った面談、Webのテストをすることによって受けやすくするってけっこう重要かなと思ってます。

一度採用のレベルを下げると技術力は回復しない

山根：ありがとうございます。「プロダクト志向のエンジニアとアルゴリズム志向のエンジニアがいると思うんですが、それぞれのエンジニアについてどのように評価をしていますか？　ビジネス接点との評価と純粋なコーディングスキル、それぞれの評価者が異なるかなど、教えていただきたい」という質問。庄司さん、いかがでしょう？

庄司：先に前提の話をしておいてもいいですか？　たぶん、これを話さないとうまく感覚が伝わらないのかなと思っているものがあるので。どのくらいの通過率なのかを、先にお話しておきます。

山根：はい。

庄司：たぶんすごい厳しいことばっかり言っているので、「何言ってるの？」って思われるかもしれないので、ちゃんとはっきり伝えとこうと思っていて。

まず1つ、確かポール・グレアムっていう人が言ってたんですけども、「技術の世界では、いったんダメなプログラマを雇ってしまったらお終いだ。会社が技術的に平凡になってしまい、その後、回復した例を私は知らない」っていう有名なセリフがあるんですね。

これは当たり前だと思っていて。平均レベルが5のところで、どうしても人が足りないからって4.5の人を採ったら、そこは平均レベルが下がるんですよね。その後、次、5の人を採っても、いくら採っても平均レベル5には絶対に戻らない。6や7を採らないと、5にすら戻らないんですよね。

わかりやすく、そうやってみんなどんどん下がっていくんですよね。それをやめようっていうのはあります。ただ、1人でやめようと思うのはつらいので、うちはCTOが1人いて、エンジニア統括マネージャっていうのが僕以外にもう1人いるので、3人で誰かが心が折れそうになった時は、「いや、ここで折れちゃダメだよ」って言って、意地でもそのエンジニアの採用レベルを下げないようにしています。

山根：なるほど。

庄司：プロダクト志向の人とサービス志向の人みたいなのがあると思うのですが、最低限の技術レベルは担保したいと考えています。どんなにプロダクト志向だろうが何だろうが、最低限の技術レベルは見させていただいて、そこから先は1次選考の時にサービスを実際につくっているエンジニアに面談してもらったりという感じで見極めてます。逆にアルゴリズムが得意な人に関しては、技術部やインフラ部の人間が見て判断する、みたいな感じになっています。

山根：ありがとうございます。

選考を厳しくしすぎて他社に持っていかれたらどうするか？

高橋：うちは、さっき言ったようにゲームのプログラマーはどちらかというとプロダクトになって、R&D系はたぶんそっちじゃないほうになるので、見ている人が別ですね。両方、やっぱりいい人はどっちでもいけそうな人もいますし、要は両方が欲しがる人もいるんで、その後は中で取り合いになったりもしますけど（笑）。

山根：それは新卒でも分けている？

高橋：新卒で。基本は本人が希望するのを第一にするんですけど。実際に会ってみると逆のこともあって、ゲームプログラマーを希望しているんですけど、聞くとR&D系の適性っていうか、本人もなんとなくそっちっていう場合もあるんで。そこはやっぱりエンジニアの面接で判断してます。

山根：なるほど、ありがとうございます。非常に挙がってきているのがあって、「選考3回だと、途中で他社から内定が出てしまうケース」。

これ、確かに私もちょっと先ほどお話を聞いてて思ったところですね。選考が厳しすぎてしまったり、選考フローが長かったり、そういったところがあるケースで、通過する前に他社に内定が出てしまって、そっちにクロージングかけられて取られてしまう、みたいなリスクもあるとは思うんですね。

コード選考であったりコード採用みたいなところを、なにか進められるところをやるうえで、そういうのを導入するハードルっていうのもあるとは思うんです。その中で、おそらくそこを解釈すると、そういった場合の対策であったり、なにか途中でやられていることとかもあったりするんでしょうか？　これはちょっと高橋さんからおうかがいできればと思います。

高橋：いい人っていうのは、いつの時代もだいたいいろんなとこから内定出ちゃうんで、そこは正直うちの魅力で来てもらえなかったって思うしか、無理して囲い込むとかは基本ないですね。はい（笑）。

山根：なるほど、なるほど。庄司さんはいかがですか？　こちらは。

庄司：そうですね。一応そこは、コーディングテストをスキップする手段はあります。OSSですでになにかのプロダクトに貢献していて、すでに社内にいるエンジニア2人が、その技術力を保証した場合は、コーディングテストをスキップできます。

ただ、人事をやられているとご経験あるかと思うのですが、採用のミスマッチはとてもコストが高いので、それを防ぐためにも基本はコーディングテストを受けていただきます。もしも「コーディングテストを受けさせられるんだったら、受けません」と言われて、しかもその人の技術力が判断できるものがなかったら「まあ、しょうがないな」と思います。

山根：ありがとうございます。あとは庄司さん宛に質問が来ていると思いますけども、「採用した結果、違ったなって思った人材はいますか？」っていう質問ですけども（笑）。

庄司：そうですね。なんか他のところでも「コード以外見てない」と強めに言っちゃったので、本当にコード以外は見てないみたいに思われているかもしれないんですが、コード以外ももちろん見てます。

「最低限コードは必要だよ」というだけで、2次面接以降は人柄やその人のやる気、どんなことをやりたいのかも見ているので、あまり採用のミスマッチが起こることはないです。

採用目標と難度をどうバランスさせるか

山根：これはお二方に質問があったところで聞いてみたいところなんですが、そういったコード採用を入れると、選考フローが面接だけよりも伸びる部分があると思います。それによって人事部からすると「何人採用しよう」っていう計画がそもそもある中で、その選考フローがガチガチに通過率が低いことによって、もともと当初予定していた人数がそろわないってことも起こると思うんですね。

ここ、けっこう人事部の方が思ってらっしゃる部分あると思うんですね。お二方がそれをコントロールしたりすることがあるのか、「そこについてエンジニア視点だとどう思われてます？」っていうのを、ぜひ聞いてみたいんです。じゃあ、庄司さんから。

庄司：もうね、僕がなんで今、言いたいかっていうと人事部長やってたことがあるんですよ。

山根：（笑）。

庄司：つまり、その数に責任を持ってたことがあるんですよ。その時は本当につらくて（笑）。人事部長としての僕はこの数字を達成しなきゃいけないんだけども、エンジニアとしての僕は「いや、それでもレベルを下げてはいけない。通しやすくするなんてもってのほかだ」。

もちろん採用チームからも「ちょっと厳しすぎるんじゃない？」「通すべき人を通せてないんじゃない？」みたいなことを言われたりして、だいぶ心が折れそうになったりもして、すごく悩んだりもしたんです。

もちろん部長の時、上から「採用はこれ必達だ」みたいなことも言われるんで、めちゃめちゃつらかったんです。でも、「レベルを下げる」ってことは結果的にはしませんでした。

それはなんでやっているかというと、数字を達成するのって、結局はその先に目的があるからなんですよね。人事部としてはその採用人数を達成するのが目的かもしれないけども、最終的な目的って、その達成した採用した人によって、サービスが良くなってユーザーさんが幸せになるためにやっているっていうのが採用じゃないですか。

それを考えると、ここでレベル下げて採用することはそれにつながらないな、会社のためならないと思ったので、そこはなんとか踏みとどまって、基準は変えなかったですね。

山根：なるほどですね。

庄司：おかげで、達成しませんでした。

山根：（笑）。ありがとうございます。じゃあ、本当に数そろえるよりは、本当に質重視でやられることを目標にしていると。

庄司：そうですね。数もそろえたいんですけれども、はい。

足りないからと言ってもレベルは下げない

山根：ありがとうございます。高橋さんのほうはいかがですか？

高橋：うちも人数が足りないから、さっき庄司さんがおっしゃったように、レベルを下げることはまずしませんね。達成したいんですけどできない。要はこちらとして望んでいるレベルの人が来ない年は「まあ、しょうがないな」って言うしかなくて。

僕なんか最後面接や先ほど言った採用のフローでいろいろやるんですけど、もともと来てくれる人を、種まきじゃないんですけど、いろんな学校に行って、うちの会社の魅力を話したり、イベントに出たりっていうところからまず始めて、それなりに来るっていう段階の、僕が担当しているのはその最後の面接、採用の部分なんです。

その事前の何年かかけてやるような部分を、きっちりがんばらないと結果として来ないんで、それはそれでその時点で「じゃあ足りないからレベル下げる」っていうのはまずしませんね。「少なかったな」っていう。

逆に言うと、良かった年は、本来の人数とは別に今の数字じゃなくて適当に言っちゃうと、例えば10名ほしいっていうのを目標にしてて15名ぐらいだと、「今年すごくいい人いるんで」っていう交渉は上としますね。

山根：逆に多くなっちゃう場合も。

高橋：多い場合もあるんで、はい。

山根：なるほど。ちなみに、人事部から「どうしても人数足りないから採ってくれ」って言われるケースはないんですか？

高橋：ないですね。そうですね、僕は人事側の所属ではなかったんですけど、そういうことを言われたことはないですね。

山根：なるほど。庄司さんは、まあ、人事部長をやられてたら……（笑）。

庄司：まあっていうのもありますし、やっぱり人事部はみんなわかってくれてますね。そうやって無理に増やすものではないっていうのわかってくれているので、それを言われることはないですね。

山根：なるほど。理解いただけている会社っていうことですね。

エンジニアは企業のどこを見ているか？

山根：あと、上に上がってしまったかな。「選考において人事と現場のエンジニア間に生まれる対立構造とその背景、それをどう乗り越えてきたのかを実例をぜひ聞いてみたい」ということなんですけれども。

庄司：対立構造があるという前提なのが……もう。

山根：対立構造があったのか、わかんないですね。

庄司：実例を教えてもらいたいですね（笑）。

山根：もし対立構造がある会社さん、いたらですけれども（笑）、事例としてどうですかね、これ。

高橋：対立してないからちょっと、具体的に言いようがないですね。

山根：お二方とも対立はしていない。もし挙手しづらいとは思うので、個別に後で懇親会の際に、ここのご質問は聞いてみてください。

あと、おもしろい質問があれば……。「技術に真摯に向き合っていることを見せるしかないとありましたが、その他にエンジニアが企業選びの際に見ているポイントはどこだと思われますか？」技術以外ってことなんですかね、これ、エンジニアの方が。

庄司：わかりやすいですよ。私個人的としては、朝出社しなくていい。

山根：なるほど（笑）。

庄司：その会社が技術的に正しいことをやっているかどうか、っていうのは結構大事だと思っています。それを見ているっていうのが大きいかな、と思ってますね。

山根：ありがとうございます。高橋さん、いかがでしょうか？

高橋：技術以外ですよね。

山根：技術以外の魅力的な打ち出しとか、なにか。

高橋：本当にゲームの会社なんで、ゲームですね。

山根：（笑）。ゲーム、いいのがつくれる。

高橋：そうですね。

山根：なるほど。

まずは優秀なエンジニアを採用する

山根：あとは、……あ、これ、おもしろいですね。「2社とも知名度があると思いますが、2人がベンチャー組織の人事になったら、どんな採用戦略を立てますか？」。

確かに、ある程度企業のブランドがある会社さまだと、比較的人事部で母集団を集めてエンジニアで選考してという構成をつくりやすいとは思うんですけれども、もしベンチャー系の組織の人事になったら、どんな戦略で採用を行うか。なにかアイデアあります？

庄司：それは、エンジニアとして人事の採用やる、ってことですかね？　それともエンジニアリングがわかんない人事として、ってことですかね？

山根：おそらくエンジニアがわかる人事、ってことだと思います。

庄司：そう、そこがけっこう大事だと思っていて、エンジニアがわからない人事だったら、まず採用に協力してくれるエンジニアを、絶対に1人見つけるべき。じゃないとエンジニアの気持ちはわからないし、技術選考どうやったらいいかや選考フローもなにもわからないので、まずはそれを見つけるべき。

その後やるとしたら、僕は最初に、1人か2人優秀なエンジニアを採用しますね。

山根：それは人事部に関わってもらえる、っていうことですか？

庄司：ええと、まあ、関わってもらえなくてもいいんですけれども、まずは優秀な人を採用して、その人を基準にします。会社の人みんなに、「この人ぐらいのエンジニアを採るために僕らはがんばるんだよ」っていう話をして、動きますね。

山根：なるほど、ありがとうございます。高橋さんはどうでしょうか？

高橋：そうですね、なかなか難しいというか。そうですね、本当に経験もないですし、今のうちの会社だと知名度が……。

実際にそういう方たちから見れば理想論なのかもしれないですけど、受ける側が来て、魅力があるっていうか、まず「入りたい」と思わなければならないですね。その分析から始めると思いますね、エンジニアとして、はい。

山根：なるほど、ありがとうございます。あとその他、ご質問を、いくつかお受け付けしたいと思うんですが。挙手でお話されたい方、もしいらしたらここでも受け付けたいと思うんですがいかがでしょう？

（会場挙手）

山根：どうぞ。

インフラ系では技術的な質問をする

質問者2：インフラ系のエンジニアの場合は、やっぱりインフラ系の、例えばAWSといった1年間無料で個人が使えるようなものを使ったことがある人間、インフラでも同じような採用を行っているっていう感じなのでしょうか？

庄司：インフラはインフラで、コーディングではないんですけども、やっぱりまず最初に技術的な質問のテストがあります。それに答えてもらうっていう感じですね。それは、クラウドに特化した話っていうのは、そこまで多くないです。

あんまり細かくは言えないんですが、それよりもどちらかっていうとネットワークの基本知識あたりがちゃんとわかっているか。ミドルウェア、例えばデータベース、キーバリューストアとかそういったものを、どういうタイミングでどう使ったりするのか、そういったレベルの話を聞いたりっていうのが多いですね。どっちにしろ、まずはスキルを見ているっていう感じになります。

質問者2：ありがとうございます。

山根：高橋さんは？

高橋：僕、インフラは答えられないです。

山根：そうですね、職種によって確かに違いはありますね。

庄司：そう、職種によって違いますね。研究開発系の人も、また違うテストになります。はい。けれども、研究開発系もその成果をまず出してもらう、っていう感じになります。

「技術的に正しい」とはどういうことか？

山根：ありがとうございます。あとその他、すいません、いろいろと質問がだいぶ挙がってきてはいるんですけれども。

（会場挙手）

質問者3：ありがとうございます。非エンジニアの人事として、ちょっと採用の際に先ほど挙げていただいたエンジニアが見ている部分で、ぜひおうかがいできればと思ったところがあったのですが。

挙げていただいた中に、「技術的に正しいことをやっているかどうかが、1つエンジニアが見ているところだ」というお話あったと思います。技術的に正しいことって、もし可能であれば具体的にどういった内容か、詳しくおうかがいすることは可能でしょうか？

庄司：技術的に正しいことがちゃんと通っている企業って、だいたい、だいたいなんですけれども、新しい技術が出てきて、……新しい技術をただ採用するのではなく、それが本当に良さそうだっていうものの時はちゃんと採用し、そうじゃない時は採用しない、というように取捨選択をきっちりやっていると思うんですね。そこを見るかなと。

「この会社は、エンジニアが『この技術は正しいんだな』と思って採用したいと考えたときに、それができる会社なんだな」っていうのを、けっこう見ている感があります。

逆に、古い技術をずっと使っているままで、「あれ？これ、絶対新しいこの技術に書き換えたほうがいいのにな」と外から見ていても感じるポイントがあるのに、……まあ、実は中から見るといろいろな理由があるのかもしれないけれども。

それを採用してないってなると、逆に、「あ、あんまりそういうことはできないんだろうな。たぶん正しいものがあっても、そのために、新しい正しいものを使うためのコストを、かけさせてくれないんだろうな」という見方をするというのがあって、技術を正しく使えている会社がけっこう選ばれるかな、というお話をした感じです。うまく伝わりましたかね？

質問者3：今お話をおうかがいした感じだと、たぶんそういったエンジニアから会社を見た時にどう判断するかっていうのは、エンジニアさん自身の見識とかも問われる部分があるのかなと思っておりまして。

その場合は、会社として、先ほどご説明いただいたような正しい技術を使われている会社さんだったら、その時点で採用する側としても、見識のあるエンジニアさんの目に留まるようなかたちになるのかなといった感じで、私のほうでは理解させていただいたのですが、方向性としてはなんとなく合っている感じでしょうか？

庄司：合っていると思います。

質問者3：ありがとうございました。

外国籍エンジニアをどう採用するか？

山根：ありがとうございます。その他、もしあれば……。

（会場挙手）

質問者4：お話ありがとうございます。日本のエンジニア採用の事情が、ここにいる方もそうだと思うんですけど、すごい激化している中で、グローバルのほうにちょっと目を向けて外国籍のエンジニアの方の採用にも手を伸ばそうかなと思っています。そのあたりもしやられていることがあったり、観点があればぜひおうかがいさせていただきたいです。

山根：バンナムさんの場合はあれですよね、海外人材は。

高橋：そうですね。とりあえず僕とか日本のスタッフだとコネクションもないしどうにもならないんで、今のところは普通の新卒採用で、外国から来る人も何人かいます。たぶんそういう意味じゃないと思いますが、向こうのそこそこできるっていう……？

質問者4：例えば、その……。

高橋：できる人を呼んで、その人つながりで紹介してもらってみている感じですね。

質問者4：日本語力もあると思うんですけど、実際、外国籍のエンジニアの方とか、例えばベトナムの方とか、優秀なのかなと思うんですけど、そういう方たちが入られた後とかに困ってくる課題だったり、あとは採用プロセスの中で日本人の方と別のところを見ているみたいなところがあれば、ぜひそのあたりも教えていただきたいです。

高橋：今のところはバンクーバーとシンガポールに子会社があるんですけど、そちらに関しては現地に行っているうちのスタッフが見て、面接をして入れているんですけども、弊社の日本のスタジオに関しては、基本的には日本語ができる方しかやっぱり対応できないので、今は日本語ができる外国籍の方のみにしています。

山根：じゃあ、庄司さんのほうもいきましょう。

庄司：うちもそうなんですが、今、海外に子会社が8社あり、海外事業の拠点となる第二本社がイギリスのブリストルにあるので、そこでも採用をしています。そこでは日本語がわからない人を採用していることもあります。

日本のオフィスにも外国籍の社員はおり、主にグローバルチームで働いています。

質問者4：もうちょっといいですか？

山根：どうぞ。

質問者4：日本で日本語がしゃべれるエンジニアの方を採用する時に、国籍が違うことでのプライオリティを一切つけずに、もうフラットに技術力で見ていくって感じですか？

庄司：そうですね。国籍を気にしたことはないですね。僕のチームにも今、韓国人とフランス人がいますし、とくになにも気にしていない感じです。

質問者4：わかりました。ありがとうございます。

山根：はい、ありがとうございます。いくつか質問がsli.doのほうにも挙がってはいますね。細かい求人票の部分であったり、給与的なお話等も挙がってはいるんですけれども、トークセッションに関してはいったんここで質問を切らせていただければと思います。

それでは、2社の社内でのコードチェック、スキルチェックをされている採用のお話、Tips持ち帰っていただけたらなと思います。改めてみなさん、簡単に拍手のほうをお二方に送っていただけますでしょうか。

（会場拍手）

山根：では、いったんここでトークセッションは終了とさせていただきます。

司会者：それではいったん、ご登壇いただいた方が退場されますので、もう一度拍手でお願いいたします。

（会場拍手）