FDEの職務経歴書の書き方｜通過率を上げる構成と実績の書き分け例

FDEの職務経歴書では何が評価されるのか？

FDEの職務経歴書では、扱った技術の網羅性より「曖昧な要望をどう課題に変え、何を動かしたか」が評価されます。 FDE（Forward Deployed Engineer）はPalantirが定義した、顧客の現場に入り込んで実装まで担う職種です。したがって書類選考でも、一般的なソフトウェアエンジニア（SWE）採用のように言語・フレームワークの一覧を確認して終わり、とはなりません。「誰の、どんな困りごとを、どう解いたか」が読み取れない経歴書は、技術要件を満たしていても通過しにくいのが実情です。

採用側は職務経歴書のどこを最初に読むのか？

採用側はまず職務要約の3〜5行を読み、そこで「顧客と作った経験があるか」を判断します。 冒頭で技術スタックの羅列から入る経歴書は、SWEの応募として処理されやすくなります。FDEを狙うなら、要約の1行目に「顧客先に入り、要件が固まっていない状態から動くものを届けてきた」という自分の立ち位置を置くのが有効です。

現場の実務者からは、「職務要約と直近1〜2案件の記述で大半の印象が決まるため、古い案件を丁寧に書くより直近を厚くしたほうが効率がよい」という声が聞かれます。読む側の時間は限られており、全案件を均等に書くと焦点がぼやけるという見立てです（企業や選考フェーズによって重心は変わるため、絶対的な作法ではありません）。

FDEで加点される記述と減点される記述は？

加点されるのは「判断」と「顧客接点」が見える記述、減点されるのは作業内容だけの記述です。 同じ案件でも、書き方によって伝わる情報量は大きく変わります。

減点側の記述に共通するのは、主語が「案件」になっていて「自分」が見えない点です。FDEの選考では、チームの成果ではなく応募者個人が何を決めたかが問われます。求められる能力の全体像はFDEに必要なスキル、職種そのものの定義はFDEとはで整理しています。

FDEの職務経歴書はどんな構成で書くべきか？

構成は「職務要約→スキル→案件詳細（新しい順）→自己PR」の4ブロックが基本で、案件詳細に最も紙幅を割きます。 特殊な様式は不要で、一般的な日本の職務経歴書のフォーマットのままで構いません。重要なのは順序と分量配分です。A4で2〜3枚に収め、そのうち半分以上を直近2〜3案件の記述に充てるのが扱いやすい形です。

全体構成は何をどの順で並べるか？

先に結論（何ができる人か）を置き、根拠となる案件を新しい順に並べる逆ピラミッド型が読みやすい構成です。 時系列の古い順から書くと、読み手が最も知りたい直近の実力に到達するのが遅れます。

1案件あたりの記述テンプレートは？

1案件は「顧客・課題・役割・打ち手・結果」の5項目で書くと、読み手が判断材料を取り出しやすくなります。 箇条書きで以下の順に固定すると、案件が変わっても比較しやすい経歴書になります。

1. 顧客と背景：業界と規模、なぜその依頼が発生したか（社名は開示可能な範囲で）
2. 課題：顧客が最初に言っていた要望と、実際の真因のずれ
3. 自分の役割：チーム人数と、その中で自分が担当・決定した範囲
4. 打ち手：使った技術と、そこで下した設計上の割り切り
5. 結果：定量または定性の変化と、その後の運用・展開

この5項目のうち、SWE出身者が抜けやすいのは1と2、コンサル出身者が抜けやすいのは4です。書き終えたら、自分の経歴書で薄いのがどちらかを確認しておくと、面接での質問の当たり所も予測しやすくなります。面接段階の準備はFDE面接対策と合わせて進めると重複が減ります。

FDEの実績はどう書けば伝わるのか？

実績は「変化の前後」をセットで書くと伝わり、数値がなくても状態の差分で代替できます。 「◯◯を構築した」だけでは、それが顧客にとって何の意味を持ったのかが読み手に伝わりません。着手前の状態と着手後の状態を並べる書き方が、最も少ない文字数で価値を示せます。

数値が出せない実績はどう表現するか？

守秘義務で数値を出せない場合は、割合・頻度・所要時間・関与人数のいずれかに置き換えます。 実額や実件数を書けない案件は珍しくありませんが、そこで「効率化に貢献」とだけ書くと情報がゼロになります。

実務者の間では、「数値を盛るより、測っていない事実を正直に書いて、代わりに現場の変化を具体的に描くほうが面接で崩れない」という考え方がよく語られます。書類で作った数字は、面接で前提条件を問われた瞬間に説明できなくなるためです。

顧客折衝の実績はどう言語化するか？

折衝の実績は「対立が起きた場面」と「自分が下した判断」を書くと、調整力の実体が伝わります。 「顧客と良好な関係を構築」といった記述は、ほぼすべての応募者が書けてしまうため差になりません。

書きやすい題材は次の4つです。

1. 顧客の要望を断った、または代替案に置き換えた場面
2. 仕様変更を受け入れた代わりに、別の何かを外す交渉をした場面
3. 非エンジニアの担当者に、技術的な制約を説明して合意を得た場面
4. 現場のユーザーと管理部門で意見が割れたときの調整

いずれも「相手がこう言った→自分はこう判断した→結果こうなった」の3文で足ります。うまくいかなかった案件を1つ入れておくと、その後の学びとセットで信頼性が上がる、という見方もあります。

未経験や異職種からFDEを狙う場合はどう書くのか？

未経験からの応募では、FDEの仕事に構造が近い経験を自分の職歴から翻訳して並べ直すのが基本方針です。 FDEという肩書での経験がなくても、「相手の言葉を課題に変えて、自分で作って届けた」経験は多くの職種に存在します。肩書ではなく行動で書き換えるのが要点です。

SWE・SIer出身者は何を書き足すか？

SWE・SIer出身者は実装力は伝わるため、顧客接点と自分の判断を書き足すのが最短の改善です。 上流から下流までの経験がある一方で、経歴書が担当工程の記述に寄りやすい傾向があります。

書き足す候補は、社内の他部署からの依頼を要件化した経験、非エンジニアへの説明経験、障害対応で顧客と直接やり取りした経験などです。受託開発とFDEの働き方の違いはFDEとSES・受託の違い、SWEとの職務の差はFDEとSWEの違いで整理しています。

コンサル・営業・データ分析出身者はどう書くか？

非エンジニア出身者は、自分が手を動かして作った成果物を具体名で書くことが最優先です。 課題定義や折衝の記述は十分でも、「作れる人」であることが伝わらないと選考が進みません。

補強といっても実績の捏造は不要です。業務外で作った小さなツールでも、「誰の何を解決したか」が書ければ材料になります。異職種からの転向の全体像は未経験からFDEを目指すを参照してください。

職務経歴書とポートフォリオはどう使い分けるのか？

職務経歴書は「判断の履歴」、ポートフォリオは「実装の証拠」を担わせ、内容を重複させないのが使い分けの原則です。 両方に同じ案件説明を書くと分量だけが増え、読み手が得る情報は増えません。役割を分けたうえで、経歴書からポートフォリオへ参照を張る形が扱いやすくなります。

それぞれの役割分担は？

経歴書には文脈と判断、ポートフォリオには動くものとコードを置くと、選考の各段階で必要な情報が揃います。

ポートフォリオを用意する場合、FDE志望であれば「誰かの困りごとを解いた」題材を1つは含めるのが有効だと考えられます。技術デモとしての完成度より、課題設定の妥当性のほうが職種との適合を示しやすいためです。

守秘義務がある案件はどこまで書けるか？

業務案件は、顧客名・固有の数値・画面や設計資料を出さず、業界と課題の型に抽象化すれば記述できます。 迷ったときの基準は「その記述から顧客が特定できるか」「公開資料に載っていない情報を含んでいないか」の2点です。

抽象化の例としては、社名を「従業員千名規模の製造業」、システム名を「基幹システムの在庫管理領域」、実数を「削減率」に置き換える形が挙げられます。契約内容によっては業界の記載すら制限される場合があるため、不安があれば前職・現職の規定を確認するのが安全です。判断がつかない部分は書かずに空けておき、面接で口頭補足する扱いにしても選考上の不利にはなりにくいでしょう。

経歴書は一度書いて完成する書類ではありません。応募先ごとに、職務要約の1行目と直近案件の見せ方だけを調整する運用にすると、更新の負担を抑えながら通過率を上げやすくなります。応募先の選定はFDEを採用している企業、転向後のキャリアの広がりはFDEの次のキャリアを参考にしてください。

姉妹メディアの関連記事