Greenでバックエンドエンジニアを採る｜求人票とスカウトの要点

バックエンドエンジニアは、IT・Web業界の中途採用で求人が多い職種の一つです。そのぶん、候補者のもとには似た求人やスカウトが並びます。「Go/Ruby/PHPでの開発経験」「API設計の経験」と書いた求人は、どの会社にも書けるため差になりません。バックエンドの候補者が求人票とスカウトで確かめたいのは、言語名ではなく「どんな負荷と複雑さのシステムに、どこまで責任を持つのか」です。 この記事では、Green（株式会社アトラエが運営する、IT・Web業界を中心とした中途採用の求人サイト）でバックエンドエンジニアを採るときの、求人票とスカウトの要点を整理します。

バックエンドの候補者が求人で見ていること

バックエンドエンジニアの候補者が、求人票やスカウトで確かめていることは、おおむね次のとおりです。

• 扱うシステムの性質：トラフィックの規模感、データの量、外部連携の多さ、求められる正確さ（決済、在庫など）
• 担当する範囲：API の実装だけか、設計やデータベースの設計、インフラまで関わるのか
• 技術的な判断の権限：技術選定やアーキテクチャの判断を、チームで行えるのか
• 既存のシステムの状態：新しく作るのか、既存のシステムを改修するのか。古い部分はどのくらいあるか
• 開発の進め方：レビュー、テスト、リリースの頻度、障害対応の体制

とくに経験のある候補者ほど、「何を作るか」より「どんな制約の中で作るか」に関心を持つ傾向があります。同じAPI開発でも、一日に数件の処理と、大量の処理が同時に走るシステムでは、求められる設計がまったく違うからです。

求人票に書くこと

バックエンドの求人票では、次のことを具体的に書きます。

1. システムが解決している課題：「飲食店の予約と在庫を一元で管理する仕組み」のように、何のためのシステムか
2. システムの性質：数値を出せない場合も、「ピーク時に注文が集中する」「外部の決済サービスと連携する」など、性質を言葉で
3. 担当する範囲：設計からか、実装からか。データベースやインフラにどこまで関わるか
4. いまの課題：「モノリスからの分割を進めている」「テストが薄く、リリースのたびに手動確認が多い」など
5. 技術スタックと選定の経緯：言語やフレームワークに加え、なぜそれを使っているか、変える余地はあるか
6. 障害対応の体制：オンコールの有無、頻度の考え方、誰が一次対応するか

6つ目の障害対応は、書かない会社が多いのですが、バックエンドの候補者は気にする項目です。入社後に初めて知ると、不満の原因になります。

スカウトの書き出し

バックエンドの候補者にスカウトを送るときは、相手の経歴の中から「システムの性質」に関わる経験を拾って書き出します。

• 弱い書き出し：「Goでのご経験を拝見し、ご連絡しました」
• 直した書き出し：「ECの注文処理で、ピーク時の負荷対策と非同期処理の設計を担当されていた経歴を拝見しました。いま当社でも、注文が集中する時間帯の処理を作り直す段階にあります」

言語名だけを拾うと、同じ言語を使う会社すべてと同じ文面になります。相手が経験してきた「制約」と、自社の「制約」を重ねると、相手は自分の経験が生きる場所だと感じやすくなります。

送り主は、可能であればテックリードやバックエンドのリーダーにします。面談で技術的な話ができる人の名前で届くと、返信のハードルが下がります。

エージェントベストの見解

バックエンドの採用で、当社がよく受ける相談は「経験者からの返信が少ない」というものです。文面を見せていただくと、多くの場合、相手の経歴の言語名や年数には触れていても、自社のシステムがどんな制約を抱えているかが書かれていません。経験のあるバックエンドエンジニアは、技術的に面白い問題があるかどうかで動くことが多い印象です。自社の課題を「レガシーで大変」と否定的に書くのではなく、「この部分をこう変えたいが、まだ手がついていない」と、取り組む余地として書く。それだけで、返信の中身が具体的になります。課題を書くことをためらう会社ほど、経験者から見ると「何をするのか分からない求人」になっています。

検索とターゲットの考え方

バックエンドの候補者を探すときは、言語名だけで絞らないことが大切です。

• 言語より、扱ってきたシステムの性質で考える：言語が違っても、同じような制約のシステムを扱ってきた人は、立ち上がりが早い傾向がある
• 職種名の揺れに注意する：「サーバーサイドエンジニア」「Webアプリケーションエンジニア」など、同じ仕事を別の名前で呼んでいる人がいる
• SIerや受託出身の人も対象に入れる：自社サービスでの経験がなくても、設計や大規模なシステムの経験がある人は多い
• 外せない経験は2つまで：たとえば「データベースの設計経験」と「本番環境の運用経験」のように、半年で任せる仕事から逆算する

検索の前に決めておくことは、Greenのターゲット設計で整理しています。

選考で確かめることへのつなぎ方

バックエンドの選考では、求人票とスカウトで伝えた「システムの性質」と「担当する範囲」を、面接でも話題の中心にします。

• 一次面接（現場のエンジニア）：過去に扱ったシステムの設計で、どんな判断をしたか。障害が起きたときにどう切り分けたか
• 二次面接または最終面接（リーダー・責任者）：自社のシステムの課題をどう進めたいか。チームでの技術的な判断の進め方
• 課題を出す場合：短時間で取り組める設計の課題や、既存のコードを読んで改善点を話してもらう形など、在職中の負担に配慮する

面接で自社のシステムの課題を具体的に話すと、候補者は入社後の仕事を想像でき、選考への意欲も上がります。

エージェントベストの見解

バックエンドエンジニアを媒体で採るか、紹介で採るかの判断について、当社は両方を扱う立場から次のように考えています。求人票にシステムの性質と課題を具体的に書ける会社は、Greenのような求人型の媒体で、候補者が自分で判断して応募してくる流れを作りやすいです。一方で、システムの詳細を公開の求人票に書けない事情がある会社（取引先との関係、未発表の事業など）は、紹介で背景を口頭で補いながら会うほうが進めやすいことがあります。当社のGreen運用代行は求人票の作成から日程調整までを成功報酬で引き受けていますが、どちらの経路が合うかは、求人票に書ける情報の量でまず判断することを勧めています。

職種全体の媒体の選び方はバックエンドエンジニアの採用媒体の選び方にもまとめています。

まとめ

• バックエンドの候補者が見ているのは、言語名より「どんな制約のシステムに、どこまで責任を持つか」
• 求人票には、システムの性質、担当範囲、いまの課題、選定の経緯、障害対応の体制を書く
• スカウトの書き出しでは、相手が経験してきた制約と自社の制約を重ねる
• 検索は言語名だけで絞らず、扱ってきたシステムの性質と職種名の揺れを考える
• 面接でも自社のシステムの課題を話題の中心にし、入社後の仕事を想像してもらう

よくある質問

使っている言語の経験がない人も対象にすべきですか

同じような性質のシステムを扱ってきた人であれば、言語の違いは入社後に埋められることが多いです。求人票で「言語の経験は問わない」範囲を明記しておくと、応募の幅が広がります。

システムの規模を数値で書けない場合はどうすればよいですか

数値を出せなくても、「ピーク時に処理が集中する」「外部との連携が多い」など、性質を言葉で書けば候補者は想像できます。面談で話せる範囲を補足すると伝えておくのも一つの方法です。

障害対応やオンコールについて書くと、応募が減りませんか

一時的に減ることはあるかもしれませんが、入社後に知って離れる人を防げます。体制や頻度の考え方、負担を減らす工夫も合わせて書くと、否定的な印象になりにくいです。