なぜ今、業務を理解するエンジニア（FDE）が求められるのか
AIやDXの相談を受けていると、「ツールは入れたが使われていない」「システムはできたが現場の仕事が楽になっていない」という話をよく聞きます。
原因は、技術が足りなかったからとは限りません。むしろ多いのは、業務理解が浅いままシステムを作ってしまった というケースです。
現場では、業務がExcel、紙、メール、チャット、古い基幹システムにまたがっています。さらに、担当者ごとの判断、例外対応、取引先ごとのルール、月末だけ発生する処理など、仕様書に書ききれない運用が大量にあります。
この状態で「AIを入れたい」「業務システムを作りたい」と考えても、最初からきれいな要件定義書を作るのは簡単ではありません。だから今、単にコードを書くエンジニアではなく、業務を理解しながら何を作るべきかを考えられるエンジニア が求められています。
その代表的な考え方が、FDE（Forward Deployed Engineer）です。
調査で見えた「FDEが求められる理由」
海外の記事や企業の発信を見ていくと、FDEが注目されている理由はかなりはっきりしています。AIそのものの性能よりも、AIを業務に組み込む力 がボトルネックになっているからです。
TechRepublicの記事では、2026年の企業AIトレンドとして「AIは広く導入されているが、価値が保証されているわけではない」と整理されています。同記事では、2024年時点でAI投資から具体的な価値を得られていない企業が74%にのぼり、2025年時点でも多くの企業が本格導入前の試験運用段階にとどまっていると紹介されています。さらに、12万社以上を対象にした調査では、AIエージェントを本番環境で運用している企業は一部に限られるとされています。
つまり、多くの企業は「AIを試す」ところまでは進んでいます。しかし、「業務の中で日常的に使われ、成果が測れる状態」までは届いていません。
この背景から、OpenAIも企業向けAI導入を支援する組織を立ち上げ、Forward Deployed Engineerが顧客企業の業務フローに入り、AIを実際の業務に組み込む役割を担うと報じられています。ITProの記事では、FDEがビジネスリーダーや現場チームと連携し、AIが最も効果を出せる領域を見つけ、ワークフローを再設計し、持続的に使えるシステムへ落とし込む役割だと説明されています。
また、Sigma Softwareの記事では、FDEを「顧客の環境に入り、価値の高い業務課題を見つけ、AIネイティブな業務フローを設計し、実環境にデプロイし、採用状況を測定するモデル」と説明しています。ここで重要なのは、FDEが単なる提案役でも、単なる実装担当でもないという点です。
FDEが求められている理由は、「AIを使える人」ではなく、AIを現場の業務成果に変換できる人 が不足しているからです。
FDEとは何か
FDEとは、Forward Deployed Engineerの略です。直訳すると「前線に配置されたエンジニア」。顧客の現場に近い場所で、業務課題を理解しながら、設計・実装・運用定着まで担うエンジニアを指します。
もともとはPalantirが広めた働き方として知られています。Palantirの公式ドキュメントでは、顧客の複雑なミッションから得た学びを開発へ還元する方法論としてForward Deployed Engineeringが説明されています。
通常のエンジニアは、決まった仕様をもとに機能を作ることが多いです。一方FDEは、仕様が固まる前の段階から現場に入り、「何が本当の課題なのか」「どこをシステム化すると効果が出るのか」を見極めます。
つまりFDEは、エンジニアでありながら、業務改善の担当者でもあり、プロダクトマネージャーでもあり、時にはコンサルタントのような役割も担います。ただし、最終的な成果物は提案書ではありません。現場で動く仕組みです。
なぜ「業務理解」がこれほど重要になったのか
従来のシステム開発では、業務側が要件をまとめ、開発側がそれを実装する分業が一般的でした。作るものが明確であれば、この進め方は今でも有効です。
しかし、DXやAI活用では、そもそも「何を作るべきか」が最初から明確ではないことが多くなっています。
たとえば、社内問い合わせ対応をAIで効率化したいとします。このとき必要なのは、チャットボットを置くことだけではありません。
- 問い合わせはどこから来ているのか
- 誰が一次回答しているのか
- どの質問はAIに任せてよいのか
- どの質問は人に回すべきなのか
- 回答の根拠となる文書はどこにあるのか
- 古い情報をどう除外するのか
- 誤回答が出たとき誰が直すのか
こうした業務設計ができていなければ、AIを導入しても現場では使われません。
つまり、問題は「AIの性能」だけではありません。AIをどの業務に、どの流れで、どの責任範囲で組み込むかが成果を左右します。ここを設計するには、業務を理解する力が不可欠です。
仕様書だけでは現場の仕事を表現しきれない
業務システムの失敗でよくあるのが、「仕様書通りに作ったのに使いにくい」という状態です。
開発側から見ると、仕様通りに作っています。発注側から見ると、確かに要望は伝えたはずです。それでも現場で使われない。これは、仕様書に書かれていない業務の細部が抜け落ちているからです。
たとえば、見積作成ひとつを取っても、実際の現場には細かい判断があります。
- 取引先によって端数処理が違う
- 急ぎ案件だけ承認フローが変わる
- 過去案件をコピーして作ることが多い
- 営業担当だけが知っている例外値引きがある
- 月末だけ経理確認が追加される
こうした細部は、最初のヒアリングだけでは出てきません。実際に現場で使ってもらい、手が止まる場所を見て、初めて分かります。
業務を理解するエンジニアは、この「仕様書に書かれていない現実」を見に行きます。だから、最初から完璧な要件を求めるのではなく、小さく作り、現場で試し、改善しながら本番に近づけていきます。
AI時代は「作る力」より「組み込む力」が問われる
生成AIの登場によって、コードを書くスピードは大きく上がりました。プロトタイプを作るだけなら、以前より短い時間でできるようになっています。
しかし、AI時代に本当に難しいのは、作ることそのものではありません。業務に組み込むこと です。
AIに何を任せ、何を人が確認し、どのデータを参照し、どのタイミングで業務フローに入れるのか。この設計が曖昧なままでは、AIは「便利そうなツール」で止まります。
たとえば、営業日報をAIで要約する仕組みを作る場合でも、単に文章を短くするだけでは不十分です。
- 誰が読むための要約なのか
- 次のアクションを出す必要があるのか
- CRMに自動登録するのか
- 上司の確認を挟むのか
- 顧客情報をどこまで扱ってよいのか
こうした問いに答えられないまま作ると、現場は「結局、自分で直した方が早い」と感じます。
AI時代に求められるエンジニアは、AIを使って何かを作れる人ではなく、AIを業務の中で価値が出る形に組み込める人です。その意味で、FDE型の考え方は今後さらに重要になります。
Constellation Researchの記事では、FDEについて「価値を早く出すための有効な手段である一方、未成熟なプロダクトを人手で補う危うさもある」と指摘されています。この視点は重要です。FDEは万能ではありません。現場に入り込む人がいれば必ず成功する、という話ではないからです。
大事なのは、FDEを「何でもやってくれる人」として扱わないことです。FDE型の開発では、現場に近い場所で課題を見つけ、必要なシステムを小さく作り、運用に乗せながら改善します。ただし、その過程で得られた知見を社内に残し、再利用できる形にしていかなければ、単なる属人的な支援で終わってしまいます。
中小企業ほどFDE型が効きやすい
FDEという言葉は、海外の大手テック企業やAI企業の文脈で語られることが多いですが、考え方そのものは中小企業にも当てはまります。
むしろ中小企業の方が、FDE型の進め方と相性がよい場面は多くあります。
中小企業では、業務が人に依存していることが少なくありません。担当者しか知らないExcel、長年使っている紙の帳票、取引先ごとの個別ルール、古いシステムへの手入力。こうした業務をいきなり要件定義書に落とし込むのは難しいです。
だからこそ、現場を見ながら小さく作る進め方が有効です。
最初から全社DXを狙う必要はありません。まずは、毎月の請求作業、問い合わせ対応、見積作成、在庫確認、日報整理など、現場の負担が大きい業務を1つ選びます。そこで小さな仕組みを作り、使いながら改善し、効果が出たら次の業務へ広げていく。
この進め方なら、大きな投資をする前に手応えを確認できます。現場も「いきなり全部変えられる」のではなく、「困っている作業が少し楽になる」ことから始められます。
業務を理解するエンジニアに必要な力
業務を理解するエンジニアに必要なのは、技術力だけではありません。もちろん、実装力は必要です。しかしそれだけでは、FDE型の働き方はできません。
重要なのは、次のような力です。
- 現場の話を聞き、業務フローとして整理する力
- 要望の奥にある本当の課題を見つける力
- 小さく作って早く試す力
- 技術的にできることと、業務上やるべきことを分ける力
- 運用後に誰が使い、誰が直すかまで考える力
特に大切なのは、要望をそのまま作らないことです。現場から「この機能がほしい」と言われたとき、そのまま作るのではなく、「なぜその機能が必要なのか」「本当に必要なのは別の処理ではないか」を確認する必要があります。
業務理解とは、現場の要望をすべて受け入れることではありません。現場の困りごとを理解したうえで、より良い解き方を一緒に探すことです。
Arintiが考えるFDE型の開発支援
「DXを進めたいが、何から作ればよいか分からない」「AIを使いたいが、現場業務にどう組み込むべきか決めきれない」「開発会社に依頼したが、業務理解が浅くて手戻りが多い」 — こうした課題は、仕様書を渡して開発するだけでは解決しにくい領域です。
Arintiは、IT事業会社でプロダクト開発や事業推進を経験してきたエンジニアで構成された、DX・開発支援会社です。システムを開発して納品するだけでなく、事業成果の達成まで見据え、事業視点でDX・開発支援 を行っています。
実際に開発を行うエンジニア自身が、課題整理・業務設計・技術選定・開発まで一貫して担当することで、事業理解と実装を分断しない開発体制を実現しています。業務DX、システム開発、アプリ開発、データ基盤構築、AI活用、プロダクト開発まで、事業に必要な仕組みを一気通貫で支援します。
業務の整理から実装、運用後の改善までを分断せずに進めたい場合は、FDE型開発の考え方が一つの選択肢になります。中小企業DXや業務システム開発に関するご相談は、お問い合わせフォームからご連絡ください。
▼会社HPはこちら
よくある質問
Q. 業務を理解するエンジニアとは何ですか?
単に仕様通りに実装するだけでなく、現場の業務フロー、データ、例外処理、運用ルールを理解したうえで、何を作るべきかから考えられるエンジニアです。
現場の要望をそのまま作るのではなく、「なぜその業務が必要なのか」「どこを変えると効果が出るのか」まで掘り下げる点が特徴です。
Q. なぜ今FDE型のエンジニアが求められているのですか?
AIやDXでは、ツールを入れるだけでは成果が出にくく、業務への組み込みが重要になっているためです。
特に生成AIは、使い方を間違えるとPoCや便利ツールで止まりやすくなります。業務を理解しながら設計・実装できる人材の価値が高まっています。
Q. 普通の開発会社との違いは何ですか?
普通の開発会社は、仕様書をもとに開発することが多いです。一方、FDE型のエンジニアは、仕様が固まる前の課題整理から入り、現場で使える形にするところまで関わります。
作るものが明確な場合は通常の受託開発でも問題ありません。何を作るべきかが曖昧な場合や、現場の業務理解が成果を左右する場合にFDE型が向いています。
Q. 中小企業でもFDE型の進め方は使えますか?
使えます。むしろ、業務が属人化していて要件を最初から書きにくい中小企業ほど、現場を理解しながら小さく作って改善する進め方と相性があります。
最初から全社DXを狙うのではなく、問い合わせ対応、見積作成、請求処理、在庫確認など、効果が見えやすい業務を1つ選んで始めるのが現実的です。