顧客の現場に入って作る仕事では、打ち合わせの終わりに「ついでにこれもお願いできますか」と頼まれることがあります。
受託開発なら、契約書に書いた範囲を根拠に、別の見積もりへ回すのが普通の受け止め方です。
ところが FDE（Forward Deployed Engineer）は、顧客ごとに合わせて作ること自体が仕事なので、契約書の線だけでは判断しきれません。
公開されている求人票と登壇資料を読むと、FDE の線は「断るかどうか」より「何を確かめ、何と引き換えにするか」で引かれていると分かります。
私も FDE を学んでいる途中で、ここに書けるのは一次情報から読み取れる範囲までです。
「範囲外」が最初から決まっていない仕事
FDE の範囲が動きやすいのは、仕事の定義そのものに理由があります。
Palantir の Forward Deployed Software Engineer の募集要項は、中心となる責務の一つに、顧客のニーズに合わせたアプリケーションの開発を挙げています。
求める資質の欄には、目標が変わっていく環境で、利用者と反復しながら働くことに抵抗がないことも書かれていました。
Anthropic の Forward Deployed Engineer の募集要項は、さらに踏み込んでいます。
支援の期間を通じて、AI を使える新しい機会を自分から見つけることまで責務に入れているのです。
頼まれる前に次の仕事を探すことまで求められている以上、新しい要望が出てくること自体は失敗ではありません。
一方で、範囲を決めて守る責任も、FDE 自身の仕事として書かれています。
OpenAI の東京拠点の募集要項 Forward Deployed Engineer – Tokyo には、FDE が持つ工程が最初から最後まで並んでいました。
課題を探るディスカバリーに始まり、技術的なスコーピング、設計、構築、本番展開までです。
スコーピングは、何をどこまで作るかを決める作業のことです。
同じ募集要項の責務には、作業の範囲を決めて届ける順番を組むことが挙がっています。
範囲と速さと品質のあいだでトレードオフをとり、届けることを守るために計画を直すことも並んでいました。
求人票はいずれも 2026 年 10 月 3 日に確認しました。
当初の範囲が、期間や人手を見直さないまま少しずつ広がっていく状態を、プロジェクト管理ではスコープクリープと呼びます。
FDE の現場では範囲が動く前提なので、広がること自体より、引き換えを決めないまま広がることのほうが問題になります。
なお、契約前の段階で範囲を決める仕事は別にあります。
Anthropic の FDE マネージャーの募集要項には、契約前にアカウントチームや Engagement Manager と組んで作業範囲を詰める仕事が書かれていました。
Engagement Manager は、届ける段取りと関係者の調整を受け持つ職種として同じ募集要項に出てきます。
詰めた範囲は、SOW（作業範囲記述書）に反映するとされています。
ここで考えたいのは、その後の常駐中に出てくる頼みごとのほうです。
頼まれた実装を、判断の材料に置き換える
常駐中の頼みごとをどう受け止めるかを、いちばん具体的に語っていたのが Ramp の登壇でした。
Ramp は、法人カードや経費管理のサービスを提供する米国の会社です。
登壇したのは、同社のエンジニアリング部門でディレクターを務める Leo Mehr 氏です。
講演は 2026 年の AI Engineer World's Fair で行われ、題は How Forward Deployed Engineering is done at Ramp（Ramp での FDE のやり方）でした。
同氏が最初に掲げた原則は「Always be scoping」で、常に範囲を確かめ続けよ、という意味になります。
FDE の仕事は顧客にイエスと言うことだと思われがちですが、それは間違いだと同氏は話しています。
頼まれた改良を全部積み上げると、自動運転車の代わりに、脚にロケットをくくりつけた馬のようなものができあがる、というたとえでした。
イエスと言える道は探しつつ、作るのは良いソフトウェアでなければならない、というのが講演の立場です。
例に挙がったのは、金曜の夜に営業担当から「SAP S/4HANA との連携を作らないと、重要な商談がまとまらない」と頼まれる場面でした。
エンジニアはつい SAP の API ドキュメントを探し始めますが、よく訓練された FDE はそこで手を止め、次のような問いで状況を集めるそうです。
| 問い | 確かめること |
|---|---|
| 急ぐ理由はどこから来ているか | 四半期末の営業ノルマのように、顧客ではなく社内の事情が急がせていないか |
| 誰が使うのか | 実際の利用者と、その人が終わらせたい仕事 |
| 代わりの手はないか | 既存の回避策や、当面は手作業で済ませる方法 |
| 顧客側で作れないか | 技術者のいる顧客なら、提供している API を使って自分たちでつなげないか |
| ほかに得をする顧客はいるか | 既存の顧客や商談中の見込み客にも同じ必要があるか |
Mehr 氏は、このうち最後の問い、つまり一件の依頼の外側を見ることを、FDE がするいちばん大事なことに挙げていました。
講演ページの解説文は、こうした問いが「特定の実装を作れ」という要求を、製品の判断のための文脈に変えると説明しています。
結果として同じ連携を作ることになっても、なぜそれが正しい投資なのかを説明できる状態で作り始められるわけです。
講演の例は営業経由の大きな依頼ですが、現場で口頭で出てくる「ついでにこれも」にも、同じ問いはそのまま当てはめられると私は読みました。
聞いた要望をそのまま作ってしまうつまずきは、FDE のコミュニケーション実務を扱った記事でも触れています。
引き受けるときは、引き換えを先に決める
問いを通した結果、作ると決めた頼みごとにも、まだ決めることが残ります。
OpenAI の募集要項にあった範囲と速さと品質のトレードオフを当てはめると、新しい頼みごとを入れるときに動かせるものは3つに絞られます。
- 範囲: いま約束している作業のどれかを後ろへ回す
- 速さ: 約束している期日を延ばす
- 品質: まず試作として出し、本番の水準に仕上げるのは後に回す
どれも動かさずに頼みごとだけを足すと、それがスコープクリープの入口になります。
3つのどれを動かすかを顧客と一緒に決めることが、線を引く作業の中身だと私は理解しています。
頼みごとの入口をそろえておくことも、引き換えを決めやすくします。
Ramp には「FDE Requests」という社内の Slack チャンネルがあり、アカウントマネージャーや営業担当が、顧客や見込み客の障害になっている事柄を投稿する仕組みです。
投稿の中身はばらつきが大きく、事情を詳しく書いたものもあれば、「SAP 連携が要る」の一行だけのものもあるそうです。
以前は FDE が一件ずつ読み、製品で既にできることを確かめ、顧客とやり取りして必要なものを見極めていました。
そこで同社は Notion のエージェントを使い、投稿に対して最初の質問を自動で返す仕組みを作りました。
最初の版は依頼を受け取って質問を2つほど返すだけでしたが、数週間で、数時間から数日かかっていた返答が数秒で返るようになったと説明されています。
後の版では、仕様を書ける状態になったと判断するまで、投稿者と何往復か質問を重ねるようになりました。
Mehr 氏はおおまかな見積もりとして、依頼の範囲を確かめる時間の2割ほどが減ったと話しています。
ここから読み取れるのは、頼みごとを口頭のまま実装へ流さず、一つの入口で記録して問いを先に回す、という順番でした。
落とし穴は「作れてしまう」ことにある
範囲の確かめを飛ばしたときに何が起きるかも、同じ講演で語られていました。
大きな顧客が、経費の立替精算の機能をモバイルで使いたいと求めた、初期の案件です。
社内のモバイルチームは手一杯だったため、FDE の2人が iOS と Android の開発を覚え、数週間かけて両方の機能を作り上げました。
ところが Android のベータ利用者を出してほしいと顧客に頼んだところ、その会社は全社員に iOS 端末を使うよう義務づけていると分かったそうです。
作る力が足りなかったのではなく、どの端末を使っているかという基本の前提を、作る前に確かめなかったことが原因でした。
手が速く、新しい技術もすぐ覚えられる FDE ほど、問いを飛ばして作り始めやすいと言えそうです。
講演の後半は、生成AIのエージェントで仕事の量を広げる話でした。
情報集め、範囲の確かめ、仕様書き、実装という FDE の工程を、一つずつエージェントに置き換えていく考え方です。
ただし範囲の確かめが弱いままだと、作る速さが上がった分だけ、方向のずれた成果物も増えていきます。
Mehr 氏はその状態を「token maxing slop cannon」、トークンを使い倒して質の低いものを撃ち出す大砲と表現しました。
講演ページの解説文も、ロケットをくくりつけた馬は自動化しても消えず、むしろ作りやすくなるとまとめています。
作業の多くをエージェントに任せても、最終的な出来を見極める判断は FDE に残る、と同氏は話していました。
どの頼みごとに時間を使うかを決める難しさは、FDE の仕事の進め方を扱った記事の最後でも取り上げています。
最後に
FDE の範囲は、顧客に合わせて作る仕事である以上、最初から動く前提で組まれています。
だからこそ線は契約書の一行で引くのではなく、頼みごとが出るたびに現場で引き直すことになります。
Ramp の問いは頼まれた実装を判断の材料に変え、OpenAI の募集要項にある範囲・速さ・品質のトレードオフは、引き受けるときの引き換えを決める物差しです。
「ついでにこれも」と言われたら、作り始める前に「誰のどの仕事のためか」と「代わりに何を動かすか」の2つを確かめると、断らずに線を引けます。
以上です。
コメントを残す