FDE（Field Data Engineer）という職種を作った理由

私がHibitoを創業し、SalesFDEというサービスを立ち上げたとき、最初に決めたのは「職種を定義する」ということだった。営業企画でもなく、データエンジニアでもなく、コンサルタントでもない。FDE（Field Data Engineer）という、まだ誰も名乗っていない肩書きを作ることから始めた。

なぜ既存の職種名では駄目だったのか。この記事では、その背景を語りたい。

営業の現場で感じた2つの断絶

私はリクルートで営業推進を経験し、Magic Momentでセールスイネーブルメントやコンサルティングに携わってきた。その中で、営業組織が変われない根本原因は、技術的な問題でも戦略的な問題でもなく、「人材の断絶」にあると確信するようになった。

断絶1: 営業企画は設計できるが、実装できない。

営業企画のメンバーは、ファネル分析やKPI設計はできる。どこにボトルネックがあるか、何を改善すべきかもわかっている。しかし、CRMのカスタムオブジェクトを設計したり、ツール間のデータ連携を構築したり、自動化ワークフローを実装したりすることは、自分たちの仕事ではないと思っている。結果として「施策は決まったがIT部門の開発待ち」という状態が慢性化する。

断絶2: エンジニアは実装できるが、営業を理解しない。

SIerやIT部門に開発を依頼すると、要件通りのシステムは出来上がる。だが、営業プロセスが四半期ごとに変化することを前提とした設計にはならない。「なぜこのフィールドが必要なのか」「このデータが商談のどの段階で発生するのか」を肌感覚で理解していないから、使いにくいシステムが量産される。営業メンバーはCRMに入力しなくなり、データは腐り、ダッシュボードは形骸化する。

この2つの断絶を埋められる人材が、日本の営業組織にはほぼ存在しなかった。

米国のGTMエンジニアとの出会い

2023年頃から、米国では「GTMエンジニア（Go-To-Market Engineer）」という職種が急速に広がり始めた。Clay、Apollo.io、n8nといったGTMテックスタックの進化を背景に、営業プロセスを技術で実装する専門人材の需要が爆発的に高まったのだ。

GTMエンジニアの定義を見たとき、私が営業の現場で感じてきた断絶を埋める存在が、ようやく職種として認識されたのだと感じた。営業プロセスを理解し、データを設計し、ツールを実装し、自動化を回す。まさに日本の営業組織に必要な人材像だった。

しかし同時に、「GTMエンジニア」という名前をそのまま日本に持ち込むことには違和感があった。

なぜ「GTMエンジニア」ではなく「FDE」なのか

違和感の正体は3つある。

第一に、日本の営業はフィールド（現場）が全てだということ。

米国のGTMエンジニアは、主にインバウンドマーケティングとインサイドセールスを中心としたデジタルファネルの最適化に軸足を置いている。しかし日本のB2B営業では、フィールドセールスの比重が依然として大きい。現場での商談、顧客訪問、対面での関係構築。こうした「フィールド」で生まれるデータと行動を扱えなければ、日本の営業組織は変わらない。

第二に、「Go-To-Market」という概念の浸透度の問題。

GTMという略語は、日本の営業現場ではまだ馴染みが薄い。営業部長に「GTMエンジニアを入れましょう」と提案しても、「GTMって何？」から説明が始まる。それ自体は問題ないが、職種名が自明でないことは採用や社内定着において不利に働く。

第三に、私たちが目指す役割の範囲がGTMエンジニアよりも広いということ。

GTMエンジニアの主な守備範囲は、テックスタックの設計と実装だ。しかし私たちが必要だと考えている人材は、営業戦略の企画段階から入り、プロセスを設計し、データ基盤を構築し、AIによる自動化まで一気通貫で担える存在だ。単なるツールの実装者ではなく、営業組織そのものをエンジニアリングする人材。

この3つの理由から、私たちは独自の職種名を定義することにした。

FDE = Field + Data + Engineer

FDE（Field Data Engineer）。この名前には3つの意味を込めている。

Field（現場）。 営業の現場に立ち、顧客と営業メンバーの行動を自分の目で見る。机上の分析ではなく、現場のリアリティからプロセスを設計する。

Data（データ）。 営業活動をデータとして構造化し、意思決定の基盤を作る。CRM設計、データパイプライン構築、KPIダッシュボード。データに基づく営業推進を実現する。

Engineer（エンジニアリング）。 設計した仕組みを自らの手で実装する。企画書を書いて終わりではなく、ワークフローを組み、APIを繋ぎ、自動化を動かす。

この3つが1人の中に統合されていること。それがFDEの本質だ。

GTMエンジニアとFDEの関係性

誤解を避けるために明確にしておきたい。FDEはGTMエンジニアの否定ではない。GTMエンジニアの思想を日本の営業文化に適応させ、さらに発展させた形だと私は位置づけている。

GTMエンジニアが切り拓いた「営業プロセスの技術的実装」という領域は、FDEの核にもある。その上で、FDEは日本特有の要素を加えている。

• フィールドセールス中心の営業文化への対応
• 営業企画（Sales Planning）の知見との統合
• 組織コーチングとの連携による定着支援

GTMエンジニアがグローバルな職種定義だとすれば、FDEは日本の営業組織のために最適化されたローカライズ版であり、同時に「企画から実装、定着まで」をカバーする拡張版でもある。

SalesFDEサービスとしての展開

Hibitoが提供するSalesFDEは、このFDEの能力を営業組織に届けるサービスだ。多くの企業にとって、FDEを正社員として採用するのは現実的ではない。営業企画の経験とエンジニアリングスキルを兼ね備えた人材は市場にほとんど存在しないからだ。だからこそ、私たちがFDEの機能を外部から提供している。

SalesFDEの特徴は、営業戦略の策定からプロセス設計、SFA/CRM構築、AI自動化の実装まで一気通貫で伴走すること。そして組織コーチングによる行動変容まで含めて、営業組織の変革を完遂することだ。

全ての営業組織にエンジニアが必要な時代

生成AIの進化により、営業プロセスの自動化は現実になった。しかし、AIを営業組織に正しく実装できる人材がいなければ、ツールは「導入したけど使われていない」SaaSの山に加わるだけだ。

FDEは、その実装を担う人材だ。営業の現場を理解し、データを構造化し、テクノロジーを実装する。この3つの力を持つ人材が、営業組織の競争力を左右する時代がすでに来ている。

私たちはFDEという職種を作ったが、これはHibitoだけのものではない。日本の営業組織が真に変革するために必要な人材像として、GTMエンジニアという世界的な潮流の中で広まっていくことを願っている。

「営業企画ができる。実装もできる。」この一文を、当たり前にしたい。それが、私たちがFDEという職種を作った理由だ。