FDEとSEは何が違うか？常駐エンジニアの新形態を既存職種と比べる

結論：SEが「仕様どおりに作る人」なら、FDEは「仕様自体を現場で作り直しながら実装する人」だ

SEとFDEは、どちらもエンジニアとしてコードを書いてシステムを作る。しかし仕事の起点がまったく違う。SEは要件定義書・仕様書・設計書といったドキュメントを受け取ることから始める。FDEはクライアントの現場に入り、担当者との対話の中から課題を引き出し、実装しながら仕様を確定させていく。

この違いは働き方の細部にとどまらない。アウトプットの定義、クライアントとの関係性、使う技術スタック、評価される指標、すべてが変わる。FDEとはどのような職種かを把握したうえで、SEとの比較を具体的に見ていこう。

---

仕事の起点の違い：要件定義書 vs 現場の対話

SIerを含む従来のSEが従うプロセスは、多くの場合こうなっている。クライアントが要望を出す、SE側が要件を整理してドキュメント化する、クライアントの承認を取る、設計・実装・テスト・納品と進む。各フェーズの完了を確認してから次に進む直列型の流れだ。

FDEの仕事の流れは異なる。現場担当者と話しながら「何が困っているか」を引き出し、その場でプロトタイプを作る。翌日には動くものをデモして、フィードバックをもらいながら機能を絞り込む。仕様書が完成するより前に、動くシステムが存在する状態が目標だ。

この違いが生まれる理由は、「クライアントは最初から正確な要件を言語化できない」という前提の置き方にある。SEモデルは要件が言語化できるという前提でプロセスを組む。FDEモデルは言語化できないものを動くものを通じて引き出すことを前提にする。

どちらが正しいかではなく、解くべき問題の性質によって向き・不向きがある。業務システムの刷新など要件が固まりやすいプロジェクトはSEモデルと相性がいい。AI導入・業務変革・新規プロダクト開発など「何を作るかが曖昧」なプロジェクトはFDEモデルが力を発揮しやすい。

---

アウトプットの定義の違い：納品物 vs 現場で動くもの

SEとFDEは、何を「成果物」と見なすかが違う。

SEの成果物は契約や仕様書に記載されたものだ。設計書・テスト成績書・ソースコード・運用手順書など、あらかじめ定義された一式を期日までに揃えることが仕事になる。「仕様どおりに作った」かどうかが品質の基準になる。

FDEの成果物はビジネス上の変化だ。売上が上がった、業務時間が週に10時間削減された、意思決定サイクルが3日から4時間に短縮された、といった指標で評価される。ドキュメントが揃っているかではなく、クライアントの現場で何かが変わったかが問われる。

この違いは受け取り方だけでなく、日々の判断にも影響する。SEは「仕様にない機能を追加するにはどうするか」という問いに対して、まず変更管理プロセスを動かすことを考える。FDEは「それはビジネス課題の解決に必要か」を最初に判断する。必要なら即実装し、不要なら仕様を絞り込むことを提案する。

---

クライアントとの距離感の違い

SEとFDEでは、クライアントとやり取りする頻度・深さ・関係の性質が変わる。

SEはプロジェクトマネージャーや発注担当者を窓口として、定例会議や進捗報告書を通じてコミュニケーションを取ることが多い。現場の担当業務者と直接話す機会は、要件定義や受け入れテストなど特定のフェーズに限られることが多い。

FDEはクライアントの現場に深く入り込む。プロジェクトマネージャーではなく、実際にシステムを使う担当者・部門長・経営層と直接話す。「この機能で合っていますか」という確認より「今日一番困っていることは何ですか」という問いを日常的に投げかける。情報の受け手ではなく、課題を引き出す側に立つ。

関係性の長さも変わる。SEは案件単位で関係が区切られることが多い。FDEはクライアントに継続的に関与し、1つの機能を使って得られたデータをもとに次の改善を提案するサイクルを繰り返す。FDEとコンサルタントの違いでも述べているように、継続的な現場関与がFDEの特徴の一つだ。

---

使う技術スタックの違い：SIer寄り vs スタートアップ寄り

SIer環境のSEが使う技術は、標準化と保守性を重視したものになりやすい。Javaや.NETなどのエンタープライズ向け言語、オンプレミス環境やプライベートクラウド、数年単位で選定されたフレームワークやミドルウェアが中心だ。個人の技術選定より、チーム全体で維持できる標準化された環境が優先される。

FDEが置かれる環境は異なる。スタートアップ・AIスタートアップ・SaaS企業での採用が多いため、PythonやTypeScript・AWS/GCPのマネージドサービス・LLM API・NoSQLといった、立ち上げが速くて変更しやすい技術を組み合わせることが多い。「この課題を今週中に動くレベルで解決するにはどの技術が最適か」という問いに答えられることが求められる。

とはいえFDEに「これを使え」という技術スタックの定義はない。重要なのは幅広い技術を必要に応じて組み合わせる判断力と、新しいツールへの適応速度だ。FDEに必要なスキルセットではこの点をさらに詳しく掘り下げている。

---

評価軸の違い：工数遵守 vs ビジネス成果

SEが評価される指標は、工数遵守率・品質（バグ発生件数・テストカバレッジ）・納期遵守率などが代表的だ。決められた予算と期間の中でアウトプットを出したかが問われる。これはプロジェクト契約の構造上、合理的な評価軸だ。

FDEの評価軸はビジネス成果に直結する。クライアントの売上・コスト・業務効率・意思決定速度のどれかが改善されたか、という問いへの答えが評価の核心になる。工数を守ったが成果が出なかった場合、FDEとしては失敗に近い。逆に工数を超えても成果が出た場合、評価はむしろ高くなることがある。

この違いは日々の判断に影響する。SEモデルでは工数が足りなくなると「スコープを削る」か「追加費用を請求する」かを選ぶ。FDEモデルでは「この工数でどの課題を解決するのが最もビジネスインパクトが大きいか」を優先順位として考える。リソースの使い方の判断基準が、契約条項からビジネス価値に移行する。

以下に5つの観点をまとめた比較表を示す。

観点	SE（SIer系）	FDE
仕事の起点	要件定義書・仕様書	現場の対話・課題発見
成果物	契約で定義された納品物一式	現場で動くシステム・ビジネスの変化
クライアントとの関係	窓口担当者を経由した定期報告	現場担当者・経営層と直接・継続的に関与
技術スタック	標準化・保守性重視のエンタープライズ技術	課題解決速度優先・クラウド・LLMなど軽量構成
評価軸	工数遵守・品質・納期	ビジネス成果・現場のインパクト

---

SEがFDEに転向するときに変えるべき習慣

SEとしての経験はFDEにも活きる。設計力・コード品質への意識・複雑な要件を整理する力は、FDEでも間違いなく武器になる。問題は技術力ではなく、仕事の進め方に染み込んだ習慣だ。

仕様書が完成するまで動かさない習慣を手放すことが最初の壁だ。FDEは仕様が固まる前に動くプロトタイプを作る。不完全でも動くものをクライアントに見せて、フィードバックをもとに仕様を作っていく。完成度60%のものを見せることへの抵抗感が強い人は、転向直後に苦労しやすい。

工数管理に意識を向けすぎる習慣も変える必要がある。SEは残り工数を常に意識して、オーバーしそうになると上長や顧客に報告するプロセスを踏む。FDEは残り工数より「このリソースで何をやれば最もインパクトが出るか」を優先する。工数管理を捨てるのではなく、優先順位の判断基準をビジネス価値に置き直すということだ。

承認プロセスを待つ習慣を意識的に崩すことも求められる。SEは変更や追加が発生した際に、変更管理フォームや上長承認を経てから動く。FDEの現場では、クライアントの担当者が「それ明日必要です」と言った機能を次の日にデモできることが価値になる。承認を待つより、まず動くものを作ってから承認を取ることの方が成果につながることが多い。

資料作成に時間をかける習慣も見直しが必要だ。SEは要件定義書・基本設計書・詳細設計書・テスト仕様書など、工程ごとにドキュメントを整える。FDEはドキュメントの代わりに動くものを作って認識を合わせる。資料作成に半日使うより、プロトタイプを作ってクライアントに見せる方が認識のズレを早く潰せる。

ただし「ドキュメントは不要」ということではない。FDEでも意思決定の記録や重要な設計判断の記録は残す。時間の使い方として、ドキュメント完成を前提にするか、動くものを前提にするかの違いだ。

FDEに向いている人の特徴では、この転向のしやすさや適性についてさらに詳しく扱っている。SEとしての経験が長い人がFDEに向いているかどうかを判断するための視点も提供している。

---

SEとFDEは対立する職種ではない

SEとFDEは優劣の関係ではない。解くべき問題の性質と、クライアントが求めているものが違う。

要件が明確で規模が大きく、組織として標準化されたシステムを作りたいプロジェクトには、SEモデルの分業・プロセス管理・品質管理が向いている。要件が曖昧で速さが求められ、現場の変化に即応しながらシステムを育てたいプロジェクトには、FDEモデルが有効だ。

AI導入が加速する2026年現在、後者のプロジェクトの割合が増えている。これがFDE的な働き方への需要を押し上げている理由の一つだ。SEのキャリアを持ちながらFDE的な動き方を身につけることは、エンジニアとしての選択肢を広げることになる。

どちらの職種に向いているかを見極めたい人は、実際に小さなFDE的プロジェクトを経験してみることが早い。座学で理解するより、クライアントと向き合いながら仕様のない問題を解く経験が、自分の適性を教えてくれる。