FDEとSE・ITコンサル・PMの違いは、担当する工程の範囲と、成果がどこで測られるかにあります。SEは決まった要件をシステムにし、ITコンサルは課題と方針を整理し、PMはプロジェクトを計画どおりに進めます。FDEはこれらの一部ずつを一人または少人数で通して担い、「顧客の業務が実際に良くなったか」で評価される職種です。
4つの職種の役割比較表
まず全体像を表で整理します。会社やプロジェクトによって線引きは変わるので、典型的な分担として読んでください。
| 項目 | FDE | SE | ITコンサル | PM |
|---|---|---|---|---|
| 主な担当工程 | 課題発見から実装・定着まで | 要件定義〜設計・実装・テスト | 現状分析・課題整理・方針策定 | 計画・進捗・課題・関係者の管理 |
| 起点 | 顧客の業務の現場 | 要件や仕様 | 経営や事業の課題 | プロジェクトの目標と計画 |
| 主な成果物 | 動く仕組みと定着した運用 | 設計書・システム | 提案書・報告書・ロードマップ | 計画書・進捗報告・課題ログ |
| 成果の測られ方 | 業務が良くなったか | 仕様どおりに動くか | 方針が採用され成果につながるか | 期限・予算・品質を守れたか |
| 自分で実装するか | する | する | 通常はしない | 通常はしない |
| 顧客の現場との距離 | 最も近い | 窓口経由が多い | 経営層・管理職が中心 | 関係者全体 |
FDEとSEの一番の違いは、要件を受け取るか見つけに行くか
SEとFDEはどちらも実装をする職種なので、違いがわかりにくいかもしれません。一番大きな違いは要件の出どころです。
SEの仕事は、多くの場合「この機能を作ってほしい」という要件を受け取るところから始まります。要件の妥当性を確認することはあっても、要件そのものを一から探しに行くことは少ないはずです。
FDEは要件がまだない段階から関わります。たとえば「見積もり業務が遅い」という相談があったとき、SEなら「見積書の作成画面を作る」という要件を待ちますが、FDEは次のように進めます。
- 見積もり業務の現状の流れを、担当者に聞きながら図にする
- 時間がかかっている場所を特定する（例：過去の類似案件を探す作業に毎回30分かけている）
- 原因を確かめる（例：過去の見積書がファイルサーバーにばらばらに保存され、検索できない）
- 解決策を決める（例：過去見積もりの検索を先に作り、作成画面は後回しにする）
このように、FDEは「何を作るか」の判断まで自分で担います。結果として、最初に想定された機能とは違うものを作ることも珍しくありません。現状の流れを図にする方法はASIS業務フロー、ヒアリングの進め方はプロジェクトスタート時のヒアリングで詳しく扱っています。
FDEとITコンサルの違いは、自分で作って定着させるかどうか
ITコンサルタントも業務の課題を整理し、解決の方針を示す職種です。課題発見の部分はFDEと重なります。
違いは、方針を示したあとに自分で作るかどうかです。ITコンサルは提案書やロードマップを成果物とし、実装はベンダーや社内の開発チームに引き継ぐのが一般的です。FDEは整理した課題を自分で実装し、現場で使われる状態まで持っていきます。
この違いは、提案の粒度に影響します。たとえば検品業務の改善で、ITコンサルが「検品データをデジタル化し、出荷判定を自動化する」という方針を出したとします。FDEはこれを実装する立場なので、次のような細部まで詰める必要があります。
- 検品の結果は「合格・不合格・保留」の3状態で足りるか
- 保留になった品物は、誰がいつまでに判定するか
- 判定前に出荷指示が出てしまった場合、どう止めるか
こうした業務の「状態」の設計は、方針レベルの資料には出てこないことが多い部分です。考え方はステータス管理とテーブル分割が参考になります。
FDEとPMの違いは、管理する対象が人と計画か業務と仕組みか
PMはプロジェクトを期限・予算・品質の範囲で進める責任を持ちます。WBS（作業の分解と計画）、課題ログ、関係者の調整、定例会議の運営が主な仕事です。
FDEも小さなプロジェクトでは、こうした管理を自分で行います。ただし、PMが「計画どおりに進んでいるか」を管理するのに対し、FDEの関心は「業務と仕組みが噛み合っているか」にあります。両方を一人で担う場面では、次のように役割が混ざります。
- 週次の定例で進捗を報告する（PMとしての仕事）
- 定例の場で、現場の担当者に試作画面を触ってもらい意見を集める（FDEとしての仕事）
- 出てきた要望を、今回の範囲に入れるか次回に回すかを決める（両方）
小規模なプロジェクトの進め方はプロジェクト管理に、WBS・課題ログ・定例報告の具体的な型がまとまっています。
4つの職種が一緒に働く場面
実際の現場では、4つの職種が分かれて存在することも、一人が複数を兼ねることもあります。
- 大規模な基幹システム刷新：ITコンサルが方針を作り、PMが全体を管理し、多数のSEが実装する。FDEがいる場合は、特定の業務領域に入り込んで現場との橋渡しをする
- 中小企業の業務改善：FDE一人、または2〜3人の小さなチームが、課題整理から実装・定着まで担当する。PMの役割もFDEが兼ねる
- 生成AIの業務導入：AIで何ができるかを顧客が判断しきれないため、試作を見せながら要件を固める進め方が多い。実装できる人が要件定義に入るFDEの形と相性がよい
どの職種からFDEを目指しやすいか
どの職種からでもFDEを目指せますが、足りないものはそれぞれ違います。
| 今の職種 | すでに持っているもの | 補う必要があるもの |
|---|---|---|
| SE・実装エンジニア | 実装力、システムの構造の理解 | 課題発見、ヒアリング、要件を決める経験 |
| ITコンサル | 課題整理、提案、顧客折衝 | 自分で作る力、定着までの細部の設計 |
| PM | 計画と調整、関係者の管理 | 業務の深い理解、実装 |
実装エンジニアの場合、足りないのは表の右側にある「上流」の工程です。どう補っていくかは実装エンジニアからFDEになるキャリアパスで説明しています。FDEそのものの説明はFDEとは？を参照してください。
この記事のまとめ
- SEは要件を受け取って作る、FDEは要件を見つけに行くところから関わる
- ITコンサルは方針を示して引き継ぐ、FDEは自分で作って定着させる
- PMは計画と人を管理する、FDEは業務と仕組みが噛み合っているかを見る
- 小規模な案件や生成AIの導入では、FDEが複数の役割を兼ねることが多い
- 実装エンジニアがFDEを目指す場合、補うべきは課題発見と要件を決める経験
FDE Guildでは、FDEに必要な工程を「業務を読む」から「現場に出る」までの7ステップに分けたロードマップを公開しています。SEとの違いがはっきり出るのはステップ2「聞く」とステップ5「決める」なので、ここから読んでみるのもよいと思います。