GTMエンジニアが商談に同席して得た5つの学び -- 営業の言語を理解するエンジニアの価値

なぜGTMエンジニアは商談に同席すべきか

Palantir FDSEの記事で、顧客先に入り込んでコードで課題を解決するエンジニアの働き方を紹介した。FDSEモデルの核は「顧客の業務を直接観察し、プロダクトと顧客業務のギャップをエンジニアリングで埋める」ことにある。

これを日本のSLG型BtoB SaaS組織に翻訳すると、まず最初のステップは営業チームの商談に同席することになる。

同席を始めたのは、あるきっかけからだった。営業チームから「提案資料を自動生成するツールを作ってほしい」と依頼を受け、仕様をヒアリングして実装した。しかし、完成したツールはほとんど使われなかった。理由を聞くと「商談の流れに合わない」「顧客が求めている情報の粒度が違う」という答えが返ってきた。

リモートで仕様書だけ受け取る構造では、GTMエンジニアリングの価値は半減する。Vercel COOのDeWitt Grosserが語っていた教訓の「GTMをプロダクトとして設計する」には、ユーザーリサーチが不可欠だ。GTMエンジニアにとってのユーザーは営業チームであり、そのユーザーリサーチの場が商談なのだ。

同席の頻度と方法

同席を習慣化するにあたって決めたルール:

営業チームには「技術的な質問が来たらパスしてほしい。それ以外の時間は観察に徹する」と伝えた。目的はあくまで営業プロセスの観察と理解であり、商談中に技術説明をすることではない。

ここから先は、同席を重ねて得た5つの学びと、それぞれをエンジニアリングでどう解決したかを書く。

学び1: 営業が「説明に使う時間」の長さ

商談の時間配分

同席してまず驚いたのは、商談の時間配分だった。60分の商談のうち、プロダクトの説明や提案に使える時間は想像よりずっと短い。

実際に10件の商談の時間配分を計測した結果:

商談時間の42%が「御社の現状はこうですよね？」「今はどういうツールで管理されていますか？」「何名くらいで運用されていますか？」という現状確認に費やされている。

しかもこの25分は、営業担当にとって最もストレスが高い時間帯だ。事前リサーチが不十分だと顧客の状況を聞き出す質問が増え、結果的にプロダクト説明に使える時間が圧縮される。顧客側も「自社の説明を何度もさせられる」ことにフラストレーションを感じている。

エンジニアリングでの解決: 商談前リサーチ自動化

この問題に対し、商談前に自動でリサーチを完了させる仕組みを構築した。

[CRMに新規商談が登録される]
    ↓
[Webhook → リサーチパイプライン起動]
    ↓ 並列実行
    ├── 企業Webサイトのクロール（事業内容、組織構造）
    ├── IRページの要約（上場企業の場合）
    ├── 採用ページの分析（技術スタック・組織課題の推定）
    ├── ニュースクリップ（直近3ヶ月の主要記事）
    └── 既存CRMデータとの突合（過去の接触履歴）
    ↓
[Claude APIで構造化]
    ├── 企業サマリー（1段落）
    ├── 推定される課題（3つ）
    ├── 商談で確認すべきポイント（質問リスト）
    └── トリガーイベント（なぜ今このタイミングか）
    ↓
[CRMのDealに自動添付 + Slackで営業に通知]

商談前リサーチの自動化により、現状把握フェーズが25分から10分に短縮された。営業担当は「御社は最近こういう取り組みをされていますよね」と確認から入れるため、顧客も「ちゃんと調べてきている」と好印象を持つ。

この仕組みの詳細な実装は前回のClaude APIパイプライン記事で書いた。ポイントは商談がCRMに登録された瞬間に自動起動すること。営業担当がリサーチを依頼する必要すらない状態を作った。

定量効果

この数字はある範囲での計測値で、全商談で同じ結果が出るとは言えないが、参考値として：

学び2: 顧客が「稟議に使える材料」を求めている

日本企業の意思決定プロセス

SLG型GTMエンジニアの定義記事で「日本企業の稟議文化」について触れた。商談に同席すると、この稟議の壁がどれだけ高いかを肌で感じる。

ある商談で、担当者が「個人的にはすごく良いと思う」と言った直後に「ただ、うちは部長→本部長→役員まで通す必要があって...」と続けた。そして次にこう聞いた。

「導入効果を数字で見せられる資料ってありますか？役員は数字しか見ないので」

この「数字で見せられる資料」のリクエストは、同席した商談の7割以上で出てきた。日本企業の意思決定フローは以下の構造になっている:

[現場担当者] 「これ良さそう」
    ↓ 稟議書を起案
[直属上長]  「効果は？ ROIは？」
    ↓ 上長の質問に答えて再起案
[部門長]    「他社比較は？ 既存ツールとの共存は？」
    ↓ 追加資料を添付して再起案
[役員]      「3年間のTCOは？ 撤退基準は？」
    ↓ 最終判断
[取締役会]  「承認 or 差し戻し」

各ステージで「承認者が判断に使う材料」が異なる。現場担当者は操作性を重視するが、役員は投資対効果しか見ない。営業担当がこの全ステージに対応するために、膨大な資料作成を手動で行っている。

エンジニアリングでの解決: ROI試算・稟議支援ツール

商談後に顧客情報を入力すると、稟議の各ステージに最適化された資料を自動生成する仕組みを作った。

[入力: 顧客情報]
  企業名・業種・従業員数・営業チーム人数
  現在の課題（選択式 + 自由記述）
  想定プラン・契約期間
    ↓
[自動生成される資料セット]
  ├── ROI試算レポート (PDF)
  │   - 現状コストの可視化（人件費ベース）
  │   - 導入後の削減効果（時間 × 単価）
  │   - 3年間のTCO比較
  │   - 投資回収期間のシミュレーション
  │
  ├── 競合比較資料 (PDF)
  │   - 機能比較ではなく「課題解決アプローチ」の比較
  │   - 顧客の業種に特化した事例
  │
  └── 導入計画書 (PDF)
      - フェーズ分けされた移行計画
      - リスクと対策
      - 成功基準の定義

特にROI試算レポートのPDF自動生成は反響が大きかった。営業担当が顧客名・業種・従業員規模を入力すると、その企業に合わせた試算が入ったPDFが30秒で出力される。営業チームからは「商談の翌日に送れるようになった。以前は3日かかっていた」というフィードバックをもらった。

ROI試算の設計ポイント

ROI試算で大事なのは、顧客が「自分ごと」として感じられる具体性を持たせること。

汎用的な「年間XX%のコスト削減」ではなく、以下の要素をパーソナライズする:

• 企業名: PDFの表紙に顧客企業名を入れる
• 業種固有の課題: 製造業なら「在庫管理の属人化」、SaaSなら「チャーン予兆の検知遅延」
• 規模に応じた試算: 営業チーム10名と50名では効果の絶対値が変わる
• 同業他社の導入事例: 同じ業種の企業がどういう成果を出したか

これらのパーソナライズをClaude APIで自動化した。営業担当がCRMのDeal情報を更新するだけで、カスタマイズされたPDFが生成される。

学び3: 競合比較は「機能表」では決まらない

機能の○×表は意思決定に使われない

商談に同席して3つ目に気づいたのは、競合比較の場面だった。

営業チームは競合比較用に「機能比較表」を用意していた。自社プロダクトの機能と競合プロダクトの機能を○×で並べたExcelシートだ。

しかし、同席した商談で顧客がこの表を見て言ったのは:

「○が多いのはわかったんですけど、結局うちの〇〇業務がどう変わるかがイメージできなくて...」

顧客は機能の数ではなく「自分の課題がどう解決されるか」で判断する。抽象的な機能一覧よりも、自社のデータやワークフローを使った具体的なデモのほうが圧倒的に説得力がある。

ある商談で、営業担当がPowerPointで競合比較を説明している最中に、顧客側の担当者がスマホを触り始めたのを見た。一方で、別の商談で顧客の実データに近いサンプルデータを使ってライブデモをしたときは、参加者全員が画面に集中していた。

エンジニアリングでの解決: カスタムデモ環境

競合がパワーポイントで説明している間に、動くプロトタイプを見せる。この差を作るために、顧客ごとにカスタマイズされたデモ環境を構築できる仕組みを作った。

[デモ環境の自動プロビジョニング]

営業がCRMで「デモ商談」フラグをON
    ↓
[自動処理]
  1. テナント分離されたデモ環境をプロビジョニング
  2. 顧客の業種テンプレートを適用
     - SaaS向け: MRR推移、チャーン分析ダッシュボード
     - 製造業向け: 在庫管理、生産計画の可視化
     - 小売業向け: 顧客分析、売上予測ダッシュボード
  3. ダミーデータを顧客の規模感に合わせて投入
     - 従業員100名なら100人分、1000名なら1000人分
  4. 顧客のロゴ・社名を反映（ヘッダー・レポートに表示）
    ↓
[営業に通知]
  デモ環境URL + 操作ガイド + 説明スクリプト

デモ環境の技術的な詳細はGTMカスタムデモ環境の記事で書いているので、ここではビジネス上の効果に絞って話す。

カスタムデモを導入してから、商談でのWin Rate（受注率）に変化が出た。この数字は実測値だが、母数が限られているため傾向の参考として見てほしい:

フルカスタムデモを見せた商談は、標準デモに比べてWin Rateが高く、商談サイクルも短い。顧客が「自社のことだ」と感じられるかどうかが、意思決定のスピードに直結するのだと思う。

学び4: 「既存ツールとの共存」が最大の障壁

「全部入れ替え」は稟議が通らない

商談で最も多かった懸念が「今使っているツールとどう共存するか」だった。

日本のBtoB企業は、すでにkintone、Salesforce、スプレッドシート、自社開発のExcelマクロ、メール+ファイルサーバーなど、様々な仕組みで業務を回している。新しいツールの導入提案に対して、ほぼ確実に出てくる質問がこれだ:

「今使っているkintone（/Salesforce/スプレッドシート）のデータはどうなりますか？」

この質問の裏にある懸念は3つある:

1. 移行コスト: 既存データの移行に何ヶ月かかるのか
2. 学習コスト: 現場のオペレーションが変わることへの抵抗
3. 稟議の難しさ: 「全面リプレイス」は金額も大きくリスクも高いため、承認が下りにくい

「全部入れ替えてください」という提案は、たとえプロダクトが優れていても稟議を通しづらい。一方「今の仕組みと並行して使い始められます」という提案は、スモールスタートとして稟議が通りやすい。

エンジニアリングでの解決: 連携デモとマイグレーションツール

この障壁をエンジニアリングで突破するために、3つの仕組みを作った。

1. CRM連携APIのライブデモ

商談中に、顧客が使っているCRM（Salesforce/HubSpot/kintone）との連携をライブで見せる。

[商談中のライブデモの流れ]

「御社はSalesforceをお使いですよね。実際に連携がどう動くか見せます」
    ↓
[テストSalesforce環境]
  → 商談データを入力
  → 自社プロダクトに自動同期される様子を見せる
  → 自社プロダクトで更新した内容がSalesforceに書き戻される
    ↓
「既存のSalesforceの運用はそのまま。裏で自動的にデータが同期されます」

これは「共存できる」ことの証拠になる。口頭で「連携できます」と言うのと、実際に動くデモを見せるのでは、顧客の安心感が全く違う。

2. データ移行シミュレーター

顧客の既存データ構造を入力すると、移行後のデータがどう見えるかをプレビューできるツール。

• CSVアップロード（列マッピングのサジェスト付き）
• マッピング結果のプレビュー（変換前→変換後を並べて表示）
• 移行にかかる推定時間の表示

このツールは商談後のフォローアップで送付する。顧客がセルフサービスで移行の見通しを立てられるため、「移行が大変そう」という懸念を自分で払拭できる。

3. 段階的移行パスの提案テンプレート

Phase 1（1-2週間）: 既存ツールと並行稼働。データの自動同期のみ
Phase 2（1ヶ月）: 新しいワークフローを一部チームで試行
Phase 3（2-3ヶ月）: 全チームへ展開。既存ツールの利用を段階的に縮小
Phase 4（任意）: 完全移行 or 共存継続の判断

「Phase 1は既存のツールの使い方を一切変えなくていい」と伝えることで、導入のハードルを大きく下げている。

学び5: 営業の「あとで手動でやります」は技術的負債の入口

受注を優先するが故の手動運用

5つ目の学びは、営業組織特有の構造的問題に関するものだ。

商談中、顧客から「こういうこともできますか？」と聞かれた際に、営業担当が即座に「できます」と答える場面を何度も見た。しかし商談後にSlackで確認すると「あの機能は標準にはないんだけど、手動でカバーする予定」という回答が返ってくる。

営業担当の立場からすれば、合理的な判断だ。「できません」と言えば失注のリスクがある。「確認して折り返します」では商談のモメンタムが下がる。「できます（手動でやります）」が短期的には最も合理的な回答になる。

しかし、これが積み重なると深刻な問題になる:

[手動運用が積み重なるパターン]

商談1: 「週次レポートを自動送信できますか？」→「できます」→ 手動で毎週メール送信
商談2: 「顧客データをCSVで一括エクスポートしたい」→「できます」→ 手動でCSV作成
商談3: 「Slackに通知を飛ばせますか？」→「できます」→ 手動でSlack投稿
商談4: 「独自の帳票フォーマットで出力したい」→「できます」→ 手動でExcel整形
    ↓
[3ヶ月後]
営業チーム全体で手動タスクが20件/週に膨れ上がる
    ↓
[結果]
顧客対応の時間が圧迫される
ミスが発生する
離職リスクが上がる

コードベースの技術的負債と同じく、短期的な判断の蓄積が長期的なパフォーマンス低下を招く。

エンジニアリングでの解決: 営業の「できます」を技術で拡張する

この問題に対するアプローチは2つある。

アプローチ1: 手動運用の棚卸しと自動化

まず営業チーム全体の「手動でカバーしている業務」を棚卸しした。Slackの過去ログとCRMのメモを分析し、手動運用の一覧を作成した。

月25時間、営業チーム全体で見ると約3人日が手動運用に消えている。これを1つずつ自動化するバックログを作り、インパクト順に潰していった。

アプローチ2: 「できます」と言える範囲の事前拡張

より根本的な解決は、営業が「できます」と言った時点でそれが本当にできる状態を作ることだ。

商談で頻出するリクエストをパターン化し、あらかじめ自動化しておく:

[頻出リクエストの事前自動化]

カテゴリ: レポーティング
  ├── 週次/月次レポートの自動配信 → 設定画面で顧客がON/OFF
  ├── カスタムフィールドでのフィルタリング → レポートビルダー実装
  └── PDF/CSV/Excelでのエクスポート → ワンクリックダウンロード

カテゴリ: 外部連携
  ├── Slack通知 → Webhook設定画面
  ├── メール通知 → 通知ルールエンジン
  └── CRM連携 → OAuth + 双方向同期

カテゴリ: データ操作
  ├── 一括インポート/エクスポート → バッチ処理API
  ├── データクレンジング → 自動検出 + 修正サジェスト
  └── 権限管理 → ロールベースアクセス制御

これにより、営業担当が商談中に「できます」と言った内容のうち、80%以上がセルフサーブで実現可能になった。残り20%はカスタム開発が必要だが、その判断も商談後のフォローで正確に伝えられるようになった。

商談同席のプラクティス

5つの学びを踏まえ、商談同席を実践するためのプラクティスを書く。

同席するタイミング

すべての商談に同席する必要はない。タイミングによって得られる学びが異なる。

商談中にメモすべきこと

同席中は以下のフレームワークでメモを取る:

## 商談メモテンプレート

### 顧客情報
- 企業名:
- 参加者（名前・役職）:
- 商談フェーズ:

### 課題・ニーズ
- 顧客が口にした課題:
- 言葉にしなかったが推測できる課題:
- 緊急度（今期中に解決したい / いずれ / 情報収集段階）:

### 営業プロセスの観察
- 営業が時間を使っていたフェーズ:
- 顧客が食いついたポイント:
- 顧客が興味を失ったポイント:
- 競合製品への言及:

### エンジニアリングで解決できそうなこと
- 今すぐ自動化できる:
- 1週間あれば作れる:
- 中期的に取り組むべき:

### ネクストアクション
- 営業側:
- GTMエンジニア側:

商談後のフィードバックループ

商談後のアクションが最も重要だ。同席して終わりでは意味がない。

[商談終了]
    ↓ 30分以内
[Slackに商談メモを投稿]
  → #sales-insights チャンネル（営業チーム全員が見られる）
  → メモのうち「エンジニアリングで解決できそうなこと」は別途 #gtm-backlog にも投稿
    ↓ 翌日のスタンドアップ
[営業チームと振り返り]
  → 5分で「昨日の商談でこういう学びがあった」を共有
  → 自動化バックログの優先度を確認
    ↓ 週次レビュー
[バックログの整理]
  → 新しいパターンの追加
  → 完了した自動化の効果測定
  → 次週の同席スケジュール確認

営業チームとの信頼関係の築き方

商談同席を提案した際、最初は営業チームから警戒された。「エンジニアが来ると、営業の粗探しをされるのでは」「商談のテンポが崩れるのでは」という懸念があった。

信頼を築くために実践したこと:

1. 最初の成果を素早く出す: 同席1週目で見つけた課題を、翌週には自動化して見せた。「このツール、先週の商談で気づいて作りました」と伝えると、同席の価値を実感してもらえる
2. 営業のやり方を否定しない: 「もっとこうした方がいい」ではなく「こういう仕組みがあれば楽になりますか？」と問いかける
3. 営業の言葉を使う: 「API連携」ではなく「自動でデータが同期される」。「バッチ処理」ではなく「夜のうちに全部終わってる」
4. 定量効果を共有する: 自動化の効果を「月XX時間削減」「Win Rate XX%向上」の形で見える化し、営業チームの成果として発信する

商談同席から生まれた自動化の実例

最後に、商談同席から生まれた自動化の全体像をbefore/afterで見る。

Before: 商談同席前

[営業担当の1日]

09:00-10:00  メールチェック + CRM更新
10:00-11:30  商談先のリサーチ（Webサイト巡回、IR読み込み）
11:30-12:00  提案資料の微修正（パワポの顧客名差し替え等）
12:00-13:00  ランチ
13:00-14:00  商談（60分のうち25分が現状把握）
14:00-14:30  商談後のCRM更新 + 議事録作成
14:30-15:30  手動運用タスク（レポート送信、CSV作成等）
15:30-16:30  フォローアップメール作成
16:30-17:00  翌日の商談準備
17:00-18:00  社内ミーティング

→ 顧客との対話時間: 約2時間/日
→ リサーチ + 事務作業: 約4.5時間/日

After: 商談同席後に構築した自動化

[営業担当の1日]

09:00-09:15  自動リサーチレポートを確認（CRMに自動添付済み）
09:15-09:30  カスタムデモ環境のプレビュー確認
09:30-10:00  商談の準備（戦略検討に集中）
10:00-11:00  商談1（現状把握10分 → プロダクト説明30分 → Q&A20分）
11:00-11:10  CRM自動更新を確認 + 追記
11:10-12:00  商談2
12:00-13:00  ランチ
13:00-14:00  商談3
14:00-14:30  フォローアップメール（テンプレート自動生成 → 微修正）
14:30-15:30  深堀り商談
15:30-16:00  ROI試算レポートの自動生成 → 確認 → 送付
16:00-17:00  顧客フォロー電話
17:00-18:00  翌日の戦略検討

→ 顧客との対話時間: 約4.5時間/日
→ リサーチ + 事務作業: 約1時間/日

全体の定量効果

営業チームからの反応

定量効果も重要だが、営業チームの定性的な反応も記録しておく:

• リサーチ自動化: 「朝出社してCRMを開くと、今日の商談先の情報がもう揃っている。この安心感は大きい」
• ROI試算ツール: 「顧客に『数字が欲しい』と言われて焦ることがなくなった。翌日にはカスタマイズされたPDFを送れる」
• カスタムデモ: 「顧客のロゴが入ったデモ環境を見せた瞬間に、商談の空気が変わる。本気度が伝わる」
• 連携デモ: 「『今のSalesforceはそのまま使えます』とライブで見せられるのが決め手になった商談が3件あった」

---

GTMエンジニアのユニークな価値は技術力だけではないと思う。営業現場を理解しているエンジニアであることが、実際に使われる仕組みを作るための前提条件だ。

仕様書には書かれないことが商談には山ほどある。稟議の壁の高さ、既存ツールへの執着、「できます」の裏にある手動運用。これらを自分で観察して初めて、商談の流れに自然に組み込まれる仕組みが作れる。

自分が最初にやったのは、営業チームのマネージャーに「週1回の商談に同席させてほしい。邪魔しない」と直接頼んだことだった。そこから始まった。

次の記事では、商談同席で得た知見を踏まえ、提案資料の自動生成パイプラインの具体的な実装に踏み込む。ROI試算レポートのPDF生成から、稟議書テンプレートの自動カスタマイズまで、コード付きで書く。

次の記事: GTM提案資料自動生成パイプラインの実装 →