FDE育成はどう進める？90日ロードマップと社内で育てる評価設計

FDE育成はなぜ中途採用より難しいのか？

FDE育成が難しいのは、技術力ではなく顧客業務へ踏み込む判断力を、社内に教材のないまま伝える必要があるからだ。

FDE（Forward Deployed Engineer）は、Palantirが職種名として広めた「顧客の現場に入り込み、自社プロダクトを顧客の業務に接続して成果まで持っていくエンジニア」を指す。採用市場でこの肩書きを持つ人材を探すアプローチは、母集団の薄さという構造的な壁にぶつかる。結果として、多くの企業が「社内のエンジニアをFDEに育てる」という選択に向かうことになる。

なお、本記事に登場する期間や配分は、国内でFDE的な役割を立ち上げる際に一般的とされる進め方を踏まえた目安であり、特定企業の実績値ではない。自社の案件サイクルと等級表に合わせて読み替えてほしい。

市場に「FDE経験者」はほぼ存在しない

FDEを名乗る経験者は国内にごく少数で、中途採用だけで枠を埋める前提はほぼ成立しないと考えたほうがよい。

FDEという職種名が広く使われ始めたのは、Palantirの採用ページやエンジニアリングブログを通じて概念が輸入されて以降であり、日本の労働市場では歴史が浅い。厚生労働省の職業分類にも独立した区分は存在しない。つまり、求人票に「FDE経験3年以上」と書いても、応募母集団はSIerのプリセールスエンジニア、コンサルティングファーム出身のエンジニア、プロダクト企業のカスタマーサクセスエンジニアといった隣接職種からの越境者で構成されることになる。

隣接職種からの採用は有効だが、これは「経験者採用」ではなく「素地のある人材の中途育成」である。採用した時点で育成計画が必要になる点は、社内育成とほとんど変わらない。

育つべきものが「技術」より「踏み込む判断」だから

FDE育成の核心は、顧客の業務に対してどこまで踏み込むかという判断で、これは座学では移せない。

現場で見ていて差が出やすいのは、顧客が「この機能が欲しい」と言ったときの反応だ。要望をそのまま実装仕様に変換する人と、その要望の背後にある業務上の困りごとまで一段掘る人とで、半年後の成果物の価値が大きく変わる。この掘り下げは、手順書に落とすことが難しい。

だからFDE育成は、研修カリキュラムよりも実案件の中でどう経験を配置するかの設計に比重が寄る。以降の章では、その配置を90日という単位で組む方法を扱う。

FDE育成の90日ロードマップはどう組むのか？

FDE育成の90日は、0〜30日で業務理解、31〜60日で小さな担当、61〜90日で顧客前の意思決定に配分する。

90日という区切りに絶対的な根拠があるわけではないが、四半期の案件サイクルと評価面談の周期に合わせやすく、育成の進捗を経営に報告する単位としても扱いやすい。

0〜30日：観察と業務理解に振り切る

最初の30日は実装を求めず、顧客の業務フローと用語を自分の言葉で説明できる状態を到達点に置く。

この期間に成果物を求めたくなるのが人情だが、急がせるほど後で戻る。おすすめしたいのは、業務フロー図と用語集を本人の手で作らせることだ。既存資料を渡すのではなく、顧客へのヒアリングから自分で書き起こす。この作業は、「何がわかっていないか」を本人と育成担当の双方に可視化する装置として機能する。

• 顧客の定例会議に同席する（発言は求めない）
• 現場の担当者に1対1で業務の流れを聞く
• 顧客固有の略語・帳票名・システム名を用語集にまとめる
• 既存データの実物を見て、仕様書との差分を洗い出す

最後の項目は特に重要だ。仕様書とデータの実態が食い違う箇所こそ、後の案件で最も工数を食う場所である。

31〜60日：小さく閉じた担当範囲を渡す

31日目以降は、失敗しても案件が傾かない範囲を切り出し、要件定義から実装まで一周させるのが有効だ。

ここでの設計上のポイントは、「工程を切る」のではなく「範囲を切る」ことにある。実装だけを渡すと、いつまでも要件定義の経験が積めない。小さくても構わないので、顧客に聞く→決める→作る→見せるを通しで一周させる。

範囲の切り出し方の目安としては、1〜2週間で一周でき、失敗しても顧客の本番業務が止まらない領域を選ぶ。既存レポートの1本を作り直す、手作業で運用されている集計を自動化する、といった規模感が扱いやすい。

61〜90日：顧客の前で判断させる

61日目からは顧客との場に単独で立たせ、要望の取捨選択を本人に決めさせる経験を意図的に作る。

FDEと通常の開発職を分ける最大の要素は、顧客の前で判断する場数だと考えている。上長が同席していると、顧客も本人も自然と上長を見る。この構造が続く限り、判断の経験は蓄積されにくい。

とはいえ、いきなり全面的に任せるのはリスクが高い。実務的には、打ち合わせには同席せず、事前の作戦会議と事後の振り返りに時間を厚く配分する形が現実的だろう。判断の場そのものは本人に、判断の質のレビューは育成担当にという分担である。

FDE育成で伸ばすスキルの階層はどう分かれるのか？

FDEのスキルは、エンジニアリング基礎・ドメイン翻訳・関係設計の三層に分かれ、下から順に積む必要がある。

この三層を混ぜて評価すると、育成計画が「なんとなく全部やる」に崩れる。層ごとに到達基準を分けて持つことが、育成の解像度を上げる。

第1層：一人で作り切るエンジニアリング基礎

土台は、データ整備から実装・運用までを一人で通せる力で、ここが欠けると顧客前で身動きが取れなくなる。

FDEは顧客先で「これ、今できますか」と聞かれる職種だ。その場で見通しが立つかどうかは、技術の幅に直結する。特にデータの前処理と、動かし続けるための運用設計は、Palantir Foundryのような基盤を扱う場合でも自前の仕組みを組む場合でも共通して効いてくる。

逆に言えば、第1層が不足している人材をFDEに配置するのは避けたほうがよい。顧客対応の負荷が加わることで、技術の学習速度はむしろ落ちる。

第2層：業務言語とシステム言語を往復する翻訳力

FDEの中核は翻訳力で、現場の言い回しをデータ構造に、システム制約を業務の言葉に戻せることを指す。

翻訳は双方向であることに意味がある。顧客の言葉を仕様に落とす方向だけを鍛えると、「できません」としか言えないエンジニアになる。制約を業務の言葉で説明し、代替案を業務のメリットとして提示できて初めて、顧客の意思決定に関与できる。

育て方としては、本人が書いた仕様書を顧客の現場担当者に読んでもらい、違和感を指摘してもらう回路が効きやすい。育成担当のレビューだけでは、業務側の違和感は拾えない。

第3層：顧客との関係と期待値を設計する力

上層は関係設計で、何を約束し何を断るかを自分で線引きし、顧客の期待値を運用する技能にあたる。

この層は最後に育つ。断る判断には、案件全体の損益と自社の方針への理解が要るからだ。育成の初期に「顧客に嫌われないこと」を過度に強調すると、断れないFDEができあがる。90日を超えた先の課題として位置づけるのが妥当だろう。

FDE育成の成果はどの指標で評価すべきか？

FDE育成の評価は稼働時間や実装量ではなく、顧客側に起きた変化と再現性の二軸で測るのが妥当である。

FDEは顧客先で働く時間が長く、社内からは活動が見えにくい。この見えにくさを稼働報告で埋めようとすると、報告のための報告が増える。測るべきは、顧客の業務がどう変わったかである。

顧客側の変化を一次指標に置く

一次指標は顧客の業務がどう変わったかで、削減工数や意思決定までの日数など事前に測れる形にしておく。

重要なのは、着手前に測っておくことだ。改善後にしか数字がない案件は、成果を語れない。育成中のFDEには、この事前計測を最初の仕事のひとつとして渡すとよい。

育成の進捗は「任せられる範囲」で段階評価する

育成の進み具合は、同席が必要か単独で任せられるかという裁量の広がりで段階化するのが実務的だ。

1. 同席レベル：育成担当の同席が必須。発言は限定的
2. 持ち帰りレベル：単独で顧客と話せるが、判断は持ち帰る
3. 判断レベル：その場で要望の取捨選択ができる
4. 設計レベル：案件の進め方とスコープ自体を顧客と設計できる
5. 育成レベル：次のFDEを育てられる

90日の到達点は、多くの場合2から3の境目あたりになる。4以上は年単位の話だと考えたほうが、期待値としては現実的だろう。

FDE育成でよくある失敗パターンは何か？

FDE育成の失敗は、常駐させれば育つという放置、育成担当の不在、開発職の物差しでの評価に集約される。

失敗1：顧客先に置けば育つと考える

常駐は育成条件のひとつにすぎず、振り返りの設計がなければ経験は本人の中に整理されないまま流れる。

顧客先に長時間いることと、経験が構造化されることは別物だ。週に一度30分でよいので、「今週、顧客の発言で意味がわからなかったものは何か」「判断に迷った場面はどこか」を言語化させる時間を確保したい。この振り返りがないと、3か月経っても業務の理解が表層に留まりやすい。

失敗2：育成担当を置かず案件のOJTに丸投げする

案件責任者と育成担当が同一だと納期が優先され、育成は必ず後回しになるため役割を分けるほうがよい。

案件責任者は納期と品質に責任を持つ。育成のために非効率な進め方を許容するインセンティブが構造的に働かない。可能であれば、案件から一歩引いた立場の育成担当を別に置き、その人の評価項目に育成成果を入れる。これは組織設計の問題であり、本人の努力では解消できない。

失敗3：既存の開発職の評価表をそのまま当てる

開発職の評価表を流用すると顧客対応の価値が評価に載らず、育成した人材から先に離職しやすくなる。

コード量やアーキテクチャ設計を中心に据えた評価表では、顧客の業務を解きほぐした時間が「開発していない時間」として扱われる。せっかく育てたFDEが、評価されないことを理由に開発組織へ戻る、あるいは社外へ出るという流れは避けたい。

対策は難しくない。評価表に「顧客の業務理解」「期待値の設計」「内製移管の進捗」といった項目を明示的に足し、等級ごとの到達基準を書き下すことだ。VACAN Technologiesを含め、FDE的な役割を社内に置く企業がまず整備すべきは、研修カリキュラムより先にこの評価表だと考えている。

FDE育成は、90日で完成するものではない。ただし90日は、「この人はFDEとして伸びるか」を判断し、育成計画を次の四半期に接続するには十分な長さだ。観察・小さな担当・顧客前の判断という三段の配置と、顧客側の変化で測る評価。この二つを先に用意してから最初のFDE候補を送り出すことを勧めたい。

姉妹メディアの関連記事