ケプラーにおけるフォワードデプロイエンジニアリングの実践

ケプラーの「フォワードデプロイエンジニアリング」：現場に浸透し、製品戦略を創る実践法

「フォワードデプロイエンジニアリング（FDE）」は、単なる営業支援やカスタマーサクセスの一環ではありません。これは製品チームの物理的な拡張であり、顧客の現場に深く入り込むことで真の問題を発見し、それを製品戦略へと転換させる重要なプロセスです。

本記事では、Palantir や Citadel での FDE 実践を経て現在ケプラーでこの機能を構築しているエンジニアが語る、現場観察から製品開発へ至る具体的な手法と、その背後にある「製品戦略としての FDE」の核心を解説します。

FDE は営業機能ではなく「製品戦略」である

フォワードデプロイエンジニアリングという用語は軍事用語に由来し、ソフトウェアを最も過酷な環境（戦場など）に展開して現実に即した形で動作させることを意味します。Palantir においてこの概念が生まれた背景には、2013 年頃の「Phoenix」という大規模データストレージプロジェクトの失敗がありました。

当時、チームは顧客との対話を一切行わず、完璧な環境下でのみ動作するシステムを設計しました。しかし、実際の金融機関のデータは不完美であり、欠損値がデフォルトで「1970 年 1 月 1 日」に設定されるなどの現実的な問題が発生。その結果、サーバー起動に必要な RAM が 14TB に達し、システムは即座に崩壊しました。

この失敗から得られた教訓は明確でした。「顧客がどう使っているか」を知るだけでなく、「顧客と共創する責任」を持つために、エンジニアが現場に直接埋め込まれる必要があるという点です。

「FDE の第一の真実は、これは役割（ロール）ではなく製品戦略である。何を構築するかを発見するレンズとして FDE を用いるのだ。」

つまり、FDE は営業活動や契約獲得のためのツールではなく、製品機能を拡張し、市場で何が本当に必要かを発見するための戦略的機能なのです。

現場への物理的浸透が「真の問題」を暴く

顧客からの要求文書（RFP）や仕様書に頼るだけでは、真の課題は見えてきません。FDE の最大の強みは、エンジニアが顧客のオフィスや現場に足を運び、彼らの日常業務を直接観察することにあります。

ある物流会社の事例では、営業担当者が作成した 47 ページにも及ぶ要求文書に基づき、3 ヶ月かけて大規模な BI ダッシュボードを開発する計画が進んでいました。しかし、現地のオペレーション責任者に「月曜日の朝、まず何をするのか？」と尋ねたところ、答えは「トラックが遅れているか確認し、新しい在庫を発送するよう指示を出すこと」だけでした。

この単純なタスクを解決するには、大規模なダッシュボードなど不要です。わずか 4 時間で Slack のアラート機能を実装すれば十分だったのです。顧客が提示するのは「解決策の提案（例：巨大なダッシュボード）」であり、FDE はその背後にある「真の問題（トラックの遅延確認）」を特定し、即座に最小限の解決策を提供します。

「問題解決が 1 日以内で可能なら、製品戦略として拡大せず、すぐに構築してリリースし、ループを閉じるべきだ。」

この「小さくても確実な解決」が顧客との信頼関係を築き、より本質的な課題へのアクセス権を得る鍵となります。

「行動」こそが最も価値のあるインサイトである

言語による説明よりも、現場での観察（アクション）の方がはるかに多くの情報を教えてくれます。あるデータ品質エンジニアが「Parquet 形式への移行に強く反対し続けた」事例があります。彼女は Parquet が使いにくいと主張しましたが、その理由を聞き出すことはできませんでした。

しかし、チームが現地に赴いて彼女の作業を直接観察した結果、真の理由は明らかになりました。彼女は手動で CSV ファイルをダウンロードし、Windows でダブルクリックして中身を確認していたのです。Parquet 形式にはネイティブのビューアがないため、この確認作業ができなかったからです。

その夜、チームは Parquet ビューアーを即席で作成しました。翌々日には顧客が移行に同意し、データ処理時間は 17 時間から 2 時間に短縮され、コストも大幅に削減されました。

FDE が現場で観察すべき「問題の兆候」は以下の通りです：

• 反復作業: 同じタスクを毎日、毎週、あるいは数時間ごとに繰り返している場合
• ツール間の移動: コピー＆ペーストや、異なるツール間での手動転送
• 感情的な反応: 「〜しなければならない」という不満や、イライラした様子
• スマホの持ち出し: ソフトウェアの処理待ち時間にスマホを操作する行為

これらの行動は、顧客が「明日を今日より良くしたい」と願う瞬間です。FDE の役割は、そのような現場の声を拾い上げ、製品に統合することにあります。

言語定義とナラティブ制御による信頼獲得

顧客組織内では、「カスタマー」「クライアント」などの用語が混在し、認識の齟齬が生じることがあります。FDE は単なる技術者ではなく、共通言語を定義する役割も担います。

また、現場で即席で作られた解決策（ハック）は「一時的な応急処置」ではなく、永続的な製品機能へと昇華される可能性があります。重要なのは、その解決策が誰によって定義され、誰が責任を持つのかを明確にすることです。

「問題を定義した者が、解決策も所有する。」

FDE が現場で小さな課題を解決し、ナラティブ（物語）を制御することで、製品チームは顧客の真のニーズに基づいた方向性を決定できるようになります。これが「Foundry」のような汎用プラットフォームが誕生した背景です。

まとめ：顧客にとって不可欠な製品を作るために

フォワードデプロイエンジニアリングの本質は、営業やサポートの延長ではなく、製品開発そのものを現場に根ざさせる戦略にあります。顧客の表面的な要望に耳を傾けるのではなく、彼らの日常業務に深く入り込み、反復作業や不便さという「行動」から真の問題を見出すことが重要です。

このアプローチにより、企業は顧客の深層にある課題を特定し、それを製品に統合することで、単なるツールではなく顧客にとって不可欠な存在へと進化させることができます。