FDEという職種名を目にして、結局は客先常駐やSESと同じものではないかと感じた方は少なくないはずです。実際、FDEもSESも顧客の現場に入って働き、準委任契約で進むことが多いため、契約書や請求書の外形だけを見比べても区別がつきません。しかしFDEとSESの違いは、誰が指揮命令を持つのか、何に対して責任を負うのか、何をもって成果と呼ぶのかという三点にはっきり表れます。この記事では、FDEとSESの違いを3つの軸で整理したうえで、客先常駐や受託開発、従来型ITコンサルまで含めた比較と、発注側がどれを選ぶべきかの判断基準について解説します。

この記事を読むと理解できること

• FDEとSESが混同されやすい構造的な理由

• FDEとSESの違いを整理するための3つの軸

• FDE・SES・客先常駐・受託開発・従来型ITコンサルの一覧比較

• 工数に対する責任と成果に対する責任がどう分かれるのか

• 自社の状況に応じてFDEとSESのどちらを選ぶべきかの判断基準

• FDEを前提にした発注と社内体制のつくり方

• FDEとデータサイエンティスト、FDEとSIerの違い

FDEとSESが混同されるのはなぜか

FDEはForward Deployed Engineerの略で、顧客の現場に前方展開されるエンジニアを指します。顧客のオフィスや業務プロセスの内側に入り、実データと実業務に触れながらソフトウェアをつくる働き方です。この説明だけを聞くと、日本のIT業界に長くいる人ほど、それはSESや客先常駐の言い換えではないかと考えます。

混同が起きるのには理由があります。第一に、FDEもSESも顧客先で作業するという外形が同じです。第二に、契約形態として準委任契約が使われる点も重なります。

第三に、請求の単位が人月や稼働時間で表現されることがあり、見積書を並べただけでは区別できません。つまりFDEとSESの違いは、契約書の表紙ではなく、その中で何を約束しているかという中身に宿っています。

外形が同じでも約束しているものが違う

SESで約束されているのは、一定のスキルを持つ技術者が一定時間稼働することです。稼働そのものが提供物であり、その時間を使って何を成し遂げるかは発注側の計画に委ねられます。

一方でFDEが約束するのは、顧客の業務課題に対して動くソフトウェアが一定のリズムで届き続けることです。何をつくるかの設計判断そのものが提供物に含まれるため、稼働時間は手段であって成果ではありません。この前提の差が、FDEとSESの違いのすべての出発点になります。

日本の商習慣が違いを見えにくくしている

日本のシステム開発は、多重下請けと人月単価の慣行のなかで長く回ってきました。そのため、現場に人が入る形の支援はすべて要員供給として理解されやすい土壌があります。

FDEという言葉が輸入されたとき、この土壌の上に置かれたことで、名前だけ新しい客先常駐という誤解が生まれました。FDEとSESの違いを説明するには、まずこの理解の枠組みを一度外す必要があります。

FDEとSESの違いを整理する3つの軸

FDEとSESの違いは、断片的な特徴の列挙では整理しきれません。ここでは、契約と指揮命令、責任の対象、成果物とゴールの定義という3つの軸で構造的に捉え直します。

軸1 契約と指揮命令はどちらにあるか

第一の軸は、業務上の指示を誰が出すかです。労働者派遣であれば、指揮命令権は発注者側にあることが法律上も明確です。SESは準委任契約であり、形式上の指揮命令権は受託側に残ります。

しかし実務では、顧客の担当者が日々のタスクを直接指示し、受託側の管理者が形骸化している現場が珍しくありません。これが偽装請負のリスクとして長く議論されてきた論点です。

FDEの場合、指揮命令は受託側が明確に保持します。ただし顧客と切り離されるわけではなく、何を優先するかというバックログの順位付けを顧客と共同で運営し、どう実装するかの判断は受託側が担うという分担になります。この共同運営という形が、FDEとSESの違いを契約面で最も実感しやすい部分です。

軸2 責任の対象は工数か成果か

第二の軸は、何に対して責任を負うかです。SESが負うのは善管注意義務のもとでの労働提供であり、責任の終点は稼働を提供したところにあります。成果が出なかった場合の第一義的な責任は、要員の使い方を設計した発注側に戻ります。

FDEが負うのは、顧客の業務上の成果と、その成果が現場に定着することです。つくったものが使われずに終わったなら、それはFDEの仕事が完了していないことを意味します。

つまり同じ準委任契約でも、SESは投入の責任、FDEは結果の責任という差があります。FDEとSESの違いを一言で説明するなら、この工数か成果かという対比が最も伝わりやすいでしょう。

軸3 成果物とゴールはどう定義されるか

第三の軸は、ゴールの定義の仕方です。SESでは、ゴールは発注側が決めた仕様や作業範囲として事前に与えられます。受託開発では、ゴールは要件定義書として固定され、それを完成させることが契約上の義務になります。

FDEでは、ゴールそのものを顧客と一緒に定義するところから仕事が始まります。何が課題なのかが曖昧な状態で現場に入り、プロトタイプや動くソフトウェアを提示しながら、課題の輪郭を具体で確かめていきます。

この、ゴールを決める工程が仕事の内側にあるか外側にあるかという点は、FDEとSESの違いのなかでも特に見落とされやすい部分です。ゴールが未確定な領域こそ、FDEが最も価値を出す場面になります。

FDEとSESと客先常駐と受託開発を一覧で比較する

3つの軸を踏まえて、FDEとSES、客先常駐や派遣、受託開発、従来型ITコンサルの5者を並べて整理します。同じ現場に入る仕事でも、責任の終点がどこにあるかで役割が大きく変わることが分かります。

この表で見ると、FDEとSESの違いは契約形態の欄では現れず、責任の対象と責任の終点の欄で初めて分かれることが読み取れます。逆に言えば、契約書の種類だけで両者を見分けようとすると必ず失敗します。

比較表の右側に並ぶ受託開発と従来型ITコンサルは、責任の終点が納品や提言で切れる点が共通しています。FDEはこの切れ目をまたいで、使われる状態になるところまでを一つの責任として引き受ける役割だと整理できます。

FDEとSESの違いは評価指標と働き方に表れる

契約や責任の話は抽象的になりがちですが、FDEとSESの違いは日々の仕事の進め方と評価のされ方に具体的に現れます。ここを見れば、名前だけFDEを名乗っている支援かどうかも判断できます。

評価されるのは稼働率か、届いたソフトウェアか

SESの現場では、稼働率と要員数が事業の主要な指標です。誰が何時間入っているかが管理の中心にあり、月末の作業報告書が成果の証明になります。

FDEの現場では、週単位で動くものが顧客に届いているかが問われます。今週何が動くようになったのかを実際の画面やデータで示し、それを見た顧客の反応を次の週の計画に反映させます。この反復のリズムがあるかどうかは、FDEとSESの違いを外から確認する際の分かりやすい目印です。

常駐しているかどうかは本質ではない

FDEは現場に入る働き方ですが、物理的に顧客のオフィスに座り続けることが要件ではありません。重要なのは、顧客の業務データと意思決定の場に近い位置にいることです。

リモートであっても、顧客の優先順位の議論に加わり、実データに触れて開発できるなら、FDEの条件は満たされます。逆に毎日同じ席に座っていても、与えられたチケットを消化するだけなら、それは客先常駐の域を出ません。常駐という形式でFDEとSESの違いを判断しないことが大切です。

知見が誰の資産として残るか

FDEのもう一つの特徴は、現場で得た知見が支援側の資産として蓄積される点です。個別企業の課題を解くなかで見つかった型やコンポーネントが、次の顧客への提案や自社プロダクトの改善に還元されていきます。

SESでは、技術者が現場を離れた時点で、その現場固有の知見はほとんど残りません。この蓄積の有無は、支援を続けるほど価値が上がるか、同じ水準の労働を提供し続けるかという差になって現れます。FDEの役割全体を体系的に押さえたい場合は、FDEとは何かを解説した記事も併せて参考にしてください。

FDEと受託開発の違いはどこにあるか

FDEとSESの違いと並んでよく問われるのが、受託開発との違いです。どちらも成果物をつくる点は同じですが、契約上の義務とプロセスの設計思想が異なります。

完成義務があるかないか

受託開発は請負契約が基本で、あらかじめ合意した仕様のものを完成させる義務を負います。仕様が固まっていることが前提であり、途中で目的が変わると変更管理と追加見積の手続きが発生します。

FDEは準委任が基本で、完成義務そのものは負いません。その代わり、何をつくるべきかを顧客と探索しながら決めていく責任を負います。つくるものが決まっているなら受託開発、つくるものを決めるところからならFDEという整理が実務的です。

要件が固まっていない領域に強いのがFDE

AI活用や業務プロセスの再設計のように、やってみないと正解が見えない領域では、要件定義書を先に完成させること自体が困難です。こうした領域で請負契約を結ぶと、曖昧な要件を無理に固定した結果、使われないシステムが納品されることになります。

FDEはこの問題に対して、プロトタイプを議論の道具として使うアプローチを取ります。抽象的な要望を具体の画面や挙動に落として見せ、その反応から本当の要件を引き出していくやり方です。PoCが実運用に進まない構造的な理由については、AIのPoCが失敗する理由をまとめた記事で詳しく整理しています。

自社の状況からFDEとSESのどちらを選ぶべきか

ここまでの整理を、発注側の判断基準に変換します。FDEとSESのどちらが優れているという話ではなく、自社の状況に対してどちらが噛み合うかという問題です。

SESが適しているのはこういう状況

やるべきことが明確に定義でき、社内に設計と進行を担うマネージャーがいる場合は、SESが合理的です。既存システムの保守運用や、仕様が確定した機能追加のように、必要なのは手数であって意思決定ではないケースが該当します。

社内にプロダクトオーナーが存在し、タスクを切り出して優先順位を管理できる体制があるなら、要員を柔軟に増減できるSESの機動力は大きな利点になります。この状況でFDEを選ぶと、支援側に委ねる判断が少なく、コストに対する価値を感じにくくなります。

FDEが適しているのはこういう状況

課題は感じているが要件に落とせない、現場の業務を知る人と技術を知る人が分断されている、PoCは作ったが運用に乗らないという状況では、FDEが適しています。必要なのは手数ではなく、課題定義から実装、定着までを貫く一本の責任だからです。

また、AIを業務に組み込みたいが何から手を付けるべきか分からないという相談も、FDEの典型的な入口です。技術的に何ができるかと、業務上何をすべきかを同時に判断できる人材が現場に必要になります。

判断に迷ったときの三つの問い

選択に迷う場合は、次の三つを自問すると整理しやすくなります。第一に、つくるべきものの仕様を自社で書き切れるか。第二に、進行と優先順位付けを担える人が社内にいるか。

第三に、納品されて終わりではなく、現場で使われる状態まで誰が責任を持つのかが決まっているか。一つでも空欄が残るなら、工数を買うSESではなく、成果と定着に責任を持つFDEを検討する価値があります。支援会社の比較観点については、FDEコンサルと支援会社の選び方を解説した記事が具体的です。

FDEとSESの違いを踏まえた発注と体制のつくり方

FDEとSESの違いを理解したうえで、実際に発注する際に押さえるべき点を整理します。契約形態を変えるだけでは、これまでと同じ客先常駐の関係に戻ってしまいます。

稼働時間ではなく届くものを合意する

FDE型の支援を成立させるには、契約時点の合意内容を稼働時間から届くものへ移す必要があります。何人が何時間という取り決めだけでなく、どのくらいの頻度で何が顧客に届くのかを明文化します。

週次で動くものを確認する場を定例として設計し、そこで見たものをもとに次の優先順位を決める運びにします。この場が形骸化すると、FDEとSESの違いは契約書の文言だけのものになってしまいます。

実データと実環境へのアクセスを先に整える

FDEが価値を出せるかどうかは、実際の業務データと実運用に近い環境に触れられるかで大きく変わります。サンプルデータと切り離されたサンドボックスだけでは、現場で使えるものはつくれません。

そのため、アクセス権限の整備や情報セキュリティ上の確認は、支援の開始前に済ませておくことが望ましいです。ここが遅れると、最初の数週間が待ち時間になり、FDE型の反復のリズムが立ち上がりません。

支援が終わったあとを設計に含める

FDEの仕事の終着点は、支援側がいなくても改善が回り続ける状態をつくることです。良い支援ほど、自らを不要にしていく方向に働きます。

そのため発注の段階から、誰が引き継ぐのか、社内のどのチームが運用と改善を担うのかを決めておく必要があります。社内側の人材をどう育てるかという論点は、FDE人材の育て方を整理した記事で扱っています。

外部に任せる範囲と内製する範囲を分ける

すべてを外部に任せると、支援終了とともに改善が止まります。逆にすべてを内製しようとすると、立ち上がりに時間がかかりすぎます。

現実的には、立ち上げと型づくりをFDEに任せ、運用と横展開を社内が担うという分担が機能しやすい形です。この分担を最初に描いておくことが、FDEとSESの違いを投資対効果の差として実感できるかどうかを左右します。

まとめ

FDEとSESの違いは、顧客先で働くという外形や準委任という契約形態では判別できません。違いが現れるのは、指揮命令を誰が持ちどう運営するか、工数と成果のどちらに責任を負うか、ゴールを誰がいつ定義するかという3つの軸です。

この3軸で見ると、SESと客先常駐は責任の終点が労働提供にあり、受託開発は納品、従来型ITコンサルは提言で終わります。FDEはその先の、現場で使われ定着するところまでを一続きの責任として引き受ける役割です。

発注側の判断としては、仕様を書き切れて進行も社内で担えるならSES、課題定義から任せたいならFDEという切り分けが実務的です。特にAI活用のように正解が事前に見えない領域では、FDEの探索しながらつくる進め方が噛み合います。

FDEを検討する段階に入ったら、次は支援会社ごとの考え方や体制の違いを比較する作業になります。比較の観点はFDEコンサルの選び方をまとめた記事に整理してあるので、発注準備の材料として活用してください。

FDEとSESの違いに関するよくある質問

Q. FDEとDSの違いは何ですか

DSはデータサイエンティストを指し、データの分析やモデル構築を通じて示唆や予測精度を高めることを主な役割とします。成果物は分析結果やモデルであり、それを業務システムに組み込む工程は別の担当に渡されることが一般的です。

FDEは、そのモデルや示唆を現場で動くソフトウェアとして実装し、業務プロセスに定着させるところまでを担います。分析の深さを追うのがDS、現場で使われる状態をつくるのがFDEという役割分担で捉えると整理しやすくなります。

Q. FDEとSIerの違いは何ですか

SIerは要件定義から開発、保守までを請負中心で一括して引き受ける事業者を指します。仕様を固めて完成させることに強みがあり、大規模かつ要件が明確な案件に適した進め方です。

FDEは、要件が固まっていない段階から顧客と一緒にゴールを定義し、動くものを見せながら課題を具体化していきます。仕様を確定させてから作るのがSIer、作りながら仕様を確かめるのがFDEという違いがあります。

Q. FDE SES 違いという観点で最初に確認すべき点はどこですか

最初に確認すべきなのは、提案されている支援が何を成果として約束しているかです。稼働人数と稼働時間だけが書かれた提案であれば、名称にかかわらず実態はSESに近いと判断できます。

次に、週次などの短い周期で動くものを確認する場が設計されているかを見ます。この二点を押さえれば、FDE SES 違いの判別は契約書の表題に頼らずに行えます。

Q. FDEとSESを併用することはできますか

併用は可能で、実際に相性の良い組み合わせです。立ち上げやAI活用のように不確実性が高い部分をFDEに任せ、仕様が固まった保守運用や定型的な開発をSESで回すという分け方が機能します。

その際に重要なのは、どちらの領域がどちらの責任範囲かを明確にしておくことです。境界が曖昧なままだと、成果の責任が宙に浮き、結果としてどちらの良さも活かせなくなります。