This article is also available in English.
印象に残る履歴書を目にしたときのことを思い出してみてください。そこにはただの職歴の一覧ではなく、その人がその仕事の適性がはっきりと伝わるストーリーが描かれていたのではないでしょうか。丁寧に作り込まれていて、文字の向こうから候補者の個性が感じられたはずです。
読んだ瞬間「この人に会ってみたい」と思いませんでしたか？カジュアル面談で、落とす理由を探すのではなく、履歴書の好印象を確認したいと思いませんでしたか？平凡な履歴書でも面接に進めるかもしれませんが、他の候補者と差別化を図ることはことはできません。一方、優れた履歴書は、最初から候補者を成功へと導くことができます。
履歴書が候補者の第一印象を形づくるように、求人票もまた会社の印象を大きく左右します。
求人票とは候補者が最初に目にする会社からの情報です。何百人、あるいは何千人もの候補者が、その求人票を手がかりに仕事や会社を評価します。平凡な求人票でも応募は集まりますが、質の高い候補者の心を動かすことはできません。
TokyoDevを運営する中で、これまでに1000件以上の求人票をレビューし、改善のためのフィードバックを企業に提供してきました。私自身、エンジニアでもあるので、同じエンジニアに何が響くのか理解しています。採用側と候補者側、両方の視点を踏まえることで、どんな求人票が効果的なのかを研究してきました。
私の経験を基に、エンジニアが「本当に読みたい」と思う求人票の作り方をご紹介します。
良い求人票を作る3つの原則
求人票を作る、もしくはレビューするとき、私は3つのポイントを常に意識しています。この３つを押さえることで、求人票を「わかりやすく」「魅力的で」「適切な人材を引き寄せる」ものにすることができます。
フィルタリングではなく、惹きつける
採用したい候補者ほど、応募する可能性は低いものです。良い候補者ほど慎重に見極め、自分に強く合っていると感じた場合にのみ応募します。逆に、そこまで欲しくない候補者ほど数打ちゃ当たるスタイルで、1日に何十件もの応募を出すこともあります。
どんなに工夫しても、合わない候補者からの応募はゼロにはなりません。なので、欲しくない人を排除しようとするのは時間と労力の無駄です。大切なのは「優秀な候補者に応募したいと思わせること」で、求人票でそれが出来なければ、結果的に採用候補者データベースは脆弱になります。
ポジションの特徴を強調する
ソフトウェアエンジニアであれば誰でもコードを書けますし、バグ修正ができます。ですから、それ自体がポジションの魅力にはなり得ません。大切なのは、その役割ならではの特徴を伝えることです。下記の例を見てみましょう。
- 課題：「1日に数百万件の取引を処理できるように、当社の決済処理システムを拡張していただきます」
- 使用技術：「Ruby on Railsを使ってAPIを構築し、Kafkaを使ってデータパイプラインを設計していただきます」
- 仕事のインパクト：「構築するパイプラインは世界中の工場から集めた排出データを処理し、企業が自社のカーボンフットプリント削減に必要なインサイト得られるようになります」
また、候補者は同じ会社の複数の募集を同時に見ていることもあります。その際、どの求人票にも会社紹介や福利厚生など同じ文章が繰り返し載っていると、各ポジションの違いが見えづらくなります。こうした共通情報は別ページにまとめ、リンクで案内するとすっきりします。個々の求人票には、そのポジション固有の情報だけを掲載すれば良いでしょう。
重複したポジションの掲載を避ける
企業が成長するにつれて、役割はより細分化されていきます。たとえばスタートアップであれば、次の2つのポジションで十分かもしれません。
- フロントエンドエンジニア
- バックエンドエンジニア
この場合、候補者にとって自分に合ったポジションを見分けるのは簡単です。
一方で、大企業になるとエンジニアの募集が100件以上にのぼることも珍しくありません。しかしよく見ると、その多くが重複していることがあります。例えば次のような形です。
- バックエンドエンジニア（バンキング／決済チーム）
- バックエンドエンジニア（クレジットカード／不正検知チーム）
- バックエンドエンジニア（インテグレーション／決済・不正検知チーム）
- …など
候補者からすると、これは混乱のもとです。「自分はどのポジションに応募すべきか？」「複数応募しないといけないのか？」「1つに応募すれば全部考慮されるのか？」と疑問が出てきます。
そのため、似たような役割を別々に掲載するのではなく、共通点を抽出して1つか2つのポジションにまとめるほうが、候補者にとっては親切です。たとえば10種類のバックエンドエンジニアを募集している場合でも、業務内容や要件の共通部分を整理すれば、より広い層の候補者に応募してもらいやすくなります。そして、最終的にどのチームやレベルに配属するかを判断するのは採用側の役割です。
もちろん、この方法を実践するには採用担当者が複数の現場マネージャーと調整し、採用プロセスを変える必要があるため、手間が増えるかもしれません。しかし候補者任せにしてしまうと、優秀な人材ほど応募を避けてしまう可能性があります。
もし前述のようにポジションをまとめる対応が難しい場合は、候補者に対してあらかじめ明確に伝えることが重要です。「複数のポジションに応募すべきか、それとも1つでよいのか」「1回の応募で似たようなポジションも選考対象になるのか」といった点を、最初から説明しておきましょう。こうした説明を加えるだけで、候補者の不安が減り、採用プロセス全体がより透明で誠実に感じられます。
求人票の構成
TokyoDev では、求人票を以下のような共通の構成に統一しています。
- 職種名
- 求人について
- 職務内容
- 応募条件
- 歓迎スキル
- 給与
- 選考フロー
このリストは、候補者が求める基本的な情報をカバーしています。構成を統一することで、候補者は複数のポジションを比較しやすくなり、応募体験も一貫したものになります。
職種名
良い職種名とは、短く、分かりやすく、一目でその役割が伝わるものです。
シニアやリーダーといった役職レベルが重要であれば、「シニア（Senior）」「リーダー（Lead）」など一般的に定着している表現を使いましょう。混乱を招く「リーダー候補（Lead Candidate）」といった言い回しは避け、必要であれば本文で補足するほうが適切です。
スキルの範囲が広すぎて具体性に欠ける場合は、より絞り込んだ表現を使います。たとえば「Android エンジニア」は「モバイルエンジニア（Android）」よりも明確です。
チーム名やプロダクト名を含む場合は、社外の人が見ても理解できる名称を選びましょう。社内用語をそのまま使うのは避け、わかりやすい表現に置き換えてください。たとえば、社内で「Plutus Team」と呼ばれているチームが決済を担当しているのであれば、求人票では「決済チーム（Payments Team）」と記載するほうが適切です。
ここからは、バックエンドエンジニアのポジションを例にとり、それぞれのステップを解説していきます。まずは職種名から始めましょう。
求人について
求人概要では、候補者が実際に取り組む課題、使用する技術、そしてその仕事がどのような影響を与えるかを示すことが大切です。長文ではなく、1～2段落程度の簡潔な説明が望ましいです。
実際にそのポジションの人が、同僚に仕事内容を説明するように書くとよいでしょう。
例：
職務内容
職務内容は、このポジションが他の類似ポジションとの違いを、候補者に明確に伝えることが重要です。すべての細かい作業を列挙する必要はありませんが、主なタスクがイメージできる程度には具体的に書くと良いでしょう。
多くても7項目までに絞りましょう。それ以上になると多すぎる印象を与えかねません。
例：
応募条件
応募条件は、難しい部分のひとつです。応募条件の目的は、候補者に「自分が応募資格を満たしているかどうか」を判断してもらうことにです。そうすることで、明らかに可能性が低い人が時間を無駄にせずに済み、採用側も選考コストを減らせます。ただし、いくら丁寧に条件を言葉にしても、本来なら応募すべき優秀な人が自ら外れてしまったり、逆に明らかに条件を満たしていない人が応募してきたりすることは避けられません。これを踏まえ、特に意識すべきは以下の点です。
リストは短く
条件が2つしか書かれていなければ、多くの候補者は「これは必須なんだな」と理解できます。しかし、7つも並んでいる場合、候補者の反応はさまざまです。数個満たしていれば応募する人もいれば、すべてを満たしていないと応募しない人もいます。
そのため、応募条件には「このスキルや経験がなければ採用しない」と断言できるものだけを記載することをおすすめします。たとえば、あなたの開発チームがRubyのコードベースを引継いで悩んでいて、プロジェクトをリードできる専門家を必要としているなら、Ruby経験を必須条件とするのは当然です。一方で、プロダクトが決済領域にあり、決済ドメインの経験がある人を望んでいるとしても、もし優秀な人材であればその経験がなくても採用したいと考えられるなら、それは必須条件にすべきではありません。
さらに、候補者のほとんどが当たり前に持っているスキルは要件に入れないようにしましょう。例えば、熟練ソフトウェアエンジニアを募集するのであれば、「Git経験」とわざわざ書く必要はないでしょう。候補者の98％は当然のようにそのスキルを持っており、残りの2％をふるい落とすために余計なノイズを加える必要はありません。
判断しやすい条件
良い条件とは、候補者が「はい」か「いいえ」で明確に答えられるものです。
たとえば「Rubyに強い」という表現は主観的すぎます。人によって「強い」の定義は異なるため、判断基準はスキルではなく自信の程度になってしまいます。
「〇年以上の経験」と年数を条件にする方法は、候補者にとって自己判断しやすい点でメリットがあります。しかしその場合でも、年数に満たないが非常に優秀な人材を排除してしまうリスクがあります。
この場合、具体的にそのスキルをどう使うかを示すことです。
例：
このように具体的に記載することで、候補者は自分が条件を満たしているかどうかを客観的に判断できます。
ソフトスキルは必要な場合だけ書く
さらに付け加えると、ソフトスキルに関する条件は多くの場合、削ってよい部分です。「高いコミュニケーション能力」「モチベーションが高い」「単独でもチームでも働ける」といった表現はあまりに一般的すぎて、ほとんど意味を持ちません。自分を「モチベーションが低い」と思って応募をやめる人はいないでしょう。もし本当にポジションに不可欠なソフトスキルがある場合のみ、明確に書きましょう。
とはいえ、ポジションによってはソフトスキルが役割の中心であり、強調すべき場合もあります。たとえば、エンジニアリングマネージャーに「リーダーシップ経験」を求めるのは妥当です。ただし、漠然と「リーダーシップ経験」と書くだけでは不十分です。実際にそれがどのような行動を指すのかを明示することが必要です。
例：
歓迎スキル
「歓迎スキル」は、必須ではないものの、候補者が自分をアピールできるポイントを示す箇所です。たとえば、PostgreSQLの経験が役立つが必須ではない場合、ここに記載しておくとよいでしょう。経験のある候補者は強調できますし、経験がない候補者も気にせず応募できます。ただし注意点として、一部の候補者は「ほとんどの『歓迎スキル』を満たさなければ応募資格がない」と誤解してしまうことがあります。そのため、「これらは必須条件ではありません」と明記することをおすすめします。TokyoDev では以下のように簡単な一文を加えています。「必須ではありませんが、以下のいずれかをお持ちの場合はご記入ください。」
また、応募条件と同様に、書き出しすぎないことが重要です。長くなりすぎると読みづらくなるため、短く、具体的で、自己判断しやすいものに絞りましょう。
例：
給与
「競争力のある給与体系」や「経験を考慮して決定」といった曖昧な表現で済ませるくらいなら、給与を載せない方がマシです。これは候補者にとってごまかしにしか見えません。「本当は提示すべきなのに、あえて書いていない」と受け取られてしまいます。
実際、シニアレベルの候補者から「給与範囲が明記されていない会社には応募しない」と何度も聞いたことがあります。知名度の低い企業であればなおさらです。候補者は「期待値以下だろう」と推測したり、「できるだけ安く採用しようとしているのでは」と不信感を持ってしまいます。
一方で、給与範囲を公開することは「公正な報酬を支払っています」という強いアピールになります。交渉力や前職の給与に左右されないことを示せるからです。特に、性別などの要因で過去に不当に低い給与を受けてきた人にとって、この姿勢は大きな意味を持ちます。給与範囲を明記することは、単なる形式ではなく、「多様性を重視し、公平な環境づくりに真剣に取り組んでいる」ことの証明になります。
給与範囲を提示する際は、幅を広くしすぎないことが重要です。たとえば「年収500万〜1,500万円」といった表記では、実質、範囲を提示していないのと同じです。もし幅が広いのが、複数のレベル区分を含んでいるためであれば、その内訳を明示しましょう:
選考フロー
選考フローの詳細を省略する企業が多く見受けられますが、最初から共有することで候補者と企業の双方にメリットがあります。候補者にとっては、どのくらい時間を要するのか、どんな面接があるのか、どう準備すればよいのかがわかり、透明性と誠実さを感じてもらえます。企業にとっては、早い段階で期待値をすり合わせることで、途中辞退を減らす効果があります。
また、プロフェッショナルで整理された選考フローを示すことで、優秀な人材を惹きつけやすくなります。
選考フローを記載する際は、主要なステップを時系列に沿って列挙し、それぞれに簡潔な説明を添えると効果的です。可能であれば、各ステップに要する目安の期間も明記することで、候補者にとってより親切な情報提供となります。
例：
ヒント
技術関連の参照情報は最新に保つ
求人票に記載する技術は、できるだけ最新のものを反映させましょう。現在使っているツールやフレームワークを記載することで、チームの現代的な開発文化を示すことができます。逆に古い技術を挙げてしまうと、「時代遅れな開発文化なのでは？」と候補者に思われてしまいます。
よくあるのが、特定のバージョンを明記してしまい、後で更新を忘れてしまうケースです。ソフトウェアのバージョンはすぐに変わるため、役割にとって本当に重要でない限り、明記しない方が無難です。
もちろん、実際に古い技術を使っている場合もあります。たとえば2010年頃は当たり前だったjQueryも、現在では新規プロジェクトで使われることはほとんどありません。今も使い続けている場合は、そのことを求人票で強調するべきか慎重に検討しましょう。たとえ正当な理由があったとしても、候補者の中にはそれを見て応募をためらう人がいるかもしれません。
バイアスを意識する
求人票の書き方や企業文化の表現には、意図せず「この職場にふさわしい人」のイメージを伝えてしまうことがあります。たとえば、「オタク歓迎」といった表現です。ゲーム・漫画・アニメ好きにアピールできる一方で、そうでない人を遠ざけてしまう可能性があります。TokyoDevの調査によると、日本に来たばかりの候補者はオタク文化に関心を持つ割合が高く、長く住んでいる人ほど関心が低くなる傾向があります。つまり「オタク歓迎」と書くと、比較的若手の応募は集まる一方で、シニアレベル人材を採用するチャンスを狭めてしまうリスクがあるのです。
福利厚生の書き方も同様です。「フリービール・フライデー」はお酒を飲まない人にとっては疎外感を与えるかもしれませんし、「ゲームナイト」は家庭の事情で参加できない人に「自分は合わないのでは」と思わせます。もちろん、こういうことを決して書くなと言っているのではなく、こうした表現が応募者層を狭める可能性があることは意識しておくべきです。
特にエンジニアの現場は男女比に偏りがあることが多いため、求人票の小さなサインが応募の多様性に大きな影響を与えます。チームや求人票をより多くの人に受け入れられるものにするための実践的なヒントとしては、TokyoDevの「エンジニアチームに女性を採用するための4段階アプローチ」も参考になります。
技術はリストではなく文脈で伝える
多くの履歴書には「スキル」欄があり、候補者が触れたことのある技術をすべてリストアップしています。しかし、「Python」とだけ書かれていても、それが一度きりのスクリプト作成経験なのか、長年プロダクション環境でシステムを構築してきた経験なのかは分かりません。
同じ問題は、求人票でも起こりがちです。たとえば「技術スタック：Python、Go、Node.js」と10〜20個の技術要素をただ並べただけのリストです。これでは、各要素が実際にどのように使われているのかが分かりません。特に「バックエンド：Python、Go、Node.js」と書かれていると、候補者は「Node.jsは10％だけ使うのか、それとも90％なのか？」と疑問に思ってしまいます。
もちろん、技術を列挙すること自体が悪いわけではありません。ただし、その役割においてどのように活用するのか、文脈を添えて説明することが大切です。たとえばバックエンドエンジニアを採用するのであれば、フロントエンドの詳細を伝える必要はありませんが、主要なバックエンド言語やフレームワークの使用方法を明示することは、候補者にとって大きなメリットです。
標準的な見出しを使う
一部の求人票では、「こんな人に来てほしい」「理想的な候補者は…」といった見出しを使い、その下に「Ruby経験5年以上」などの条件を並べるケースがあります。こうした工夫には「応募条件」と書くよりもフレンドリーな印象を与えたいという意図があります。しかし、これはかえって曖昧さを生みます。「これは必ず満たさなければならない条件なのか、それとも多少不足していても応募できる“歓迎スキル”なのか？」候補者は判断に迷います。
そのため、「応募条件」や「歓迎スキル」といった標準的で明確な見出しを使う方が良いのです。これにより、候補者は「どこが必須で、どこは柔軟なのか」をすぐに理解でき、安心して応募することができます。
日本企業へのヒント
機械翻訳をそのまま使わない
日本語で書かれた求人票を機械翻訳にかけると、英語ネイティブの目には不自然でぎこちなく映ることが多いです。その結果、応募者は「この会社はプロフェッショナルではないのでは」「非日本語話者は後回しにされているのでは」と疑念が生まれます。
さらに、日本語の求人票は英語のものとは慣習が異なります。そのため、たとえ直訳がきれいに見えても、英語話者には「何かおかしい」と感じさせてしまうのです。ですから、単なる翻訳ではなく、英語を母語とする応募者を念頭に置いて書き直すことが大切です。
実際の例として以下は、ある日本企業の実際の求人票（匿名化済み）からの引用で、機械翻訳をそのまま使ったことが明らかな例です。
このような文章は、まさにこの記事を書くきっかけとなったものです。まず、文章そのものが採用ではなくマーケティング目的で書かれたように感じられ、冗長でありながらほとんど意味を伝えていません。こうした内容は、候補者を惹きつけるどころか、かえって遠ざけてしまいます。ここまでくると、むしろ削除した方が良い場合もあります。
その他にもこの例文はに、ネイティブスピーカーに違和感のある点がいくつもあります。
- 「small to big listed companies」や「mid-term vision」といった表現は英語では一般的に使われません。
- “Adsemble Platform Next Gen Delivery”のように製品名を引用符で囲むのは、日本語ではよく見られますが、英語の求人票では不自然です。
- 「※（こめじるし）」や「■」「【】」といった日本特有の記号も、違和感を与えてしまいます。
機械翻訳はあくまでも出発点に過ぎません。必ずネイティブレベルの英語話者にチェックしてもらいましょう。理想を言えば、その人がエンジニアでもあるとさらに良いです。そうすれば、自然な英語であるだけでなく、ターゲットとなる応募者にとって技術的にも適切で魅力的な表現に仕上げられます。
日本語要件は曖昧にしない
ポジションに日本語能力が必要な場合、多くの求人票では「ビジネスレベルの日本語」や「JLPT N2」といった表現で記載されています。ところが、これは解釈の幅が広く、実際にどの程度の日本語力が必要なのか候補者には分かりにくいのが現状です。
ベストは 「具体的にどのような日本語力が求められるのか」を明確に示すことです。TokyoDevが提供している言語レベルの基準を参考にしてみてください。
例：
> ビジネスレベルの日本語。社内のプロダクトマネージャーと日本語で口頭および筆記によるやり取りを行います。多少の間違いは問題ありません。専門的な技術用語のサポートが必要でも構いません。ただし、基本的には円滑にコミュニケーションできることが求められます。
日本語と英語を同じ求人票に混在させない
日本語話者と英語話者の両方を対象に採用活動を行う場合、ひとつのATS（採用管理システム）上で日本語と英語を混在させた求人票を作るのは手軽かもしれません。しかし、これは候補者にとっては使い勝手が悪くなってしまいます。
理想は日本語版と英語版の2種類の求人票を用意することです。広告の掲載先も別であれば、それぞれにローカライズした短いタイトルをつけることができますし、候補者にとっても読みやすくなります。もしどうしても1つにまとめたい場合は、冒頭に「English follows」と記載し、完全な日本語版 → 完全な英語版という順に分けて掲載する方が良いでしょう。
日本語と英語を交互に混在させるのは絶対に避けてください。たとえば、職務内容を日本語と英語で両方書き、その後に応募条件をまた日本語と英語で繰り返すようなケースです。こうした重複は読みづらさを増すだけで、候補者が必要な情報を素早く把握できなくなってしまいます。
居住要件は明確に伝える
世界中のエンジニアが「日本で働きたい」と考えています。TokyoDevはまさにそのために存在しています。求人票が英語でも日本語でも、日本国外のエンジニアは「自分も応募できるのだろうか」と思います。
そのため、すでに日本に住んでいない候補者でも応募可能かどうかをはっきりと明記することが大切です。これは応募者・企業双方にとって無駄な時間を省くことにつながります。
「求める人物像」といった項目は避ける
日本企業が英語で求人票を書くときによく見られるのが、「Requirements（応募条件）」「Nice to haves（歓迎スキル）」に加えて、「Profile of an ideal candidate（求める人物像）」という項目を設けるパターンです。
日本語では意図が伝わるかもしれませんが、英語では意味が曖昧で、一般的でもありません。さらに問題なのは、そこに書かれているポイントも直訳で、英語では「balances technical expertise with an awareness of business impact（技術的専門性とビジネス的視点を両立できる）」「shows curiosity and a drive to build services that truly help users（深い関心があり、本当にユーザーを助けるサービスを作りたいと考えている）」など、ぼんやりとポジティブな表現に終始してしまうことです。こうしたソフトスキルの表現は、優秀な候補者を惹きつけないどころか、逆に応募をためらう理由にもなりかねません。
したがって、このような項目は削除するか、他の項目に組み込むことをおすすめします。その際は、抽象的な表現を避け、実際の業務に結びついた具体例として書き直すようにしましょう。
まとめ
求人票は、エンジニアにとって会社の第一印象を左右するものです。明確で具体的、かつ整理された求人票は、最適な候補者が自身をそのポジションに重ね合わせ、自信を持って応募できる後押しとなります。
つまり、重要なのは次のポイントです。
- 不適切な応募者を排除することではなく、優秀な応募者を惹きつけることに注力する
- 一般的な作業内容ではなく、実際の業務内容を伝える
- 給与や選考フローなどを透明かつ具体的に示す
日本企業の場合は、単なる翻訳ではなく、英語話者のエンジニアに向けて書くことが重要です。
求人票は、未来のチームメイトとの関係を築くための最初の一歩です。その第一歩を大切にすれば、一緒に働くことを心から楽しみにしてくれる優秀な候補者との出会いに繋がります。
