採用時に、上級エンジニア候補者の高度なシステムアーキテクチャ設計能力を客観的に評価する方法

2人の候補者に同じ課題が与えられた。ユーザーが短いビデオクリップを共有できるサービスを設計せよ、というものだ。1人目の候補者は10分で分かりやすい図を描き、よく使われるコンポーネントをすべて挙げ、自信満々に説明した。2人目の候補者はゆっくりと話し始め、ユーザーは誰なのかを尋ね、どの部分がよく分からないのかを述べ、ストレージについて異なる選択をし、明確な理由を説明した。面接官Aは1人目の候補者を「優秀」と評価した。同じ面接に立ち会った面接官Bは2人目の候補者を「優秀」と評価した。2人のメモはほとんど一致しなかった。

これは例示シナリオであり、採用に関する記録された事例ではありません。よくあるケースなので、ほとんどのエンジニアリングチームなら認識できるでしょう。どちらの設計も妥当でした。違いは、各面接官が評価した項目、つまり流暢さ、スピード、自身が好むアーキテクチャへの精通度、あるいは論理的思考の質でした。このガイドは、同じ証拠に基づいてシニア候補者を評価するシステム設計面接のルーブリックを必要とするエンジニアリングマネージャーとエンジニアリングイネーブルメントリーダー向けです。これにより、2人の面接官が同じ理由で同じ結論に達することができます。以下の各基準は、実際の採用決定に使用する前に、シニアエンジニアによる検証と公平性の確認が必要です。

システム設計面接の評価基準とは何ですか？

システム設計面接の評価基準は、何を求めているのか、各評価が観察可能な行動でどのように表れるのか、そしてどのミスが他の強みで補えないのかを一覧にした採点ガイドです。これは質問の横に配置されるため、各面接官は同じ基準に基づいて証拠を収集します。Google の構造化面接ガイドでは、これらの採点ツールを「評価基準」と呼び、研究者は「行動基準評価尺度」と呼んでいると指摘しています。構造化面接は予測妥当性が高く、人口統計学的グループ間の差異が小さく、事前に作成された質問、ガイド、評価基準によって面接1回あたり平均40分節約できると報告しています。詳細なガイダンスは、Google re:Work: 構造化面接ガイドで読むことができます。

公開されている事例は簡単に見つけることができ、そのほとんどは候補者向けに書かれています。このガイドは、その逆、つまり採用される側の人々のためのものです。

クイック事実

1. 評価対象となるパフォーマンスを定義する

まずは仕事内容から始めましょう。テーマから始めるのではなく。シニアエンジニアにとって、関連するタスクは通常、曖昧な問題が与えられたときに、アーキテクチャ上の決定を下し、それを擁護し、変更すべき点を述べることです。これを1つの文で書き、その人物が働く役割、レベル、およびコンテキストを明記してください。決済会社のシニアバックエンドエンジニアの役割と、メディア会社のシニアプラットフォームエンジニアの役割では、求められる水準が異なります。

また、評価対象としていない項目も明記してください。タイピング速度、特定のクラウドベンダーへの精通度、共有ホワイトボードにきれいに絵を描く能力などは、よくある偶発的な評価基準です。これらが業務内容に関係ない場合は、評価点に影響すべきではありません。

2. 代表的で、かつ馴染みのないタスクを選択する

実際の業務内容を反映し、受験者が暗記できないような問題を選びましょう。「URL短縮サービスを設計せよ」といったよく知られた問題は、練習の成果が評価されます。自分の専門分野から機密情報を削除した問題を選び、上級エンジニアに独立して解いてもらい、妥当な解答の範囲を把握しましょう。

45分間の問題解決能力は、シニアエンジニアの能力のごく一部しか示していないことを理解してください。このテストでは、曖昧さ、制約、トレードオフへの対処能力は評価できますが、メンターとしての能力、数ヶ月にわたる移行作業の遂行能力、長期にわたるインシデントへの対応能力は評価できません。採用資料にその旨を明記しておけば、誰もテストの点数を過大評価することはありません。

3. 観察可能な基準とアンカーを記述する

書き留められる証拠に基づいて評価基準を作成する。上級システム設計面接のための、簡潔で実用的な評価基準の例：

各基準を0～2点で採点してください。0点は基準を満たしていないか、根拠が不十分な場合、1点は関連する項目が欠落している部分的な基準を満たしている場合、2点は合意された基準に照らして完全かつ妥当な基準を満たしている場合です。評価尺度よりも、基準となる点数（アンカー）が重要です。例えば、トレードオフの推論においては、0点は「理由を述べずに技術名を挙げている」場合、1点は「理由は述べているが、代替案のコストは示していない」場合、2点は「提示された制約条件に対して選択肢を比較し、それぞれが何を犠牲にするかを述べている」場合です。

面接官が提示したデータ保護要件を無視したり、明確な制約を満たせない設計を提案したりするなど、重大な誤りは個別に定義してください。平均点に重大な誤りを隠してはなりません。自信やスピードに基づいて採点することは避けてください。慎重に思考する静かな候補者を、そのスタイルを理由に減点すべきではありません。判断力と問題解決能力を評価するためのガイドでは、推論課題の評価基準の書き方について解説しています。

4. 評価者の能力を検証し、パイロットテストを実施する。

二人が読み間違えるような評価基準は、まだ評価基準とは言えません。実際に使用する前に、以下の点を確認してください。

1. 例を一つ選んでください。 採用プロセスに関わっていない同僚が作成した文書によるデザインを使用するか、本人の同意を得た上で模擬面接の録画を使用してください。
2. 独立して採点する。 各評価者は、他の評価者の点数を見る前に、各評価基準に関する根拠を記述する。
3. 証拠を比較する。 得点差が1点を超える場合は、基準点が曖昧だったのか、評価者が異なる点に気づいたのかを調べてください。基準点を書き直してください。
4. 別の例についても同様に繰り返してください。 意見の相違が言葉遣いではなく判断に関するものである場合は、そこで議論を止めましょう。

Googleのガイドでは、面接官のトレーニングとキャリブレーションを組み合わせることで、面接官が評価に一貫性と自信を持てるようにしており、これは同じ考え方です。近隣チームのエンジニアリングマネージャーなど、専門家にケースとアンカーをレビューしてもらい、人事チームには採用地域における公平性と法的要件を満たしているかどうかプロセスをレビューしてもらいましょう。

5. 現実的な例題に取り組む

例示です。使用前に、上級エンジニアが事例と解答基準を検証する必要があります。

課題内容：候補者は、配達アプリ向けの通知サービスを設計する。顧客は注文状況が変更された際に通知を受け取ることができる。注文規模は「1日に数百万件の注文があり、そのほとんどが食事時」とだけ説明されている。

最初の試み。「注文サービスと通知ワーカーの間にメッセージキューを配置し、すべてのイベントをデータベースに保存してプッシュ通知を送信します。」構造は妥当だが、候補者は必要なチャネル、通知が遅れたり二重に送信されたりした場合の対処法、ピーク時の負荷がキューにどのような影響を与えるかといった点について質問しなかった。

面接官からのフィードバックと再面接。面接官は「遅延通知と重複通知、どちらがより問題でしょうか？」と尋ねます。面接官は各評価基準ごとに標準的なフォローアップ手順を用意しておくべきであり、そうすることで全ての候補者がスキルを示す機会を平等に得ることができます。

より強力なアプローチ。「プッシュ通知の場合、重複メッセージはアプリへの信頼を失う原因となるため、送信順序とステータスキーを使用して送信を冪等化します。SMSの場合は、コストがより重要なので、時折の重複メッセージは許容します。食事時のピーク負荷時には、キューがバーストを吸収し、ワーカーがキューの深さに応じてスケーリングする必要があります。配信時間の約束がどの程度厳格か不明なため、単純な再試行ポリシーと時間制約のある更新のための優先レーンのどちらを選択するかを決める前に、プロダクトオーナーに確認します。」

採点。評価基準に基づくと、この回答はトレードオフの推論（2つの選択肢、コスト、理由）で2点、問題設定（前提条件の提示、質問）で2点、面接官が制約を追加するまでの変化への対応で1点となります。面接官は、候補者の設計を自分の好みの設計と照合するのではなく、証拠に基づいて採点していることに注意してください。

インタラクティブな配信が役立つ場面

ここで身につけるスキルは面接官向けのものであり、インタラクティブな練習が適しています。ライブのキャリブレーションセッションでは、例のデザインを示し、各評価者に各基準を個別に採点してもらい、議論の前にその分布を公開します。参加者は、部屋の中で最も声の大きい人の意見を聞く前に採点を確定し、意見の相違は書き直す必要がある基準点を示します。同じ例とルーブリックは、後から参加する新しい面接官向けに自己ペースで実行でき、曖昧なケースについてはライブセッションで議論できます。AhaSlides は、インタラクティブな学習とライブ配信と自己ペース配信の切り替えをサポートしています。これはプレゼンテーションおよび学習ツールであり、面接プラットフォームや応募者追跡システムではないため、実際の候補者データは採用ツールに保持してください。使用する予定の特定の作成、フィードバック、またはレポート機能は、独自のワークフローと照らし合わせて確認してください。フォーマットの選択については、適応型、インタラクティブ、ライブ学習を使用するタイミングに関するガイドを参照し、フィードバックの設計については、有用なフィードバックを備えたインタラクティブな練習の設計を参照してください。

何が変わったかを測定する

評価基準が機能していることを示す指標を事前に決定しておきましょう。実用的な指標は2つあります。1つ目は一致度です。同じ録音または文書化された設計図に対して、独立した面接担当者は、調整後の方が調整前よりも評価が近いでしょうか？評価対象者、分母、およびタイミングを明確に定義してください。2つ目は関連性です。数か月後、評価結果は新入社員の設計レビューにおけるパフォーマンスと関連しているでしょうか？採用人数が少ない場合は、これはあくまで目安に過ぎないため、評価基準の見直しを促すきっかけとして捉え、決定的な証拠とはみなさないでください。結果が改善した場合は、評価基準の有効性を判断する前に、役割定義の変更や調達チャネルの変更など、同時期に他に何が変わったのかを確認してください。

残る可能性のある制約

• 代表性。 一つの問題提起は、仕事内容の一部を示すものです。それに加えて、作業サンプルや過去の決定に関する構造化された対話など、他の証拠も提示しましょう。
• 公平性。 評価基準はばらつきを減らすのに役立ちますが、それだけで偏見を取り除くことはできません。事例と評価基準を精査し、背景に関する前提がないか確認し、人事チームと協力してグループ間の評価結果を比較してください。
• 面接時間。 調整には何時間もかかる。それがなければ、評価基準はただの長い書式に過ぎない。
• 役割の明確化。 チーム内で「シニア」の意味について合意が得られない限り、どんな基準を設けても解決にはならないだろう。
• 法的背景。 採用選考に関する規制は地域によって異なります。選考プロセスを変更する前に、現地の要件を確認してください。

よくある質問

システム設計面接の評価基準には何を含めるべきでしょうか？

問題設定、トレードオフの推論、深み、変化への対応、コミュニケーションなど、3～5つの評価基準があり、それぞれに0～2点の点数が付けられ、さらに重大な誤りのリストが別途作成される。

面接官が自信度で評価を下すのをどうすれば防げますか？

点数をつける前に、各評価基準について観察可能な証拠を記述させ、各点数を「2つの選択肢を比較し、選ばなかった選択肢のコストを述べる」といった行動に結びつける。

システム設計の面接はどのくらいの時間で行うべきでしょうか？

面接は通常1時間程度に設定されますが、適切な長さとは、候補者が評価基準のすべてを示すことができる長さです。まずは試験的に面接を実施して試してみてください。

評価基準によって採用を客観的にすることは可能か？

これにより一貫性が高まり、監査も容易になるが、判断は依然として必要となる。目的は、面接官が同じ理由で意見を一致させることであり、意思決定から個人を排除することではない。

どこから始めれば

募集中の職種を1つ選び、1文で職務内容を記述してください。アンカーポイントと簡単な重大なエラーリストを含む3つの評価基準を作成し、上級エンジニアに独立してそのケースを解決してもらいます。面接担当者と1回のキャリブレーションセッションを実施し、意見の相違が生じたアンカーポイントを書き直し、広く使用する前に少数の実際の面接で評価基準を試験的に適用してください。

キャリブレーションセッションを自社の面接担当者とリアルタイムで実行し、その後は各自のペースで再利用する方法を確認するには、AhaSlidesをご覧ください。