メインコンテンツへスキップ
  1. 記事一覧/

開発者採用の面接でSTARメソッドを使う

· loading · loading ·
仁才徳
著者
仁才徳
韓国ソウル在住のリーダー兼ソフトウェアエンジニア

今年からエンジニアリングマネージャーとして採用する側に回る機会が増えました。そこで一番痛感したのは、候補者に経歴を自由に語ってもらうだけでは、ほとんど何も分からないということです。履歴書を見れば「何をやってきたか」は分かります。でも「どう働く人なのか」は、まず見えてきません。

そのギャップを埋めるのに一番役立っているのが、STARフォーマットを使った行動面接です。STARはSituation(状況)、Task(課題)、Action(行動)、Result(結果)の頭文字で、候補者に過去の実体験を語ってもらいながら、この4つの要素を順に押さえていきます。いかにも人事研修っぽい型ですし、実際その通りなのですが、具体性を強制できるのが強みです。シグナルは具体性の中にあります。

良い回答のかたち
#

「複雑なバグを解決した経験を教えてください」という質問を例にすると、聞き取りたいのは、当時の状況(何が起きていて、なぜ重要だったのか)、候補者自身が背負っていた課題、実際に取った行動(「私たちが」ではなく「私が」)、そして結果です。できれば数字付きで。

強い回答は、たとえばこんな感じです(技術的負債の例):

「デプロイパイプラインに45分かかっていて、不安定なテストのせいで開発者は何度もビルドをやり直していました。1ヶ月分のロスタイムを集計したら、1人あたり約15時間。このデータを経営側に示して、テストの並列化と特に不安定なテストの修正に2スプリント投資する提案をしました。結果、デプロイは12分に短縮され、デプロイ頻度は2倍になりました。」

状況、課題、行動、結果が5文に収まっていて、本人の貢献もはっきり分かります。「パイプラインが遅かったので直しました」という回答と並べてみれば、この型の価値は一目瞭然です。

よく使っている質問
#

すべてを網羅しようとするより、いまチームに必要なコンピテンシーを軸に質問を整理しています:

コンピテンシー質問
問題解決「プレッシャーの中で本番障害をデバッグした経験を教えてください。」
コラボレーション「難しいステークホルダーと協力する必要があったプロジェクトについて教えてください。」
テクニカルリーダーシップ「直接の権限がない中で技術的な意思決定に影響を与えた経験を教えてください。」
学習アジリティ「慣れない技術を短期間で身につける必要があったときのことを教えてください。」
オーナーシップ「自分が作ったものが失敗した経験を教えてください。そのときどうしましたか?」

最後の質問が個人的なお気に入りです。失敗をどう語るかは、成功談3つ分より多くを教えてくれますし、事前に台本を用意しにくい質問でもあります。

面接の本番はフォローアップ
#

候補者が最初からSTARの流れで完璧に答えてくれることは、まずありません。それで構いません。フォローアップの質問こそが面接の本番です。「パフォーマンスを改善しました」と言われたら、どのくらい、どうやって測ったのかを聞く。話がずっと「私たち」なら、あなた自身は何をしたのかを聞く。妙にきれいにまとまった話なら、次に同じ状況になったら何を変えるかを聞いてみる。

もうひとつ、身につけるのに時間がかかった教訓があります。全候補者に同じ質問をして、シンプルな基準で採点することです。機械的に感じますが、公平に比較する方法はこれしかありません。そうしないと、結局は直近に話した人の印象に引きずられてしまいます。

もちろん、これで技術評価が不要になるわけではありません。実際にものを作れるかどうかは、別途確かめる必要があります。ただ、仮定の質問は口先でしのげても、過去の行動はごまかしにくいものです。この1年面接を重ねてみて、練り上げられた「強みと弱み」の回答より、しっかり掘り下げたストーリーのほうがずっと信頼できると感じています。

参考資料
#

このサイトの関連記事:

外部リソース: