FDE と SI の差は、要件を誰が書くかだ

FDE とは何か

FDE は Forward Deployed Engineer の略で、前方に配置されたエンジニアという意味だ。前方は軍の言葉から来ている。本部で汎用製品を作る人ではなく、顧客企業の中に入り、そのデータと会議と詰まりの席に座ってコードを書く人だ。

この名前を作ったのは Palantir だ。Palantir の中では役割が二つに分かれることが多い。Forward Deployed Software Engineer（FDSE）は顧客環境に製品を載せ、開発と配備を担う。Deployment Strategist はその前で問題を選び、利害を揃える。韓国で今 FDE と呼ぶ席は、この二つを一人に束ねることが多い。

Toss、AWS、Microsoft、Google、OpenAI のように自社の仕組みを顧客の中に植える会社が、この席を採っている。名前が格好いいからではない。顧客の建物を出ると、本当の問題が見えなくなるからだ。B2C はアンケートと画面で問題を見られる。B2B は、その会社の中に入らなければ、判断がどこで止まるかが見えない。

SI と八割重なる

SI はシステムインテグレーションだ。顧客が使っている仕組みをつなぐか、欲しい仕組みを作って納品する仕事。韓国では長く育った産業で、現場に出て要件を受け、構築し、検収を受ける流れはすでに存在する。

FDE も顧客の現場に出る。要望を聞き、仕組みを載せ、動かす。Hype Check EP.3 はこの重なりを八割前後と見ている。測定値ではなく、仕事の要素を一つずつ広げてみた推定だ。海外でも、ソリューションアーキテクトやコンサルタント、SI エンジニアのリブランディングではないか、という声がある。的外れではない。現場に常駐し、構築して出ていく形だけ見れば、同じに見える。

求人の名前だけ FDE に変えても、仕事は自動では変わらない。入社したあとも、顧客が書いた画面リストをそのまま実装するなら、その人は SI エンジニアと同じだ。分かれる点は肩書きではない。要件文書を誰が、いつ書くかだ。

残りの二割は、要件を誰が書くか

RFP は Request For Proposal、顧客が「これを作ってほしい」とまとめた提案依頼書であり、要件文書だ。伝統的な SI は、この文書がかなり細かくなってから開発が始まる。画面、機能、日程、検収基準がすでに書いてある。開発者の仕事は、その文書を実装し、配備する側に近い。

その文書を書く人は、多くの場合、現場の実務者ではない。コンサルティング会社が顧客の言葉を受け取って具体化することが多い。コンサルの仕事は、顧客が望むビジョンを文書に入れることだ。顧客も自分の問題をすべて知らない。問題でないことを過大に読んだり、本当の詰まりを落としたりする。そうしてロックされた文書が開発に渡ると、開発者は現場を取り直す工数が残っていない。すでに企画された構造に合わせる仕事になる。

FDE はこの順序を変える。顧客が要件を仕上げてくれるまで待たない。最初の仕事は開発ではなく観察だ。人々がどのデータを見、どの順で働き、どこで判断が止まるかを先に見る。「ダッシュボードを作って」と言われても画面は描かない。その画面が必要な意図を聞く。現場に入ると、問題はダッシュボードの不在ではなく、部署ごとに同じ指標を違う意味で読んでいることかもしれない。そのとき作るべきは画面ではなく、指標の定義だ。

契約に入れる四行

名前を FDE にするだけでは足りない。会社は顧客との契約で「この順で仕事をする」と書かなければならない。FDE 自身も「顧客が言ったことを実装する人」という自己像から離れなければならない。片方だけ変わると、現場はまた RFP 実装に戻る。

下の四行は、提案書や SOW（作業明細書）にそのまま貼れる実務の下書きだ。法務レビュー前の文である。核は一つ。初週の成果物を画面から観察メモに変えることだ。

この条項がないと、顧客は初週に画面を求め、供給側は工数がロックされた状態で拒む根拠がない。条項があると、「ダッシュボードを作って」は受諾ではなく、質問の始まりになる。

第n条（発見週）
1. 最初の五営業日の成果物はソフトウェアではなく観察メモとする。
2. 発注者が示した機能リストは仮説である。発見週の終了時に双方が問題定義を書き直す。それまで開発工数と画面仕様は確定しない。
3. 発注者が求めた画面が現場観察と食い違う場合、受注者は実装に入る前に問題定義を修正する権限と義務を持つ。
4. 発見週で確認したデータ構造・意思決定の型・指標定義は、納品物とは別に発注者の内部文書として残す。

初週、月から金まで

条項だけ入れて現場が同じなら意味がない。発見週の五日はこう使う。開発環境は要らない。ノートと、一つの仕事を一日ついて歩く許可があれば足りる。

月曜日は画面リストを受け取らない。一つの仕事の一日をついて歩く。誰がどの画面を開き、どこに数字を書き、誰に聞き、どこで止まるかだけ書く。火曜日は同じ数字を一つ選ぶ。売上、在庫、待ち時間など、会議に出る指標でよい。その数字を部署が二つ以上あるところに聞き、読み方が割れるかを見る。水曜日は止まっている意思決定を一つ選ぶ。解く価値があるかだけ一行書く。画面は作らない。

木曜日はその問題だけで最小の仮説を書く。「A と B が同じ名前を違う計算で使っている。名前を揃えると会議が短くなる」。これは仮説だ。まだ開発工数は確定しない。金曜日は顧客と問題定義を書き直す。ここから開発範囲が開く。金曜の問題定義が最初の機能リストと同じなら、そのリストは仮説ではなく確認済みの問題だ。違ってもよい。違うほうが、この週の成果だ。

現場で書いた問題が数字になった場所

Palantir の公開事例は、この順序が「仕様どおり納品」とどう違うかを示す。数字は動画の字幕ではなく、病院と Palantir Impact が公開した値を使う。

Tampa General Hospital は 2021 年から Palantir Foundry を使っている。病院の発表（2024-06-05）は、患者配置にかかる時間を 83% 減らし、麻酔後回復室（PACU）の滞留を 28% 減らしたと書く。あらかじめ完成した「災害対応画面仕様」があった席ではない。患者情報、人員、病床がシステムに散らばり、配置判断が遅れていた現場の詰まりだ。

Panasonic Energy of North America は、熟練技術者の頭の中と個人メモ、過去の作業記録にあった障害対応を、Ask Atom という現場補助に集めた。Palantir Impact に載る保全マネージャ Tara Meisinger の言葉はこうだ。三か月から六か月かかっていた学習曲線が数週になった。文書をまるごとチャットボットに入れた結果ではない。センサ、修理チケット、非構造化ファイルをつないで初めて、新人も同じ問いに届ける。

Airbus は 2015 年、Foundry で A350 生産の日程、人員、部品、欠陥を一つの画面に集めた。Palantir Impact は A350 の引き渡しが 33% 速くなったと書く。2017 年、その構造は Skywise という航空産業プラットフォームに育った。一つの工場の鋭い詰まりから入り、あとから産業全体へ広げる形だ。FDE の堀は納品画面ではなく、現場から掬い上げて会社の中に戻ってくるデータ構造と意思決定の型にある。

実装が安くなるほど、誤った RFP は速く積もる

生成 AI で SI が死んだ、という言い方は言い過ぎだ。変わったのはコードを書き、画面を描く費用だ。要件がすでに正確に決まっているなら、顧客社内の AI チームでも以前より少ない人数で同じ画面を作れる。それは外の FDE の値ではない。

値が大きくなるのは問題を定義する仕事だ。顧客が本当に困っているのは画面の不在ではなく、何を自動化すべきか分からない段階であることが多い。問題を誤って定義したまま AI で実装すると、誤った画面がより速く増える。スロップだ。コードを多く作ったことが成果ではない。

だから FDE を運用する会社は顧客との契約で順序を明示し、FDE 個人は顧客が求める画面の下にある意図を問えなければならない。企画から配備まで一人が責任を持つので負担は大きい。その負担が年俸に見える席でもある。名前は重要ではない。これから開発という仕事は、問題を提案し、作り、説得する仕事に近づくだけだ。

今日やること

進行中か、これから開くプロジェクトの契約書や作業明細書を開く。初週の成果物が画面、機能リスト、プロトタイプと書いてあれば、その行を観察メモに変える。上の四行の下書きを貼る。法務レビューの前に、顧客がその順序に合意するかが核だ。

今週の会議に出てくる数字を一つ選ぶ。売上、在庫、待ち、不良率など、名前が同じ指標でよい。部署が二つ以上あるところに、その数字をどう計算するか聞く。読み方が割れたら、その差を今週の問題定義に書く。割れなければ次の数字へ行く。

顧客がすでに RFP を送ってきていても、発見週は開ける。文書を捨てるのではない。機能リストの横に「仮説」と書き、五日後に同じリストを書き直す。残った行が、そのプロジェクトの本当の範囲だ。