FDE（Forward Deployed Engineer：顧客や利用現場に深く入り込み、課題特定から試作・本番定着までを主導するエンジニア）の採用要件は、案件で担う作業工程、本人の決定権、社内の支援体制を明確にし、入社時に求める実務経験と入社後に支援で補う領域を整理して定めます。各社の求人要件を単純に足し合わせても、自社の開発現場に合致した募集条件にはなりません。本記事で提示する設計表や求人票ひな型は編集部作成の試用前テンプレートであり、特定企業での有効性を検証した普遍的な採用基準ではありません。採用設計で最初に行うべき作業は、自社案件でFDE本人に委ねる作業責任と周囲が支援できる範囲を先に確定することです。
共通架空案件における担当範囲と決定権の整理
案件の担当範囲と決定権を曖昧にしたまま採用要件を定めると、応募者に過剰な自律性を要求したり、現場の受け入れ体制と乖離した選考基準を設けたりする原因になります。
ここでは具体的な設計対象として、編集部作成の架空案件「社内規程の問い合わせに対する回答候補を担当者へ提示する支援システム」を扱います。この案件の目的は、問い合わせ対応担当者が規程を探し、回答案を作成する作業を補助することです。現時点での利用件数、現行の処理時間、正答率は未計測という前提です。依頼部門から全件自動回答の要望が出ている場合でも、規程の誤解釈による影響を防ぐため、システムによる利用者への自動送信や申請の自動承認は対象外とします。
本案件では、対象範囲の確定は業務責任者が行い、規程の正本管理や解釈は規程管理者が判断します。認可（Authorization：特定リソースへのアクセス可否を制御する仕組み）仕様の策定や停止基準の承認をFDE一人へ集約させてはなりません。以下の表は、本架空案件における工程別の責任分担と協働体制を整理したものです。
| 工程 | FDEが担当する作業 | 最終決定者 | 協働相手 | 引き継ぎ先 | 本案件の対象外事項 |
|---|---|---|---|---|---|
| 課題整理 | 業務フローの整理、対象範囲の特定、制約事項の洗い出し | 業務責任者 | 問い合わせ窓口担当者 | なし | 全件自動回答化、自動承認 |
| 規程調査 | 規程台帳の確認、版や有効期間の確認、不一致箇所の抽出 | 規程管理者 | 規程管理者 | なし | FDEによる独自の規程解釈 |
| 権限設計 | 参照可能グループの確認、認可仕様の策定 | セキュリティ担当 | インフラ担当 | セキュリティ担当 | 未承認グループへの回答開示 |
| 最小実装 | 回答候補提示、根拠提示、不一致時の保留処理の実装 | 開発責任者 | なし | 運用担当 | 特定製品の無条件導入 |
| 評価検証 | 失敗ケースの定義、架空入力に対する精度検証と記録 | 業務責任者 | 問い合わせ窓口担当者 | なし | 未計測数値に基づく効果保証 |
| 運用移行 | 監視手順書の作成、手動切り替えフローの策定、共通部品化 | 業務責任者 | 運用担当 | 運用担当 | 無人での継続運用 |
FDEは規程の最終的な解釈者ではなく、不明点や資料間の不一致を発見して規程管理者へ確認を戻す役割を担います。また、本番環境への移行判断や停止判断は業務責任者が行い、稼働後の監視や手動対応は運用担当が引き継ぎます。会社側が用意する決定権の境界と支援体制を先に定義することで、候補者個人に依存しない実務の枠組みが定まります。立ち上げ期に推進者個人へ依存してしまう失敗を避けるためにも、中小企業のAI導入 失敗パターン7選を参考に組織的な体制を整えます。
自社が抱える業務課題に対して、どこまでをAIや自動化の対象とし、どこに人間の判断を残すべきか整理する際は、AI自動化診断（Walker’s）を活用して前提条件を点検できます。
担当責任から必須要件と歓迎要件への変換
求人票の必須要件は他社求人の記述を転載するのではなく、担当作業の難度、立ち上がりに必要な時期、現場で実際に提供できる支援体制から判断して設定します。
他社の公開求人を確認すると、求める経験の記述は各社で異なります。JDSCの求人票（herp.careers）では開発経験2年以上や曖昧な状況での課題整理経験を必須とし、AIプロジェクト経験は不問としています。ソフトバンクの求人票（softbank.jp）では5年以上の開発や技術導入経験、LLMや生成AIアプリの構築導入経験、顧客折衝経験を必須に掲げています。また、OpenAIの採用ページ（openai.com）（2026-10-08確認時点）では日英両言語での流暢さを必須とし、「You might thrive in this role if you」節の中で、顧客対応を含む開発や技術導入5年以上の経験、および曖昧な状況での複雑なシステム導入経験などを求める経験の目安として記載しています。自社の採用条件を検討する際は、他社の文面をそのまま写すのではなく、自社の事業方針や支援体制、必要な立ち上がり時期を踏まえて点検することが大切です。
今回の架空案件に基づき、担当責任を必須要件と歓迎要件へ変換した対応表を以下に示します。最初の工程表にある「最小実装」を含め、職務と採用要件を網羅的に対応づけています。なお、ロール（Role：ユーザーの役割や権限区分）やIdP（Identity Provider：認証情報を一元管理する基盤）などのセキュリティ知識について、本案件ではセキュリティ担当によるレビュー体制があるため、入社時の必須は基本の認可実装力にとどめ、高度な連携経験は歓迎要件として扱います。また、運用担当者への手順書作成は職務に含めますが、過去の本番障害対応そのものは入社後の運用チームによる支援で補えるため歓迎要件とします。
- 1. 担当工程と決定権の確定 FDEが自力で遂行する実務と、業務責任者・規程管理者・セキュリティ担当が承認する境界を明確にします。
- 2. 社内支援体制の確認 入社後に協働相手や専任担当がレビュー・伴走・引き継ぎを行える領域を特定します。
- 早期立ち上げが必要／支援下でも自力遂行が必須 【必須要件】として設定 初期の仕様整理や認可の基本実装など、レビュー体制があっても本人が自走できないと案件が停止する項目。
- 社内の専任担当が補完可能 【歓迎要件】として設定 本番障害対応やIdP高度連携など、入社後に運用チームやセキュリティ担当の支援で補える項目。
- 支援体制も未定で要件も不明瞭 案件体制の見直しへ戻る 過剰な自律性を候補者に要求することを防ぐため、求人要件を確定する前に社内の責任境界と支援体制を再設計。
年数による自動判定ではなく、案件の立ち上がり時期と社内支援の有無を基準に分岐させます。
| 工程 | FDEが担当する作業 | 最終決定者 | 協働相手 | 入社時に必要な経験（必須） | 必須とする理由 | 入社後の支援 | 歓迎経験 | 確認する証拠 |
|---|---|---|---|---|---|---|---|---|
| 課題整理 | 業務フロー整理と対象範囲特定 | 業務責任者 | 窓口担当者 | 曖昧な要求から制約と例外を整理した経験 | 初期段階で仕様の骨格を自力で導く必要があるため | 業務責任者が要件確定の壁打ち相手を担当 | 問い合わせ対応の業務設計経験 | 認識齟齬を発見し合意を形成した過去の記録 |
| 規程調査 | 不一致抽出と管理者確認 | 規程管理者 | 規程管理者 | ドキュメント間の矛盾や未定義事項を特定した経験 | 規程の誤解釈を防ぎ確認事項を正確に抽出するため | 規程管理者が正本確認と解釈判断を担当 | 業務マニュアルや規程の整備経験 | 仕様の不整合を指摘し確認を依頼した記録 |
| 権限設計 | 参照権限を守る認可設計 | セキュリティ担当 | インフラ担当 | 認可やロール制御を含むWebアプリケーション開発経験 | レビューがあっても自力で基本仕様を実装できる必要があるため | セキュリティ担当による仕様レビュー | ゼロトラスト環境やIdP連携の設計経験 | 過去に設計したアクセス制御の設計書や実装記録 |
| 最小実装 | 回答候補提示・保留処理の実装 | 開発責任者 | なし | Webアプリケーションまたはバックエンドの実装経験 | 自力で動作可能なプロトタイプを構築する必要があるため | 開発責任者によるアーキテクチャ助言とコードレビュー | 検索拡張生成（RAG）を用いたプロトタイプ実装経験 | 過去に自身が実装したコードや機能仕様の解説記録 |
| 評価検証 | 失敗ケース定義と検証記録作成 | 業務責任者 | 窓口担当者 | 失敗条件を自ら定義してテストや検証を実施した経験 | 不正確な回答を早期検知して停止させる必要があるため | 窓口担当者による検証用シナリオと過去問い合わせ履歴の提供 | 機械学習やLLMの評価基盤の運用経験 | 検証における期待値と失敗例の比較分析記録 |
| 運用移行 | 監視手順と手動切替の設計 | 業務責任者 | 運用担当 | 手順書の作成や他者へのシステム引き継ぎ経験 | 運用担当者が迷わず手動切替を行えるようにするため | 専任運用チームによる監視インフラの提供 | 本番システムの障害対応や監視設計の経験 | 引き継ぎ資料やシステム停止手順の作成記録 |
特定のLLM製品やクラウド基盤の利用経験を一律に必須とする必要はありません。社内にセキュリティ担当やインフラ担当の支援体制があれば、自社の基盤仕様への適応を入社後に補う領域として設定しやすくなります。一方で、認可実装のようにセキュリティレビューがあっても基本的な実装力が求められる領域や、関係者との認識齟齬を発見して仕様に落とし込む経験は、案件初期の停滞を防ぐために必須経験として設定する合理性があります。
求人票ひな型と社内レビューの実施手順
求人票の公開前には現場責任者、人事、法務がそれぞれの観点から記載内容を推奨手順として精査し、過度な要求や誤認を招く表記を排除します。
現場責任者は実際の作業範囲と支援体制が現場の実態と合致しているかを確認します。人事は求める経験と市場での募集可能性のバランスを確認します。法務は業務範囲の表記が雇用契約の実態と整合しているかを確認します。
本記事で紹介した構成の参考として、2026年10月8日公開の初版素材（試用前テンプレート）の圧縮ファイルへのリンクを以下に掲載します。提供ファイルの存在と構成（Markdown求人票とCSV対応表）は確認済みですが、社内レビュー未実施の試用前ひな型であるため、ダウンロード資料をそのまま実務へ適用せず、本文中に提示した設計表やひな型を自社に合わせて調整してご利用ください。
素材ダウンロード：/wp-content/uploads/fde-resources/2026-10-08/fde-hiring-requirements.zip
以下は、架空案件の内容を反映させた求人票の記入例です。フォールバック（障害や異常検知時に代替の手動運用へ切り替える設計）の手順書作成や、本人の決定権と社内承認の境界を明示しています。
# 募集職種: Forward Deployed Engineer (社内規程問い合わせ支援担当)
## 1. 案件の目的と背景
社内規程に関する問い合わせ対応業務において、回答候補を担当者へ提示する支援システムを構築します。
現時点での問い合わせ件数や削減効果などの数値は未計測であり、本試行を通じて業務フローの計測と改善可能性を検証します。
本案件では全件自動送信や申請の自動承認は行わず、担当者の確認を支援する範囲に限定します。
## 2. 担当工程と成果物
* 担当工程: 課題整理、アクセス権限を考慮した最小実装、検証ケースの作成、運用引き継ぎ
* 成果物: 回答候補提示機能、評価検証ログ、運用監視および手動フォールバック（代替手動運用）手順書
## 3. 本人の決定権と承認体制
* 本人が決定できる事項: 最小実装におけるコンポーネント構成の選定、評価テストケースの作成、異常検知時の停止具申
* 社内の承認が必要な事項: 規程の最終解釈（規程管理者が承認）、システム基本構成の確定（開発責任者が承認）、認可仕様の確定（セキュリティ担当が承認）、評価の合格基準の確定および本番公開・緊急停止の最終判断（業務責任者が承認）
## 4. 必須とする経験・能力
* Webアプリケーションまたはバックエンドシステムの設計・開発経験
* 仕様が確定していない状況において、関係者へのヒアリングを通じて制約条件や例外ケースを整理した実務経験
* ドキュメント間の矛盾や未定義事項を特定し、関係者と合意形成を行った実務経験
* 認可制御やロール管理を伴う機能の実装実務経験
* 自らテストケースや検証条件を設計し、システムの不具合や失敗例を分析した経験
* システムの引き継ぎ資料や運用手順書を作成した経験
## 5. 歓迎する経験・能力
* 問い合わせ対応業務のフロー設計や業務改善の経験
* LLMや検索システム（RAG：検索拡張生成）を用いたプロトタイプ開発または評価の経験
* ゼロトラスト環境やIdP（ID管理基盤）連携の設計経験
* 本番システムの障害対応や監視設計の経験
## 6. 社内の協働職種と支援体制
* 業務責任者が週次で要件の優先順位付けと意思決定を支援します。
* 規程管理者が規程の正本確認と解釈判断を担当します。
* 開発責任者が基本アーキテクチャの助言とコードレビューを実施します。
* セキュリティ専任担当が認可設計のレビューを実施します。
* 稼働後のシステム監視と手動切り替えの一次対応は専任の運用担当チームが引き継ぎます。
## 7. 選考プロセスで確認する職務上の証拠
* 書類選考: 過去の開発実績において、自身が担った役割、決定権、直面した課題の整理記録
* 一次面接: 仕様の曖昧さや関係者間の不一致を解消した具体的な過去の行動事例
* 実技選考: 矛盾する資料や制約条件が与えられた状況下での設計判断と実装課題
求人票を作成した後は、面接における質問設計や実技課題の設計へ移行します。選考段階での行動証拠の評価方法はFDE面接評価の設計（/guide/fde-interview-evaluation/）を参照してください。また、受験者の設計判断を確かめる実技試験の設計手順はFDE採用課題の設計（/guide/fde-hiring-assignment/）で解説しています。エンジニア視点でのFDEの役割理解についてはFDEのキャリア解説（/guide/fde-career-engineer/）も合わせて確認してください。
よくある質問
他社求人の経験年数や技術要件をそのまま採用条件に使えるか
そのまま転載して自社の採用条件に設定することは適切ではありません。他社の必須要件は、その企業が想定する案件の難易度、任せる決定権の範囲、社内の技術支援体制を前提に組まれているためです。自社に業務責任者やセキュリティ担当の支援がある場合は、過度な実務年数や特定技術の経験を求めず、業務整理や認可設計の基礎経験があれば自社で立ち上げられる場合があります。
必須要件と歓迎要件を分ける判断材料は何か
自社案件の担当作業の難易度、早期立ち上がりの必要性、現場で実際に提供できる支援体制の3点から総合的に判断します。例えば本架空案件では、セキュリティ担当によるレビュー体制を用意しているものの、認可制御のコードを自力で書けなければプロトタイプ開発が進まないため、認可開発経験を必須要件に設定しています。一方で本番障害対応の経験などは、稼働後に専任の運用チームが監視と一次対応を巻き取れる体制があるため歓迎要件に留めています。このように、支援の有無によって必須と歓迎の境界を切り分けます。
一人のFDEに任せる範囲と会社が提供する支援の書き方はどう整理すべきか
FDEが担当する作業工程と本人が持てる決定権を明記した上で、隣接する工程の最終決定者と協働職種を対比させて記載します。「規程の最終解釈は規程管理者が行う」「本番環境の公開と停止は業務責任者が承認する」といった承認の境界を明文化することが有効です。あわせて、セキュリティレビューの実施体制や運用引き継ぎ先のチームを求人票に明記することで、候補者が入社後に背負う責任の範囲を具体的に示せます。
試用前の求人票ひな型を自社で使う前に誰が何を確認すべきか
現場責任者、人事担当者、法務担当者による社内レビューを推奨します。現場責任者は作業範囲と支援体制が実際の案件体制と乖離していないかを点検します。人事担当者は必須条件が労働市場に対して過剰に狭き門になっていないか、選考基準と連動しているかを確認します。法務担当者は職務内容の表記が雇用条件や法令上の要件を満たしているか、誤認を招く表記がないかを点検します。
参考資料
本記事における職務整理や他社要件の比較分析にあたり、以下の公開情報および企業発信を参照しています（各社の採用基準そのものを本記事が保証するものではありません）。
- Insight Edge Tech Blog：当社がForward Deployed Engineer(FDE)職を新設した背景と狙い（2026-07-03公開・2026-10-08確認） – 現場常駐型とビジネス推進を担うFDEの類型整理
- LayerX 採用情報：Ai Workforce事業の募集一覧（2026-10-08確認） – 顧客課題の特定からプロダクト連携を担うエンジニア職務の事例
- JDSC 採用情報：【Dev】FDE【正社員】（2026-10-08確認） – 開発経験2年以上・AI未経験可とする求人事例
- ソフトバンク 採用情報：AIエンジニア（Forward Deployed Engineer）（2026-10-08確認） – 開発5年以上・LLM導入経験を必須とする求人事例
- OpenAI Careers：Forward Deployed Engineer – Tokyo（2026-10-08確認） – 顧客対応を伴う技術導入経験を求める求人事例
自社案件におけるFDEの担当範囲や必要なスキルセットの定義にお悩みの企業担当者様は、業務プロセスの可視化と自動化範囲を診断するAI自動化診断（Walker’s）をご利用ください。現場の実態に合わせたエンジニアリング支援やPoC開発体制の構築については、Walker’sの開発支援サービスにてご相談を受け付けています。
