· 6分で読了

雇用と面接

# 雑談
この記事は中国語から自動翻訳されたものです。翻訳によりニュアンスが失われている場合があります。

「謙虚さ」「飢え」「賢さ」という3つのキープレイヤー特性は、パトリック・レンシオーニ（Patrick Lencioni）の著書『理想のチームプレーヤー』で提示された、理想的なチームの特性だ。僕はこれをかなり使いやすい評価フレームワークだと思っている。

  • Smart
  • Humble
  • Hungry

特に注意したいのは、ここでいう Smart は単なる Book Smart ではなく、EQ が高く、対人コミュニケーション能力が高く、自分の言動が他人に与える影響を理解し、それを管理できることを指す。理想の同僚は同時にこの3つの特性を備えているべきだが、開発職に限って言えば、知的な意味での賢さもかなり重要だと思う。小さい頃から数学オリンピックやプログラミングコンテストで戦ってきたタイプである必要はなく、手を動かして問題を解き、深掘りし続ける力があるかどうかだ。

ジュニアエンジニアであれば、Smart + Humble を備えていれば十分だ。ただし、次の2つの組み合わせではいけない。

  • Smart + Hungry
  • Humble + Hungry

賢さと飢えは、ものづくりや開発においてより多くのアイデアを生む一方で、チームの意見を無視して独断で突き進む可能性もある。僕に言わせれば、組織内では Smart & Hungry だけではたいていうまく機能せず、むしろチームに害を与えやすい。Humble + Hungry はなおさらだ。組織に必要なのは、謙虚だが仕事がうまくできず、理想ばかり高い人ではない。

Vue の作者である Evan も以前こう述べていた。ものすごく賢いのに、こちらが出した意見を何でも否定する人がいる。こういう人はたいてい、プロジェクトを円滑に進めることができない。

https://x.com/saucedopen/status/1798973109598351683?s=46

Some people can be very technically brilliant but disagree on almost everything with you

Humble + Hungry には、実はかなり賢いのに、謙虚すぎるせいでそれが表に出ていないだけ、という可能性もある。こういうタイプには、プロジェクト内容について多めに質問して、その人が得意な領域で力を発揮できるようにするといい。

今は問題解決能力がより重視されるので、基本的には会社が求める人材像に合わせて戦略を調整する必要がある。

  • 会社が専門家を必要としているなら、より多くの専門能力を評価する
    • フロントエンドなら、候補者がパフォーマンス、アクセシビリティ、CSS、設計原則について深い理解を持っているか
    • バックエンドなら、候補者が自分のプログラミング言語を十分に使いこなせるか、そして大規模システムで必要となるコンポーネントにどれだけ精通しているか
  • 会社がゼネラリストを必要としているなら、より多くの問題解決能力を評価する
    • プロジェクトを最初から最後までやり切った経験があるかを見る。ここでいう経験は、練習用の Side Project ではなく、実際に問題を解決した経験でなければならない
    • 開発以外の視点、たとえばマーケティング、営業、プロダクト改善、Product Market Fit の発見などについての見識があるか

Denny は以前、DHH の記事『You can’t fix core competency with a stern conversation』を僕に共有してくれた。DHH によれば、新しく採用した人の状態が理想的でない場合、通常は Engagement と Competency の2つに分けて考えられる。

もし Engagement の問題、つまりコミュニケーションや協業が期待通りでないなら、話し合って認識と目標をそろえればよい。だが、仕事の能力の問題であれば、対話だけでは解決できない。DHH の主張は、専門技術は長い時間をかけて身につけるものであり、本人がそういう状態で現れているなら、対話で変わることを期待するのは現実的ではない、というものだ。

僕はこの DHH の記事をとてもよく書けていると思うし、その後、人選を評価する際の基準の1つにもなった。候補者が話題に出したプロジェクトについては、書いてある以上、できる限り細部まで聞くようにしている。本当に実装したのか、それとも少し手を加えただけで名前を載せただけなのかは、この段階でかなり見抜ける。

もう1つ僕がやるのは、現場での live coding だ。必ずしも完全なコードである必要はなく、簡単な機能実装や言語特性の確認（JavaScript を使うなら非同期処理くらいは知っておくべきだろう）、一緒に Code Review をすることでもいい。しかも僕は、面接者が AI を補助として使うことを嫌わない。むしろ推奨している。

僕が観察したいのは、次のような点だ。

  • 未知の問題に直面したとき、どう解決するか
  • プロジェクトを進めるとき、何を重視するか
  • 本当に開発をやってきたのか。踏んだ地雷や技術的判断について、すらすら語れるか
  • AI をうまく活用して効率を上げる方法を知っているか
  • センス

採用は難しい。特にスタートアップでは、不適任な人材はチームの士気に大きな影響を与えがちだ。短い面接の中で有望な候補者を見つけるのは、正直くじ引きに少し似ている。こういう状況では、精度を上げるしかない。僕がこのことに気づいたのは、つい最近だ。

前はとにかく来る者拒まずで、履歴書がそこそこ良ければ面接していたが、終わってみると想像とのギャップが非常に大きかった。リソースが限られている以上、より客観的なデータで絞り込むしかない。学歴、勤めていた会社、経歴、プロジェクトだ。

リソースが限られているなら、採用は Recall を上げるのではなく、候補者の精度を最適化することを目標にすべきだ。

面接する側

面接される側は会社の内部で働いたことがないので、会社への印象は面接官と面接プロセスから形作られることが多い。だから面接は、合う人を見つけるだけではない。面接の良し悪しは会社の評判にも影響する。僕は面接のとき、次の原則をできるだけ守るようにしている。

  • 面接者ができるだけ快適な状態で力を出せるようにする
    • この快適さを保つことに、こちらから積極的に気を配る
  • 「僕はあなたが通過できるよう助けたい」という姿勢で面接者に向き合う
    • すべての面接者を潜在的な協力相手だとみなす
  • 「相手を言い負かす」ことを目的にしない
    • 僕たちは協力相手を探しているのだ

面接者を言い負かすことを目的にして、SNS で得意げに相手を揶揄する面接官は多い。僕はこういう風潮にまったく賛同しないし、非常に嫌悪感を覚える。問題の難易度がどうこう以前に、今日の面接官が「こんなことも知らないのに応募してくるのか」という態度で面接者を見るなら、その面接は最初から無効だ。

いろいろ言ってきたが、いちばん大事なのは——人を人として扱うことだろう。

もちろん面接は双方向だ。十分な情報が得られて評価できると思ったら、大らかに「評価に足る情報は得られたので、ここで早めに終えてもよい」と言うのも1つの方法だ。