履歴書の順序づけ
From The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳
2006年9月8日 金曜
求人で標準的に使われている添状を付けた履歴書というのは、候補者を知るための方法としては驚くほど貧弱なものだ。履歴書は応募者の資質についてほんのかすかな手がかりしか与えてくれない。
しかし時に履歴書はきわめて強いネガティブな手がかりを与えてくれ、それ以上調べることなくその応募者をふるい落とすことができる。一度私は、Microsoft Window[原文のまま] プログラミングのエキスパートだという人から履歴書を受け取ったことがある。別なときには、職歴に書かれていた仕事がダンキンドーナッツだけということもあった。その履歴書は高校の就職相談室のアドバイザーのよくやるアドバイスに従ってとても上手くやっていたが(彼は「ドーナッツトレーのマネジメント」をしていたそうだ)、その応募者がコンピュータを見たことがあることを示すものは何もなかった。
しかしそういう場合を別にすると、履歴書から候補者について多くのことを読み取るのはとても難しい。Fog Creekにおける私たちのポリシーは3つの部分からなっている:
- 求人広告を選別的に行い、履歴書の山の中のノイズを減らすようにする。
- 履歴書だけに基づいて採用はしない。履歴書はふるい分けして面接しなければならない人の数を減らすのに使うだけだ。
- 面接する順番を決めるために残った履歴書の順序づけをするとき、厳格に客観的なシステムを使って履歴書に点数を付ける。それによって履歴書の発するとても弱い信号をどう解釈するかという点について、公正で一貫的になるようにしている。
私たちが履歴書を順序づける目的で使っている客観的な尺度がいくつかある。それによって最初に電話をかける相手がいい結果になる可能性を高くするようにしているのだ。
情熱を持っていること。私たちは応募者がコンピュータに対して情熱的であり、プログラミングが本当に好きなことを示すものを探す。情熱の兆候として典型的なものには次のようなものがある。
- コンピュータを使う仕事やプログラミングの経験が、非常に早い時期にまでさかのぼる。優れたプログラマというのはバナナリパブリックでシャツを畳んでいるよりは、コンピュータキャンプで夏を過ごしたり、歯医者をしているおじさんのためにオンライン予約スケジューラを構築したりしているものだ。
- 課外活動。プログラミングが好きな人たちは、しばしば余暇の時間に自分のプログラミングプロジェクト(あるいはオープンソースプロジェクトへの貢献)をやっている。
- 計算機プログラムの構造と解釈を読んでどんなに感動したかと添状の中で熱烈な文章を書いている。
- 履歴書の中にある、ある種のプログラミング言語やテクノロジーに関する記述は、その人がプログラミングを好きであり、新しいテクノロジーの探求にエネルギーを使っていることを示している。私がこれを書いている時点について言えば、Rubyが履歴書に書かれているのは、その人が最新のものについて調べるのが好きなプログラマで、常にスキルを向上させようと努めているということの徴になる。それは彼らがプログラミングへの情熱を持っているからであり、それというのも、Rubyを要求するような雇用者はまだ希だからだ。これについては気をつける必要がある。1996年にはJavaが履歴書にあるのはそういう情熱を示していたが、しかし今日では、それはほとんど何の情報も付け加えない。
選んでいること。私たちは添状をよく調べて、その応募者が本当に私たちのところで働きたいと思っていることを示すものを探す。自分について話しているばかりの一般的な添状は見たくない。彼らがその応募について真剣に考え、Fog Creekが自分の働きたい場所だという結論に至ったことの一貫した説明を聞きたい。これを手がかりとして使う理由は2つある。第一に、これはその候補者が何百という職に同時に応募しているのではないことを示している。彼らがFog Creekについて調べ、私たちだけのための添状を書くのに時間を使っているという事実は、彼らが自分の能力に自信を持っており、何千通もまとめてメールを出すのではなく、ごくわずかの会社にだけ応募していることを示している。一括送信の履歴書は死にものぐるいの兆候に思える。さらに重要なことは、専用の添状がある場合、私たちがその候補者に採用を伝えたとき、彼らがおそらく受け入れるということだ。これは私たちの歩留まりを高くする。私が6人の人間しか面接する時間がないとしたら、他の条件が同じであれば、他の何百という職にも応募している一般的に頭がいいという人よりは、Fog Creekで本当に働きたいと思っている6人を面接しようと思う。他の条件が同じならね。
英語ができること。英語の能力で履歴書に点数を付けるかどうかというのは、私たちにとって難しい決断だった。コンピュータプログラミングの領域では、英語を話せない移民が素晴らしいプログラマでありうるからだ。しかしたとえそうであっても、プログラマたちと働いてきた長年の経験から言えるのは、自分のアイデアについて明確にコミュニケートできるプログラマは、コンパイラとしかうまくコミュニケートできないプログラマよりもずっと実効性が高いということだ。コミュニケートできる能力はコードのドキュメンテーションのために重要であり、他の人がレビューできるよう仕様書や技術的な設計ドキュメントを書くために重要であり、そして何かをやるのにどんなやり方をするのが最善か議論するミーティングにおいて重要になるのだ。優れたプログラマであっても自分のアイデアがうまく説明できないならあまり大きな貢献はできない。このカテゴリーに関しては、履歴書がきちっと整然としているかどうかも考慮に入れる。文法ミスがたくさんあり、整理されていないごちゃごちゃした履歴書は、秩序立てて思考することができないのか、あるいは一般にだらしがないことの徴として、とても大きな赤信号になる。多くの仕事では別に問題にならないのかもしれないが、ソフトウェア開発では問題なのだ。特に私たちは通常英語の誤りの多い履歴書は失格にしている。たとえノンネイティブスピーカーであったとしても、誰か履歴書をチェックしてくれる人を見つけるのはそんなに難しいことではないはずだ。それができないというのは、自分のすることのクオリティに対する気遣いを欠いているということだ。その上で私たちは、高いコミュニケーション能力を持つノンネーティブスピーカーには理解を示そうと思っている。冠詞が抜けているチャーミングな東欧スタイルや、段落をすべて"So"で始めるチャーミングな北西太平洋スタイルは別に問題にしない。
頭がいいこと。このカテゴリーでは、私たちは候補者が頭が切れること、少なくとも数学キャンプに行っていたようなナード的な頭脳を持っていることを求めている。これの兆候としては、高いGPA、高い標準テストスコア、Phi Beta Kappaのような優等生協会、Top Coderコンテストへの参加、競技チェス、あるいはACMプログラミングコンテストに出ていることなどがある。
選ばれていること。私たちが履歴書の中に探すもう1つのものは、その人が過去に非常に選別的なプロセスを通り抜けていることの証拠だ。アイビーリーグ出身者がみんな雇うに値するわけではないし、コミュニティカレッジ出身者を避けるべきであるわけでもないが、しかし非常に選別的な大学に入っていることは、少なくとも誰かが、どこかで、ある種の選別プロセスを使い、その人が非常に優れていると判断したことを意味している。私たちの会社での選別性の基準は、応募者の30%未満しか受け入れない大学やプログラムに入っていたか(この基準に合うアメリカの大学は60くらいある)、一日中続く面接をするような難しい採用プロセスを持つことで知られる会社で働いていたということだ。軍隊で将校トレーニングやパイロットコースのような非常に選別的なところに所属していたり、あるいは海兵隊にいたというのも、その人がある種の難しい採用/選別手続きを通り抜けたことを示し、ポジティブな指標になる。
本格的であること。経験を積んだプログラマたちの間で、ある種のテクノロジーは他のものよりも本格的なものと考えられていて、その理由はうまく使うのが単に難しいためだ。これもまた弱い指標ではあるが、私はJavaで何かしたという人よりは、OCamlで何かやっていたという人に強い印象を受ける。アセンブラやデバイスドライバやカーネルでの仕事は、Visual BasicやPHPでの仕事よりも印象が強い。ATLを使うC++プログラミングは、Perlより難しい。オペレーティングシステムやコンパイラを作っていた人は、データベースの単純なフロントエンドを作っていた人よりも本格的と言える。
こんな風に言うのが扇動的に見えるのは分かる。何しろ過去5年の私の個人的なプログラミング経験はVBScriptであり、これは脳に深刻なダメージのある人にでも分かるようにVisual Basicを簡単にしたバージョンみたいなものだからだ。履歴書はプログラマを判定する方法としてはとても貧弱なものだということを思い出してほしい。そこから得られるのはごく弱い信号でしかない。その上で、ある種のテクノロジーは単に他のテクノロジーよりも難しく、そのテクノロジーを上手く使えたなら、雇うべき人であることの強い証拠になるということだ。だから履歴書を順序づける目的においては、難しいテクノロジーは上の方へ上がる傾向があり、一方で、たとえばMicrosoft Wordを使う能力があると主張するのは、底の方へ沈むことになる。
多様性をもたらすこと。含みの多い「多様性」という言葉を使って国際的な大きなフレーム戦争を引き起こす前に、私がここで意味していることを少し注意して定義しておきたい。私は既存のチームとは十分に違ったバックグランドを持つ人々を特に求めているのだ。彼らは新しいアイデアと新しい考え方をチームにもたらし、自分自身の声のこだまを聞いているようなグループ思考に疑問を引き起こしてくれる。私が異なるバックグランドと言うときに意味しているのは、文化的、社会的、それに職業的なものも含んでいる。エンタープライズソフトウェアで多くの経験を積んでいる人は、インターネットプログラマのチームに有用な多様性をもたらしうる。貧しく育った人は、アンドーバー出身のお坊ちゃんばかりのスタートアップに有用な多様性をもたらしうる。家庭に籠っているママが職場に復帰すれば、新卒ばかりのチームに有用な多様性をもたらしうる。アセンブラの経験のある電子工学エンジニアは、Lispハッカーのチームに有用な多様性をもたらしうる。エストニアの大学を最近出たばかりの人は、中西部出身の経験豊かなマネジメントコンサルタントのチームに有用な多様性をもたらしうる。ここでの理屈は、チームに多様性が多いほど、チームの誰かが何かの経験をバックグランドに持っていて、チームが異なった解法を見出せる可能性が高くなるということだ。
ここで強調しておきたいのは、これらの指標——情熱を持っていること、選んでいること、英語ができること、頭がいいこと、選ばれていること、本格的であること、多様性をもたらすこと——は、採用の基準ではない、ということだ。採用の基準にするには弱すぎる。このテストで点数が低いが非常に優れている人や、へぼなプログラマだが高い点数になる人はたくさんいる。ジョエルがアイビーリーグ出しか雇わないとか、GPAフェチだとか文句を言う前に、このリストが採用不採用を決めるためのものではないということを理解してもらいたい。履歴書の山を並べ直すための客観的で公正な方法というだけのことであり、それによってうまく行く見込みの最も高い候補者が最初に面接されるようにし、そのあと彼らを採用すべきかの判断をするのだ。
履歴書がそんなに貧弱なものであるなら、何かもっと関門を追加することはできないか?
今挙げたものは、どんなに想像をたくましくしようとも、履歴書を順序づけるルールとして理想的なものではない。私はむしろ再帰アルゴリズムを実装する能力とか、コードの中のバグをどれくらいの時間で見つけられるかとか、9個のことを短期記憶に保持しておくことができるかといったことで履歴書を順序づけたいと思う。その方が、エリート大学の入試委員会の基準を通ったということより、成功するプログラマのいい指標になる。残念ながら、これらのことは履歴書には書かれていない。
リクルーターが感じる誘惑の1つは、応募プロセスに余分な関門を追加するということだ。応募手続きにある種のプログラミングクイズを含めるという案はよく耳にする。これは応募の数を減らすという点では機能するが、しかし質を改善はしないという点ではうまく行かない。優れた開発者には、通常の添状＋履歴書しか要求しない会社だけでも十分な選択肢があり、応募するだけで作為的な関門やプログラミングテストを通ることを求めるなら、まずいプログラマ同様、いいプログラマも追い払ってしまうことになる。実際のところ、最高のプログラマを追い払ってしまう可能性が高く、それは彼らがもっとも多くの代替案を持つからで、残るのはあまり代替案を持たないが故に必死になっており、余分の手間をかけても喜んで応募してくる人たちということになる。
特定のテクノロジーの経験を求めないこと
ニューヨーク大学のパネルディスカッションで、私は学生にIT業界でのキャリアについてアドバイスしたことがある。私のアドバイスはこのアーティクルからの抜粋なのだが、創作文章講座を受講するかなにかして卒業するまでにいい文章を書く方法を学ぶことと、経済学を取ってビジネス側の話が別にミステリーでないことを理解するようにということだった。私はまたCかアセンブラによるローレベルのプログラミングコースを少なくとも1つ取って、コンピュータがローレベルにおいてどう動いているのか理解することを勧めた。
パネルでは地元のヘッドハンターが一緒で、彼は実際ニューヨークでも技術分野のリクルーターとしてはいい方だったのだが、彼のスピーチは15分に渡る退屈なアルファベットのごった煮だった。「私たちは多くのXMLと、幾分かのC++を目にしている。SOAPとWSDLはホットだが、COMやATLはあまり目にしない」。そういうのが目が回るくらい続いていた。彼は世界を履歴書のキーワードだけで考えている人だったのだ。
最高のプログラマにとってリクルーターの頭にくるところは、彼らがキーワードやバズワードに病的に執着していることだ。プロのヘッドハンターやリクルーターの業界では、候補者を職にマッチングする単純なアルゴリズムが使われており、採用側の会社が現在たまたま求めているものに合った技術略語のリストを持つ候補者を探すのだ。それが余計腹立たしく感じられるのは、そういったリクルーターのほとんどは、それらの技術が何を意味するのかまったく知らないということだ。「ああ、MSMQの経験はないの? じゃ、しょうがないね」。不動産屋であれば、サブゼロ冷蔵庫やバイキングストーブについておしゃべりしていれば、少なくともそれが何なのかは知っている(最近ではステンレス製の冷蔵庫はみんな「サブゼロ」とみなされているようだが)。技術分野のリクルーターは、5年のRuby on Railsの経験を求めたり、「Windows API」の仕事から履歴書に「Win32」としか書いていない人を落としたりするときにぼろを出す。
リクルーターがそんな風にしているのは、それが簡単で、コンピュータで処理でき、彼らが開発者を判断できる唯一の方法だからだ。
しかしそれは、ほとんどあらゆるソフトウェア開発の職について、およそ最悪な採用方法なのだ。
私たちの信条は長期的視点で採用するということだ。現在たまたま知っているどんな技術も、来年には古くなっている。しかもそれらの技術のあるものはとても簡単に学ぶことができる。誰かRubyでの開発ができる人を採用する必要があるというとき、SmalltalkとPythonの深い経験を持つがRubyのことは聞いたこともないという人は、Rubyの本を1冊読んだという人よりも成功する見込みがずっと高い。基本的に優れたソフトウェア開発者には、別なプログラミング言語を学ぶというのは全然たいしたことではないのだ。2週間で彼らは非常に生産的になっていることだろう。2年後には、まだ発明されていないプログラミング言語でまったく違ったことをやってもらっているかもしれない。
なんにせよ履歴書のキーワード欄はあまり信用できないものだ。現役のプログラマはみんな、そのキーワードで履歴書をフィルタするプログラムのことを知っており、さわったことのあるテクノロジーをすべて履歴書に入れ、フィルターを通るようにしている。
このルールには1つの例外がある。アーキテクトや開発者のリーダーを採用しようとしている場合だ。最初のコードの基礎を作り、システムが一緒に動くようにする方法見つけ出すチーフソフトウェアエンジニアには、あなたの使う技術に関して多くの経験を積んでいる人を採用したいだろう。C++とMFCを使ったWindowsのGUIプログラムを開発するチームであれば、コードがはじめから正しく構成されているようにすることができ、そして本当に難しい問題が持ち上がったときにそれを解決できるだけの十分な経験を積んでいるWindows/MFCのグルが、少なくとも1人、チームのどこかにいる必要がある。
構築が行われる言語、クラスライブラリ、API、プラットフォームについてのしっかりした数年の経験を持つアーキテクトが少なくとも1人いない限り、新しいプロジェクトをはじめたりしないことだ。プラットフォームを選ぶことができるなら、あなたのチームがもっとも良く使えるものを選ぶことだ。それがたとえトレンディなものではなかったり、もっとも生産性が高いと言われているものでなかったとしても。このことは、時にはある特定のテクノロジーのセットについて広範にわたる経験を積んだ候補者(単にキーワードがリストされているというのでなく、LAMPや.NETやJ2EEといったスタック全体について本当に知っている候補者)を探す必要があることを意味する。しかしソフトウェア開発者の大部分については、キーワードマッチングで雇うべきではない。
履歴書を順序付けるというのは、採用プロセスの1つの側面に過ぎない。採用プロセスにはプログラマに魅力的な環境を作ること、優れた履歴書を引き寄せること、厳格な面接プロセスを使うことが含まれ、それによって最高のソフトウェアを作れるプログラマを採用できるようにするのだ。
(オリジナル: Sorting Resumes)
