「Forward Deployed Engineer（FDE）」という言葉を聞いたことがあるでしょうか。日本ではまだ馴染みの薄い職種ですが、私たちテクシズはこのスタイルで顧客と仕事をしています。この記事では、FDEとは何か、従来の受託開発と何が違うのか、なぜ今この働き方なのかを説明します。
FDEとは
Forward Deployed Engineer は直訳すると「前方に配置されたエンジニア」。米国のPalantir社が広めた職種で、エンジニアがオフィスにこもって仕様書どおりに作るのではなく、顧客の現場に入り込み、業務の実態を自分の目で見て、課題の発見から解決までを担うスタイルを指します。
ポイントは、FDEの仕事が「開発」から始まらないことです。最初にやるのは、現場の人の隣に座って業務を観察し、話を聞くこと。何に時間が取られているのか、どこで情報が分断されているのか、本当のボトルネックはどこか。課題を定義するところからがエンジニアリングだと考えます。
受託開発と何が違うのか
従来の受託開発は、おおまかに言えばこういう流れです。顧客が要件をまとめ、発注し、開発会社が見積もり、仕様書どおりに作って納品する。この構造には根本的な弱点があります。要件を書く時点で、解決策が固定されてしまうことです。
現場の課題を一番わかっているのは現場の人ですが、その課題を「システムの要件」に翻訳するのは別のスキルです。翻訳の過程で本質がこぼれ落ち、出来上がったシステムが「仕様どおりだが使われない」ものになる——これは多くの会社が経験している失敗ではないでしょうか。
FDEはこの翻訳を顧客に任せません。エンジニア自身が現場に入り、業務を理解した上で「これはシステム化すべき」「これは運用を変えるだけでいい」「ここはAIに任せられる」と切り分けます。要件書を待つのではなく、課題定義そのものを顧客と一緒にやる。発注先ではなく、チームの一員として動きます。
SESとは違うのか
「エンジニアが顧客の現場に入る」と聞くと、SES（客先常駐）と同じに聞こえるかもしれません。たしかに「現場にいる」という見た目は似ていますが、提供しているものが違います。
SESが提供するのは労働力です。エンジニアの稼働時間を提供し、何をするかは基本的に顧客側が決めます。アサインされたタスクをこなすのが仕事で、極端に言えば、顧客の指示が間違っていてもそのとおりに作るのがSESの構造です。課題を定義する責任は顧客側に残ったままです。
FDEが提供するのは課題解決です。現場に入るのは指示を受けるためではなく、課題を自分の目で見つけるため。何を作るべきかの提案から、プロトタイプの作成、本番開発、運用改善まで、解決までの道筋に当事者として責任を持ちます。常駐すること自体には意味がなく、課題を掴むのに必要な分だけ現場に入る、という距離感です。
ひとことで言えば、SESは「人を出す」、受託は「言われたものを作る」、FDEは「一緒に問題を見つけて解く」。座る場所の話ではなく、責任の持ち方の話です。
なぜ今、FDEなのか
AIによってコードを書くコストは劇的に下がりました。動くプロトタイプを作るのに数か月かかった時代は終わり、数日で形にして現場に見せられるようになっています。
すると何が起きるか。開発の価値の重心が「作ること」から「何を作るべきか見極めること」に移ります。 実装が速くなるほど、間違ったものを速く作ってしまうリスクも上がる。だからこそ、課題を正しく掴むための「現場に入る」工程の価値が相対的に大きくなっているのです。
FDEとAIは相性のいい組み合わせです。現場で課題を見つけ、その場でプロトタイプを作って見せ、フィードバックをもらってまた直す。このループが速く回るほど、システムは現場の実態に近づいていきます。
現場で実際にやること
私たちの場合、FDEとしての関わり方はだいたいこうなります。
- 週次の定例と現場ヒアリング：定例ミーティングに加えて、実際に業務をしている人に話を聞きます。資料ではなく、画面と手元を見せてもらいます
- 課題の言語化と優先順位づけ：見つけた課題を一覧にし、効果と実現コストで優先順位を顧客と一緒に決めます
- 高速プロトタイピング：優先度の高いものから、まず動くものを作って現場に当てます。完璧な設計より、早いフィードバック
- 育てる運用：納品して終わりではなく、使われ方を見ながら継続的に改善します。業務は変わり続けるので、システムも変わり続けます
成果物のかたちは「買い取り」でも「SaaS」でも
FDEとして作ったものを、最終的にどう持つか。これは顧客の経営判断に合わせて選べるべきだと考えています。私たちは大きく2つのかたちに対応しています。
ひとつは、作って渡すかたち。 開発したシステムをソースコードごと納品し、顧客の資産にします。社内システムとして自社で運用したい、自社のIT部門で育てていきたい、という場合はこちらです。属人化を避けるため、引き継ぎを前提としたドキュメントと構成で作ります。
もうひとつは、SaaSとして一緒に育てるかたち。 私たちが運用を持ち、継続的に改善し続けます。業務が変わればシステムも変える、という「育てるプロダクト」の考え方です。現場で磨かれた仕組みが他社にも通用するものになれば、SaaSとして外に展開していく道もあります。その場合、最初の顧客は「発注者」ではなく「共創パートナー」になります。
どちらが正解かは、システムの性質と顧客の戦略次第です。一度作れば大きく変わらない業務基盤なら買い取りが合理的ですし、変化の速い業務やAIを組み込んだ仕組みなら、継続的に育てるSaaS型のほうが結果的に安くつくことが多い。このあたりの設計も、現場を知っているFDEだからこそ一緒に考えられる部分です。
まとめ
FDEとは、顧客の現場に入り込み、課題の発見から解決までを担うエンジニアです。要件書を介した分業ではなく、課題定義から一緒にやる協働。AIで実装コストが下がった今、この「何を作るべきかを現場で見極める」働き方の価値はますます大きくなっていると私たちは考えています。
テクシズはFDEスタイルでの開発支援を行っています。「システム化したいが要件がまとまらない」「作ったシステムが現場で使われていない」——そんな課題をお持ちでしたら、お問い合わせからお気軽にご相談ください。