FDE CAREER ARTICLE
FDEポートフォリオの作り方｜題材・README・評価テンプレート
FDE（Forward Deployed Engineer）向けのポートフォリオでは、画面の見栄えや使ったAIモデルの新しさだけを見せても、仕事の全体像は伝わりません。重要なのは、誰のどの課題を選び、どの制約の中で設計し、自分が何を実装し、どのように本番品質と成果を確かめたかを一つのケーススタディとして説明することです。
OpenAIの東京向けFDE求人は、課題発見、技術的な対象範囲、システム設計、実装、本番展開、利用定着、業務への影響までを役割に含めています。Google Cloudの東京向けFDE求人も、プロトタイプだけでなく、顧客環境のAPI・既存データ・セキュリティ境界との統合、評価、可観測性まで挙げています。
本記事では、これらの公式求人と企業公式技術資料を基に、題材の選び方、READMEの構成、自己点検表をテンプレート化します。FDEの仕事全体を先に知りたい場合は「FDEとは」と「FDEの仕事内容・必要スキル・類似職との違い」をご覧ください。
この記事の要点
- 技術から題材を選ばず、利用者・重要業務・制約・成功指標から選ぶ
- 一つの制作物を、課題→判断→実装→本番品質→評価→学びの順で見せる
- 自分が担当した範囲と、ライブラリ・生成AI・第三者が担った範囲を分ける
- 生成AIを使う場合は、正常例だけでなく失敗例、評価データ、人による確認、コストと応答時間を示す
- 顧客名、個人情報、実データ、APIキー、公開許可のないコードを掲載しない
目次
結論：完成画面より「意思決定の証拠」を見せる
FDEの制作物は、機能一覧ではなく意思決定の記録として作ります。「チャット画面を作った」「RAGを実装した」だけでは、なぜ必要だったのか、本番で使えるのか、成果があったのかが分かりません。
最低限、次の3つを同じ案件の中でつなげます。
PORTFOLIO FOUNDATIONFDEポートフォリオの3つの証拠
利用者、現状業務、痛点、基準値、解かない範囲を言葉にする
実装、データ、権限、評価、監視、障害時の運用をつなぐ
利用、品質、時間、費用、フィードバックを確認可能な事実で示す
OpenAI東京はprototypeからstable productionまでの技術デリバリー、顧客チームとの協働、scope・speed・qualityのトレードオフ、再利用できるplaybookやbuilding block化を挙げています。したがって、ポートフォリオでも「何を作ったか」だけでなく「何を対象外にしたか」「どこで計画を変えたか」「次に再利用できるものは何か」を残します。
公式求人から整理する6つの評価項目
企業ごとにFDEの担当領域は異なり、共通の公式採点表はありません。ここでは現行の公式求人に書かれた責任を、制作物で示せる6つの証拠へ変換します。
| 証拠 | 公式求人にある責任の例 | ポートフォリオに残すもの |
|---|---|---|
| 1. 課題発見 | discovery、technical discovery、曖昧な要求やopen-endedな問題の理解 | 利用者、現状フロー、痛点、基準値、ヒアリング記録、未検証の仮説 |
| 2. 対象範囲・判断 | technical scoping、deliveryの順序、scope・speed・qualityのトレードオフ | 選択肢、制約、採用・不採用理由、対象外、段階的なリリース計画 |
| 3. ハンズオン実装 | full-stack build、code、debug、API・データ・既存システムの統合 | 自分が書いたコード、システム構成、データフロー、テスト、実行手順 |
| 4. 本番品質 | stable production、security perimeter、observability、長期運用 | 認証・権限、ログ、監視、障害例、リトライ、ロールバック、運用手順 |
| 5. 評価・成果 | adoption、workflow impact、ROI、accuracy・safety・latency、利用者との反復 | 導入前の基準、評価データ、指標、結果、失敗例、利用者フィードバック |
| 6. 学習・再利用 | playbook、building block、reusable module、product feedback | 意思決定ログ、共通部品、次案件で使える手順、残課題、次の改善 |
現在の日本向け募集を比較するときは「FDE求人一覧」を使い、応募先の責任範囲に合わせて強調点を変えます。生成AI中心、データ中心、SaaS統合中心では、同じFDEでも見せる技術と成果が異なります。
FDE向けポートフォリオの題材を選ぶ4条件
題材は「最新モデルを使えるか」ではなく、次の4条件で選びます。
- 利用者が具体的：誰が、いつ、どの作業で使うかを一文で言える
- 現状と成功を測れる：導入前の時間、品質、手戻り、完了率などを少なくとも一つ確認できる
- 外部との接続がある：API、データベース、ファイル、認証、既存業務のいずれかとつながる
- 失敗時の運用を考えられる：誤回答、入力不足、外部API停止、権限不足などの例外がある
| 題材例 | 利用者と業務 | 実装できる証拠 | 評価・運用の例 |
|---|---|---|---|
| 問い合わせ一次振り分け | サポート担当が、受信した問い合わせを分類し担当へ渡す | メール／フォーム連携、分類、検索、承認、チケットAPI | 分類一致率、手動修正率、応答時間、機密情報のマスキング |
| 提案書の要件抽出 | 営業・プリセールスが、RFPから要件と未回答事項を整理する | 文書解析、表抽出、引用、権限、レビュー画面 | 要件の抜け、引用の正確性、レビュー時間、原文への追跡可能性 |
| 社内申請の事前確認 | 申請者と承認者が、必須項目や規程違反を確認する | ルール＋LLM、権限、監査ログ、通知、手動承認 | 差し戻し率、見逃し、誤警告、例外時のエスカレーション |
| ナレッジ検索 | 現場担当が、社内文書から根拠付き回答を探す | RAG、アクセス制御、引用、更新、検索ログ | 回答可能率、根拠一致、権限漏れ、検索不能時の案内 |
| データ品質監視 | 業務・データ担当が、欠損や異常を見つけ対応する | データパイプライン、検証rule、alert、dashboard、runbook | 検知時間、誤警告、復旧時間、原因別の再発防止 |
生成AIを使わない題材でもよい
FDEは企業によって生成AI、データ、数理最適化、SaaS統合など重心が異なります。応募先が生成AIを扱うなら評価やガードレールの証拠は有効ですが、技術の必要性を説明できないままLLMを追加する必要はありません。ルールベース、検索、通常のWebアプリで十分な部分と、生成AIが必要な部分を分ける方が技術判断を示せます。
ケーススタディを7章で構成する
GitHub公式のREADMEガイドは、プロジェクトが何をするか、なぜ有用か、開始方法、支援先、保守者などを含める例を示しています。FDE向けには、そこへ業務課題、判断、評価、運用を加えます。
CASE STUDY FLOW課題から再利用までを一つの線で見せる
- Problem利用者・現状・痛点を定義
- Scope制約・対象外・成功指標を決定
- Build自分の実装範囲を明示
- Operate権限・監視・障害対応を設計
- Evaluate実データに近い条件で評価
- Reuse学び・共通部品・次の改善を残す
| 章 | 書く内容 | 避けたい書き方 |
|---|---|---|
| 1. 30秒の概要 | 利用者、課題、作った仕組み、自分の担当、確認できた結果を5行以内で示す | 技術名だけを長く列挙する |
| 2. 課題と現状 | 導入前の業務フロー、痛点、基準値、関係者、確認方法を示す | 「非効率だった」だけで根拠を示さない |
| 3. 対象範囲 | 制約、成功指標、対象外、仮説、優先順位を示す | すべての課題を解決したように書く |
| 4. 設計と実装 | 構成図、データフロー、自分が書いた部分、主要な設計判断を示す | ライブラリ名や生成AIの出力を自分の成果として扱う |
| 5. 本番品質 | 認証・権限、テスト、ログ、監視、障害対応、コスト、デプロイ方法を示す | 正常系のデモだけを掲載する |
| 6. 評価と成果 | 評価データ、指標、結果、失敗例、利用者の修正、未達項目を示す | 確認していない時間削減やROIを推定する |
| 7. 学びと次 | 変えた判断、残課題、再利用部品、次の実験、保守責任を示す | 「良い経験になった」で終える |
コピーして使えるFDEポートフォリオのREADMEテンプレート
次のテンプレートをコピーし、角括弧の中を自分の事実へ置き換えます。実在利用者へ確認していない内容は「想定」「仮説」「未検証」と明示してください。
# [プロジェクト名]
## 1. 30秒で分かる概要
- 利用者: [誰が、どの場面で使うか]
- 課題: [導入前に起きていた具体的な問題]
- 解決策: [作った仕組みを1〜2文で]
- 私の担当: [調査／設計／実装／評価／運用のうち本人が担当した範囲]
- 確認できた結果: [事実のみ。未計測なら「未計測」と記載]
## 2. 現状業務と課題
- 導入前フロー: [入力→判断→処理→出力]
- 利用者への確認方法: [ヒアリング／観察／公開資料／想定]
- 基準値: [時間、件数、品質、手戻り等。分からなければ不明]
- 放置した場合の影響: [確認できた範囲]
## 3. 対象範囲と成功指標
- 今回解くこと: [対象]
- 今回解かないこと: [対象外]
- 制約: [期間、データ、権限、予算、環境、法務]
- 成功指標: [指標／測り方／目標または比較対象]
- 主要な仮説: [未検証であることを明記]
## 4. 設計と実装
- システム構成図: [画像またはMermaid等へのリンク]
- データフロー: [取得元→処理→保存→出力]
- 技術選定: [選択肢／採用理由／採用しなかった理由]
- 自分が書いた部分: [repositoryのpathやPR]
- 第三者・AIが担った部分: [library、API、生成codeとreview方法]
## 5. 本番品質と運用
- 認証・権限: [誰が何へアクセスできるか]
- テスト: [unit／integration／end-to-end]
- ログ・監視: [何を記録し、どの状態で通知するか]
- 障害時: [timeout、retry、manual fallback、rollback]
- セキュリティ: [個人情報、secret、入力攻撃、監査]
- コスト・性能: [1件あたり費用、応答時間、上限]
## 6. 評価と結果
- 評価データ: [件数、作り方、実利用との差]
- 指標: [task success、正確性、安全性、latency等]
- 結果: [数値と測定日]
- 失敗例: [代表例と原因]
- 人による確認: [誰が、何を、どの基準で確認したか]
- 利用者から変えた点: [変更前→変更後]
## 7. 学び・残課題・再利用
- 判断を変えた点: [根拠]
- 残るリスク: [未解決事項]
- 再利用できるもの: [component、test、playbook]
- 次に試すこと: [優先順位付き]
- 長期保守者: [個人開発なら自分／終了予定も明記]
## 実行方法
[必要環境、setup、test、demo data、停止方法]
## 公開範囲
[匿名化、dummy data、license、秘密情報を含まない旨]
READMEだけで全情報を詰め込まず、詳細な設計判断は`docs/decisions/`、評価データの作り方は`docs/evaluation/`、運用手順は`docs/runbook/`へ分けても構いません。第三者がREADMEから必要な資料へ移動できることを優先します。
生成AIの制作物は「評価」を機能として作る
OpenAIのEvaluation best practicesは、評価目的、データセット、指標、実行・比較、継続評価という流れを示し、実利用に近いタスク固有の評価、ログ、人の判断との校正を勧めています。「動いているように見える」だけの評価を避ける考え方は、モデルやベンダーにかかわらず、ポートフォリオの説明にも使えます。
- 評価目的：「良い回答」ではなく、利用者が完了したい仕事を定義する
- 評価データ：正常例だけでなく、曖昧入力、長文、権限外、取得不能、攻撃的入力を含める
- 指標：正確性だけでなく、引用、拒否、手動修正、安全性、応答時間、費用を分ける
- 人の確認：自動評価と人の判断が一致しない例を残し、基準を修正する
- 継続評価：prompt、model、tool、dataを変えたときに同じ評価を再実行する
Google Cloud Well-Architected Frameworkは、運用、セキュリティ、信頼性、費用、性能などの非機能観点を分けています。すべてを大規模に実装する必要はありませんが、ポートフォリオでは自分の案件で重要なリスクを選び、何を実装し、何を未対応としたかを説明します。
DEMO VS EVIDENCE機能デモをFDEケーススタディへ変える
画面、model呼び出し、正常な入力、単発の結果を見せる
業務・制約・評価を足す
利用者、対象外、統合、権限、失敗、測定、運用、次の判断まで示す
6軸12点で自己点検する
次の表は、公開前に不足を見つけるための自己点検表です。採用企業の公式採点表ではなく、合計点で合否を予測するものでもありません。0がある軸について、説明または証拠を一つ追加します。
| 評価軸 | 0：証拠なし | 1：説明あり | 2：検証可能 |
|---|---|---|---|
| 課題発見 | 課題が抽象的 | 利用者と現状フローを説明 | 確認方法、基準値、未検証点まで明示 |
| 対象範囲・判断 | 作った機能だけを列挙 | 制約と対象外を説明 | 比較した選択肢と判断根拠を記録 |
| 実装 | 本人の担当が不明 | 構成と担当範囲を説明 | code、test、実行手順で第三者が確認可能 |
| 本番品質 | 正常系demoのみ | 権限、log、障害対応を説明 | test結果、monitor、runbook、rollbackを確認可能 |
| 評価・成果 | 「便利になった」だけ | 指標と結果を記載 | data、測定条件、失敗例、日付を確認可能 |
| 学習・再利用 | 完成で終了 | 学びと残課題を説明 | decision log、共通部品、次の改善を確認可能 |
GitHubを公開できない実務案件は、証拠を分解する
業務で作ったコードや顧客データは、会社・顧客の許可なく公開できません。公開repositoryがない場合でも、次の情報を公開可能な範囲へ抽象化できます。
- 業界・企業名を伏せた利用者像と業務フロー
- データ名や製品名を一般化したシステム構成図
- 自分が担当した工程、意思決定、実装範囲
- 絶対値を出せない場合の、展開部署数、リリース完了、運用手順整備など確認可能な事実
- 公開できる別データで再現した小さなdemonstration
- 失敗から変えた判断、再利用した手順、引き継ぎ方法
同じ案件を応募書類へ変換するときは「FDE転職の職務経歴書テンプレート」を使います。職務経歴書は責任と成果の要約、ポートフォリオは設計・コード・評価を追加確認する証拠と役割を分け、期間・担当・数字を一致させてください。
公開してはいけない情報を先に除く
ポートフォリオは公開範囲の広い応募資料です。コードを見せることより、守るべき情報を守れることを優先します。APIキーを一度commitしてから削除するのではなく、最初から環境変数とdummy dataを使います。GitHubのSecret scanning資料も確認し、利用できる保護機能を有効にします。ただし、検知機能は秘密情報をcommitしてよい理由にはなりません。
| 公開してよい例 | 匿名化・許可確認が必要 | 公開しない |
|---|---|---|
| 自作code、dummy data、公開API、公開資料を基にした設計 | 業務flow、実績数値、architecture、画面、顧客のfeedback | API key、password、token、秘密鍵、接続文字列 |
| 自分で作った図、公開可能なdecision log、test dataの作り方 | 企業名、顧客名、担当者、契約、価格、内部の製品名 | 個人情報、顧客data、社内文書、未公開情報 |
| licenseを確認した依存関係と引用元を示した公開素材 | 勤務先のcode断片、log、prompt、screenshot、障害事例 | 公開許可のないsource code、転載禁止素材、第三者の著作物 |
7日間で最小版を作る手順
7日間は内定までの期間ではなく、ケーススタディの最小版を完成させるための作業例です。経験や題材に応じて延長してください。
- 1日目：利用者、現状フロー、痛点、基準値、未検証の仮説を1ページにする
- 2日目：成功指標、対象外、主要リスクを決め、APIとデータの最小構成を描く
- 3日目：重要な一つの業務フローをend-to-endで実装する
- 4日目：認証・権限、入力検証、log、error処理、testを追加する
- 5日目：正常例と失敗例を含む評価データを作り、指標と結果を記録する
- 6日目：第三者に触ってもらい、誤解した点、止まった点、手動修正を記録する
- 7日目：README、構成図、decision log、runbook、残課題、demoを整える
完成後は「FDE転職ガイド」で応募先の要件と照らし、応募求人に関係しない技術説明を削ります。ポートフォリオは大きくするより、読み手が責任範囲を追える状態にします。
FREE TEMPLATE
READMEテンプレートをダウンロード
顧客課題、対象範囲、設計・実装、本番品質、評価、残課題までを一つのケーススタディへ整理できます。角括弧を、自分が確認できる事実へ置き換えて使ってください。
FDEポートフォリオ READMEテンプレートMarkdown形式・無料↓FDEポートフォリオについてよくある質問
FDE未経験でもポートフォリオは作れますか？
Q
FDE未経験でもポートフォリオは作れますか？
A
作れます。ただし、FDEとしての実務経験があるように装ってはいけません。個人開発、学習課題、社内改善、公開dataを使った検証など、制作物の前提と自分の担当を明示し、実在利用者へ確認していない部分は「想定」「未検証」と書きます。ポートフォリオだけで実務経験や採用を代替できるとは限りません。
生成AIやRAGを必ず使うべきですか？
Q
生成AIやRAGを必ず使うべきですか？
A
応募先の仕事と題材に必要な場合だけ使います。ルール、検索、通常のソフトウェアで解ける部分までLLMへ任せる必要はありません。生成AIを使う場合は、model名だけでなく評価データ、失敗例、human review、権限、cost、latencyを示してください。
GitHubの公開は必須ですか？
Q
GitHubの公開は必須ですか？
A
すべての求人に共通する公開必須条件ではありません。業務codeを公開できない場合もあります。公開可能な個人repository、匿名化したケーススタディ、構成図、decision log、評価方法を組み合わせ、自分の担当と判断を説明します。応募先が提出形式を指定している場合はその案内を優先します。
個人開発で顧客課題をどう設定しますか？
Q
個人開発で顧客課題をどう設定しますか？
A
身近な業務担当者へ公開可能な範囲でヒアリングするか、自分が実際に行う反復業務を対象にします。確認相手がいない場合は想定利用者と仮説を置き、事実と分けます。「企業で導入されている」「工数を削減した」など、確認していない実績は書きません。
成果の数値がない場合はどう書けばよいですか？
Q
成果の数値がない場合はどう書けばよいですか？
A
推定値を作らず、確認できる事実を書きます。本番または検証環境へのrelease、利用者数、対象部署、完了した業務、test件数、手動修正の有無、運用手順の作成などです。数値がない理由と、次にどう測るかも設計判断として記録できます。
ポートフォリオはいくつ必要ですか？
Q
ポートフォリオはいくつ必要ですか？
A
公式求人に共通する必要個数は確認できません。まず一つを、課題から本番品質、評価、学びまで深く説明できる状態にします。別の応募先で異なる技術領域や顧客責任を示す必要がある場合に、二つ目を追加します。
まとめ：一つの制作物で、課題から成果までをつなぐ
FDE向けポートフォリオは、技術カタログではありません。利用者と現状業務を確認し、制約と対象外を決め、自分で実装し、権限・評価・監視・障害対応を加え、確認できた結果と残課題を示します。
まずREADMEテンプレートへ一つの案件を書き、6軸の自己点検表で不足を見つけてください。制作の順番は「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」
- OpenAI API「Evaluation best practices」
- Google Cloud「Well-Architected Framework」
- GitHub Docs「About the repository README file」
- GitHub Docs「Secret scanning」
この記事をシェアする
