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は基本的に自社プロダクトという再利用可能な資産の上に立ち、顧客ごとの差分だけを作る。だからこそ一人あたりの担当領域が広く、意思決定の速度が求められる。

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

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

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

一方で、元請け・下請けという多重構造と人月ベースの見積りが、変化への追随を難しくする側面もある。要件が確定していることを前提にした工程設計は、要件そのものが探索対象である案件と相性が悪い。

両者の分岐点は「誰が課題を定義するか」

分岐点は課題定義の主体で、SIerは顧客が定義し、FDEはエンジニア自身が現場で定義する点にある。

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

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

契約面の違いは、FDEがプロダクト利用料を軸にし、SIerが工数と納品物を軸にする点にある。

この差は営業手法の違いにとどまらない。「エンジニアが何をすると儲かるか」というインセンティブ構造そのものが変わるため、日々の判断基準が変わる。

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

FDEはサブスクリプション＋導入支援が中心で、SIerは請負契約または準委任契約が中心となる。

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

スコープ管理の思想はどう違うのか？

FDEはスコープを絞って早く価値を出し、SIerはスコープを固定して逸脱を防ぐという逆向きの思想を取る。

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

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

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

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

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

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

具体的には次の4層で捉えると整理しやすい。

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

この4層のうち、SIerのキャリアで最も鍛えられていないのは4層目であることが多い。技術力ではなく、「使われるまで粘る」ことを自分の職務範囲だと考えられるかが分かれ目になる。

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

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

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

FDEは顧客の利用状況で評価され、SIerは納期・品質・予算の達成度で評価される点が異なる。

FDEの一日は、午前に顧客の現場に入り、午後に見たことをそのまま実装し、翌週にはユーザーに触ってもらう、といった往復になりやすい。逆に言えば、まとまった実装時間を確保しにくく、コードの美しさだけを追求する働き方とは相性が悪い。技術的な深掘りを職業的アイデンティティにしている人にとっては、ここが最大のギャップになりうる。

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

転職に必要なのは、課題を自分で定義し実装まで運んだ経験を、具体的に語れる状態にすることである。

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

面接では技術スタックの一致より、顧客の業務を変えた実体験の解像度が重視される傾向が強い。

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

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

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

転職前に埋めておくべきギャップは何か？

埋めるべきギャップは、実装から離れた期間の技術的な手触りと、成果を数値で語る習慣である。

• 手を動かす感覚を戻す：設計・管理中心だった場合、SQL、API連携、簡単なフロント実装まで自力で完結できる状態にしておく。業務データを扱うためデータ処理の基礎は特に重要になる。
• 成果を指標で語れるようにする：処理時間、対応件数、エラー率など、担当システムが業務のどの数字に効いたかを棚卸ししておく。守秘義務の範囲で、粒度を落として語れる形にしておくとよい。
• プロダクト思考に慣れる：個別最適の作り込みではなく、「他の顧客にも共通する部分はどこか」を考える習慣を付ける。FDEの実装は、しばしばプロダクト本体への機能提案につながる。

移行の実務ステップはどう組むべきか？

現職にいる間に社内で疑似FDE的な動き方を実践し、その実績を持って移るのが現実的な順序である。

いきなり転職するより、次の順で進めるほうが再現性が高い。第一に、現職で顧客の現場に足を運ぶ機会を意図的に増やす。第二に、正式な要件になっていない小さな改善を、自分で提案して実装まで持っていく。第三に、その一件を「課題→仮説→実装→結果」の形で書き起こす。この一件があるかどうかで、職務経歴書の説得力はかなり変わる。

なお、FDE的な職種は求人票の名称が統一されていない。「ソリューションアーキテクト」「導入エンジニア」「カスタマーエンジニア」などの名称でも、実質がFDEである場合がある。逆にFDEを名乗っていても、実態が常駐受託に近いこともあるため、面接では「誰が課題を定義するのか」「自社プロダクトはあるのか」を必ず確認したい。

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

使い分けの基準は、課題が既に定義済みか、探索から始める必要があるかという一点にある。

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

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

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

併用の要点は、探索フェーズをFDEに、確立した業務の本番運用をSIerに任せる分担である。

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

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

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

発注側が確認すべきチェックポイントは何か？

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

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

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

姉妹メディアの関連記事