FDEとSIerの違いとは？契約・スキル・転職と使い分けを実務比較

FDEとSIerの違いは、そもそも何が本質なのか？

FDEとSIerの本質的な違いは、成果物が仕様どおりのシステムか、顧客業務で出た成果かにある。

FDE（Forward Deployed Engineer）とSIer（システムインテグレーター）は、どちらも「顧客企業のためにソフトウェアを届ける」仕事に見える。ただ、価値の置き所が違う。SIerは合意した要件を満たすことが価値になり、FDEは顧客の業務指標が動くことが価値になる。後で扱う契約・スキル・評価の差は、すべてこの一点から生まれている。

FDE（Forward Deployed Engineer）とはどんな職種か？

FDEはPalantirが定義した職種で、顧客の現場で課題定義から実装・定着までを一人で通して担う。

Palantirは、自社プロダクトのGothamやFoundryを導入するとき、製品を売って終わりにしない。エンジニアを顧客の現場に「前方展開（forward deploy）」させる体制を取ってきた。FDEは顧客のオペレーションを観察し、データモデルを設計し、自社プロダクトの上にワークフローを組み上げる。日本でも近年、SaaS企業やAI企業が同じような役割を「FDE」「ソリューションエンジニア」「導入エンジニア」といった名前で置き始めている。

注意したいのは、FDEが「受託開発者の常駐版」ではない点だ。FDEは基本的に、自社プロダクトという再利用できる資産の上で、顧客ごとの差分だけを作る。そのためFDE一人が受け持つ領域は広く、意思決定にも速さが求められる。

SIer（システムインテグレーター）の役割はどう定義されるか？

SIerは、要件定義から設計・開発・運用までを契約に基づいて請け負い、システムを納品する事業者である。

日本のSIerは、顧客の情報システム部門の外部委託先として発展してきた。SIerの強みは、大規模・長期・高信頼性が求められる領域での工程管理と、ドキュメントで説明責任を果たせることにある。金融の勘定系や公共システムのように「止まらないこと」「監査に耐えること」が最優先の領域では、今もSIerの体制が合理的だ。

一方で、元請け・下請けの多重構造と人月ベースの見積りは、変化への追従を難しくする面もある。要件が確定していることを前提に組んだ工程は、要件そのものを探す案件とは相性が悪い。これはSIerの能力の問題ではなく、契約と工程が求める振る舞いの問題だと捉えるほうが正確だ。

FDEとSIerの分岐点はどこにあるのか？

分かれ目は「誰が課題を定義するか」だ。SIerでは顧客が定義し、FDEではエンジニア自身が現場で定義する。

現場の実務者として一番効いてくると感じるのは、表の最下段だ。SIerの現場にも「納品したのに使われない」という悔しさはあるはずだ。FDEは、その悔しさを構造ごとなくそうとして設計された職種だと捉えると理解しやすい。

FDEとSIerで契約と収益モデルはどう違うのか？

FDEの契約はプロダクト利用料が軸で、SIerの契約は工数と納品物が軸になる。ここが最大の違いだ。

これは営業手法だけの違いではない。「エンジニアが何をすれば利益が出るか」というインセンティブの構造が変わるため、FDEとSIerでは日々の判断基準まで変わってくる。

FDEとSIerで契約形態と請求の仕組みはどう違うのか？

FDEはプロダクト利用料と導入支援費が中心で、SIerは請負契約か準委任契約が中心になる。

FDEにとっては、契約更新が実質的な通信簿になる。「作ったかどうか」ではなく、「翌年もお金を払う価値があると顧客が判断したか」で評価される。稼働時間を積み上げても成果にはならない。反対にSIerでは稼働時間がそのまま売上になるため、少人数で短く終わらせる工夫が報われるとは限らない。

FDEとSIerでスコープ管理の思想はどう違うのか？

FDEはスコープを絞って早く価値を出し、SIerはスコープを固定して逸脱を防ぐ。考え方が逆向きだ。

SIerの請負契約では、スコープの曖昧さがそのまま赤字リスクになる。だから要件を凍結し、変更管理プロセスで統制するのがSIerとして正しい振る舞いだ。一方FDEは、最初から全体を作らない。まず一つの業務、一つの画面、一つの意思決定に絞って動くものを出し、そこで得た学びをもとに次の範囲を決める。

この違いを理解しないまま人だけを移すと、事故が起きやすいという印象がある。FDEの現場に「仕様が固まっていないので着手できない」という規律を持ち込めば、仕事が止まる。SIerの現場に「まず作って見せる」を持ち込めば、契約違反になりかねない。どちらが優れているかではなく、契約が求める振る舞いが違うと理解することが出発点になる。

インセンティブ構造はFDEとSIerの日々の判断をどう変えるのか？

FDEは利用定着が収益源なので撤退の判断が早い。SIerは稼働が売上なので完遂が優先されやすい。

「この機能は使われていない」という同じ事実を前にしても、判断は分かれる。FDEなら、作るのをやめて別の業務に移る判断が正当化される。契約更新の材料にならない実装に時間を使えば、それがそのまま損失になるからだ。SIerでは、合意済みのスコープを途中でやめるには契約変更が必要になるため、まず完遂してから次の提案に回すのが合理的になる。

これは技術者個人の姿勢の差ではない。収益モデルが日々の意思決定を形づくっていると見るべきだ。

FDEとSIerで求められるスキルと働き方はどう違うのか？

FDEには業務理解と実装を一人で往復する幅が、SIerには工程内の深さと管理能力が求められる。

スキルの差は「どちらが高度か」ではなく、「どの範囲を一人で持つか」の差だ。以下では、FDEのスキル構成、SIer出身者の強みがどこまで通用するか、評価指標の違いを順に整理する。

FDEに求められるスキルセットは何か？

FDEに必要なのは、業務ヒアリング、データモデリング、実装、そして定着支援までやり切る推進力である。

FDEのスキルは、次の4層で捉えると整理しやすい。

1. 業務理解：顧客のオペレーションを現場で観察し、誰がどのタイミングで何を判断しているかを言葉にする。
2. データモデリング：散らばった台帳・基幹システム・センサーデータなどを、意思決定に使える形に構造化する。
3. 実装：自社プロダクトの設定・拡張・API連携・フロントの作り込みまで、必要な範囲を自力で行う。
4. 定着：現場のユーザーに使ってもらって運用に乗せ、効果を見える形にして契約更新につなげる。

この4層のうち、SIerのキャリアで最も鍛えられていないのは、たいてい4層目の「定着」だ。分かれ目になるのは技術力ではない。「使われるまで粘る」ことを自分の仕事の範囲だと考えられるかどうかだ。

SIer出身者のスキルは、FDEでどこまで通用するのか？

SIerで培った要件整理、品質管理、ステークホルダー調整は、FDEでも高く評価される強みになる。

表の上半分は、そのままFDEに持ち込める資産だ。下半分は捨てるものではなく、使う場面が変わるものと考えたほうがよい。たとえばドキュメントは不要にはならない。ただし分厚い設計書ではなく、次の担当者と現場が読む短い引き継ぎ資料に形を変える。

FDEとSIerで働き方と評価指標はどう違うのか？

FDEは顧客の利用状況で評価され、SIerは納期・品質・予算をどれだけ達成したかで評価される。

FDEの一日は、往復の繰り返しになりやすい。午前に顧客の現場に入り、午後に見たことをそのまま実装し、翌週にはユーザーに触ってもらう。その分まとまった実装時間は取りにくい。技術の深掘りを職業的なアイデンティティにしている人にとっては、ここがFDEとの最大のギャップになりうる。

SIerからFDEへ転職するには何が必要か？

課題を自分で定義し、実装まで運んだ経験を、具体的に語れる状態にしておくことが転職には欠かせない。

必要なのは資格や特定の技術スタックよりも、FDEの働き方を一度でも実践した証拠だ。面接の評価軸、埋めるべきギャップ、移行の順序、求人の見極め方の4点で整理する。

FDEの面接で見られるポイントはどこか？

FDEの面接では、技術スタックの一致より、顧客業務を変えた実体験を具体的に語れるかが重視されやすい。

FDEの採用側が知りたいことは、おおむね次の3点に集約される。

1. 課題定義の経験：与えられた要件ではなく、自分が現場で見つけた問題を説明できるか。
2. 一気通貫の経験：ヒアリングから実装、リリース、利用状況の確認まで、どこまで自分の手で行ったか。
3. 撤退・修正の判断：うまくいかなかったとき、何を根拠にどう方向転換したか。

SIerで「規模の大きさ」を語る癖が付いていると、話が噛み合わないことがある。FDEの面接では評価が逆転しやすく、100人規模のプロジェクトでサブシステムを担当した話より、5人で顧客の1業務を変えた話のほうが評価されやすい。

SIerからFDEへの転職前に埋めておくべきギャップは何か？

埋めるべきギャップは主に二つある。実装から離れていた間に鈍った技術の手触りと、成果を数値で語る習慣だ。

成果の棚卸しは、守秘義務の範囲内で粒度を落とし、語れる形にしておくとよい。設計や管理が中心だった人ほど、実装の手触りを先に取り戻しておくと面接での説得力が変わる。

SIerからFDEへの移行ステップはどう組むべきか？

現実的なのは、SIerにいる間にFDEに近い動き方を実践し、その実績を持って移る順序だ。

いきなり転職するより、次の順で進めるほうが再現性は高い。

1. 現職で、顧客の現場に足を運ぶ機会を意図的に増やす。
2. 正式な要件になっていない小さな改善を、自分で提案して実装まで持っていく。
3. その一件を「課題→仮説→実装→結果」の形で書き起こす。

この一件があるかどうかで、職務経歴書の説得力はかなり変わる。面接の3つの観点（課題定義・一気通貫・撤退判断）に、そのまま答える材料になるからだ。

FDE求人票の実態はどう見極めるのか？

FDE求人は名称が統一されていない。課題を誰が定義するかと、自社プロダクトがあるかで実態を見極める。

FDE的な職種は、「ソリューションアーキテクト」「導入エンジニア」「カスタマーエンジニア」などの名称でも、中身がFDEであることがある。逆に、FDEを名乗っていても実態は常駐の受託開発に近い場合もある。面接では「誰が課題を定義するのか」「自社プロダクトはあるのか」を必ず確認したい。この二つが曖昧なまま入社すると、想定していた働き方と現実が大きくずれる。

企業はFDEとSIerをどう使い分けるべきか？

使い分けの基準は一つだ。課題がすでに定義されているか、探すところから始める必要があるかである。

FDEとSIerは競合ではなく、案件のフェーズによって適材が変わる関係にある。案件の性質別の向き不向き、併用時の分担、契約前の確認事項を順に見ていく。

どの案件にFDE型が向き、どの案件にSIer型が向くのか？

要件が固まっていて大規模・高信頼性が必要ならSIer型、要件を探している段階ならFDE型が合う。

表の6行を一つの問いに戻すと、課題が仕様として書けるならSIer型、書けないならFDE型になる。

FDEとSIerを併用する場合、どう役割を分けるべきか？

併用するなら、探索フェーズをFDEに、確立した業務の本番運用をSIerに任せる分担が要になる。

実際の企業では、FDEかSIerかの二者択一より併用のほうが多い。まずFDEが現場に入って業務の仮説を検証し、「これは全社に効く」とわかったものだけを、SIerや社内の情報システム部門が安定運用に載せる。この分担が機能すれば、探索の速さと運用の堅牢さを両立できる。

失敗しやすいのは、探索フェーズにSIer型の契約と工程を当てはめてしまうケースだ。要件定義書を作るだけで半年が過ぎ、書き上がる頃には前提が変わっている、という展開になりやすい。逆に、全社の基幹にあたる領域をFDE的な少人数体制のまま走らせると、属人化と運用破綻のリスクが高まる。

VACANのように現場のリアルタイムデータを扱う事業会社から見ると、現場で起きていることとシステムが前提とする業務フローのズレは、常に生まれている。そのズレを最初に見つけるのは、ドキュメントではなく現場に立っている人間だ。FDEという職種の存在意義は、ズレを見つけた人がそのまま直せる権限と技術を持っている点にある。体制を設計するうえでは、これが契約形態以上に重要な論点だと考えている。

発注側がFDEとSIerの契約前に確認すべきチェックポイントは何か？

発注側は契約前に、「誰が課題を定義するか」と「成果をどう測るか」を合意しておく必要がある。

• 課題定義を発注側が行うのか、受け手側に委ねるのかを明示する
• 成功指標を、納品物ではなく業務指標で置けるかを検討する
• 最初のスコープを、数か月以内に効果が見える範囲まで絞る
• 検証後に本番運用へ移す際の体制と引き継ぎ方法を先に決めておく
• 現場のキーパーソンが議論に参加できる時間を確保する

最後の項目は軽く見られがちだが、FDE型の成否を最も左右する。現場が忙しすぎて誰にも観察させてもらえないなら、FDEを呼んでもSIerを呼んでも結果は変わらない。