新卒・中途どちらもコーディングテストを実施
山根淳平氏（以下、山根）：ちょっとご質問がお二人に入ったのでお話をさせていただくと、「これって新卒・中途どちらのお話を、もしくは、どちらもこういう選考フローなのか？」っていうご質問なんですけども、いかがでしょう？
庄司嘉織氏（以下、庄司）：僕も見てて思ったんですけども、たぶん勘違いされているなと思っているのではっきり言っとくと、両方一緒です。
山根：新卒・中途両方。
庄司：新卒だろうがなんだろうが、「まずコードを提出してください」です。
山根：ありがとうございます。
庄司：それを一応補足しておくと、さっきも言ったように、教育の体制がそんなに整っていないっていうのもあるんですけども、今のこの世の中、プログラム書きたいと思ったら、書けないことないんですよね。パソコンさえあればできるんで、昔みたいにコンパイラが何十万出さないと買えなかった時代じゃないんで、今ならできるんですよ。
今やらない人が「就職したらやります」って言っても信じられないので、基本的には今書いている人を求めているので一緒です。コーディングテストを受けてもらう。もちろんコーディングテストの内容が少し違うのはありますけれども、基本的には一緒です。
山根：なるほどですね。ちなみに、少し違うっていうのは、中途のほうが難しくなるんですか？
庄司：中途のほうが難しくなります。
山根：難しくなるんですね。ありがとうございます。
庄司：ただ一応、学生さんとかみんなにも説明しているんですけど、僕らが求めているのはエンジニアですと。小説を書く作家を求める時に、「まだ日本語が書けませんけれども、小説家になりたいです」っていう人を雇わないですよね。日本語書けるの最低条件だよねっていう感じで、エンジニアがコード書けるのは最低条件にしてます。
山根：なるほど、ありがとうございます。高橋さんのほうはいかがでしょうか？
髙橋秀司氏（以下、高橋）：もう完全に新卒採用です。
山根：こちらは新卒採用ですね。
高橋：はい。
山根：ちなみに中途は？
高橋：中途に関しては、試験はある程度したりするんですけど、要はルートによってちょっと違うんです。キャリアのほうは確実にこうして採っているという感じはないですね。もちろん面接はあります。
山根：ポジションに合わせて、選考フローも変えていると。なるほど、ありがとうございます。
ソースコードから何を見極めているか？
山根：というかたちで、参加者の方からも質問があったら随時拾っていきたいと思ってますんで、よろしくお願いします。
選考フローのお話の中でいろいろと出てきたところから、今、新卒も中途も技術的なところをけっこう両社とも見られている部分が、お話にあがったと思うんですけども、「ソースコードから何を見極めてますか？」と。
今いらっしゃっている企業さまの中で、人事部の方で、我々もいろいろとご相談をいただくことが多いんですけども、採用のご担当者さまの中だと、例えば、「エンジニアの現場とちょっとうまく連携が取れてない」「エンジニアの現場面接どうやろう？」「どういうふうにスキル評価しよう？」っていうのを考えられている企業さまもあると思うんですが。
そういった中で、やられている企業さまがソースコードを提出してもらって何を見極めているかっていうのも、ぜひお話聞いてみたいなと思ってます。高橋さん、ゲーム業界的な部分って、何を見てますか？
高橋：今年初めてソースコードを使うWebのテストをやったんで、それが正しいとか間違っているとかわからないんです。基本的に、最初本当に思っていたのは、やっぱりマルかバツではありませんが、得点だけで高い点数だったらすごい技術がある、低い点数だったらあまり技術のないっていうのを若干期待してたんです。
コードテストで評価しているポイント
高橋：実際のところ、そんなに、こう……。まあ、今回我々がうまく……試行錯誤してうまくいってなかったのかもしれないですけど、あんまり得点の差、要はきれいに分布するようなかたちにならなかったのもあるんです。
でも、やっぱりソースコードを見ると、できない……。まあ、できる人はたぶんきれいなコードを書いたり、わかりやすく、とくに問題ないんですが、できない人の中でも、やっぱり時間があれば解けるんですけど、時間制限内にうまくいかなかった人とか。
つまる部分とか、本人の書いたコードを見ると、やっぱり人によって、途中で投げ出してしまったようなコードを書いている人などいろいろで。それって本当に正直数字でも出ないから、主観になっちゃう部分もあるんですけど、そこで、本人がどう答えまで導き出したのか、導き出せないにしろどこでつまったかとか。
そこに関してはWebのテストだけじゃなくて、面談も含めて、できなかった理由を聞くなりします。「ぜんぜんわかりませんでした」っていう人から「こういうところがダメで、実際のところつまってできませんでした」ってちゃんと説明してくれる方までいろいろで。そこでその部分が今までよりも、ぜんぜん今まで予想外にしなかった部分でもあるんですけど、スキルとしてこちらで見ることができました。
山根：なるほど。ちなみに、定量的に評価するみたいな部分もあるとは思うんですけれども、それはコンパイルが通っているかとか変数の付け方とか、どういうところを今見られているんですか？
高橋：きれいなコードを書く人って学生さんなんでそんなにいないんで。まあそれほど……変数名がどうとかまではあまり期待してないですけど（笑）。
山根：そこまで期待してない。
高橋：定量的な部分でいうと、明らかにエンジニアが見ればわかるんですけど、簡単なミスでけっこう何時間もつまるってことがあって、そこで引っかかっている人も、点数でいっちゃうと点数が取れない、というところで、あえてそこで見ました。
山根：なるほど。ありがとうございます。じゃあ次に庄司さん、お願いします。
技術ごとの文化に合わせてコードが書けているか？
庄司：これはさっきのWebエンジニアとiOS,Androidエンジニアで分けている理由にもなるんですけれども、まずちゃんとそれぞれの文化のコードが書けているか。
例えば、iOSだったらiOSなりの書き方ってあるんですよね。ビューにロジックを置かずにどこにロジックを置くか、というところなど、設計部分まで含めてちゃんと書けているか、っていうのを見てます。
だから、ただ単に問題が解けていればいいというわけではなくて、そういう設計部分。だから、逆にうちは、その変数名も含めて、設計の部分は見てますね。どれだけ最適化されているか、あとは問題文を、言うんでしょう、わざとけっこう柔軟にとれる文にしているんですね。問題の内容は言えないので、ボヤッと言うんですけども。
その仕様をどう解釈して、ちゃんと拡張性のあるように実装するかも含めて見ています。だから、コンパイルが通るとか、そういうのはもう当たり前ですね。
山根：ありがとうございます。これは庄司さんに対してのご質問かもしれないんですが、「すべての人がOSS活動しているわけではないと思うのですが、GitHubだけで判断できないエンジニアのスキルセットの把握をするための、なにか方法があったら教えてください」ということです。
庄司：そうですね。そうだと思っているので、課題を受けてもらう。GitHubだけではない。
山根：その中でGitHubを使わせるっていうのをやる。
庄司：GitHubのアカウントを持っているのは、当たり前だよね。そこで公開している公開してないは置いといても、アカウントは持っているよねっていう感じですね。
「ゲームが好き」をどう評価するか
山根：ありがとうございます。あと、高橋さん宛にご質問があって、「選考においてゲーム好きが重要とのことですが、自社のゲームが大好きというのが選考可否に影響を受けるものですか？」。
高橋：自社ですか。ないですね。
山根：（笑）。
高橋：ちょっと質問とズレちゃうかもですが、そもそもゲームが好きかどうかで注意しなきゃいけないのは、本当にゲームだけ好きな人だと、やっぱりさすがにエンジニアとしては認められません。ゲーム好きであり、だからこそエンジニアとして、要はプログラミングでゲームをつくりたいと思っている方っていうのを選んでいるので、うちの会社が好きかどうかは、他のゲームが好きでもぜんぜん問題ありません（笑）。
山根：ありがとうございます。
高橋：僕も、別にうちの会社のゲームだけが好きなわけじゃないですし（笑）。
山根：（笑）。他のゲームもやると。
高橋：はい。
山根：ありがとうございます。ちょっとおもしろい質問があるんです。「人物面・コミュ力はどの程度見ていますか？ また、未経験の採用って何パーセントぐらいですか？」さっきのお話を聞くと、庄司さんはもう……。
庄司：未経験はなしです。未経験でエンジニアはないです。
山根：ありがとうございます。高橋さんは？
高橋：そうですね。うちの場合、職種で、要はR&D系と本当にゲームプログラマーとツールつくる人がいます。
例えば僕は、どちらかというとゲームプログラマー系を見ているんですけども、ゲームを1回もつくったことがない人間は、正直それ以外になにか本当に光るものがない限り、つらいなと思います。それで「ゲームつくりたいんです。ゲーム好きです」って言っても、まったく説得力にならないんで。
山根：やっぱりつくってみてほしい、っていうのがあると。
高橋：そうですね、はい。
山根：お二方ともあれですね、学校だったりもしくは社会人の中でつくったことがある経験、もしくはちゃんと選考フローの中で、GitHubで問われたり、ちゃんと使えるかっていうのを、調べたらできる環境が世の中に今そろっているんで、そこの伸びしろじゃないですけど、そういったところを選考の中で見られている、みたいなところがありますよね。
高橋：そうですね、はい。
人事とエンジニアの役割分担
山根：ありがとうございます。では、次のご質問に移っていきたいと思います。「人事とエンジニアの役割分担」ですね。今日これは50パーセント50パーセント。おそらく人事部に関わられるエンジニアの方と、人事の方がいらっしゃるかと思うんですけれども、ここの役割分担、質問としてあれなんですけれども、「難しくないですか？」ということは聞いてみたいです。
お二人とも、今、エンジニアとして働かれている中で人事に関わってらっしゃる。その中で選考フローもつくられてきている部分もあるとは思います。どういった役割分担をやってきたのか、なにかこうやっていくうえでTipsみたいなものがあるのか、ぜひ聞いてみたいと思うけれどもいかがでしょうか？ じゃあ、庄司さんから。
庄司：まず「難しくないですか？」っていう話でいうと、もうね、軸足が違う職種同士は、役割分担が難しいんですよ。
山根：（笑）。
庄司：それは認めるしかなくて。エンジニアもDevOpsとかよく言われているように、DevとOpsだけでも役割分担難しいと言われている。軸足が違うとやっぱ難しいんですよね。なのでどうするかっていうと、お互い歩み寄ってコミュニケーション取るしかないねっていう元も子もない話になるんですけども。
僕の場合はクックパッドに入社したのが5年半、6年ぐらい前で、入社した時から「僕は一緒に働くエンジニアを自分で見たいから、採用に関わらせてくれ」って言いました。
だから、選考のフローとかも「こういうふうにしたほうがいい」ってアドバイスもしたし、実際、面接とかもガンガンやってたし、っていうのでどんどん関わっていってたっていう感じですね。
山根：なるほど。先ほどの選考フローは、2年前、3年前ぐらいからでしたっけ、人事に関わられたの。
庄司：そうですね。3年ぐらい前に人事部長になった時に、あのかたちに落ち着かせたというか。でも、昔からあのかたちが基本メインではありましたね。
山根：じゃあ、フロー自体はそんなに変わってなかったんですか？
庄司：フロー自体はそんなに変わってないです。使っているツールがちょっと変わった感じはありますけども、フロー自体に大きな変更はないですね。
山根：なるほど、ありがとうございます。高橋さん、いかがでしょうか？
高橋：切り分けに関しては、弊社ではエンジニア以外にもアーティストや企画、サウンドと他に職種がいるので、僕のエンジニアみたいな作業は、その特殊な自分たちの職種の能力を測れるかどうかが、基本我々のやる部分っていう感じにしています。
山根：なるほど、ありがとうございます。
スキルチェックを始める企業へのアドバイス
山根：ちなみに、ここでなにかご質問がある方がいたら、ぜひ投稿いただきたいんですけれども。コード採用の部分に対する質問が比較的多いので、後ほどまだお答えできてない部分については触れていけたらと思います。
こちらが最後のご質問になります。「これからスキルチェックを始めます。すでにスキルチェックを導入している企業さま、スキルチェックをなにかしらやられている企業さまが多かったと思うんですけれども、そういったこれから始めようとされる企業さま向けに、Tipsがあればぜひお話いただければと思います」。高橋さん、こちらいかがでしょうか？
高橋：そうですね。僕も採用する時に聞いたんで、「他のゲーム会社、（スキルチェックを）使ってませんか？」っていう感じで（笑）。まあ、わかんなかったんですけど。Tipsっていうか、始めたばっかなんで。
ぜひ、とりあえずのお試しでできるっていう気軽なノリでできるかわからないんですけど。僕も始めたのは、今回に関しては正直会社に対しては、「まずは試して、ダメだったら元のに戻します」ってお願いしてやってもらったっていうかたちなんで。たぶん続けると思うんですけれども、ぜひやってもらって、情報共有をしたいです。よろしくお願いします。
山根：ありがとうございます。庄司さん。
庄司：スキルチェックを始めようとする時に、まず絶対にやらなきゃいけないなって思っているのは、どのレベルのエンジニアをうちは求めるんだっていう基準値を決めることです。それを決めないでただスキルチェックをしても意味ないんで、そこをちゃんと考えることが一番大事かなと思ってます。
「うちはこのぐらいのレベルのエンジニアがほしいから、スキルチェックをやったらここを超える人じゃないと採らないよね」みたいなのを先に決めとかないで、いきなりスキルチェックだけ導入しちゃうと、コードが出てきたけれども、「これ、通していいのかな？ 通しちゃいけないのかな？」って、結局現場が混乱する状況になります。なので、まずそこはそろえておくべきかなっていうのがありますね。
