FDEのスキル地図——実装・顧客折衝・運用移管の三層（シリーズ2/5）

目次▼

1. 1結論を先に
2. 2まず用語の地図
3. 3具体例：層1 —— 実装（通るものを出す）
4. 4層2 —— 顧客折衝（合意を取る）
5. 5層3 —— 運用移管（居なくても回る）
6. 6三層の合計で見る
7. 7よくある偏り
8. 8いまの一手

第1回で、FDE（Forward Deployed Engineer）は「実装・客先・通しきる」の三条件だと書いた。第2回は、その三条件を身につける順のスキル表に落とす。

転職を決めていなくても、「自分のいまの仕事は、どの層が薄いか」の健康診断として読める。用語は都度かみ砕く。

この記事の使い方

• 決めること: 自分が強い層／薄い層を一文で言えること
• 決めないこと: まだ「どの講座を買うか」（講座より、現場の痕跡が先）
• 前提: 完璧なフルスタックを目指さない。FDEは薄い縦スライスを通す力の職種

結論を先に

層	必須の核	後回しでよいもの
実装	本番相当で動くAPI／UIの一本、型と失敗時の振る舞い、ログ	最新モデルの全暗記、研究論文の追跡
顧客折衝	曖昧な要望→受け入れ条件、関係者の調整	華麗なプレゼンだけ、営業ノルマ
運用移管	権限・監視・引き継ぎ文書、責任分界点	客先に居座り続ける「何でも屋化」

三層すべてが「得意」である必要はない。ただしどれか一つがゼロだと、別職種の方が合う。

まず用語の地図

用語	かみ砕いた意味
顧客折衝	相手とすり合わせて決める対話。売り込みトーク単体ではない
受け入れ条件	「これができたら完了」と双方が合意するチェック項目
運用移管	作り手が居なくても回る状態にして渡すこと
責任分界点	ベンダー（売り手）と顧客、それぞれ何を責任持つかの線
可観測性	壊れたとき、ログ・指標・痕跡から原因を追えること
権限設計	誰が何を見られ／実行できるかの決め方
縦スライス	画面だけ・裏側だけ、ではなく端から端まで通る最小機能
技術的負債	急いで通したあとに残る「後で直す約束」。無いふりをしない

具体例：層1 —— 実装（通るものを出す）

FDEの実装は、OSSのスター数より本番相当で通るかが先。

必須

1. HTTP API か同等の境界を1本書ける — 入出力が説明できる
2. 失敗を設計できる — タイムアウト、権限エラー、再試行の可否を黙殺しない
3. 型かスキーマで契約を固定できる — TypeScriptのZod、PythonのPydanticなど。モデル出力を「文章として正しい」だけで信じない
4. ログを残せる — 客先の情シス（情報システム部門）に「何が起きたか」を見せられる
5. デプロイの最低限 — 自分の変更を、検証環境から本番相当へ載せられる

あると強い

• フロントの薄い画面（現場が触れるデモ）
• データ連携（CSV／既存SaaS API／社内DBの読み取り）
• 生成AIのツール呼び出し（モデルに外のAPIを触らせる仕組み）の失敗処理

後回しでよい

• 全モデルのベンチマーク暗記
• 論文実装の再現競争
• 「美しい」マイクロサービス分割（客先の最初の1本には過剰なことが多い）

自己採点（実装）

点	目安
0	チュートリアルどおりのものしか動かしたことがない
1	個人プロジェクトは動くが、権限・ログがない
2	仕事で本番相当に出した経験が1本以上ある
3	他人の本番障害を、ログから切り分けた経験がある

2未満なら、講座より先に「本番相当の一本」を作る方が、転職にも職場改善にも効く。

層2 —— 顧客折衝（合意を取る）

ここが弱いと、優秀な実装でも客先では通らない。

必須

1. 現状の業務フローを図にできる — 誰が入力し、誰が止め、誰が決裁するか
2. 要望を受け入れ条件に翻訳できる — 「便利にして」をそのまま受け取らず、検証できる文にする
3. 関係者のズレを言語化できる — 現場は速さを、情シスは監査を、事業は数字を欲しがる、など
4. スコープ（やることの範囲）を守れる — 「ついでに」で本稼働が遠ざかるのを止められる
5. 稟議・審査の待ちを織り込める — 技術のカレンダーだけで勝負しない

あると強い

• 議事の要約をその日のうちに返す習慣
• 「今はやらない」リストを合意として残す力
• 英語／日本語の切り替え（外資系プロダクト＋国内顧客の案件）

後回しでよい

• 営業としてのクロージング技術そのもの（FDEの主戦場は「通す」こと）
• スライドの見た目を過度に磨くこと

自己採点（顧客折衝）

点	目安
0	仕様書が来るまで動けない／動きたくない
1	社内の隣の席とのすり合わせはできる
2	他部署や外部と、受け入れ条件まで合意したことがある
3	対立する部門のあいだで、通る線を自分から提案したことがある

層3 —— 運用移管（居なくても回る）

FDEの仕事は「自分が英雄で居続ける」ことではない。いなくなっても回ることが成果だ。

必須

1. 最小権限 — 自分のアカウントが管理者のまま残らない
2. 監視とアラートの入口 — 壊れたとき誰が気づくか
3. 運用手順の一文以上 — 再起動、権限追加、問い合わせ先
4. 責任分界点の明示 — バグはベンダー／データ品質は顧客、など（案件ごとに違う）
5. 引き継ぎの完了定義 — 「ドキュメントを置いた」ではなく「顧客側が独力で1操作できた」

あると強い

• 監査ログの設計
• 障害時の連絡テンプレート
• 現場向けの短いハンズオン

後回しでよい

• 完璧な社内Wiki体系
• 客先のIT部門そのものを作り直す壮大な計画

自己採点（運用移管）

点	目安
0	自分が居ないと止まる仕組みしか作ったことがない
1	READMEはあるが、他人が読んでも再現できない
2	他人が手順どおりに回せた実績がある
3	自分が抜けたあと90日、大きな問い合わせなしで回った経験がある

三層の合計で見る

合計	いまの立ち位置
0–3	まずは本社エンジニアとしての強化か、小さな社内導入から。FDE求人はまだ早い
4–6	弱い層を1つ埋めれば候補。第3回の「証拠」で弱点の見せ方を変える
7–9	選考に進んでよい水準。足りないのは会社研究とストーリー整理が多い

AI特有のスキル（プロンプト、評価セット、モデル比較）は実装層の加点として足す。土台の三層がないと、客先ではほぼ使えない。

よくある偏り

1. 実装だけ強い — PoCは通るが、稟議と情シスで止まる
2. 折衝だけ強い — 約束が実装に落ちず、信頼を溶かす
3. 運用だけ強い — 守れるが、新しい経路を通す速度が足りない
4. AIだけ強い — デモは美しいが、権限とデータの取り決めの前で止まる

偏り自体は普通だ。危険なのは、偏りを職種全体の定義だと思い込むことだ。

いまの一手

本気で狙う人

1. 三層を 0–3 で自己採点し、一番低い層だけ今週のテーマにする
2. 低い層向けに、第3回で使える「通しきった話」の種を1つ仕込む
3. 講座を買う前に、本番相当の縦スライス計画を書く

まだ様子見の人

1. 自社の直近プロジェクトを三層で採点する（個人ではなく案件）
2. どこで止まったかを「モデル／業務／権限／決裁」に分類する
3. 組織に足りない層がFDE的な役割かどうかだけメモする

次の 第3回（証拠の作り方） では、職務経歴書に載る「現場で通した痕跡」の残し方を書く。シリーズ一覧は FDEハブ。

※この記事の内容についてご意見・ご指摘がある場合は、お問い合わせよりご連絡ください。確認の上、必要に応じて追記・訂正します。