LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

「エンジニアの求人票が書けない」という詰まりは、書き手の力量の問題ではないことが多いようです。原因の多くは、1枚の紙のなかで性質のまったく違う2つの層が混ざっていることにあります。

1つは、法令で明示が求められている欄。何をどこまで書くかが外側から決まっており、人事・総務が押さえる領域です。もう1つは、自社で決めなければならない中身。どの役割か、入社後に何を出してほしいか、どのスキルがどの深さで要るのか——ここは現場が決めない限り誰も埋められません。

本記事では、前者を厚生労働省の資料で確認したうえで*1、後者をIPAの「デジタルスキル標準」の枠組みで具体化する手順を整理します*3。技術の中身がわからない状態でもスキル要件を指定できる書き方まで扱います。募集の前段にある人材像の決め方についてはDX人材の採用、募集の前に決めておくことで扱っているので、本記事はその次の工程として読んでください。

求人票は2層でできている——混ぜたまま書くから止まる

最初に全体の構造を押さえておきましょう。書けない箇所がどちらの層にあるのかで、相談すべき相手が変わります。

第1層は法令で決まっている欄です。項目そのものは選べません。書き方の水準も、抽象的な表現では足りないと明示されている箇所があります。ここが埋まらない場合、必要なのは社内規程の確認であって、現場へのヒアリングではありません。

第2層は自社で決める中身です。役割、成果、スキルとその深さ。ここは何を調べても出てきません。決める人が決めない限り、空欄のままになります。

実務でよく起きるのは、第2層が決まっていないのに第1層だけを埋めて公開してしまうことです。労働条件は正しく書かれているのに、業務内容の欄が「DX推進に関する業務全般」で終わっている求人票は、この形になっています。法令の要求は満たしていても、候補者から見て応募の判断材料がない状態です。

第1層：明示が必要な14項目と、2024年4月に増えた3つ

厚生労働省の資料では、労働者の募集や職業紹介事業者への求人の申込みの際に明示しなければならない労働条件が、記載例つきで整理されています*1。まず最低限の項目を確認しましょう。

加えて、派遣労働者として雇用する場合のみ、その旨を示すことが必要とされています*1。「雇用形態：派遣労働者」というように示す例が挙げられています*1。

このうち2024年（令和6）年4月1日施行の改正職業安定法施行規則で追加されたのは3つです*1。従事すべき業務の変更の範囲、就業場所の変更の範囲、そして有期労働契約を更新する場合の基準（通算契約期間または更新回数の上限を含む）です*1。労働基準法に基づく労働契約締結時の明示義務についても、同様の改正が行われています*1。

エンジニア採用で見落としやすいのは、裁量労働制と固定残業代の書き方です。裁量労働制を採用している場合は「企画業務型裁量労働制により、●時間働いたものとみなされます」のような記載が必要とされ*1、時間外労働の有無に関わらず一定の手当を支給する制度（いわゆる固定残業代）を採用する場合は、基本給と手当を分けて示し、手当が何時間分の時間外手当に相当するのか、そして一定時間を超える分の割増賃金は追加で支給されることまで書く形が示されています*1。

「変更の範囲」は、具体的に書くよう求められている

追加された3項目のうち、実務でもっとも迷うのが「変更の範囲」でしょう。厚生労働省の資料では、これは雇入れ直後にとどまらず、将来の配置転換など今後の見込みも含めた、締結する労働契約の期間中における変更の範囲を指すと説明されています*1。

更新基準の書き方については、「諸般の事情を総合的に考慮したうえで判断する」というような抽象的なものではなく、「勤務成績、態度により判断する」「会社の経営状況により判断する」など、具体的に記載することが望ましいとされています*1。抽象化して逃げる書き方は、望ましくないと名指しされていると読めます。

また、いわゆる在籍出向を命じることがある場合で、出向先での就業場所や業務が出向元の会社の変更の範囲を超えるときは、その旨を明示するようにしてくださいとも書かれています*1。

エンジニア採用でこの欄が重くなるのは、勤務形態の扱いです。リモート可で募集したあとに出社前提へ変わる可能性があるなら、就業場所の変更の範囲がその可能性を含んでいるかどうかを先に決めておく必要があります。入社後に条件が変わる形は、早期離職の理由になりやすい部分でもあります。この論点は出社回帰とリモート活用の両立で扱っている内容と地続きです。

明示のタイミングと、公開後に負う義務

項目だけでなく、いつ明示するかについても整理されています*1。

ハローワーク等への求人の申込みや自社ホームページでの募集、求人広告の掲載を行う場合は、求人票や募集要項において、少なくとも前述のような労働条件を明示しなければなりません*1。ただし求人広告のスペースが足りない等やむを得ない場合には、「詳細は面談時にお伝えします」などと付したうえで、労働条件の一部を別途のタイミングで明示することも可能とされています*1。

その場合でも、原則として、面接など求職者と最初に接触する時点までに、すべての労働条件を明示する必要があります*1。面接等の過程で当初明示した労働条件が変更となる場合は、その変更内容を速やかに明示することも求められています*1。

もう1点、運用上見落としやすいのが更新義務です。募集広告などの労働者の募集に関する情報を提供する場合は、掲載した時点を明示するなど、正確かつ最新の内容に保つ義務があるとされています*1。公開したら終わりではなく、掲載中は最新に保つ側の責任が続くという理解が要ります。

実務では、求人票を複数の媒体に出したあと、条件を1か所だけ直して他が古いまま残る事故が起きやすい部分です。掲載先の一覧と、最後に確認した日付を1枚で持っておくと運用が安定するでしょう。

第2層：役割から書き始める（類型 → ロール）

ここから自社で決める層に入ります。順番は、役割 → 成果 → スキルです。この順番を守ると、技術の詳細を知らなくても書き進められます。

役割の言葉は、IPAの「DX推進スキル標準（DSS-P）」から借りるのが早い方法でしょう。DSS-Pは6つの類型と、その下位区分である「ロール」、そして全ての類型・ロールに共通の「共通スキルリスト」から成り立っています*3。ロールとは、組織・企業や個人にとって活用がしやすいように、類型を業務の違いによってさらに詳細に区分したものと説明されています*3。

つまり、求人票に書くべき粒度は「類型」ではなく「ロール」に近いということです。ソフトウェアエンジニアという類型のなかには、フロントエンドエンジニア、バックエンドエンジニア、クラウドエンジニア／SRE、フィジカルコンピューティングエンジニアといったロールが置かれています*3。ビジネスアーキテクトの類型にはビジネスアナリストやプロダクトマネージャーが、データマネジメントの類型にはデータエンジニアやデータアーキテクトが含まれます*3。

各ロールには「担うべき責務」と「主な業務」が定義されています*3。たとえばバックエンドエンジニアは、デジタル技術を活用したサービスを提供するためのソフトウェアの機能のうち、主にサーバサイドの機能の実現に主たる責任を持つ役割とされています*3。この定義文は、そのまま業務内容の欄の骨格として使えます。

次が成果です。「入社後6か月で、何がどうなっていればよいか」を1文で書く。ここが書けないときは、役割の選択そのものが曖昧である可能性が高いでしょう。役割を1つに絞り直すほうが早く進みます。

成果の書き方には、避けたい型が1つあります。「開発力の向上に貢献」「DX推進をリード」のような、達成したかどうかを後から判定できない文です。判定できない成果は、入社後の評価基準にもそのまま使えません。逆に「既存の受発注システムの改修を、外部ベンダーとの窓口を含めて1人で回せる状態にする」のように書けていれば、面接で確認すべきことも、入社後に評価する対象も自然に決まります。求人票の業務内容の欄が抽象的なまま残るのは、この1文を先に書いていないためだと考えると原因を絞りやすいでしょう。

スキルは「深さ」で書く——4段階の指定なら技術がなくても書ける

最後にスキルです。ここが技術のわからない書き手にとって難所になりますが、枠組み側に答えが用意されています。

DSS-Pの共通スキルリストは、DXを推進する人材に求められるスキルを5つのカテゴリー・13のサブカテゴリーで整理しています*3。カテゴリーは「ビジネス変革」「データ整備・活用」「テクノロジー」「セキュリティ」「パーソナルスキル」の5つです*3。

そして各ロールに必要なスキルは、共通スキルリストのスキル項目一覧を参照し、各ロールに求められるそれぞれのスキル項目のレベルを「重要度」として定義する形になっています*3。この重要度の定義が、求人票の書き方をそのまま解決します。

なお、パーソナルスキルについては別の基準が置かれており、「z：役割や状況に応じた実践力が必要」として、DXを推進する全ロールに普遍的に求められるスキルと位置づけられています*3。リーダーシップやコラボレーションを「必須要件」として並べても差がつかないのは、この設計から見ても自然な結果でしょう。

この4段階の効き方は具体的です。「Pythonが使える方」と書くと、読み手によって想定される水準が大きくぶれます。「Pythonでの実装経験（a：高い実践力と専門性）」と「クラウドインフラの構成理解（c：知識として説明可能なレベル）」のように深さを添えると、書いた本人が技術の中身を判断できなくても、面接官の間で読み方がそろいます。

もう1つの効果は、必須要件の数が自然に減ることです。すべてをaで書こうとすると要件が過大になり、母集団が消えます。aとbに入れる項目を数個に絞り、残りをcとdへ落とす作業は、そのまま母集団の設計にもなっています。この観点は地方企業のエンジニア採用難で扱っている母集団の制約とあわせて考えると効果が見えやすいでしょう。

書き終えたあと、公開前に社内で確認する3点

最後に、公開ボタンを押す前の確認です。3点だけ見ておくと、後工程での手戻りが減ります。

• 面接官3人が同じ基準で読めるか。同じ求人票を渡して「この応募者は要件を満たすか」を各自に判断させ、割れたらスキルの深さの指定が足りていません。
• 社内の等級に置けるか。賃金欄を書くには、その役割を社内のどの等級に対応させるかが決まっている必要があります。ここが未定のまま公開すると、内定提示の段階で止まります。
• 変更の範囲が実態と合っているか。将来の配置転換や勤務地の変更の可能性を、現場の想定と人事の記載で突き合わせます*1。

3点目は特に、書いた人と運用する人が違うことで齟齬が出やすい箇所です。求人票の記載は労働契約の入口にあたるため、社内規程や労働条件通知書との整合については社会保険労務士等への確認を経て進めてください。

なお、要件を固めたのに採用が間に合わない局面では、期間を埋める手段として業務委託の併用も選択肢に入ります。ただし要件が固まっていない段階で外に出すと判断の根拠が社内に残らないため、順序としては本記事の作業を先に置くのが無理のない進め方でしょう。

まとめ：求人票を書き切るための3つの整理

第一に、求人票は2層でできているという整理です。法令で明示が求められる欄は、業務内容・契約期間・契約の更新・更新上限・試用期間・就業場所・就業時間・休憩時間・休日・時間外労働・賃金・加入保険・受動喫煙防止措置・募集者の氏名または名称の14項目で、派遣労働者として雇用する場合はその旨も必要です。2024年4月1日施行の改正で、従事すべき業務の変更の範囲、就業場所の変更の範囲、有期労働契約を更新する場合の基準の3つが追加されました。更新基準は抽象的な表現ではなく具体的に書くことが望ましいとされ、掲載中は正確かつ最新の内容に保つ義務もあります。第二に、自社で決める層は役割・成果・スキルの順に書くという整理です。役割はDX推進スキル標準の「ロール」の粒度で選び、その定義文を業務内容の骨格に使います。成果は「入社後6か月で何がどうなっていればよいか」を1文で書きます。第三に、スキルは深さで書くという整理です。共通スキルリストの重要度はa（高い実践力と専門性）、b（一定の実践力と専門性）、c（知識として説明可能なレベル）、d（全体の中での位置づけや関連の理解）の4段階で、aとbを必須要件、cとdを歓迎要件に振り分けると、技術の中身を判断できない書き手でも面接官の間で読み方をそろえられます。公開前には、面接官が同じ基準で読めるか、社内の等級に置けるか、変更の範囲が実態と合っているかの3点を確認してください。

よくある質問

出典

1. *1　参考：厚生労働省「募集時などに明示すべき労働条件が追加されます！」（2024（令和6）年4月1日施行 改正職業安定法施行規則・求人企業向けリーフレット）（https://www.mhlw.go.jp/content/001114110.pdf）。明示が必要な労働条件の項目と記載例、追加された3項目、「変更の範囲」の書き方、明示のタイミングと最新に保つ義務の一次情報として（2026年8月確認）
2. *2　参考：厚生労働省「令和6年4月より、募集時等に明示すべき事項が追加されます」（https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/koyou_roudou/koyou/haken-shoukai/r0604anteisokukaisei1.html）。改正職業安定法施行規則についての資料の掲載元として（2026年8月確認）
3. *3　参考：独立行政法人情報処理推進機構「デジタルスキル標準 ver.2.0」（2026年4月16日公開）（https://www.ipa.go.jp/jinzai/skill-standard/dss/rcu1hd000000j76k-att/dss_ver2.0.pdf）。類型・ロール・共通スキルリストの構成、5カテゴリー13サブカテゴリー、重要度a〜dおよびzの定義の確認として（2026年8月確認）

Tweet