FDE（Forward Deployed Engineer）という肩書きを初めて見たとき、頭に浮かんだのは「これ、日本のSIerでいう常駐エンジニアと何が違うんだ」という素朴な疑問でした。
顧客の現場に入り、業務を聞き取り、動くシステムを形にする。
字面をなぞるだけなら、クラウドベンダーのソリューションアーキテクトとも見事に重なって見えます。
似た職種の違いを言葉にできないまま、なんとなく流してしまったことはありませんか？
私自身はFDEを経験しておらず、公開されている一次情報を読み解いている立場ですが、それでも三つを切り分ける軸は四つに絞り込めました。
名前が似て見えるのは、入口が同じだから
三つの職種は、どれも顧客の困りごとから話が始まります。
分かれ道が現れるのは、その先で誰の何を背負うのかという部分。
FDEは顧客の中に入って作り、SIerは契約した範囲を完成させ、ソリューションアーキテクトは設計の意思決定を支えます。
同じ「顧客に近い技術者」でも、責任の重心が三者三様にずれているのです。
FDEは一社のために、多くの機能を成立させる
FDEという働き方を開発の方法論そのものとして掲げているのがPalantirです。
同社のアーキテクチャセンターの解説では、Forward Deployed Engineering を「人間版の誤差逆伝播」と表現しています。
問題にできる限り近づいたエンジニアが、中核の開発チームと連携しながらフィードバックを絞り出し、新しい機能を出し続ける。
顧客の現場そのものを、製品を鍛えるための材料に変えてしまう発想。
AI企業でも同じ動きが起きていて、AnthropicのFDE求人票には、顧客のシステムの中でClaudeを使った本番アプリケーションを作ると書かれています。
顧客へ渡す技術的な成果物として並んでいるのは、MCPサーバーやサブエージェント、エージェントスキルといった手触りのある部品です。
さらに再現可能な導入パターンを見つけて製品と開発チームに知見を還元するところまでが職務範囲に含まれています。
顧客先への出張は25%程度と明記されていて、現場に足を運ぶことが前提の職種だと分かるのです。
SIerは決めた形のシステムを完成させて納める
SIerは日本で定着した呼び方で、一次請けとしてシステム構築をまとめて請け負う事業者を指します。
要件定義から設計、開発、テスト、運用まで、工程を通して面倒を見る座組みが基本形。
一番大きな違いは、成果物が「発注者と合意した仕様どおりのシステム」に固定されている点です。
検収が通れば、そのプロジェクトはいったん閉じます。
体制は解散し、メンバーはそれぞれ次の案件へ移っていく。
現場で溜めた知恵を社内のテンプレートや再利用部品として残せても、外に売る製品の仕様へ跳ね返る回路は構造的に細いまま。
自社パッケージを持つ会社なら事情は変わりますが、受託が主戦場である限り、この非対称はついて回ります。
ソリューションアーキテクトは設計と助言で選択肢を絞る
三つ目は、クラウドベンダー各社が役割としてはっきり定義している職種。
MicrosoftはAzureソリューションアーキテクトの認定ページで、責務を「ステークホルダーに助言し、ビジネス要件をAzureの設計へ翻訳すること」と説明しています。
しかも設計の拠り所としてWell-Architected FrameworkとCloud Adoption Frameworkという枠組みを名指ししているところが面白いポイント。
実装そのものは開発者や管理者、セキュリティエンジニア、データエンジニアと組んで進めるものだと書かれています。
AWSの認定ソリューションアーキテクト（アソシエイト）のページを読むと、輪郭はさらにくっきり浮かんできました。
試験の主題はコストとパフォーマンスを最適化した設計で、深いハンズオンのコーディング経験は必須ではないと明記されています。
つまり手を動かして作り切ることより、正しい選択肢まで絞り込むことに軸足が置かれているのです。
四つの軸に並べ直すと輪郭が出る
三者の説明を突き合わせて、私は次の四つの軸に落とし込んでみました。
誰の課題を解くか、何を成果物として置くか、案件が終わったあとどうなるか、そして製品への還流があるか。
- 誰の課題を解くか：FDEは特定の一社の業務課題、SIerは発注者と合意した要件、ソリューションアーキテクトは顧客のアーキテクチャ上の意思決定
- 成果物は何か：FDEは顧客環境で動く本番アプリや部品、SIerは検収を受けるシステム一式、ソリューションアーキテクトは設計・提案・レビュー
- 終わったあとどうなるか：FDEは関係が続いて次の適用先を探す、SIerは体制を解散して次案件へ、ソリューションアーキテクトは別の顧客の設計へ
- 製品への還流：FDEは職務として明記、SIerは自社資産に留まりやすい、ソリューションアーキテクトは要望として製品側へ届ける
この四つで並べ直すと、FDEだけが「作ったものが自社製品の次の仕様になる」回路を職務の中に持っていると分かります。
Palantirが方法論に据え、Anthropicが求人票へ書き込んでいるのは、突き詰めればこの一点。
顧客の現場が、そのまま製品の伸びしろになるという構造に、私はようやく腑に落ちました。
違いが分かると、足りない筋肉も見えてくる
三つを分けて考えられるようになると、次は自分の持ち駒の偏りが気になってきます。
要件が固まったあとの工程を磨いてきた人にとって、FDEが求める顧客と直接話して課題そのものを定義する力は、意識して足していく領域。
反対に、設計と助言に強い人が実装まで持ち切ろうとすると、こんどは本番運用の泥臭さが壁になります。
どれが上でも下でもなく、鍛える筋肉が違うだけ。
三つの求人票と公式ドキュメントを並べて読むだけでも、自分がどこを伸ばしたいのかという判断材料は一気に増えました。
FDEという職種そのものの成り立ちについては、この連載の一本目が詳しいです。
要件が固まる前に動かして確かめるという進め方そのものは、別の記事で整理しました。
最後に
FDEとSIerとソリューションアーキテクトは、顧客に近いという一点だけが共通していて、背負うものはきれいに分かれています。
誰の課題か、何を納めるか、終わったあとどうなるか、そして製品へ返るか。
この四つを手元に置いておくと、求人票を読むときも、自分の次の一手を選ぶときも迷いがはっきり減ります。
私もまだ一次情報を読み解いている途中なので、分かったことがあればこの連載に足していくつもり。
以上です。
コメントを残す