技術力は上がっている。任されるスコープも広がった。それでも、どこかで成長の天井にぶつかっている――。そのような感覚を味わったことはありませんか？
連載「技術の“先”を聞きに行く」では、技術力の前に立ちはだかる壁を超えたエンジニアに、その感覚をどう突破したかを聞きに行きます。
第3回は、SalesforceのニューヨークオフィスでFDE(Forward Deployed Engineer)として活動する深田 紘平(@koheifukada)さん。アメリカで働くことを目標にセールスフォース・ジャパンへ新卒入社し、プリセールス、プロダクトマネージャーと同一企業内で職種を変えながら、4年目で米国Salesforceのニューヨークオフィスへの異動を実現。そこからさらに、FDEへとロールチェンジを果たしています。
「製品のことは理解しているつもりだった。しかし現場に入ってみて、それが思い込みだったと気づいた」という深田さん。FDEという職種が生まれた国で、今まさに壁を乗り越えているエンジニアは、技術力の“先”に何を見ているのでしょうか。
FDE発祥の地で、立ち上がり期のプロダクトを届ける
── 日本ではFDEへの関心が急速に高まっていますが、実態がまだよくわからないという声も多いです。SalesforceにおけるFDEとは、どのような役割なのでしょうか。
Salesforceの公式なFDE組織は、「Agentforce」のリリース直後に立ち上がりました。AIエージェントの企業導入には、極めて高い技術力を持ってお客様の組織に深く入り込む、従来とは根本的に異なるサポートモデルが必要だからです。
さらに現在、AI市場そのものが急速に動いています。音声、マルチエージェント、MCP、コーディングエージェントといった新しい技術が次々と登場し、エージェントの上にさらに高度なイノベーションが乗るフェーズに入りました。そうした中で、FDEの仕事も、導入を広げたり目の前の課題を解決したりすることに加えて、現場で見えた課題や学びを、より早くプロダクトに返していくことの重要性が増していると感じています。
FDEは製品開発チームと密に連携しており、お客様の現場で直面した製品上・エンジニアリング上の障壁をリアルタイムで共有し、解消につなげていきます。それだけでなく、お客様からのリクエストを単なる個別要望として受け取るのではなく、製品としてどこまで標準化できるかという問いに変換して届けることで、プロダクトそのものの進化を後押しする役割もあります。
── FDEは、企業によっては顧客先に常駐するイメージがありますが、Salesforceではどうですか。
基本的に、顧客先に常駐はしていませんが、お客様とは定期的なミーティング等で深くエンゲージしています。プロジェクトにはしっかりリソースを割きますが、チームとしてはリモートが標準です。私自身は週2回程度SalesforceのNYオフィスに出社しています。
一方、キックオフなど必要なタイミングではお客様と直接お会いすることもあります。たとえば先週は、Salesforceのシカゴオフィスで2日間のワークショップを対面で実施しました。こうした現場での動きはプロジェクトの状況次第で変わります。
普段は、Deployment StrategistとFDEがペアになってプロジェクトを進めています。日々のお客様とのやり取りはこのペアが中心で、大きなワークショップになるとセールスやプロダクトの担当者も加わる形です。
1日の時間配分としては、お客様と社内FDEチームとのミーティングが半分、自分で手を動かして開発やテストをする時間が半分、というイメージです。ただ、それだけではなく、最新のAgentforce機能やロードマップを技術レベルでキャッチアップしたり、他のAI企業と情報交換をしたり、イベント登壇したり、現場で見つけた課題を製品開発チームに還元する動きも日常的にあります。
── 開発から製品開発チームへの還元まで、守備範囲がかなり広いですね。SalesforceにおけるFDEのオンボーディングはどのような仕組みになっていますか。
「Ready in SIX」というオンボーディングプログラムがあります。6週間で現場に出てプロジェクトに貢献できる状態になる、という設計です。
最初の2週間は、Salesforceのプラットフォームやエージェント、AIの技術をインプットする期間です。次の2週間は実習で、世界各地から50人以上が一つのオフィスに集まり、学習成果の集大成となる実践的なプロジェクト（Capstone Project）をチームで解いていきます。最後の2週間は、学んだことの振り返りと、先輩FDEの実際のプロジェクトに同行して現場を体験する期間です。
世界各地から研修で集まったFDEメンバー
── 6週間は手厚いですね。どのように顧客の業界知識をキャッチアップしていますか。
私は金融やヘルスケアといった規制業界の顧客を担当していますが、業界特有の用語もわからないし、米国と日本ではルールや仕組みがまったく違う。最初は本当に苦労しました。そこで一番効果的だったのが、お客様のAIエージェントを紐解くことです。エージェントに与えられた役割、ツール、ガードレール、データを見れば、その企業が何を自動化しようとしていて、何を人間の判断に残しているかが一目でわかります。インストラクションは自然言語で書かれているため、業務フローと業界・顧客特有の言語がそのまま落とし込まれているんです。
その中でも、テストが最大の学びの場ですね。テストを設計するには、このエージェントのゴールは何か、何をもってリリースできるのかといった業界基準の理解。エンドユーザーが実際に何を聞き、何を達成したいかというユーザー理解。そしてエージェントにどんなデータやAPIが必要か、どのエッジケースで壊れるかという技術的な把握。これらすべてを理解しなければなりません。テスト戦略の設計からレビューまでの過程が、そのままドメイン知識の獲得につながりました。
── FDEが現場で最初に向き合うのは、どのような課題ですか。
お客様はご自身のビジネス課題を一番よく理解されていますから、課題がすでに明確な状態で、FDEがアサインされます。
一方で、お客様が把握しきれないのが、その課題を解決するための具体的な方法やSalesforceのプラットフォーム特有の技術的な制約や特性です。既存のシステムをAgentforceに置き換えようとした際に、どこに技術的なブロッカーがあるのか。それを現場で最初に発見し、解決策を設計していきます。
さらに、現場で見つけた課題を個別案件としてではなく、製品の問いとして捉え直すことも重要です。どこまでを標準化し、どこからを個別に設計すべきかという、という視点ですね。顧客に深く入るほど本当の課題は見えてきますが、個別対応に寄りすぎるとスケールしない。そのトレードオフを現場で見極めることも、FDEの仕事の難しさだと思います。
動かしてみて「わかっていたつもり」だったと気づいた
── 深田さんはセールスフォース・ジャパンでソリューションエンジニア（プリセールス）、プロダクトマネージャーと経験を重ねた後ニューヨークに移り、さらにFDEへと転じました。なぜFDEという選択をしたのでしょうか。
日本でプロダクトマネージャーとしてやっていたのは、新機能を日本市場に適応しリリースすることでした。Einstein GPTの立ち上げに携わり、SalesforceのCEO・CTOとともに発表する機会もありました。製品への理解には自信がありましたが、いただいたフィードバックを実装に落とし込んでいく過程で、技術的な課題の深いレベルにまであまり踏み込めなかったんです。
セールスフォース・ジャパンで約3年間プロダクトマネージャーを務めた後、念願だった米国SalesforceのニューヨークオフィスのAI製品開発チームに移ることができました。キャリアの目標にしてきた夢が一つ叶ったタイミングでした。
ところが、本社で1年半ほど過ごす中でAIエージェントの時代が到来。お客様の業務やシステムのあり方が大きく変わる中で、エンタープライズの本番環境で本当に動き、価値につながるものは何かを、現場で技術的なレベルで把握しなければ、良い製品は作れないと感じるようになりました。ちょうどその頃、SalesforceがFDE組織に投資するアナウンスがあり、社内公募を通じてFDEに移ることを決意したんです。
── 実際にFDEになってみて、技術への向き合い方は変わりましたか。
向き合い方というよりも、技術の使い方が職種によって大きく異なると感じています。
ソリューションエンジニアの頃は、デモンストレーションが動いて実現可能性を示せればよく、レイテンシーやデータボリュームまで気にする必要はありませんでした。プロダクトマネージャーの時は、エンジニアとアーキテクチャについて会話したり、経営層やイベント用に見せるモックデモを迅速に作成したりするために技術を使っていました。
一方、FDEに求められるのは、特定のお客様の本番環境で実際にスケールして動くものを作ることです。プロダクトマネージャーの頃は「このAPIを使っています」という粒度で十分だったのが、FDEではそのAPIの中身を細かく理解し、どの項目をエージェントに組み込むべきか、データボリュームはどれくらいかまで把握しなければならない。製品として理解することと、顧客の本番環境でシステムとして成立させること。その差は想像以上に大きかったですね。
──具体的にどういう差を感じましたか。
それまで製品のことは理解しているつもりでした。でも、FDEとして現場に入ってみて、それが思い込みだったと気づきました。製品の特性や制限、お客様が抱えている技術的な制約など、動かしてみないとわからないことばかりだった。お客様のシステムで実際に構築し、データをつなげ、APIをインテグレーションし、テストしてみて、初めて見えてくるものが本当に多いのです。
AIと聞くと、モデルやプロンプトの層にフォーカスしがちですが、エンタープライズレベルで動かすとなると、その上のインターフェース、さらにデータ統合、API連携、テストや監視と、カバーすべき領域が一気に広がります。すべての領域に精通する必要はなくとも、レイヤー間のつながりは理解しなければならない。今まさに、そこに壁を感じています。
── 直面している課題はテクニカルな部分だけですか。
いえ、課題はテクニカルなところだけでなく、お客様のマインドセットにもあります。
たとえば、エージェントの精度を測る際に、一つひとつの応答に対する「良い/悪い」のフィードバックだけに固執してしまうケースがあります。しかしエージェントは、複数回のやり取りを通じて一つの目的を達成するものです。マルチターンでの評価と継続的な改善が必要だということを、技術的な根拠とともに毎回のミーティングで伝え続けなければなりません。
技術を動かせるだけでは、お客様は動かない。FDEになって初めて向き合った、技術の先にある壁だと感じています。
── その壁をどう越えようとしているのか、知りたいです。不安はありませんか。
これまでのキャリアでも、研究、マーケティング、開発などさまざまな角度でAIに関わってきたので、技術そのものへの不安はありません。ただ、それをすべて実装して顧客に届けるという経験はまだ少なく、正直不安はあります。
一方で、一人でやっているわけではないので、わからない領域があれば詳しいメンバーがフォローに入ってくれます。自分としては、他のチームが作っているAPIやエージェントのコードを見に行って、AIコーディングツールで構造を理解したり、テクニカルな質問を準備・整理してミーティングに臨んだりしています。
壁に直面したときに一番大事なことは、何かしら自分のアウトプットを出すことです。小さくても動くものを作る、技術仕様を書く、プロトタイプを作る。自分なりのアウトプットを出してフィードバックをもらう。そのサイクルで、少しずつ壁の向こう側が見えてくる感覚があります。
日本にいた頃にも、まだ市場に根付いていない新しい製品を手探りで導入していく経験がありました。それがFDEとしての今の動き方にも活きていますね。
小さなアウトプットを起点に、プロダクトが進化する
── 「小さくてもアウトプットを出すのが大事」とおっしゃっていましたが、その実践から生まれたものはありますか。
社内ハッカソンで作った「Greenlight」というツールがあります。
きっかけは、最初にアサインされたプロジェクトでした。FDEの仕事の中核に、お客様が構築したエージェントが本番環境にリリースしても問題ない品質かどうかを判断し、Go/No-Goのサインを出すという工程があります。社内での判断だけでなく、お客様側でも承認を得る必要がある、非常に重要なプロセスです。
SalesforceにはTesting Center（テスト実行機能）が用意されていますが、何をどうテストすべきか、何をもってGoなのか、No-Goなのかという判断は、ツールに頼れません。毎回6時間のマニュアル作業で、しかもどのプロジェクトでも必ず直面している。全員が同じ壁にぶつかっていたのに、誰もそれを「解くべき課題」として定義していなかったんです。そこで、このテスト戦略の自動化をハッカソンのテーマとして持ち込むことにしました。
Agentforce Vibes、CursorやClaude Codeを使い、テスト戦略の策定、戦略に基づくデータセットの自動生成、Testing CenterへのAPI連携による実行、そして100件・200件・300件と出てくるテスト結果のAIレビューまでを一気通貫で自動化するツールを構築。テストプロセスを6時間から15分に短縮できたことも良かったですが、個別案件で得た知見を、そこだけで閉じず、次の案件でも効く形に変えられたことが価値でした。
── ハッカソンの後、どのように広がっていったのですか。
ハッカソンには60のアイデアが集まりましたが、その中からリーダーシップが選んだトップ10に入りました。さらにFDE全員による投票でも選ばれ、サンフランシスコ本社でのBuild Sprint——5つのチームが集まって、本番レベルのツールに仕上げる合宿のような場に招待されました。今ではGreenlightに社内の全FDEがアクセスできる状態になっています。
そこからさらに、製品開発チームとも連携しています。実は製品開発チームも、Agentforceの開発ライフサイクルを加速させる“agentforce-adlc”というスキルを作ろうとしていたんです。Greenlightの存在を共有して、彼らのオープンソースに貢献すべく協業し始めています。
製品チームと開発しているAgentforceの開発スキル
Salesforceには「カスタマーゼロ」という考え方があり、お客様に提供する前にまず社内で製品を使い込む文化があります。現場で生まれたツールがプロダクトそのものの進化につながっていくのは、この文化があるからだと思います。
── FDEの仕事は、お客様の課題を解くだけでは終わらないということでしょうか。
はい。プロダクトへのフィードバックもFDEの重要な仕事です。
フィードバックには大きく2つのレイヤーがあります。一つは、現場のプロジェクトをよりスムーズに進め、他のお客様にも価値を広げやすくするための、機能改善・仕組み化レベルのフィードバックです。
もう一つは、「これがなければプロジェクト自体を継続できない」「FDEとして継続的に投資できない」といった、製品戦略やインフラ基盤、開発リソース配分に関わるレベルのフィードバックです。
前者については、現場のFDE一人ひとりでも改善に貢献できます。たとえばGreenlightのような取り組みはその典型です。
一方で後者は、個別案件の中で一人のFDEが判断するものではありません。複数のプロジェクトから見えてきた共通課題として、リーダー陣とともに優先順位を決めていく領域になります。
特に前者については、現場で得た学びを短いサイクルで改善につなげやすいのが、このSalesforceの大きな魅力です。SalesforceやSlackのように、すでに数千・数万人のユーザーが使っている基盤の上にエージェントを展開できるので、リリース直後からリアルなフィードバックが返ってきて、すぐに改善できる。このサイクルの速さは、ゼロから構築する場合には得られないものだと感じています。
作れる力の、その先にあったもの
── 深田さんの周囲で「この人はすごい」と感じるFDEは、どんな方ですか。
何人かいます。もちろん技術力があることは前提で、新しいイノベーションへのキャッチアップが早く、裏側の技術も理解している。
ただ、それだけではなくて、新しいツールを使って自分でガンガン手を動かしながら何かを作れる。大きなプロジェクトにも入れるし、イネーブルメント（社内の教育・育成活動）にも呼ばれる。Slackチャンネルでもユースケースを積極的にシェアしたり質問に答えたりしている。技術だけではなく、それを使っていろんな場所で活躍できる人は、本当に力のある人だと感じています。
── そう聞くとスーパーパーソンのように感じてしまいますが、実際にそのレベルが求められるのでしょうか。
スーパーパーソンかと言われたら、そんなことはありません。プロジェクトに入ると全員でカバーするので、一人ひとりが担当する領域は実は結構小さいんです。コンサルテーション力と技術力とチームワークがあれば、プロジェクトの中で価値を出すことは十分できます。
一方で、プロジェクトを超えて組織全体にインパクトを出すとなると、また別の力が求められます。先ほどのGreenlightのような取り組みがまさにそうですね。
── FDEを経験して、「技術力」という言葉の意味は変わりましたか。
大きく変わりました。「壊れてもいい」というマインドセットが必要だと感じています。完璧なものが最初から動くわけではない。まだ誰も答えを知らない新しいユースケースや新しい技術に飛び込んで、お客様と一緒にプロダクトを育てていく。エージェントを壊すためにテストする。その柔軟性が求められます。
しかも、2〜3年常駐するような形ではなく、短い時はプロジェクトベースで1〜2か月で作って完了するスピード感です。そのレベルで素早く動かないと、製品も完成しないし、競合にも負けてしまう。
加えて、コードを書くことそのものの希少性は、確実に下がっています。一方で、何を良しとするか、何を標準化し、何を個別対応として引き受けるかを判断する力の希少性は、むしろ上がっている。AIによってできることが増えたからこそ、エンジニアには「どう作るか」だけでなく、「誰のどんな問題を、どの解像度で解くべきか」を見極める力が求められるようになっていると感じます。
AIが出す膨大なアウトプットの中から、本当に良いものを選び取る力。米国ではそれを「Taste」と呼んでいます。何が良いかという高い判断基準を自分の中に持ち、複数の選択肢から選び取る力のことです。生まれつきのセンスではなく、現場で判断を重ねる中で鍛えられるものだと考えています。
── 最後に、技術力の壁にぶつかっているエンジニアに向けて、メッセージをお願いします。
できないことが10個あったときに、何をどの順番でできるようになるのか、何はできなくてもよいのかを、自分で整理していくこと。それが大事だと思います。これはプロダクトマネージャーとして動いていた時にもらったアドバイスですが、技術力に限らず、変化の大きい環境で成長していくうえで普遍的に重要な考え方だと感じています。
私自身、米国に移るまでにも数年かかりましたし、途中で難しいと感じたことも何度もありました。それでも、自分に足りないものを整理し、一つずつ向き合っていく中で、結果として道が開けていきました。また、出張の機会などを使って自分の関心や挑戦したいことを伝え続け、機会は待つのではなく、自分から取りにいくことを意識してきました。
もう一つ大事だと思うのは、良いものに触れ、それの何が良いのかを自分の言葉で言語化していくことです。私はもともと純粋なソフトウェアエンジニアではなく、「いい製品を届けたい」という関心が先にあって技術を身につけてきた、プロダクト寄りのエンジニアです。いくつかの職種をまたいで仕事をしてきたからこそ感じるのは、特にAIの進化以降、職種の境界は以前より薄くなっているということです。今はFDEやエンジニアやプロダクトマネージャーといった肩書きに自分を閉じ込めるよりも、今できないことを一つずつできるようにしながら、より良いものを作れる人になることの方が大事だと思っています。
技術を磨くことはもちろん大前提ですが、その先では、誰のどんな課題を解くのか、何を作るべきかを判断する力も問われます。良いものに触れ、その良さを言語化することの積み重ねが、そうした判断基準をつくっていくのだと思います。技術の天井にぶつかっていると感じるなら、それは成長が止まったのではなく、「作れること」の次のステージに進み始めているサインなのかもしれません。
