Joel on Software このページは"ジョエル・オン・ソフトウェア
| |||
※新しい翻訳はJoel on Software Translation Projectにあります。 その他の "Joel on Software" の記事(日本語) |
Joel Spolsky ジョエル・スポルスキ 翻訳: 松村 弘典 2000-03-23 Fog Creek Softwareでは適切にスタッフを採用する事が必須である。我々の業界では対象となる人々を3つのタイプに分類する事が出来る。一方には 未洗のイモ とでも呼ぶべき、この業種に従事するのに基本的なスキルさえも持ち合わせていない集団がいる。これらの人たちは履歴書を注意深く確認して2,3の簡単な質問をする事で比較的容易に除外する事が出来る。対極には スーパースター と呼ばれる、パーム上で動くLispコンパイラを週末の暇つぶしにアセンブリ言語で書いてしまうような人たちがいる。これらの中間にあたるのが大多数の「応募者」で、何かしらやってくれるのではないかと思わせる人たちである。ここで紹介する幾つかのトリックはこれら一般的な応募者とスーパースターとの違いを見極めるためのものであり、Fog Creek Softwareはスーパースター以外は採用しない。 まず始めに。Fog Creek Softwareに採用されるような人材には以下の要素が求められる。
これは非常に重要だ。ただこの点さえ思い出せてもらえれば良い。夜布団に入る前に毎晩暗誦して欲しい。我々の欲しているのは「 才能 」に溢れた逸材であり、特定のスキルを持つ技術者ではない。どのようなスキルも技術的に数年すれば時代遅れとなる。重要なのはどのような新技術でも習得する事の出来る人を採用する事であり、たまたまちょうど良いタイミングでSQLを知っていた人を採用する事ではない。 賢くて を定義するのは容易ではないが、先々で紹介してゆく面接の質問のなかでどうやって探してゆくかを見てゆこう。「 結果に結びつけられる 」ことは重要だ。しばしば大企業で見かける 賢くて しかし 何にも結果に結びつけられない人はたいがい博士号を掲げていて、常に非現実的な学術的思想を持ち出すのでほとんどの人から相手にされない。彼らにとっては学術的に問題を掘り下げてゆく事こそが至上であり、日程どおりに納品できる事は重要な事ではない。これらの人々は簡単に識別する事が出来る。彼らは大きく異なるコンセプトにセオリー的な類似性を見出す事が大好きで、たとえば「表計算はプログラミングのひとつの発展形だ」といって一週間ほど姿を消し、それがいかにプログラム言語に類似した計算言語としての属性を持つかについてのすばらしい論文を書き上げる。非常に賢い。が、役には立たない。 さて、 結果に結びつけられる が 賢くない 人たちはろくすっぽ物事を考えずに事を進めるので、結局誰か他の人が後始末をしなければならなくなる。有能な人たちの時間を吸い上げるこれらの人たちは会社の「負債」と言い換えることが出来る。関数化してまとめる事もせずにソースコードのブロックを丸ごとコピー&ペーストするような人たちがこれにあたる。結果的には確かに「結果に結びつけられ」てはいるが、あまり賢いやり方ではない。 面接で最も重要な事は:
面接の結果として、あなたは候補者に関する鋭い決断を下さなければならない。ここでの決断には2通りしか存在しない。 採用 か、 不採用 である。自分のPCに向かい、あなたのフィードバックを人事担当に即刻送信する。件名には候補者の名前を、本文の一行目は 採用 か、 不採用 であるべきだ。あとは何故そうなのかを説明する文が一行二行あればいい。 これら以外の決断は存在しない。 決して「他グループでなら採用してもいいんじゃないかな」のようなことは言わない事。これは大変無礼な答えで、候補者は私と働くには少々力不足だが、他の凡人部署には適当であろうと言っているのと同じである。もしもあなたがこれを言いそうになったら、機械的に「不採用」と翻訳していい。もしも候補者が君の部署のある業務を器用にこなせる可能性があったとしても、他部署ではまったく戦力になりそうにないというのであればやはり 不採用 だ。状況は刻一刻と変化してゆくものであり、我々が求めているのはどこで何をしていても成功に結びつける事が出来る人材である。もし君がSQLの天才的なエキスパートを見つけたとしても、それ以外のことを学べない人材であれば 不採用 だ。彼にFog Creekでの将来は無い。 決して 「たぶんね。なんともいえないが」も言わない。なんともいえないんだったら 不採用 だ。別に難しい事じゃない。同様に、「 どちらともとれない 」も 不採用 「基本的には採用だけど少し心配な点が・・・」などと言わない事。これも 不採用 なのだ。 面接で忘れてはいけない最も重要な点はここにある ―優良な候補者を誤ってはじいてしまう事は不良な候補者を誤採用するよりはずっとマシ― 不良候補者の不手際を修正するために、ゆくゆく多大なる優秀な人々の時間、ひいては会社のコストを犠牲にしなければならなくなる。少しでも不安要素があれば 不採用 だ。 面接をしてゆくとたくさんの候補者を落とさなければならなくなるだろうが、そんな事は心配しなくてもいい。Fog Creekは誰も採用できないだろうが、そんな事は 君の問題じゃない。採用担当者の問題で、人事部門の問題で、代表者の問題だけど君の問題じゃない。無能な人材が集まった巨大なソフトウェア会社に成長してしまうのと、小さくても高品質な会社である事と、どちらが重要化を常に自問して欲しい。もちろん優秀な候補者を探す事は重要だし、すべての人は優秀で有用な人たちを採用する事が面接の役割である事は理解している。が、もし君がFog Creek Softwareで面接官をするのならばあたかも我々には優秀な候補者が潤沢にいるかのように振舞って欲しい。どれだけ優秀な候補者が枯渇していたとしても妥協して合格点を下げる事は行ってはならない。 とは言っても、どうやってこの難しい決断を下したらよいのか。ここは基本に戻り、面接中に次の質問を自分自身に投げかけて欲しい。 「この人は賢いか?」 「この人は 結果に結びつけられる人か?」 正しい答えを得るためには、候補者に正しい質問を投げかける必要がある。 参考までに、この世で考えうる最低の面接の質問を挙げておく。「Oracle8iでのvarcharとvarchar2の違いは何か?」。Fog Creekが採用したい人間像とある特定のどうでもいいトリビアを知っているかどうかには何の関連性も無い。インターネットで15秒で調べられるような内容を知ってるか知っていないかにどのような価値があると言うのか。 実際のところまだまだひどい質問は存在するので、それらについても後述する。 ようやく本トピックの核となる「面接の質問」に入った。私の面接の質問リストは実は私のマイクロソフトでの初めての仕事で手に入れたものだ。いくつもの有名なマイクロソフト面接質問が存在しているし、誰もが自分のお気に入りを持っている。君もそのうち自分が 採用・不採用 を決断する為に欠かせない自分だけのお気に入りの質問群を蓄積してゆくだろう。ここでは私が使用していて有効だったテクニックについて説明する。 私は面接の前に候補者の履歴書を眺め、 面接の計画 を紙切れに書き留める。計画と言ってもたかだか自分の質問したい問題リストだが。例えばプログラマーの面接では下のような計画になる。
面接の前には、私は候補者に関する事前知識をなるべく耳にしないよう細心の注意を払う。仮に君が、既に面接が始まる前に候補者は賢い人だと思ってしまっていたら(たとえばそれがMITの博士号を取得したというそれだけの理由であったとしても)、そこから先一時間の間候補者が何を話そうともその印象が塗り替えられることは無い。君が候補者は呆け者だと思ってしまったらその先入観は面接中のどんな言葉でも払拭される事はないだろう。面接はとてもデリケートな秤のようなもので、たかが一時間余りの面接で人を判断するのは強引にも思える。ここでもし君が事前に得る少しばかりの先入観は大きな錘のようなもので、どちら側に乗ろうがその面接自体が無駄なものになってしまう。かつて一度、面接前に採用担当が私の部屋にやってきて「お前はこの候補者を 気に入るはずだ」と言った事があり参ってしまったことがある。今ならば「私がそこまでその候補者を気に入る自信があるならば何故即刻採用としないんだ、面接するのは私の時間の無駄じゃないか」と言えたろうが、その時私はまだ若く気も弱かったので面接を行う事にした。彼があまり賢くない返答をすると「これはきっと例外に違いない、聞き方が悪かったのかも」等のように彼の全ての言動を色眼鏡で見るようになってしまっていたので、結局いまいちの候補者であったにもかかわらず 採用 としてしまった。ところで他の全ての面接官は彼のことを 不採用 としていたらしい。従って、「採用担当の言う事には耳を貸すな」「候補者の事前情報収集は行うな」そして、「自分独自の結論が出るまでは他の面接官と候補者について話をするな」ということを強く勧めたい。これらは科学的根拠に基づいたものだ。 紹介 のフェーズは候補者をリラックスさせる意図で提供される。私は大体30秒程度で私が誰でどのように面接を行ってゆくのかを説明する。私はこのとき常に候補者に対して、我々が興味を持っているのは「 どのように」問題を解決してゆくかで、解決案そのものではないということを理解してもらうようにする。ところで面接中に机をはさんで候補者と対面する事は極力避けるようにしたい。これは両者の間に障壁を生成し、候補者を緊張させて本当の姿を確認する事が出来なくなってしまう。むしろ机を壁向かいにしたり、回り込んで候補者と同じ側に座って精神的な距離を縮めてあげることにより、候補者の精神状態に邪魔されないよりよい面接が期待出来る。 2番目は候補者が直近で関わっていたプロジェクトについての質問である。新卒対象であれば卒業論文の内容や、最も長期間就学したお気に入りの選択科目の事でも良い。例えば私は時々、「前学期に受講した科目のうちどれが一番好きだった?別にコンピュータに関連していなくても良いよ」というような質問をする事がある。実際のところ私は彼らがコンピュータに無関連の学科を習得していたと聞いてもそれはそれで喜ばしい事だと思える。彼らの科目スケジュールを見ると最低履修時間分のコンピュータサイエンスの科目以外は全て音楽関連で埋まっている事もあり、にもかかわらず「私はオブジェクト指向データベースについての科目が好きでした」というような返答を受けることがある。それはそれで良いのかも知れないが、私はそこででっち上げられるくらいならば素直にコンピュータよりも音楽が好きと返答してくれたほうが好ましいと思う。 中途採用の候補者であれば前職について聞いてみるのが良いだろう。 この質問で私が期待しているインプットはひとつ、「 情熱 」だ。候補者が直近で関わったプロジェクトについて以下の兆候が見られればそれはとても良い事である。
さて、リストの3番目は 解答のない問題 だ。これは楽しめる。この質問ではわざと答えようの無い問題を出して、候補者がどのように対処するかを観察する。たとえば「シアトルに視力調整士は何人いるか」「ロサンゼルスにガソリンスタンドは何件あるか」「ピアノの調律士はニューヨークに何人いるか」など。
プログラミングの問題に関しては、私はC言語で単純な関数を書くようお願いする。私の投げる典型的な問題を挙げる。
5行以上のコードを求められるような問題は敬遠するべきだろう。そんな時間は無いはずだ。 これらの問題についてもう少し掘り下げてみよう。1番、文字列のインプレイス反転について。私がこれまで見てきた全ての候補者は始めに必ずと言っていいほど引っかかる。彼らは例外なく別バッファを割り当てて、そこに反転した文字列を埋めてゆくのだ。問題は誰がそれを割り当てるのかと言うこと。この質問はたくさんの候補者から大変興味あるひとつの事実を私に伝えてくれた。Cを知っていると思っているほとんど全ての人達はメモリやポインタについて理解できていないのだ。このような人たちがプログラマとして仕事をしていると言う事実はにわかには信じ難いが、紛れも無い事実なのだ。この問題を用いて、以下の点を確認する事により候補者を判定する事が出来る。
3番目の問題では彼らがC言語のビット演算子をどれだけ良く学んだかを観察できるが・・・これ こそは才能ではなくスキルだ。だから君は多少彼らに助けの手をさしのべてあげても良い。おもしろいのは彼らにまずバイト中の立っているビットを数える関数を書いてもらってから、それを高速化するよう要求する事だ。非常に賢い候補者はプログラムの初期化時にルックアップ配列を作成するだろう(どれだけ多くともたかだか256エントリ程度なのだから)。それなりに賢い候補者とも要求メモリ・コード量と実行速度とのトレードオフについて興味深い会話が出来る。さらに彼らにプレッシャーを与えてもいい。初期化時にルックアップテーブルを作成する時間を費やしたくない、とか。賢い候補者はキャッシュを提案してくるかもしれない。初めての値の場合のみビットを数えてからルックアップテーブルを更新して、次から同じ値が来た時に再計算しなくてもいいように。更に賢い候補者は出現パターンを利用して格段に効率よく同テーブルの作成が行えるような方法を発明するかもしれない。 君が他人がコードを書くところを観察するときには、下記のテクニックが助けになるだろう。
無論君は彼らの関数内にバグを見つけることだろう。その為に5番目の「 自分の解答に満足しているか質問」があるのだ。「良し。じゃ、どこにバグがあるか教えて?」と聞いてみるといい。世にも憎らしい模範的なフリー回答の質問だ。全てのプログラマはミスを犯すが、そのこと自体に罪は無い。自分達で見つけることが出来ればよいのだ。文字列操作関数では彼らのほとんどは新しい文字列のNULL端末処理を忘れるだろう。ほぼ全ての関数で、「あと一歩なのに」という間違いがあるだろう。セミコロンを忘れているかもしれない。長さ0の文字列を渡すとうまく動作しなかったり、mallocが失敗したらアクセス例外が発生するかもしれない。候補者がバグの無いコードを書くなんてほぼありえないと思っていい。もっともその場合には次のやりとりは更に楽しいものになる。「君のコードにはバグがある」と君が言ったとき、候補者は注意深く自分のコードを見直すはずだ。そうしたら君は、候補者がいかに外交的且つ力強く彼のコードが完璧なものであるかを説得できるか観察できる。たいがいの場合、次に進む前に彼らに対して自分の回答に満足しているかどうかを聞く事は良いアイデアだ。どこかのクイズ番組の司会のように。 パート6、設計に関わる問題。候補者に何かしら設計するよう要求する。Excelを設計したJabe Blumenthalは候補者に対して家を設計するよう問題を出すのが好きだった。Jabeによると、ホワイトボードに向かって歩き出し、いきなり真四角を書いた候補者がいたそうだ。無論彼は即刻 不採用 。設計の質問だというのに何を考えているのか。
これらはそのまま7番目の「 挑戦的な質問 」につながる。これも楽しい。面接中、君は候補者が完全に100%疑いもなく正しい事を言う事を待つ。そうしたら君は「あれ?ちょっと待ってよ?」と言ってから2分ほど詭弁をふるって完全否定する。 彼らの言っている事が正しいとわかっている事 について議論を仕掛けるのだ。
確かに面接と言うシチュエーションでは候補者と君との立場が対等であるとは言い難い。君の立場が強い為に萎縮してしまい、議論をすることを候補者が遠慮してしまう危険性は十分ある。 それでも 、良い候補者と言うのは議論することについて積極的な傾向があり、それこそ面接中であるということすら忘れてしまってただ君を説得する事に専念するだろう。我々が雇用したいのはそういう人達なのだ。 最後に、君は候補者に対して何か不明な点があるかどうか質問すべきだ。面接官の幾人かは面接テクニックのマニュアルどおりにここで候補者が知的な質問をするかどうか観察するようだ。私個人としては別にここで候補者が何を聞いてきてもあまり気にしない。この時点では既に面接の結果について決断されているのだ。そもそも候補者は一日で5人から6人の面接官に出くわすのだ。そのそれぞれに異なるすばらしく知的な質問をしろと言うのは土台無理な話だろう。何も質問が無いならそれで結構。 私は常にいつだって必ず面接の最後に5分ほどFog Creekのことを売り込む。これは君が 候補者を採用する気が無かったとしてもとても大切な事だ。もし君が幸運にもすばらしい候補者に出会ったのだとしたら、この時点で君は全てを賭けて彼がFog Creekに入る事を確実にするだろう。だが、もしそれが悪い候補者だったとしても、Fog Creek Softwareについてエキサイトさせて、会社に対して好印象を抱いたまま帰路につかせるようにしたい。こう考えたらいい、彼らは従業員候補であるだけでなく、お客様であり、或いは外部採用担当者であると。もし彼らがFog Creekは仕事をするのに素晴らしい環境であると思えば、友達にも応募を勧めることだろう。 そういえば、避けるべき最低の面接の質問を幾つか紹介すると約束した事を思い出した。 まず始めに。違法な質問は避ける事。人種、宗教、性別、国籍、年齢、兵役、階級、性的嗜好や身体障害に関連する全ての質問は「 違法」である。もし候補者の履歴書に1990年に兵役についていたと書かれていても、湾岸戦争に行ったかどうかなど聞かない事。法律違反だ。履歴書にハイファのテクニオン大学卒と書かれていたとしても、どんな遠まわしにでもイスラエル系移民か?などとは聞かない事。法律に反している。 このページ で違法な面接の質問についてなかなか良い議論が展開されている(もっとも、それ以外の面接の質問にはバカバカしい物が目立つが)。 次に、質問する事によって、それがあたかも採用判断の基準であったり、我々がそれを非常に意識するのだと言う事を候補者に誤解させてしまうような質問はしない事。私の思いつく最良の例としては、候補者は妻帯者か否か、子供はいるのかを質問する事だ。このような質問は、まるで我々が「子持ちは仕事に対する貢献度が低い」とか、「産休を取られるんじゃないか」など懸念しているような誤った印象を与える。 最後に。6本の同じ長さのマッチ棒を使って4つの同じ形の正三角形を作れの類の頭の体操のような質問は避ける事。ひらめきが全ての質問を投げ、相手がそれに気づくか否かを観察したところで「賢くて結果に結びつけられる」人かどうかの情報は得られない。 面接とは確固たる理屈に基づくものと言うよりむしろ、抽象的なアートであろう。しかし、もし君が「 賢くて結果に結びつけられる 」という基本を思い出すことが出来れば君の面接はきっとうまく行く。もしも機会があったら同僚に面接時にどんな質問をするのかだとか、期待する回答だとかを聞いてみるといい。レドモンドの16号ビルカフェテリアでは昼食時のこの話題がいつまでも皆のお気に入りだ。 この記事の原文(英語)は The Guerrilla Guide to Interviewing です。 | ||
ジョエル・スポルスキは、ニューヨーク市の小さなソフトウェア会社 Fog Creek Software の設立者です。イェール大学を卒業後、マイクロソフト社、Viacom社、 Juno社でプログラマとして働きました。 |
このページは著者の個人的な意見を掲載したものです。
All contents Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.