4つのカレンダーをまたぐ日程調整、実際の評価基準から作る面接キット、自動で進むオンボーディング、ハンドブックに基づくポリシー回答。エージェントはロジスティクスを担い、人に関する判断は人が行います。
ステージ2 — システム設計 · 面接官キット
What this stage is for: whether the candidate reasons about failure before they reason about throughput. It is not a breadth check — stage 3 covers breadth, and asking here duplicates it.
Open with a system they have actually operated, not a hypothetical. Follow the first failure mode they name all the way down. A strong answer gets more specific under pressure; a weak one gets more abstract.
Not in scope for this stage, and flagged because interviewers keep straying into it: compensation, notice period, and anything that belongs to the recruiter conversation.
Peopleチームの仕事は判断と大量の調整です。調整が判断を妨げます。以下はすべて、その調整側の仕事です。
面接官と候補者の都合が合う枠を見つけ、必要な資料を添えて招待を送り、面接官が離脱したら全体をやり直します。採用遅延の最も確実な原因であり、純粋なロジスティクスです。
各段階について、何を確認する面接か、それを実際に測る質問、良い回答と弱い回答の例を用意します。リポジトリ内の自社評価基準から生成するため、新人面接官も経験者と同じ進行ができます。
全面接官の記録を、入力者ごとではなく評価基準に沿って整理し、意見が分かれた点を強調します。意見の相違を表面化することが目的で、解決するのは面接パネルの仕事です。
アカウントを申請し、資料を集め、役割から初週の計画を作り、バディに通知します。誰かが開くのを覚えておくチェックリストではなく、実行されるチェックリストです。
Slackスレッドで質問すると、リポジトリ内の文書から該当箇所を引用して回答します。ハンドブックに答えがなければ、もっともらしいポリシーで埋めず、その旨を伝えて担当者に回します。
既存の役割とチームの実際の業務を読んでから求人票を書きます。そのため、似た肩書きの前回の求人票ではなく、実際の仕事に合った説明になります。
ここでの成果物は人ではなくプロセスに関するものです。採用ループを一貫させ、基準を明確にします。これはツールが本当に改善できる部分です。
What this stage is for: whether the candidate reasons about failure before they reason about throughput. It is not a breadth check — stage 3 covers breadth, and asking here duplicates it.
Open with a system they have actually operated, not a hypothetical. Follow the first failure mode they name all the way down. A strong answer gets more specific under pressure; a weak one gets more abstract.
Not in scope for this stage, and flagged because interviewers keep straying into it: compensation, notice period, and anything that belongs to the recruiter conversation.
キット、スケジュール、デブリーフの構成、オンボーディング計画。すべて採用の進め方に関するものです。候補者への判断は一切含みません。この境界は制限ではなく、意図したプロダクト方針です。
ポリシー回答は、該当箇所を引用したリポジトリ内の文書から作成されます。ハンドブックにない質問は担当者に回します。空白を埋めるのではなく、空白として報告します。
評価基準からキットを生成する価値は、速さではありません。15人目の候補者にも1人目と同じ面接を行えることです。これは効率以前に、公平性の特性です。
Peopleシステムには社内で最も機密性の高いデータがあるため、ここでは仕組みが最も重要です。各システムにはプロジェクトごとに一度だけ接続します。資格情報がマシンに入ることはありません。
Easy connectでは、各アプリのOAuth画面を通じて3,000以上のアプリに接続でき、多くの応募者管理・HRシステムはこの方法で利用できます。対応していない場合は、OpenAPI、GraphQL、raw HTTP、リモートMCPサーバーで接続できます。エージェントに触れさせたくないデータを持つシステムなら、正しい設定は接続しないことです。
同じセッションを開始する3つの方法。スケジュール実行は固定日でロジスティクスに向け、評価に関わるものには決して使いません。
Slackスレッドで質問し、ハンドブックの該当セクションを引用して回答します。ハンドブックに答えがない質問は、推測せず人に引き継ぎます。
候補者に送るものはすべてAskに設定します。メッセージと宛先を示す呼び出し箇所で実行が一時停止し、承認するとまったく同じ箇所から再開します。
cronトリガーが初日にセッションを開始し、チェックリストを進めます。アカウント申請、読書リスト作成、初週の計画、バディへの連絡。固定日・固定リストで、評価は含みません。
ここは「エージェントが処理した」が誤りになる機能です。1行目が製品としての立場で、残りはプラットフォームの制御です。
1つのプロジェクト、1セットのコネクタ、積み重なる1つのメモリ。各チームが自分の仕事に必要なスキルを書き、別のシステムを立ち上げる必要はありません。