エンジニア・IT職の求人票の書き方｜技術スタック・開発環境の正しい書き方と採用成功例

エンジニアの求人票には、営業職や事務職とは全く違うルールがあります。「コミュニケーション能力を重視します」「やる気のある方歓迎」といった表現は、エンジニアにとっては逆効果になります。本記事では、中小企業がエンジニア採用で勝つための求人票の書き方を、悪い例と良い例を並べて解説します。

エンジニア採用が中小企業に難しい理由

経済産業省の試算では、2030年にはIT人材が最大79万人不足します。厚生労働省の有効求人倍率データでも、ITエンジニアは常に10倍前後で推移しています。つまりエンジニア1人に対して求人が10件ある状態です。

この状況で中小企業が戦う相手は2種類あります。1つはGAFAMや国内大手で、年収1,000万円以上を提示してきます。もう1つは資金調達済みのスタートアップで、ストックオプション・フルリモート・最新技術スタックをセットで出してきます。

中小企業が同じ土俵で戦っても勝てません。だが「求人票の情報量」では勝てます。大手の求人票は抽象的で、スタートアップの求人票は派手だが実態が見えません。中小企業は「リアルで具体的な情報を出す」ことで差別化できます。

関連記事：中小企業の採用完全マニュアル

エンジニアが求人票で必ずチェックする6項目

エンジニアは求人票を「技術的に働ける場所か」の観点で読みます。チェックされる項目はほぼ固定されています。

1. 技術スタック：使っている言語・フレームワーク・インフラの具体名
2. 開発フロー：ウォーターフォールかアジャイルか、レビュー体制、リリース頻度
3. リモートワーク可否：週何日・コアタイムの有無・実態
4. 裁量：技術選定権・設計の自由度・意思決定プロセス
5. 技術的負債の状態：レガシーの有無、リファクタ計画
6. チーム構成：エンジニアは何人か、年齢層、経験年数

この6項目を埋めていない求人票は、エンジニアからは「情報がないから応募の判断ができない」と見なされ、スキップされます。

❌悪い例と✅良い例：技術スタックの書き方

エンジニア求人票で最も致命的なミスが、技術スタックの曖昧さです。

❌ 悪い例

使用技術：Java、Python、各種クラウド（その他詳細は面接でお伝えします）

これを見たエンジニアは応募しません。理由は3つあります。Javaが2系なのか21なのか分かりません、Pythonが何のフレームワークか分かりません、「面接で伝える」は隠している印象を与えます。

✅ 良い例

技術スタック

• フロントエンド：React 18 / TypeScript 5.x / Next.js 14（App Router）
• バックエンド：Python 3.12 / FastAPI / SQLAlchemy
• インフラ：AWS（ECS Fargate / RDS Aurora PostgreSQL / CloudFront）
• IaC：Terraform
• CI/CD：GitHub Actions
• 監視：Datadog / Sentry

開発フロー

• スクラム開発（2週間スプリント）
• プルリクエストはエンジニア2名以上のレビュー必須
• 本番リリースは週1回（火曜 14:00）
• テストカバレッジ 70%以上を維持

ここまで書くと、エンジニアは「自分のスキルが活きるか」「入社後のキャッチアップにどれくらいかかるか」を判断できます。判断できる情報を出すことが、応募への最短ルートです。

技術スタックのバージョンまで書くと「古いと思われて応募が減るのでは」と心配する声がありますが逆です。古くても正直に書いた方が、入社後のミスマッチが減ります。古さを隠して採用しても、1ヶ月で辞められたらコストの方が大きいです。

関連記事：仕事内容の書き方

リモートワーク・フレックスの正しい書き方

「リモートワーク可」「フレックス制度あり」という一言だけの求人票は、エンジニアから信用されません。なぜなら「可」と書いてあっても実際は週5出社の会社が多いからです。

❌ 悪い例

勤務形態：リモートワーク可、フレックスタイム制度あり

✅ 良い例

勤務形態

• ハイブリッド勤務（週2日出社・週3日リモート）
• 出社日はチームで調整（火・木が多い）
• フレックスタイム制（コアタイム 11:00〜15:00）
• 実績：エンジニア10名中、9名が週3リモートを利用
• 地方在住メンバー2名はフルリモート（四半期に1度出社）

「可」ではなく「実績」を書きましょう。実績の数字があると、制度が形骸化していないことが伝わります。

フルリモートと書いておきながら実際は月数回の出社を求める会社は、入社後に揉めます。求人票の段階で正確に書いた方が、長期的には採用コストが下がります。

技術的負債・レガシーシステムを正直に書くメリット

「レガシーなシステムをリファクタしていくフェーズです」と書くと応募が減る、と思い込んでいる経営者が多いです。しかし実際は逆で、この情報を正直に書いた方が、長く働いてくれるエンジニアが集まります。

❌ 悪い例

モダンな技術を使った開発を行っています。エンジニアが働きやすい環境です。

入社後に10年物のPHP 5.6のコードを見せられたエンジニアは、3ヶ月で退職します。

✅ 良い例

システムの現状と今後

• 基幹システムはPHP 7.4 / Laravel 6で稼働中（2018年リリース）
• 2026年中にPHP 8.3 / Laravel 11へのバージョンアップを計画
• 新規サービスはGo / gRPCで開発中（マイクロサービス化を推進）
• 技術的負債の解消に全体工数の20%を割り当てている
• 入社いただく方には、まずLaravelの保守と並行して、新サービスの設計にも参加いただきます

レガシーを「リファクタ対象」として見せると、改善経験を積みたいエンジニアが応募してきます。隠して採用するとミスマッチで辞めます。正直に書いた方が、結果的に採用母集団の質が上がります。

未経験・第二新卒エンジニア向けの求人票の書き方

未経験エンジニアを採用するときも、「未経験歓迎」の一言では何も伝わりません。未経験者が知りたいのは「自分が入社後どう成長するのか」の具体像です。

❌ 悪い例

未経験歓迎！先輩が丁寧に教えます。やる気重視！

✅ 良い例

未経験入社後のロードマップ

• 1〜3ヶ月目：社内研修（HTML/CSS/JavaScript基礎、Git、Linux）
• 4〜6ヶ月目：メンター付きでバグ修正・小規模機能追加を担当
• 7〜12ヶ月目：機能単位での設計・実装を担当
• 2年目以降：要件定義フェーズから参加

サポート体制

• メンター制度（1on1 週1回）
• 技術書購入補助（月5,000円まで）
• Udemy法人アカウント支給
• 過去3年の未経験入社者：8名中7名が2年以上継続勤務

数字を入れると、研修が実在することが伝わります。「丁寧に教えます」では伝わりません。

関連記事：未経験歓迎の書き方

Wantedly・Green・GitHub・Indeedの使い分け

エンジニア採用では、媒体ごとに読まれ方が違います。同じ求人票を全媒体に貼るのは効率が悪いです。

• Indeed：検索流入が中心。キーワード（React、Pythonなど）を具体的に書くと露出が増える
• Green：エンジニア特化。技術スタックの詳細度・開発環境の写真が効く
• Wantedly：カルチャー・ビジョン重視。事業の意義やチームの雰囲気を長文で
• GitHub採用（GitHub Jobs的な使い方）：自社エンジニアの公開リポジトリやテックブログへのリンクを貼る

中小企業がまず力を入れるべきはIndeedとGreenです。Wantedlyはコンテンツ制作の工数が重いです。GitHub・テックブログは長期的な資産になりますが、採用直結までは時間がかかります。

関連記事：Indeedの求人票の書き方

まとめ：エンジニア求人票は「判断材料を出す」ゲーム

エンジニア採用の求人票は、営業職の求人票とは発想を変える必要があります。エンジニアは「魅力的に見せる文章」ではなく「判断できる具体情報」を求めています。

技術スタックはバージョンまで書きましょう。リモートは実績を書きましょう。レガシーは正直に書きましょう。未経験向けはロードマップを数字で書きましょう。この4つを守るだけで、中小企業の求人票はエンジニア採用市場で差別化できます。

隠して集めた母集団は、入社後に離脱します。正直に書いた求人票の方が、長期的には採用コストが下がります。

求人票の作成をもっと効率化したい方は、AIで求人票を自動生成できる採用ハリネズミをお試しください。無料でお使いいただけます。