メルカリにおけるエンジニア採用の舞台裏––技術力を見極めるためにやっていること

メルカリにおける技術者採用方法の変遷

Motohiro Takayama 氏：ご紹介に預かりましたTakayamaと言います。メルカリという会社に2年半くらいいます。エンジニアリングマネージャーを1〜2年していました。

その中で採用に関わることが多々あり、けっこうメルカリは世界のあちこちに出かけて行って新卒の採用を仕掛けたりしているんですね。そういったバックグラウンドもありますが、最近はマネージャーというよりもテックリードをがんばって盛り上げていくぞみたいな活動をしています。

コードインタビューという意味でいくと、昨日Evernoteを見返していたら、2006年にGoogleを受けていたんですね。タイトルが「敗因」となってるからどうも落ちてるんですけど。

そのころから1年とか2年のスパンでコードインタビューを受けてきました。そういう外から見た、つまり採用される側から見た部分と中に入って見たときにどんな感じで違うんだっけなみたいなところの話ができればいいかなと思います。

技術力を見極めるためにやっていること

我々が技術力の見極めにおいてやっていることは大きく2つあって、近しいことをやっている会社はたぶんいっぱいあると思うんですけど、基本的に「課題を解いてもらう」と「面接する」というところですね。

さっきのスマートニュースさんのお話にもあったと思いますけど、Codility。Codilityを使うこともありました。弊社の技術課題はけっこうがんばって自分たちの手で作ったあたたかみのある感じなんですけれども。

各セクション、例えばAndroidアプリ。ぼくは、主にAndroidアプリのエンジニアのマネージャーをしていたんので、そこではアプリを作る技術課題とかをしています。一方で、マシンラーニング、セキュリティとかの領域では、それぞれに則した技術課題というのがあって、それぞれが求める基準を満たすようなものを作っています。「期限内に自分のベストを出してください」みたいな。これはある意味でコード面接をしているみたいな感じだし、非同期的なのでオンラインテストしているようなものだなと思いますね。

いいところとしては、実際のコード面接をするとわかるんですけど、（実際の面接は）すごく圧迫感がありますね。密室で45分めっちゃコードを書くみたいな。そういうのじゃなく、対面よりもプレッシャーが低くていいかなとか。あとホワイトボードだと補完とかないので、好きな環境で書けるのもいいところです。

一方で採用する側としては結果しかない。例えばGitの commit log 実績として残してくれる方もいるんですけれど、どういう思考でその結果になっているのかというのはけっこう読み取るのが難しいなというのはありますね。

あと課題の設定がけっこう大事だなと思っていて、自分の見たいポイントに対して課題を作らず自由に課題を作っちゃうとみんな自由に書いちゃうので。この人いいんだっけ？　悪いんだっけ？　みたいなのがけっこう判断難しいなというところがあります。よく考えて作らなあかんというところですね。

Androidのチームだと今2、3回書き直していて、少しずつ改善はされています。

グローバルな技術面接における心得

技術面接。みなさんわかると思うんですけど、技術について聞きます。それもやっぱりセクションごとに自分たちのクライテリアが違います。

例えばさっきの技術課題みたいなのを解いてもらったら、そこで気になったことについてメモしといて「なんでこういうふうに書いたのでしたっけ？」「どうしてこのような設計にしたんですか？」といった話をすることが多いです。

実際のホワイトボードコーディングみたいなことをするケースもあります。しないケースもある。それは人によって、候補者の方とか面接官の方によってベストなバランスを見ながら考えているという感じです。ここまでが前提。

このイベントは「GO GLOBAL」ですよね。メルカリは「GO GLOBAL」と言いながら、グローバルが日本に来ている感じであって。

何かと言うと、けっこう候補者の方が海外に住んでいる方が多いです。そういう人たちに日本オフィスに来て働いていただくということが最近多くて。日本の東京オフィスを見てみると、エンジニアの半分くらいの人は外国人かもしれないなぁみたいな雰囲気感があって。日本オフィスがグローバル化してるみたいな雰囲気を感じます。けっこうそういう環境はレアかなと思っていておもしろいんですけど。

そういう候補者さんが増えてきている。何が起こるかというと、日本語じゃないとか、基本的にリモートとか、タイムゾーンが違うので調整が難しいなど。

日本に住んでる方だととりあえず来てください。面接しましょうみたいなことが言えるんですけれど。なかなかそういうことが全員に対して言えないので、よりしっかりと見て判断しないといけない。

技術課題と面接って分けたんですけど。課題に関してはなにも問題ありません。もともと非同期的だし、自然言語が違ってもコードでコミュニケーションできます。

だけど、面接に入ってくるとまた違う問題が出てきます。自然言語に関してはメルカリにでは「Global Operation Team」というところがサポートしていて、面接の場に行くと、間に入って同時通訳をしてくれたりします。

Tipsとしては、同時通訳の中でしゃべりじゃなくてテキストで書いてくれてることがあるんですね。それを使うとあとで面接内容を振り返るのにすごく便利だなぁと思って。これはナイスだなと思っています。

実際の面接を英語でやってると、けっこう思い出せないことがあったりするので、そういったときに内容を思い出せるのはすごく助かっています。ところで、英語で「バリバリ面接官するで」ってなるときはけっこう基礎が問われるところなので覚悟が要ります。

コーディング面接については、ホワイトボードでコードを書いてもらう人も、リモートの人もいるんですけれど、どうやって実践しているかと言うと、Google DocsやSkype Interviewsみたいに双方向に質問しながら書ける環境を用意しています。日本に住んでいてリモートで面接するしかない地域に住んでる人にも同じようなことをしています。

よくある問題としては向こう側かこちら側かわからないんですけど、基本的にHangoutsで面接すると途中で切れてしまうんですね。何を言ってたんだっけみたいなことがよくあるんですけど、そういうときのTipsとしてはたぶんこう言ってたんじゃないかとして評価してしまうとぜんぜん公正じゃないことがあって。ちゃんとわからないことはわからないと言って聞き返し続けるのが大事かなと。例えばそれで時間が足りなかったら「もう1ラウンドしましょう」みたいなことは大事かなと思います。

スケールさせるために気をつけていること

あとはScale。メルカリは「グローバル」と「スケール」というのが標榜していて、今はすごくエンジニアを増やそうとしているんですけれども、そうなると迎える側と候補者さんの両方が増えるわけですよね。

迎えるほうが増えると人によってばらつきがありますよね。面接の仕方とか、評価の仕方とか。そういうのをキャリブレーションしないといけません。

あと、候補者さんが増えると、選考するのって一人ひとりについてパワーと時間がかかるわけですけど。そういうのがダーっと増えてくると、こっちも「ワーっと来た！」みたいな感じになって大変で、作戦が必要になってきます。

でもそんなに奇を衒（てら）ったことはしていなくて、これまでは一子相伝で「面接ってこういうふうにするねんで」みたいに言っていたことを標準化しました。

あとは技術課題の評価について。さっき言ってましたけどちゃんと設定しないとグラグラな感じになっちゃいます。このへんをちゃんと見ましょうとかそういうことを話し合って決めたりしています。

あと、Codilityではないんですが、ほかのチーム、AndroidじゃないチームでHackerrankというサイトがあって。このサイトは何かと言うと技術課題的なものがいっぱいあったり、自分で作ったりできて。それに対してこのへん採点してよって書いておけばちゃんと自動で採点してくれるので、「候補者さんが増えてもスケールするね」みたいな感じのところを目指したいです。Androidのところも確かあったんですけど、そんなにカスタマイズがめっちゃできる感じじゃなかったからもうちょっと進捗を待ちたいなぁという感じですけれども。本当はこういうのでどんどん自動化していきたいみたいなところはあります。

「うまい、やすい、はやい」

その他。これは吉野家ですね。「うまい、やすい、はやい」。何かと言うと、お互いに1番いい状況を目指したいわけですね。採るほうも採られるほうも。

採るほうとしては、うまい。うまいというのはつまりクオリティだと思うんですけど。自分たちにマッチするいい人が欲しいなとか思うんだけど、採られるほうとしては別にこの会社じゃないかもしれないし、自分にとって1番いい会社に行きたいというところがクオリティだと思います。

やすい。やすいは結局コストみたいな話なんですけど。それぞれのプロセスでけっこう時間がかかったりするんだけど、そういうのはできるだけ避けたい。受けるほうとしても「これとこれとこれ勉強しておいてください！」とか言われるとけっこうしんどいので、準備がかからないほうがいいよねとか。

はやい。はやいもだいたいやすいに近いんですけど。受けました、どうでしたがすぐにわかるとお互いテンポ良く進むことができるので、そういった感じを目指したいなと思っています。

選考フローは厳密に決まっていない

技術課題とか面接とかしてるんですけど、かっちりとした選考フローみたいなものは実はなくて。例えば十分にアウトプットがあって、GitHubとかでめっちゃコミットしてるとか、コントリビュートしてるみたいなのが目に見てわかるとか。

ブログ活動でちゃんとアウトプットわかったり、コミュニティ活動をしている人に対しては「基本的に技術のところは担保されているからいらない」みたいな感じで技術課題をスキップすることもあります。

面接内容についても、面接って実はけっこう面接官の人のスキルが問われて。話題を求めるわけですよ。この人が1番いい感じでグイグイ答えてくれそうな内容って何だろうっていう。

それを探るために「何をしていましたか？」「最近おもしろかったことって何ですか？」って聞いていくんですけど。その人自身がアウトプットをドカーンって出していれば、そこについていきなりしゃべれてお互いハッピーだなと思いますね。

なので、十分にアウトプットしてるとお互いいいことがあるかなと。とくに候補者のほうとしてはいいことがあるかなと思ってます。

外で候補者としてじゃなくて中から採用活動に関わってみることになって何があったかなと思うと。その組織自体がどういうフェーズかによってどういう採用プロセスを取るかというのは変わっているなと思いますね。

例えば最初だとすごくざっくばらんにカジュアルに面接しておしまいみたいな人もいるし。もうちょっと進んでくると、もうちょっとかっちりしたプロセスでやりましょうとかなってきて。

そうするとさっきみたいにスキルの問題が出て、じゃあそういうのじゃなくてちゃんといい人を見定めてからどういうプロセスにするかを検討するということもやったりするので、組織のフェーズでいろいろ変わると思っています。

それは面接をしたりテストをするときに採られるほうとしても、例えば今自分がどこかのいい会社に行こうとして「ダメでした〜」みたいなところがあったとしても、それはたまたま1番欲しいものを持っていなかったりするだけだったりします。

僕も過去にはいろんな会社を受けてダメだったりしていたんですけど、そう言われたときは「うっそー？」とか思ってたんです。でも実際にそういうことはあるなぁというのが中から見ての感想ですね。僕も自分はそうだと信じたいって感じです。

面接する側になることで見えることがある

まとめると、弊社はグローバル化が日本で進んでいて、人が増えてスケールしないといけないなというところで。けっこう混ぜると大変です。混ぜると大変。カオスとか大変なことが好きな人はぜひチャレンジしてみてほしいです。

あとは受ける側じゃなくて、中の人で面接とかしてみるとけっこう見えてくることもあるので。コーディングインタビューは大変なんですけど1回突破してそれを中でやってみると、逆に今度は自分が受けるほうとしてもうまくできるかもしれないので。面接してみるといいんじゃないですかね。

なんかすごいまとめになってしまった。これでおしまいです。ありがとうございます。

（会場拍手）