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

エンジニアへのデータ依頼と待ち時間をなくし、自分で10分でデータを取得できるようになります。月次レポート作成時間の大幅短縮やリアルタイムなパイプライン分析が可能になり、営業戦略の立案に集中できます。

営業企画がSQLを実務レベルで使えるようになるまでどのくらいかかりますか？

週3時間の学習で3ヶ月が目安です。1ヶ月目にSQL基本構文、2ヶ月目にBIツール連携、3ヶ月目に自動化と応用を学びます。

SQLとPythonやBIツール、営業企画が最初に学ぶべきはどれですか？

まずSQLを学ぶべきです。SQLはどのデータベースでも使える共通言語であり、学習コストも低く、BIツールのカスタムクエリにも必要です。PythonやBIツールはSQLを覚えた上で活用すると効果が最大化します。

営業企画がSQLで具体的にどんな業務を効率化できますか？

パイプライン分析の自動化、リードソース別ROI評価、商談ステージの遷移分析、営業担当者別アクティビティ分析、予実管理のリアルタイム化の5つが代表的なユースケースです。

営業企画がSQLを書く時代が来た

毎月15日、営業企画は地獄を見る

月次レポートの締め日。営業企画担当のあなたは、こんな作業をしていないだろうか。

SalesforceからCSVをエクスポートする。HubSpotからもCSVを出す。会計ソフトから売上データを引っ張る。3つのExcelファイルをVLOOKUPで突合する。ピボットテーブルを組む。グラフを作る。パワーポイントに貼る。

途中でデータの不整合に気づく。「この商談、Salesforceでは受注なのにHubSpotではまだ進行中になっている」。原因を調べるために営業に確認する。修正する。レポートを作り直す。

毎月15時間。年間180時間。この作業に知的な価値はほぼゼロだ。

Excelの限界は、あなたの限界ではない

誤解しないでほしい。Excelは素晴らしいツールだ。しかし、営業企画の仕事がExcelで完結する時代は終わった。

データ量の限界。 Excelは100万行が上限だ。過去3年分の商談データ、リード情報、活動履歴を結合すれば、すぐに到達する。「重くて開けない」ファイルを同僚と共有した経験があるなら、その限界を体感しているはずだ。

再現性の欠如。 先月作ったレポートと同じ集計を今月も行う。しかしExcelでは手順が属人化する。担当者が休むとレポートが出せない。引き継ぎ資料は「このセルにこの関数を入れて…」という手順書になる。

リアルタイム性の不在。 CSVをエクスポートした瞬間にデータは古くなる。「今日時点のパイプライン」を見たいのに、先週のデータで意思決定している。

SQLは、これらの限界を突破する。

なぜSQLなのか

「BIツールを入れればいいのでは」「Pythonの方がいいのでは」。そう思うかもしれない。しかし営業企画がまず学ぶべきはSQLだ。理由は3つある。

理由1: データの共通言語だから。

Salesforce、HubSpot、BigQuery、Redshift、PostgreSQL。どのデータベースもSQLで操作する。一度学べば、どのシステムのデータにもアクセスできる。PythonやRはデータ加工には強いが、データベースから情報を取り出す第一歩は常にSQLだ。

理由2: BIツールの真価を引き出すから。

Tableau、Looker、Metabase。どのBIツールもGUIで操作できるが、カスタムクエリを書けるかどうかで活用範囲が桁違いに変わる。「このデータソースとあのデータソースを結合して、この条件でフィルタして」という要望を、エンジニアに依頼せず自分で実現できる。

理由3: 学習コストが低いから。

SQLの基本構文はSELECT、FROM、WHERE、GROUP BY、ORDER BY。5つのキーワードを覚えれば、ほとんどの集計は書ける。プログラミング言語と比べて圧倒的に取り組みやすい。英語が読めれば、SQLは「何をしているか」が直感的にわかる。

営業企画がSQLで解決できる5つのユースケース

具体的に、SQLで何ができるようになるのか。営業企画の実務に即した5つのユースケースを紹介する。

ユースケース1: パイプライン分析の自動化

SELECT
  sales_stage,
  COUNT(*) AS deal_count,
  SUM(amount) AS total_amount,
  AVG(days_in_stage) AS avg_days_in_stage
FROM opportunities
WHERE close_date BETWEEN '2026-01-01' AND '2026-03-31'
GROUP BY sales_stage
ORDER BY sales_stage;

ステージ別の商談数、金額、平均滞留日数が一発で出る。毎月CSVをエクスポートしてピボットテーブルを組む必要はない。このクエリをBIツールに保存すれば、リアルタイムで更新されるダッシュボードになる。

ユースケース2: リードソース別のROI評価

SELECT
  lead_source,
  COUNT(*) AS total_leads,
  SUM(CASE WHEN status = 'converted' THEN 1 ELSE 0 END) AS converted,
  ROUND(SUM(CASE WHEN status = 'converted' THEN 1 ELSE 0 END) * 100.0 / COUNT(*), 1) AS conversion_rate
FROM leads
WHERE created_date >= '2025-04-01'
GROUP BY lead_source
ORDER BY conversion_rate DESC;

どのリードソースからのコンバージョン率が高いか。マーケティング予算の配分を議論するとき、「感覚的にウェビナーがいい」ではなく「ウェビナー経由のコンバージョン率は23.4%、展示会は8.7%」と数字で語れる。

ユースケース3: 商談ステージの遷移分析

各ステージでの平均滞留日数を算出し、ボトルネックを特定する。「提案から交渉への遷移に平均42日かかっている。ここが改善ポイントだ」と、データで営業プロセスの課題を指摘できる。

ユースケース4: 営業担当者別のアクティビティ分析

通話回数、メール送信数、商談数、受注率を担当者別に集計する。ハイパフォーマーの行動パターンを抽出し、チーム全体の底上げ施策に活かす。「トップセールスは初回接触から3日以内にフォローメールを送っている」といったインサイトが見える。

ユースケース5: 予実管理のリアルタイム化

受注実績と目標を突合し、達成率をリアルタイムで表示する。月中でも「このままのペースだと目標の87%着地」という予測が出せる。月末に慌てて数字を集計する世界から脱却できる。

全員がプログラマーになる必要はない

ここで強調しておきたい。営業企画にフルスタックエンジニアのスキルを求めているわけではない。

必要なのは「データに直接アクセスできる力」だ。エンジニアに「このデータを出してください」と依頼し、3日待ち、出てきたデータが想定と違い、再依頼する。このサイクルを、自分で10分で解決できるようになる。それだけだ。

複雑なデータパイプラインの構築はエンジニアに任せればいい。ETLの設計もインフラの管理もエンジニアの仕事だ。しかし「このテーブルからこの条件でデータを取り出す」という基本操作は、データを使って意思決定する人間が自分でできるべきだ。

学習ロードマップ: 3ヶ月で実務に使える

営業企画がSQLを実務レベルで使えるようになるまでのロードマップを示す。

Month 1: SQLの基本（週3時間）

SELECT / FROM / WHERE で条件付きデータ抽出
GROUP BY / HAVING で集計
ORDER BY / LIMIT でソートと件数制限
JOIN で複数テーブルの結合
練習環境: BigQueryの無料枠、またはSQLiteをローカルに構築

最初の1ヶ月で「CSVエクスポート → Excel加工」の作業を「SQLクエリ1本」に置き換える体験をする。この体験が学習のモチベーションを決定的にする。

Month 2: BIツールとの接続（週3時間）

Metabase、Looker Studio（旧データポータル）、Tableauのいずれかに接続
保存したクエリをダッシュボード化
自動更新スケジュールの設定
チームメンバーへの共有

ここまでできれば、月次レポートの作成時間は15時間から30分に短縮される。

Month 3: 自動化と応用（週3時間）

定期実行クエリの設定（スケジュールドクエリ）
Slack通知との連携（閾値超えアラート）
サブクエリ、ウィンドウ関数などの応用構文
CRMのAPIからデータウェアハウスへのデータ連携の理解

3ヶ月後、あなたは「データが欲しい」と思ったとき、誰にも依頼せず、自分で答えを出せるようになっている。

営業企画の価値が変わる

SQLを書ける営業企画は、「データを整理する人」から「データで意思決定を支援する人」に変わる。

毎月のレポート作成が自動化されれば、空いた時間で本来やるべき仕事ができる。営業戦略の立案、施策の効果検証、新しい市場機会の発見。営業企画の本質的な価値は、Excelの関数を組むことではなく、データから「次に何をすべきか」を導き出すことだ。

営業企画がSQLを書く。これは「エンジニアの仕事を奪う」話ではなく、「営業企画の仕事を本来の価値に近づける」話だ。

データに直接アクセスできる営業企画がいる組織と、いない組織。その差は、今後ますます開いていく。