マーケティングは「良いリードを送っている」と言い、営業は「質が低い」と言う。これは日本のBtoB企業で非常によく起きています。MA導入・インサイドセールス立ち上げ・MQL運用開始・CRM本格活用のタイミングで、営業とマーケティングの摩擦が急激に増えます。「SQLの定義って何?」「営業が追ってくれない」「商談化率が低すぎる」「マーケと営業で数字が違う」といった言葉が会議に出始めます。

しかしこれはコミュニケーション不足ではありません。本当の原因は、収益につながる顧客の定義が構造として設計されていないことにあります。MQLとSQLの分断は、収益の流れが整備されていない組織では必ず起きます。マーケティングと営業は本来、別の指標で動いているからです。

マーケティング
資料DL数 ↑
セミナー参加 ↑
スコア 50点 ↑
MQL送付 ✓
「良いリードを
送っている」
定義
の壁
営業
導入時期 不明
決裁権 なし
情報収集 段階
商談化 困難
「質が低い
リードばかり」
マーケティングと営業の分断:MQL判定基準と商談候補の定義がずれ、両部門が別々の指標を最適化する

SQL定義がズレる5つの構造的原因

  1. 「良い顧客」の定義が部門で異なる

    マーケティングは獲得件数・見込み客数・スコアを追い、営業は受注・年間売上・成約率を追います。見ている収益地点が違うため、同じ見込み客を「良い」と見るか「使えない」と見るかが自然にずれます。

  2. 見込み客の条件が行動量だけで決まっている

    資料ダウンロード・セミナー参加・スコア数点といった行動量だけで見込み客を絞り込むと、導入時期不明・決裁権なし・情報収集段階の連絡先が大量に送られます。行動量と受注可能性は別物です。

  3. 商談候補の条件が担当者ごとに違う

    営業マネージャーごとに「これは追う」「これはいらない」の判断が異なると、商談候補の基準は崩れます。基準が個人の経験に依存する限り、部門間の摩擦は解消されません。

  4. 指標の定義が統一されていない

    マーケティングが見込み客数を追い、営業が商談転換率を追っていても、両者の定義がずれていれば会議は「数字の責任論」になります。共通の収益指標の土台がなければ、議論は建設的になりません。

  5. 収益の流れが部門で分断されている

    マーケティングは見込み客獲得まで、営業は商談から——それぞれが担当範囲だけを見ていると、収益全体の流れが誰にも見えなくなります。これが分断の本質です。

SQL定義問題は「部門仲の問題」ではない

多くの会社はSQL問題を「部門連携不足」として捉えます。しかし本質は感情ではありません。指標の設計・収益の流れ・定義の統一・RevOpsの問題です。つまりSQL定義の問題は、Revenue Architectureの問題です。

コミュニケーション改善を試みても、収益構造が設計されていなければ同じ摩擦が繰り返されます。

Revenue Qualification Design
流入
Traffic
属性条件
優良見込み
MQL
ICP合致
行動条件
商談候補
SQL
決裁権
時期確認
商談
Opportunity
課題合致
予算確認
年間売上
ARR
収益確定
各ステージで「収益につながる条件」を定義し、マーケティングと営業が合意する
Revenue Qualification Design:流入から年間売上まで、各ステージで収益基準の条件を定義し両部門が共通認識を持つ構造

本当に必要なのは「収益基準での顧客定義」

どの顧客を、どの条件で、どのタイミングで収益候補とみなすか——これを定義する設計が必要です。重要なのは見込み客数ではなく、収益につながる顧客を定義することです。この定義が整うと、マーケティングは収益に向けた獲得を最適化し、営業は質が揃った商談候補を受け取れます。

SQL定義が機能している会社には共通点があります。狙う顧客像(ICP)が明確に定義されている。見込み客の条件が収益基準で決まっており、行動量だけで判断していない。商談候補の条件が営業との合意のもとで設定されている。成功パターンが構造化されており再現できる。RevOpsが両部門の間に立って設計を維持している。

Revenue Architecture という考え方

SQL定義問題の本質はマーケティング問題ではありません。営業・マーケティング・カスタマーサクセス・CRM・KPI・データを「収益につながる一つの構造」として設計するRevenue Architectureの問題です。Revenue Architecture・収益基準での顧客定義・RevOps・KPI設計・収益の流れという構造が整うことで、SQL定義は部門を超えて機能するようになります。

マーケティング 営業 CRM KPI RevOps BI
Revenue Architecture
収益基準の顧客定義 MQL・SQL条件合意 KPI統一設計 収益可視化 RevOps
商談化率の向上
質の揃った商談候補が
営業に届く
収益の可視化
マーケから受注まで
一貫して追える
部門間の連携改善
共通の収益指標で
両部門が動く
Revenue Architectureによる統合:マーケティング・営業・CRM・KPI・RevOps・BIを接続し、収益につながる商談化率を高める

日本企業でSQL問題が起きやすい理由

日本企業では部門分断・属人営業・指標の分断・Excel文化が根強く残っています。そのためマーケティングと営業が「別組織」として動きやすく、収益チームとして連携するための構造が整いにくい。必要なのは「収益チーム」として動くための共通設計であり、日本企業の組織文化に合ったRevenue Architectureの導入が求められます。

Consilegyの考え方

ConsilegyではMQL・SQL改善を単なるMAの運用改善とは考えていません。本質はRevenue Architecture・収益基準での顧客定義・RevOps・収益可視化・収益の流れの設計にあります。HubSpot・Salesforce・BI・Slack・Kintoneを横断しながら、「収益につながる顧客選別の構造」を設計します。目的は見込み客数を増やすことではなく、収益につながる商談を増やすことです。

課題 Consilegyのアプローチ
マーケと営業でSQL基準がズレる ICP定義 + 商談候補条件の合意設計
見込み客の商談転換率が低い 収益基準の見込み客条件設計
指標の定義が部門ごとに違う KPI統一設計 + 定義の明文化
部門間の摩擦が続く RevOps整備 + 収益チーム設計
収益全体が見えない 収益の流れ設計 + 収益可視化構築

まとめ:SQL問題はRevenue構造の問題

マーケティングと営業でSQL定義がズレる原因は部門仲の問題ではありません。Revenue Architecture不足・KPI設計不足・収益基準での顧客定義未設計・RevOps未整備が本質的な原因です。だからこそ必要なのは見込み客数の改善ではなく、「収益につながる顧客選別の構造」を設計することです。SQL定義はRevenue Architecture全体として設計されるべきです。

「質のいいリード」の前に、収益基準の顧客定義を

ConsilegyはICP定義から商談候補条件の合意設計まで、マーケティングと営業が収益チームとして動ける構造を支援します。まずは現状のSQL定義の課題を整理するところから始めましょう。

無料相談を予約する