必須条件と除外条件
Mira が要件を理想の候補者プロフィールに変換する仕組み。Must-Have、Nice-to-Have、Avoid にそれぞれ何を入れるか、そしてそれぞれが検索とランキングをどう形づくるか。
検索を始める前に、Mira はあなたのブリーフを 理想の候補者プロフィール に変換します。これはあなたが確認して承認する、構造化されたサマリーです。3 つのリストで構成され、それぞれが検索を異なる方向に導きます。要件を正しいリストに入れることが、結果をコントロールする方法です。
3 つのリスト
| リスト | ここに入れるもの | 検索をどう形づくるか |
|---|---|---|
| Must-Have Requirements | 候補者が必ず満たさなければならない、譲れない条件 | ハードな基準。Mira はこれを使ってフィルターとマッチングを行うため、1 つでも欠ける候補者は通過しません。 |
| Nice-to-Have | 満たしていれば候補者をより強くするが、満たしていなくても除外はしない希望条件 | 検索を広げ、合致する候補者を押し上げます。誰かを除外することは決してありません。 |
| Avoid | 除外条件。避けたい競合企業や、エージェンシー・コンサルティング専業の経歴など | 検索には使いません。候補者を取得した後に適用し、合致する人を除外またはランクダウンします。 |
各リストは独立しており、同じ条件を 2 つのリストに入れるべきではありません。1 つでも中身があれば、どのリストは空でも構いません。
採用基準から保護属性を除外してください。年齢、性別、人種、宗教、国籍、障害の有無といった属性は有効な要件ではありません。Mira はこれらに基づいてフィルタリングやランク付けを行わない設計になっており、ほとんどの市場でこれらを採用基準に用いることは法律違反です。
ハードフィルター vs 推論による条件
要件を自分で「フィルター」と「あいまいな条件」に振り分ける必要はありません。Must-Have Requirements の中で、Mira は各行を読み取り、どう使うかを判断します。
- フィールドに対応するものには リテラルなフィルター。役職、シニアリティ、勤務地、企業など。
- それ以外には 推論による条件。「プロダクトを 0 から 1 に立ち上げた」「高成長企業出身」といった暗黙的なものは、Mira がキーワード照合ではなく解釈します(Mira の検索の仕組み を参照)。
つまり、あなたは要件を自然な言葉で述べるだけで大丈夫です。それがハードフィルターなのか、それとも推論すべきものなのかは Mira が処理します。
確認、編集、承認
Mira は検索を始める前に、カード上で理想の候補者プロフィールを提案します。主導権はあなたにあります。
- どのリストも編集できます。Must-Have を追加する、何かを Nice-to-Have に移す、競合を Avoid に加えるなど。
- 内容が正しく見えたら、検索 をクリックします。そのまま採用しても、先に編集しても、検索はカード上のプロフィールに対して実行されます。
Mira はあなたが承認してから初めて検索を始めるため、検索はあなたが設定した基準そのものに対して実行されます。あとから方向性を変えたくなったら、プロフィールを調整すれば、Mira は新しいバージョンに対して再実行します。
ヒント
- 譲れない条件は Nice-to-Have ではなく Must-Have に入れる。 Nice-to-Have の要件は誰も除外せず、押し上げるだけです。
- 候補者を除外する条件には Avoid を使う。 特定の競合企業や方向性の合わない業界など、説明文の中に埋もれさせるのではなく Avoid に入れます。
- 各行は 1 つの原子的な条件にとどめる。 そうすることで Mira はそれぞれをきれいに評価できます。
次のステップ
- Mira の検索の仕組み:確認済みのプロフィールがどのようにマルチソース検索を駆動するか。
- 候補者プロフィールの中身:返ってきた候補者をどう読むか。
- Mira が候補者をマッチさせる仕組み:MRE があなたの条件をどう推論するか。