なぜマーケと営業で
「SQL定義」がズレるのか

ITバックオフィスSaaSを手がける企業（従業員約200名）では、リード数は順調に増えていました。しかし営業現場からは「質が低い」という声が上がり続け、マーケティング側は「なぜ商談にならないのか分からない」という状態が続いていました。議論は半年近く繰り返されましたが、解決しませんでした。

原因は部門の仲の問題ではありませんでした。MQLからSQLへの引き渡し基準が属人的で、マーケティングと営業で「良いリード」の定義が一致していなかったことが本質でした。収益基準を揃えた結果、MQL→SQL転換率が最大20%向上し、低確度リードへの無駄な接触が削減されました。

あなたの組織は大丈夫か——5つの確認項目

1. 「マーケが送るリードは質が低い」という言葉が会議で出る

   この言葉が出ている組織では、多くの場合MQL・SQLの定義が合意されていません。

2. MQLの条件がスコア点数だけで決まっている

   資料ダウンロード・セミナー参加・ページ閲覧回数の合計だけでMQLを判定すると、「情報収集段階」「決裁権なし」「導入時期不明」のリードが大量に流れます。

3. 「このリードは追うか追わないか」が担当者ごとに違う

   営業マネージャーや担当者によって判断基準が異なる場合、SQLの定義はその人数分だけ存在しています。

4. 商談化率が月ごとに大きく変動する

   基準が属人的なままだと、担当者の状態や月のノルマ進捗によって商談化率が安定しません。

5. マーケと営業が「成功した案件」を振り返る習慣がない

   受注した案件の最初の接触・行動履歴・引き渡しタイミングを定期的に分析していない場合、改善の根拠がないまま同じ議論が繰り返されます。

3つ以上当てはまる場合、MQL・SQLの議論は「感情の問題」に見えて、実は「定義設計の問題」です。

SQL定義がズレる3つのパターン

1. MQL基準が行動量だけになっている

   スコアリングを導入したこと自体は正しい判断です。ただ、スコアが「資料DL×3点、ページ閲覧×1点」という行動量の合計に過ぎない場合、「情報収集に積極的な担当者」がMQLになるだけで、受注可能性とは無関係です。受注に近い行動——「料金ページ閲覧」「導入事例の複数閲覧」「比較記事の閲覧」——をスコアに反映することが必要です。

   判断基準：スコアが高い順に並べたリストを営業に見せたとき、「これは追いたい」と言われるリードが上位に来ていなければ、基準がズレています。

2. 引き渡し判断が担当者の「感覚」に依存している

   MQLの条件がシステムで定義されていても、最終的な判断が担当者の経験則に委ねられている場合、引き渡し基準は属人化したままです。前述のSaaS企業でも、「本来優先すべきリードが適切に扱われず、確度の低いリードに営業リソースを割く構造」が続いていました。

   判断基準：「なぜこのリードを今週営業に渡したか」を聞かれて条件を即答できない担当者がいたら、引き渡しルールは定義されていません。

3. マーケと営業で「成功の定義」が違う

   マーケティングはMQL数・商談化率・リード獲得コストを最適化し、営業は受注数・平均単価・営業サイクル長を最適化します。見ている指標が違う限り、同じリードを「良い」「悪い」と評価するのは必然です。共通のゴール——「受注に近い行動をしているICP企業の担当者」——を揃えて初めて、定義は機能します。

   判断基準：マーケと営業が「今月うまくいった案件」として挙げる案件が一致していなければ、成功の定義がズレています。

定義を揃えた後に何が変わったか

前述のITバックオフィスSaaS企業では、HubSpotを使って収益基準を再設計したことで、以下の変化が起きました。

1. MQL→SQL転換率が最大20%向上

   行動スコアリングにICP条件と受注近接行動を加えたことで、営業が「追いたい」と感じるリードの比率が上がりました。

2. 低確度リードへの接触を削減

   スコア基準と引き渡しルールを明文化したことで、営業が高スコアリードへの集中が可能になりました。

3. パイプライン可視化により施策と収益の因果関係を把握

   どの流入経路・どの行動が最終的な受注に寄与しているかが分かるようになり、マーケティング投資の判断根拠が生まれました。

「質の問題」ではなく「定義の問題」でした。揃えると、議論の内容が変わります。

まず3日でできること

1. 直近3ヶ月の受注案件の「最初の接触」を調べる

   CRMまたはMAで、受注した案件がどの流入経路・どのコンテンツから始まったかをリストアップします。「受注に近かったリードの共通点」が見えてきます。これがMQL・SQL再定義の出発点です。

2. 現在のMQL条件を1枚のスプレッドシートに書き出す

   スコア基準・属性条件・行動条件を文書化します。書いてみると「スコア点数しかない」「業種・規模の条件がない」ことが分かります。この文書を営業に見せて「これで追いたいリードが来ますか」と確認します。

3. 次の週次MTGで「今週商談になったリードの共通点」を5分話す

   マーケと営業が同じ場で「今週商談になったリードはどんな人だったか」を確認するだけで、定義のズレが具体的になります。この習慣を月1回続けるだけで、定義は少しずつ揃っていきます。

まとめ：SQL定義のズレは設計の問題

マーケと営業の摩擦は、コミュニケーション不足や部門の仲の問題ではありません。「良いリード」の定義が揃っていないまま、それぞれの指標を最適化しているから起きます。

MQL・SQLの条件を収益基準で設計し直し、マーケと営業が同じ定義で動ける状態を作ることが先です。議論の前に、定義を1枚の文書にしてください。