FDE CAREER ARTICLE
FDE転職の職務経歴書テンプレート｜書き方・例文・英語resume
FDE（Forward Deployed Engineer）転職の職務経歴書では、「API開発を担当」「顧客と要件定義を実施」と書くだけでは、仕事の広さと本人の責任が伝わりません。公式求人に書かれた責任へ自分の経験を対応させるには、誰のどの課題に対し、どの制約の中で何を判断し、自分が何を実装し、本番へどう届け、何が変わったかを一つの案件として書きます。
OpenAIの東京向けFDE求人は、課題発見、技術的な対象範囲、システム設計、実装、本番展開、利用定着、業務への影響を挙げています。Google Cloudの東京向けFDE求人も、technical discovery、code・debug、API・既存データ・セキュリティ境界との統合、評価・可観測性を含みます。
本記事では、これらの公式求人と厚生労働省の職務経歴書準拠様式を基に、FDE向けの書類構成へ変換します。FDEの仕事全体は「FDEとは」、転職準備全体は「FDE転職ガイド」で確認できます。
この記事の要点
- 冒頭は職務要約、後半は案件詳細という二層構造にする
- 案件を、顧客課題→制約→本人の判断→実装→本番化→成果→学びの順で書く
- チーム全体の成果と、自分が決めた・実装した範囲を分ける
- 確認できる数字だけを使い、数字がなければ展開範囲、release、運用、品質などの事実を使う
- 顧客名、個人情報、秘密のsystem名、公開許可のない数値・codeは匿名化または非掲載にする
目次
結論：「担当業務」ではなく、課題から成果までを書く
FDE向けの職務経歴書で、最も避けたいのは担当業務と技術スタックだけの羅列です。担当範囲が広いFDEでは、要件定義、開発、導入、運用を別々の箇条書きにすると、同じ課題を最後まで進めたのかが見えません。
一案件につき、次の3つを最初にそろえます。
RESUME EVIDENCEFDE職務経歴書の3つの核
利用者、現状業務、痛点、制約、成功の定義を示す
自分が決め、設計し、書き、releaseした範囲を示す
測定条件、確認日、利用範囲、品質、残課題を事実で示す
FDEの仕事内容や類似職との境界を説明し直す必要はありません。「FDEの仕事内容・必要スキル・類似職との違い」を理解したうえで、自分の実務に含まれる証拠だけを書きます。FDEという肩書きで働いていない場合は、元の職名をFDEへ書き換えず、実際の担当範囲を示してください。
公式求人から逆算する6つの証拠
企業ごとにFDEの責任は異なり、共通の書類評価表は公開されていません。ここでは、現行求人に書かれた責任を、職務経歴書で確認できる証拠へ変換します。
| 証拠 | 公式求人にある責任の例 | 職務経歴書へ書くこと |
|---|---|---|
| 1. 課題発見 | discovery、technical discovery、requirements gathering、open-ended problem | 利用者、現状業務、確認した問い、基準値、解くべき課題 |
| 2. 対象範囲・判断 | technical scoping、deliveryの順序、trade-off、production blockerの解消 | 制約、比較した選択肢、対象外、本人が決めたこと、その理由 |
| 3. 実装 | full-stack、code・debug、integration、data pipeline | 自分が書いた部分、system、API、data、test、主要な技術判断 |
| 4. 本番化・運用 | production rollout、stable production、security、observability | release、権限、monitor、incident、rollback、runbook、保守責任 |
| 5. 利用・成果 | adoption、workflow impact、ROI、accuracy・safety・latency、user iteration | 利用範囲、測定条件、結果、未達、利用者から変えた点 |
| 6. 学習・再利用 | playbook、building block、reusable module、product feedback | 共通化したcomponent、decision log、handoff、次案件での再利用 |
NotionのJapan向けFDE求人は、顧客案件の技術デリバリーをend-to-endで担い、migration、integration、production-gradeのcustom agent・AI workflowを設計・運用するほか、現場の課題をproduct roadmapへ返すfeedback loopや、再利用できるmethodology・internal toolingを挙げています。PalantirのJapan Government向け求人は、open-endedな顧客課題を理解し、solutionをdesign・implementし、技術・非技術の関係者と反復する役割を挙げています。
書類では「顧客対応も開発もできます」と自己評価を書くのではなく、過去案件の中でその両方が接続した証拠を一つ示します。
職務経歴書を「要約＋案件詳細」の二層にする
厚生労働省のジョブ・カード様式案内は、職務経歴書の準拠様式と記入例を提供しています。職務経歴書（ジョブ・カード準拠様式）には、期間、会社・所属・職名、職務内容、職務で得た知識・能力・スキル等の欄があります。
FDE応募では、この基礎情報を残しながら、冒頭の要約と案件詳細を次の二層に分けると責任範囲を追いやすくなります。
READING FLOW採用側が証拠へ進める二層構成
- Summary対象求人に近い経験を3〜5行で提示
- Problem利用者・業務・制約を説明
- Decision本人が決めた範囲と理由
- Build設計・code・integrationの担当
- Productionrelease・品質・運用
- Outcome確認できた変化と学び
| 層 | 含める内容 | 役割 |
|---|---|---|
| 1. 職務要約 | 経験年数、得意領域、顧客・利用部門、実装範囲、本番経験、代表成果を3〜5行 | 対象求人との接点を短く示し、読むべき案件を案内する |
| 2. 職歴の基本情報 | 期間、会社、所属、職名、雇用形態、事業・製品、役割の変化 | 経歴の時系列と前提を正確にする |
| 3. 案件詳細 | 課題、制約、本人の判断、実装、本番化、成果、学び、技術 | 要約の主張を検証できる事例にする |
| 4. スキル・資格 | 技術名、使用期間、使用場面、担当水準、関連案件 | keywordではなく、どこで使ったかへ接続する |
| 5. 公開成果物 | GitHub、case study、登壇、技術記事、公開資料 | 守秘可能な範囲で、実装・説明の追加証拠を出す |
職務要約の記入例
次は架空の記入例です。角括弧を埋めるのではなく、自分の確認可能な事実へ置き換えてください。
法人向けWeb・データ連携の開発に[年数]従事。営業・業務部門へのヒアリングから対象範囲を定め、Python／TypeScriptでAPI・管理画面・データ処理を実装し、クラウド環境へのリリースと運用設計まで担当しました。代表案件では[利用者・業務]を対象に、[確認できた成果]を達成。顧客固有の連携を[共通部品・手順]へ整理し、[再利用した範囲]へ展開しました。
年数、成果、展開は実績に合わせます。FDE経験がない場合に「FDEとして従事」とは書かず、実際の職名とFDEへ接続する経験を示します。
コピーして使える一案件の職務経歴書テンプレート
一つの案件を次の形で整理します。`[チーム]`と`[本人]`を分けることで、成果を小さく見せず、担当範囲も誇張しません。
## [案件名または公開可能な一般名]
期間: [YYYY年MM月〜YYYY年MM月]
会社・所属・職名: [事実]
体制: [チーム人数／主なrole。公開可能な範囲]
顧客・利用者: [匿名化した業界・部門・利用者]
### 1. 課題
- [事実] 導入前の業務flow:
- [事実] 起きていた問題・基準値:
- [事実] 誰に何を確認したか:
- [仮説] 当初の原因・解決仮説:
### 2. 制約と対象範囲
- 制約: [既存system、data、security、期限、体制、予算]
- 今回の対象: [解く範囲]
- 対象外: [解かない範囲]
- 成功指標: [指標、測り方、比較対象]
### 3. 本人の判断・責任
- [本人] 決めたこと:
- [本人] 比較した選択肢:
- [本人] 採用理由・trade-off:
- [チーム] 他のmemberが決めたこと:
### 4. 設計・実装
- [本人] 実装した機能・component:
- architecture／data flow:
- API／data／外部systemとの統合:
- test／review:
- 使用技術: [用途と担当水準を併記]
### 5. 本番化・運用
- release方法・担当:
- 認証・権限・security:
- log・monitor・alert:
- incident・rollback・manual fallback:
- 引き継ぎ・runbook・長期保守者:
### 6. 成果
- [チーム成果] 業務・事業上の変化:
- [本人の寄与] その成果へ直接行ったこと:
- 測定条件・確認日:
- 未達・残課題:
### 7. 学び・再利用
- feedbackから変えた点:
- 共通化したcomponent／playbook:
- 次案件・productへ戻した内容:
- 次に改善すること:
関連skills: [技術名ではなく、上記の使用場面へ対応]
公開links: [GitHub／case study／記事。公開許可済みのみ]
制作物そのものを見せる場合は、「FDEポートフォリオの題材・READMEテンプレート」を使います。職務経歴書は読み手が短時間で責任範囲を理解する要約、ポートフォリオは設計・code・評価を追加確認する証拠と分けます。
職種別に「弱い表現」を書き換える
以下はすべて架空の例です。数値や成果をそのまま流用せず、自分の実績へ置き換えてください。
| 出身職種 | 弱い表現 | FDE向けに確認しやすい表現 |
|---|---|---|
| SWE | 顧客向け管理画面とAPI開発を担当 | 受注処理で入力不備が発生する業務を対象に、業務担当3名へ例外を確認。本人は入力ruleとAPI境界を設計し、TypeScriptの画面とPython API、integration testを実装。段階release後の手動修正件数を計測し、原因上位2件のvalidationを追加した |
| SIer・ITコンサル | 顧客折衝、要件定義、project管理を実施 | 既存3system間の二重入力を対象に、関係4部門のdata ownerと対象範囲を合意。本人はAPI接続のprototypeとmapping処理を実装し、security reviewの指摘を反映。release判断資料とrollback手順を作成し、運用teamへ引き継いだ |
| AI・data | RAGを用いた社内検索systemを構築 | 規程検索で根拠文書へ到達できない課題に対し、本人はaccess権を維持するindex設計、引用表示、評価datasetを実装。回答可能率、引用一致、権限外拒否、latencyを変更ごとに比較し、誤答時は原文検索へ戻すflowを追加した |
TASKS TO EVIDENCE担当業務の羅列を一つの成果へつなぐ
要件定義、API開発、顧客説明、運用支援を別々に列挙
同じ課題で接続
課題、判断、本人の実装、本番、結果を一案件の因果として説明
成果の数字がないときは、事実の解像度を上げる
売上や工数削減を測っていない案件で、推定の効果を作ってはいけません。数字がないことを隠すより、確認できる状態変化と測定計画を書きます。
| 観点 | 書ける事実の例 | 併記する条件 |
|---|---|---|
| release | prototype、本番、限定release、全体展開のどこまで完了したか | 環境、日付、対象、本人の担当 |
| 利用範囲 | 利用者、部署、業務、data source、処理件数 | 測定期間、activeの定義、公開可否 |
| 品質 | test、失敗例、手動修正、error、incident、rollback | 分母、test dataと実dataの差、未計測項目 |
| 運用 | monitor、alert、runbook、on-call、権限review、引き継ぎ | 誰が保守したか、実際に使ったか |
| 意思決定 | 継続、停止、対象縮小、technology変更、段階導入 | 判断者、本人の提案、根拠 |
| 再利用 | component、template、playbook、次案件での利用 | 再利用先、何が短縮・改善したか、未測定なら明記 |
数字を書くときの4点セット
- 指標：何を数えたか
- 比較：導入前後、旧方式、新方式、目標など何と比べたか
- 期間・分母：いつ、何件、何人を対象にしたか
- 本人の寄与：チーム成果に対し、自分が何を決め・実装したか
「処理時間を50%削減」と書くなら、測定した作業、件数、期間、本人の実装、別要因を説明できるようにします。説明できない場合は、「対象業務を自動処理へ変更し、[測定方法]を導入」のように、確認済みの事実へ戻します。
チーム成果と本人の担当を分ける
大きな成果は複数人で作ります。チーム成果を書かないと事業への影響が小さく見え、本人だけの成果にすると誇張になります。次の二段で書きます。
- チーム成果：何を本番へ届け、利用者・業務に何が起きたか
- 本人の責任：その成果に対し、自分が確認・判断・設計・実装・運用した範囲
架空の記入例：「チームは受注審査の新flowを2部署へrelease。本人は業務担当への例外ヒアリング、data mapping、審査API、integration test、運用monitorを担当し、release後の手動修正を分類してvalidation ruleを更新した。」
「lead」「主導」「owner」と書く場合は、どの意思決定権と成果責任を持っていたかを説明します。会議を進行しただけ、担当者だっただけの案件でownerと書かないでください。
技術スタックを案件の証拠へ接続する
技術欄はkeyword一覧ではありません。同じPythonでも、notebookで分析したのか、本番APIを運用したのかで証拠が違います。技術名、使用場面、担当水準、関連案件をセットにします。
| 技術領域 | 弱い記載 | 確認しやすい記載 |
|---|---|---|
| Python | Python 5年 | FastAPIによる業務APIの設計・実装・test・release・monitorを3案件で担当 |
| LLM／RAG | OpenAI、RAG、LangChain | 権限付き文書検索でchunk・retrieval・citation・eval dataset・manual fallbackを設計 |
| Cloud | AWS、Google Cloud | IAM、network、CI/CD、logging、cost alertを含む本番環境を設計・運用 |
| 顧客課題 | 要件定義、顧客折衝 | 利用者5名への業務確認から対象外と成功指標を合意し、2段階releaseを設計 |
| Project推進 | Agile、Scrum | 不確実性の高いintegrationを先に検証し、週次decision logでscopeを調整 |
守秘義務を守りながら案件を書く
FDEでは顧客環境、data、securityへ深く入ることがあります。具体性を出すために、秘密情報を持ち出してはいけません。契約、社内規程、顧客の許可が最優先です。
| 項目 | 公開可能な書き換え例 | 掲載しない例 |
|---|---|---|
| 顧客 | 国内製造業、従業員規模、対象部門など許可された一般情報 | 非公開の顧客名、担当者名、連絡先、契約条件 |
| system・data | 既存CRM、基幹system、数百万件規模など許可された粒度 | 内部URL、table名、schema、実data、access情報 |
| 成果 | 割合、範囲、段階、定性的な状態変化など許可された表現 | 未公表の売上、原価、障害件数、security incident |
| code・図 | 公開dataで再現したdemo、自作の抽象構成図 | 勤務先のsource code、log、screenshot、prompt、秘密鍵 |
日本語職務経歴書から英語resumeへ変換する
OpenAI東京の現行求人は、resumeを英語で提出し、interviewには日本語・英語双方の会話を含むと明記しています。これはOpenAI固有の条件であり、すべての日本向けFDE求人が英文resumeを求めるわけではありません。
英語版は日本語版を単語単位で直訳せず、次の順で短くします。
- Action：本人が何をしたか
- Problem／Scope：誰の何を、どの範囲で扱ったか
- Technical decision：何を設計・実装し、なぜ選んだか
- Production evidence：release、quality、operationをどう担ったか
- Result：測定条件付きで何が変わったか
架空の英語例：
Led discovery with operations users to define exception handling for an order-review workflow; designed and implemented the TypeScript UI and Python API, added integration tests and monitoring, and used post-launch correction logs to prioritize two validation improvements.
“Led”や“owned”は事実として意思決定・成果責任を持った場合だけ使います。英語の流暢さを見せるために、本人の担当や成果を拡大しないでください。対象求人の言語、提出欄、file形式を応募直前に確認します。
提出前に12項目を確認する
- 応募先の公式求人を開き、必須・歓迎・責任を分けて読んだ
- 冒頭3〜5行で、応募先に近い経験と代表案件を示した
- 元の職名、会社、期間、雇用形態を事実どおり書いた
- 各案件に利用者、課題、制約、対象外がある
- チーム成果と本人の判断・実装を分けた
- code、API、data、test、本番化の担当範囲を説明できる
- 利用定着、品質、運用、成果のうち確認できる事実がある
- 数字に指標、期間、分母、比較条件がある
- 根拠のないROI、削減率、利用率を作っていない
- 顧客名、個人情報、秘密情報、公開許可のないcode・数値を除いた
- 技術欄が関連案件と使用場面へ接続している
- リンク、file名、言語、提出形式が応募先の案内と一致している
企業側がFDEの責任と評価をどう設計するかは「FDE採用ガイド」で整理しています。候補者側は、その評価表を推測するのではなく、公式求人に書かれた責任へ自分の証拠を対応させます。
FREE TEMPLATE
一案件テンプレートをダウンロード
課題、制約、本人の判断、設計・実装、本番化、成果を一つの因果で整理できます。チーム成果と本人の寄与を分け、確認できない数字を作らないための確認項目も付けています。
FDE転職向け 職務経歴書・一案件テンプレートMarkdown形式・無料↓FDEの職務経歴書についてよくある質問
FDE未経験でも職務経歴書を書けますか？
Q
FDE未経験でも職務経歴書を書けますか？
A
書けます。ただし、元の職名をFDEへ変えたり、担当していない工程を追加したりしてはいけません。SWE、SIer、ITコンサル、AI・data、Solution Architect等の経験から、顧客課題、本人の実装、本番化、成果へ接続する事実を選びます。FDE未経験と開発未経験は別であり、求人の必須要件も確認してください。
職務経歴書は何ページにすべきですか？
Q
職務経歴書は何ページにすべきですか？
A
今回確認した公式FDE求人から、全社共通のページ数は確認できません。応募先の指定を優先し、職務要約から関連案件の証拠へ迷わず進める長さにします。古い・関連の薄い案件は短くし、対象求人に近い2〜3案件を詳しくする方法があります。
顧客名や案件名を出せない場合はどうしますか？
Q
顧客名や案件名を出せない場合はどうしますか？
A
契約と社内規程に従い、業界、規模、対象部門、業務を公開可能な粒度へ抽象化します。顧客を特定できる組み合わせ、内部system名、実data、未公開数値は載せません。匿名化の可否を判断できない場合は、勤務先・顧客・法務へ確認します。
成果の数字がない場合はどうしますか？
Q
成果の数字がない場合はどうしますか？
A
推定値を作らず、release段階、利用範囲、test、手動修正、incident、runbook、引き継ぎ、意思決定など確認できる事実を書きます。何を測れていないかと、次回どう測るかも記載できます。数字がある場合は期間、分母、比較条件を併記します。
ポートフォリオと同じ内容を書いてよいですか？
Q
ポートフォリオと同じ内容を書いてよいですか？
A
同じ案件を使えますが、役割を分けます。職務経歴書は課題、本人の責任、本番、成果を短く要約し、ポートフォリオはarchitecture、code、評価、decision logを追加確認する資料にします。具体的な構成は「FDEポートフォリオの作り方」で確認し、両方の期間、担当、数字を一致させてください。
英文resumeは必須ですか？
Q
英文resumeは必須ですか？
A
企業ごとに異なります。OpenAI東京の現行FDE求人は英文resumeと日英interviewを明記していますが、すべての日本向け求人へ一般化できません。応募先の公式求人・応募formを確認し、必要な場合はaction、scope、technical decision、production evidence、resultの順で英語へ再構成します。
まとめ：一案件を、顧客課題から本番成果までつなぐ
FDE向け職務経歴書では、技術名、要件定義、開発、顧客折衝を別々に並べず、一つの課題の中でつなぎます。利用者と現状を示し、制約と対象外を決め、本人の判断・実装を分け、本番化と確認できた成果までを書きます。
まず代表案件を一つ、記事内のテンプレートへ記入してください。その後、対象求人の公式要件と照らし、関係の薄い説明を削ります。書類と同じ事実を口頭で説明する準備は「FDE面接対策」、成果物の不足を埋める順番は「FDE学習ロードマップ」で確認できます。
参考にした公式情報
- OpenAI「Forward Deployed Engineer – Tokyo」
- Google Cloud「Forward Deployed Engineer, GenAI（English, Japanese）」
- Notion「Forward Deployed Engineer, GTM – Japan」
- Palantir「Forward Deployed Software Engineer – Japan Government」
- 厚生労働省「ジョブ・カード様式のダウンロード」
- 厚生労働省「職務経歴書（ジョブ・カード準拠様式）」
- 厚生労働省「ジョブ・カードを知る」
この記事をシェアする
