テックリードになると、採用面接の面接官を頼まれる場面も出てきます。
コードレビューや設計の相談には慣れていても、人を評価するための訓練を受けないまま面接の席に座ることは十分にあり得ます。
「何を聞けば、この人とチームでうまくやれるかが分かるのか」と迷ったことはありませんか？
面接を受ける側の対策とは逆向きの、評価する側の話です。
私自身もテックリードを目指して学んでいる途中なので、足場にするのは Google や GitLab が公開している面接の手引きと、採用に関する研究です。
先に結論を書くと、面接の前に「何を測るか」と採点の基準を決め、面接中は答えの正しさより考え方の筋道を記録するのが、テックリードに向いた関わり方でした。
面接の前に「何を測るか」を決めておく
面接の質を左右するのは、当日の質問のうまさより、その前の準備です。
Google が公開している構造化面接のガイドは、構造化面接を「同じ職に応募した候補者を、同じ方法で評価すること」と説明しています。
具体的には、全員に同じ質問をし、同じ尺度で採点し、事前に決めた基準で判断するというやり方です。
採点表には「優れている・十分・ボーダーライン・不十分」の回答がそれぞれどんな姿かを書いておき、面接官全員で同じ理解を持つよう勧めていました。
そこまで決める理由は、人が初対面の相手を無意識のうちに一瞬で判断してしまうからです。
同じガイドは、面接の場で最初の印象を裏づける証拠ばかりを探し始めてしまう確証バイアスを例に挙げていました。
研究の裏づけもあります。
Journal of Applied Psychology の第 107 巻（2022 年）に載ったサケット（Paul R. Sackett）氏らのメタ分析は、選考手法ごとの予測力の推定値を見直した論文です。
従来上位だった手法の多くは順位を保ったまま推定値が 0.10〜0.20 ポイント下がり、そのなかで構造化面接が最上位の選考手法になったと報告しています。
同じ論文は、選考で使う指標と入社後の仕事ぶりとの関係は、以前考えられていたよりかなり弱いとも結論づけていました。
面接で人を見抜ける度合いには限りがあるからこそ、ぶれを減らす仕組みが要る、と読めます。
では、何を測ればよいのでしょうか。
『An Elegant Puzzle』の著者ウィル・ラーソン（Will Larson）氏は、ブログ記事Designing interview loopsで、その役割の理想的な人物像から、成功に欠かせない技能を書き出して重要な順に並べる手順を紹介しています。
次に技能ごとの評価方法を決め、それぞれに点数と基準を明記した採点表（ルーブリック）を用意する流れです。
採点表が書きにくいなら、それは採点しやすい別の評価方法に替えるべきサインだというのも同氏の指摘です。
チームの技術と日々の仕事をいちばんよく知るテックリードは、この「必要な技能を言葉にする」段階で力を発揮しやすい立場でしょう。
三つの形式は「何が見えるか」で使い分ける
技術面接には、コーディング、設計、過去の仕事を聞く面接と、いくつかの形式があります。
どれを選ぶかの軸になるのが、ラーソン氏の「語ってもらうより、やって見せてもらう」という原則です。
同氏は、健全なチームを作った経験を語ってもらう面接をやめ、組織の健康度調査の結果を渡して問題点と打ち手を考えてもらう形に置き換えた例を紹介しています。
コーディングの面接でこの考え方に近い形をとっているのが GitLab です。
同社のハンドブックにある技術面接のページによると、候補者は面接用の小さなアプリケーションへのマージリクエストを事前にレビューし、当日はそのレビューを説明しながらコードを書いて改善します。
見ているのは、非同期でのコミュニケーション、技術の知識、チームのメンバーと協力できるかどうかです。
レビューとその改善という、入社後の日常業務にいちばん近い形で力を見ていると言えそうです。
レビューで何を見るかをチームのレビュー運用と同じ物差しにしておけば、採点もぶれにくくなるでしょう。
チームのレビュー運用の決め方は、こちらにまとめました。
設計の面接について、ラーソン氏は Staff 以上のエンジニアの面接を論じたStaff-plus interview processesで、システムの設計を説明してもらい、変わっていく要件に合わせて設計をどう育てるかに焦点を当てる形を挙げています。
過去の仕事を聞く面接は、行動面接とも呼ばれます。
GitLab の面接の進め方のページは、「〜したときのことを教えてください」という形の質問で、状況・課題・行動・結果（STAR）の順に話してもらうよう勧めています。
過去の行動は、その人がこれからどう動くかを示す最も有効な手がかりとみなされている、というのがその理由です。
ただしラーソン氏は、経験を語らせる面接は意図せず「受け答えの洗練度」を測ってしまいやすいとも注意しています。
見るべきは「正解」より「考え方の筋道」
形式が決まったら、次は面接中に何を記録するかです。
GitLab のガイドは行動面接について「正解はない」と書き、大事なのは候補者の話を聞いて、どう語るかについてのデータを集めることだとしています。
確認の観点として並ぶのは、話に結果があるか、結果を何かで測ったか、追加の質問で評価に足る具体性を引き出せたかといった項目です。
テックリードの目で見るなら、設計や技術の質問で拾いたいのはトレードオフの扱い方です。
ラーソン氏は Staff 以上のエンジニアに求める「判断力」の一つに、トレードオフや設計をめぐる議論を取りまとめられるかを挙げています。
採点表に「前提をどう確かめたか」「選ばなかった案と、その理由を言えたか」といった観点を書いておくと、答えの見た目のよさに引っ張られにくくなりそうです。
技術選定の場で「選ばなかった理由」を残す考え方は、別の記事でも扱いました。
記録は、面接が終わったらすぐに残すのが基本です。
GitLab は評価シート（スコアカード）を 24 時間以内に書き終えること、長所と短所を必ず両方書くこと、仕事に関係のないことは書かないことを求めています。
エンジニア向けの評価シートでは、点数の理由を記入欄に残すよう求めている点も見逃せません。
点数そのものより、その点をつけた理由が、あとで評価をすり合わせるときの材料になるからです。
評価のすり合わせと、陥りやすい落とし穴
面接官が複数いるなら、全員の評価が出そろってから話し合う順番を守るのが大切です。
GitLab では、偏りを減らすために面接官はほかの面接官の評価シートを見られない仕組みになっています（採用責任者は閲覧可）。
先に誰かの評価を読めば、それが自分の見立ての出発点になってしまう、という心配からでしょう。
そのうえで、つまずきやすい落とし穴を三つ挙げます。
自分に似た人を高く評価してしまう
GitLab は、よくない評価の例として「これまでで最高の候補者」「多くの点で自分を思い出させた」と書いた文を載せ、ほかの候補者と比べる書き方は親近感バイアスや対比バイアスにつながると説明しています。
ラーソン氏も、「このチームに自然になじみそう」という感覚で決める面接は、自信の見せ方のような、能力とは関係の薄い特徴に引っ張られやすいと書いていました。
自分の今の仕事ができるかで測ってしまう
同じ記事でラーソン氏は、経験の浅い面接官が候補者の強みではなく「面接官自身の今の役割をこなせるか」を基準にしてしまう失敗も挙げています。
『Software Engineering at Google』の第 5 章は反対に、自分より優秀で、いずれ自分の代わりが務まる人を採るよう勧めています。
同章は、自分の立場を脅かさない人ばかりを採ることを、避けるべきパターンの一つに数えていました。
急ぐあまり基準を下げてしまう
同じ章には「採用の基準を妥協する」という、避けるべきパターンもあります。
5 人採りたいチームが 40〜50 人を面接し、基準に届いているかどうかに関係なく上位 5 人を選んでしまう、という例です。
採るべきでなかった人を採ったときのコストは、適した人を探すコストよりはるかに大きいというのが同章の立場でした。
事前に決めた基準は、ほかの候補者と比べずに済む物差しにもなるわけです。
最後に
テックリードが面接官を務めるときは、面接の前に測る技能と採点表を決め、面接中は考え方の筋道を記録するのが軸になります。
評価は全員が書き終えてから持ち寄り、自分に似ているかどうかではなく基準で比べます。
どれも大がかりな仕組みは要らず、次の面接の前に、見たい技能と「どんな答えなら何点か」を書き出すところから始められます。
いつか面接の席に座る日に備えて、「点数の横に理由を一言」を覚えておくつもりです。
以上です。
コメントを残す