MUST・WANT・NGの違い
MUST｜検索結果に最低限必要な条件
MUSTは、その求人を検討するうえで入社時点から必要性が高く、検索から外すと確認工数が大きく増える条件です。
たとえば、特定の職種経験、業務経験、資格などが候補になります。
ただし「求人票に必須と書いてあるから」だけで設定せず、その条件が本当に検索段階で必要かを確認します。
WANT｜検索で落とさず、候補者評価で使う条件
WANTは、経験があれば求人との適合度が高まる条件です。
検索ではOR条件として広げたり、プロフィール確認時の加点材料として使ったりします。
たとえば、業界経験、特定商材の経験、マネジメント経験などが求人によって該当します。
NG｜明確に対象外と判断できる条件
NGは慎重に設定します。
「理想ではない」「できれば避けたい」という程度の条件までNGへ入れると、母集団を必要以上に狭めます。
明確な業務要件や選考基準に基づいて判断し、法令や採用上の公正性に反する属性を安易な除外条件にしません。
求人票をそのまま検索条件にしない
求人票には、役割、業務内容、必須要件、歓迎要件、人物像など多くの情報があります。
しかし、すべてが検索可能な条件とは限りません。
求人票を次の4種類へ分けます。
・候補者の職務経歴から確認できる経験
・資格やスキルなど明示的に確認できる条件
・面談や選考で確認すべき能力
・会社が求める人物像など、検索では直接確認しにくい条件
検索条件にするのは、原則として候補者プロフィールから事実として確認できるものです。
「コミュニケーション力が高い」「主体性がある」といった抽象的な能力を、職務経歴だけから推測して検索条件にしません。
MUSTを絞る方法
MUST候補を出したら、一つずつ次の質問で確認します。
この条件がないと入社直後に仕事を任せられないか？
入社後に習得できる経験までMUSTにすると、候補者を落としすぎます。
近い経験で代替できないか？
特定業界、特定製品、特定技術などは、近い経験で代替できる場合があります。
検索段階で必要か？
候補者プロフィールだけでは判断できず、面談で確認した方がよい条件もあります。
この3点を確認し、検索MUSTを最小限にします。
WANTを加点条件として使う
WANTは「あるか・ないか」で候補者を検索結果から消すのではなく、候補者確認時に優先順位をつけるために使います。
たとえば次のように整理できます。
・WANT A：求人との接点が強く優先して見たい
・WANT B：あるとプラスだが必須ではない
・WANT C：入社後に活かせる程度
WANTの数が多い求人でも、候補者にすべてを求める必要はありません。
「3項目中1つ以上」など、複数の強みのどれかを持つ候補者を拾う設計もできます。
候補者プロフィールで確認できる「証拠」を決める
MUST・WANTは抽象語のままでは運用できません。
各条件について、「候補者情報のどこに何が書いてあれば満たすと判断するか」を決めます。
たとえば法人営業経験なら、職種名だけでなく、担当顧客、営業手法、商材、実際の業務記述などを確認します。
プロジェクトマネジメント経験なら、役職名だけでなく、進行管理、要件整理、チーム管理、顧客折衝などの記述を見ます。
この証拠を定義すると、担当者による判定差を減らせます。
求人要件を検索条件へ変換する
求人要件を整理したら、媒体上の検索項目へ変換します。
主な変換軸は次の通りです。
・職種
・業界
・業務経験
・スキル、資格
・キーワード
・勤務地
・年収など求人と関係する条件
ただし、媒体ごとに検索項目と仕様は異なります。
同じ求人でも、媒体Aでは職種選択、媒体Bではキーワード検索を中心にするなど、実装方法は変わります。
媒体の現行画面・公式情報を確認し、存在しない検索項目を前提にしません。
AND条件を増やしすぎない
検索条件を細かく設定すると、「職種AND業界ANDスキルAND経験年数AND製品経験」のように条件が重なります。
一つひとつは妥当でも、組み合わせると候補者がほぼ残らないことがあります。
そのため、検索条件を追加するたびに候補者件数を確認します。
特に、業界経験、経験年数、特定製品、特定企業などは、本当にMUSTかを見直します。
候補者件数と対象率をセットで見る
検索結果が多い・少ないだけでは、良い条件か判断できません。
検索後に候補者プロフィールを確認し、「実際にスカウト対象になった割合」も見ます。
候補者数が多く対象率が低い場合は、検索条件が広すぎる可能性があります。
候補者数が少なく対象率が高い場合は、条件が厳しすぎて有望候補者を検索から落としている可能性があります。
必要な送付数を確保できるかまで含めて判断します。
条件を緩和する順番
候補者が少なすぎる場合、一度に全部の条件を外さないことが重要です。
おすすめの考え方は次の順番です。
1. MUSTの中にWANTが混ざっていないか確認する
2. 特定業界・製品・技術の完全一致を見直す
3. 経験年数を仕事内容や責任範囲へ置き換える
4. 同義語・類義語を追加する
5. 地域や働き方など求人条件側も必要に応じて確認する
一項目ずつ変更し、候補者件数と対象率がどう変わったかを記録します。
検索条件は求人ごとに更新する
一度作った検索条件を固定すると、市場や求人要件の変化に対応できません。
実際の選考結果を見て、検索条件と候補者評価を見直します。
たとえば、選考通過者に共通する経験が見つかった場合はWANTへ追加できます。
逆に、MUSTとしていた経験が実際の選考では重要でなかった場合は、検索から外すことを検討します。
検索条件は採用チームと現場で共有する
採用担当者と現場でMUST・WANTの理解が違うと、スカウト対象者を選んでも書類や面談で落ち続けます。
運用開始前に、条件名だけでなく「満たす具体例」「満たさない例」「要確認にする例」を共有します。
判断が割れた候補者を定期的に振り返ると、基準を揃えやすくなります。
AIでMUST・WANTの叩き台を作る
生成AIは、求人票や採用要件から、職種、業務、スキル、資格、経験などを抽出し、MUST・WANT・NGの叩き台を作る用途に使えます。
ただし、AIが求人情報にない条件を補ったり、一般的な採用基準を勝手に加えたりすることがあります。
最終的な検索条件は採用担当者・現場が確認し、求人の実態に合わせます。
候補者個人情報をAIへ入力するかどうかは、媒体規約、契約、個人情報の取り扱い方針を別途確認します。
AIスカウトくんでの検索条件設計
AIスカウトくんは、TechSuite株式会社が提供する、生成AIと採用のプロを組み合わせたスカウト代行サービスです。
求人情報を整理し、MUST・WANT・NG、検索キーワード、候補者選定基準へ落とし込みます。
運用開始後も、候補者母集団、対象率、送付数、返信、選考結果を見ながら、条件を緩和・修正します。
よくある質問
MUST条件はいくつまでにすべきですか？
一律の個数はありません。求人で本当に入社時点から必要か、近接経験で代替できないかを一項目ずつ確認し、必要最小限にします。
歓迎要件はすべてWANTに入れますか？
求人票の歓迎要件でも、候補者検索に使う必要がないものがあります。候補者プロフィールから確認でき、優先順位付けに役立つものだけを使います。
検索結果が多すぎるときはどうしますか？
対象率が低い原因を確認し、求人との適合に寄与する条件を一つずつ追加します。単に候補者数を減らすためだけの条件は入れません。
NG条件は多いほど効率的ですか？
いいえ。除外を増やすほど誤って有望候補者を落とす可能性も高まります。明確な対象外条件に絞り、「好ましくない」程度なら要確認やWANT側で扱います。
AIスカウトくんに関するよくある質問
スカウト代行とRPOの違いは？
違いは支援範囲です。AIスカウトくんはスカウト運用を中心に支援し、TechSuiteでは採用活動全体を支援するRPOサービスの「AI RPOパートナー」も提供しています。
候補者検索から送信まで、すべて任せられる？
はい。AIスカウトくんでは、候補者検索・選定からスカウト文の作成、送信まで対応できます。ただし、プランによっては検索条件の作成や定期的な振り返り・改善支援を含まない場合があります。
スカウト媒体の利用料金は代行費に含まれる？
いいえ。AIスカウトくんの代行費とは別に、利用するスカウト媒体の契約・利用料金が必要です。
新卒採用と中途採用の両方で使える？
はい。AIスカウトくんは新卒採用・中途採用の両方に対応しています。人材紹介会社の候補者スカウト運用にも対応できます。ただし、媒体の利用規約により第三者による代行が認められていない媒体では対応できません。
どのスカウト媒体でも代行できる？
はい。ビズリーチやOpenWorkリクルーティングなど、基本的に各種スカウト媒体で代行できます。ただし、媒体の利用規約により第三者による代行が認められていない媒体では対応できません。利用予定の媒体について、事前に対応可否を確認します。
まとめ｜検索条件は「理想の人物像」ではなく「候補者を見つけるための基準」にする
スカウト検索のMUST・WANT・NGは、求人票をそのままコピーするのではなく、候補者プロフィールから確認できる事実へ変換します。
MUSTを必要最小限にし、WANTを加点材料として残し、NGは明確な対象外条件だけにします。
検索結果件数と対象率を見ながら条件を一項目ずつ調整し、実際の選考結果を検索基準へ戻すことで、候補者を落としすぎず再現性のある検索設計にできます。
この記事に近い導入事例
