Webエンジニア採用で用いる「コードテスト」ができるまでの軌跡

QuipperのWebエンジニア採用におけるコードテスト

鈴木和幸氏：それでは『QuipperのWebエンジニア採用におけるコードテスト』という題でLTさせていただきます。Quipperでソフトウェアエンジニアをしております。@kecholといいます。よろしくお願いします。

まずQuipperという会社を知らない方もいらっしゃると思いますのでさらっとご紹介させてください。

Quipperはロンドンに本社がある教育系のスタートアップです。もともと海外向けに教育動画サービスのQuipperというのをやっていたんですが、2015年にリクルートグループに買収されまして、現在は日本向けのプロダクトのスタディサプリと海外向けのQuipperの両方を展開しています。

「海外で」と言いましたが、Quipperは現在インドネシア、フィリピン、メキシコ、日本の4つの国に拠点があり、エンジニアの採用は各拠点でそれぞれ行なっています。

今日は、以前Quipperのプロダクトチームのブログで僕が書いた、このLTと同じ題の『QuipperのWebエンジニア採用におけるコードテスト』というお話を少し掘り下げたいと思います。コードテストを実施する側のお話です。

Webエンジニアの採用プロセス

まずQuipperのWebエンジニアの採用プロセスを少しご説明させていただきます。

応募チャネルや応募してきた方によって変わることもあるんですが、基本的にはまず書類のスクリーニングで募集要件を満たしているか確認して、一次面接でカルチャーマッチや技術力を確認させていただいたうえでコードテストに進んでいただいています。

コードテスト以降のプロセスでいくと二次面接が技術面接となっていて、最後のVP of Eの面接で改めてカルチャーマッチを確認させていただいたうえでオファーというかたちのプロセスになっています。

そのプロセスの中で実際に行なっているコードテストが、この画面の右側のようなものになります。

右に出ているコードはRubyのコードになるんですが、現在は1問あたりだいたい2時間程度で解けるようなシンプルなコードテストを実施しています。

候補者には自宅で解いていただいた上でメールなどで提出いただくというかたちを取っています。また、言語については実際に我々がプロダクトで利用しているRubyだったりとかJavaScriptのような言語を使ったテストをさせていただいています。

言語とかフレームワークが未経験だったとしても一般的なHTTPとかDBの操作というような知識があればキャッチアップしながら十分解けるような内容のテストになっています。

実はQuipperではもともともっと複雑な、1つのアプリケーションを丸ごと作ってもらうようなコードテストを実施していました。

ですが、採用プロセスでコードテストの時点での落ち率高かったということがありまして、それを改善するためにこういうテストのかたちにしました。

それまではコードテストのプロセスだけで2週間かかっていて、コードテストに時間がかかってしまうために選考中に他社に決まってしまうとか、そもそもコードテストを提出してもらえないみたいな問題があったのでよりシンプルなかたちに切り替えていこう、という話になりました。

コードテストにおいて譲ったところ、譲れなかったところ

コードテストを見直すにあたってさまざま議論はあったんですが、まず譲らないところとして、そもそもコードテストはなくさないということは決めました。どれだけ面接の評価が良くても書かれたコードが悪ければ落とさざるを得ないと。

さらにコードが書かれているものを実際に公開されている人が全員ではないということと、面接で聞き出すことって難しいよね、という話もあり、コードテストを実施してきちんと実力を見極めるという方針をまず決めました。

一方で、あくまでコードテストを軽くしていくという方向性だったので、最低限のレベルを担保することにコードテストでは集中するということ、そのために1つのアプリケーションを作ってもらうことはせずに技術要素をそれぞれ分解してテストを行うということを決めました。

なお、今のところCodilityとかLeetCodeで出てきたような純粋なアルゴリズム問題というのはQuipperのテストでは出していません。大きく2つの理由がありますが、1つ目の理由として日本ではまだメジャーな手段とは言えない、というのがあります。

まず、欧米とは違って日本ではソフトウェアエンジニアという職は必ずしもCSの学位を持っている人が就く職業ではないので、そもそも候補者がアルゴリズムの知識を持っていることを前提としていないと思っています。加えて、Daigo Satoさんのホワイトボードコーディングの話でもあったとおり、そうした課題を解くのはある程度訓練が必要な技能だと思うんですが、実際候補者がそういう訓練を積んでいることってすごく少ないと考えています。結果として、僕らが採れるパイが少なくなってしまうというのが理由の1つ目です。

なぜ純粋なアルゴリズム問題ではないのか？

あともう1つの理由として、我々がサービスを作るうえでそうしたアルゴリズム的な解法が必要な課題がまだボトルネックになっていないと感じています。スマートニュースさんみたいに機械学習や自然言語処理を活用しているシステムだったり、先ほどのゲーム業界みたいな当たり判定が必要になるようなシステムを作る必要があるとそういうアルゴリズムの問題を解けることが非常に重要になると思うんですが。

現時点の我々のシステムだとDBのアクセス数とかキャッシュ戦略とかがシステムのパフォーマンスに対して非常に支配的なので、そちらをまず確認したいということで優先度を決めています。

あとは組織的な話でいくと、アルゴリズムの知識があっても実際の現場で使われる言語やフレームワークを経験していない人材を受け入れられるほど成熟したエンジニアの組織ではないということもあって、ある程度自力でフレームワークや言語をキャッチアップしていける方の採用を重視するという事情もあります。

コードテストができるまで

では実際のコードテストをどのように作っていったのかという話を少しさせていただきます。実際にコードテストを見直すにあたって、採用メンバーで、まずはスプレッドシートにどういう項目をテストしていきたいのかをまとめました。

同時に、コードテストでは担保できない部分について、二次面接で見るのかとか、あきらめて見ないと決めるのかといったことも合わせて議論していきました。そうしたように実際にどういう観点を見るかというのを決めたうえで問題のたたき台をそれぞれの観点に対して作っていきました。

次に、社内のエンジニアに実際に解いてもらって適切な難易度かどうかを確認しました。

とくに難しすぎないかとか、必要な時間はどれだけかかったのかみたいなところを確認しつつ、想定してない解答がないか、チートができるようになっていないか観点で確認しました。

ただこうやって確認しても、難しすぎないということはわかるんですけれども、すでに入社している人にしか確認できないので、逆に簡単すぎないというのはわからないんです。なので、最後の最後は勇気を持って運用に乗せるということをしました。

実際に運用に乗せたあとどうやってレビューしているのかという話で言いますと、僕らはCodilityのようなシステムとかツールを使っていないので、提出があったらGitHub上の課題用のリポジトリに候補者の回答をPull Requestとして提出してレビューしています。

そもそもテストの中で環境の差異が出ないようにDockerfileをテストに含めてテストできるようにしているとか、Pull Request上で自動テストが回せるようにスクリプトを用意しておくとか、レビュー内容をコメントで残すようにしたりとか、工夫しながらレビューを行なっています。

プラスしてやっていることとしては、3、4人の採用メンバーのエンジニアがモブレビューで同期的にコードをレビューすることで早く合否判定ができるという工夫もしています。

Codilityとかtrackとか、今日出てきたオンラインテストを行うツールについては、ネガティブな印象を持っているから使っていないという訳ではなくて、まだちゃんと使ってみたうえで判断ができていないだけなので、機会があれば使ってツールとかも模索してみたいなぁとは思ってます。

あと、オンラインテスト用のツールではないんですけれども、今だとJavaScriptのコードテストを自動テストを回して確認するのが難しいので、動作確認をローカルの開発環境でやらなきゃいけなくて。そういうものはCodePenとか別のツールを使って提出してもらうのはありかもしれないなぁと思ったりしてます。

導入した結果

最後に、実際導入してみた結果についてお話させてください。改善したコードテストでは、狙ったとおり提出までの時間が大幅に短縮されて、2週間とかかかっていたものが3日程度で提出してもらえるようになりました。

スクリーニングプロセスとしてもある程度機能しているという実感を持てていて、通る人もいれば、落ちる人もいます。

とはいえまだ難易度の調整だったり継続的なメンテナンス、例えばライブラリを使ったコードについては、そのライブラリに新機能が載ると新しい解法が出てくるとかっていうこともあるので、そういうこともキャッチアップやアップデートをしていくということが必要かなと思っています。

あとはコードテスト自体が変わったので、その後の二次面接も合わせてまだまだ改善が必要だと考えています。コードテストの改善だけでもある程度良い成果を出せたので、引き続きやっていきたいと思っています。

これは余談なんですけれども、弊社のインドネシアの拠点ではシンプルなコードテストに移すことをせずにまだ1アプリケーションを丸ごと提出してもらうという構成を変えずに実施しています。

これはなぜかと言うと日本と違ってインドネシアの現地の企業だとほとんどコードテストを実施していて、日本みたいにコードテストを実施することで採用上不利になることが非常に少ないということと。

インドネシアだとチートをする候補者がいて。チートしてきた候補者をあぶり出すためにそれなりの量のコードを書いてほしいということを現地の担当者が言っていました。

そうした話を聞いて、採用のプロセスについて何か一義的な方法があるわけではなくて、「国とかチームの状態で採用のベストプラクティスというのが変わってくるのかな」と思っています。これからも自分たちに合った採用のやり方を考えていきたいなと思っている次第です。以上です。ありがとうございました。

（会場拍手）