非エンジニアがエンジニアを採用する方法

「自分には手に負えない」と気づく瞬間

求人を出し、履歴書が届く。しかしどれも聞いたこともないフレームワークの名前ばかり並んでいる。誰かが「スケーラブルなマイクロサービスアーキテクチャによるフルスタック開発で5年の経験」と主張しているが、それが本当にすごいことなのか、それとも面接の1時間前にチュートリアルサイトで読んだ内容の受け売りなのか、判断のしようがない。面接では相槌を打つしかなく、突っ込んで確認する手立てがない。

これはよくあることだ。10〜200人規模の会社を経営する人の多くはエンジニアではないが、それでもエンジニアを採用する必要がある。朗報なのは、うまく採用するためにコードを学ぶ必要はないということだ。必要なのは、コードそのものを判断しようとするのをやめて、その周辺にある証拠を判断することだ。

技術に詳しいふりをしない ― それは逆効果になる

候補者は、あなたがはったりをかましているかどうかを見抜く。「Kubernetesの経験について教えてください」と聞いておきながら、どんな答えが返ってきても「なるほど、なるほど」としか言わないなら、鋭い候補者には「この面接には実質的な基準がない」と伝わってしまう。話は流暢だが実務ができないタイプはすんなり通過し、あなたが本当にチェックしていると思い込んでいる物静かで有能なタイプは、自分を過小評価して終わる。

それより正直に伝えたほうがいい。「私は技術に詳しくないので、平易な言葉で説明してもらいますし、選考の一部では技術に詳しい人の力を借ります」と。これは弱みではない。自分が実践したことのない分野で人を採用する際、有能な採用担当者が必ずやっていることと同じだ。

「一時間だけ」誰かの技術的な目を借りる ― 全プロセスではなく

うまく採用するために、フルタイムの技術系共同創業者は必要ない。必要なのは、エンジニアの1時間を2回借りることだけだ。1回目は職務内容と選考質問の作成を手伝ってもらうため、2回目は最終面接に同席してもらうか、成果物サンプルを確認してもらうためだ。

誰に頼めるか:

• 2時間分のコンサルティング料を払って依頼するフリーランスのエンジニア
• ソフトウェア開発の経験がある友人やアドバイザー
• 別の用件ですでに契約しているコントラクター

依頼する内容は範囲を絞る。「この候補者のこの質問への回答が、内容として成立しているか見てほしい」というふうに。「この人を審査してほしい」といった曖昧で、好意に頼りすぎる依頼は避けること。

仮定の質問ではなく、自分の実績を説明させる

本当に何かを作った経験のあるエンジニアは、こちらが求める詳しさのレベルに合わせて、平易な言葉でそれを説明できる。履歴書を盛っている人は、たいてい表面的な話以上には踏み込めない。

有効な質問を、明らかになる度合いの高い順に挙げる:

1. 「自分が誇りに思う、作ったものについて教えてください。それは何をするもので、あなたはどの部分を担当しましたか?」
2. 「そのプロジェクトで一番難しかった技術的な問題は何で、それをどうやって解決しましたか?」
3. 「そのチームの他のエンジニアに『あなたと働くのはどうだったか』と聞いたら、何と答えると思いますか? それはなぜですか?」
4. 「自分のコードが原因で本番環境に障害が起きたことについて教えてください。何が起き、どう対応しましたか?」

4番目の質問が最も多くを明らかにする。本物のエンジニアであれば、ほぼ全員が何かを壊した経験を持っている。数年の実務経験を主張しているのに「そんなことは一度もない」と答える人は、嘘をついているか、重要なものを一度もリリースしたことがないかのどちらかだ。

小規模で本物の成果物サンプルを使う

候補者に無償で機能を丸ごと作らせる必要はない。60〜90分程度で終わり、その職務で実際にやる仕事に近い、範囲を絞った短いタスクのほうが、1時間の会話よりも多くを教えてくれる。

公平さを保つために:

• 報酬を支払うか、無償でも妥当だと言えるくらい本当に小さいタスクにする(どちらが適切かは、たいていの候補者が教えてくれる)
• その選考段階の全員に同じタスクを課す
• タスク後に、候補者自身に解決策を説明してもらう ― ここで、言及されていない誰かの助けを借りていた人物を見抜ける

自分にその成果物を評価する技術的な判断力がない場合は、まさにここで先ほどの「借りた1時間」を使うべきタイミングだ。

ゼロからタスクを作りたくない場合は、標準化された技術スクリーニングテストがこの段階の前に一次選考を行ってくれる。AssessFitは幅広い技術スキルに対応したアダプティブテストを提供しており、応募者全員を技術担当のレビュアー一人にいきなり送り込む必要がなくなる。

「知っていると主張していること」ではなく「実際に作ったもの」を確認する

技術名がずらりと並んだ履歴書は、その人が何に触れたことがあるかを教えてくれるだけで、何が得意かは教えてくれない。代わりに証拠を求めよう。

• GitHubのプロフィール、ポートフォリオ、実際に作った公開中のものへのリンク
• 会社名やプロダクト名 ― 自分で実際に見てみるために
• プロジェクトのうち、実際に本人が担当した割合はどれくらいか

ツールの長いリストに感心してはいけない。1つか2つ、深く語れるものがあるかどうかに関心を向けよう。深さこそがシグナルであり、バズワードの幅広さはむしろその逆であることが多い。

リファレンスチェック:スキルではなく、成果の確実性を聞く

リファレンス(照会先)に「彼/彼女のコードは良かったですか?」と聞いても、その照会先自身が技術者でない限り有用な答えは得られない。技術者であったとしても、それは曖昧で寛容な質問であり、めったに突っ込んだ答えは返ってこない。

代わりにこう聞こう:

• 「その人は、自分で見積もったスケジュール通りに、言った通りのことを完了させましたか?」
• 「何か問題が起きたとき、その人は早めに知らせてきましたか、それとも後になって発覚しましたか?」
• 「曖昧な指示のタスクを任せて、自分で考えて対処してくれると信頼できますか、それとも何もかも細かく指示する必要がありますか?」

これらの質問も、照会先がコードを知っている必要はない。必要なのは、その人と一緒に働いた経験があることだけであり、これなら正直な答えを引き出すハードルはずっと低い。

正直に言っておくべき限界

ここで紹介した方法は、最終的に信頼できる技術者を確保することの代わりにはならない。もしこれがあなたにとって最初のエンジニア採用で、社内外に本当にサニティチェックをしてくれる人が誰もいないなら、それはリスクとして声に出して認めておく価値がある ― 自分自身に対して、そして場合によっては、誰か知り合いを紹介してくれるかもしれない初期の投資家やアドバイザーに対して。90日間の試用期間を設け、明確で非技術的な成果指標(実際にリリースされたか、それは機能したか、ユーザーから苦情はなかったか)を定めておくことは、面接で見えていたよりも実力が伴わなかった場合の保険になる。

あなたはエンジニアになろうとしているわけではない。本当に何かを作った人と、そのための言葉だけを覚えた人との違いを見抜けるプロセスを構築しようとしているのだ。