「越境前提だからこそ、やりがいがある」Sansan瀬戸さん|FDEの走り書きのトップ画像

「越境前提だからこそ、やりがいがある」Sansan瀬戸さん|FDEの走り書き

投稿日時:
瀬戸 博則のアイコン

Sansan株式会社 / 技術本部 CTO室 AI Solution Development 兼 Sansan事業部 プロダクト室 AIイネーブルメントグループ マネージャー

瀬戸 博則

AI時代に新たな職種として注目を集める、Forward Deployed Engineer(FDE)。本連載「FDEの走り書き」では、不確実性の高い現場を走る当事者たちの、今だからこそ語れる試行錯誤を追いかけます。

今回はSansan株式会社の瀬戸博則さんに、FDEの役割や課題・やりがいを綴っていただきました。


はじめまして、Sansan株式会社の瀬戸博則と申します。

SIer、事業会社、広告代理店を経て、データ分析基盤の構築、データマネジメント、データ利活用推進に従事してきました。現在は、Sansan AIエージェントというプロダクトにおけるFDEチームを管掌しています。

本稿では、SIer・コンサル・事業会社を横断してきた立場から、SansanにおけるFDEとその組織について紹介します。

コンテキストの正確さで差別化する「Sansan AIエージェント」

Sansan AIエージェントは、営業現場の業務プロセスに「溶け込む」ことを設計思想に据えたAIエージェントです。

商談前の準備、商談後のフォロー、ナレッジの引き出しといった営業活動のタスク単位で動き、ユーザーの状況に応じて必要な情報を提示します。利用者はエージェントとの対話を通じて、個社固有のドメイン知識を蓄積できます。社内メンバーを育てるように、エージェントの振る舞いを磨いていける点が特徴です。

このプロダクトの土台にあるのは、Sansanが長年積み上げてきた4つのアセットです。

  • 名寄せ技術による企業データの統合
  • 名刺・商談・企業データの蓄積
  • 営業領域に根差したドメイン知見
  • 業務フロー × データ × AIを一体で設計・実装できる体制

これらに個社の業務データを掛け合わせることで、個社の背景と状況に則した出力が可能になります。

汎用LLMや他SaaSと違うのは、自社で名刺・商談・企業データと名寄せ基盤を持っている点です。「コンテキストの正確さ」を支えるデータと技術が手元にあるため、AIの推論性能そのものではなく、業務インパクトで差別化できます。これが他社にはない強みになっています。

越境前提の3ロールに分けたチーム構成

Sansan AIエージェントのFDEは1人ですべてを担うのではなく、ケイパビリティによって主軸を分けてチームを組んでいます。具体的には次の3区分です。

  • DS(Deployment Strategist): アカウントマネジメント、プリセールス、顧客業務課題のヒアリング・整理、ソリューション提案を担当
  • FDE:顧客のビジネス要件・データ要件を捉え、プロダクトの個社カスタマイズ・実装・現場での定着支援を担当
  • プロダクト開発:データ連携、エージェントワークフロー、ナレッジ管理システムなど、横展開可能な共通機能の実装を担当

まずDSが顧客の暗黙知の言語化、解くべきビジネス課題の特定、AIエージェント活用のグランドデザイン策定を行います。そのグランドデザインをFDEが実装と定着まで運び、プロダクト開発に還元していきます。

3つのロールに分けている理由は、得意領域の深さが違うからです。FDEは個社業務を深掘りし、プロダクト開発は再利用性を抽象化し、DSはビジネスとプロダクトの境界を行き来する、というように深さの方向が分かれます。

ただし責務を線で切ることはしていません。FDEが顧客対応で気づいた課題は次のプロダクト機能や改修のタネになりますし、プロダクト側の技術制約が提案内容に影響することもあります。そのため、役割を分けつつも越境を前提にしたチーム設計にしています。FDEがプロダクト機能開発に手を入れることもありますし、プロダクト開発担当が顧客のチャットに入り実装相談に乗ることもあります。

具体的な業務例はテックブログでもご紹介しております。*1

FDEの価値は、高速イテレーションとプロダクト還元

FDEが価値を出すうえで重視している点は2つあります。

1点目は、知識移転ロスを発生させない高速イテレーションです。要件定義と実装を行き来する際に、別の人にバトンを渡し直さない設計にしています。

2点目は、個社案件のナレッジを基盤やプロダクトに還元することです。個社の課題解決とプロダクト全体の進化を、両立させる前提で動きます。

こうした価値を発揮する上で、求められるスキルセットは大きく3点です。

  • Webサービスやデータモデリングの実装経験(Python/SQL/API連携、データ操作)
  • 営業プロセスや顧客業務への理解(業界知識、現場の意思決定構造の把握)
  • ストラテジストとしての姿勢(受託でも純粋なコンサルでもなく、プロダクト価値を最大化する立ち位置)

現メンバーのバックグラウンドは大きく2系統に分かれます。ITコンサル、もしくはB2Bソリューション営業の経験が豊富な方。または、Webアプリ開発やデータエンジニアリングを軸に持ちながら、ビジネスへの強い関心を持つ方です。越境前提の設計なので、入った時点で両方を完璧に持っていなくても大丈夫な組織設計になっています。

自身の経験から振り返る、SIer・コンサルとの違い

ここまで読んでくださった方の中には、「SIerやコンサルとFDEとの違いは何か」が気になる方もいると思います。私がSIerやコンサルとして働いた経験を踏まえて、大きく違うと考えているのは「アウトカムへのコミット先」と「プロダクト還元の有無」の2点です。

挿入画像/Sansan FDEの走り書き.jpg

Sansan AIエージェントのFDEは、プロダクトをベースにラストワンマイルを埋めるところまでが仕事の輪郭です。PoCで終わらせない、納品で終わらせない、利用定着のメトリクスが動くまで伴走する。これが基本姿勢になります。一方で、コンサルやSIerで働いていた時は、あらかじめ定められた契約のゴールがありました。

さらに決定的な違いは成果物の納品後だと感じています。FDEというポジションでは、個社対応で得た知見をプロダクトに還元することを前提にしているからです。

ある顧客で必要だったプロンプトのパターンや業務ユースケースが他の顧客でも使える形であれば、次の案件ではFDEが介在しなくても同じ結果が出せるように、プロダクト側で吸収しています。事業をスケールさせるために、プロダクトの進化を主目的に据えているのです。

もちろんプロダクトで吸収せず、社内向けフレームワークや共通部品で吸収する方法もあります。ただ、そのやり方は属人化やドキュメント陳腐化を招きやすく、再利用率が下がることも少なくありません。

だから我々は、個社対応で抽出した型を「フレームワークや共通部品」ではなく「プロダクトの機能」として実装し、全顧客に同じ進化を届ける形を目指しています。

こうしたやり方に、1人のエンジニアとして大きなやりがいを感じています。自分が個社案件で培ったノウハウやユースケースがSansanのプロダクトに残り、他の顧客にも横展開されていきます。つまり一過性のカスタマイズで燃え尽きるのではなく、自身のキャリアとともにプロダクトの成長として蓄積されていくのです。

曖昧さや不確定さを定義する、FDEの難しさ

ここまで強みと違いを語ってきましたが、当然ながら難しさも抱えています。

1つ目の課題は、どこまでを個社対応に留め、どこからをプロダクト機能として抽象化するかの判断です。

FDEが個社案件に入り込むほど、顧客の深い課題にアプローチできる一方、意識していないと「すべて個社のための実装」に陥りがちです。個社カスタマイズが多すぎるとプロダクトとして進化せず、事業のスケールがヘッドカウントに強く依存する構造になってしまいます。このボーダーラインは日々議論しながら試行錯誤しているところです。

2つ目の課題は、顧客自身がまだ言語化できていない課題を、FDE側から先回りして定義し、解決策として提示することの難しさです。

AIエージェント活用の現場では、顧客から出てくる「やりたいこと」が、そのまま解くべき課題とは限りません。「商談準備を効率化したい」「ナレッジを整理したい」というニーズの背後には、本当の業務ボトルネックや意思決定の歪みが隠れていることが多くあります。

FDEに期待されているのは、顧客の言葉をそのまま要件化することではなく、業務観察と仮説検証から本質的なペインを定義し、それに対する解決策を提案することです。要件が出てくるのを待つのではなく、こちらから踏み込んで「解くべき課題はこれです」と仮説を当てに行く動き方が必要になります。

ただし、この取り組みは顧客の期待値とのギャップを生むこともあります。なぜなら、時に営業の最前線で業務している担当者やキーパーソンを巻き込むなど、顧客側の時間割り当てや調整も必要であるため、「ここまで言語化する必要があるのか」「もっと簡単にできると思っていた」というご反応をいただくことがあります。

この心理的ギャップを埋めるため、重要課題の1つを早めにプロトタイプとして見せて共通認識をつくることや、2〜3日にまとめて合宿形式の言語化セッションを実施して短時間で深く入るといった工夫で、価値体感サイクルをなるべく短くするようにしています。

また3つ目には、課題というより組織の伸びしろとして、1案件あたりのFDE工数を半分にしたいのですが、まだ道半ばです。プリセールスの型化、ベース機能の拡充とフィードバックサイクル、オンボーディングの効率化を並走させていますが、ここの仕組み化に手を動かせる人材はまだまだ足りていません。

SIerやコンサルの次のキャリアに、FDEという選択肢を

ここまで読んでくださった方の中には、SIerやコンサルでの経験を踏まえた「次のキャリア」を考えている方もいらっしゃるのではないでしょうか。

FDEは、ビジネス貢献も意識しつつ、開発も自分で進めたいエンジニアにフィットするロールです。例えば「商談前準備」のユースケースであれば、顧客業務の要件整理から、社内データソースとの接続設計、プロンプトとワークフローの調整、現場での定着支援までを一気通貫で担います。提案だけでもなく、実装だけでもなく、定着までを地続きで担当できるのがFDEの面白さです。

プロダクトをつくるだけの仕事に物足りなさを感じる方、顧客提案だけの仕事に開発の手応えを求めたい方、固定された分業に「もっと越境したい」と感じている方には、私たちの環境と親和性が高いと思います。

越境前提のチーム設計なので、最初から技術とビジネスの両側を完璧に持っている必要はありません。主軸のケイパビリティで入っていただき、隣接領域は走りながら身につけていけます。前職で身についた業務理解や開発スキルが、Sansan AIエージェントというプロダクトの進化にダイレクトに残っていく喜びを感じていただけると思います。

少しでも関心を持っていただけたら、Findyの求人ページからご連絡ください。具体的な役割や働き方について、お話しできればと思います。

Loading...Loading...Loading...

*1 ビジネス・データ・現場の全てを理解する。Sansan AIエージェントFDEという仕事(Sansan Tech Blog)