コーディングテストは意味がない?優秀なITエンジニアを採用するために
人事や各部署の採用後担当の方とお話していると、外資系・日系企業を問わずソフトウェアエンジニアの採用に苦労している方が少なくありません。ボトルネックはサイバーセキュリティ・エンジニアのように絶対数が圧倒的に足りない、ということではなく、「優秀な」エンジニアが少ないということだそうです。ジョブ型採用の要でもあるスキルの見極め。どうすれば優秀なソフトウェア・エンジニアを見分けることができるのでしょうか?
最も単純な解がコーディングテスト(コーディング試験)です。実際に課題を出してコードを書いてもらえば実力は一目瞭然のはず。実際にGoogleやMeta、LINEやYahooなど、優秀なエンジニアがたくさん集まる世界的なIT企業で採用されている手法です。
でもコーディングテストをやっているのに採用がうまくいかない…そんな悩みを抱えている方もいらっしゃるのではないでしょうか?
そのような場合は、コーディングテストの活用・実施方法を見直すべきかもしれません。この記事ではコーディングテストの限界と、コーディングテストが向いている場面・そうでない場面について考えてみたいと思います。
コーディングテストの限界
コーディングテストはアルゴリズムの知識を測るもの
コーディングテストの多くはアルゴリズムの知識を試すものです。
アルゴリズムは開発の基本ですが、プログラミングの実務能力と必ずしも比例しません。コーディングテストで高得点をとれても、職場では「使えない」プログラマーもいますし、コーディング試験は苦手でも、開発者として非常に優秀な人もいるのです。
エンジニアは不慣れな環境で試験を受けなければいけない
更に、試験を行う環境について考えてみましょう。ITエンジニアが日常的に仕事をするのは統合開発環境(IDE)です。優秀なエンジニアほど、自分が使いやすいようにIDEをカスタマイズし、よく使うリソースにすぐにアクセスできるようにするなど工夫を凝らしているでしょう。
一方、一般的なコーディングテストではこのような使い慣れたツールを使用することはできません。実際の仕事ではあり得ないような環境で試験を受けるのです。このような環境でよい結果を出せるかどうかは、必ずしも日常的なパフォーマンスとは関係がありません。
コーディングテストの内容が実際の業務内容とかけ離れていることが多い
多くの企業は一般的なコーディングテストを利用しており、入社後の業務との関連性が低いテストになってしまっていることが少なくありません。
バグを修正する人が必要なのに、一からアプリを作る能力を評価するコーディングテストを行う意味はあるでしょうか?
これは極端な例ですが、これではテストを受ける候補者が「あなたが期待する業務において」優秀なエンジニアかどうかはわかりません。コーディングテストで測る能力と入社後に期待する能力がマッチしていないからです。
コーディングテストは時間がかかる
コーディングテストはそれなりの時間がかかります。「たった1,2時間じゃないか」と思われるかもしれませんが、候補者は普通、複数社の面接を受けています。10時間以上拘束される人もおり、仕事をしながら転職活動をしているエンジニアにとっては大変な負担です。
コーディングテストの時間を短縮すればより多くの候補者に受けてもらうことができ、バーンアウトせずに最後まで完遂してもらえるかもしれません。また、選考のスピードアップにもつながります。もちろん、候補者エクスペリエンスが向上するという利点もあります。「優秀なエンジニアが少ない」ような売り手優位の転職市場ではオファー受諾率アップに直結するポイントです。
コーディングテストはシニアエンジニアやマネージャーの採用には向かない
新卒やジュニア・エンジニアがプログラミングの基礎を理解しているかを知りたい場合には、コーディングテストは明解かつ有効な方法です。
しかしシニアエンジニアやマネージャー級の人材の採用となると話は違います。ベテランの開発者に業務との関連性があまりないチープなコーディング試験を課せば、逆に見限られてしまうかもしれません(売り手市場では尚更です)。
長年開発業務に携わってきたエンジニアには単純なテストでは測れない経験や勘があります。また、チームの中で求められる役割を果たすためにはコーディング能力とは違う素質も必要です。足切りとしてコーディング試験を行うのは適切ではないでしょう。ケース・インタビューやコンピテンシー面接などを活用し、難局の乗り越え方や問題解決に望む姿勢・アプローチなどをしっかり見極めるべきです。
IT・テクノロジーを変革したい場合は、このような経験豊富なシニアエンジニアや現場をリードしてくれる人材が欠かせません。現在、デジタル・トランスフォメーション(DX)が重要と考えている国内企業は85%を超える(NEC『IT投資動向調査2022』より)と言います。優秀なシニア人材はひっぱりだこ。コーディングテストにこだわり過ぎて人材確保のチャンスを逃さないような選考プロセスを築くべきです。
結論:コーディングテストは不要か?
コーディングテストには上述したような限界もあります。ですが求める能力を的確に見極めた上で、その能力を図るのに相応しい内容の試験を公正・正確に行うのであれば、合否の判断材料として役立つでしょう。
例えばコーディングテストでシンプルなソリューションで課題を解決できるか、テスト可能で拡張性・可読性が高いコードを書けるかといった点を確認することはできます。
ソフトウェア・エンジニアの中途採用でコーディングテストを行う場合は、次の点に配慮して組み立てましょう。
- 汎用的なコーディングテストを使用しない。特定のプログラミング言語・フレームワークの知識を問うものがベターです。
- 使用するコーディングテストがポジションの要件やジョブ・ディスクリプション、入社後に担当する実務にマッチしているかを毎回確認する。
- テスト時間に配慮する。(理想は1時間以下です!)
- 自動採点のみで判断しない。優秀な候補者を逃してしまうリスクがあります。
- コーディングテスト以外のリソースも併用する。ポートフォリオを見せてもらう、過去に描いたプログラムを説明してもらう、GitHubを活用する、Stack Overflow上の評価をチェックする、など。
- ベテラン・エンジニアやマネージャー候補にコーディングテストを課す場合は慎重に。上記1~5に注意し、実務に関連性が高い課題を、できるだけ実際の仕事環境に近い環境で解いてもらうべきです。テストを実施する意図も丁寧に説明しましょう。
いかがでしたか。コーディングテストを使った採用がうまく行っていないと感じていらっしゃる方は、採用するポジションで何が求められているのかを整理し、コーディングテストの活用・実施方法を見直してみてはいかがでしょうか?