Agile HR

■イベントレポート概要

エンジニアの採用選考で、職歴書や面接内での口頭質問ではわからない技術力を見極める手法として導入される「コードチェック」。
今回は、その実践例を聞ける機会として、落合陽一氏が率いるピクシーダストテクノロジーズのエンジニア4名をお招きし、現行の開発ポジション別のコードレビュー観点、面接で候補者にどのようにレビューしているかなどを紐解いていきます。

■会社紹介

西田：本日は、ピクシーダストテクノロジーズ株式会社の事業本部 Development ファンクションより、4名のエンジニアの方にお越しいただいております。技術部門責任者の安間様、フロントエンドエンジニアの上坂様、バックエンドエンジニアの平岡様、View of Voice開発責任者の西村様でございます。本日はよろしくお願いいたします。


まずは簡単に、ピクシーダストテクノロジーズ様の事業紹介をしていただければと思います。

安間様：ピクシーダストテクノロジーズでは、デジタルとアナログの世界の境界で、新しい技術や製品を連続的に作り続ける孵卵器となる会社を目指しています。アナログの部分とデジタルにできる部分との1番良い均衡点を探すことを技術の肝としています。

具体的には、音や光を扱う波動制御技術をコアにして、 ワークスペース、ダイバーシティ、ヘルスケア 領域に対して様々な研究や事業化を行っています。

弊社のミッション『「社会的意義」や「意味」があるものを連続的に生み出す孵卵器となる』に共感し、社会的価値が高いものをどんどん作り出していきたいエンジニアの方に、ぜひ目指していただきたいです。社会価値の追求、価値ある挑戦、敬意と衝突、全員殿の4つのPxDT Valueに沿って考え、行動できる方を募集しています。

弊社はハードウェア込みのクラウドソリューションを行っています。VUEVOというクラウドに繋がるハードウェア（マイク）とそれを制御するスマートフォンとマイクで収集した音声を表示するwebアプリケーションをセットにしたサービスです。

弊社では、ソフトウェアエンジニアとして、職種を定義しております。アルゴリズムエンジニア、組み込みエンジニア、webを担当するインフラエンジニア、バックエンドエンジニア、 フロントエンドエンジニア、そして、スマートフォンのアプリケーションを作るスマホアプリエンジニアと、さまざまな専門領域ごとで担当分けし、チームで仕事をしています。
そのため様々な職種を募集しており、その採用にはコーディングテストを活用しております。

西田：今、ご紹介いただきました通りピクシーダストテクノロジーズ様では、様々なエンジニアの職種において、コードチェックツールを導入されています。本日は、その位置付けや実施方法、導入プロセスなど、具体的にどのように活用されているのかを深掘りしていきます。

■コードから候補者の思考やパーソナリティーを読み解く

西田：早速ですが、まずはコードチェックツールの導入の理由とメリットをお話しいただけますでしょうか。

安間氏：コーディングテストを利用する理由としては、仕事を遂行する上で弊社が重要視している点を満たしているかどうかを見られるからです。
Track Testを使うとコーティングテストの結果そのものは点数で出てきます。ただ、点数が高ければいいというわけではなく、コードの中身をしっかり見ています。 コーディングの中で、どこの部分をどのように正解して、どのように間違えたかが重要です。よって、 コーディングテストはやってもらうだけではなく、テストをきっかけに、エンジニアの面接中に質問して、そこを深掘りする材料としても利用しています。

エンジニアの方々は話すのが得意ではない方も少なくないのですが、コードをよりどころにして会話をしていくと、どんどん話が進み、膨らみます。そのため、面接でも助かっています。
また、コードを読み解いていくと、何を大切にして開発しているのかが可視化され、それについて面接の中でも聞けることが大きなメリットといえるでしょう。

一方で、コードチェックはするものの、やはり、ミッションやバリューに共感する人を最優先で我々は採用しています。やり切れるだけの気力や気合もすごく大切で、デジタルなツールを活用した評価もありますが、アナログな点もかなり重視しています。

西田：候補者の中には面接が得意でない方もいらっしゃることもあり、コーディングテストを実施し、その受験者様が書かれたコードを元とした会話で、その方のご思考や、パーソナリティーも把握されていく、ということですね。

安間氏：そうですね、導入以前はホワイトボードコーディングをしていました。ディスカッションするのに1時間半〜2時間かかっていました。考えるのを待つ時間などもあったので導入後の時間的コストの削減は大きいです。
また、当初のホワイトボードコーディングは、その場で問題を解答いただくものでしたので、どうしても簡単なものにならざるを得なかったのです。今は適切な難易度でテストが実施でき、我々も準備してから面接に臨めるというメリットもあります。

また、テストを実施し続けることで弊社を受けに来る方はどのような方が多くて、どこらへんがどうできる方々なのかが社内の知見としてTrack Testに蓄積されます。
最終的にはデータを元に書類選考の精度上昇に繋げられたら更にいいのかなと思っています。

西田：コスト削減と過去の受験者データの集約で採用が洗練されていくのは大きなメリットですね。

■コーディングテスト実施のタイミングとは

西田：選考フローにてどのようなタイミングでコーディングテストを取り入れられているのか、お伺いしたいです。

安間様：コーディングテストを1次面接前に実施しています。なので、カジュアル面談、コーディングテスト、 1次面接、2次面接、最終面接と進めています。
また、コーディングテストの内容をベースとした質問を1次面接、2次面接でするようにしています。 このコーディングテストは専門分野ごとに実施していますので、弊社のバックエンドに相当する方が応募された場合であれば、バックエンドの担当エンジニアを含む複数人でコードチェックを実施します。

■コードの中身を掘り下げる技術面接。重要なのは「間違えたところ」

西田：面接で深掘りしていくポイントに関しまして、コードのどのような部分をご覧になって質問や判断をされているのか具体的に教えていただけますでしょうか。

上坂様：弊社に応募いただける方々は、過去の経歴として、いわゆるSIerで働かれていた方、もう少し研究開発よりでコード書かれていた方などさまざまで、得意な分野はそれぞれ違います。それが結構コードから見てわかるのですよ。
なので、私達は、なんとなくこんな人かな、こんなタイプかな、みたいな想像をしながら面接に挑めます。面接をする以前に、その人の経歴や得意不得意、人となりがコードから掴めるので、そういった点を見ています。

平岡様：バックエンドの観点では、 やっぱりバックエンドってビジネスロジックの中心にあるので、保守性が高いか、後で回収する人のことを気にする意識があるか、チームで働く意識があるかどうかは見ますね。

西村様：僕はアルゴリズム開発をしているのですが、弊社では研究開発から量産するまでをチームで進めています。そのため、変わっていく担当者、他のメンバーにきちんと理解してもらえる可読性は大事だなと思って、そこを重点的に見ています。
ソフトウェア開発はチームで行うので、チーム開発を意識した開発ができるのかという観点で見ています。例えば、コードの変数名の命名規則に一貫性があるかなど、可読性は確認します。
また、コーディングテストで回答に困難な箇所にぶち当たった時に、どう解決していくのかという点でもチェックしていきます。そして、次の選考面接では、関連したディスカッションもしていきます。

安間様：付け加えると、本当に満点が良い訳では無いです。間違えていた場所がかなり重要だと思っていて、現状でこれがうまくいっていない、何故これができてないのかがわかっている方は、やっぱり良いです。
点数を取れなかった方も、例えば別のアルゴリズムの強い課題を聞けば解いてくれるかもしれないので。そういった意味で、協力して課題を解決していけそうな方をすごく評価しています。そういう面を面接で聞かせていただいています。

西田：よくわかりました。ありがとうございます。

■評価者全員の「GO」で合格

西田：それぞれの職種ごとに複数の評価者がつき、複眼で候補者様のコードを見たり、面接したりして評価されていくとのことですが、 複眼評価のポイントや、合否基準の平準化、目線合わせは、どのようにされているのでしょうか。

安間様：基礎的な項目に関しては、これまで候補者の方に受けていただいた結果データがありますので、このぐらいの点数は取れるだろうというレベルが概ねわかった上で進めています。
基準合わせは、複数人の中でコードがどうだったかを会話して、その職種ごとに合わせていく形です。

上坂様：フロントエンドでは、例を示し、似た形で実装してほしいことを問題文に組み込んでいます。それに似ているかである程度目線は揃います。
コードの質は、人によって多少評価が分かれますが、そこまで大きく分かれるようなことはないというのが正直なところです。

西田：なるほどですね、ありがとうございます。
ちなみに合否のご意見が分かれた場合、最終結果はどういう方法で決定をされていますか。

安間様：基本的な考え方としては、全員GOで合格です。ひとつでも懸念事項があった場合には、基本的にお見送りです。
各職種の判定している方々は一人ひとりがその職種のプロなので、その意見を尊重しています。 多数決とかはないですね。

■コーディングテストの点数を見るだけでは、ミスマッチは起こり得る

西田：全員GOを出した上での合格っていうことであれば、失敗事例は起こりづらそうですね。

上坂様：実際のところなくはないですよね。
コーディングテストを足切り的に使うと問題のレベルは少し下がってしまうので、それ以上どのぐらいまでできるのかは測れません。問題の難易度を上げると離脱率が高くなってしまうのでバランスが難しいところです。

コーディングテストを取り入れただけではどうしてもミスマッチは起こり得ます。だからこそ、テストだけじゃなくて、face to faceで話して、テスト内容のディスカッションを通していいな、一緒に働きたいなと思った方を採用させていただいています。

テストと同じことをチームでもできるかどうかを重視して見ています。これは候補者の方にも伝えていて、我々のチーム、会社に入っていただけますか？というのが採用全体での問いですね。

西田：ありがとうございます。なるほど。テストツールのスコアはその方の一面であって、直接会話したりコミュニケーション取ったりする中で、その方の人柄やマインド、カルチャーのマッチ感を総合的に見ての評価が重要になってくるということですね。

■状況やフェーズに合わせたコードテストのブラッシュアップが成功を呼び込む

西田：コーディングテストをそもそも導入しようとしたきっかけや、実際導入を始めた後に、継続的に利用する中でのブラッシュアップについてぜひお聞かせいただきたいです。

安間様：ベンチャー企業ということもあって、フェーズが進むにつれてエンジニアの数は増えてきました。

導入前は、技術のことをたくさん聞かなくてはいけないので困っていました。エンジニアが5人から10人までの間は、 面接時にホワイトボードでクイズをその場で書いていただき、その場で聞いていましたね。当時はコロナウイルスもなかったので、対面の面接が多く、その場でディスカッションし、答えられるかで技術面を見ていました。

そうしていくうちに、何かコーディング試験をやった方がいいのでは？という話が社内で挙がって、Track testを導入したのが、2019年の8月頃からです。
エンジニアが10人から30人の頃は、共通テストとして、アルゴリズムに関するテストやクイズを実施していました。

2020年の8月くらいから、様々な職種の方々が受けに来てくれるようになり、これ1つだとなかなか難しい段階に入ってきました。共通テストを少しずつなくして、フロントエンドやバックエンドなどの職種ごとのテストに順次細分化させていきましたね。

このような形で、コーディングテストの使い方は、会社の成長とともにアップデートしているのが現状です。なので、今が最適かというと、そんなことはないです。エンジニアの数が増えればまた変わっていくと思います。今後も良くないところは直し、さらに効率化できるところは効率化していきます。

西田：なるほど。会社のフェーズに合わせて採用プロセスやテストツールの扱い方をブラッシュアップしていくことが採用をうまくいくコツなのかなと、感じました。ありがとうございます。

本日のセミナーは以上とさせていただきます。
お話をお伺いさせていただきました、ピクシーダストテクノロジーズの4名のエンジニアの皆様、本日はありがとうございました。

ピクシーダストテクノロジーズの皆様：ありがとうございました。