Quipper ではエンジニアを採用するにあたり、候補者に複数回の面接と、コードテストのための課題提出をお願いしている。
今年の春から夏にかけて、前任者から日本オフィスのエンジニア採用に関わる仕事を引き継いだとき、採用プロセスを変更した。それまでは一部の採用担当者だけが面談と合否判断をしていたが、エンジニア採用の場合は原則としてエンジニア全員が面談に参加可能とし、課題のレビューも全員が行うようにした（カレンダーに面談の予定を作るとき全員招待する。辞退しても構わない）そして合否判断の議論も原則としてエンジニア全員で行うようにした。
これによってブラックボックスだった採用プロセスを透明化できたが、課題のフィードバックを共有するとき、先に発言した人の意見に影響されてしまってフェアな判断が下せなくなる懸念があった。そこで、以下のようなやり方でフィードバックを共有することにした。
- フィードバック記入用のテンプレートとなる Google ドキュメントを用意する。記入すべき項目は、
- 合否の判断（yes or no; 必須）
- 良いポイント（任意; 複数可）
- 悪いポイント（任意; 複数可）
- 総評コメント（任意）
- 課題のコードレビューをしたエンジニアはテンプレートの Google ドキュメントをコピーして自分専用のフィードバックシートに記入する
- 記入が終わったら採用プロセスのコーディネーターに Google ドキュメントを共有する
- コーディネーターは全員分のフィードバックが集まったら（または提出期限がきたら）内容をとりまとめる
- 合否判断が明らかな場合は結果に従い採用プロセスが進んだり終わったりする。明らかでない場合はエンジニア間で議論し、それでも決まらなければ CTO に判断を委ねる
こうすることで、他人の意見に影響を与えてしまう・影響を受けてしまう懸念をなくすことができた。また、合否判断を yes or no の二択としたことで曖昧さがなくなり、ジョエル・スポルスキーの本に書いてある「いいと思うけど僕のチームに入れるのはちょっと」みたいなアンチパターンを避けることができる。日本オフィスのエンジニア採用だけでなくグローバルでエンジニア採用する際も同様のやり方をはじめたので、各人が合否の意思表示をはっきりさせるのがより大事になってくると思う。
このやり方は、採用という非常にセンシティブな情報を扱うプロセスに関与する人数が増えてしまうし、一票の重みに差がないので、合否判断を下すエンジニア間の実力差が大きい場合は適用するのが難しいかもしれない。 Quipper 日本オフィスの場合は、在籍しているエンジニアが全員十分なキャリアと見識を兼ね備えており、センシティブな情報を共有しても差し支えなく、また実力差による一票の不平等も発生しないと判断した。組織がかわるにつれて、このやり方もかわっていくことになるだろう。
採用プロセスのコーディネーターはあくまで事務手続きや諸連絡などの雑用を行う調整役に過ぎず、マネージャーのようなものではない点は強調しておきたい（少なくとも自分は単なる調整役であるという意識でその仕事をこなしている）フラットなエンジニアリングチームは「どのコードをマージするか」だけでなく「どの候補者を仲間に迎えるか」の議論においても対等な関係であるべきで、そこに肩書きはいらない。
