MEDDICの商談チェック項目14｜○をつけていい判定条件
店長MEDDICの6要素と、チェック項目が「6つ」では足りない理由
MEDDICは、高額で関係者の多い法人商談の受注確度を見極めるために、1990年代のPTC社で生まれた営業フレームワークです。金額が大きく、検討が長く、決裁に複数の部署が関わる商談ほど、担当者の手応えと実際の受注確度がずれます。そのずれを、担当者の感覚ではなく確認事項の形に置き換えるための枠組みが、頭文字で並んだ6つの要素です。まずはその6要素が、それぞれ何を確かめるためのものかを整理します。あわせて、実務で「埋めたつもり」になりやすい記入の典型も並べます。ここが本記事の出発点になります。
| 要素 | 何を確かめるものか | 「埋めた」と誤解される典型の記入 |
|---|---|---|
| M：Metrics | 導入によって動く数字はどれかを確かめます | 「コスト削減」（金額も期間も入っていません） |
| E：Economic Buyer | 予算について最終判断を下す人は誰かを確かめます | 「営業部長」（その人に会っていません） |
| DC：Decision Criteria | 選定の判断軸は何かを確かめます | 「価格と機能」（どちらが重いのかがありません） |
| DP：Decision Process | 承認の経路と所要はどうなっているかを確かめます | 「稟議に上げる予定」（誰の承認が何段階必要かが不明です） |
| IP：Identify Pain | 解決しないと困る理由は何かを確かめます | 「業務効率化したい」（誰がいつ困るのかがありません） |
| C：Champion | 社内で推してくれる人は誰かを確かめます | 「担当者と仲が良い」（社内で発言した事実がありません） |
問題は、この6要素をすべて言えるようになり、CRMのMEDDIC欄も一通り埋めている営業ほど、埋めた案件がそのまま失注する点にあります。理由は表の右列にあります。右列の記入は、どれも6要素という粒度で見るかぎり「埋まっている」ように見えます。つまり6要素は、確認すべき領域を示すカテゴリ名であって、その場で合否を判定できる単位になっていないのです。チェック項目が6つのままでは、埋めた気になった状態と本当に押さえた状態を区別できません。次章では、この6要素を判定できる単位に割り直します。
MEDDIC商談チェックリスト｜6要素を14項目に割り、○をつける条件を決める
本章がこの記事の中心です。MEDDICを扱う記事の多くは6要素の説明で止まりますが、実務で必要なのは説明ではなく、商談が終わった直後に自分の案件を照らし合わせられる項目です。そこで6要素を14の判定項目に割り、それぞれに「合格と判定していい条件」を決めます。以降、見出しにある印をつけてよい状態を「合格」、つけられない状態を「未達」と呼びます。条件を決めるときの原則は一つで、書けているかどうかで機械的に判定できる形にすることです。「理解している」「把握している」は判定できないため、条件には使いません。判定できない条件を置くと、結局は担当者の自己申告に戻ってしまうからです。
もっとも、項目を細かくする作業には、抜け漏れを防ぐためという以上の意味があるように思います。チェックリストは、確認漏れを見つける道具として語られがちです。けれども実際に商談を壊すのは、聞き忘れた項目ではありません。聞いたつもりになっている項目のほうです。探検の地図にたとえるなら、白いまま残っている領域よりも、想像で描き込まれた海岸線のほうが危ない、という構造に近いのかもしれません。白紙は誰の目にも未確認だと分かりますが、線が引かれた瞬間、それは確認済みの顔をして地図に居座ります。そして航路は、白紙ではなく、その線を信じて引かれます。
だとすると、判定条件を決める作業の本当の役割は、確認の精度を上げることではなく、自分が何を知らないのかを言葉にできる状態を作ることだと言えそうです。知らないと分かっている未知は、次の商談の議題になります。知っていると思い込んでいる未知は、議題になりません。前者は放っておいても案件を殺しませんが、後者は稟議の直前まで姿を見せずに残ります。「書けているかどうか」という機械的な線を引くのは、後者を前者に変換するための操作です。以降の14項目は、確認漏れの一覧ではなく、思い込みを未確認に格下げするための装置として読んでいただくのがよいかもしれません。
Metrics・Economic Buyer — 数字と決裁者に○をつけていい条件
M-1 数字が特定されている：合格の条件は、単位と現在値の両方が書けていることです。「不良率」という項目名だけでは足りず、その不良率が現在どの水準にあるのかまで書けて初めて合格になります。現在値のない記入は、導入後に効果を測る起点がないため、提案の根拠として成立しません。
M-2 その数字を顧客が口にした：合格の条件は、顧客の資料か発言に実際に出てきた数字であることです。営業が業界平均から置いた数字は、稟議の場で必ず崩れます。社内の誰かが「うちの実態とは違う」と言った瞬間に、提案全体の前提が疑われるからです。
M-3 目標値と期限がある：合格の条件は、いつまでにどの水準にしたいのかが書けていることです。現在値と目標値と期限がそろって初めて、投資判断の材料になります。
E-1 最終判断者の氏名と役職が特定されている：合格の条件は、その人がいくらまで決裁できるのかが分かっていることです。役職名だけでは合格にしません。同じ部長でも決裁枠は組織によって違い、金額が上振れした瞬間に判断者が変わるためです。
E-2 その人に接触した：合格の条件は、同席・面談・メールのいずれかで直接のやり取りがあることです。「担当者が話を上げてくれている」は未達です。この項目は、実際に照らし合わせると最も未達が付きやすい項目になります。未達だった場合の動かし方は、後の章でまとめて引き取ります。
Decision Criteria・Decision Process — 選定基準と稟議経路に○をつけていい条件
DC-1 選定基準の項目が3つ以上挙がっている：合格の条件は、顧客の言葉で書けていることです。営業が提案書の比較表から逆算して並べた基準は、顧客の基準ではありません。
DC-2 基準に順位か重みがある：合格の条件は、どれが最優先かを顧客自身が言ったことです。挙がった基準がすべて並列に見えている状態は、基準を聞けたのではなく、まだ聞けていない状態です。順位が出ないうちは、提案の力点を決めようがありません。
DC-3 基準が誰の基準か分かっている：合格の条件は、現場の基準と決裁者の基準を分けて書けていることです。この二つはほとんどの場合ずれています。現場は運用の手間を重く見て、決裁者は投資対効果と社内説明のしやすさを重く見ます。ずれを知らないまま提案すると、どちらか片方にしか刺さりません。
DP-1 承認の登場人物が全員挙がっている：合格の条件は、氏名または役職で列挙できることです。「関係部署が何箇所か絡みます」という粒度では、誰が止めるのかが読めません。
DP-2 各ステップの所要期間が分かっている：合格の条件は、稟議に上げてから決裁が下りるまでにどれくらいかかるのかが書けていることです。ここが空欄の案件は、着地する月を読むことができません。
DP-3 直近の締切・イベントが分かっている：合格の条件は、期末・予算計上・契約更新・法改正など、顧客側で動かせない日付が把握できていることです。動かせない日付がない案件は、無期限に延びる前提で扱う必要があります。
Identify Pain・Champion — 課題と、自称Championを本物と分ける条件
IP-1 困りごとが業務の場面で書けている：合格の条件は、いつ・誰が・何をしているときに詰まるのかが、顧客自身の言葉で書けていることです。さらに、放置した場合に何が起きるのかまで顧客が自分の言葉で語っていれば、判断の材料としては十分な状態になります。「効率化したい」は未達です。営業が「それは大変ですね」と代弁して整えた困りごとも、顧客の中では言葉になっていないため未達として扱います。稟議で説明するのは営業ではなく顧客側の誰かなので、その人の言葉になっていない課題は社内で再生できません。
C-1 推してくれる人の氏名がある：合格の条件は、特定の個人の名前が書けることです。「情報システム部が前向きです」という部署単位の記入は、推してくれる人を特定できていない状態です。
C-2 その人が社内で発言した実績がある：この記事で最も差が出る判定です。合格の条件は、自分がいない場——社内会議、上司への報告、稟議書の起案——で、その人が自社を推した事実を確認できていることです。仲が良い、よく質問してくる、社内の情報をくれる、これらはすべて未達です。あわせて、その人の意見が過去の意思決定に反映された例を知っているかまで確認できていれば、影響力の面でも合格と判断できます。熱心に動いてくれても、社内で意見が通らない人であれば案件は前に進みません。Championを見つけて育てる、という言い方は多くの記事に出てきますが、自称と本物を分けているのは関係の良さではなく、社内での発言実績です。
以上をチェックリストとして通しで並べると、次のようになります。M-1／M-2／M-3／E-1／E-2／DC-1／DC-2／DC-3／DP-1／DP-2／DP-3／IP-1／C-1／C-2 の14項目です。案件レビューやCRMには、この単位で転記してください。ただし、すべてを合格にしなければ進めない、という意味ではありません。フェーズごとの合格ラインは後の章で引きます。ここまでで、埋めた気になっていた項目が未達に変わった案件が出てくるはずです。その未達をどう動かすかは、必ず引き取ります。
○をつける前に見るのは、項目の中身ではなく「誰が言ったか」
前章の条件を通すと、多くの項目に未達が付きます。ただし、本当に危ないのは未達が付いた項目ではありません。合格とも未達とも判定されないまま、「一応埋まっている」状態で放置される項目です。CRMに「Economic Buyer：営業部長」と書かれていても、その一行からは、決裁者本人と会って確認したのか、担当者がそう言っただけなのか、営業が組織図と金額から推測したのかが分かりません。同じ文字列でも、この三つは確度がまったく違います。本章では、項目の中身を見る前に出所を見る、という順番を入れます。
埋まっているのに当たらないチェックリストで、何が起きているか
同じ「営業部長」という記入でも、成り立ちは三通りあります。一つ目は、決裁者本人が「私が決めます」と言った場合で、これはほぼ確実です。二つ目は、担当者が「たぶん部長決裁です」と言った場合で、担当者が稟議の実務を知らないことは珍しくありません。金額が想定より上振れした瞬間に本部長決裁へ移り、登場人物が入れ替わります。三つ目は、営業が組織図と金額から推測した場合で、根拠はありません。
問題は、この三つがCRMの一行になった瞬間、まったく同じ顔をすることです。そして案件レビューでマネージャーが見るのは、その一行です。結果として、営業個人の推測が組織の共通認識として流通し、着地予測にまで反映されます。稟議の場で知らない決裁者が出てきて止まる案件の大半は、商談の場ではなくここで壊れています。形骸化の原因を入力の面倒さに求める議論をよく見かけますが、実際の原因は入力量ではありません。推測が、事実とまったく同じ書式で同じ欄に入ってしまうことが原因です。
出所で3段階に分ける — 顧客本人の口／担当者の伝聞／営業の推測
直し方は一つで、記入に出所を付けます。段階は三つで足ります。Aは本人の口から直接聞いた情報、Bは別の人から聞いた伝聞、Cは営業の推測です。書式は項目の後ろに一文字添えるだけで、「Economic Buyer：営業部長（B・担当者談）」のように書きます。入力の負荷はほとんど増えませんが、レビューで見るべき場所が一目で分かるようになります。
判定への使い方も単純です。Cは合格にしません。推測は空欄と同じ扱いにします。Bは、次の商談でAに引き上げる対象として扱います。合格になるのはAだけです。この運用を通すと、前章の14項目のうち合格が付く数は、想像していたより少なくなります。ただし、少なくなった状態こそが案件の実際の姿です。ここで初めて、チェックリストは失注の予測に使える道具になります。丁寧に確認しましょう、という心がけではなく、書式に一文字足すという操作で解決する点が重要です。形だけのチェックになるのではないかという不安には、運用の負荷を上げない形でしか答えられません。
空欄が見つかった案件を、次の商談でどう動かすか
チェックリストの価値は、未達が付いた後に何をするかで決まります。確認して終わりであれば、それは案件の成績表にしかならず、担当者にとっては未達の一覧を眺める時間が増えるだけです。足りないと分かったところで自分にできることがないのではないか、という感覚は、ここが埋まっていないことから来ています。マネージャーが不足要素を質問で確認する、という運用は語られますが、それはマネージャー側の段取りであって、担当者が顧客に何と言うかではありません。本章では、未達の種類ごとに、次の商談で口にする言葉まで降ろします。
決裁者・意思決定プロセスが空欄のとき — 断られない頼み方と、断られたときの読み替え
最も多い未達はE-2、決裁者に接触できていない状態です。ここで「決裁者に会わせてください」と正面から頼むと、担当者は自分が飛ばされると感じて断ります。通りやすい頼み方は三つあります。一つ目は、担当者を主役にする形です。社内でご説明されるときに資料が足りないと申し訳ないので、想定される質問を先に潰しておきたい、と伝えます。会わせてもらうのではなく、担当者の準備を助ける形にします。二つ目は、役割と時間を限定する形です。効果の測り方だけ確認する場を短時間でいただけないか、と議題を狭めるほど通ります。三つ目は、顧客側の必要から逆算する形です。稟議には投資対効果の記載が要ると伺ったので、その数字の前提を決裁者と一度合わせておきませんか、と持ちかけます。
断られた場合も、それ自体が情報になります。担当者が上に上げられない、社内の政治的な事情がある、そもそも案件が本気で動いていない、のいずれかです。この時点でC-2が未達である可能性が高いので、決裁者に向かう前にChampionを作り直す順番になります。DP側が空欄の場合は、「稟議はどのような流れになりますか」と手続きを尋ねるのではなく、過去の類似案件を聞きます。同じくらいの規模のものを導入されたときはどういう順番で決まったのか、と実例を尋ねると、経路と所要期間が具体で返ってきます。停滞している案件は、まずこの順で見直します。
数字・課題・選定基準が空欄のとき — 聞き直す場を作る口実の作り方
M・IP・DCの未達は、聞き方が分からないのではなく、聞き直す場がないことがボトルネックになります。一度商談を終えた相手に、もう一度同じことを伺いたいとは言いにくいからです。そこで、こちらから何かを持ち込む形に変えます。一つ目は試算を持って行く形です。同業のケースで試算してみたので、御社の前提だとどこがずれるか教えてほしい、と渡します。相手は訂正するだけでよく、答える負荷が下がります。二つ目は提案の分岐を見せる形です。二つの案で提案が分かれるので判断材料としてどちらを重く見るか、と尋ねると、DC-2の重みが引き出せます。三つ目は議事メモを送って確認する形です。認識のずれがないか確認させてほしい、と送ると、IP-1の場面が具体化して返ってきます。
共通しているのは、質問ではなく確認の形にしていることです。質問は相手に考える作業を頼みますが、確認は相手に訂正を頼むだけなので、返答率がまったく違います。
| 未達の項目 | 次のアクション | その場の言い方 |
|---|---|---|
| E-2（決裁者に接触できていない） | 担当者の社内説明を助ける名目で同席を求めます | 社内でご説明される際の想定質問を、先に一緒に潰しておきたいのですが |
| DP-1／DP-2（経路と所要が不明） | 過去の類似案件の実例を聞きます | 同じくらいの規模のものを入れられたときは、どういう順番で決まりましたか |
| M-1／M-2（数字がない） | 試算を持ち込み、訂正してもらいます | 同業の前提で試算してみたのですが、御社だとどこがずれますか |
| DC-2（優先順位がない） | 提案の分岐を見せて重みを引き出します | 判断の材料として、どちらをより重く見られますか |
| IP-1（課題が場面になっていない） | 議事メモを送って確認を求めます | 認識にずれがないか、確認させていただけますか |
| C-2（社内での発言実績がない） | 社内説明の場面を一緒に作ります | 社内でご説明されるとき、どういう点を聞かれそうですか |
商談フェーズ別｜どこまで埋まっていれば次に進めるか
14項目を一回の商談ですべて埋めるのは不可能です。初回商談で稟議の経路まで聞こうとすれば、相手は売り込みの気配を感じて口が重くなります。逆に、提案の直前になっても決裁者に接触できていないのであれば、そのまま提案書を作り込むのは危険です。つまり必要なのは全項目の達成ではなく、フェーズごとの最低ラインです。合格ラインのないチェックリストは、未達の一覧を並べるだけの罪状リストになり、やがて誰も開かなくなります。本章では、フェーズごとに何が埋まっているべきで、何が空欄なら次に進まないのかを決めます。
| フェーズ | その場のゴール | 埋まっているべき項目 | 空欄なら次に進まない項目 |
|---|---|---|---|
| 初回商談 | 二回目の約束を取ることです | IP-1（詰まる場面）／M-1（数字の名前）／C-1（推してくれそうな人の名前） | IP-1（困っている場面を言えない相手は、まだ案件になっていません） |
| 要件確認・二回目 | 選定基準の合意を作ることです | DC-1／DC-2／M-2（顧客の口から出た数字）／DP-1（登場人物） | DC-2（優先順位が出ないうちは、相手の中で検討が始まっていません） |
| 提案前 | 提案内容を握ることです | E-1／E-2／DP-2（所要期間）／DC-3（現場と決裁者の基準の差） | E-2（決裁者に接触しないまま提案書を作ると、作り直しになります） |
| 稟議前・クロージング | 社内で通る状態を作ることです | C-2（社内での発言実績）／DP-3（締切）／M-3（目標値と期限） | C-2（自分のいない場で誰も推していない案件は、稟議で止まります） |
初回商談でEとDPを聞かないのは、聞くべきでないからではなく、聞くと売り込みに見えるからです。関門として最も重いのは提案前のE-2です。ここで止まる勇気があるかどうかで、提案書を作り直す回数が変わります。注意したいのは、進まないことと失注が別だという点です。進まないとは、次の提案や見積を出す前に、その項目を埋めに戻るという意味です。ここを混同すると、チェックリストが撤退判断の道具に見えてしまい、現場は使わなくなります。
なお、MEDDICが要らない商談もあります。単価が低い、担当者に決裁権がある、検討が二週間ほどで終わる、既存顧客の追加購入といった商談では、14項目は過剰です。判断の軸は商材の属性ではなく商談の型です。同じ商材でも、新規導入なら14項目が要り、既存部署の増設なら要りません。項目を増やすほど商談が尋問になるという懸念は、この線引きをしないまま全案件に同じリストを当てることから生まれます。
チェック項目をその場で埋めるための聞き方
項目と条件が決まっても、商談の場で口に出せなければ埋まりません。ここでは14項目と同じ並び順で、そのまま言える質問文を置きます。順番をそろえるのは、読者が項目表と質問表のあいだを行き来しなくて済むようにするためです。質問文と同じくらい重要なのが前置きです。聞く理由が先に示されると、相手は答えを作りやすくなり、同じ質問でも尋問になりません。前置きのない質問がはぐらかされるのは、相手が答えたくないからではなく、何のために聞かれているのかが分からないからです。
| 項目 | そのまま言える質問文 | 前置き |
|---|---|---|
| M-2 | 差し支えなければ、今その数字はどのくらいでしょうか | 提案の規模感を間違えたくないので |
| E-1 | 最終的なご決裁は、どなたの承認が必要になりますか | 稟議の資料を過不足なく用意したいので |
| DC-2 | 挙げていただいた中で、どれが一番重いですか | 全部にお応えしようとすると、かえって焦点がぼやけるので |
| DP-2 | 稟議に上げてから決まるまで、通常どのくらいかかりますか | こちらの準備の段取りを合わせたいので |
| IP-1 | その作業で詰まるのは、どういう場面でしょうか | 前提を取り違えたまま提案したくないので |
| C-2 | 社内でご説明されるとき、どういう点を聞かれそうですか | ご説明しやすい形にしたいので |
最後の質問は、Championに協力を申し出る質問であると同時に、C-2の判定材料にもなります。社内で説明する場面を具体的に語れる人は、実際にその場に立っている人だからです。なお、14項目を一回の商談ですべて聞くことはしません。前章のフェーズ別の合格ラインに沿って、一商談あたり四問から六問に絞ります。質問の数を減らすより、前置きを付けるほうが場の空気には効きます。
BANT・MEDDICC・MEDDPICCとの違いと、チェック項目としての使い分け
MEDDICの周辺には似たフレームワークがいくつもあり、どれを使うべきかで迷う場面があります。ただし、チェック項目という観点で見ると違いははっきりしています。差は思想ではなく、確認する範囲と項目の粒度です。粒度が粗いフレームは初期の見込み判定には向きますが、検討が進んだ複雑商談では判定の解像度が足りません。以下に、使い分けの目安を整理します。
| フレーム | 確認範囲 | 向く商談 | チェック項目としての粒度 |
|---|---|---|---|
| BANT | 予算・決裁者・必要性・時期 | 初期の見込み判定 | 粗く、複雑商談では「決裁者は部長」で止まります |
| MEDDIC | 6要素 | 検討が進んだ案件の確度判定 | 本記事の14項目は、これを判定できる単位に割ったものです |
| MEDDICC | 6要素＋競合 | 相見積もりが前提の商談 | 競合比較の一項目を足します |
| MEDDPICC | 6要素＋競合＋書面手続き | 契約・法務・購買の手続きが重い商談 | 契約締結までの期間が着地月を左右する規模で足します |
| SPIN | 質問の型 | 課題を言葉にしてもらう場面 | チェック項目ではなく、空欄を埋めに行くときの聞き方として併用します |
使い分けの基準は一行で足ります。関係者が三人以上、検討が一か月以上、金額が担当者の決裁枠を超える、この条件に当てはまるならMEDDICを使い、当てはまらないならBANTで十分です。
チェックリストが形骸化する原因と、続く運用
チェックリストは作った直後には機能します。項目が具体的で、未達が見えて、次の一手が決まるからです。ところが数か月で形だけになる例が非常に多く、その原因は商談の現場ではなく運用側にあります。原因は二つで、どちらも「埋めさせる圧力」が生む副作用です。前の章までで作った14項目・出所の三段階・未達への対応表は、そのまま運用の道具として使えます。逆に言えば、運用の設計を間違えると、これらは全部使われないまま残ります。
CRMの入力項目にすると、埋めることが目的になる
チェックリストを作ると、まずCRMの入力必須項目にしたくなります。ところが空欄が指摘される仕組みにすると、担当者は推測で埋めます。前の章の分類でいえばCの記入が一気に増え、しかも書式は事実と同じなので、レビューでは見分けが付きません。埋まっている案件の割合は上がりますが、当たらないチェックリストが完成します。
必須にすべきなのは項目ではなく出所です。空欄のままでよい、ただし埋めるならA・B・Cのどれかを付ける、という運用にします。埋める圧力が下がるぶん、記入の精度は上がります。CRMへの記録を標準化するという方針そのものは正しいのですが、標準化する対象を項目の埋まり具合から出所の明示に移すだけで、同じ入力欄が別の意味を持ちます。
案件レビューは「空欄を責める場」ではなく「空欄を埋める段取りを決める場」
もう一つの原因はレビューの進行です。案件レビューが空欄の指摘会になると、担当者は空欄を隠すようになります。事前に埋めてから出席するようになれば、レビューは実態から離れます。レビューで聞くべきは、なぜ空欄なのかではなく、この空欄をいつ、誰に、何と言って埋めるのか、です。
進行はそのまま前章の対応表を使えます。マネージャーの質問を「E-2が未達ですね」から「E-2を合格にするために、次の商談で誰に何を頼みますか」に変えるだけで、レビューは詰問から段取りに変わります。個別の支援やフィードバック設計といった言葉で語られる話は、実務ではこの質問の言い換え一つに集約できます。
最後にまとめます。第一に、6要素はカテゴリ名なので、判定できる14項目に割り直します。第二に、判定の前に「誰が言ったか」を見て、本人・伝聞・推測の三段階を分けます。第三に、未達はフェーズ別の合格ラインで見て、足りない項目を次の商談の議題にします。チェックリストは案件の成績表ではなく、次の商談の準備リストです。未達は失点ではなく、次に何を聞きに行くかを教えてくれる情報です。
あわせて読みたい
＼ 最新情報をチェック ／
