■Speaker 情報
株式会社ゆめみサーバーサイドグループ
サーバーサイドエンジニア・シニアアーキテクト
仲川 樽八 様
2000年の会社創業期から株式会社ゆめみに参画。バックエンド開発からWeb画面の作成に携わる。直近10年はAPIなどのバックエンド開発に専念していたが、近年会社として即戦力だけではなく新卒採用に注力していく中で、現在はエンジニアリングと採用を兼務している。
■イベントレポート概要
新卒採用市場において、テックブランド力が高い株式会社ゆめみ。同社にて、サーバーサイドエンジニアとして開発とエンジニア採用に携わる仲川様にご登壇いただき、採用におけるコードテストの位置づけや活用のポイント、コードレビュー粒度揃えの工夫などについてお話いただきました。■「テストの解き方」に注目することで、候補者のコーディング経験を測る
モデレーター：まず最初に、コードテスト導入理由やコードチェックをする背景をお伺いできますか？
仲川氏：コードテスト導入のきっかけは、新卒未経験者にプログラマーのポテンシャルがあるかを見るためのツールとして使い始めたことです。
元々はコードチェックどころか新卒採用をほとんどやってなかったんですね。中途採用ばかりだったのですが、弊社が拡大する際に新卒採用を始めることになりました。当時はポテンシャル採用と言って、プログラマーとしての資質・能力があるのかを見極めるのが非常に難しくて、悩んでいたんですよ。そんな中で候補者のコーディングを見るのは手っ取り早く、やってみたことがきっかけです。
この時点では、社内に新卒で未経験の方をエンジニアとして育て上げるシステムもなかったため、コードが書ける方を見つけるという導入目的がありました。
モデレーター：なるほどです。最初のきっかけは新卒採用という入口から。育成システムが整っていなくとも、業務に入れる素地がある新卒を通過させたいという目的で、最初は導入されてたという流れだったんですね。
仲川氏：そうですね。非常に中途の流動性が高い時期を経て、企業を拡大するにあたって、ちゃんと新卒を取って会社で育て、長く所属いただくという考えに移っていきました。
近年は新卒採用市場での会社のブランド力が向上したので、応募者が増えてきています。また、応募者のレベルが上がってきていて、足切り目的のコードテストでは落ちる人がほとんどいなくなっています。我々が利用しているギブリーのTrack Testでは、問題ごとに定められたUnitテストの通過率で点数が付きます。以前は50点以下のスコアで足切りにしていたのが、60、70、80、90…と、どんどん上がってきて、今はほとんどの方が満点を取るようになってきています。なので、Unitテストの実行が満点であっても、その書き方の方に目を向けています。そこでコードチェックです。
配慮が読み取りづらいとか、独特な書き方になってしまっている、変な癖がついてるんじゃないかな、みたいな話が通過の理由になっています。いわゆる点数に出る能力を見るのではなくコーディング経験を問う目的で現在は使っています。
モデレーター：新卒市場でブランド力ができてきたからこそ、コードテストの点数を取れるだけではなく、経験もあるようなより優秀な方が入ってきている状況ですかね。元々は未経験者の方のチェックという立ち位置でコードテストをやっていたところから、徐々にレベルが全体的に上がってきていると。
仲川氏：そうです。それでコードチェックの重要性が上がってきているわけです。
■優秀エンジニアの見極めと魅力付けの両立が叶う採用プロセス
モデレーター：選考フロー内でのコードチェックの実施タイミングについて、ぜひお聞かせいただきたいです。
仲川氏：弊社だと書類審査で良さそうだなと感じたら積極的に通過にしていて、そこからコーディング試験でしっかりと見ようと考えています。コーディング試験と機械採点を通過した後、その次にエンジニアによるコードレビューがあります。その後は、エンジニアの一次面接と代表による最終面接の2つなので、コーディング試験がウエイトを占める選考フローになっています。
モデレーター：なるほど。ちなみに、事前のカジュアル面談などで自社のアトラクトをした上で、真剣に受験するマインドになった上でのコーディング試験であれば、ある程度熱量を持って受けてもらえると思います。一方で、書類選考の後にコーディング試験を突然出された際、踏み留まる受験者がいるかもしれないと考える人事もいるようです。
そのあたりはどのようにお考えですか？
仲川氏：もともとはエンジニアなら技術で勝負して来てほしいという考えだったのですが、ここ何年かですかね、コードチェックの観点やサンプル問題、選考フローをウェブで公開させていただくことで、 できるだけ敷居を下げています。 今も新卒の方も受けやすいようにする工夫を模索してるところです。
モデレーター：ちなみに、コードレビューの結果は候補者にフィードバックしているのでしょうか。
仲川氏：試験の点数足切りを突破し、コードチェックを行った候補者全員にフィードバックしています。
モデレーター：いや、すごいですね。新卒の方からすると自分のコードの内容について詳しくレビューをいただけるというのは、めったにない貴重な経験になりそうです。
■コードチェックで、仕様書に書かれていない部分への想像力や他人との協調性が見える
モデレーター：具体的にコードチェックの評価をどのようにされていますでしょうか？
仲川氏：うちの会社に合わせたコードチェックの観点を定めています。
最も大事にしている観点が３つありまして、1つめがチームでの開発を意識したコードかどうか、２つめが長期のメンテナンスを意識できているか、3つめがバグの入り込みにくいコードになっているかどうかです。
そういったコードをかけるということは、うちの求めているような、経験のある優秀な人材だと判断しています。コードから仕様書に書かれていない部分への想像力や経験、他人との協調性の部分を読み取っています。後は学校で習うような一般的なことで、メモリー効率、実行効率を意識できているかですね。ここはある程度の重要度ですかね。
その一方で、複雑な要件の実装を短時間で行えるかや、特定の言語、特定のアルゴリズムを知ってるか知ってないかなど、ただの知識問題にしたくないのでここら辺に関してはあまり意識していないでやっています。どんな観点を重要視するかは、会社によって変える必要があると思います。
モデレーター：そうですよね。企業様によっては、この言語ですぐに活躍できる方を採用したい。なので、特定の言語を使える方を見定める問題を選ばれる企業様もいらっしゃいます。ただ、それよりも基礎体力といいますか、チームでの開発を意識しているコードであるかをよく見られているイメージです。
仲川氏：言語の流行り廃りは激しいです。今、流行っている言語の習熟度が高くとも、将来ずっと使うかはわからないので言語指定は幅広くしています。やはり、データ整合性・安全性、可読性、将来のメンテナンス性があるかが重要でしょう。
モデレーター：そのあたりの要素は、中途の方ですと既にご経験されていて、コードからも把握しやすいかと思います。一方、新卒でもそのようなポイントでコードに差が出るものなのでしょうか。
仲川氏：すごく差が出ますね。大学の授業で習ったことや研究内容で必要なことは、どうしても使い捨てのコードになってしまうことが多いです。それとは別に、例えば自分でサービスをやっている。サークルでチーム開発をしている。そのような経験の差が、コードにデータ整合性・安全性、可読性、将来のメンテナンス性があるかどうかで見えてくる感じです。
■制限時間に余裕がある難易度に調整。候補者の見たい観点を浮き彫りに
モデレーター：試験で出題する問題の難易度はどのように決めましたか？ホワイトボードコーディングやペアプログラミング、自社のサービスのコードを一緒に書いてみるなど、様々な手法があると思います。その中で、コードテストで出題する問題選びや難易度調整も非常に重要になりますが、ゆめみ社ではどのように決めたのでしょうか。
仲川氏：制限時間を200分で設けています。ただ実態は、60分ほどで解けてしまい、残り時間はリファクタリングに十分使える簡単な問題を選定しています。 通過率が30％程度の難しい問題にしてしまうと、コードが書きかけなのか書けないのか、時間があればリファクタリングできるのかが判断できないんですよね。それを判断するために、納得のいく状態でコードを出していただき採点しています。
問題を選ぶ時間は結構かけましたね。 我々の見たい観点をきちんと見られる問題を選定するため、初級中級あたりのものに関しては一通り全部目通しました。「あ、これだとこの観点がちょっと見にくいな」などと考えながら数日かけて決めました。
■評価テンプレートの運用とレビュー会で、評価の粒度を揃える
モデレーター：多くの言語での受験を受け入れていると、エンジニア選考官のレビューの粒度を揃えるのが大変かと思います。そこの工夫があれば是非お伺いしたいです。
仲川氏：まず、各言語ごとに模範解答を作成しました。また、全言語共通の評価テンプレートを作っています。出題している問題専用の評価テンプレートなので、それを見ながらチェックしていけば、ある程度揃うかと思います。
更に、レビュワーは必ず2名以上付けます。「短くてシンプルに書かれているが、もう少々改善点ありそうだね」というような、評価が難しい場合には、3人目の判断を見ることもしています。また、過去の回答を利用したオープンレビュー会を複数回開催しました。良いケースと、判断を迷うケースをまとめています。
モデレーター：なるほどです、ありがとうございます。エンジニアの皆さんのマインドセット的には、人事業務にもミッションを持たれて動く体制になっているのでしょうか？
仲川氏：そうです。私自身は、他の業務と平行しながら人事業務のウエイトを大きく持っています。ただ、採用人数が増えてきて、他のエンジニアの力を借りてレビューすることが必要になってきています。
モデレーター：皆さんが社内の状況に理解を示して、人事業務もオーナーシップを持って回す体制になっているとは素晴らしいですね。人事とエンジニアの間でその体制を作れてることが、すごくいい企業文化なんだろうなと想像しました。
仲川さん、本日はご登壇いただきまして、誠にありがとうございました。
