FDE採用要件の書き方｜求人票の作り方
日本FDE協会です。FDE人材を採りたいと思って求人票を書き始めると、多くの採用担当者が「顧客の現場に入り込むエンジニア」という抽象的な一文で止まってしまいます。しかしこの書き方では、応募者が本当に実務を回せる人かどうか見極められません。この記事を読めば、あなたがFDE 採用要件を求人票に落とし込み、必須要件・歓迎要件・任せる案件規模を具体的な言葉で書き分けられるようになります。応募段階で「どこまで単独で任せられる人か」を明文化する、そのドラフトを自分で作れる状態を目指します。なお、ここでいうFDEはForward Deployed Engineer（顧客の現場に入り込むエンジニア）を指します。ディスク暗号化（Full Disk Encryption）のFDEとは別物です。
※本記事は「採用の要件定義（求人票の書き方）」がテーマです。案件そのものの要件定義とは別テーマなので混同にご注意ください。
FDE 採用要件は「案件のリスク階層」から逆算する
求人票がぼやける最大の原因は、募集する前に「この人にどんな案件を任せるのか」を決めていないことです。FDEの仕事は、顧客の現場業務をヒアリングして整理し、AIやワークフローで改善し、運用まで定着させる一連の流れです。ただし、任せる案件の規模とリスクによって、必要な力はまったく変わります。
まず任せる案件を3段階で言語化する
求人票を書く前に、任せたい案件を次のように分けて言語化してみてください。この整理が要件定義の土台になります。
案件層 | 典型的な内容 | リスクの重さ |
|---|---|---|
小規模 | 1部署の定型業務の改善・小さな自動化 | 限定的（影響範囲が狭い） |
中規模 | 部門横断の業務設計・データ連携 | 権限や統制の考慮が必要 |
高リスク | 全社導入・監査対応・個人情報を扱う基幹業務 | 内部統制・監査証跡が必須 |
この層が決まると、求人票に書くべき要件が自然と定まります。逆にここが曖昧なまま「FDE募集」と出すと、応募者も自分が合うか判断できません。
必須要件と歓迎要件を書き分ける
要件は「必須」と「歓迎」を明確に分けます。ここを混ぜると、応募のハードルが上がりすぎたり、逆に力不足の人が集まったりします。
必須要件は「単独で回せる最低ライン」
必須要件は、任せる案件層を単独で完遂できる最低条件に絞ります。抽象語ではなく行動で書くのがコツです。例えば小規模案件なら、次のような書き方です。
- 現場担当者にヒアリングし、業務フローを図や文書に整理できる
- AIツールやノーコード/ローコードで、動くものを短期間で試作し改善提案できる
- 作った仕組みの手順を第三者が引き継げる形で文書化できる
前川会長は大手エンジニアリング企業で、石油コンビナート向け入出荷管理などの案件を上流設計から運用保守まで自分で手を動かしてきました。その経験から、必須要件には「完璧な設計書を書ける」ではなく「まず動くものを見せてフィードバックを得られる」力を据えることを重視しています。要件定義書を待つより、試作で会話が進む人のほうが現場では強いからです。
歓迎要件は「案件層を上げるための力」
歓迎要件には、より重い案件を任せられるようになるための力を書きます。中規模以上を見据えるなら、部門をまたぐ調整力、データ設計の経験、AIエージェントやRAG（社内文書を検索して回答に使う仕組み）の設計経験などが該当します。歓迎要件は「あれば案件層を引き上げられる」という位置づけで書くと、応募者にも成長余地が伝わります。
統制・監査・属人化防止を求人票の言葉にする
ここが、一般的なFDE求人ではほぼ抜け落ちる部分です。多くの求人票は「AIを使える」「現場に入れる」で止まりますが、高リスク案件を任せるなら、統制と監査への遂行力を要件として明記しなければなりません。
見極めたい3つの遂行力
権限管理やアクセスログを踏まえた設計ができるか。職務分掌や監査証跡を意識して、後から「誰が何をしたか」を追える仕組みを組めるか。そして、作った本人しか触れない状態を避け、ドキュメント化と引き継ぎを前提に進められるか。この3点は、求人票に次のような一文で落とし込めます。
- 「権限・ログ・監査証跡を考慮した業務設計ができる方（高リスク案件を担当いただく場合は必須）」
- 「属人化を防ぐため、運用手順の文書化と引き継ぎ設計を前提に業務を進められる方」
あるSaaS企業の経営者と話したとき、社内でAIを触れる人が一人に偏り、その人が休むと業務が止まるという悩みを聞きました。属人化の典型です。求人票に引き継ぎとドキュメント化を要件として書いておくだけで、こうした事態を防げる人材を集められます。スキル領域そのものを詳しく知りたい方はFDEに必要なスキルの全体像もあわせてご覧ください。
セキュリティ要件は文脈を明確に書く
求人票にセキュリティ要件を書く際は、Full Disk Encryptionのような技術要素と混同されないよう、「情報セキュリティ・権限管理・ログ管理を踏まえた導入設計」のように業務文脈で明記します。応募者の受け取り方を揃えることも、要件定義の一部です。
等級を要件に組み込むときの注意
「どこまで任せられる人か」の目安として、FDE検定の等級を求人票に併記する企業もあります。等級は認定する能力の目安として使えますが、書き方には注意が必要です。
等級は「能力の目安」として書く
FDE検定は協会が独自に運営する民間認定で、国家資格でも名称独占・業務独占資格でもありません。資格の有無が業務従事を法的に制限することはありません。したがって求人票では「3級相当の能力を歓迎」のように能力の目安として書き、資格を応募の絶対条件にする必要はありません。認定する能力の目安は次の通りです。
等級 | 認定する能力の目安 |
|---|---|
3級 FDEプラクティショナー | 独立して小規模案件を担当できる（中小企業・部門単位） |
2級 FDEシニア | 複数部門・高リスク案件（企業横断） |
1級 FDEアーキテクト | 大規模導入責任者・監査対応（全社・公共性の高い案件） |
顧客や現場に対しては、等級を超える案件を単独で受任することは協会規程に反し認定の対象外である、という自主規律があります。これは法的制限ではなく協会規程上の位置づけですが、任せる案件層と等級を対応づけて求人票を書くと、双方の期待がずれません。等級の全体像はFDE検定とは？をご参照ください。なお、検定の取得と報酬の間に因果を約束するものではありません。
よくあるご質問
Q. FDE 採用要件を書くとき、まず何から決めればよいですか？
A. 任せる案件のリスク階層です。小規模・中規模・高リスクのどれを任せるかを先に言語化すると、必須要件と歓迎要件が自然に定まります。案件層が曖昧なまま募集すると、応募者も自分が合うか判断できません。
Q. 求人票にFDE検定の等級を必須条件として書くべきですか？
A. 必須にする必要はありません。FDE検定は民間認定で、資格の有無が業務従事を法的に制限することはありません。等級は「認定する能力の目安」として、任せる案件層と対応づけて歓迎要件などに書くのが実務的です。
Q. 統制や監査の要件は、すべての求人に書くべきですか？
A. 任せる案件層によります。個人情報や基幹業務を扱う高リスク案件を任せるなら、権限・ログ・監査証跡を踏まえた設計力を必須要件に含めます。小規模案件中心なら歓迎要件で十分な場合もあります。
FDEの採用要件づくり・人材育成のご相談はお気軽に
日本FDE協会
FDE（Forward Deployed Engineer）の認知拡大・人材育成・コミュニティ形成を目的とした協会です。技術とビジネスの双方を現場で実践するエンジニアを支援しています。