【まとめ】コーディングテストを考える過程で調べたことや考えたこと
こんにちは。@inase17000です。
仕事がちょうど忙しくなる時期にあわせて、大学院の授業がはじまり、日々テンテコ舞いです。こんなときこそブログやポッドキャストと向き合っていきたいですね。
さて、エンジニア採用においてコーディングテストの導入を考えておりまして、他社の事例などを色々調べました。耳にはするものの、あんまり頻繁に目にするものでもないので時間をかけてちゃんと考えたいと思っていました。
せっかくだから調べたことや考えたことをシェアしておきます。今後コーディングテストを考える人々のお役に立てれば幸いです。
コーディングテストとは
まずは何事も定義から入るのが肝心ですね。技術系の記事はだいたい「●●とは」から始まります。
コーディングテストは、採用候補者に対してプログラミングに関わる課題を出題し、その回答を提出してもらう形式の選考プロセスの一部を指します。
コーディングテストの別名（エイリアス）
・プログラミングテスト
・コーディングチェック
・技術試験
・コードテスト
調べていくなかで面白かったのは、呼び方がいろいろあるということです。コーディング≒コード≒プログラミング≒プログラムという表記揺れの関係でいろんなパターンを観測できました。呼び方は違えど、それぞれ同じものを指していることが多いです。
この文章内では読みやすさのために、「コーディングテスト」で統一します。
コーディングテストの目的
コーディングテストはエンジニア採用において面接だけでは判断がつかない部分を補うことが主な役割です。出題する企業側の目線になってみると、主に目的が２つ存在します。
①技術力（設計、プログラミング）を測る
履歴書・職務経歴書に「PHP 5年以上」と書いてあっても、実は本人の手ではほとんど触ったことがなく、既存コードのバグ修正程度で携わってましたということもよくあります。経験年数や環境の詳細は、文面に書いてある内容だけでは判断がつきません。
ちょっとしたコードのまとまりを作ってもらうだけで、その経験が実の詰まったものか紙面上の話だけなのかがわかりやすくなります。イケてる開発者は少ない行数のコードにも意味を持っていますし、その根拠を説明することができます。
②課題に対する対応力を測る
選考プロセスが終わり、チームにジョインしてもらった後には、実務に入っていくことになります。実務の中では、大小あわせてさまざまなビジネス的・技術的課題に直面することになります。
コーディングが必要な実務の中でありそうな事例を切り取り、そのアウトプットに至るまでの思考プロセスやアウトプットの表現力、説明能力を見ることで、ジョイン後の課題に対する対応力が継続的に発揮できそうかを確認します。
また、出題される側である採用候補者にも、目的があると思います。
例えば、実際に書いたコードをもとにコミュニケーションできるので、面接官として登場するエンジニアのレベルを見抜くこともできるでしょう。一緒に働くことになるであろうエンジニア、チームが指摘する技術的観点や関心ごとを知ることでその会社の理解が進むに違いありません。
コーディングテストのやり方について分類を洗い出した
前置きが長くなりました。インターネットから約10社の事例を見つけることができました。（思ったより情報公開されていないことに驚き...）その中でいくつか分類できる違いを見つけましたので整理しておきます。このほかにも言語指定や開発環境の指定、コード提出方法の違いなど細かい話は色々あったのですが、主要どころに絞ってます。
●オフライン or オンライン
コロナ禍の現状を考えるとほぼオンラインでの選考が大前提になっていると思います。
あえてオフラインでコーディング（例：ホワイトボードでコーディング）をしてもらうことで見れる観点としては、プログラミングに必要な事項が頭の中に入っているか、記述する順番を見ながら無駄のないアプローチになるか、などが挙げられます。
しかしながら、ジョイン後の開発環境（リモートなら自分の家、マシン）でパフォーマンスが出せるかが重要なわけですから、あえて不都合な制限を増やして特殊環境でのパフォーマンスを取り出し評価するのはあまり意味がないのではないかと感じました。
このオフライン/オンラインの軸は、制限時間に関しても影響を与えます。オフラインの場合は面接官立ち会いになりますから、制限時間が短くなりがちです。またオンラインの場合は、制限時間をもうけたとしても実際それが守られたかどうかを確認するのは難しくなります。実質、無制限と変わらない状態になりそうです。専用のサービスを利用するなど対策をとれば、オンラインにおいて制限時間を設けることも可能になります。
●一般的なアルゴリズム or 業務を意識したケーススタディ
海外のようにComputer Scienceの学位以上が当然必要になってくる環境においては、一般的なアルゴリズム（ソートや最適化問題など）を実装してください、という出題が考えられます。USではLeetCodeやCodilityなどのサービスを使ってテストを行うことが多いようです。
一方で日本企業においては、単純にアルゴリズム実装の知識の有無を問うのではなく「課題に対する対応力を測る」ために、実際の開発内容に近いケーススタディでの出題が多くありました。
「●●できる機能を作ってください。使えるリソースは○○です。」といった内容で出題されますが、必ずしもその企業のサービスに関連するとは限らず、世の中でよくありそうな架空のサービスを例にとることが多かったです。これをその企業の技術課題に近しいものが出題されればジョイン後のパフォーマンスがダイレクトに見れるのでしょうが、企業秘密との兼ね合いでなかなか実現が難しいのでしょう。
●コーディングテスト単体 or 面接とセット
コーディングテストそのものだけで採点がされ、合格不合格が決定している企業がありました。大量に応募があるような会社はそれでスクリーニングしているのだと思います。（そもそもこういうコーディングテストを設置するだけで、ちょっとした精神的ハードルを設けるという効果も狙っていそう）
面接とコーディングテストをセットでやる場合には「Coding Interview（コーディング面接）」と呼んでるところもあるみたいです。わかりやすい。
●採点基準を公開 or 非公開
候補者のUXにとって重要なポイントになると思われるのが採点基準ですね。
企業ごとにコーディングテストの目的に沿った、採点基準を事前に設けていると思う（定量的なものになっていなくても、少なくとも確認観点は必ず定まっているはず）ので、それを公開していくかどうかは企業のスタンスによりそうです。
個人的には、候補者の緊張を解いて普段通りのパフォーマンスを出してもらえるようあらかじめ採点基準になりえないこと（＝候補者が気にしなくていいこと）を明示しておくことはとても重要だと思います。神は細部に宿るものの、神の宿木のない細部だけ作り込まれると本末転倒ですしね。。。
で、ユアマイスターはどうなん？
ここまでやっておいて、ユアマイスターではどうなんだ？という話なのですが、まだ始めたばかりの状況で、今後ふりかえりをしながら順次アップデートし続けていくことになると思います。
フロントエンド開発を前提にした問題からはじめていますが、モバイル開発、バックエンド開発やインフラに関しても手応えを見ながら運用をはじめていけるようにブラッシュアップしていく所存です。
ずっと大事にしたいのはコーディングテストをやる目的ですね。
参考リンク
今回コーディングテストについて考えるにあたって参照したリンクをリストアップしておきます。みなさんに感謝。
P.S. ポッドキャストでもこの話題で話した回があるので宣伝しておきます。
現場からは以上です！！