FDEとSES・SIerの違いを3点で整理する——指揮命令・自社製品・工程

「言い換えでは？」という疑問が生まれる理由

「FDEとは結局、客先常駐の言い換えではないか」——この疑問は正直な反応だ。

FDEもSESも、エンジニアがクライアント企業の現場に入り込んで働く形を取る。採用ページの文面も、仕事の外見も、大差がないように見える。IT業界では職種名のリブランディングによる印象操作が繰り返されてきた背景もあり、「また同じことを別の名前で呼んでいるだけでは」と警戒するのは自然な読み方だ。

ただし疑問を持ったまま採用や発注の判断をするのは危うい。3つの軸で構造を確認すれば、同じに見える場面と明確に異なる場面が分かれる。

なお、FDEの語の起源と概念の輪郭については「FDEとは何か」にまとめているため、定義の確認はそちらに委ねる。ここではSES・SIerとの比較に絞る。

---

3つの軸で並べると見えてくること

① 指揮命令系統

| | 誰の指揮下で動くか | |---|---| | SES | クライアント企業（準委任・派遣の形式を問わず実態としての作業指示が発生する） | | FDE | 自社（エンジニアリング会社）の製品戦略・方針 | | SIer | 請負契約が原則。指揮命令はなく成果物を納める |

SESで問題になりやすいのが「偽装請負」だ。形式上は準委任・請負であっても、クライアントから直接「今日はこの作業をやってほしい」と指示を受けていれば、法的なリスクが生じる。FDEはここが根本的に違う。現場に入るのは自社製品の導入・定着を推進するためであり、エンジニアは自社の目的を持って動く。

② 自社プロダクトの有無

これがFDEを定義する核心に近い。FDEは自社のソフトウェアやプラットフォームを顧客環境に根付かせることを仕事の出発点とする。製品の内部構造への深い理解、他社事例の横断的な蓄積、ユースケース開発の経験が武器になる。

一方、SESはスキルセットを時間単位で提供するモデルであり、特定製品へのコミットは原則として求められない。技術力は問われるが、製品ロイヤルティとは別の話だ。

③ 担う工程の範囲

• SIer：要件定義から設計・開発・テスト・納品までを担う。工程の区切りが明確で、納品後は別途保守契約がなければ関与が薄れる。
• SES：特定工程に技術者を配置する。設計だけ、コーディングだけという形もある。工程をまたぐ責任は持ちにくい。
• FDE：導入から現場定着、改善サイクルの継続まで伴走する。工程の「後ろ側」に責任を持つ点がSIer・SESと異なる。

FDEが担うのは「動く」ではなく「定着する」だ。この違いが工程の範囲を決める。

---

同じに見える場面と、差が出る場面

実務上、FDEとSESが区別しにくくなるケースがある。

似て見えるケース

• エンジニアが週3〜5日クライアントのオフィスまたはリモートで常駐している
• 業務システムの設定・データ整備を現場でこなしている
• クライアントのチャットツールに常時参加し、その日の問い合わせに対応している

差が明確になるケース

• クライアントから直接「今日はこの作業をやってほしい」と指示されるか否か（指揮命令）
• 現場で使っているツールが自社製品か、クライアント既存のシステムか（プロダクト）
• 本番稼働後にも改善提案の責任を持つか、納品で関係が一区切りになるか（工程）

SIerとの混同も起きやすい。上流工程を担うSIerは要件定義から関与するため、「現場に入り込んでいる」ように見える。ただしSIerが成果物の納品を終着点とするのに対し、FDEは現場で活用が始まってからが本番という設計になっている。この非対称さが日常業務の見た目には現れにくい。

FDEが実際の現場でどう動くかは、「FDEの仕事内容とは？」で詳しく扱っている。

---

見分けるための3問

FDE・SES・SIerを区別するとき、次の問いを順番に確認するだけで整理できる。

1. エンジニアへの作業指示は誰から出ているか（クライアントか、自社か）
2. 現場に入る目的は特定の自社製品の定着か、汎用的なスキル提供か
3. 現場が「動く」状態になった後も関与が続くか、工程で区切られているか

3問すべてに答えられれば、見た目が似ていても構造の違いが整理できる。「リブランディングかどうか」を疑う前に、まずこの3点を確かめることが実務的な判断の出発点になる。

DX伴走の文脈でFDE的な動き方を検討しているなら、しぼる：DX伴走支援の考え方も参考にしてほしい。