CTOのishkawaです。

10Xでは全職種の選考プロセスにトライアルを設定していましたが、ソフトウェアエンジニアに関してはトライアルによる選考を終了し、新たな選考プロセスを導入することにしました。本稿では、創業以来続けてきたトライアルをやめて、選考プロセスをアップデートしていくことに決めた背景を紹介します。

トライアルとは

トライアルとは実際に10Xの仕事に取り組んでもらいます。大まかな流れは次の通りです。

会社の情報をインプットし、取り組むイシューの候補を考える。
社員へのヒアリングやディスカッションを通じて、取り組むイシューを決める。
イシューの解決に向けたアクションプランを策定し、可能な範囲で進める。
成果を発表する。

トライアルは1日や数週間といった短期間で実施します。

良かった点

会社と候補者の双方から様々な面のフィットが確認できるのが、トライアルの良いところでした。例えば、候補者の方が会社に入った時に成果を出していけるか、仕事をする上で大事にする価値観は合っているか、事業や開発の機会が候補者のキャリアの方向性と合っているか、といった観点の確認ができます。

また、トライアルは候補者の方に会社のことを知っていただく機会としても機能していました。トライアルに取り組む中で事業の理解が進んだり、解くべきイシューが見えてきたりして、入社後に自分がどのように活躍できるのかイメージしていただけるようでした。

課題となった点

素晴らしく良い点もあったトライアルですが、課題もありました。

まず、最大の課題となったのは候補者の方に大きな負担がかかる点です。多くの候補者の方には本業や他社の選考があり、10Xのトライアルにまとまった時間を割くのは簡単なことではありません。この負担により、選考を辞退されることもありました。10Xに強い関心を持って転職活動のエネルギーを10Xに集中させてくれるという嬉しいケースもありましたが、候補者層が選考時にそのような判断ができる人に限定されてしまうとのは、やはり大きな課題でした。

他の課題の1つには、トライアルの評価の再現性の確保が難しい点がありました。トライアルのお題は「今の会社やプロダクトやシステムの状況をインプットし、最も大きく成果を出せるイシューを発見して解決に向けた動きをしてほしい」という抽象度の高いものでした。課題がオープンな分、候補者の方が力を強く発揮できるケースもあれば、限られた時間の中で上手く課題を見つけられないケースもありました。また、事業の進捗に伴って、そもそもどんなレバーが存在するのか、どのレバーを引くとどのような影響があるのか、理解が難しくなってきていた側面もありました。

その他、トライアルで成果を出すには問題発見と解決のスキルが重視され、技術的なスキルを見づらいなどの課題もありました。これは単にすべてをトライアルでやろうとするから課題になるのであり、他に技術的スキルを確認しやすいプロセスがあれば良さそうでした。

アップデートの方針

これまでに挙げてきた課題の解決のため、選考プロセスをアップデートすることに決めました。アップデートの大方針は「トライアルのエッセンスを残しながら課題を解決する」でした。検討の結果、導入されたのはコーディング試験とディスカッション面接です。選考プロセスの内容はポジションによって若干異なるのですが、詳細は下記URLにまとまっています。

10X ソフトウェアエンジニア選考ガイド

コーディング試験に関しては、当初は個人的にはそこまで必要かな？という印象だったのですが、純粋にコーディングスキルを再現性高く確認できることで、候補者の方も評価者もコーディングに関しては自信を持って次のプロセスに進めるというメリットがありました。

ディスカッション面接はややトライアルの側面を引き継いでいるものなのですが、時間は1時間に限定されおり、取り組む課題も実務のサブセットのような粒度に抑えられています。こちらは問題発見やコラボレーションの力が再現性高く確認できるものとなっています。