スカウト代行 / サポーターズ
サポーターズのプロフィール選定基準の作り方|経験の段階と使用言語で線を引く
サポーターズの選定は、通数に制限がないぶん、誰に送らないかを決めるほうが難しい媒体です。送り放題だからと全員に送ると、返信対応が破綻します。結論を先に書くと、サポーターズの選定は「プログラミング経験を段階で捉える」「使用言語と志向性を組み合わせて線を引く」「契約前にデモプロフィールを見て基準を作る」の三つを型にします。仕様は変わるので、契約する前に公式の案内で確認してください。以下は、2026年9月23日時点で公式サイトに記載されている内容に基づいて整理しています。運用はサポーターズの運用スケジュールと送信計画に、文面はサポーターズのスカウト文面の型にまとめています。
絞り込みの軸は三つ
公式サイトの記載。スカウト・メディアのページのよくある質問には「スカウト時に学生をどこまで絞り込み可能でしょうか?」という問いに対して、「プログラミング経験の有無(授業での経験からリリース経験)や使用言語、志向性等で検索いただく事が可能です」との記載があります。
三つの軸に分けて考えます。
| 軸 | 公式サイトの記載 | 選定での使い方 |
|---|---|---|
| プログラミング経験 | 「有無(授業での経験からリリース経験)」 | 段階として捉える。どこから上を対象にするか |
| 使用言語 | ー | 自社の技術スタックとの距離を測る |
| 志向性 | 「志向性等」 | 作りたいものの方向。技術力だけでは測れない部分 |
経験を段階で捉えます。公式サイトは「授業での経験からリリース経験」と幅を示しています。ここが選定の一段目です。
| 段階 | 目安 | 送るかどうかの考え方 |
|---|---|---|
| 授業での経験 | 講義・演習で書いた | 育成前提の採用なら対象。インターン集客に向く |
| 個人開発の経験 | 自分で作ったものがある | 自主的なアウトプットがある。面談の材料が多い |
| チーム開発の経験 | ハッカソン、サークル、共同制作 | 協働の話ができる。選考で見たい点が広がる |
| リリース経験 | 公開して人に使われている | 運用の話ができる。競合も多い可能性がある |
どこから上を対象にするかを、先に決めます。自社が育成前提なら「授業での経験」から拾う。即戦力に近い人を求めるなら「個人開発以上」に絞る。この線を引かないと、通数無制限の媒体では母数が無限に見えて、判断が止まります。
使用言語は「一致」ではなく「距離」で見ます。自社がGoを使っていて、学生がPythonしか書いていないとき、送らないと決めるのは早計です。新卒では、言語を移れるかどうかのほうが重要になることがあります。実務では、次の三つに分けます。
| 分類 | 扱い |
|---|---|
| 自社と同じ言語の経験がある | 一行目に書ける材料が最も多い。優先 |
| 系統が近い言語の経験がある | 移りやすい前提で書ける。「◯◯を書かれているので△△も入りやすいと思います」 |
| 系統が遠いが、深くやっている | 言語より深さを評価する設計なら対象。文面で理由を書く |
志向性が効きます。同じ技術力でも、作りたいものが違えば合いません。プロダクトを作りたいのか、基盤を作りたいのか、データを扱いたいのか。技術条件だけで絞ると、返信は来ても面談が噛み合わないことがあります。
母集団の性質を知っておく
登録学生について。公式サイトのよくある質問は「どのような学生がサポーターズに登録していますか?」に対して、次のように答えています。
「IT・デジタル関連の職種(エンジニア・データサイエンティスト・ITコンサルタントなど)を志望する学生の中でも、意欲的な学生や、プログラミング経験のある学生が多く登録しています。サポーターズは、技術者を育てる活動として『技育プロジェクト』を運営しています。『技育プロジェクト』では、テックカンファレンス・ハッカソン・技術勉強会等を年間で約150回開催しており、就活生だけでなく、大学1〜2年生も多く参加しています。※例えば、テックカンファレンス『技育祭』には毎回2,000名以上の学生が参加しています。『技育プロジェクト』に参加している意欲的な学生が就活生になったタイミングでサポーターズを利用しているため、意欲や技術力の高い学生が多く登録しています」
エンジニア以外も含まれます。データサイエンティストやITコンサルタントを志望する学生も登録しているとされています。自社が求めているのがどの職種かを、抽出の段階で分ける必要があります。
選ばれる理由として挙げられていること。同サイトは、三つの理由を挙げています。
| 理由 | 公式サイトの記載 |
|---|---|
| 01 国内最大級のエンジニア学生の登録数 | 「エンジニア学生の3人に1人が利用するサービスとなっています。全国の学校のプログラミングサークルとの関係構築などを行なっており…」 |
| 02 ハイスキルなエンジニア学生が多数 | 「技術的な実績や自主的なアウトプットを重視したマッチングを行います。コーディングスキルがあり、問題解決能力に長けたハイスキルなエンジニア学生に直接アプローチできます」(※対象:2026年卒のサポーターズ登録学生) |
| 03 10年以上蓄積した採用ノウハウ | 「10年以上にわたるエンジニア採用の豊富な経験と独自のノウハウを活かし…」 |
「技術的な実績や自主的なアウトプット」を読みます。選定の二段目は、ここです。
| 見るところ | 何を読むか |
|---|---|
| 作ったもの | 何を、なぜ作ったか。課題から始まっているか、チュートリアルの写経か |
| 続いているか | 一度作って終わりか、改善を重ねているか |
| 人に使われているか | 公開しているか、使ってもらった反応があるか |
| チームでの役割 | ハッカソンやサークルで、何を担当したか |
| 学び方 | 何を見て学んだか。独学の進め方に癖が出る |
「上位10%」という基準も示されています。公式サイトは、1on1面談イベントについて「サポーターズ登録学生の中でも上位10%相当のスキルセットを持ったハイスキル学生と1対1で話せる採用サービス」としています。スカウトで狙う層をこの基準と比べておくと、どのサービスを使うべきかの判断材料になります。トップ層だけを狙うなら1on1面談イベント、幅を持って当てるならスカウト、という切り分けです。
エラベルの見解
依頼側から見ると、この媒体の選定で最初にやるべきなのは、契約前にデモプロフィールを見ることです。公式サイトのよくある質問には「契約前でもどんな学生が登録しているか見ることはできますか?」という問いに対して「契約前でも、商談時に登録学生の属性情報やデモプロフィールをご覧いただけます」との記載があります。
ここで基準を作ってから契約します。実際のプロフィールを五つか十見て、「この人には送る」「この人には送らない」を現場のエンジニアと一緒に決める。その場で出た理由を書き留めれば、それが選定基準の原型になります。契約してから基準を作ろうとすると、最初の一か月が試行錯誤で消えます。
そして、現場のエンジニアを一人入れます。人事だけで「作ったものがすごい」を判断するのは難しい。逆に、エンジニアだけだと技術の高さで選んでしまい、育成前提の枠が埋まりません。二人で見て、意見が割れたところを言葉にすると、基準が立体になります。
もう一つ、送らない基準も書くこと。通数が無制限なので、「送らない」を言葉にしておかないと、なんとなく全員に送る運用になります。志向性が明らかに違う、卒業年度が対象外、すでに別の職種で送っている。こうした除外条件を先に書いておくと、選定が速くなります。エラベルでは、依頼側が担当者の経歴を見て選ぶ仕組みなので、契約前の商談にデモプロフィールを見に来る担当者かどうかを、面談で確かめてみてください。
選定の型と、確認すること
型。
| 段階 | やること |
|---|---|
| 0 | 商談時にデモプロフィールを見る。現場のエンジニアと一緒に、送る・送らないを五〜十件で試す |
| 0 | 経験の段階(授業/個人開発/チーム開発/リリース)のどこから対象にするかを決める |
| 0 | 使用言語を三分類(同じ/近い/遠いが深い)に分け、それぞれの扱いを決める |
| 1 | 抽出。プログラミング経験・使用言語・志向性で絞る |
| 1 | 職種を確認(エンジニア/データサイエンティスト/ITコンサルタント等) |
| 2 | 技術的な実績と自主的なアウトプットを読む。三段階で評価 |
| 2 | 評価の理由を一行残す。用途(インターン集客/説明会/面談)を決める |
| 3 | 送信。週の上限は「返せる数」から決める |
評価の三段階を定義します。「評価3=現場エンジニアとの面談を出す」「評価2=説明会やイベントの案内を出す」「評価1=今回は送らない」。用途と紐づけて定義すると、そのまま文面に落ちます。
運営に確認すること。公式サイトに記載のない項目は、契約前に確かめてください。
| 確認すること | なぜ必要か |
|---|---|
| 絞り込み項目の一覧 | 卒業年度、地域、学校区分などがどこまで指定できるか |
| 検索条件の保存 | 毎週同じ条件を使い回せるか |
| 候補者の管理機能 | メモ・ラベル・評価を残せるか。残せなければ自社の表で持つ |
| 送信済みの確認 | 重複送信を防げるか。誰が送ったかを分けられるか |
| 再送の条件 | 時期を変えて同じ学生に送る設計が組めるか |
| アカウント数の上限 | 外注する場合に何人分の枠が要るか |
| 公開募集機能の使い方 | スカウトと募集ページの連動 |
| 運用代行の範囲 | 送付対象学生の提案がどこまで含まれるか |
運用代行との重なりを確かめます。公式サイトは、スカウト・メディアの特徴の三つ目として「イベントページ作成、スカウト送付、ページ改修などスカウトサービス利用にあたっての業務を専任スタッフが代行いたします。送付対象エンジニア学生のご提案なども行いながら、採用成功のために伴走いたします」としています。送付対象の提案が含まれるなら、選定の一部は媒体側で賄えます。どこまで含まれるかを確かめてから、外注範囲を決めます。
記録を残せるかを先に確かめます。媒体側に記録機能がなければ、自社側で表を持ちます。選定の理由が残っていないと、担当者が変わった時点で基準が消えます。媒体を複数使う場合の整理は媒体の組み合わせ方にまとめています。
エラベルの見解
依頼側から見ると、選定を外に出すときの不安は「技術を見られるのか」です。これは正しい心配で、エンジニアの選定は、技術の中身が分からないと判断できません。
ただ、外注先に技術力を求めるのは筋が違います。技術の判断基準は現場のエンジニアが作り、外注先はその基準に沿って機械的に振り分ける。この分担にすれば回ります。基準を作るときに、現場のエンジニアに「この三人の違いを言葉にしてください」と頼むのが、最初の仕事です。
そして、基準は具体例で書きます。「技術力が高い」ではなく、「個人開発で、課題から始まっていて、改善のコミットが続いている」。「向いていない」ではなく、「チュートリアルの写経だけで、自分で決めた部分が見えない」。この対比があると、誰が見ても同じ判断になります。
もう一つ、送らない基準を書くことを条件にします。通数が無制限の媒体では、送信数で仕事をした形にできてしまいます。「なぜ送らなかったか」が記録に残る形にしておくと、選定の質が見えます。エラベルは依頼側が担当者を選べる仕組みなので、送らない判断の記録まで約束できる担当者かどうかを、面談で確かめてみてください。
まとめ
- 絞り込みは「プログラミング経験の有無(授業での経験からリリース経験)や使用言語、志向性等」とされている
- プログラミング経験は段階で捉え、どこから上を対象にするかを先に決める。通数無制限だからこそ、線を引かないと判断が止まる
- 登録学生は「IT・デジタル関連の職種(エンジニア・データサイエンティスト・ITコンサルタントなど)を志望する学生の中でも、意欲的な学生や、プログラミング経験のある学生が多く登録」とされている
- 「単なる母集団形成ではなく、技術的な実績や自主的なアウトプットを重視したマッチングを行います」とされており、作ったものの中身を読むのが選定の二段目
- 契約前でも、商談時に登録学生の属性情報やデモプロフィールを見られるとの記載がある。基準は契約前に作る
- 運用代行に「送付対象エンジニア学生のご提案」が含まれるとされている。外注範囲を決める前に範囲を確認する。仕様は変わるので、公式の案内でご確認ください
よくある質問
未経験の学生も母数に入りますか
サポーターズの公式サイトは、絞り込みについて「プログラミング経験の有無(授業での経験からリリース経験)や使用言語、志向性等で検索いただく事が可能です」としています。「有無」と「授業での経験から」という書き方なので、経験の浅い層も母数に含まれる形です。また、登録学生については「IT・デジタル関連の職種を志望する学生の中でも、意欲的な学生や、プログラミング経験のある学生が多く登録しています」とされています。自社がどの段階から対象にするかを先に決めてから抽出するのが実務です。仕様は変わるので、公式の案内でご確認ください。
契約前に学生の様子を見られますか
公式サイトのよくある質問には「契約前でもどんな学生が登録しているか見ることはできますか?」という問いに対して「契約前でも、商談時に登録学生の属性情報やデモプロフィールをご覧いただけます」との記載があります。実務では、この場に現場のエンジニアを同席させ、実際のプロフィールを見ながら「送る・送らない」を五〜十件試します。その場で出た理由を書き留めると、そのまま選定基準の原型になります。
通数が無制限なら、全員に送ればよいのでは
公式サイトは、スカウト・メディアについて「スカウト送信の通数制限無しで、年間を通じてご利用いただけます」としています。ただし同じページは、特徴の二つ目として「特化型サービスのため、大手ナビ媒体と比べ学生の受け取るスカウト数が限られており、他企業に埋もれてしまう心配もありません」とも述べています。学生が受け取る通数が少ない環境では、一通の印象がそのまま会社の印象になります。また、送信を増やすと返信対応と面談の負荷が上がるため、実務では自社の受け皿(説明会の定員、面談枠、選考の処理能力)から送信数を決めます。