FDEとは、何者なのか？

LT会（15分）で発表した、FDE（Forward Deployed Engineer）の入門資料です。

Palantir発祥で、いまAI業界が奪い合っている「FDE」とは何者なのか。その正体を「コンサル力・営業力 × PM力 × 開発スキル」の3つの要素に分解し、ビジネスの上流から開発の下流へ、仕事が流れる順番で解説します。

▼ 内容
・FDEとは？ SE / コンサル / SES との違い
・なぜ今FDEが熱いのか（AI導入のラストワンマイル）
・Palantirの原型「Delta × Echo」モデル
・柱① コンサル力・営業力 … 課題を見つける技術、提案の型、相手別の翻訳、デモの作り方
・柱② PM力 … ピープル / プロダクト / プロジェクト / テクノロジーの4マネジメント
・柱③ 開発スキル … フルサイクルエンジニア、技術スタック5層、現場で差がつく泥臭い力
・組織・チームで実現するFDE … 分業と役割分担という現実解
・FDEスキルは「事業をつくる力」… 経営者・フリーランスにこそ効く理由

Transcript

1. FDEとは、 何者なのか？ LT TALK · 15 MIN Forward Deployed Engineer を「分解」して理解する 発表：須田まさぴょん🐱 2026.08 LT会 コンサル力・営業力 × PM力 × 開発スキル
2. はじめに 今日、持ち帰ってほしいこと 1 FDEを説明できる いま世界中のAI企業が奪い合っている「FDE」 という職種。その正体を、自分の言葉で説明で きるようになる。 2 FDEを分解できる FDEに必要な力を3つの構成要素に分解し、そ れぞれの中身を具体レベルで理解する。 FDEとは？ → ① コンサル力・営業力 → ② PM力 → ③ 開発スキル → まとめ 3 現在地がわかる 3本柱のうち自分はどこが強くて、どこが弱い か。明日からの一歩が見つかる。
3. イントロダクション FDEとは？ DEFINITION 自社プロダクトを携えて顧客の現場に入り込み、 課題の発見から実装・運用定着までを一気通貫で担うエンジニア 🏛️ 発祥は Palantir CIAなど「要件を言語化できない顧客」との開 発から生まれた。エンジニア自身が現場で業務 を観察し、作りながら適用する。 🪖 名前の由来 軍事用語の「前方展開（Forward Deployment）」。後方（本社）で作って納品する のではなく、前線＝顧客の現場で戦う。 💡 今日の軸：FDEとは「作れる人が、現場に出ていく」という職種である 🔨 最大の特徴 提案して終わりではなく、実装まで自分でやり 切る。成果物は提案書ではなく「動いて、使われ ているシステム」。
4. イントロダクション SE・コンサル・SESと、何が違うのか 課題定義 実装 成果物 撤収 SES / 客先常駐 顧客から受領 ◦ 労働力の提供 前提なし（常駐継続） ITコンサル 自ら定義 ×（提案書まで） 提案書・レポート プロジェクト単位 SE / SIer 受領 ◦ 設計書・コード 納品で終了 FDE 自ら発見 ◦（自分で作る） 動いて、使われているシステム あり（顧客の自走が前提） 🎯 ミッションが違う 「仕様通りに作る」ではなく「P/L改善を実証す る」。「動いたか」ではなく「事業が変わったか」 で評価される。 🔄 開発組織との関係が違う 下流の受け手ではなく上流。現場の知見をプロ ダクトのロードマップに還流させる。 💸 インセンティブが逆 人月が伸びるほど儲かるSESに対し、FDEは顧 客が自走し継続することが利益になる。
5. イントロダクション なぜ今、 FDEが熱いのか？ AIの性能ではなく、現場に導入しきる「ラストワンマイル」が世界的なボトルネックに 70% 米企業の70%がFDE採用を計画 （2026年半ば。年初はわずか5〜10%） 🌍 世界の動き 2,100% 2026年末までのFDE需要の増加予測 （米 Christian & Timbers 調べ） ・OpenAI：AI導入専門会社「The Deployment Company」を設立（評価額140 億ドル規模と報道） ・Anthropic：FDE中心のコンサル会社「Ode」を投資家と設立 ・Google：獲得競争のため面接を「数週間で4〜6回」→「2日で2回」に短縮 出典：TechCrunch (2026/7)、The Pragmatic Engineer、JAPAN AI ラボ ほか 🗾 日本の動き 1,000〜2,000万 円 日本のFDE求人の年収中心レンジ （2026年時点） ・LayerX・ログラス・マネーフォワード・Sansan・エクサウィザーズ などが採用 開始 ・PdM職を廃止しFDEを組織の中核に据えた企業事例も登場 ・背景は「PoC止まり」問題：生成AI案件の約30%がPoC後に放棄されるとの予 測（Gartner）
6. イントロダクション ／ 背景知識 原型：Palantir の「Delta × Echo」— 2人1組のモデル DELTA Forward Deployed Engineer ・本番品質のコードを書くエンジニア ・データパイプライン、業務データの設計、AI実装 ・本社の製品エンジニアと同じ技術水準 ・例えるなら「スタートアップのCTO」 ECHO Deployment Strategist × ・現場の業務・組織・政治を読む戦略担当 ・元軍人・臨床医・会計士など非エンジニアが多い ・どの部署が対立しているか、なぜその運用が残っているか ・例えるなら「現場のインサイダー」 ⚖️ この2人の"緊張関係"が設計上の狙い — Deltaだけなら「技術的に美しいが誰も使わないもの」、Echoだけなら「正しいが動くものがない」で終わる。 🤖 現代のFDEは、AIの力を借りてこの2人分を1人でやる仕事 — だから3つの力の掛け算になる
7. イントロダクション FDEの構成要素 — 3つの力の 「掛け算」 仕事が流れる順番で見ていく— ビジネスの上流から、開発の下流へ PILLAR 01 コンサル力 営業力 ＝ 価値を認めさせられる 語るより、見せる × PILLAR 02 PM力 ＝ 前に進められる 4つのマネジメント ビジネスの上流 ⚠️ 足し算ではなく掛け算 — どれか1つがゼロなら、届けられる価値もゼロになる × PILLAR 03 開発スキル ＝ 作れる 幅 × 速度 × 完了責任 開発の下流
8. PILLAR 01 · ビジネスの上流 コンサル力・営業力 「価値を認めさせる力」＝ 語るより、見せる 課題を見つける 提案力 説明力 デモ実装・提案
9. 柱① コンサル力・営業力 WHY なぜ「エンジニア」に営業・コンサル力が必要なのか PALANTIR の答え 伝統的な営業部隊を持たず、エンジニアそのものを営業エンジンにした。 提案資料ではなく 動作するソフトウェア で信頼を勝ち取る。 ❓ 顧客が本当に知りたいこと 「その技術はうちで使えるのか」。これに答えられる のは、うちのデータで動くものを見せられる人だけ。 📄 提案書 vs デモ 提案書は「できるはずです」としか言えない。デモは 「もう動いています」と言える。 🎤 エンジニアが営業をやるのではない。エンジニアだからこそできる営業がある ⏱️ 結果：時間が圧縮される Palantirの「AIPブートキャンプ」は、顧客が実データ を持ち込み1〜5日で動くアプリを目撃する。数ヶ 月〜数年の商談が数日に。
10. 柱① — 1/4 CONSULTING コンサル力 — 「課題を見つける」 技術 ここを外すと、どんなに良いものを作っても価値にならない 👀 入り込む・観察する ・「何に困ってますか？」への答えは、 たいてい表面的 ・業務を横で見る。実際の画面・手 順・例外処理 ・「なぜそうしてるのか」を5回聞く 🧩 構造化・切り分け ・業務を工程に分解し、ボトルネック を特定 ・「AIでやること」「やめるべきこと」 「ルールベースで十分なこと」を分 ける ・Human in the Loop の設計 📈 効果を定量化 ・「業務が改善される」→「月40時間・ 年480時間の削減」 ・顧客のKPIの言葉に翻訳する ・測り方を導入前に決めておく 🏆 一番かっこいいAI提案は、「それ、AIじゃなくていいです」と言えること 🗳️ 意思決定を読む ・誰が・いつ・何をもって判断するか。 予算はどこから出るか ・稟議の材料（セキュリティチェックシ ート、費用対効果試算）を先回り で用意
11. 柱① — 2/4 PROPOSAL 提案力 — このまま使える「提案の型」 STEP 1 STEP 2 STEP 3 STEP 4 STEP 5 数字で今を示す。できれば顧 客自身に言わせる。 「今この業務に月◯時間」 原因を工程レベルで特定す る。 「Aの工程で人が手作業だ から」 語らず、動くデモを見せる。 「ここをこう変えます（実 演）」 投資と回収を数字で。 「年◯円削減、3ヶ月で回 収」 小さく確実に始める道筋を示 す。 「まず1部門で4週間」 現状 🌱 Land & Expand 課題 最初から全社導入を狙わない。1部門・1業務で確実 に成功させ、その成功事例が社内で伝播するのを狙 う。 解決策 ⚠️ リスクの先出し 効果 できないこと・限界・前提条件を自分から言う。隠す と後で信頼を失う。先に言えば誠実さになる。 進め方 📋 相手のフォーマットに合わせる 役員会で使うなら1枚。情シス審査ならチェックシー ト。相手がそのまま使える形で渡す。
12. 柱① — 3/4 COMMUNICATION 説明力 — 技術を「ビジネス言語」に翻訳する 相手 関心事 話すべき言葉 NGな話し方 経営層 ROI・リスク・スピード 「投資◯円、回収◯ヶ月、リスクは◯」 アーキテクチャの説明 情シス セキュリティ・運用負荷 「データは外に出ません、運用は◯人日/月」 「大丈夫です」の一言 現場ユーザー 自分の仕事がどう変わるか 「この画面のこのボタンだけ覚えればOK」 AI・LLMという単語 エンジニア 実現方式・技術的妥当性 技術用語でそのまま、正確に 抽象論・ふわっとした説明 🧰 技術を伝える4つの道具 ・比喩：「RAGは、AIに社内資料のカンペを渡してから答えさせる仕組み」 ・図解：データの流れと、人がどこで登場するかを1枚で ・数字：「速い」ではなく「3秒 → 0.5秒」 ・デモ：説明そのものを省略できる最強の手段 🎚️ 話す前に整える ・結論から言う（PREP）。相手が知りたい順に話す ・相手が知らない前提を、相手のせいにしない ・難しいことを難しいまま話すのは、説明ではない ・沈黙を怖がらない。相手が考える時間を奪わない
13. 柱① — 4/4 DEMO アジャイルなデモ実装・デモ提案 — 最強の武器 Show, don't tell（語るな、見せよ）— 課題を聞いたら、次回その場で動くものを持っていく 💥 デモが強い4つの理由 ・信頼が一瞬で立つ：「この人は口だけじゃない」が3分で伝わる ・議論が具体化する：抽象論が止まり、本音の要件が出てくる ・意思決定が速くなる：投資判断の前に現物を見られる ・次の商談が向こうから来る：「うちの部署でもできる？」＝ Land & Expand の起 点 🛠️ 効くデモの作り方 ・顧客の実データ（か、そっくりのダミー）を使う。汎用サンプルは刺さらない ・顧客の業務用語をUIに出す。その会社で呼んでいる名前で ・1つのシナリオを完走させる。機能を並べない ・90%は捨てる前提。作り込まない。見せる時間は5分以内 ⚠️ デモの落とし穴 ①良すぎると「もう完成してる」と誤解される →「これは10%です。本番化にはこれだけ必要です」を必ず言う ②動かないデモは逆効果 → 通しリハー サル必須。ネットワークが死んでも見せられるよう録画も用意。 🔥 FDEの営業力は"売り込む力"ではない。動くものを見せて、相手に「次はこれもできる？」と言わせる力
14. PILLAR 02 · 全工程をつなぐ PM力 「前に進める力」＝ 任せて安心な人になる力 ① ピープル ② プロダクト ③ プロジェクト ④ テクノロジー
15. 柱② PM力 — 1/4 PEOPLE ピープルマネジメント 🤝 クライアント ・期待値コントロール：できる事・できない事・時期 を常に揃える ・キーパーソンの見極め：決裁者／推進者／反対 する人 ・まず現場に座って仕事を見る。業務を「自分ごと」 に ・悪い報告ほど早く出す。隠した瞬間に信頼が壊れ る 🗣️ プロジェクトは技術ではなく、人で詰まる 👥 メンバー ・タスクの設計・割り振りと、レビューを通じた育成 ・モブ／ペア作業での知識共有、属人化の防止 ・進捗が止まっている＝助けが必要のサインと捉 える 🏢 ステークホルダー ・経営層：ROI・リスク・いつ結果が出るか ・情シス：セキュリティ・既存影響・運用負荷 ・現場：自分の仕事は楽になるのか、増えるのか ・三者は関心事が全く違う前提で調整する
16. 柱② PM力 — 2/4 PRODUCT プロダクトマネジメント 🎨 UI / UX ・機能一覧ではなく「業務の流れ」で画面を設計す る ・「毎日使われるか」が唯一の正義 ・使われないシステムは、動いていても価値ゼロ ・マニュアル・導入教育まで設計に含める ✅ 品質保証 ・「デモで動く」ではなく「業務で信頼される」品質ラ イン ・落ちても業務が止まらない設計、エラー時の振る 舞い ・AI特有：精度評価（Evals）、ハルシネーション対 策、間違いに人が気づける導線 🌉 「動くもの」と「使われるもの」の間にある深い谷を埋める 📮 製品への還元 ・現場の知見を実装レベルの解像度で本体ロード マップへ ・「この顧客だけの要望」と「業界共通の課題」を見 分ける ・Palantirの強さの源泉：個別対応を再利用可能 な機能に抽象化して還流
17. 柱② PM力 — 3/4 PROJECT プロジェクトマネジメント 📝 ドキュメント力【書く】 ・議事録・設計書・意思決定ログ（ADR） ・「言った言わない」を消し、後から入る人のコスト を下げる ・ドキュメントは信頼の貯金。書ける人は任される ✍️ 合言葉は「書いて、分けて、見せる」 🧩 構造化する力【分ける】 ・「AIで何かやりたい」→ 業務工程に分解 → ボト ルネック特定 ・スコープ定義＝「やらないこと」を決める ・価値 × 緊急度 × 実装コストで優先順位をつけ る 📊 タスク管理【見せる】 ・WBS・かんばんで進捗を可視化する ・リスクを先回りして検知：「この確認、来週までに 返事が来ないと詰みます」 ・「今どこで、次に何をするか」に誰でも即答できる 状態
18. 柱② PM力 — 4/4 TECHNOLOGY テクノロジーマネジメント 📐 設計Review・設計責任 ・アーキテクチャ選定の理由を説明でき、結果に責 任を持つ ・ADRで判断を記録し、レビュー文化を作る ・「後で直せる決定」と「直せない決定」を見分け、 後者に時間をかける 💰 コスト効率 ・クラウド費用・LLMのトークン課金の見積もりと 最適化 ・「その構成、月いくら？」に即答できる＝技術選定 は経営判断 ・PoCでは無視できたコストが全社展開で100倍に なる罠を先読み ⚙️ 技術の意思決定に、名前を出して責任を持つ 🔐 セキュリティ関連 ・顧客データの扱い（保存・持ち出し・学習利用）と 権限設計 ・AI固有：プロンプトインジェクション、機密リーク、 エージェントの暴走防止 ・「セキュリティで止まる」は導入失敗の最頻出パタ ーン。情シスを最初から味方に
19. PILLAR 03 · 開発の上流〜下流 開発スキル 「作りきる力」— キーワードは 幅 × 速度 × 完了責任 フルサイクル 技術スタック AI/LLM実装 現場の泥臭さ
20. 柱③ 開発スキル WHY IT'S DIFFERENT 前提が違う — FDEは「更地で試合をする」 自社プロダクト開発 FDEの現場 要件 PdMが定義してくれる 要件がない。自分で見つける 技術スタック 決まっている・慣れている 顧客ごとに違う。初見も多い データ 整備済み 汚い・欠けている・ドキュメントがない 環境 自由に使える VPN・権限申請・閉域網・持ち出し禁止 チーム 分業できる 人がいない。全部自分 期限 スプリント単位 「来週の役員会で見せたい」 🏕️ 整備されたグラウンドではなく更地で戦う。だから求められるスキルの「形」が変わる
21. 柱③ 開発スキル — 1/4 FULL CYCLE 土台：フルサイクルエンジニア —「開発したものが運用する」 設計 → 開発 → テスト → デプロイ → 運用 → 改善 ↺ 改善は次の設計へ — このループを一人で回しきる 😵 分業モデルの課題 ・引き継ぎのたびに知識が失われる ・障害対応にチーム間の往復が発生する ・開発者が「運用の痛み」を知らないまま設計する 🔁 フルサイクルの強み ・フィードバックループが最速になる ・本番の問題を自分で踏むから、次の設計が良くな る ・「誰かに投げる」がないので意思決定が速い 🧱 顧客先に分業する人数はいない。1人でサイクルを一周回しきれることがFDEの土台 ⚖️ トレードオフ ・認知負荷が高い。深い専門性を極めたい人には 不向きな面も ・Netflixもツール投資と支援チームをセットで整 備して成立させている ・個人なら、その代わりがAIとマネージドサービス
22. 柱③ 開発スキル — 2/4 TECH STACK 実際に何ができればいいのか — 5つの層 LAYER 1 アプリケーション フロント／バック／DB を1人で。デザイナーもDBAもいない前提で業務画面・API・スキーマを作る。顧客の既存DBをドキュメントなしで読 み解く力も。 LAYER 2 データ 基幹システム・CSV・スプレッドシート・PDFからのパイプライン構築。クレンジングと名寄せ。実務時間の多くはここに溶ける。そして「業務の 地図」を描くデータモデリング — 現場の言葉（「案件」「担当者」「在庫」）とその関係を、そのままデータの形で定義する（Palantirが言う"オ ントロジー"）。 LAYER 3 インフラ・連携 クラウド／IaC／CI/CD、監視・ログ。そして既存システムとの統合（レガシーAPI、SSO、閉域網、オンプレ）— ここがFDEの実装工数の大半を 占める。 LAYER 4 RAG／エージェントの本番運用、コンテキストエンジニアリング、Evals（評価設計）、Human in the Loop 設計。「動く」と「業務で信頼でき る」の差を埋める層。 LAYER 5 AIコーディングの使いこなし（＝2人分を1人でやる最大の武器）、初見スタックへの適応力、セキュリティの基礎。 AI / LLM 横断 ※ OpenAIのFDE求人（Tokyo）：「5年以上の顧客対応を含む技術デリバリー経験」「Python/JS等でフロント・バック双方の本番品質コード」「LLM／生成AIシステムの構築・デプロイ経験」／ SF版は「7年以 上のフルスタック経験」「出張50%」を要求
23. 柱③ 開発スキル — 3/4 REAL WORLD 求人票に書かれない、現場で差がつく力 🔍 既存システムのリバースエンジニアリング 🚧 動かない環境を動かす力 ・ドキュメントのないコード・DBから仕様を推定する ・「なぜこの謎の仕様が？」を業務側にヒアリングして紐解く ・謎の運用には必ず歴史的な理由がある ・権限が下りない、VPNが繋がらない、ライブラリが入れられない ・制約の中で代替案を出す（クラウド不可ならローカルLLM、API不可ならCSV連 携） ⚡ 捨てる前提のコードを、速く書く 🛡️ 本番データの怖さを知っている ・検証フェーズと本番の品質を意図的に使い分ける ・ただし「デモ用コードをそのまま本番に流さない」判断もセットで持つ ・個人情報・機密情報・消してはいけないデータ ・バックアップと権限を「最初に」確認する癖 ・15分詰まったら聞く。1人で溺れない 🧨 実際の仕事は、キラキラしたAI実装が2〜3割。残りは「データが汚い」「権限が下りない」との戦い
24. 柱③ 開発スキル — 4/4 HOW TO TRAIN 開発スキルの鍛え方 — 明日からできる4段階 LEVEL 1 — 広げる 担当外の工程を1つ引き取る。インフ ラ、監視、リリース作業など、普段「誰 かがやってくれている」ところへ。 LEVEL 2 — 一周回す 小さくていいので企画から本番運用 まで1人で回す個人開発を1本。運用 の痛みを自分で体験する。 LEVEL 3 — 速くする AIコーディングで「アイデア→動くデ モ」を1日以内に出す練習を反復。速 度は才能ではなく習慣。 LEVEL 4 — 現場に出る 顧客・ユーザーと直接話す場に自分 から入る。要件ヒアリング、サポート対 応、導入支援。 🗺️ 全部を深く知る必要はない。大事なのは「地図を持っている」こと — どこに何があるか分かり、必要になったら潜れる状態
25. TEAM & ORGANIZATION 組織・チームで実現するFDE 完璧なスーパーマンはいない — だから「分業と役割分担」という現実解がある 🤝 2人組で分ける 🧩 チームで3役に分ける 🤖 1人 + AIで補う
26. 組織・チームで実現するFDE REALITY とはいえ、 完璧なスーパーマンはいない — 分業で作るFDE 3本柱フル装備は「目指す方向」であって「前提条件」ではない。元祖Palantirからして2人組＝分業で始めている。 🤝 A：2人組で分ける Delta × Echo 型 ・「作る人」×「現場とビジネスを読む人」のペア ・小規模導入・スタートアップの定番 ・原点にして、いまも最強の分業 🧩 B：チームで3役に分ける 柱ごとに主担当を置く型 ・コンサル・営業／PM／開発リードで分担 ・中規模以上のプロジェクト向き ・ただし全員が越境前提。綺麗に分けきると従来 のSIに逆戻り 🤖 C：1人 + AIで補う 弱い柱をAIで底上げする型 ・コード生成・資料作成・議事録・壁打ちをAIに ・小さく始める案件の現実解 ・AI時代に「1人FDE」が増えている理由 ⚠️ 分業の落とし穴 — 役割を綺麗に分けすぎると「引き継ぎロス」が復活し、ただの分業SIに戻る。タスクは分けても、顧客成果への責任は分けないこと。 🧭 個人の戦略：主戦場の柱を1本深く持ち、残り2本は「会話できるレベル」に — それが分業チームでの自分の居場所になる
27. BEYOND THE JOB TITLE FDEスキルは、 「事業をつくる力」 だから経営者・フリーランスにこそ、この3本柱がめっちゃ効く 課題の設計から実装まで 外注せず一周まわせる 工数ではなく成果で稼ぐ
28. 事業をつくる力 FULL CYCLE OF BUSINESS 3本柱の射程 — ビジネス設計から、 開発の上流〜下流まで FDEの3つの力を横に並べると、事業が一周する工程まるごとをカバーしている STEP 1 課題発見 STEP 2 提案・合意 STEP 3 要件・設計 STEP 4 STEP 5 実装 ① コンサル力・営業力 リリース 運用・改善 ③ 開発スキル ② PM力 — 全工程を貫き、止めずに前へ進める ↺ 運用・改善で見えた次の課題が、また STEP 1 に戻る（Land & Expand） ⚖️ 一般的なエンジニアは右半分（要件〜運用）だけ、一般的なコンサルは左半分（課題〜提案）だけ。FDEは、この一本を最初から最後まで自分で通せる。 💰 この一周が回って、はじめてお金になる。事業とは、要するにこの一周のこと STEP 6
29. 事業をつくる力 WHY IT MATTERS TO YOU だから、経営者・フリーランスにこそ効く 🏛️ 経営者・事業責任者 「作れる経営者」は、打ち手の数が違う ・仮説→検証を外注なしで回せる 待ち時間も外注コストもゼロ。思いついたその週に試せる ・技術的な実現性を自分で判断できる ＝ 意思決定が速い ・一周を知っているから、採用・評価・見積もりの目利きができる ・「作ってから考える」が選択肢になる 検証コストが下がると、打席に立つ回数そのものが増える 🧑‍💻 フリーランス・個人事業主 単価の決まり方そのものが変わる ・時間ではなく「結果」に値段がつく 工程の一部だけ請け負うと、単価は「何時間働いたか」でしか決まらない。 一周まるごと持てば「月40時間の削減」という成果 で値段を交渉できる ・「言われたものを作る」から「課題ごと任される」へ ・元請けになれる ＝ ビジネス上流から入れる 予算と意思決定がある場所から関われる ・1人でも「小さな会社」として機能する 🚀 AIが守備範囲を広げた今、「1人で一周まわす」は現実的になった。FDEは職種名だが、中身は事業を立ち上げる力そのもの ※ 会社員にとっても同じ。この力はそのまま「社内で新規事業を立ち上げる力」になる。
30. まとめ FDE ＝ コンサル × PM × 開発の「総合格闘技」 ① コンサル力・営業力：価値を認めさせられる × ② PM力：前に進められる × ③ 開発スキル：作れる 元はPalantirが Delta（エンジニア）× Echo（戦略）の2人組でやっていたこと。それをAIの力で1人がやれるようになったのが現代のFDE。 つまり今は、「全部そこそこできる人」にかつてない価値がつく時代。 1 【コンサル・営業】先に見せる 資料で語る前に、動くデモを最速で見せる癖をつけ る。 2 【PM】1枚残す 今日の意思決定を、ドキュメント1枚に書いて共有 する。 🧭 3本柱のどこが強くて、どこが弱いか — 自分の現在地を知ることが最初の一歩 3 【開発】1周まわす 担当工程を1つ広げ、企画から本番運用まで自分で 回してみる。
31. THANK YOU ご清聴ありがとうございました Q&A —「自分はどの柱から鍛える？」もぜひ聞かせてください 参考資料：TechCrunch — FDEs are the AI industry's latest talent obsession ／ The Pragmatic Engineer ／ Palantir's FDE Model 分析（Delta / Echo）／ OpenAI FDE 求人（Tokyo / SF）／ Goodpatch Blog — FDEのスキルセット ／ JAPAN AI ラボ ／ Netflixのフルサイクル開発者
32. おまけ 時間が余ったら / Q&Aで使うスライド APPENDIX
33. APPENDIX FDEに向いている人・向いていない人 ✅ 向いている 🤔 向いていないかも 不確実な状況を「面白い」と感じる 仕様が固まっていないと動けない 顧客の成果を自分の成果と感じられる 技術そのものを深く極めたい 完璧より、まず動くものを出せる 作り込んでから見せたい 人と話すのが苦にならない 一人で黙々と作りたい 越境を歓迎する 役割分担を明確にしたい 💬 どちらが良い・悪いではありません。「向いていない」側は、深い専門性で勝負するスペシャリストの資質でもあります。大事なのは、自分がどちらの戦い方で価値を出す かを自覚すること。
34. APPENDIX よくある質問 Q. 普通のエンジニアとの一番の違いは？ Q. 何から始めれば？ 要件が与えられないこと。課題の発見から任され、成果物は「コード」ではなく「顧客 の業務が変わったという事実」。 現職でフルサイクルを意識し守備範囲を1工程広げるのが最短。あわせて顧客接点 のある仕事（ヒアリング、サポート、導入支援）に自分から入る。 Q. コンサルが実装を覚えるのと、エンジニアがコンサル力をつける の、どちらが近道？ Q. 何でも屋になって専門性が失われない？ Q. 激務なのでは？ Q. 自社プロダクトがない会社では？ 一般には後者。実装力は習得コストが最も高く、かつ「動くものを出せる」ことが信 頼の源泉になるため。 顧客の現場・出張・不確実性の負荷は確かに高い（OpenAIのSF求人は出張50%）。 一方で裁量・学習速度・報酬も高い。向き不向きがはっきりする職種。 FDEの専門性は「特定技術の深さ」ではなく「顧客の課題を、動く形にして届けきる 再現性」。ただし技術の軸を1本持っておくと強い。 純粋な定義からは外れるが、スキルセットの価値は変わらない。受託・SIでも「課題 発見から定着まで担う」動き方はそのまま強みになる。