FDEとは？ 現場に入り、業務改善を「提案」で終わらせないエンジニア

FDEとは、現場で「使えるところ」まで作るエンジニア

FDEは、Forward Deployed Engineer（フォワード・デプロイド・エンジニア）の略です。直訳すると「前線に配置されたエンジニア」。開発会社の中で仕様書を待つのではなく、顧客の現場に入り、まだ言葉になっていない問題を見つけ、試作し、実装し、仕事の流れとして定着するところまで関わります。専門用語なので、この記事で覚える必要はありません。一言でいえば、相談と開発のあいだに残っていた距離を埋める人です。

この役割を広めた企業としてよく知られているのがPalantirです。現在はOpenAIやAWSなどもFDEの採用を進めています。AWSの発表では、顧客の実際の制約のなかで一緒に開発し、支援が終わった後は顧客が自分たちで回せる状態を目指す、と説明されています。

「何か効率が悪い。でも、何をどう頼めばよいか分からない」。そんな曖昧な状態から仕事を始められることが、FDEの特徴です。

システムを入れた後にも、作業は残る

新しいツールやSaaSを導入したのに、仕事は十分に軽くなっていない。よくある状態です。

システムに入力した情報を、別のExcelにも写す。CSVを書き出して、毎月同じ形に整える。紙の依頼書を見ながら台帳へ入力する。問い合わせのたびに、詳しい担当者を探す。報告書の数字は集計できても、説明文は毎回ゼロから書く。

どれも、一つだけ見れば小さな作業です。けれど、10分の作業が1日20回あれば200分になります。複数の人が同じ確認をしていれば、会社全体ではさらに大きな時間です。

ここで大事なのは、「人件費削減」をすぐ人減らしに置き換えないことです。先に減らしたいのは、残業、二重入力、差し戻し、確認待ち、担当者探し、担当者が本来の仕事に使えていない時間です。採用が難しいなら、今いる人が無理なく仕事を続けられる余白を作ることにも意味があります。

FDEは、実際にどのような流れで業務改善を進めるのか

業務改善と聞くと、最初にツールや製品を選ぶ姿が浮かぶかもしれません。実際には、道具を選ぶのは少し後です。先に見るのは、人、情報、判断、例外がどの順番で動いているかです。

1. 01経営上の困りごとを聞く。残業を減らしたいのか、採用難を補いたいのか、入力ミスを減らしたいのか、締めを早くしたいのか。解決したい問題を先にはっきりさせる。
2. 02担当者に、普段どおりの仕事を見せてもらう。マニュアルに書かれていないメモ、その人しか知らないExcel、月末だけ起きる例外、確認の電話。こうした「書かれていない手順」を見つける。
3. 03いまの業務の流れを図にする。誰が、何を受け取り、どこへ入力し、誰が確認するか。差し戻しや例外も含めて描く。
4. 04件数、時間、ミス、待ち時間を測る。改善前の数字がないと、導入後に「少し楽になった気がする」で終わる。
5. 05効果、難しさ、安全性から優先順位を決める。時間がかかっている業務が必ず最初の対象になるとは限らない。
6. 06一部署・一業務で小さく試す。ダミーデータや個人情報を除いたデータで、画面や自動処理を小さく作り、担当者に触ってもらう。
7. 07本番の運用まで設計する。権限、記録、エラー時の連絡、人の最終確認、バックアップ、手順書、担当者交代時の引き継ぎまで決める。
8. 08効果を測り、次を決める。時間は減ったか、差し戻しは減ったか、実際に使われているか、想定外の手作業が増えていないか。直すか、広げるか、やめるかを判断する。

この流れは一本道ではありません。試作して初めて分かる例外もあります。FDEは観察、試作、検証を短く往復しながら、現場に合う形へ近づけます。

具体例：月次集計を改善するなら、どこまで見るのか

たとえば、経理や管理部門で毎月行う集計を考えます。

改善前は、複数のシステムからCSVを書き出し、ファイル名を変え、Excelへ貼り付け、前月との差を確認し、上司向けの報告文を書く。担当者は慣れているので作業できますが、その人が休むと手順が分かりません。

ここで「CSVを自動で結合すれば終わり」と考えると、うまくいかないことがあります。書き出す日によって列が変わる、特定の分だけ扱いが違う、締め後の修正は別表に入れる、といった例外があるからです。

FDEは、例外を含む今の流れを見たうえで、自動化する場所と人が確認する場所を分けます。

AIを使うなら、差の理由を勝手に断定させるのではなく、「確認したほうがよい差」を挙げる、報告文の下書きを作る、といった補助から始めます。数字の責任までAIに渡さないことが大切です。

FDEとSES、社内SE、コンサルは何が違うのか

「客先に来るならSESと同じでは」「社内SEがいれば不要では」と聞かれます。違いは職種の優劣ではなく、何を目的に置き、どこまで責任を持つかです。

社内SEがいる会社では、FDEが置き換えるより、経営者、現場責任者、社内SE、FDEが一緒に動く形が現実的です。社内SEは既存システムや契約、変更時の影響をよく知っています。FDEは、日常運用では手が回りにくい業務観察や短期の試作を担当する。役割を分けたほうが安全です。

一般的なFDEは、自社製品を持つ会社のエンジニアが顧客現場で製品を当てはめ、得た知見を製品へ戻すモデルを指すことが多くあります。Eighgentは現段階で、特定製品だけを入れる会社ではありません。Excel、既存のSaaS、AI、決まった手順の自動化、Webアプリを組み合わせる、FDE型の現場実装パートナーという位置づけです。この違いは曖昧にせず、依頼の前に説明します。

FDEに向いている課題、別の依頼先が向いている課題

FDEが力を発揮しやすいのは、困りごとはあるものの、まだ仕様書になっていない仕事です。

• 同じ情報を紙、Excel、システムへ何度も入力している
• 一人しか分からない集計や確認がある
• 新しいシステムを入れたが、周辺の手作業が残っている
• AIを試したが、実際の業務へ組み込めていない
• 大きな投資の前に、一部署で効果を確認したい
• 現場、管理職、社内SE、業者の間を整理する人が必要

反対に、仕様が完全に決まった大規模パッケージ導入、24時間365日の保守要員、単純な人手の補充、専門的な判断そのものをAIへ任せる開発は、初期の支援には向きません。必要に応じて、既存の業者や専門事業者と役割を分けます。

技術的に可能であることと、会社として今やるべきことは同じではありません。扱うデータ、利用目的、保存、学習への利用、権限、記録、責任の範囲は一つずつ確認します。個人情報を含む指示文を外部のAIへ入れる場合の注意は、個人情報保護委員会も注意喚起しています。

Eighgentが目指すのは「FDE型の現場実装パートナー」

改善の相談は、「システムを作ってほしい」という形で来るとは限りません。「この集計が毎月大変」「この確認を見落とすのが怖い」「あの人が休むと止まる」といった、現場の言葉から始まります。

その話を聞き、いまの帳票やデータを確認し、Excelや小さな業務アプリへ落とし込む。導入後に現場から修正点を聞き、運用できる形に直す。この進め方は、FDEにかなり近いものです。

ただし、ある現場で改善した方法が、別の会社でそのまま使えるとは考えていません。会社ごとに規模、システム、人の配置、ルール、契約が違います。だから、製品を先に決めるのではなく、まず現場を見ます。IPAのDX推進指標も、関係者で現状と課題の見方をそろえ、短いサイクルで見直す考え方を示しています。

Eighgentが提供したいのは、「AIを入れましょう」という提案ではありません。今の仕事のどこが重いのかを一緒に見つけ、安全に切り出せる部分を小さく作り、現場が使い続けられる形にすること。それがFDEの役割だと考えています。

相談前に用意するものは、一つだけでよい

要件書も、使いたいAI製品の一覧も必要ありません。「毎月つらい作業」「特定の人しかできない作業」「ミスが怖い作業」のどれかを、一つ挙げてください。そこから、誰が関わり、何件あり、どこで待ち、何を確認しているかを整理します。

最初のゴールは、会社全体を変えることではありません。一部署・一業務について、改善する価値があるか、安全に試せるか、どの数字で効果を見るかを判断できる状態にすることです。

FDEについてよくある質問