顧客の成果創出とプロダクトの成長を 両立するためのFDE 2026.09.28 Sansan株式会社 技術本部 CTO室 AI Solution Developmentグループ 田代 大也 

田代 大也（Hiroya Tashiro） Sansan株式会社 CTO室 技術本部 AI Solution Developmentグループ ▼現職 ・2025.07入社 ・「Sansan AIエージェント」におけるFDEを担当 ▼前職 ・株式会社D2C (当時NTTドコモ・電通等によるJV／現在CARTA HOLDINGS傘下) ・データサイエンティストとして広告関連の分析やBIの提供など ・クライアントワークもこのときに経験 

会社概要 社名 Sansan株式会社 設立 2007年6月11日 従業員数 上場証券取引所 拠点 2,077名（2026年5月31日時点） 東京証券取引所 プライム市場 本社：東京都渋谷区桜丘町1-1 渋谷サクラステージ28F 関西支店、福岡支店、中部支店 サテライトオフィス グループ会社 Sansan神山ラボ、Sansan Innovation Lab、Sansan長岡ラボ Sansan Global Pte. Ltd. （シンガポール） Sansan Global Development Center, Inc. （フィリピン） Sansan Global (Thailand) Co., Ltd.（タイ） ナインアウト株式会社 株式会社言語理解研究所 Eightキャリア株式会社 

Sansan株式会社の働き方を変えるAXサービス 生産性を向上させ、企業のAI活用を最大化するデータベースとしても貢献できる 「働き方を変えるAXサービス」を提供します。 法人向け 個人向け 名刺データベースが、収益を最大化する 契約データベースが、利益を守る 「なくせる」をつくり、全社の働き方を変える 営業AXサービス 契約AXサービス 経理AXサービス 名刺アプリ 営業 契約 請求 名刺管理 データクオリティマネジメント 各サービスの活用で変わる働き方 必要な情報を すぐに見つけられる 情報の管理がしやすく すぐに共有できる 情報を分析・活用しやすく データに基づいた判断ができる 

プロダクトSansanにおける「AIサーチ」と「AIエージェント」 Sansanアプリに搭載され、共通のユースケースに対応する「AIサーチ」に対して、 「AIエージェント」では顧客の個社ごとにデータや対応ユースケースなどカスタマイズしてご提供 ・Sansanアプリに搭載 ・FDE・DSが個社にカスタマイズして提供 ・Sansanデータ(名刺・企業情報等)を参照 ・Sansanデータに加えて個社のデータも参照 本日お話しするのはこちら 

本日お伝えすること ①Sansan AIエージェントにおけるFDEの基本的な役割を整理 ②実際の動きを事例でご紹介 ③事例の中で、FDEとしてお伝えしたいポイント ④今後の課題 

Sansan AIエージェントにおけるFDE … 個社対応とプロダクトへの還元 共通機能に対して個社カスタマイズしたものを提供し、個社から得られたFBや知見を基に共通機能として プロダクトに還元する → FDEが起点となってこの流れをつくり、プロダクトの進化を図る ▼共通機能には無かったが、顧客Aのためには必要な機能として実装 ・顧客が導入しているXXという外部ツールとのコネクタ ・チャットUI内でグラフを表示・エクスポート ・特殊な形式の画像ファイルのインポート 共通機能として採用 汎用性が低いので共通化は見送り ・外部ツールXXとのコネクタ ・チャットUI内でグラフを表示・エクスポート ・特殊な形式の画像ファイルのインポート 

基本的な役割のスコープ 個社のための開発をコアとして、プロダクト還元の起点になる。また個社の戦略定義・要件定義について もDS(Deployment Strategist)と共に検討・提案する 個社対応 プロダクト全体 Tech 個社のための開発 共通機能の開発 （FDE） (共通側のエンジニア ・デザイナー・FDE) Biz 個社の戦略策定・要件定義 （DS・FDE） プロダクト全体の戦略策定・要件定義 上記はあくまで典型例。案件のフェーズやその時々の稼働状況によって、実際の対応範囲は変わる →本日は「一例として、こうでした」をご紹介 

ご紹介する事例 1つの具体例として、あるメーカー様でのSansan AIエージェントの事例をご紹介 ・メーカーのお客様 ・対面は営業部門の企画・DX系の領域を担う部署の方々 顧客 ・Sansanに名刺やコンタクト(商談等の履歴)のデータが多く蓄積 ・主にFDE1名がプロジェクトを推進 ・DSやPMがサポートに付く Sansan側の体制 ・既存のSales・CSメンバーとも適宜連携 

プロジェクトの流れ 要件定義、初期構築、検証・現場ヒアリング、本格利用開始、継続改善…の流れ 現在は利用開始の段階で、本日はそこまでの範囲からポイントを絞ってお伝え 要件定義 初期構築 検証・改善 ▼ピックアップしてお伝えすること ①要件定義の進め方と決めたこと ②FDEとしての開発と検証・改善のサイクル ③スコープのコントロール ④プロダクト還元のためのアクション 利用開始 継続改善 

①要件定義の進め方と決めたこと 「蓄積された名刺やコンタクト情報をもっと活用したい」といった温度感から始まることが多い 現在の事業・業務の状況や、経営・マネジメント・現場それぞれの課題を棚卸しから始める ステップ 独立したチャットUIを提供(画像はイメージ) ①組織・営業プロセス・KGI／KPIなど現状を確認 ②KGI／KPIから下ろした具体目標や課題、理想の姿を検討 ③②を達成するためのユースケースの洗い出しと優先度決め ④技術要件を含め詳細化（ここでは一部内容を抜粋・抽象化して記載） ユースケース 参照するデータ コンテキスト・オントロジー設計 ・商品ジャンルが複数に跨るような複雑な 提案の骨子作成 ・価格交渉のための交渉材料の収集 ・日々のマネジメント活動のサポート ・Sansanデータ ・基幹システムからのデータ（取引先マス タ・実績データ・商品データ等） ・過去の商談資料 ・事業や組織の概要 ・経営方針・全社的な方針／目標 ・各部署の詳細や方針／目標 ・商品・商流・業界の知識 この段階ではDS, PMが中心的に稼働した 

②FDEとしての開発と検証・改善のサイクル 必要なデータの接続・モデリング、プリセットプロンプトやコンテキストの構築、その他必要機能を開発 できた部分から対面の部署や一部実際の営業メンバーに試してもらい、FB収集→改善を高速に回す ・データの整備 (システムとの接続／手動インポート、データモデリング等) ・プリセットプロンプトやコンテキスト・オントロジーの構築 ・その他、共通機能に含まれていなかった機能の開発 FDE 内容・状況に応じて ・要件をドキュメント化して 共通側のエンジニアに依頼 ・FDE自身で開発 ・自身で試す ・対面から経営層などへも定期的に展開 顧客の 対面・現場 ・上記からのFBを得る いわゆるオペレーション業務なども含め、ここからはFDEがプロジェクト全体を推進した （案件によってFDE／DSどちらがリードするか異なっている） 

③スコープのコントロール 前ページのサイクルを回す中で、顧客側から様々なFBを得られる。かつFDE側もサクッと作って試してみ たいモチベーションを持つ →結果としてユースケース等のスコープが拡散し、当初達成したいと考えていた目標から逸れてしまうよ うなリスクがどの案件にもある。適宜スコープを調整しながら進行することが求められる ・これできるなら、こんなこともやってみたい ・技術的にはクイックに作れるしやってみる ・これは微妙だから上手くいってる方を優先したい ・前段の再整理が必要なので後回しに・・・ 顧客の 対面・現場 FDE ・その機能・ユースケースの実現は目標達成のために必要か？現場のペインは解決されても成果には繋がるのか？ ・出力が微妙なのはLLMの性能やデータの問題か？そもそも課題に対して必要な出力の要件がずれているのではないか？それを クリアにしつつ引き続き優先して取り組むべきではないか？ FDEが一人でコントロールできることが理想と言うこともできる 一方で、DSが常に全体を俯瞰し、スコープのコントロールに責務を持つことも一つの方法 （この事例では、FDEが自ずからコントロールに動くこともあれば、DS／PMからFDEにツッコミが入ることもあった） 

④プロダクト還元のためのアクション 個社で得られたFBや知見、利用実績を基に、各機能等に対してプロダクトとしての共通化を検討する 共通化に際して汎用性はもちろん、他の顧客に対しても機能導入によるROIが見込めるかで判断される ・共通化の余地がある内容についてドキュメント化 ・具体要件に加え、想定するインパクト、また個社で先行して開発した 場合はその実績などを整理 ・起票後、共通側のエンジニアのレビューなどから内容をブラッシュアップ ・PdMを中心に共通化の是非を判断 ・「ユーザー目線での利便性や汎用性」「顧客の成果創出・ROI向上に寄与 するか」といった評価軸で判断 現実には、FDEとして日々の個社対応に目線が向く中で、 ついつい共通化に対しておろそかになってしまうことも・・・ 

個社対応とプロダクト還元の両立 顧客の成果創出とプロダクトの成長を両立するための、Sansan AIエージェントでの取り組み例を挙げる ● ● アイデアから実現までをスムーズに繋げる仕組みづくり ○ 具体的な要件からアイデアレベルの雑記まで、NotionのDB上にチケットを起票する ○ →要件としてFixしたものについてGitHub側に連携する／内容によっては自動で実装まで進む 共通化の判断責務を切り分け ○ FDEが共通化の起点になる一方で、直接ユーザーのFBやペインに触れたり利用の現場を見ている からこそ、盲目的に「この機能は共通して必要」と考えてしまうことがある ○ ● PdMが共通化の判断に責務を持ち、FDE自身は共通化の最終的な判断をしない 共通化についても目標として持つ ○ 事業・チームとして、実際の売上だけでなく、例えば共通化できた機能の数を目標に持つことで、 個社としての成果創出とプロダクト還元の両方に対してモチベートするように 上記のよう仕組みでの改善と、FDE個々人の全てをやり切ろうとする姿勢の、両方が必要 

今後の課題 比較的ミクロなタスクの生産性はAIとその活用方法の進化によって日々向上している 一方で、顧客の成果貢献やプロダクト全体としてのスケールアップは、今後の大きな課題に挙げられる ● 顧客のアウトカムに対してより直接的にコミットする ○ 現状では、成果を説明する際に「こういう機能ができた」「これくらい使われた」といった内容 に留まることも多い ○ 経営・事業上の成果としてROIなどクリアに説明できるよう、常に具体的な成果の創出を念頭に 顧客と合意形成を図りながらプロジェクトを進行する。これを全ての案件で実現する ● プロダクトの進化を加速する ○ 前述のような取り組み・工夫は重ねているものの、まだまだ理想的なスピード感には遠い ○ FDEを介して実際のFBを起点とする還元と、プロダクト全体としてのビジョンの発展に対するそ の実現のための具体化の、両面での改善が必要 ともに課題に向き合ってくださる方をお待ちしています！！ 

Sansan 技術本部 採用情報 https://media.sansan-engineering.com/