ナレッジベース

paizaは、候補者が実際に解いたプログラミング問題からコーディング能力を可視化するエンジニア向けの採用サービスです。職務経歴からスキルを推測するのではなく、実装力を事前に確認したうえで面接に進める点が他媒体との違いになります。

この記事では、成功報酬型の料金体系や主な機能に加え、paizaランクの見方と採用基準の設計、提出コードを活かした選考の進め方まで、企業の採用担当者向けに実践的なポイントをまとめています。

paizaとは？

paizaは、paiza株式会社が運営するITエンジニア向けの転職・就職サービスです。最大の特徴は、候補者が実際にプログラミング問題を解いた結果をもとに、コーディング能力がランクとして可視化されている点にあります。

「実際にコードを書いた結果」が採用前に分かる

一般的な採用媒体では、候補者の技術力は職務経歴書の記載から推測するしかありません。「Python経験3年」と書かれていても、どの程度書けるのかは面接や技術試験を経なければ分かりません。

paizaでは「paizaスキルチェック」によって候補者のコーディング能力がランク・レーティングとして表示されます。

一般的な媒体	paiza
職務経歴から技術力を推測する	経歴＋ランク＋提出コードで確認できる
面接や技術試験で初めて実力が分かる	一定の実装力を事前に把握できる
面接時間の一部を基礎確認に使う	面接では一段深い議論に時間を使える

導入企業の事例では、従来は履歴書上の経験と実際のスキルにギャップが生じることが課題でした。paiza導入後はスキルレベルを事前に把握できるため、面接ではより具体的なプロジェクトや技術の議論に時間を使えるようになり、半年で3名の内定につながっています。

求人応募の約7割がスカウト経由

paizaはスキルチェック型の媒体であるため、「求人を掲載すれば高ランク層から応募が来る」と考えられがちです。

しかしpaiza公式の採用ガイドでは、paiza内の求人応募の約7割がスカウト経由と説明されています。

転職潜在層は求人検索を頻繁に行わないため、企業側から求人の存在を伝える必要があります。掲載して待つのではなく、求人の作成とスカウトの運用をセットで進めることが前提になります。

スカウト運用にサポートが介在する

paizaのスカウト運用は、他のエンジニア向け媒体と進め方が異なります。

企業が採用条件を指定する
↓
paizaのサポートチームが候補者リストを選定する
↓
企業が送信の可否を判断する
↓
対象候補者へスカウトを送信する
↓
候補者から「話を聞いてみたい」または「気になる！」が返る
↓
特に会いたい候補者へプラチナスカウトを送る

人事が毎日候補者を検索して発掘し、すべての文面を自社で作成するという媒体とは異なり、paiza側の採用チームを活用しながら、企業は「誰に会いたいか」の判断精度を高めるという運用ができます。

採用担当者にエンジニア経験がなくても運用しやすい

GitHubやOSS活動、技術記事から候補者を判断する媒体では、人事側にも一定の技術理解が求められます。

paizaでは実際にコードを書いた結果がランク化されているため、技術採用に詳しくない採用担当者でも初期判断を行いやすくなります。導入企業のなかにも、「採用担当にエンジニア経験がなく、書類だけではスキルを判断できない」という課題からpaizaを活用している企業があります。

よくある質問

Q：paizaは新卒採用にも使えますか？
A：使えます。中途採用向けのpaiza転職に加え、新卒向けのサービスも展開されています。導入企業のなかには、paizaランクを基準に会う候補者を決めることで、新卒エンジニアの採用数を年間2〜3名から二桁へ拡大した事例もあります。

Q：paizaランクが高い候補者を採用すれば失敗しませんか？
A：ランクが測っているのは基本的にコーディング能力です。設計力、プロダクト思考、コミュニケーション、要件定義、チーム開発といった実務で必要な要素は含まれません。ランクは技術面の一次シグナルとして扱い、実務経験は職歴、ビジネススキルや人物面は面接で確認するという役割分担が必要です。

paizaの特徴と登録者層

paizaを活用するには、どのような層が登録しているのか、そして技術力がどう可視化されているのかを理解しておく必要があります。

登録者層のイメージ

項目	内容
会員規模	85万人規模とされています
対象	ITエンジニアおよびエンジニア志望者
経験レベル	学生・未経験層から即戦力層まで幅広い
志向	プログラミングが好き、技術を伸ばしたいという層との相性が良い
対応区分	新卒採用と中途採用の両方

学生や未経験に近い層から経験豊富なエンジニアまで幅広く登録しているため、育成前提の採用と即戦力採用の両方に対応できます。

導入企業からは、paizaのユーザーは「プログラミングが好き」「技術を伸ばしたい」という志向を持つ層との相性が良いという声が出ています。

paizaの5つの特徴

コーディング能力がランクとして可視化されている

paizaスキルチェックによって、候補者の実装力がランクとレーティングで表示されます。職務経歴書の記載だけでは分からない実力を、採用の判断材料として使えます。

提出コードを確認できる

ランクという数値だけでなく、候補者が実際に提出したコードを技術判断の材料として確認できます。

導入企業のなかには、候補者のコードを見ることで「どの程度の技術レベルなのか」「どのような考え方をするのか」まで確認できると評価している企業があります。

候補者から「気になる！」が届く

候補者は求人に対して「気になる！」を押し、企業へ興味を伝えられます。企業側はその候補者を確認し、特に会いたい人へプラチナスカウトを送れます。

企業側からのアプローチだけでなく、候補者側から興味が示される導線がある点が特徴です。

スカウト運用にサポートが介在する

paizaのサポートチームが採用条件をもとに候補者リストを選定し、企業がその送信可否を判断する流れです。候補者の検索から文面作成までをすべて自社で行う必要はありません。

新卒と中途の両方に対応している

中途採用向けのpaiza転職に加え、新卒向けのサービスも展開されています。エンジニア採用を新卒と中途の両輪で進めたい企業にとっては、同じ基準で技術力を確認できる点がメリットになります。

paizaランクが測っているもの

paizaランクが可視化しているのは、基本的にプログラミング・コーディング能力です。

ランクに含まれない要素

• 設計力
• プロダクト思考
• コミュニケーション能力
• マネジメント経験
• 要件定義の能力
• 顧客理解
• チーム開発の経験
• 事業理解

導入企業のなかには、採用時に見る比重を技術的スキル30%、ビジネススキル40%、個性30%程度と説明し、paizaを技術部分を確認するための判断材料として使っている企業があります。

役割分担の考え方

判断要素	確認する手段
コーディング能力	paizaランク・提出コード
実務経験	職務経歴
ビジネススキル・人物・カルチャー	面接

「Aランク以上だから採用」という判断ではなく、ランクを一次シグナルとして位置づけたうえで、他の要素は別の手段で確認する設計が必要です。

よくある質問

Q：paizaのユーザーはスキルの高い層に偏っていますか？
A：偏っていません。学生や未経験に近い層から即戦力層まで幅広く登録しています。そのため即戦力採用だけでなく、ポテンシャルを重視した若手採用にも対応できます。採用したい層に応じて、求めるランクの基準を変える運用が有効です。

Q：登録者数だけで導入を判断してよいですか？
A：判断しないほうが安全です。会員数の規模ではなく、自社の採用要件に該当する候補者が何名いるかを確認してください。「Goのシニアを3名採用したい」のであれば、言語・経験年数・希望勤務地・希望年収・ランクまで条件に入れたうえで、実際にアプローチできる人数を商談時に確認することを勧めます。

paizaの主な機能

paizaには、技術力を可視化したうえで候補者へアプローチするための機能が揃っています。

paizaスキルチェック

候補者がプログラミング問題を解き、その結果からコーディング能力をランクとレーティングで可視化する仕組みです。

企業側はこのランクを、候補者の技術水準を判断する一次シグナルとして利用します。

提出コードの確認

ランクという数値だけでなく、候補者が提出したコードそのものを確認できます。

コードから分かること

• 実装の進め方
• データ構造や処理の選択
• コードの読みやすさ
• 問題へのアプローチの仕方

技術面接の材料としても活用でき、「この実装でこのデータ構造を選んだ理由は何ですか」といった具体的な質問につなげられます。

求人票

採用したいポジションを掲載します。候補者は自分のランクで応募可能かどうかと、自分がやりたい仕事かどうかの両方を判断するため、ポジションごとに分けて作成することが推奨されています。

候補者検索

ランク、使用言語、経験年数、希望勤務地、希望年収などの条件で候補者を絞り込めます。

「気になる！」

候補者が求人に対して興味を示す機能です。企業側はこの候補者を確認し、特に会いたい人へアプローチできます。

候補者の種類	状態
検索で見つけた候補者	自社への興味は不明
「気になる！」を押した候補者	求人を見たうえで興味を示している

自社に関心を示している候補者を優先することで、アプローチの効率が上がります。

3種類のスカウト

paizaには複数のスカウトが用意されています。

種類	特徴	使いどころ
通常スカウト	標準的なスカウト	可能性のある候補者へ広く
ゴールデンスカウト	送信数に制限がある	要件との一致度が高い候補者へ
プラチナスカウト	「気になる！」を押した候補者へ送る	相互に興味がある状態の候補者へ

公式では、プラチナスカウトは企業と候補者が互いに興味を持っている状態からスタートするため、通常より内定につながりやすいと説明されています。

送信通数を均等に使うのではなく、候補者の温度に応じて使い分けることが重要です。

サポートチームによる候補者選定

paizaのサポートチームが、企業が指定した採用条件をもとに候補者リストを選定します。企業側はその送信可否を判断する形です。

候補者の検索から文面作成までをすべて自社で行う必要がないため、採用担当者のリソースが限られている企業でも運用しやすい設計になっています。

新卒向けのサービスとイベント

中途採用に加えて新卒採用にも対応しています。1on1形式のイベントや自社イベントを通じて、早期の学生層と接点を持つ運用が可能です。

導入企業のなかには、1dayインターンから約140名を集め12名の承諾につなげた事例や、就業型インターンから採用につなげている事例があります。

よくある質問

Q：スカウトの3種類はどう使い分けますか？
A：候補者の温度と優先度で分けます。「気になる！」を押している候補者にはプラチナスカウト、要件との一致度が高く優先度の高い候補者にはゴールデンスカウト、可能性のある候補者には通常スカウトという配分が基本です。送信数に制限のあるスカウトほど、対象を絞って使ってください。

Q：サポートチームに任せれば運用は不要ですか？
A：候補者リストの選定は支援を受けられますが、送信の可否判断、スカウト文の内容、面談での対応は自社で行います。またリストの精度を上げるには、自社の採用条件を明確に伝える必要があります。丸投げではなく、判断精度を高める役割分担として捉えてください。

paizaのメリット・デメリット

技術力を事前に可視化できる点が最大の強みですが、その数値の扱い方を誤ると採用の判断を見誤ります。

メリット

技術力を事前に把握できる

職務経歴書の記載と実際のスキルにギャップが生じるという課題を、スキルチェックの結果によって解消できます。面接前に一定の実装力を確認できるため、面接では基礎的な確認ではなく具体的なプロジェクトや技術の議論に時間を使えます。

提出コードを面接の材料にできる

ランクという数値だけでなく、候補者が書いたコードそのものを確認できます。「なぜこの実装を選んだのか」「データ量が増えたらどう変えるか」といった深い質問につなげられるため、技術面接の質が上がります。

エンジニア経験のない採用担当者でも初期判断ができる

GitHubやOSS活動から技術力を読み解く必要がある媒体と異なり、コーディングの結果がランク化されています。人事が「まず会うべき候補者」を判断しやすくなります。

運用工数を抑えられる

paizaのサポートチームが候補者リストを選定するため、検索から文面作成までをすべて自社で行う必要がありません。採用担当者のリソースが限られている企業でも運用しやすい設計です。

温度の高い候補者を特定できる

「気になる！」を押した候補者は、求人を見たうえで興味を示している状態です。この層を優先することで、アプローチの効率が上がります。

新卒と中途の両方に対応できる

同じ基準で技術力を確認しながら、新卒採用と中途採用を並行して進められます。

育成採用と即戦力採用を分けて設計できる

事前にスキルが分かるため、育成前提で採用するのか即戦力として採用するのかを面接前に判断できます。導入企業のなかにも、この使い方をしている企業があります。

デメリット

ランクは総合力を測るものではない

paizaランクが可視化しているのはコーディング能力です。設計力、プロダクト思考、コミュニケーション、マネジメント、要件定義、チーム開発といった実務で必要な要素は含まれません。

ランクで絞りすぎると母集団が急減する

「即戦力だからAランク以上のみ」と厳密に絞ると、対象となる候補者がほとんどいなくなる可能性があります。paiza自身も、候補者が見つからない場合には求人要件そのものを見直すことを推奨しています。

掲載して待つだけでは応募が集まりにくい

求人応募の約7割がスカウト経由とされています。スキルチェック型の媒体であっても、企業側からのアプローチが前提になります。

エンジニア以外の採用には使えない

ITエンジニアに特化した媒体です。

現場エンジニアの関与が必要になる

提出コードの確認や技術的な深掘りは、現場エンジニアでなければ判断できません。人事だけで完結する媒体ではありません。

高スキル層を採るには自社の環境も問われる

高いランクの候補者を検索できたとしても、その層が働きたいと思う環境がなければ採用にはつながりません。導入企業のなかには、優秀なエンジニアを採用するために子会社を設立し、副業可・裁量労働・フルリモート・アジャイル開発といった働く環境そのものを変えた企業もあります。

メリット・デメリットの整理

観点	メリット	デメリット
技術判断	事前に実装力を把握できる	ランクは総合力を示さない
候補者選定	人事でも初期判断ができる	ランクで絞りすぎると母集団が減る
運用	サポートが候補者を選定する	スカウトの運用は前提になる
選考	提出コードを面接材料にできる	現場エンジニアの関与が必要
母集団	新卒から即戦力まで幅広い	エンジニア以外は対象外

よくある質問

Q：ランクの基準はどう設定すべきですか？
A：ポジションによって変えてください。若手や第二新卒であれば一定水準のランクを基準にしつつ学習意欲や伸びしろを重視し、ミドル層であれば高いランクと実務経験の両方、シニア層であればランクに加えて設計や技術選定の経験まで確認するという設計が有効です。すべてのポジションで共通の基準を置く必要はありません。

Q：ランクが低くても採用すべき候補者はいますか？
A：います。導入企業のなかには、理想とする技術スタックの経験がない候補者でも、キャッチアップの意欲があれば面接している企業があります。同社は現在の技術だけでなく、新しい技術を学び続けられるかを重視しています。必須条件を「一定以上のコーディング力」、歓迎条件を「自社と一致する言語やフレームワークの経験」と分ける考え方が有効です。

paizaの料金体系

paizaは成功報酬型の料金体系です。初期費用や掲載費用が発生せず、採用が決定するまで費用はかかりません。

料金の基本構造

費目	内容
初期費用	発生しない
掲載費用	発生しない
スカウトの送信	費用は発生しない
成功報酬	採用決定時に発生

求人を掲載してもスカウトを送っても、採用に至らなければ費用は発生しません。導入時のリスクを抑えて始められる構造です。

中途採用（paiza転職）の成功報酬

採用した人材の年収の25%程度が成功報酬として設定されています。

費用のシミュレーション

入社者の年収	成功報酬の目安
500万円	125万円
600万円	150万円
800万円	200万円
1,000万円	250万円

年収に連動する構造であるため、高年収のポジションほど1名あたりの費用も上がります。

新卒採用（paiza新卒）の成功報酬

新卒採用の成功報酬は40万円からとされ、採用した候補者のスキルランクに応じて変動します。

技術力の高い候補者ほど報酬が上がる設計であるため、どの水準の学生を採用するかによって費用が変わります。

他の採用手法との比較

年収800万円のエンジニアを採用した場合の比較です。

採用手法	料金構造	1名あたりの目安
paiza	成功報酬25%	200万円
人材紹介	完全成功報酬30〜35%	240万〜280万円
Forkwell Jobs	基本利用料＋成功報酬25%	基本利用料＋200万円
LAPRAS（JOB BOARD）	成功報酬15%程度	120万円
Green	職種別の定額成功報酬	120万円程度＋初期費用

人材紹介と比べると料率は抑えられていますが、固定費型の媒体と比べると採用人数が増えるほど総額は膨らみます。

採用単価の考え方

固定費が発生しない代わりに、成功報酬が採用人数に比例します。

採用人数	総額（年収800万円の場合）	1名あたりの単価
1名	200万円	200万円
3名	600万円	200万円
5名	1,000万円	200万円

採用人数が増えても1名あたりの単価は下がりません。複数名の採用を計画している場合は、月額固定型の媒体と総額を比較したうえで判断してください。

一方で、採用が決まらなければ費用が発生しないため、採用の確度が読めない段階ではリスクを抑えられる構造です。

運用工数も含めて評価する

費用が発生しない期間があるとはいえ、運用にかかる人件費は実質的なコストです。paizaでは特に次の工数が発生します。

• 求人票の作成と改善
• スカウトの送信可否の判断
• スカウト文の作成
• 提出コードの確認（現場エンジニア）
• カジュアル面談の実施

候補者リストの選定についてはサポートを受けられるため、他のエンジニア向け媒体と比べると検索にかかる工数は抑えられます。

よくある質問

Q：採用に至らなければ本当に費用はかかりませんか？
A：初期費用と掲載費用が発生しない成功報酬型です。ただし契約内容によって条件が異なる可能性があるため、返金規定や早期退職時の扱いも含めて契約前に確認してください。

Q：新卒の成功報酬がランクによって変動するのはなぜですか？
A：paizaでは候補者の技術力がランクとして可視化されているため、そのランクに応じて報酬が設定される仕組みです。高いランクの学生を採用するほど費用は上がりますが、技術力を事前に確認したうえで採用できる点とあわせて評価してください。

paizaが向いている企業・向いていない企業

技術力を事前に可視化できる媒体であるため、何を採用の判断軸に置くかによって適性が分かれます。

向いている企業

コーディング力を重視するエンジニア採用をしたい企業

実際にコードを書いた結果を採用の判断材料にできます。実装力を重視するポジションとの相性が良い媒体です。

採用担当者にエンジニア経験がない企業

ランクによって技術水準の目安を把握できるため、書類だけでは技術力を判断できないという課題を解消できます。導入企業のなかにも、この課題からpaizaを活用している企業があります。

面接前に技術力を把握したい企業

履歴書上の経験と実際のスキルにギャップが生じるという課題に対応できます。面接では基礎的な確認ではなく、具体的なプロジェクトや技術の議論に時間を使えるようになります。

新卒と中途を並行して採用したい企業

中途向けのpaiza転職と新卒向けのサービスの両方が提供されています。同じ基準で技術力を確認しながら、両方の採用を進められます。

育成前提の採用も視野に入れている企業

事前にスキルが分かるため、育成前提で採用するのか即戦力として採用するのかを面接前に判断できます。学生や未経験に近い層も登録しているため、ポテンシャル採用にも対応できます。

採用の確度が読めない段階の企業

成功報酬型で初期費用と掲載費用が発生しません。採用に至らなければ費用が発生しないため、まず市場の反応を見たい段階でも着手しやすい構造です。

現場エンジニアがコードを確認できる企業

提出コードを技術判断の材料として使えます。現場が確認できる体制があるほど、この媒体の強みを活かせます。

向いていない企業

エンジニア以外の職種を採用したい企業

ITエンジニアに特化した媒体です。

大量採用を計画している企業

成功報酬が採用人数に比例するため、採用人数が増えるほど総額が膨らみます。固定費型の媒体との比較が必要です。

ランクだけで採用を判断したい企業

ランクが測っているのはコーディング能力です。設計力、プロダクト思考、コミュニケーション、マネジメントといった要素は含まれません。ランクを絶対的な基準にすると、実務での活躍とずれた採用になります。

求人を掲載して待ちたい企業

求人応募の約7割がスカウト経由とされています。企業側からのアプローチが前提であり、掲載だけでは応募が集まりにくい媒体です。

現場エンジニアを巻き込めない企業

提出コードの確認や技術的な深掘りは現場でなければ判断できません。人事だけで完結させようとすると、ランクに依存した判断になります。

高スキル層を求めるが働く環境を整えられない企業

ランクの高い候補者を検索できても、その層が働きたいと思う環境がなければ採用にはつながりません。導入企業のなかには、優秀なエンジニアを採用するために子会社を設立し、副業可・裁量労働・フルリモート・アジャイル開発といった働く環境そのものを変えた企業もあります。

設計やマネジメント経験を最重視する採用

コーディング能力が可視化される媒体であるため、アーキテクチャの設計経験や組織マネジメントの経験を主軸に評価したい採用では、他の判断材料が必要になります。

導入前のチェックリスト

確認項目	判断のポイント
採用職種	ITエンジニアか
判断軸	コーディング力を重視するポジションか
採用人数	成功報酬の総額が予算内に収まるか
現場の協力	提出コードを確認できるエンジニアがいるか
運用体制	スカウトの送信判断と面談を行えるか
働く環境	求める水準の候補者が魅力を感じる環境があるか
該当候補者数	自社の条件でアプローチできる人数を確認したか

特に「該当候補者数」は、導入前に必ず確認しておきたい項目です。会員数の規模ではなく、言語・経験年数・希望勤務地・希望年収・ランクまで条件に入れたうえで、実際に何名へアプローチできるかを商談時に確認してください。

よくある質問

Q：他のエンジニア向け媒体との使い分けはどう考えればよいですか？
A：判断軸で分けるのが分かりやすくなります。実装力を重視するならpaiza、GitHubなどの公開アウトプットから技術力を読みたいならFindyやLAPRAS、志向性や働き方のマッチを重視するならForkwellというように、何を材料に候補者を判断したいかで選択してください。採用担当者にエンジニア経験がない場合は、paizaのほうが初期判断を行いやすくなります。

Q：知名度のない企業でも採用できますか？
A：可能です。paizaのユーザーは技術を伸ばしたいという志向を持つ層が多く、開発環境や任せられる仕事の内容を重視する傾向があります。求人票で技術スタックや開発体制、キャリアパスを具体的に伝えられれば、知名度に関わらず関心を得られます。

paizaランクの見方と採用基準の設計

paizaを使いこなせるかどうかは、ランクをどう扱うかで決まります。足切りの基準にするのではなく、判断の一部として位置づける設計が必要です。

ランクを「面接する人を決める基準」として使う

ランクの効果的な使い方は、採用の可否を決めることではなく、まず会うべき候補者を決めることです。

導入企業のなかには、新卒採用で「Bランク以上なら会う」という基準を設定した企業があります。同社はpaiza導入前は年間2〜3名程度だった新卒エンジニアの採用が、導入後は二桁採用へ拡大したとしています。

従来の進め方との違い

従来：履歴書を1枚ずつ読んで技術力を推測する

↓

paiza：ランク・プロフィール・スキルPR・希望条件から「会うべき人」を決める

特にエンジニア経験のない採用担当者にとって、この判断基準を持てることの意味は大きくなります。

ランクで絞りすぎない

「即戦力を採用したいのでAランク以上のみ」と厳密に絞ると、対象となる候補者がほとんどいなくなる可能性があります。

paiza自身も、スカウト条件を厳しくしすぎると対象候補者がほとんどいなくなるため、候補者が見つからない場合には求人要件そのものを見直すことを推奨しています。

要件の分け方

分類	内容
必須条件	一定以上のコーディング力
歓迎条件	自社と完全に一致する言語・フレームワークの経験

導入企業のなかには、理想とする技術スタックの経験がない候補者でも、キャッチアップの意欲があれば面接している企業があります。同社は現在の技術だけでなく、新しい技術を学び続けられるかを重視しています。

育成採用と即戦力採用でランクの基準を変える

すべてのポジションで共通のランク基準を置く必要はありません。

対象	ランクの扱い	重視する要素
若手・第二新卒	一定水準を満たしていればよい	学習意欲・伸びしろ
ミドル	高いランク＋実務経験	即戦力性
シニア	ランクに加えて設計・技術選定の経験	技術リーダーとしての能力

導入企業のなかには、事前にスキルが分かるため育成前提で採るのか即戦力として採るのかを面接前に判断できる、という使い方をしている企業があります。

採用したい層に応じて、ランクの位置づけを変えてください。

ランクだけで技術力の評価を完結させない

paizaではコーディング能力が数値になるため、技術力の評価がランクだけで完結しやすくなります。

導入企業のなかには、現在の技術力以上に次の要素を重視している企業があります。

• 技術への情熱
• 新しいものを学べるか
• 自社で本当にやりたいと思っているか

高いランクを持ちながら学習意欲が低い候補者より、一定のランクで学習意欲が高い候補者のほうが、長期的に活躍するケースもあります。特に新卒や若手の採用では、この観点が重要になります。

判断要素の役割分担

判断したい内容	確認する手段
コーディング能力	paizaランク
実装の考え方	提出コード
実務経験	職務経歴
設計力・技術選定の経験	面接での深掘り
ビジネススキル・人物・カルチャー	面接・カジュアル面談
学習意欲・志向	面談での対話

導入企業のなかには、採用時に見る比重を技術的スキル30%、ビジネススキル40%、個性30%程度と説明している企業があります。paizaはあくまで技術部分を確認するための判断材料です。

よくある質問

Q：ランクの基準はどのように決めればよいですか？
A：現場エンジニアと相談して、ポジションごとに設定してください。まず「このランクなら実務で問題なく実装できる」という水準を現場に確認し、それを面接の基準にします。ただし基準を決めた後も、その条件で該当する候補者が何名いるかを確認し、母集団が少なすぎる場合は要件の見直しを検討してください。

Q：ランクが表示されていない候補者はどう扱えばよいですか？
A：スキルチェックを受けていない候補者については、職務経歴や本人の記載内容から判断することになります。ただしpaizaの強みは技術力の事前可視化にあるため、ランクのある候補者を優先するほうがこの媒体の特性を活かせます。

paizaの求人票の作り方

paizaの求人票では、候補者が「自分のランクで応募できるか」と「自分がやりたい仕事か」の両方を判断します。この2点が伝わる構成にすることが前提になります。

求人はポジションごとに分ける

paizaの求人票ノウハウでも強調されている点です。

避けたい求人

• フロントエンドもバックエンドもリーダーも1つの求人にまとめる
• 給与を300万〜900万円のように広いレンジで設定する
• 「経験に応じて仕事をお任せします」と記載する

推奨される分け方

求人の単位	対象
CTO・技術責任者	技術組織を統括する層
テックリード	技術的な意思決定を担う層
バックエンドエンジニア	サーバーサイドの実装を担う層
フロントエンドエンジニア	クライアントサイドの実装を担う層
アプリエンジニア	モバイル開発を担う層
若手メンバー	育成前提で採用する層

仕事内容とレイヤーごとに分けることで、候補者は自分向けの求人かどうかを判断できます。

年収レンジを広く設定すると、上位層からは物足りなく、下位層からは届かない求人になります。ポジションごとに現実的なレンジへ絞り込んでください。

技術スタックだけでなく開発環境まで書く

エンジニアが転職時に見ているのは使用言語だけではありません。paiza公式も、求人票やスカウトで開発チーム、仕事の進め方、働き方、キャリアパスまで具体的に伝えることを推奨しています。

避けたい記載

「Rubyを使います」

推奨される記載

• Ruby / Rails
• AWS
• GitHub Actions
• コードレビュー必須
• 2週間スプリント
• プロダクトマネージャー・デザイナーとのスクラム開発
• 技術選定はチーム単位で実施
• 週4日リモート

paizaのユーザーには「プログラミングが好き」「技術を伸ばしたい」という志向を持つ層が多いため、入社後にエンジニアとしてどう働けるのかの具体性が判断材料になります。

記載したい項目

カテゴリ	内容
技術スタック	言語・フレームワーク・インフラ・データベース
開発体制	チーム構成・役割分担
開発プロセス	スプリント・レビュー・リリースの進め方
技術選定	誰がどこまで決められるか
働き方	リモートの可否・裁量労働の有無
キャリアパス	入社後にどのようなキャリアを描けるか
年収	ポジションに応じた現実的なレンジ

高スキル層を採用するなら環境も整える

求人票の作り方以前の話として、求める水準の候補者が働きたいと思う環境があるかどうかが問われます。

導入企業のなかには、優秀なエンジニアを採用するために従来の組織のまま採用しようとせず、エンジニア向けの子会社を設立した企業があります。

整えた環境

• 副業可
• カジュアルな服装
• 実力に応じた年俸
• 裁量労働
• フルリモート
• アジャイル開発

高ランクの候補者を検索できることと、その層を採用できることは別の問題です。 求人票に書ける内容を増やすには、実際の環境を変える必要があるケースもあります。

よくある質問

Q：求人はいくつまで作るべきですか？
A：実際に採用を進めるポジションごとに作成してください。ただし求人が増えるほど管理工数も増えるため、優先度の高いポジションから順に分けていく進め方が現実的です。1つの求人に複数のポジションをまとめている状態があれば、まずそこから見直してください。

Q：年収レンジはどこまで具体的に書くべきですか？
A：ポジションに応じた現実的なレンジを提示してください。候補者は自分の経験とランクで応募できるかを判断します。レンジが広すぎると、どの水準で採用されるのかが分からず、検討の土台に乗りません。経験レベルごとに求人を分け、それぞれで適切なレンジを示すほうが判断しやすくなります。

paizaのスカウトの運用と書き方

paizaでは求人応募の約7割がスカウト経由とされています。スキルチェック型の媒体であっても、掲載して待つ運用では成果につながりません。

スカウト運用の流れ

paizaのスカウト運用には、サポートチームが介在します。

企業が採用条件を指定する
↓
paizaのサポートチームが候補者リストを選定する
↓
企業が送信の可否を判断する
↓
対象候補者へスカウトを送信する
↓
候補者から「話を聞いてみたい」または「気になる！」が返る
↓
特に会いたい候補者へプラチナスカウトを送る

候補者の検索から文面作成までをすべて自社で行う媒体とは異なり、企業側は「誰に会いたいか」の判断精度を高めることに集中できます。

ただしリストの精度はこちらが伝える採用条件に依存します。条件を曖昧なまま渡すと、送信可否の判断に時間がかかります。

「気になる！」候補者を優先する

候補者が求人に「気になる！」を押している場合、その候補者は求人を見たうえで一定の興味を示している状態です。

候補者の種類	状態
検索・リストから抽出した候補者	自社への興味は不明
「気になる！」を押した候補者	求人を見たうえで興味を示している

公式でも、プラチナスカウトは企業と候補者が互いに興味を持っている状態からスタートするため、通常より内定につながりやすいと説明されています。

候補者の分類とスカウトの使い分け

ランク	候補者の状態	送るスカウト
A	「気になる！」があり、ランクと経歴も合致	プラチナスカウト
B	ランクと経歴が合致している	ゴールデンスカウトまたは通常スカウト
C	可能性がある	通常スカウト

送信通数を均等に使うのではなく、候補者の温度に応じて配分してください。送信数に制限のあるスカウトほど、対象を絞って使います。

スカウトで会社説明を長く書かない

paiza自身が、反応の悪いスカウトとして次のパターンを挙げています。

• 会社説明や製品説明が長い
• 仕事内容の説明が少ない

反応の良いスカウトに含まれる要素

要素	内容
仕事内容	どのような仕事をするのか
開発環境	どのような技術・体制で開発するのか
働き方	リモートの可否・裁量の範囲
キャリア	入社後にどのようなキャリアがあるか

避けたい書き方

「当社は2005年に創業し、〇〇業界でシェアNo.1を獲得しており」

推奨される書き方

「現在PHPからGoへの段階的な移行を進めています。入社後はバックエンドの設計と実装に加え、技術選定にも参加いただく予定です」

エンジニアにとっては、企業の沿革より入社後に何をするのかのほうが判断材料になります。

スカウトの対象と求人内容をズラさない

paiza公式が明確に注意している点です。

Java経験を希望している候補者にRubyの求人を送れば、「なぜ自分に送ってきたのか」という疑問につながり、企業への不信感を生みます。

確認すべき3つの軸

軸	確認する内容
ランク	技術水準が求人の要件に合っているか
経験	業務内容とフィットするか
希望条件	候補者側の希望と合っているか

「ランクが高いから何でも送る」という運用は避けてください。paizaではスキルが可視化されているからこそ、その人に合っていないスカウトが目立ちます。

よくある質問

Q：スカウトの反応が悪い場合、まず何を見直すべきですか？
A：送信対象と求人内容の一致を確認してください。候補者の希望する言語や条件と求人がずれていれば、文面を改善しても反応は得られません。あわせて、スカウト本文が会社説明に偏っていないか、仕事内容と開発環境が書かれているかを確認してください。

Q：サポートから提案されたリストはそのまま送ってよいですか？
A：送信可否は自社で判断してください。リストの精度は伝えた採用条件に依存するため、ずれがあれば条件をすり合わせる必要があります。また候補者の希望条件と自社の求人が合っているかは、送信前に確認しておくことでミスマッチを防げます。

提出コードを活かした選考・面談の設計

paizaでは候補者が提出したコードを確認できます。これを技術面接の材料として使うことで、面接の質が大きく変わります。

提出コードを技術面接の共通資料にする

ランクという数値だけを見るのではなく、実際のコードを確認します。

導入企業のなかには、候補者のコードを見ることで「どの程度の技術レベルなのか」「どのような考え方をするのか」まで確認できると評価している企業があります。

コードをもとにした質問の例

• この実装でこのデータ構造を選んだ理由は何ですか
• データ量が10倍になった場合、どう変えますか
• 実務であれば、エラーハンドリングをどのように追加しますか
• 他にどのような実装方法が考えられますか

コーディングテストの点数を確認するのではなく、候補者自身が書いたコードを共通の材料として技術的な対話を行うという使い方です。

これにより、抽象的な質問では見えにくい設計の考え方や実務での判断力を確認できます。

カジュアル面談を技術試験にしすぎない

2026年のpaizaの調査では、ITエンジニアを採用する企業の7割以上が何らかの採用ミスマッチを経験しており、その防止策として60%がカジュアル面談を活用していました。

paizaではランクと提出コードで基礎的な技術力をある程度確認できます。だからこそ、面談では基礎的な確認に時間を使う必要がありません。

面談で確認したい内容

• 技術的に何をしたいのか
• どのようなプロダクトを作りたいのか
• チームでどう働くのか
• 自社の技術課題を面白いと感じるか
• キャリアとして何を求めているか

技術力の確認はスキルチェックに委ね、面談は志向・事業・カルチャーの相互理解に使うという役割分担が合理的です。

初期の接点から現場エンジニアを出す

導入企業のなかには、新卒候補者との最初の面接から必ず現場エンジニアが1対1で話す運用を取っている企業があります。

さらに誰でもよいわけではなく、候補者が興味を持っている領域で実際に働くエンジニアをアサインしています。

候補者の志望領域	アサインするエンジニア
AI・機械学習	機械学習エンジニア
バックエンド	バックエンドのリード
マネジメント志向	エンジニアリングマネージャー

候補者にとっては「この会社には自分が目指したいエンジニアがいる」ことを確認できる機会になります。

応募ポジションに固執しない

導入企業のなかには、面接での対話を踏まえて応募ポジション以外を提案している企業があります。

応募：エンジニア

↓

面接：リーダーシップの資質が見える

↓

提案：リーダー候補としてはどうかと打診する

逆に候補者から「今後はマネジメントに関わりたい」と聞けば、そのキャリアを用意できるポジションを検討します。

paizaでは技術水準が先に確認できているため、**「技術要件を満たした候補者を、どこに配置すれば最も活躍するか」**という発想を持ちやすくなります。

新卒採用では「説明できるか」まで見る

新卒採用の事例では、ランクだけでなく次の点まで確認されています。

• コーディングテストの結果
• コードの意図を説明できるか
• チーム開発の経験があるか

制作物の提出を必須にし、「なぜそれを作ったのか」を深掘りしている企業もあります。

書ける
↓
なぜそう書いたか説明できる
↓
チームのなかで使える

「Bランクだから優秀」という判断ではなく、この3段階まで確認する設計が有効です。

新卒では早期接触が有効

新卒採用の事例では、インターンから本選考へつなげる運用が目立ちます。

• 1〜3月のインターン期を重視し、1on1イベントや自社イベントで早期層と接触する
• 6月の1dayインターンで約140名を集め、12名の承諾につなげる
• 就業型インターンから採用につなげる

スカウトから会社説明会、本選考という流れだけでなく、スキルで対象学生を絞り、早期インターンで現場エンジニアと接点を作ってから本選考へ進めるという設計が有効です。

よくある質問

Q：提出コードは誰が確認すべきですか？
A：現場エンジニアが確認してください。コードの良し悪しや考え方の判断は、人事だけでは困難です。人事がランクと経歴で一次選考を行い、現場が提出コードを確認して技術的な判断を加えるという分業が現実的です。

Q：カジュアル面談で技術の話を一切しなくてよいのですか？
A：技術の話は必要ですが、能力を測る場としてではなく、相互理解の材料として扱ってください。自社がどのような技術課題に取り組んでいるか、候補者が何を面白いと感じるかを話すことで、入社後のミスマッチを減らせます。提出コードについて話す場合も、評価ではなく考え方を知るための対話として進めてください。

数値管理と改善の進め方

paizaは求人応募の約7割がスカウト経由であるため、スカウトの各段階を分けて計測することが改善の起点になります。

追うべきファネル

条件に該当する候補者数
↓
スカウトの送信数
↓
開封
↓
返信・「気になる！」
↓
プラチナスカウトの送信
↓
カジュアル面談
↓
選考
↓
内定
↓
承諾

自然応募とスカウト経由の流入を分けて計測することで、どちらに課題があるかを判断できます。

ボトルネックの切り分け

状態	疑うべき箇所
該当候補者が少ない	ランク条件・要件が厳しすぎる
スカウトが開封されない	送信対象と求人内容のずれ・件名
開封されるが返信がない	会社説明に偏った文面・仕事内容の不足
返信はあるが面談に至らない	提案内容・日程調整のスピード
面談は多いが選考へ進まない	面談での伝え方・ポジションの魅力
内定を出しても辞退される	提示条件・働く環境・選考スピード

該当候補者数を定期的に確認する

paizaでは技術力がランクで可視化されているぶん、条件を厳しく設定しやすくなります。その結果、対象となる候補者が想定より少なくなるケースがあります。

確認の手順

1. 現在の採用条件で該当する候補者数を確認する
2. 母集団が不足していれば、条件を1つずつ緩めて変化を見る
3. どの条件が母集団を大きく狭めているかを特定する

paiza自身も、候補者が見つからない場合には求人要件そのものを見直すことを推奨しています。

特に緩めやすいのは次の条件です。

• ランクの下限
• 特定の言語やフレームワークの経験年数
• 希望勤務地の範囲

導入時にも母集団を確認する

導入を検討する段階でも、会員数の規模ではなく自社の条件に該当する人数を確認してください。

確認したい条件

• 使用言語
• 経験年数
• 希望勤務地
• 希望年収
• ランク

「Goのシニアを3名採用したい」という要件であれば、これらの条件をすべて入れたうえで実際にアプローチできる人数を把握します。

あわせて、同業種や近い規模の企業がどの程度利用しているかも確認しておくと、競合状況の判断材料になります。

改善は1か所ずつ行う

求人票・ランク条件・スカウト文・送信対象を同時に変更すると、効果の要因を特定できません。

改善の順序

1. 求人票（すべての受け皿）
2. 採用条件・ランクの基準（母集団）
3. スカウトの送信対象（開封率）
4. スカウトの文面（返信率）
5. 面談の設計（選考移行率）
6. 提示条件・働く環境（承諾率）

母集団が確保できていない状態で文面を改善しても、成果は変わりません。上流から順に確認してください。

承諾率が低い場合は環境も見直す

内定は出るが辞退されるという状態が続く場合、選考プロセスだけでなく、提示している労働環境そのものが求める水準の候補者と合っていない可能性があります。

導入企業のなかには、優秀なエンジニアを採用するために働く環境そのものを変えた例もあります。副業の可否、裁量労働、リモートワーク、開発手法といった条件は、候補者の意思決定に直接影響します。

よくある質問

Q：どのくらいの期間で成果を判断すべきですか？
A：成功報酬型で固定費が発生しないため、一定期間の運用を継続しやすい構造です。目安として3か月程度を前提に、月次でスカウトの開封率と返信率、面談数を確認しながら改善を重ねてください。ただし該当候補者数が極端に少ない状態が続く場合は、期間を待たずに要件の見直しを検討してください。

Q：ランクの基準を下げることに現場が反対する場合はどうすればよいですか？
A：該当候補者数のデータを共有してください。「Aランク以上に絞ると対象が何名になるか」を具体的な数字で示すことで、要件の議論が現実的になります。あわせて、キャッチアップの意欲や学習姿勢で補える範囲についても現場と認識を合わせておくと、基準の調整がしやすくなります。

まとめ

paizaは、候補者が実際に解いたプログラミング問題と提出コードからコーディング能力を可視化し、その技術水準を起点にスカウトと選考を進めるサービスです。

押さえておきたい要点

• 経歴ではなく「実際にコードを書いた結果」を採用前に確認できる
• ランクが測っているのはコーディング能力。設計力やビジネススキルは含まれない
• ランクは足切りではなく「まず会うべき人」を決める基準として使う
• 育成採用と即戦力採用でランクの基準を変える
• 求人応募の約7割がスカウト経由。掲載して待つ運用では成果につながらない
• スカウト運用にはサポートが介在するため、判断精度を高めることに集中できる
• 「気になる！」を押した候補者を優先し、プラチナスカウトを使う
• スカウトでは会社説明ではなく、仕事内容・開発環境・働き方・キャリアを書く
• 送信対象と求人内容をズラさない。ランクが高いだけで送らない
• 求人はポジションごとに分け、技術スタックと開発体制を具体的に書く
• 提出コードを技術面接の共通資料として使う
• 初期の接点から、候補者の志望領域に近い現場エンジニアを出す
• 求める水準の候補者が働きたいと思う環境があるかも問われる

技術力を数値で確認できるからこそ、ランクだけで判断を完結させないことが重要です。ランクは技術面の一次シグナルとして扱い、実務経験は職歴、志向やカルチャーは面談で確認するという役割分担を設計してください。

経営幹部・重要ポジションの採用ならGrowth Talentへ

paizaはコーディング力を重視するエンジニア採用に強みを持つ一方、CTOやVPoEといった技術組織の責任者、あるいはCxOクラスの採用では判断軸が異なります。経営に近いポジションには、その層に特化したチャネルを併用することが有効です。

Growth Talentは、スタートアップ・ベンチャー企業のCxOクラス・経営幹部・事業責任者などの重要ポジションに特化した求人プラットフォームです。成長企業で経営に関わることを前提にキャリアを考えている層が登録しており、事業フェーズへの理解がある候補者と出会えます。

このような採用ニーズに適しています

• CTO・VPoEなど技術組織を統括する人材を採用したい
• CFO・COOなどCxOクラスのポジションを募集している
• 事業責任者・部門責任者など経営に近いポジションを探している
• エンジニアメンバーの採用と並行して、技術責任者の採用も進めたい

採用の運用体制にお悩みなら採用支援サービスへ

「採用要件をどう設定すべきか判断できない」「現場エンジニアを採用に巻き込めない」といった課題は、多くの企業に共通するものです。

Growth Talentを運営する株式会社Interiorでは、採用要件の設計から媒体選定・求人票の改善・スカウト運用まで、採用活動を包括的にサポートする採用支援サービスを提供しています。