こんにちは、株式会社K.Platinum代表の沼田です。
去年（2025年）の7月、LayerXさんがJD（職務記述書）を公開した瞬間、エンジニア採用クラスタが一瞬ざわついた職種がある。
FDE — Forward Deployed Engineer。
直訳すると「前線配備エンジニア」。要は、お客さんのオフィスや業務現場に張り付いて、要件定義から実装までやり切るエンジニアのことだ。米国ではPalantirが10年以上前から運用していたロールで、近年OpenAIやAnthropicも採用していると言われている。日本では、LayerXが本格的に組織化して打ち出したことで一気に認知が広がった。
そのLayerXのJDを読んだ時、僕は「これ、うちが昔からやってたやつだ」と笑ってしまった。
K.Platinumは設立2期目の頃から、ITコンサルとエンジニアの二刀流で動ける人をずっと採ってきた。けど、その役割に決まった名前がなかったから、社内では「動けるITコンサル」「コードも書けるコンサル」みたいに、毎回ふわっと呼んでいた。
「FDE」という言葉が日本に上陸してから、いろいろなものが整理された。今日は、17人規模の中小ITコンサルが、FDEという職種を組織用語として採用したら何が変わったかを、半年運用した時点で書き残しておく。
2025年7月、LayerXがFDEのJDを公開した日
ざっくり経緯を共有しておくと、FDEは2025年7月にLayerXがJDをWebで公開し、同年秋にPodcast・Findyのインタビュー・採用イベントで認知が一気に広がった。半年経った2026年初頭時点で、日本語の「FDE」記事はざっくり20本〜30本前後（ジュバンニ調べ）。まだ少ない。
FDEの定義は、LayerXのJDから雑に抽出するとこんな感じ：
- 顧客と一緒に、価値あるイシューを発見する
- イシューに対して、必要なら自分でコードを書いて検証する
- コードを書く時間と、書かない時間の比率が「常に変動する」のが特徴
- "コンサルとエンジニアの中間"ではなく、"顧客の隣に座るエンジニア"
ここで重要なのは、3つ目の「コードを書く比率が変動する」というところ。普通のエンジニアは「8割実装、2割MTG」くらいで一定だけど、FDEは「今週は要件整理だけ」「来週はガッツリ実装」みたいに、波がある。
普通のITコンサル＋普通のエンジニア、という二窓では捉えきれないロールだ。
K.Platinumは設立当初から「ITコンサル×エンジニア」の二刀流だった
僕は24歳で起業して、今年で3期目を迎えている。立ち上げの最初の1年は、社員ゼロで全部ひとりでやっていた。
要件定義→提案書→PoC実装→顧客説明→運用設計→ドキュメント。順番にやるんじゃなくて、毎日全部が同時並行で動く感じ。今思えば、あれは僕がFDE業務を自分1人でやっていただけだった。
で、社員が増えてきて、僕以外の人にも「ITコンサルとエンジニアの両方できる人」を採るようになった。3期目時点で社員17人。そのうち2人をFDE専任として配置している。
なぜ専任を作ったかというと、お客さんから「沼田さんと同じ動き方ができる人を1人、固定で張り付けてほしい」というご依頼が増えたからだ。社長1人で複数案件をハンドリングする限界が見えたタイミングで、FDEというロールに名前を付けて、組織として運用することにした。
LayerXのJDが日本のFDE元年を作ったタイミングと、ちょうど僕が「うちもFDEポジションを正式に作るか」と考え始めたタイミングが重なったのは、本当に偶然だった。
FDEを「正式な組織用語」にして変わった3つのこと
「FDEっていう言葉、別になくてもよかったんじゃない？」と言われそうなので、組織用語として定着させて何が変わったか、3つ書いておく。
変化1：採用面接の問いが変わった
これが一番大きい。
FDEという名前を採用する前、面接で「あなたはITコンサル志望ですか、エンジニア志望ですか？」と聞いていた。応募者の8割は「両方やりたいです」と答える。けど、両方やりたいの中身が人によってバラバラだった。
- 「コードもたまには書きたい」エンジニア寄りの人
- 「実装の流れも分かるコンサルになりたい」コンサル寄りの人
- 「お客さんの会社に張り付いて何でもやる人になりたい」FDEど真ん中の人
3番目を採りたいのに、面接の問いが2つの軸（コンサル／エンジニア）しかないと、1番と2番を取り違える事故が起きていた。
FDEという言葉を入れてから、面接の問いは「あなたはFDEになりたいですか、それともFDEではないですか？」に変わった。応募者は「FDEの仕事内容」を知った上で、自分の希望を答えられる。判定が早くなった。
変化2：案件アサインの優先順位が変わった
K.Platinumは案件選択制を採っていて、社員が案件にどう入るかをある程度自分で決められる仕組みにしている。けど、お客さん側に「とにかく今、要件が固まらないから誰か張り付いて」という案件が時々出てくる。
これは普通のエンジニアやコンサルだと、お互い負担感が大きい案件だ。エンジニアは「実装はいつ始まるんですか？」とソワソワするし、コンサルは「実装は別の人が来るんですか？」と気にする。
FDE専任を作ってからは、こういう"溶岩流みたいに動く案件"を最優先でFDEに投下するルールにした。FDEは要件が固まらないことを苦にしないし、固まったらそのまま自分で実装に入る。お客さんから見ても、人が入れ替わらないので安心感がある。
変化3：「コードを書かないこと」を評価できるようになった
普通のエンジニア評価だと、コミット数・PR数・実装規模が指標になる。「コードを書かなかった週」はマイナス評価になりがちだ。
FDEは違う。今週コードを書かず、お客さんと業務ヒアリングに3日張り付いて、要件を整理してホワイトボードに5枚描いてきた、というのが満点の週になり得る。コードを書かないことが価値になる場面が、はっきり存在する。
「FDE評価軸」を別に作ったことで、コードを書かない週でも本人と僕が「今週はちゃんと成果出てる」と握れるようになった。これが地味に効いている。
【エンジニア募集中】 K.Platinumでは、コンサルとエンジニアの二刀流で動ける仲間を探しています。FDEという働き方に興味がある方は、エンジニア募集の詳しい条件を見る。
17人規模のFDEと、500人規模（LayerX）のFDEの違い 3点
ここからは、業界の中の人にちょっと刺さるかもしれない話。LayerXさん（500人超の組織）と、K.Platinum（17人組織）で、同じFDEと呼んでいてもオペレーションがどう違うか、3点書く。
違い1：1人のFDEが持てる案件数
LayerXのJDを読むと、FDEは複数顧客を同時並走できることを前提に組まれている。組織として案件ポートフォリオを持ち、FDEは案件間を行き来する。
17人規模のK.Platinumでは、FDE1人が同時に持てる顧客は1社が限界だ。なぜなら、FDEが要件定義から実装まで全部やる前提だと、コンテキストスイッチのコストが大きすぎる。
これは規模の制約というより、案件単価と粒度の問題。K.Platinumのお客さんは中堅企業中心で、1案件3〜8ヶ月かけるディープな受託寄り。LayerXさんはプロダクト＋導入支援のハイブリッドだから、FDEの動き方が違って当然だ。
違い2：スキルレンジ
LayerXのFDEは、設計と開発の橋渡しが中心。実装はBizDevとEM、開発チームに分担されるイメージ。
K.PlatinumのFDEは、要件定義からデプロイ、運用設計まで1人で全部できないと務まらない。社員17人組織だと「自分の後ろに大量のエンジニアチームがいる」という前提が取れないので、最後まで責任を持つレンジが広い。
これは中小ITコンサルのFDEの宿命だと思っている。きついけど、お客さん側から見ると「窓口が1人で完結する」という強烈なメリットがあって、僕らは結局この強みで勝負している。
違い3：FDEのキャリアパス
LayerXさんのFDEは、組織内でVPoEや事業責任者にキャリアが伸びていくイメージ（公開情報から推測）。
K.PlatinumのFDEは、ちょっとずれる。うちの場合、FDEの上のキャリアは「社長候補」または「独立してパートナー化」になる。組織が小さい分、FDEで5年やった人間は、たぶん自分で会社を持てる。むしろうちの卒業制度（COMPANYBLOG-17で書いた）と組み合わさって、「FDEとして3年→K.Platinumから独立→パートナー企業として再契約」というルートが成立する。
この違いは「FDEを抱える組織のサイズ」と「FDEのキャリア天井」が連動するから出てくる差だと思う。17人組織でしか作れないキャリアパスがある、と僕は前向きに捉えている。
採用面接で増えた「FDE志望なんですが、受託開発に応募していいですか？」という質問
最後に、最近の採用現場のリアルを書いて終わる。
FDEという言葉が日本に上陸してから、応募者の中に「FDE志望なんですが、受託開発企業に応募しても大丈夫ですか？」と質問してくる人が、明らかに増えた。
僕の答えは、いつも同じ。「FDEは受託・自社プロダクト関係なくやれる職種。むしろ受託の方が、お客さんに張り付く時間が長いからFDEに向いてる」。
ただ、FDEは「コンサル×エンジニア」の格好良い見た目だけが先行している節もあって、応募者にはちゃんと3つのフィルタを聞いている。
フィルタ1：コードを書かない時間に何ができるか
「今日はコード書きません」と決まった時、何をやるか。
- 業務ヒアリングを5社分、自分から取りに行ける
- 要件整理メモを書ける
- ドキュメントを書き直せる
- お客さんの業界ニュースを読み込める
ここに具体的な動きが思い浮かばない人は、FDEより普通のエンジニアの方が幸せだと思う。コードを書かない時間が苦痛だと、FDEはやれない。
フィルタ2：顧客の業界に興味を持てるか
製造業のお客さんなら製造業の経営課題を、流通業のお客さんなら流通業の在庫戦略を、自分から知りたくなる人かどうか。
これがFDEの一番の素養だと思っている。技術スキルは後から鍛えられる。お客さんの業界への興味は、後から作るのが本当に難しい。
フィルタ3：「受託＝下請け」じゃないと理解しているか
受託開発に「下請け感」を感じてしまう人がたまにいる。お客さんの言いなりで作る業務、というイメージ。
FDEは真逆だ。お客さんと同じ立場で、何を作るか・作らないかを決める仕事。受託開発の「指示待ち下請け」イメージを引きずっている人は、FDEの面接で苦しくなる。
結論：FDEは「コンサルとエンジニアの中間」じゃない
半年運用してたどり着いた僕の結論。
FDEは「コンサルとエンジニアの中間」じゃない。「顧客の隣に座るエンジニア」だ。コンサル業務もエンジニア業務も、その日その日で必要なものをやる。けど立ち位置はずっと「顧客の隣」で固定されている。
LayerXさんが日本のFDE元年を作ってくれたおかげで、僕らみたいな中小ITコンサルも、ようやくこの職種を組織用語として整備できるようになった。日本のFDEがもう1段標準化されれば、もっと多くのITコンサル会社が同じ運用を持てるようになる。
そして、17人組織でやる「規模が小さいFDE」運用論は、まだ誰も書いていない領域だ。これからの数年で、もう少しちゃんと整理して書き残していこうと思っている。
K.PlatinumでFDEとして働くことに興味がある方、よかったらカジュアルに話しましょう。コード以外の話もたくさんできる人を、いつも探しています。
沼田海斗（ぬまた・かいと）
株式会社K.Platinum 代表。24歳で起業し、現在3期目。ITコンサルとエンジニアの二刀流で動ける組織づくりにこだわっている。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひ採用ページをご覧ください。
関連記事
- [COMPANYBLOG-22] SI × ITコンサル。上流から開発まで一貫でやる小さな会社の戦い方
- [COMPANYBLOG-17] 独立したいエンジニアへ。K.Platinumの"卒業制度"という考え方
- [COMPANYBLOG-50] エンジニア17人の小さな会社で、なぜ"全員経営者目線"が成立しているのか