SQLで営業企画を変える｜GTMエンジニアが使う分析クエリ10選

結論

• 営業企画がCRMデータをSQLで直接分析できれば、依頼→待機→加工のサイクルから抜け出せる
• パイプライン・受注率・営業パーソン別KPIなど実務で即使える10クエリをコード付きで紹介
• Excel集計から脱却し、月次レポート15時間→30分への短縮を狙える

この記事が役立つ状況

• 対象者: 営業企画担当者・GTMエンジニア志望者・データに直接アクセスして提案の質を上げたい営業マネージャー
• 直面している課題: データ抽出をエンジニアやIT部門に依頼して数日待ち、届いたCSVをExcelで加工する非効率なサイクルから抜け出せない
• 前提条件: CRMのデータベースにアクセス可能な権限があり、テーブル構造（CRMデータ設計）の基礎理解があること

あなたは営業企画のSQL分析を支援するアシスタントです。

【私の状況】
- 役割: [営業企画担当 / GTMエンジニア / 営業マネージャー]
- 使用CRM: [Salesforce / HubSpot / その他]
- 分析したい指標: [パイプラインサマリー / 受注率推移 / 営業パーソン別KPI / その他]
- データベース種別: [BigQuery / Snowflake / PostgreSQL / その他]

【知りたいこと】
[具体的な問い：例「提案済みステージで滞留している商談を抽出したい」]

【出力してほしいもの】
1. 上記環境で動くSQLクエリ
2. クエリの解説（どのテーブル・カラムを使い、何を集計しているか）
3. 実行結果から導ける示唆の例

営業企画がデータで意思決定するなら、SQLは避けて通れない。CRMに蓄積された商談データ、リード情報、活動履歴を自在に分析できるかどうかで、営業企画の提案の質は根本的に変わる。本記事では、GTMエンジニアが実務で使っている営業分析SQLクエリ10選を、コード付きで解説する。Excel集計から脱却し、データに直接アクセスする第一歩として活用してほしい。

なぜ営業企画にSQLが必要なのか

営業企画の仕事は「売れる仕組みの設計」だ。営業企画の仕事内容でも述べた通り、市場分析・KPI設計・プロセス改善のすべてにデータが必要になる。しかし多くの営業企画担当者は、データが必要になるたびにエンジニアやIT部門に抽出を依頼し、数日待ち、届いたCSVをExcelで加工している。

この依頼→待機→加工のサイクルが、営業企画のスピードを殺している。

SQLを書ければ、CRMのデータベースに直接クエリを投げて、必要な情報を数分で手に入れられる。月次レポートの作成に15時間かかっていた作業が30分で終わる。「先週のパイプラインはどうなっているか」を知りたいとき、誰にも頼まず自分で答えを出せる。

SQLはCRMデータ設計の知識と組み合わせることで真価を発揮する。テーブル構造を理解したうえでクエリを書けば、「どのデータがどこにあるか」で迷うことがなくなる。

ここから、営業企画の実務で即使えるSQLクエリ10選を紹介する。

クエリ1: パイプラインサマリー

最も基本的かつ最も使用頻度が高いクエリがパイプラインサマリーだ。商談ステージごとの件数・金額・平均滞留日数を一覧化する。

SELECT
  stage_name,
  COUNT(*) AS deal_count,
  SUM(amount) AS total_amount,
  ROUND(AVG(amount), 0) AS avg_deal_size,
  ROUND(AVG(days_in_current_stage), 1) AS avg_days_in_stage
FROM deals
WHERE created_date >= DATE_TRUNC('quarter', CURRENT_DATE)
GROUP BY stage_name
ORDER BY
  CASE stage_name
    WHEN '初回接点' THEN 1
    WHEN 'ヒアリング完了' THEN 2
    WHEN '提案済み' THEN 3
    WHEN '交渉中' THEN 4
    WHEN '受注' THEN 5
    WHEN '失注' THEN 6
  END;

このクエリを実行すれば、今四半期のパイプラインの全体像が一発で出る。「提案済みに金額が溜まっているのに交渉中が少ない」といったボトルネックを即座に発見できる。CSVエクスポートしてピボットテーブルを組む時代は終わりだ。

クエリ2: 月別受注率推移

営業組織の健康度を測る最重要指標の一つが受注率だ。月ごとの推移を見ることで、プロセス変更や施策の効果を定量的に評価できる。

SELECT
  DATE_TRUNC('month', close_date) AS month,
  COUNT(*) AS total_deals,
  SUM(CASE WHEN is_won = true THEN 1 ELSE 0 END) AS won_deals,
  ROUND(
    SUM(CASE WHEN is_won = true THEN 1 ELSE 0 END) * 100.0 / COUNT(*), 1
  ) AS win_rate_pct,
  SUM(CASE WHEN is_won = true THEN amount ELSE 0 END) AS won_amount
FROM deals
WHERE close_date >= DATE_ADD(CURRENT_DATE, INTERVAL -12 MONTH)
  AND is_closed = true
GROUP BY DATE_TRUNC('month', close_date)
ORDER BY month;

過去12ヶ月の受注率推移を出すこのクエリは、経営会議の定番資料になる。「3月に受注率が下がったのはなぜか」という問いに対して、データで仮説を立てる出発点となる。

クエリ3: 営業パーソン別KPI

営業担当者ごとのパフォーマンスを可視化する。商談数、受注数、受注率、平均単価を一覧化して、ハイパフォーマーの行動パターンを分析する基盤になる。

SELECT
  owner_name,
  COUNT(*) AS total_deals,
  SUM(CASE WHEN is_won = true THEN 1 ELSE 0 END) AS won_deals,
  ROUND(
    SUM(CASE WHEN is_won = true THEN 1 ELSE 0 END) * 100.0
    / NULLIF(COUNT(*), 0), 1
  ) AS win_rate_pct,
  ROUND(
    AVG(CASE WHEN is_won = true THEN amount END), 0
  ) AS avg_won_amount,
  SUM(CASE WHEN is_won = true THEN amount ELSE 0 END) AS total_won_amount
FROM deals
WHERE close_date >= DATE_TRUNC('quarter', CURRENT_DATE)
  AND is_closed = true
GROUP BY owner_name
ORDER BY total_won_amount DESC;

このクエリの結果を見れば、「Aさんは受注率は高いが商談数が少ない」「Bさんは商談数は多いが平均単価が低い」といった個別課題が浮き彫りになる。1on1の材料としても使える実用的なクエリだ。

クエリ4: リードソース別ROI

マーケティング予算の配分を議論するときに不可欠なのがリードソース別のROI分析だ。どのチャネルから来たリードがどれだけ受注に繋がっているかを可視化する。

SELECT
  lead_source,
  COUNT(DISTINCT l.lead_id) AS total_leads,
  COUNT(DISTINCT d.deal_id) AS converted_deals,
  ROUND(
    COUNT(DISTINCT d.deal_id) * 100.0
    / NULLIF(COUNT(DISTINCT l.lead_id), 0), 1
  ) AS conversion_rate_pct,
  COALESCE(SUM(d.amount), 0) AS total_revenue,
  ROUND(
    COALESCE(SUM(d.amount), 0)
    / NULLIF(COUNT(DISTINCT l.lead_id), 0), 0
  ) AS revenue_per_lead
FROM leads l
LEFT JOIN deals d
  ON l.lead_id = d.lead_id AND d.is_won = true
WHERE l.created_date >= DATE_TRUNC('quarter', CURRENT_DATE)
GROUP BY lead_source
ORDER BY total_revenue DESC;

「展示会のリードは多いがコンバージョン率が低い」「紹介経由は少数だがリード単価が圧倒的に高い」。このクエリの結果があれば、マーケ予算の再配分を数字で提案できる。HubSpotのレポート機能でも類似の分析は可能だが、SQLで書けばデータソースを横断した集計ができる点が強みだ。

クエリ5: 商談停滞検知

パイプラインの中で動きが止まっている商談を自動的に検出する。営業マネージャーが「この商談、最近どうなっている？」と聞く前に、データでアラートを出す仕組みだ。

SELECT
  deal_name,
  owner_name,
  stage_name,
  amount,
  days_in_current_stage,
  last_activity_date,
  CURRENT_DATE - last_activity_date AS days_since_last_activity
FROM deals
WHERE is_closed = false
  AND (
    days_in_current_stage > 30
    OR CURRENT_DATE - last_activity_date > 14
  )
ORDER BY amount DESC;

「30日以上同じステージに留まっている商談」「14日以上アクティビティがない商談」を抽出する。このクエリをBIツールに保存し、Slackに週次で自動通知すれば、商談のフォロー漏れを構造的に防げる。金額降順で並べることで、インパクトの大きい案件から対処できる。

クエリ6: コホート分析

リードの獲得月ごとに、その後の受注率と受注金額を追跡する。マーケティング施策の長期的な効果測定に不可欠な分析手法だ。

SELECT
  DATE_TRUNC('month', l.created_date) AS cohort_month,
  COUNT(DISTINCT l.lead_id) AS cohort_size,
  SUM(CASE WHEN d.is_won = true THEN 1 ELSE 0 END) AS total_won,
  ROUND(
    SUM(CASE WHEN d.is_won = true THEN 1 ELSE 0 END) * 100.0
    / NULLIF(COUNT(DISTINCT l.lead_id), 0), 1
  ) AS lifetime_win_rate_pct,
  COALESCE(SUM(CASE WHEN d.is_won = true THEN d.amount ELSE 0 END), 0) AS lifetime_revenue,
  ROUND(
    AVG(CASE WHEN d.is_won = true
      THEN DATE_DIFF(d.close_date, l.created_date, DAY)
    END), 0
  ) AS avg_days_to_close
FROM leads l
LEFT JOIN deals d ON l.lead_id = d.lead_id AND d.is_closed = true
WHERE l.created_date >= DATE_ADD(CURRENT_DATE, INTERVAL -12 MONTH)
GROUP BY DATE_TRUNC('month', l.created_date)
ORDER BY cohort_month;

「1月に獲得したリードは最終的に15%が受注し、平均クロージングまで67日」。この粒度のインサイトがあれば、リード獲得施策の評価が単月のCPAだけでなくLTV視点で行える。コホート分析はSQLの真骨頂であり、BIツールのGUIだけでは再現が難しい分析の代表格だ。

クエリ7: セールスサイクル分析

ステージ間の遷移日数を分析し、営業プロセスのどこに時間がかかっているかを特定する。プロセス改善の優先順位付けに直結する。

SELECT
  from_stage,
  to_stage,
  COUNT(*) AS transition_count,
  ROUND(AVG(days_between), 1) AS avg_days,
  PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY days_between) AS median_days,
  PERCENTILE_CONT(0.9) WITHIN GROUP (ORDER BY days_between) AS p90_days
FROM stage_transitions
WHERE transition_date >= DATE_ADD(CURRENT_DATE, INTERVAL -6 MONTH)
GROUP BY from_stage, to_stage
ORDER BY avg_days DESC;

平均値だけでなく中央値とP90（上位10%の遅い案件）を出すのがポイントだ。「提案→交渉の平均は21日だが、P90は58日」であれば、一部の案件が極端に長引いていることがわかる。中央値と平均値の乖離が大きいステージが改善の最優先候補になる。

クエリ8: フォーキャスト（売上予測）

今期の売上着地見込みを、商談ステージごとの受注確率で加重平均する。営業マネジメントの最重要クエリの一つだ。

SELECT
  owner_name,
  SUM(CASE WHEN is_won = true THEN amount ELSE 0 END) AS closed_won,
  SUM(CASE WHEN is_closed = false THEN amount * stage_probability ELSE 0 END) AS weighted_pipeline,
  SUM(CASE WHEN is_won = true THEN amount ELSE 0 END)
    + SUM(CASE WHEN is_closed = false THEN amount * stage_probability ELSE 0 END)
    AS forecast_total,
  quota,
  ROUND(
    (SUM(CASE WHEN is_won = true THEN amount ELSE 0 END)
      + SUM(CASE WHEN is_closed = false THEN amount * stage_probability ELSE 0 END))
    * 100.0 / NULLIF(quota, 0), 1
  ) AS attainment_pct
FROM deals d
JOIN sales_quotas q ON d.owner_id = q.owner_id
  AND q.quarter = DATE_TRUNC('quarter', CURRENT_DATE)
WHERE d.close_date BETWEEN DATE_TRUNC('quarter', CURRENT_DATE)
  AND DATE_ADD(DATE_TRUNC('quarter', CURRENT_DATE), INTERVAL 3 MONTH)
GROUP BY owner_name, quota
ORDER BY attainment_pct;

受注済み金額＋加重パイプラインの合計で着地見込みを算出し、目標に対する達成率を担当者別に表示する。達成率の低い順に並べることで、サポートが必要な担当者を即座に特定できる。stage_probabilityは各ステージの過去実績から算出した受注確率を入れておく。

クエリ9: 失注理由集計

失注データの分析は、営業プロセス改善の宝庫だ。なぜ負けたかを構造化して把握することで、再現性のある対策を打てる。

SELECT
  lost_reason,
  COUNT(*) AS deal_count,
  SUM(amount) AS lost_amount,
  ROUND(AVG(amount), 0) AS avg_deal_size,
  ROUND(
    COUNT(*) * 100.0
    / SUM(COUNT(*)) OVER (), 1
  ) AS pct_of_total
FROM deals
WHERE is_won = false
  AND is_closed = true
  AND close_date >= DATE_ADD(CURRENT_DATE, INTERVAL -6 MONTH)
GROUP BY lost_reason
ORDER BY lost_amount DESC;

「価格」「競合負け」「タイミング」「ニーズ不一致」——失注理由をランキングし、失注金額ベースで見ることが重要だ。件数ベースでは「タイミング」が最多でも、金額ベースでは「競合負け」が最大ということがある。ウィンドウ関数OVER()を使って全体に占める割合も算出しており、優先対処すべき理由が一目でわかる。

クエリ10: アクティビティ分析

営業担当者の活動量と成果の相関を分析する。「量」と「質」の両面から行動パターンを把握し、チームのベストプラクティスを抽出する。

SELECT
  a.owner_name,
  COUNT(CASE WHEN a.activity_type = 'call' THEN 1 END) AS calls,
  COUNT(CASE WHEN a.activity_type = 'email' THEN 1 END) AS emails,
  COUNT(CASE WHEN a.activity_type = 'meeting' THEN 1 END) AS meetings,
  COUNT(*) AS total_activities,
  COALESCE(w.won_deals, 0) AS won_deals,
  ROUND(
    COALESCE(w.won_deals, 0) * 1.0
    / NULLIF(COUNT(*), 0) * 100, 1
  ) AS activity_to_win_ratio
FROM activities a
LEFT JOIN (
  SELECT owner_name, COUNT(*) AS won_deals
  FROM deals
  WHERE is_won = true
    AND close_date >= DATE_TRUNC('quarter', CURRENT_DATE)
  GROUP BY owner_name
) w ON a.owner_name = w.owner_name
WHERE a.activity_date >= DATE_TRUNC('quarter', CURRENT_DATE)
GROUP BY a.owner_name, w.won_deals
ORDER BY won_deals DESC;

通話回数、メール送信数、ミーティング数を担当者別に集計し、受注件数との相関を見る。「トップセールスのCさんは通話数は平均以下だがミーティング数が圧倒的に多い」といった、数字に基づくコーチングの材料が得られる。営業企画の仕事内容で述べた研修設計にも直結するデータだ。

SQL学習ロードマップ——営業企画が3ヶ月で実務レベルに到達する方法

ここまで10種類のクエリを紹介したが、すべてを一度に覚える必要はない。段階的に学習し、実務で使いながらスキルを定着させるアプローチが最も効果的だ。

Month 1: 基本構文を覚える（週3時間）

SELECT / FROM / WHERE / GROUP BY / ORDER BY。この5つのキーワードで、クエリ1（パイプラインサマリー）とクエリ3（営業パーソン別KPI）が書ける。練習環境はBigQueryの無料枠か、SQLiteのローカル環境がおすすめだ。まずはCSVエクスポート→Excel加工の作業を1つだけSQLに置き換えてみてほしい。

Month 2: JOINとCASE式を習得する（週3時間）

複数テーブルの結合（JOIN）と条件分岐（CASE WHEN）を覚えれば、クエリ4（リードソース別ROI）やクエリ6（コホート分析）が書けるようになる。BIツール（Metabase、Looker Studioなど）に接続し、クエリ結果をダッシュボード化するところまで進めるとよい。

Month 3: ウィンドウ関数と応用（週3時間）

ウィンドウ関数（OVER / PARTITION BY）、サブクエリ、PERCENTILE_CONTなどの応用構文を学ぶ。クエリ7（セールスサイクル分析）やクエリ9（失注理由集計）のような高度な分析が自力で書けるレベルを目指す。ここまで来れば、GTMエンジニアとしてのデータスキルの基盤が完成する。

営業企画がSQLを使うメリットは何ですか？

エンジニアへのデータ抽出依頼をなくし、自分でリアルタイムにCRMデータを分析できるようになります。パイプライン分析や受注率算出などを数分で完了でき、意思決定のスピードと精度が向上します。

SQLを学んだことがない営業企画でも使いこなせますか？

はい。SQLの基本構文はSELECT・FROM・WHERE・GROUP BY・ORDER BYの5つで、プログラミング未経験でも3ヶ月・週3時間の学習で実務に使えるレベルに到達できます。

まとめ——SQLは営業企画の「共通言語」になる

SQLを書ける営業企画は、データの依頼者ではなくデータの活用者になれる。本記事で紹介した10種類のクエリは、営業組織が日常的に直面する分析課題のほぼすべてをカバーしている。

パイプラインの現状把握、受注率のトレンド分析、担当者別パフォーマンス、マーケティングROI、商談の停滞検知、コホート分析、セールスサイクルの可視化、売上予測、失注分析、アクティビティ分析。これらを自分の手で、リアルタイムに実行できること。それが、データドリブンな営業企画の第一歩だ。

CRMデータ設計でデータの構造を整え、SQLで分析し、HubSpotなどのCRMで施策を実行する。この一連の流れを一人で回せる人材が、GTMエンジニアだ。まずは今日、1本目のクエリを書いてみてほしい。さらに高度な分析基盤については営業データ基盤構築ガイドで、機械学習との連携は営業フォーキャストのML活用ガイドで確認してほしい。