Vercel COOが語る「GTMをプロダクトとして設計する」-- SDR10人をAIエージェント+QA1人に置き換えた戦略
Vercel COO Jeanne DeWitt Grosserは「GTMをプロダクトとして設計・テスト・イテレーションする」と語る。SDR10人をAIエージェント+QA1人に置き換えた具体的な戦略と、GTMエンジニア1人が25-30%の時間で構築した仕組みを解説する。
Vercel COOが語る「GTMをプロダクトとして設計する」-- SDR10人をAIエージェント+QA1人に置き換えた戦略
Jeanne DeWitt Grosserとは
Jeanne DeWitt GrosserはVercelのCOO（最高執行責任者）。Google在籍時にGoogle Cloud Platform（GCP）のセールス組織を率いた経験を持つ。
Vercelはフロントエンド開発プラットフォームとして開発者に広く使われているが、エンタープライズセールスも展開するSLGの側面がある。DeWitt GrosserはこのSLG組織をGTMエンジニアリングで再設計した。
「GTMをプロダクトとして設計する」とは
DeWitt GrosserがLenny's PodcastとTomasz Tunguzのブログで語った核心的なメッセージ:
「GTM（Go-To-Market）のプロセスそのものをプロダクトとして扱う。仮説を立て、実装し、テストし、データを見て改善する。エンジニアがプロダクトを作るのと同じサイクルをGTMに適用する」
この発言を聞いたとき、「言葉は新しいが、やっていることはエンジニアリングそのものだ」と感じた。
プロダクト開発でいうと、ユーザーストーリーを定義してフィーチャーを実装する。A/Bテストでユーザー行動を検証し、ログ/メトリクスで監視する。バグをフィックスしてCI/CDで高速デプロイする。GTMエンジニアリングでは、これと同じことを営業プロセスに対してやる。営業プロセスの各ステップを定義してワークフロー/自動化を実装する。A/Bテストでコンバージョン率を検証し、パイプラインメトリクスで監視する。ボトルネックを特定して解消し、営業ワークフローを高速イテレーションする。
SDR10人 → AIエージェント + QA1人
VercelのGTMエンジニアリングで最も注目された変革は、10人のSDR（Sales Development Representative）チームをAIエージェント+QA担当1人に置き換えたことだ。
SDRの従来業務
SDRの主な仕事はターゲット企業のリスト作成、各企業のリサーチ（担当者特定、課題仮説構築）、パーソナライズドメールの作成・送信、返信の管理とフォローアップ、商談のスケジュール調整、CRMへの活動記録だ。
このうちリスト作成、リサーチ、メール作成・送信、活動記録はパターン化可能な作業だ。
AIエージェントへの置き換え
VercelのGTMエンジニアが構築した仕組み:
[データ収集] Clay + Apollo
→ ターゲット企業リスト自動生成
→ 企業データ/担当者データのエンリッチメント
[AI処理] Claude / GPT
→ 企業ごとの課題仮説生成
→ パーソナライズドメッセージ作成
→ 返信内容の分析・分類
[配信] Smartlead / Instantly
→ メールシーケンスの自動実行
→ ウォームアップ管理
→ バウンス/返信の自動処理
[CRM] HubSpot / Salesforce
→ 活動ログの自動記録
→ パイプラインステージの自動更新
[QA担当1人]
→ AIの出力品質のチェック
→ エッジケースの手動対応
→ ワークフローの改善提案
構築にかかった工数
DeWitt Grosserによると、GTMエンジニア1人が業務時間の25-30%を使って構築した。フルタイム換算で2-3ヶ月程度の工数で、10人のSDRチームと同等以上のアウトプットを出す仕組みが完成した。この数字は初めて聞いたとき、少し信じ難かった。
コスト比較
概算:
| 項目 | SDR10人 | AIエージェント + QA1人 |
|---|---|---|
| 人件費（年間） | $600K-$800K | $60K-$80K（QA1人） |
| ツール費 | $50K | $100K-$150K（Clay, Smartlead等） |
| GTMエンジニア工数 | - | 25-30%（既存エンジニアの兼務） |
| 合計 | $650K-$850K | $200K-$300K |
コストが1/3以下になるだけでなく、品質面のメリットもある。AIは疲れないので金曜夕方も月曜朝も同じ品質だ。対象企業を100社→1000社に増やしてもコストはほぼ変わらない。全アウトリーチのデータが自動記録され、改善のインプットになる。
SLG組織への影響
営業担当の役割変化
SDRのパイプライン生成がAIに置き換わることで、AE（Account Executive）の役割がより高度になる。
AIが生成した商談は、既にリサーチ済み・課題仮説付きの状態でAEに渡される。AEは「ゼロからリサーチする」時間がなくなる代わりに、提案の質と深さで勝負する必要がある。
人間が価値を出すべきは「顧客の課題を深く理解し、最適なソリューションを提案する」部分で、その前段のリサーチやリスト作成は自動化すべきワークだった、というのがDeWitt Grosserの主張だ。
GTMエンジニアの組織内位置づけ
Vercelの事例では、GTMエンジニアはセールス組織とエンジニアリング組織の間に位置する。
CRO / VP of Sales
├── AE Team（商談〜受注）
├── CS Team（既存顧客管理）
└── GTM Engineer（パイプライン基盤構築）← ここ
├── AIエージェント管理
├── CRM/ツール統合
└── メトリクス/ダッシュボード
SREがプロダクトの信頼性を担保するように、GTMエンジニアはパイプラインの信頼性を担保する。この比喩はしっくりくる。
日本のBtoB企業への適用
「SDRをAIで置き換える」は日本でも可能か
部分的に可能だ。ただし、日本特有の課題がある。
ターゲット企業のリサーチ自動化（IR資料、プレスリリース、採用ページの分析）、CRMへの活動ログ自動記録、商談前の情報整理・課題仮説生成は実現できる。
一方で、日本のBtoBセールスでは電話アプローチが依然として有効な業界がある。メールシーケンスだけでは不十分なケースが多い。初回接触は紹介経由が効果的なケースも多く、コールドアウトリーチの効果が米国ほど高くない。Apollo/ZoomInfoのカバレッジ問題もあり、日本企業の担当者メールアドレスを大量取得すること自体が難しい。
日本で効くGTMエンジニアリングの形
日本市場では、Vercelモデルをそのままコピーするのではなく、SLGの商談品質を上げる方向にGTMエンジニアリングを適用するのが現実的だと思う。
ターゲット企業のIR/ニュース/採用情報を自動収集・要約して、営業が商談に入る時点でのドメイン知識を底上げする。顧客ごとにカスタマイズされた提案書のドラフトをAIで生成する。商談後の議事録から次アクションを自動抽出してCRMに反映する。既存顧客の利用状況を可視化してチャーン予兆を検知する。
いずれも「営業担当の時間をリサーチ・事務作業から解放し、顧客との対話に集中させる」ためのエンジニアリングだ。
DeWitt Grosserの3つの教訓
Lenny's Podcastでの発言から、自分が特に刺さった3点を書く。
GTMプロセスを「出荷可能な単位」で考える。 プロダクト開発で最小限のリリース可能単位を考えるように、GTMプロセスも分解して段階的に自動化する。全部を一度にやろうとしない、というのは実際に作り始めると忘れがちだ。
メトリクスで会話する。 パイプラインの各ステージのコンバージョン率を計測して、「なんとなくうまくいっている」から脱出する。エンジニアが得意な「データで判断する」文化をGTMに持ち込む。
エンジニアをセールスの近くに置く。 GTMエンジニアがセールスチームの隣で仕事をすることで、営業の痛みを直接理解できる。仕様書だけ受け取って作る構造では価値が半減する。これは言われてみると当たり前だが、実際にできていない組織は多い。
次の記事ではGTMエンジニアリングの技術スタック全体像を整理する。ここまでに出てきたツールとワークフローを4層モデルで整理し、日本市場での再構成パターンをまとめる。