顧客の声は大事です。
顧客が何に困っていて、何を必要としているのかを知らなければ、営業もプロダクト開発も成り立ちません。顧客の課題を解決し、その対価を受け取ることが事業の基本である以上、顧客を見ない企業活動には限界があります。
ただ、この「顧客の声」という言葉、社内では強すぎるんです。
「顧客がそう言っている」「この機能がなければ受注できない」と言われると、なかなか反論できません。反対すれば、顧客を見ていない、売上を軽視している、と受け取られかねない。仮説や設計思想には別の仮説をぶつけられますが、「顧客の声」には、それだけで議論を終わらせる力があります。
最近、この顧客の声は、企業にとって重要な情報であると同時に、扱い方を間違えると組織を壊す麻薬のようなものではないか、と考えるようになりました。
もちろん、問題は顧客の声そのものにあるわけではないでしょう。ここで麻薬と言っているのは、顧客の声に従えば答えが出たような気になり、自社で考えなくても済んでしまう、その依存性のことです。
顧客の声は、伝わる途中で別のものになる
顧客が口にしたことと、本当に解決すべき問題は同じとは限りません。
たとえば「CSVの一括出力機能が欲しい」と言われたとしても、実際の問題は月末の集計に三日かかっていることかもしれません。「競合製品にはこの機能がある」という話も、実務で必要なのか、調達時の比較表を埋めたいだけなのかで意味が変わります。「この機能がなければ買えない」という言葉も、本当の購入条件なのか、社内稟議の説明材料なのか、価格交渉の一部なのかは分かりません。
顧客の声をプロダクト開発に使うには、誰が、どの業務の、どの場面で困っているのかを知る必要があります。その人は実際の利用者なのか、それとも決裁者なのか。どのくらいの頻度で起きる問題なのか。既存機能ではなぜ解決できないのか。こうした文脈がそろって、ようやく一つのフィードバックになります。
ところが、顧客の声が営業からプロダクト側へ渡るまでには、いくつかの変換が起きます。
まず、営業が接している顧客は市場全体の一部です。商談中の顧客、大口顧客、発言の強い顧客、解約しそうな顧客の声ほど社内に届きやすくなります。営業活動を通じて集めた声である以上、そこには最初から偏りがあります。
次に、問題が解決策へ変換されます。「集計に三日かかる」という問題より、「CSV一括出力機能が欲しい」という要求の方が、社内へ依頼しやすいからです。ただ、この変換が行われた時点で、ほかの解決方法を考える余地はかなり狭くなります。
さらに、特定の顧客が特定の状況で口にした案が、「顧客ニーズ」や「市場要求」という言葉に一般化されます。ここまで来ると強いです。もとの発言にどれほど代表性があったのか分からなくても、プロダクトのロードマップを動かす根拠になります。
顧客の声の危うさは、発言の正誤よりも、それを使うことで自社で市場を解釈し、判断する作業を省略できてしまう点にあります。
しかも、「顧客が言ったから作った」という説明は社内的に安全です。自分たちで仮説を立てて外せば判断の責任を問われますが、顧客要望に従った結果なら説明がつきます。要望に応えて受注できれば、すぐに成功体験も得られます。
こうして顧客の声は、判断の材料ではなく、判断を代行してくれる便利な答えになっていきます。これが、私が麻薬と呼びたくなる理由です。
営業とプロダクトは、合理的にすれ違う
この問題を、営業が顧客の言葉をそのまま信じてしまうからだ、と片付けるのも違うと思います。
営業は商談を進めるために、顧客の発言を具体的な社内要求へ変換しなければなりません。期限、予算、競合状況がある中で、目の前の案件を優先するのは自然なことです。顧客要望を満たして受注できれば、それははっきりした成果として評価されます。
一方で、プロダクト側が営業からの要望を警戒することにも理由があります。一社のために追加した機能は、その後も保守し続けなければなりません。個別対応が増えれば製品は複雑になり、開発速度も落ちます。大口顧客の要求だからといって、ほかの顧客にも同じ価値があるとは限りません。
営業とプロダクトでは、見ている時間軸も評価指標も異なることがあります。それぞれの立場では合理的に動いているのに、両者をつなぐ仕組みが「顧客の声の伝達」に依存しているため、対立が起きます。
営業側から見れば、プロダクト側は顧客を見ずに理屈ばかり言っているように見えます。プロダクト側から見れば、営業は顧客の言葉をそのまま持ち込み、製品全体への影響を考えていないように見えます。そのうち営業はプロダクトに期待しなくなり、プロダクト側も営業経由のフィードバックをノイズとして扱い始めます。
誰かのコミュニケーション能力が低いという話ではなく、顧客を観察する人、課題を解釈する人、作る人、結果を確認する人が分かれていることに問題があります。途中に人が増えるほど、顧客の現実は短い機能要求に圧縮されていきます。
FDEは、伝言ゲームに対する回答だった
そこでForward Deployed Engineer、FDEです。
FDEは一般に、顧客の現場に入り込み、顧客と一緒にシステムを作るエンジニアとして説明されます。FDE、あるいはFDSEという名称と役割は、Palantirのモデルに由来すると一般に説明されています。Palantirでの正式な職種名はForward Deployed Software Engineer、略してFDSEで、社内ではDeltaと呼ばれています。その後、AI企業を含むほかの企業にもFDEという名称が広がりました。ただし、現在は企業によって仕事内容にかなり幅があり、統一された職種定義があるわけではありません。
FDEの価値を「顧客対応もできるエンジニア」と捉えると、プリセールスやソリューションアーキテクト、導入コンサルタントとの違いが曖昧になります。私が面白いと感じているのは、担当者の肩書よりも、観察、課題定義、設計、実装、導入、検証のつなぎ方です。
Palantirの公式ブログには、一般的な製品開発をリレー競技にたとえた説明があります。経営やプロダクトマネージャーが方向を決め、エンジニアが作り、営業やサポートが利用者の反応を受け取り、それを再びプロダクト側へ返す。Deltaはこの区間をまたぎ、顧客との初期の議論から課題の特定、スコープ設定、製品の展開、稼働後の利用者支援まで、かなり広い範囲を担当します。
現在のPalantirのFDSE求人でも、顧客の課題を理解し、システム設計やプロトタイプからアプリケーション開発、データ統合までを行い、顧客と社内の双方から継続的にフィードバックを受ける役割と説明されています。
顧客の発言をそのまま機能要求として持ち帰るのではなく、いったん仮説に戻し、現場のデータや業務を見ながら実際に動くものを作る。それが本当に使われるのか、業務が変わるのか、成果が出るのかまで確認する。
顧客の声を正確に伝達するというより、顧客の声を検証可能な形に変える仕組みと考えた方が分かりやすいと思います。
Palantirの発明は、DevとDeltaの分業にある
Palantirは、製品開発を担うDevと、顧客側に入るDeltaの違いを、公式ブログで説明しています。
Devが見るのは「一つの能力と、多くの顧客」、Deltaが見るのは「一つの顧客と、多くの能力」です。
この説明を見たとき、なるほどと思いました。ここにはプロダクト企業が抱える矛盾が、そのまま表れています。多くの顧客に共通する機能を作らなければ製品にはなりません。一方で、共通機能だけを見ていては、個々の顧客が実際に成果を出すところまで届かないことがあります。
Palantirはこの矛盾を、一人のスーパーマンに任せず、反対方向を見る二つのエンジニアリング機能として組織の中に置いています。
Deltaは顧客の成果を追い、必要に応じてコア製品にもコードを戻します。ただし、何でも顧客要望のまま製品へ入れられるわけではなく、大きな変更は製品チームのロードマップと照らして判断されます。この緊張関係まで含めて、仕組みになっています。
FDEを営業とプロダクトの間に置いた中間職と見るだけでは、この構造が見えません。顧客固有の問題を深く解く機能と、多くの顧客に使える形へ共通化する機能を分け、その間を人とコードが行き来するようにした。私がFDEを発明だと感じるのは、この組織設計です。
なお、「PalantirがFDEを発明した」という言い方は広く見られますが、役割の成立過程を示す公開一次資料は限られています。そのため、この記事では歴史的な発明者を断定するのではなく、PalantirでFDEという役割が形成され、独自の開発・導入モデルとして制度化された、という範囲で捉えています。
Palantirだからできたのか、FDEがPalantirを作ったのか
ここで考えなければならないのが、これはPalantirのように独自のカテゴリーを作った企業だから可能だったのではないか、という点です。
確かに、この仕組みを模倣するには条件があります。Palantirは2025年度の年次報告書で、高い導入コスト、失敗リスク、複雑なデータ環境、長い販売期間を伴う、大規模で実行の難しい案件を対象としていると説明しています。また、複雑で価値の高い課題を理解するには顧客の問題を直接経験する必要があるとして、利用者の中に入り、そこから研究開発の機会を見つける方針も明記しています。
高度なエンジニアを顧客ごとに配置できる契約規模があり、顧客固有の実装を吸収できる共通プラットフォームがあり、現場で得た知見を製品へ戻す開発体制がある。こうした条件がそろって、FDEは持続可能になります。
だから、一般的な企業がFDEという肩書だけを持ち込んでも、同じことができるとは限りません。共通のプロダクト基盤がなければ、顧客常駐型の受託開発になります。個別案件の知見を製品へ戻す経路がなければ、コードも書けるプリセールスで終わります。現場で判断する権限がなければ、顧客要望を本社へ持ち帰る従来の伝言ゲームに戻ります。それぞれの仕事にも価値はありますが、この記事で発明と呼んでいる仕組みとは別のものです。
一方で、因果関係は逆向きにも見えます。Palantirが独自のポジションにいたからFDEを採用できた面もあれば、FDEを中心とする開発と導入の方式がPalantirの独自性を作った面もあります。
FDEは、成功したプロダクト企業に後から足された職種ではなく、プロダクト、顧客、販売方式、契約構造、組織文化と一緒に発達し、Palantirという会社の形を作った構成要素なのでしょう。
AI時代にFDEという名前が広がる
最近FDEが注目されている背景には、生成AIの企業導入があります。
生成AIは能力の変化が速く、出力も確率的です。技術的に可能なことと、業務で安定して使えることにも差があります。要件を固めてから一度に作るより、小さく作り、実際に使い、評価しながら適用範囲を決める方法と相性がよいところがあります。
OpenAIの東京勤務のFDE求人を見ると、顧客と一緒に課題を探索し、設計、構築、本番展開までを担当するとあります。成功指標には本番での利用や業務への影響に加え、プロダクトやモデルのロードマップを変えるフィードバックも含まれます。個別案件で得たパターンを再利用可能な部品にすることも仕事です。
PalantirとOpenAIでは、プロダクトも顧客も事業の歴史も違います。それでも、技術の可能性と顧客の業務の間にある距離を、現場で作りながら埋めるという点では共通しています。
一方、市場で言葉が広がれば意味も変わります。現在のFDEは企業ごとに、営業支援、導入支援、コア製品への貢献のどこを重く見るかが異なり、ソリューションエンジニアやコンサルタントとの境界も一定していません。今後は「顧客対応から実装までできる高度なエンジニア」という意味で定着するのかもしれません。それも市場が必要とした新しい仕事ですが、なぜFDEという考え方が生まれたのかは残しておいた方がよいと思います。
FDEでも解決できないこと
FDEが顧客の現場に入っても、本当の課題が自動的に分かるわけではないでしょう。接する相手が特定部門の責任者だけなら、実際の利用者の問題を見落とすことがあります。大口顧客の事情に引っ張られれば、市場全体では特殊な要求を一般化してしまうかもしれません。
FDEの権限が強すぎれば、営業経由の個別要望がFDE経由の個別開発に置き換わるだけです。現場での速さが優先されすぎれば、保守性やプロダクト全体の一貫性も損なわれます。顧客との距離の近さは、市場理解の正しさを保証しません。
目の前の顧客にしか使えないものを作り続ければ、事業は受託開発に近づきます。共通機能だけを追い、個々の顧客が成果を出せなければ、顧客不在のプロダクト開発になります。顧客成果と製品への共通化の間を往復できることに、FDEの価値があります。
顧客の声は、答えではなく入り口である
顧客の声は重要です。ただ、それを聞くことと、そのまま従うことは違います。
顧客の発言には、その人の立場、業務、組織、調達条件、目の前の制約が含まれています。その文脈を失った声が「市場要求」に変わり、社内の議論を止めるようになると、企業は自分で市場を解釈し、製品の方向を決める力を失っていきます。
FDEだけでこの問題が解けるほど、話は単純ではないでしょう。それでも、顧客の声を現場で仮説として検証し、個別案件の学びを製品として共通化するかどうかの判断へ戻すところまで、一つの仕組みにした点には見るべきものがあります。
顧客の声が麻薬になるのは、それを判断の材料ではなく、答えとして使ったときです。顧客の声は、あくまで顧客を理解するための入り口です。
その声をもう一度仮説へ戻し、現場で作り、結果を確かめ、学びを組織へ戻す。FDEは新しいエンジニアの名前というより、この流れを企業の中に組み込むための発明だったのだと思います。
参考資料
Palantir Technologies, Forward Deployed Software Engineer – US Government
Palantir Technologies, Who Wants to be a Delta?
Palantir Technologies, Dev versus Delta: Demystifying engineering roles at Palantir
Palantir Technologies, Annual Report on Form 10-K for the fiscal year ended December 31, 2025
OpenAI, Forward Deployed Engineer – Tokyo
Gergely Orosz, What are Forward Deployed Engineers, and why are they so in demand?
コメント