商談のヒアリング項目が、担当者ごとにバラバラになっている。そんな課題をお持ちの方は多いのではないでしょうか。

ベテランは顧客の事情を深く聞き出してくるのに、若手の商談メモは「予算はまだ」「時期は来期」で終わっている。同じ「Aランク商談」というラベルが貼られていても、中身の確度がまるで違う。結果として、週次のパイプラインレビューは数字の読み合わせではなく、案件ごとの記憶の掘り起こし作業になっていきます。

この状態を解消するために使われるのが、営業フレームワークです。BANT、MEDDIC、SPICED。名前を聞いたことがある方も多いはずです。

ただ、この3つは似ているようで、設計思想がまるで違います。そして多くの組織が、この違いを意識しないまま「とりあえずBANTで」と選んでしまい、数年後に「フレームを埋めているのに、営業の質が上がらない」という壁に当たります。

結論から申し上げます。3つのフレームワークに優劣はありません。違うのは、それぞれが答えようとしている問いです。そして見落とされがちですが、3年運用したあとに社内に残る資産も、まったく別物になります。

フレームワーク主な目的答えようとしている問い3年運用後に残る資産
BANT案件を見極めるこの案件は今、商談化できるか追うか否かの判定材料
SPICED顧客を理解する顧客はなぜ変える必要があるか顧客がなぜ動いたかの記録
MEDDIC大型商談を勝ち切るこの案件をどう前に進め、受注するか大型案件の攻略履歴

右端の列が、本レポートで最もお伝えしたい論点です。フレームワークの選定は営業手法の選定に見えて、実際には組織が顧客について何を記録し、何を記録しないかを決めるデータ設計だからです。

本レポートでは、3つの違いを整理したうえで、実務でどう組み合わせるか、そしてそれをどこに実装するかまでを解説します。

なぜ営業フレームワークが必要なのか？

営業フレームワークとは、顧客や案件を見るための共通の型です。何を聞き、何を記録し、何をもって前進とみなすかを組織で揃えるために使います。

冒頭の光景に戻ります。あれは担当者の能力差の問題に見えて、実際には共通の型がないことの帰結です。型がないまま人数だけ増えると、次の4つが同時に壊れていきます。

  1. 案件の質を比較できない。Aさんの「有望案件」とBさんの「有望案件」が同じ意味を持たなくなります
  2. 次に何を聞くべきかが分からない。若手が商談後に「で、次は何を確認すればいいのか」で止まります
  3. 営業からカスタマーサクセスへの引き継ぎが弱くなる。なぜ買ったのかが伝わらないまま、支援が始まります
  4. 売上予測の精度が下がる。案件の状態を示す言葉が揃っていないため、確度の合算が意味を持ちません

4つ目は特に深刻です。営業予測の精度をめぐる整理（Sales Forecasting Accuracy Guide）では、精度を左右する要因としてCRMのデータ品質とパイプラインの規律が繰り返し挙げられています。ここから言えることは1つです。入力を揃えない限り、予測の計算方法をどう変えても数字は動きません。

フレームワークは、この入力を揃えるための装置です。逆に言えば、揃える中身を間違えると、精度は上がりません。

BANTとは何か？

BANTは、案件の基本条件を4つの観点で確認するフレームワークです。1950年代にIBMが自社の営業組織向けに開発し、1960年代に外部公開されたことで、法人営業の標準として広く普及しました。

  • Budget（予算）：投資できる予算はあるか
  • Authority（決裁権）：目の前の相手は決められるか、誰が決めるのか
  • Need（必要性）：解決したい課題があるか
  • Timeline（導入時期）：いつまでに導入したいか

BANTを理解する鍵は、これが絞り込みのために設計された道具だという一点にあります。当時のIBMが抱えていたのは、大量の引き合いに対して営業リソースが足りないという問題でした。だから4項目しかない。初回接触の短い時間でも確認でき、営業に渡すべき案件を素早く選り分けられます。

裏返せば、4項目のすべてが売り手の都合で組まれています。予算はあるか、決裁権はあるか、いつ買うか。これらは「この人に時間を使う価値があるか」を判定する問いであって、顧客の事情を理解する問いではありません。これは欠陥ではなく、用途に沿った設計です。

問題が起きるのは、絞り込みの道具を理解の道具として使ったときです。「ご予算はおいくらでしょうか」「決裁者はどなたですか」を初回商談で並べれば、顧客からは値踏みに見えます。しかも購買プロセスが複雑化した現在のB2Bでは、初回接触の時点で予算枠も決裁ルートも固まっていないことが珍しくありません。まだ存在しない答えを聞き出そうとして、案件を落とすことになります。

実践ポイント

BANTは案件の入口を見極めるフレームワークです。「この案件を今追いかけるべきか」の判定には強く、「なぜこの顧客が動くのか」の理解には向きません。役割を限定して使うことをお勧めします。

SPICEDとは何か？

SPICEDは、顧客の状況と意思決定の理由を理解するためのフレームワークです。B2Bの収益設計を体系化しているWinning by Designが提唱しました。

  • Situation（状況）：顧客が今どういう状態にあるか
  • Pain（課題）：何に困っているか
  • Impact（影響）：その課題が解決されると、事業にどんな変化が起きるか
  • Critical Event（重要な期限）：いつまでに変化が必要か、その期限は何によって決まっているか
  • Decision（意思決定）：誰が、どんな基準で、どのように決めるか

BANTとの決定的な違いは、ImpactとCritical Eventの2項目にあります。

Impactは、課題が解決されたときに何が変わるのかを、顧客の事業の言葉で確認する項目です。「リード獲得が足りない」で止めず、月50件が150件になると商談数が何件増え、売上計画のどの数字に効くのかまで踏み込む。ここまで揃うと、提案は費用ではなく投資として議論できるようになります。

Critical Eventはさらに重要です。「なぜ今なのか」を規定している事実を特定する問いだからです。来期の予算策定、基幹システムの保守切れ、新製品の上市、担当役員の交代。こうした動かせない予定が背後にあるかどうかで、案件の性質はまったく変わります。ここが空欄のまま進む案件は、競合に負けるのではなく「検討が続いたまま消える」という終わり方をします。B2Bの大型商談では、競合ではなく現状維持に負けるケースが相当数を占めます。だとすればCritical Eventの特定は、競合対策より優先度の高い論点だと言えるでしょう。

Winning by Designの資料（The SPICED Framework）は、SPICEDを単なる商談ヒアリングの型としてではなく、社内の引き継ぎ・フォーキャスト会議・カスタマーサクセスへの移行を支える共通言語として位置づけています。「1回の商談を超えて持続する共通言語」という表現が使われている点は、後述する使い分けの議論に直結します。

実践ポイント

SPICEDは顧客の意思決定ストーリーを整理するフレームワークです。「なぜ変えるのか」と「なぜ今なのか」の2つが埋まらない案件は、確度ではなく前提を疑うべき状態にあります。

MEDDICとは何か？

MEDDICは、大型で複雑な商談を管理し、勝ち切るためのフレームワークです。1996年にPTC社で、Dick Dunkel氏らが自社の受注案件と失注案件を分析する中で体系化しました。MEDDICCの解説（Who Created MEDDIC）によれば、営業組織が約300名規模に拡大した際の品質のばらつきと離職への対処が、開発の直接的な動機だったとされています。急拡大する営業組織に規律を持ち込むための道具として生まれた、という出自です。

  • Metrics（成果指標）：顧客が測る定量的な成果は何か
  • Economic Buyer（最終決裁者）：予算を最終的に握るのは誰か
  • Decision Criteria（選定基準）：何を基準に選ぶのか
  • Decision Process（意思決定プロセス）：どんな順序と承認を経て決まるのか
  • Identify Pain（課題の特定）：解決すべき課題は何か
  • Champion（社内推進者）：社内で提案を推してくれる人は誰か

6項目のうち4つが、意思決定の構造に関するものである点に注目してください。誰が決めるか、何で選ぶか、どう決まるか、誰が推すか。MEDDICの重心は、顧客理解そのものより、組織の中で案件をどう前進させるかに置かれています。

これは開発された環境を考えれば自然な設計です。1件あたりの金額が大きく、関与者が多く、購買までに数カ月から年単位を要する商談では、勝敗を分けるのは課題理解の深さより、意思決定構造の把握です。とりわけChampionという概念は、他の2つのフレームワークにはない発想です。商談は営業がいない会議室で決まります。その場に自社の提案を代弁してくれる人がいるかどうかを、商談管理の必須項目として明示したところにMEDDICの独自性があります。

一方で、MEDDICは重い。6項目を埋めるには複数回の商談と社内調査が必要で、単価の小さい案件に適用すると、管理コストが受注益を上回ります。初回商談でChampionを特定しようとしても、多くの場合はまだ存在しません。

実践ポイント

MEDDICは複雑な案件を攻略し、勝ち切るためのフレームワークです。全案件に適用するものではなく、金額・関与者数・検討期間の3条件で線を引き、対象案件を絞って運用するのが現実的です。

3つのフレームワークの比較

ここまでの整理を、一覧にします。

比較軸BANTSPICEDMEDDIC
主目的案件判定顧客理解商談攻略
向いている場面初期商談・インサイドセールス営業・カスタマーサクセス全般大型・複雑商談
顧客課題の深掘り△◎○
決裁プロセスの把握△○◎
受注後も使えるか△◎○（Metricsのみ）
使いやすさ◎○△
営業管理への活用○○◎

出典：各フレームワークの設計思想と適用範囲より筆者作成

この表で強調したいのは、△が付いた項目は欠陥ではないということです。BANTの「顧客課題の深掘り△」は、深掘りしないことで速さを得ている設計上の選択です。MEDDICの「使いやすさ△」は、複雑な意思決定構造を扱うために払っている必要なコストです。

道具の優劣を論じても、実務は1ミリも動きません。論点は、自社の営業プロセスのどの地点で、どの問いに答えたいのかです。

実務ではどう使い分けるのか？

現実の営業プロセスでは、3つを排他的に選ぶ必要はありません。むしろ、時間軸に沿って組み合わせるのが実務的です。

商談の進行に合わせて、次のように配置します。

フェーズ担当使うフレームワーク目的
リード選別インサイドセールスBANT追いかける案件を決める
商談前半営業SPICEDなぜ変えるのか、なぜ今かを掴む
大型案件の進行管理営業MEDDIC決裁構造とChampionを押さえる
受注後の引き継ぎ営業→カスタマーサクセスSPICED期待した成果を継続して追う

注目していただきたいのは、SPICEDが2回登場する点です。これは記載の重複ではありません。受注という区切りを、最も多くの項目が生き残った状態でまたげるのがSPICEDだからです。

受注した瞬間に、BANTのBudgetもTimelineも記録としての意味を失います。MEDDICも、Economic BuyerとDecision Processは購買が終われば役目を終えます。ただしMEDDICのMetrics（顧客が測る成果指標）だけは例外で、これは受注後の成果検証にそのまま使えます。

対してSPICEDは、5項目のほぼすべてが受注後も生きます。とりわけImpactは、受注後にこそ検証すべき項目です。顧客が期待した変化は実際に起きたのか。起きていないなら何が足りないのか。この問いは、継続と拡大の判断に直結します。

サブスクリプション型のビジネスで収益の大半が受注後に発生する構造を踏まえると、この差は無視できません。

フレームワークは「埋める欄」ではなく、組織のデータ構造である

ここからが、本レポートで最もお伝えしたい論点です。

営業フレームワークの導入は、しばしば「ヒアリング項目を決める」話として扱われます。しかし実際に起きているのは、それよりずっと構造的なことです。どのフレームワークを選ぶかは、組織が顧客について何を記録し、何を記録しないかを決める意思決定にほかなりません。

CRMの項目設計を考えれば分かりやすいはずです。BANTを採用した組織のCRMには、予算・決裁者・課題・時期の4項目が並びます。ここに蓄積されるのは、案件を追うか否かの判定材料です。3年間運用すれば、判定材料が3年分たまります。

一方、SPICEDを採用した組織のCRMには、顧客の状況・課題・その影響・期限・意思決定構造が並びます。3年運用した組織には、顧客がなぜ動いたのかの記録が3年分たまります。

同じ3年でも、残る資産がまったく違います。そして後者は、勝ちパターンの分析にも、カスタマーサクセスの引き継ぎにも、AIによる案件スコアリングの学習データにも使えます。前者からは、そのどれも取り出せません。

つまりフレームワークの選定は、営業手法の選定ではなく、データ設計です。埋める欄を決める作業ではなく、組織の顧客理解の器を決める作業だと捉えるべきでしょう。

Winning by Designは、SPICEDを部門をまたぐ共通言語として位置づけています。私はそこから一歩踏み込んで、共通言語の選択はCRMに残る資産の差として跳ね返る、と考えています。言葉を揃える話に見えて、実際には数年後の分析力を決めている。ここが、フレームワーク論が営業部門の話で終わってはいけない理由です。

この視点に立つと、「使い分け」の実装先も変わります。使い分けとは、営業担当者が頭の中で場面に応じて切り替えることではありません。それでは属人化を別の形で温存するだけです。

ただし、ここで手を広げてはいけません。実装先は3つありますが、同時に着手すると、ほぼ確実に0個で終わります。順番に申し上げます。

最初の一手は、CRMに「Critical Event」の入力欄を1つ追加することです。そして、ここが空欄の案件を、その月のフォーキャストから外す。追加する欄は1つで構いません。

この運用変更には、あらかじめ知っておくべき副作用があります。初月は、予測数字が落ちて見えます。これまで確度が高いとされていた案件のうち、期限の根拠がないものが一斉に外れるからです。しかしこれは精度の悪化ではなく、実態が可視化されただけです。ここで数字の見栄えに引き戻されると、この施策は続きません。経営層への事前の説明が要る論点です。

そのうえで、次の順で広げます。

  1. CRMの項目：まずCritical Event、次にImpact。どのフェーズでどの項目が必須になるかをシステム側で規定する
  2. フォーキャストの定義：確度ランクの判定基準を項目に紐づける。「Aランク」ではなく「Critical Eventが特定され、Economic Buyerと接触済み」と定義する
  3. 引き継ぎフォーマット：営業からカスタマーサクセスへ渡す情報を、SPICEDの項目で固定する。着手は3カ月目以降で構いません

この3点を仕組みとして押さえて初めて、フレームワークは組織の共通言語になります。裏を返せば、研修で用語を教えるだけで終わっている限り、共通言語にはなりません。よくある失敗は、導入した初月だけ入力率が上がり、3カ月後には自由記述の商談メモに戻っているというものです。原因は現場の意識ではなく、入力が業務プロセスに組み込まれていないことにあります。

実践ポイント

最初の一手は、CRMに「Critical Event」の欄を1つ追加し、空欄の案件をフォーキャストから外すことです。初月は数字が落ちて見えます。それは実態が見えた合図であって、悪化ではありません。

まとめ：フレームを埋めることが目的ではない

3つのフレームワークの役割を、あらためて整理します。

BANTは案件を選ぶための道具です。速く、軽く、初期選別に強い。SPICEDは顧客を理解するための道具です。なぜ変えるのか、なぜ今なのかを掴み、受注後まで持ち越せる。MEDDICは案件を勝ち切るための道具です。誰が決めるかの構造を押さえ、大型商談を前に進める。

3つは競合しません。答えようとしている問いが違うだけです。

そのうえで、最も重要なことを申し上げます。フレームワークの価値は、項目が埋まっているかどうかでは決まりません。組織として顧客理解が共有され、次のアクションが揃うかどうかで決まります。CRMの必須項目を100%埋めながら、誰も中身を読んでいない組織を、私は何度も見てきました。

だからこそ、フレームワークの議論は営業部門だけで完結させるべきではありません。何を記録するかを決めるのはデータ設計であり、それは営業・マーケティング・カスタマーサクセスを貫く収益プロセス全体の設計に属します。ここを設計しきれるかどうかが、これからのB2B組織の分かれ目になると考えています。

そしてもう一つ。どのフレームワークを選ぶにせよ、項目を埋めるのは現場に出た人間です。Critical Eventは、顧客と向き合った会話の中にしか落ちていません。市場に出て一次情報に触れる習慣がないまま型だけを導入しても、埋まるのは推測です。型より先に、市場に出る順序を取り違えないことをお勧めします。

埋めることが目的化した瞬間に、フレームワークはただの入力作業になります。

営業フレームワークについてよくある質問

Q1. BANT・MEDDIC・SPICEDのうち、どれか1つを選ぶならどれですか？

自社の商材と営業プロセスによります。単価が低く商談サイクルが短いなら、速さの効くBANTで十分な場合があります。単価が高く関与者が多いならMEDDIC。継続課金型で受注後の成果が収益を左右するならSPICEDです。判断軸は「受注後も顧客理解を使い続けるか」です。使うならSPICEDを基軸に置くことをお勧めします。

Q2. BANTはもう古いのでしょうか？

古いという評価は正確ではありません。BANTは1950年代にIBMが引き合いの選別のために開発したもので、その用途では今も有効です。問題になるのは、顧客理解の道具として使ったときです。初回接触の選別に限定すれば、4項目の軽さは現在も他のフレームワークにない強みだと言えるでしょう。

Q3. SPICEDとMEDDICは、項目が似ているように見えます。何が違うのですか？

重心が違います。SPICEDはImpactとCritical Eventによって「なぜ変えるのか、なぜ今か」という顧客側の理由を掘ります。MEDDICはEconomic Buyer、Decision Process、Championによって「誰がどう決めるか」という意思決定構造を押さえます。顧客を理解するのがSPICED、案件を前進させるのがMEDDICという整理が実務的です。

Q4. 複数のフレームワークを併用すると、現場の入力負担が増えませんか？

増えます。だからこそフェーズごとに必須項目を分けることが要点です。全案件に全項目を求めるのではなく、リード選別ではBANTの4項目、商談化以降はSPICED、一定金額以上の案件だけMEDDICを追加する。CRM側で必須項目をフェーズ条件に紐づければ、1案件あたりの入力量は大きく変わりません。

Q5. フレームワークを導入しましたが、定着しません。何が原因ですか？

多くの場合、入力が業務プロセスに組み込まれていないことが原因です。研修で用語を教えるだけでは、3カ月で自由記述に戻ります。フォーキャストの確度判定をフレームワークの項目に紐づけ、項目が埋まっていない案件は予測から外すという運用にすると、入力は業務上の必然になります。意識ではなく仕組みで解決する論点です。

Q6. 営業からカスタマーサクセスへの引き継ぎには、どれを使うべきですか？

SPICEDです。BANTとMEDDICは受注をゴールに設計されているため、受注後に引き継ぐ意味のある項目がほとんど残りません。SPICEDのImpactとCritical Eventは、受注後に「期待した変化が起きたか」を検証する基準として機能します。引き継ぎフォーマットをSPICEDの項目で固定すると、支援の初動が速くなります。

Q7. 営業予測の精度は、フレームワーク導入でどこまで改善しますか？

フレームワークを導入しただけでは改善しません。精度を左右するのはCRMのデータ品質とパイプラインの規律であり（forecastio, 2026）、フレームワークはその入力を揃える手段にすぎないためです。確度ランクの定義を項目に紐づけ、判定を主観から条件に変えたときに、はじめて数字が動き始めます。なお導入初月は、期限の根拠がない案件が外れるため、予測値がいったん下がって見える点に注意が必要です。

営業プロセスとCRMのデータ構造設計について

ギアソリューションズでは、B2B企業の営業プロセス設計と、それを支えるCRMのデータ構造設計を、実行まで含めてハンズオンで行っています。「フレームワークを入れたが現場に定着しない」「営業からカスタマーサクセスへの引き継ぎが機能していない」という課題をお持ちの方は、ご相談ください。

参考情報