あなたは技術者採用の面接が苦手ですね。そう、あなたですよ。間違ったスキルを探し求め、適正の無い人たちを採用して、自分自身と会社に悪い影響を与えているのです。応募者リストを見直さなくとも、今までとは違う人材を採用し、会社の業績を上げ、あなた自身も仕事をもっと楽しめるようになりますよ。

いささか大胆な物言いだということは承知しています。仕事での経験を積み面接を担当するようになってから10年、大小の企業の様々な部署で、技術者を雇うための数多くの面接をしてきました。採用する人材が会社に及ぼす影響についても見てきました。完璧な採用を目指せというつもりはありません。私自身がこれまで何度もしてきたあらゆる失敗をあなたが犯さなくても済むよう、お伝えしたいのです。私がこれまで学んできたことは次のようなことです。

誤った判断基準

1. 応募者の現時点の知識に基づいて採用しない

面接で犯しがちな最初の間違いは、現在のスキルを過大評価し、将来の成長を過小評価してしまうことです。応募者が今持っている知識を基準に採用をするのはやめましょう。必要な仕事を言われた通りこなす人を探すのは、その仕事をうまくこなせるようになる素地を持つ人を探すよりずっと間口が狭いのです。

しかしもっと悪いのは、応募者のスキルを判断する方法です。よく面接では、プログラム言語の曖昧なシンタックスの特性や、よく知られたAPIの詳細を質問したりします。有名な fizzbuzz問題 では「モジュロ演算子を知っているか？」というような質問がなされるだけです。「いいえ」と答えた場合、採用される見込みが低くなりますが、実際のところ、この質問によって得られるのは大した情報ではありません。それなのに面接中の20分をこのテストに費やしたりするのは、限られた時間を無駄にする行為です。

2.記憶の良しあしで採用しない

以前は私もよく面接中、応募者にコードを書かせたものです。これは最悪です。ホワイトボードにコードを書くというのは、実際のプログラミングの作業からはあまりにもかけ離れています。預言者ではないのですから。例えばペアを組んでコンピュータに向かってコードを打ち込んだとしても、これは的外れな能力をテストしていることになります。人に注視され、時間との戦いの中でコードを書かなければなりません。私の知る相当優秀なエンジニアですら、この状況下では能力を発揮できないでしょう。仮に、厳しい時間的制約を受けながらコードを書くことが仕事の要件だと信じているのなら、それが組織の問題ではないか検討してみるべきだと思います。

ホワイトボードにコードを書かせるような面接では、決まって共通のソリューションや下層データ構造を再実装するように指示したりしますが、こういうことは高い技術力の対極にあります。優れたエンジニアは、今まで目にしたことがない問題でなければ、生産性を最大化するためにライブラリを利用しようとするものです。これはテストとしても不毛で、本人が問題解決しているのか、他の人の解決方法を記憶しているだけなのか、どうやって判断するのでしょうか。検索すれば15秒で分かるようなアルゴリズムの詳細を暗記する価値はありません。

3.高学歴を採用の条件にしない

学歴を高評価する人もいます。私の経験からいえば、いい大学に行ったとか、とにかく大卒だとかということはエンジニアの資質を見極める条件にはなりません。関連分野で博士号を取得していれば興味には値しますが、これもあまり当てになりません。エンジニアはコードを書いてソフトウェアを納品しますが、学者は理論を証明し、概念実証を記述します。両方できる賢い人もいるでしょうが、当然のことではありませんし、強い相関性もありません。

4.職歴を採用の条件にしない

履歴書上の有名な会社名を過大評価する人もいます。注目を浴びている会社、有名な会社、特に大企業が職歴にあるという理由で採用を決めるのはやめましょう。大企業では部署による違いは計り知れません。企業が成功しているからといって、応募者がその成功に貢献したということにはなりません。あなたが他の企業の採用プロセスについてたまたま熟知していて、適切な採用をしていると請け合える場合なら、応募者リストのトップに持ってくるくらいはしてもいいかもしれません。でもそこから先は、面接の状況で判断しましょう。

5.友人や家族を採用しない

最後になりますが、家族を雇用するのは絶対やめましょう。可能なら友人も避けてください。既存の関係がある人とは先入観、暗黙のパワーバランスや、義理、人情などが絡んできて、会社のためになることと矛盾したりします。会社か友情かどちらかを選ぶという事態に直面しないよう、最初から衝突の可能性は避けたほうが賢明です。

判断基準にすべきこと

まず、次の2つを自問してみることから面接の第一段階を始めてみてください。

1. この仕事ができそうか。 「今すぐできるか」というのではなく、応募者が仕事のやり方を習得できるだろうかという点に確信を持たなくてはなりません。
2. 成長しそうか。 もちろん答えはイエスであるべきです。

1. 関連した経験は望ましいが、必須ではない。

シンタックスやAPIの質問をするのは関連する経験があるかを判断する目的でしょうが、あまりいいやり方とは言えません。そうではなく、採用後に関わることになる技術分野について話してみてください。応募者がどのくらいその分野について知っているのか聞き出しましょう。応募者の資格や経歴だけに基づいて採用を決定したり、通過させたりしようとしてはいけません。そのポジションに必要な技術力が高くないのなら、他に知っているトピックを探して話させ、必要なら説明させてみてください。複雑なトピックの理解度と、それを明確に伝える能力について判断するのです。この2つが実地のエンジニアの仕事になるからです。

2.常に向上する人であること

知識そのものより、どのように、どのくらい短い期間でそれを習得したかのほうがもっと大切です。新しいスキルを習得し、それをうまく生かしてきた実績がある人を探しましょう。彼らのキャリアパスや、どうステップアップしてきたかについての足跡を探りましょう（これは経験年数と関連しますが、同じではありません）。雇用した人が毎年昇給することを考慮すると、その間スキルを向上させる努力を怠り成長が見られない人は、どんどんコストに見合わなくなっていきます。

3. Smart and Gets Things Done™（頭が良くて遂行能力もある）

Joel Spolskyの有名な記事、 面接のゲリラガイド 、（そしてそれに続いて出版された書籍、 『Smart and Gets Things Done』 は、技術者の採用に関して良くまとまっている文章です。頭のよさというのは判断が難しいものですが、私がここで記述するテクニックは役立つと思います。また、「遂行能力」、つまり実際にソフトウェアを納品したことがあるのかという点は同様に大切です。

Joelと私の見解は全く同じではありません。私はライブコーディングがさほど価値があるものとは思えません。Joelはポインタ演算の理解に重きを置いているようです（少なくとも記事を書いた時点では）。これは「複雑なトピックを理解する能力」を測るなかなか面白い問題かもしれません。しかし優秀なエンジニアでもこの分野は門外漢ということも多いでしょうから、話してみるのは有用だとしても最終審査とするべきではないと思います。

4. テクノロジーについて知的に議論できる

前述したように、エンジニアの2つの仕事は複雑な概念を理解することと、それを明確に伝えることです。どちらか一方しかできない人は、たとえ他の分野で輝かしいキャリアがあったとしても、エンジニアとしては二流ということになります。世界一のプログラマなら、記録的な速さで信じられないほど効率的なアルゴリズムを開発できるでしょうが、エンジニアの仕事はチームの一員としてより大きなものを作り上げることです。もしあなたが同僚とのコミュニケーションに時間を費やしたくないとか、できないとかいうのであれば、あなたは自分の仕事の半分しかできていないことになります。

5. 自分の知らないことを知っている人

面接をする時はいつも、応募者よりも自分のほうが熟知している専門分野は何か探します。これは、私のほうが賢いと誇示するためではなく（続きを読んでくださいね）、彼らが自分の技術的な知識の範囲外に投げ出された時、どのように反応するかを見るのが重要だからです。

最もダメそうな応募者は、あいまいなことを言ったり、当てずっぽうなことを言ったりします。これはかなり悪い兆候です。そもそもごまかしが明らかな上に、本人は隠し通せていると思っているのですから。 ダニング＝クルーガー効果 の用語によればこういう人は下位4分の1にいて、自分の知識の欠如を正しく判断することが出来ない人ということになります。他の状況でも同じことをしようとするでしょう。

一方、有能な人は、限界を感じた時すぐに「分かりません」と言い、質問をすることもあるでしょう。もっと有望な場合は「推測させていただければ…」と切り出すでしょう。これはすばらしい行動です。なぜならこれらの行動には、知的誠実性と、物事を解き明かそうとする熱意が表れているからです。

6.これは対話であって、尋問ではない

先ほど述べたように、面接する相手よりも良く知っている分野を探すのはいいやり方だと思います。しかし、これはあなたのほうが頭が良いとか、優れていると証明するためではありません。応募者の専門知識の度合いを測るためであり、知識の広さと深さを知るためです。知識の限界が見えることもあるでしょうが、そこがポイントなのです。そうなったからといって、彼らがしくじったということにはなりません。

その点について伝えておくことも重要で、面接を受ける人がリラックスして、快適でいられる環境にしましょう。なぜなら実際に仕事を始めた時はそういう環境に置かれるはずだからです（もし違うなら、あなたの会社は最悪なので、辞めましょう）。ストレスがかかり、パニック状態で得られる回答は基本的に使えません。例えそれが良い答えだったとしても、その人の本質を表す回答ではないので、役に立たないことには変わりません。ストレスやパニック状態というのは持続できる状態ではないので、プレッシャーをかけられた時にしか成果をあげられない人を雇ってしまうリスクを冒すことになります。

例外は常に存在する

関連する経験を有していない応募者の場合、残された唯一の面接手段は、昔ながらの技術的な質問をするということでしょう。これは、経験の浅い応募者にも、他業種で経験を積んでから転職を希望している応募者にも適用可能です。

研修コースを修了したばかりの人は、その研修がどれだけ集中的で、どれだけ定評があったとしても、エンジニアになる方法を心得てはいません。もちろんプログラミングのやり方は知っているでしょうが、それは実際の仕事のうちの半分でしかないのです。大学を出たばかりの人だと、講義で学ぶパズルの解決策のような知識だけで、プログラミングがきちんとできるかどうかさえ怪しいといったところでしょうか。私の経験では、プロとしてのプログラミング経験が1年未満の人は、どれだけプログラミングが得意であっても、実務経験としては未熟と言えると思います。

新卒や経験の浅い応募者は、プロとしての周囲との関わり方についても知識を持ち合わせてはいません。このことが、面接を難しいものにするだけでなく、一方で大きな責任を生むことにもなります。採用を決めた場合、応募者にとっては、あなたの会社の企業風土や業務慣習が、その後の彼らの人生にとって永遠に指標となり続けるからです。

一方、もしあなたが、エンジニアがその専門性を徹底して追求できるような大企業に勤めているということであれば、その場合も私のルールは適用外となります。そういった場合、実際に会社が求めるのは天才プログラマであり、自分のやっていることをうまく説明できようができまいが、そんな能力などは二の次です。大企業であれば、その天才プログラマ専用に、フルタイムの担当マネージャーを雇えばいいわけですし、連絡事項は、その人を通じて行えば問題ありませんからね。このやり方であれば、コストはかさむものの、大きな実りが期待できます。スタートアップには予算的に厳しいため、現実的な選択肢とはならないでしょうが、エンジニアが50人を超えるような環境だと、一考に値するかもしれません。

自問する：この人物と一緒に働きたいか？

応募者が適任だと判断した後には、もう1つの問題が待ち受けています。それは、実際にその人物と一緒に働きたいかどうかということです。その答えを得るための決まった質問などはありません。あえて言えば、質問に対する答え方に注目するということでしょうか。この場合、その質問は人格テストのような様相を帯びてしまうことになり、ある意味、危険な領域に足を踏み入れることになります。なぜなら、人格判断というのは主観的なものであるため、審査の基準に偏見（個人的な偏見、 潜在的な偏見 、無意識的な偏見）を持ち込む可能性が生じるからです。

無自覚的な偏見のせいで優れた応募者を拒否するといった忌まわしい結果は、できれば避けたいものです。だからこそ、多くの人が純粋で正誤の基準のはっきりした技術的な質問を選択します。しかし、技術的な質問はプロセスを容易にはするものの、偏見から全く無縁かというと、そういうわけでもないですし、偏見を回避する機能のようなものが備わっているわけでもありません。例えば、シンタックスに関する50の質問をしたとしましょう。潜在的に気に入っていたり、優秀だと思い込んでいたりする応募者に対して、ヒントや合図を送るのは簡単なことです。私自身、そのような経験はあります。つまり、偏見というのは、それほど厄介なものなのです。このことを常に意識し、都度確認しつつ、必要に応じて自分に修正を加えない限り、二流の人材を雇った結果、会社に大損害を与えてしまうことだってあり得るかもしれません。

1. 一緒に働く人材を探す

「この人物と一緒に働きたいか？」ということと「この人物と友人になりたいか？」ということを混同しているスタートアップの事例を目にしたことがあります。

このような思い込みは捨ててください。この2つは全くの別物です。個人的なレベルにおいて共通事項が何も見当たらないような相手とでも、プロとして生産的ですばらしい関係を築くことは可能です。会社が「家族のようなもの」である必要はありません。会社は友情を育むための施設ではないですからね。飲み友達を選んでいるわけではないのです（ちなみに、飲むことが重要視されるような会社の場合、大きな問題を抱えることになるかもしれませんが）。

2. ろくでなしお断り

npm での1日目、私たちは「ろくでなしお断り」政策を実行に移しました。そして、最近読んだものの中で、Polyvore（多様なエンジニアリングチームをうまく維持できているように見えます）が、 同じ類の政策 を実施していることを知り、何だかうれしくなりました。この政策は、「無神経な天才」は必要ないし、相手を小ばかにしたり皮肉屋だったり、いじめたり鼻持ちならなかったりする人も同じく不要、意地悪く不快で、同僚の面目をつぶすような人とは一緒に働かない、というものです。どれだけ、才能や生産的能力が優れていたとしても、チーム内の士気をおとしめるようでは、全く意味がありません。いったん壊れたチームの和を修復するのは、非常に困難です。その犠牲の大きさを考えると、例えそれが何らかの危機的状況をしのぐためであっても、このような人材を雇うことに価値があるとは思えません。もし、雇ってしまったのなら、躊躇せず迅速に解雇することをお勧めします。

「採用はするが、他のチームに行ってもらう」といったフレーズが自分の口から出てきた場合、その応募者がろくでなしの可能性は大いにあります。なぜなら、その応募者のスキルは認めているものの、あなた自身は直接的に一緒に働きたいとは思っていないということですからね。あなたがそう思わないということであれば、他の人だってそうでしょう。そんなくだらない人を他のチームに押しつけるべきではありません。

ただし、一般的に、ろくでなしは簡単に見分けることが可能です。性格の根幹に大きな欠点があれば、数時間の面接のうちにボロが出てしまうものです。そうした欠点は、職場の環境に悪影響を与えるものになりかねません。傲慢さやだらしなさ、細かいことに対する注意力の欠如などは、すぐに目に付きます。それらに気付いた場合、採用は見送ったほうが賢明でしょう。

3. 「チームにフィットしそう」を採用の基準にしない

「チームにフィットしそう」というフレーズを考える時、私は必ず「 偏見を自由にする 」という結論に行き着きます。「彼はこの職場に合いそうだね」も同じですし、陰湿なものになると、「私とはつるめそうもない」というものまであります。そういったフレーズを言う人たちはもっと大人になるべきであり、会社と友達を作る場所を分けて考えるべきです。同僚と仕事以外でどう付き合うかを調べているわけではありませんし、一緒に働きたいから社交的な付き合いをしなければならないといった要件もありません。

私自身、内向的でお酒を口にしない人物として、雇用プロセスに社交的な活動を組み入れるのは、ぜひともやめてほしいとお願いしたいくらいです。職場での付き合いと社会的な場での付き合いはおのずと異なります。ちょっとした会話が苦手な人もいるし、バーで快適に過ごせない人だっています。前述した、リラックスできて居心地がいい環境を、というパートを覚えていますか？　そこで話しているのは、あなたの快適さではなく、彼らの快適さなのです。

では、「チームにフィットしそうを採用の基準にしない」というルールに対して、「ろくでなしお断り」政策と「一緒に働きたい」という要件を、どのように調和させればいいのでしょうか。それは、チームにとっていい人材は、必ずしも友達になりたい人とイコールではないということを肝に銘じておくということです。違いはわずかですが重要ですよね。どうしても、その両方を追い求めてしまいがちですが、会社の成功にとっては誤った基準であり、最終的に維持できなくなるでしょう。

4. 均一さは悲惨

私は社会的な観点から、「多様性は本質的に優れている」といった議論をするつもりはありません。それはあまりに短絡的すぎます。それでも多様性の欠落は、数学的に見ても、会社にとっていいことではないでしょう。「仕事に適任」という基準ではなく「自分と同類」という基準が思わず優先されることもありますが、世にいる最高のプログラマたちがみんな一様ということはあり得ません。つまり、会社にとって多様性のなさは、「このチームは雇用が下手」「上層部や人事は、この状況を正す能力を持ち合わせていない」「このチームにはベストな人材がそろっていない」など、ネガティブなことしか意味しないというわけです。

見つけられない時はどうすればいいか？

これについての私の意見は、あまり参考にならないかもしれません。才能のある人材という面では、npmは非常に恵まれているからです。みんなnodeやnpmを愛しており、求人を出した際には、有能な応募者からの応募が多数届きます。私が以前に関係したスタートアップであるawe.smは、それほど有名ではありませんでしたが、それでも私たちは何とかいい人材を確保していました。大切なのは、時間をかけて、あらゆるネットワークを駆使するということです。Hacker Newsの採用情報からの応募もありましたし、ブログからの応募、それにある時はTechCrunchの記事を経由した応募を受け取ったこともありました。

覚えておいていただきたいのは、無能な人材を雇うということは、有能な人材を待つことよりもコストがかかり、時間も浪費するということです。「現時点では誰でもいい」と妥協して言うのは簡単ですが、その言葉が真実となることはありません。誤った人材の補充がミスを生み、ひいては周りの仕事をも遅らせ、場の空気を悪くしてしまいます。確信が得られない場合、採用は控えたほうが得策です。ただし、仮にそのような人材を雇ってしまった場合は、できる限りのサポートと指示を与え、状況が好転するよう試みてください。その結果、何の向上も見られない時は、冷たいですが解雇を言い渡すしかないでしょう。

全ては簡単なことではない

あなたが担当したこれまでの面接がうまくいかなかった理由、それは、実のない面接をするほうが簡単だ、ということに尽きると思います。つまりあなたの側にとっては、創造力も努力も、そして考えることもさほど要求されずに済むわけですからね。これらの技術は定義が難しいですし、実行も容易ではないでしょう。しかし、つまるところ、それが雇用というものなのです。道のりは困難で予想よりも時間がかかり、決まったルールはなく酸性試験のように明確な答えが得られるわけでもありません。その中で尽力して、会社の強化、いい人材の確保、優れた製品、そしてチーム全員が楽しく働ける環境の実現につなげる。それこそが、雇用担当としてのあなたの仕事だと思います。

まとめ

1. 多くの面接では、実際の仕事とは関係ないスキルをテストしがちである
2. 即戦力となる人材が欲しい
3. または、仕事を早く覚えてくれそうな有能な人材が欲しい
4. 仕事の持ち場で継続的に向上する人材が欲しい
5. 面接は、協力的な対話を基本とし、戦闘的で威圧的なものにはしない
6. 一緒に楽しく働ける人材が欲しい
7. 「楽しく働く」と「楽しく付き合う」を混同しない
8. どんなに能力があろうと、ろくでなしは採用しない
9. 多様性のないチームは、理想的な姿からほど遠い
10. 雇用は時間がかかり、困難な道のりであるということを肝に銘じる

以上