FDEはただのプログラマーじゃない。比較表で違いがひと目でわかる

同じくコードを書く仕事でも、一方はオフィスで要件に対応し、もう一方は顧客現場で結果に責任を持ちます。違いは技術力ではなく、「何に対して責任を持つか」です。

ここ2年、面白い現象があります。コードを書き続けていたプログラマーの一群が、突然職名を**FDE（Forward Deployed Engineer、フォワード・デプロイド・エンジニア）**に変え、年収と発言権が一段階上がりました。

そこで疑問が出ます——FDEは結局「プログラマーが看板を変えただけ」なのか？

まず結論を述べます。看板ではなく、責任の境界が変わったのです。 以下、4つの次元から分解して説明します。読み終えれば、自分がどちら側に向いているか分かります。

まず最も鍵となる一言：何に責任を持つかが、あなたの職種を決める

職種の本質を判断する最も手っ取り早い方法は、その責任の終点がどこにあるかを見ることです。

プログラマーの責任の終点は、通常「機能ができた、テスト通過、リリース発表」に落ち着きます。機能を納品したその瞬間、主な仕事は終了です。この機能がリリース後に何人使ったか、業務が良くなったかは、もっとプロダクト、運営と顧客自身の問題です。

FDEの責任の終点は、「業務結果が本当に良くなった」に落ち着きます。機能リリースは起点に過ぎず、後にもっと長い道があります。ユーザーは使うか？使ってどれだけ時間を節約したか？節約した時間はお金に変わったか？もし良くならなければ、プロセスが間違っているか、データが間違っているか、それともソリューション自体がシーンを選び間違えたのか？

一言でまとめると：

プログラマーは機能に責任を持ち、FDEは業務結果に責任を持ちます。

この言葉は言葉遊びではありません。責任の終点が異なれば、連鎖的にあなたが毎日何をするか、誰と話すか、どう「やり終えた」を定義するかに影響します。

次元対照表：一目で差が分かる

この表は保存をお勧めします。面接で「あなたは自分がプログラマーかFDEだと思いますか」と聞かれたとき、この6行に沿って話せば、形容詞を並べるより役立ちます。

次元一：仕事対象——一方は機械、もう一方は人

プログラマーが一日で最も打ち合わせるのは、確定性が非常に高いものです。コードがエラーを報告するか、インターフェースの戻りが正しいか、テストカバレッジが十分か。機械は嘘をつきません。動かなければ動かない、フィードバックは非常にきっぱりしています。

FDEが一日で最も打ち合わせるのは、確定性が非常に低いものです。業務担当者が口では「AIが欲しい」と言っても、実際に欲しいのは「残業を2時間減らす」かもしれません。プロセス責任者が「この工程は非常に重要」と言っても、掘り下げると3年間誰も手順通りにやったことがないと分かります。意思決定者が気にするのは投入産出比で、あなたのモデルパラメータではありません。

だからFDEには特に核心的な動作があり、ニーズ翻訳と呼ばれます。顧客の口から出る曖昧で、感情的で、さらには自己矛盾する話を、技術で解決できる、検収可能な具体的な問題に翻訳します。

一つの汎用シーンを挙げます。カスタマーサービス部門が「AIでカスタマーサービスの効率を上げたい」と言います。

直接着手すれば、大体カスタマーサービスロボットを作ることになり、誰も使いません。翻訳後は変わるかもしれません。「毎日800件の重複相談のうち、チケット分類工程を自動化し、平均処理時間を6分から3分以内に圧縮する」と。

同じ訴求が、翻訳前後で全く異なるプロジェクトになります。これがFDEの最も価値のある部分です——コードが書けることではなく、どのコードを書くべきか知っていることです。

次元二：納品物——機能は終点か、起点か

プログラマーが納品するのは一つの機能です。このボタンがクリックでき、このインターフェースが呼び出せ、このページが表示できます。

FDEが納品するのは一つの完結したサイクルです。顧客が問題を提起してから、この問題が実際の業務フローで解決され、かつ計量できるまでです。

一つの完結したサイクルは少なくとも4段階を含みます。

1. プロセスが現在どう動いているか理解する——お金、情報、伝票が誰の間で流れ、どの工程で詰まるか
2. どの工程が最も動かす価値があるか判断する——繰り返し性が高いか、複雑度が高いか、節約した時間がお金に換えられるか
3. 最小納品可能なものを作る——大プラットフォームではなく、一つの小工程が通れば十分
4. リリース後指標を見守る——ユーザーは本当に使い始めたか？数字は変わったか？変わらなければ戻って直す

4段目に注意してください。多くのAIプロジェクトはこの工程で「死にます」。ものはできました、デモは成功しました、会議で皆拍手しました、それで終わりです。3ヶ月後に振り返ると、誰も使っていません。

FDEの存在意義は、4段目を発生させないことです。

次元三：技術の位置——目的は手段か、手段は目的か

これは2つの職種が最も衝突しやすい部分です。

プログラマーの文脈では、技術自体がしばしば目的の一部です。アーキテクチャは優雅でなければならず、コードは保守可能でなければならず、性能は極限まで圧縮しなければなりません。これらの追求は完全に正しく、専門性の体現でもあります。

FDEの文脈では、技術は徹底的な手段です。非常に典型的な判断基準があります。

もし非常に愚かな方法（例えば一段のスクリプト + 一枚の表 + 人工でクリック）で、2日以内に80%の問題を解決できるなら、FDEはそれを選びます。2ヶ月かけて100%の問題を解決する綺麗なシステムを作るのではありません。

なぜか？FDEの第一目標は有用性を証明することだからです。 まず有用性を証明して、初めて大きくする話ができます。2ヶ月動いた完璧なシステムは、途中で顧客の予算が削られたり、担当者が変わったり、業務方向が変わったりして、直接胎死腹中になるかもしれません。一方、2日で作った愚かな方法は、今日人に2時間節約させ、明日より多くのリソースを要求する理由になります。

これはFDEが技術品質を重視しないという意味ではありません。違いは優先順位の並び方にあります。まず生き残り、それから優雅さを語るのです。

次元四：成功基準——「リリースした」と「使い始めた」の間に太平洋

プログラマーの達成感の源は通常非常に具体的です。要件ができた、Bugを直した、負荷テスト通過、リリース成功。

FDEの達成感の源は半拍遅く、もっと難しいです。最前線の人が主動的に使い始めた、ある指標が3週間連続で下がっている、顧客が主動的に「これをもう一つの部門に拡大できないか」と提起した。

この2つの基準に優劣はありませんが、一人を2つの基準で同時に考課することはできません。もしFDEが「どれだけの機能を納品したか」で考課されれば、彼は必ず第二の営業担当者に退化します——これが多くの企業がFDEを雇っても使いこなせない根本的な理由です。

では共通点は？技術を理解すること、この点は例外なし

これだけ違いを話したので、よくある誤解を澄明しなければなりません。FDEは「技術を理解しない営業」でも、「話せるプロジェクトマネージャー」でもありません。

FDEは依然として技術職です。 それはあなたに要求します：

• インターフェースドキュメントが読め、2つのシステムを接続できる
• 基礎スクリプトを書いてデータを処理でき、データがどこで汚れているか分かる
• 大規模言語モデルの能力境界を理解し、何ができて何ができないか分かる
• 自分で手を動かして動くプロトタイプを組み立てられ、PPTを描いて他人の実装を待たない

違いは深さの要求が異なることです。FDEは一般的にモデルを訓練したり、アルゴリズム論文を読んだり、ミリ秒レベルまで最適化する必要はありません。しかし技術面が十分広く、一山のツールから使えるものを素早く選び、それを本当に組み立てられることを要求します。

一言で技術の敷居をまとめると、ある領域のトップ選手である必要はないが、複数の技術を組み合わせて問題を解決できる人でなければなりません。

どんなプログラマーがFDEに転向するのに向いているか？

全員が適しているわけではありません。もしあなたが下の3条のうち2条以上に合えば、FDEへの転向の適合度は比較的高いです。

第一、あなたは「これ誰も使わない」で悩みます。 多くの人は機能ができれば満足します。あなたは思わず追及します「結局誰か使ったか、どう使ったか」。この追及がFDEの起点です。

第二、あなたは人と話すのが厭わず、話し終えて収穫があります。 外向的という意味ではなく、業務担当者の愚痴から本当の問題がどこにあるか聞き取れ、中断されても苛立たないということです。

第三、あなたは不完全を受け入れられます。 FDEは毎日取捨をしています。精度が少し悪くてもリリースできる、インターフェースが少し醜くても使える、ソリューションが少し愚かでも今日動かせる。完璧を追求する人は非常に苦しいでしょう。

逆に、もしあなたが最も楽しむのが技術を極限まで追求することで、最も嫌いなのが終わりのない会議と要件変更なら、誠実に優秀なプログラマーをやる方が、性価比が高いかもしれません。

最後に、人を怒らせるかもしれない一言

FDEは非常に持て囃されていますが、プログラマーの「アップグレード版」ではありません。

それは技術の価値実現ルートを一歩前に移動させただけです——「私が作った、あなた方が使いに来て」から、「私があなた方が結果を使うのを見守る」に変わりました。

技術力の高い人はFDE職でも依然として貴重です。コミュニケーション能力の高い人はFDE職でより始めやすいです。 本当の分水嶺は決してコードが書けるかどうかではなく、自分が書いたコードが実世界で生み出す結果に責任を持つ意志があるかどうかです。

この問題を考え抜けば、3つのフレームワークを多く学ぶより役立ちます。

私が誰かは重要ではなく、重要なのはこの一式があなたに役立つことです。これから30日間、FDEを概念から方法まで、一条一条分解してお見せします。

FDEを体系的に学び、私が整理したFDE学習資料パックを入手したいですか？本号をフォローして、今後の更新を見逃さないでください。

本文はFDE 30日入門連載第3篇です。文中に関わる職種対比は汎用業界認識であり、具体的な職責は各社の実際の求人要件を基準とします。