スカウト代行 / paiza転職
paiza転職の検索条件の組み方|母集団を狭めすぎない設計
paiza転職の検索条件は、自分で検索画面を操作して組むものではありません。企業向けページのよくある質問には「ご指定の条件に該当する求職者のリストをpaizaのサポートチームが選定します」とあり、条件は人に伝える形で渡します。そのうえ求人ごとに通過ランクが設定されるので、条件は「求人票のランク」と「サポートチームへの指定」の二重になります。この記事では、最初の条件をどう置き、リストが多すぎるとき・少なすぎるとき・それでも足りないときに何を動かすかを、母集団が尽きるまでの分岐として整理します。以下は2026年9月24日時点で公式サイトおよび掲載中の求人ページに記載されている内容に基づいており、運営はpaiza株式会社です(有料職業紹介事業許可 13-ユ-305439)。
出発点は「必須を短く、ランクは受け入れ方で分ける」
最初の条件で決めるのは、技術の必須要件と、対象にするpaizaランクの二つです。公開されている求人の応募要件は必須要件と歓迎要件に分かれていて、必須は「何らかのシステム開発経験 実務1年以上」のように短く、歓迎に具体的な技術名が並ぶ構成でした。必須に技術名を並べると、言語は違っても構造の近い経験を持つ人が条件から落ちます。必須は「何ができる人か」、歓迎は「何を使ってきた人か」と分けておくのが出発点です。
ランクはプログラミングスキルチェックで判定され、採点は「各問題につき10個のテストケースを入力。負荷試験を実施し、実行速度を測定。また解答速度の観点からもスコアリング」とされ、結果は6段階で評価されます。公式に示されている業務レベルの目安を、条件設計に使う形で並べると次のとおりです。
| 水準 | 問われる内容 | 業務レベルの目安 |
|---|---|---|
| データ出力系の基本的な実装 | 変数・配列・文字列操作・ソートで指示通りに書けるか | 業務システム、Webアプリの運用保守、一部開発 |
| 計算量を意識した効率的なロジック | ツリー構造、探索等のアルゴリズムを組めるか | 業務システム、Webアプリの開発をリード |
| より良いアルゴリズムの設計・実装 | 計算量、メモリの削減を意識した高度なアルゴリズム | 検索エンジン、データ解析、広告配信など |
| 専門領域の研究・開発 | 確率、統計解析、機械学習、グラフィック等 | 各専門領域での即戦力 |
ランクは上げるほど母集団が薄くなります。企業向けページには導入企業の声として、ランクを見れば育成前提で採るのか即戦力として採るのかという方針を考えた上で面接ができる、という記述があります。ランクは足切りの線ではなく、受け入れ方を分ける線として置くと、最初の母集団を狭めずに済みます。
エラベルの見解
スキルが数値化されている媒体では、採用側が安心を求めて基準を上げがちです。上位ランクだけを対象にすれば外れは減りますが、母集団が薄くなった結果、送る相手がいなくなることのほうが多いと考えています。この媒体は求人ごとに通過ランクを設定できるので、同じポジションで上位ランク向けと中位ランク向けの二本を出す設計が取れます。上位向けには裁量の大きい書き方、中位向けには育成前提の書き方にしておくと、どちらの層からも反応を拾え、面接で見るポイントも求人ごとに揃います。一本に絞って基準を上げるのは、母集団が十分にあると確かめてからで構いません。
最初のリストの件数で、動かす条件が分かれる
条件を渡すと、サポートチームからリストが届きます。最初に見るのは、その件数が自社で判定しきれる量かどうかです。多すぎれば条件が緩く、少なすぎれば必須かランクが厳しいと考えられます。どちらの場合も、一度に複数の条件を動かすと何が効いたのかが分からなくなるので、動かすのは一つずつにします。
件数の状態ごとに、最初に動かす条件と、動かさずに残す条件を分けると次のようになります。動かさない列を置いたのは、慌てて条件を触るときに、効いている条件まで崩してしまうのを避けるためです。上の行ほど手軽で、下の行ほど求人の作り方にまで影響が及びます。
| リストの状態 | 最初に動かす条件 | 動かさずに残す条件 |
|---|---|---|
| 判定しきれないほど多い | 歓迎要件の一つを必須に上げる | 対象ランク |
| 適量だが判定で見送りが多い | 条件の言い方(判定できる言葉に直す) | 必須と歓迎の分け方 |
| 少ない | 必須の技術名を歓迎に下げる | 経験年数・領域 |
| 必須を緩めても少ない | 対象ランクを一段下げ、育成前提の求人を分ける | 上位ランク向けの求人 |
表の二行目が、この媒体に固有の分岐です。検索画面を自分で操作する媒体なら条件の数値を変えれば済みますが、ここでは条件を人に伝えているので、言い方が曖昧だとリストがぶれます。件数が適量なのに見送りが多いときは、条件の中身より伝え方を先に疑います。
判定の比率を見て、条件の言い方を直す
条件を判定できる言葉に直すと、リストの精度が上がります。抽象的な表現は、受け取る側によって解釈が変わるからです。直し方の例を挙げます。
- 「自走できるエンジニア」ではなく「要件が固まっていない状態から設計まで担当した経験がある」
- 「モダンな技術に強い方」ではなく「TypeScriptでの実務経験が1年以上、またはReact系の開発経験がある」
- 「カルチャーに合う方」ではなく「少人数チームでの開発経験がある」
直した効果は、リストの判定の比率で確かめます。送信可とした理由と見送った理由を一件ずつ書き出しておき、見送り理由の多いものを次の条件に書き足していく形です。9割以上を送信可にしているなら条件が緩く、3割を切るならリストと条件の認識がずれています。5〜7割あたりに収まっていれば、条件の粒度は適切と見てよいでしょう(公式の基準ではなく、運用の目安です)。
それでも足りないときは、求人の側で母集団を広げる
必須を緩め、ランクを下げ、言い方も直したのにリストが足りないときは、条件の外で母集団を広げます。一つ目は、求人票の特徴タグです。公開されている求人には「若手歓迎」「第二新卒歓迎」「スキルチェンジ(技術転向)歓迎」「オンライン面談可」といったタグが並んでいました。技術転向を受け入れる姿勢を示すタグは、条件を緩めたのと同じ効果を持ちます。
二つ目は、求人票を見て自発的に応募する経路です。求職者には「スキルランクに応じて、応募可能な求人情報をマイページに表示」され、「企業が求めるスキルを満たした求人のみに応募できる」と説明されています。求人票は運営側の取材で作られ、「開発手法」「開発環境」「使用ツール」「評価方法」「上司プロフィール」などを徹底取材しているとされるので、取材に現場のエンジニアが出て中身を厚くするほど、スカウト以外の入口が太くなります。候補者側には事業内容や技術スタックで企業を検索・比較できる企業一覧ページもあり、技術スタックで比べられる前提で情報を整えておきます。
三つ目は、自社で直接アプローチする経路です。企業向けページには、スカウトの送信代行のほか、求職者へスカウトで直接アプローチすることも可能だと書かれています。どこまで自社で検索できるかは公式サイトからは分からないので、次の章の確認項目に入れておきます。
母集団が尽きたかどうかを、自社の数字で見積もる
会員数は85万人とされ、企業向けページには「※2025年3月時点」、別の箇所には「※2024年8月当社調べ」という注記が付いています。登録者はWeb開発(フロント・サーバ)を中心に、エンジニア素養を持ったマネジメント職など幅広いIT人材が登録していると説明されています。ただしランク別の人数や職種別・地域別の内訳は公開されていないので、会員数から自社の母集団を割り出すことはできません。
分からないなりに、打ち合わせで聞く数字と、初月の実績を掛け合わせれば見積もりは作れます。下の表は、何を誰に聞き、どう掛けるかをまとめたものです。初月の実績が出るまでは、比率の欄を仮の値で置いておき、1か月後に差し替えます。
| 見積もりに使う数字 | 出どころ | 使い方 |
|---|---|---|
| 自社条件・ランク別の候補者数 | 打ち合わせで運営に聞く | 母集団の上限として置く |
| リスト提示の頻度と件数 | 打ち合わせで運営に聞く | 月に判定する件数を出す |
| 判定の比率 | 初月の自社の記録 | 候補者数に掛けて送信数を出す |
| 「気になる」の比率 | 初月の反応の実績 | 送信数に掛けて二段目の対象数を出す |
| 同一ポジションで複数求人を出せるか | 打ち合わせで運営に聞く | ランク別に分けたときの上限を足し合わせる |
候補者数に判定の比率を掛けると送れる人数が出て、そこに反応の比率を掛けると「気になる」の見込みが出ます。月ごとのリスト件数でその見込みを割れば、何か月で母集団を一巡するかの目安になります。送信済みの候補者が複数求人で重複する場合の扱いも、あわせて確かめておきます。
もう一点、対応言語は「Java、PHP、Ruby、Python2、Python3、Perl、C、C++、C#、JavaScript、Objective-C、Scala、Go、Swift、Kotlin」です。これ以外の言語を主に使ってきた人は、別の言語で受験している可能性があります。またランクは「現在の評価ルールでは基本的には下がることはありません」とされ、過去に取得したランクがそのまま残ります。
エラベルの見解
返ってくるリストの質は、条件を書いた人が、ランクの言語と実務の言語が一致するとは限らないことや、過去に取ったランクが直近の経験を表すとは限らないことを知っているかどうかで変わります。これを知らずに「Goで上位ランク」と書くと、Goの実務経験があっても別の言語で受験した人が条件から落ちます。そこで私たちは条件を書くとき、ランクは「話を始める材料」として扱い、実務の経験は必須要件の文章の側で指定するよう勧めています。ランクと経験を別の欄に分けて書くと、見送り理由の多くが消えます。文面の設計はpaiza転職のスカウトテンプレートの作り方にまとめています。
まとめ
- paiza転職の条件は、求人票の通過ランクとサポートチームへの指定の二重になる
- 出発点は、必須要件を短くし、ランクは足切りではなく受け入れ方を分ける線として置くこと
- リストの件数と判定の比率を見て、動かす条件を一つずつ選ぶ
- 条件を緩めても足りないときは、特徴タグ・求人票経由の応募・直接アプローチで入口を広げる
- 母集団の大きさは公開されていないので、運営に聞く数字と初月の実績を掛けて見積もる
よくある質問
Q. paiza転職では検索画面で条件を入力しますか
公式のよくある質問では、指定した条件に該当する求職者のリストをサポートチームが選定し、企業がリストを確認して送信の可否を判断する流れが説明されています。条件は人に伝える形になるので、判定できる言葉で書くことが大切です。自社でどこまで直接検索できるかは、打ち合わせで運営にご確認ください。
Q. 通過ランクは高く設定したほうがよいですか
ランクを上げるほど母集団は薄くなります。同じポジションでも、上位ランク向けと中位ランク向けで求人を分けると、母集団を絞らずに期待する役割を揃えられます。複数求人を出せるかどうかは運営に確かめてください。
Q. 自社の条件で何人の候補者がいるか、事前に分かりますか
会員数は公開されていますが、ランク別・職種別・地域別の内訳は公開されていません。打ち合わせで自社条件での候補者数を聞き、初月の判定の比率と反応の比率を掛けると、見込みの目安が出ます。料金・通数・機能の条件は変わるため、掲載した内容は2026年9月24日時点の記載として、最新の条件は運営にご確認ください。