MEDDIC/MEDDPICC — エンジニアが知るべきセールスフレームワーク
「……失注だって?」
ソウタは Slack の通知を二度読みした。画面には営業チームからのメッセージが表示されている。
@channel Nextera Healthcare 案件は失注となりました。競合の DataForge に決定したとのことです。
3週間かけて PoC 環境を構築した。深夜までデモスクリプトを磨き上げた。技術評価では「圧倒的に優れている」と先方のエンジニアから賞賛された。それなのに、負けた。
「なぜだ……技術では勝っていたはずなのに」
ソウタがオフィスで呆然としていると、カイが隣の席に座った。
「Nextera の件、聞いたよ」
「カイさん、意味がわかりません。先方の CTO の田村さんは完全にうちの味方でした。技術評価でも全項目で上回っていたのに」
カイは静かに頷いた。
「ソウタ、一つ聞いていいか。田村さんの上——最終的に予算を承認する人は誰だった?」
「えっと……COO の方だったと思います。名前は確か……」
「会ったことは?」
沈黙が流れた。
「……ないです」
カイはコーヒーを一口飲んでから言った。
「それが敗因だ。Technical Champion は掴んでいた。でも Economic Buyer——予算の最終決裁者にリーチできていなかった。DataForge はそこを押さえていた」
WARNING
技術的に優れていても、購買の意思決定構造を理解していなければ負ける。これはエンジニアが最も見落としがちなポイントだ。
なぜエンジニアにセールスフレームワークが必要なのか
「技術で勝てば案件は取れる」——ソウタはそう信じていた。多くのエンジニアがそう思っている。
しかし現実は違う。B2B SaaS の購買決定は、技術評価だけでは決まらない。予算、社内政治、法務審査、競合比較、ROI の定量化——複数の要素が絡み合う。
カイはホワイトボードに向かった。
「FDE がセールスフレームワークを理解すると、3つの変化が起きる」
「今日教えるのは MEDDIC——B2B セールスで最も実績のあるフレームワークの一つだ。もともとは PTC というソフトウェア会社で生まれた手法で、エンタープライズセールスの世界では事実上の標準になっている」
MEDDIC とは
MEDDIC は6つの要素の頭文字を取ったものだ。
- M — Metrics(メトリクス)
- E — Economic Buyer(エコノミックバイヤー)
- D — Decision Criteria(意思決定基準)
- D — Decision Process(意思決定プロセス)
- I — Identify Pain(ペインの特定)
- C — Champion(チャンピオン)
「重要なのは、この6つすべてに FDE が貢献できるということだ。むしろ FDE にしかできない貢献がある」
INFO
MEDDIC は「案件を評価するフレームワーク」であると同時に「案件を前に進めるためのフレームワーク」でもある。各要素が埋まっていない=リスクがある、と読む。
M — Metrics:定量的なビジネス成果
「最初の M は Metrics。顧客が求めている定量的なビジネス成果だ」
ソウタは首を傾げた。「レスポンスタイムとかスループットのことですか?」
「それは技術メトリクスだ。ここで言う Metrics はビジネスメトリクス——売上、コスト削減、生産性向上を数字で示すものだ」
FDE が Metrics で果たす役割は大きい。営業担当者が「30%のコスト削減」と口で言うのと、FDE が本番データを使って実測値を示すのでは説得力がまるで違う。
# app/services/metrics_calculator.rb
# FDE がデモ環境で顧客のメトリクスを計測するサービス
class MetricsCalculator
def self.benchmark_comparison(customer_data)
baseline = customer_data[:current_processing_time_ms]
arclight_result = ArcLight::Pipeline.process(customer_data[:sample_payload])
improvement_ratio = baseline.to_f / arclight_result.duration_ms
annual_hours_saved = calculate_annual_savings(
baseline: baseline,
improved: arclight_result.duration_ms,
daily_volume: customer_data[:daily_transaction_volume]
)
{
current_latency_ms: baseline,
arclight_latency_ms: arclight_result.duration_ms,
improvement_factor: improvement_ratio.round(1),
annual_hours_saved: annual_hours_saved,
# ↓ 経営層に刺さるのはこの数字
estimated_cost_saving_jpy: annual_hours_saved * customer_data[:hourly_engineer_cost]
}
end
def self.calculate_annual_savings(baseline:, improved:, daily_volume:)
saved_per_request_sec = (baseline - improved) / 1000.0
daily_saved_hours = (saved_per_request_sec * daily_volume) / 3600.0
(daily_saved_hours * 365).round(1)
end
end「このコードの肝は estimated_cost_saving_jpy だ。エンジニア人件費に換算した年間コスト削減額。これが経営層に刺さる Metrics だ」
INFO
FDE が提供できる Metrics の強み:実データに基づくベンチマーク、本番環境に近い条件での計測、技術的根拠のある数値。営業資料の「推定値」とは信頼度が違う。
E — Economic Buyer:予算の最終決裁者
「Nextera で負けた最大の原因がこれだ」
「Economic Buyer は予算の最終承認権限を持つ人。CTO がテクノロジー選定の権限を持っていても、1,000万円を超える予算の承認は CFO や COO が握っている——そういうケースは珍しくない」
「FDE は技術者だから、技術担当者とばかり話しがちだ。でも Economic Buyer 向けの資料——ROI サマリーやビジネスインパクトの要約——を用意することは FDE の仕事だ。技術的な裏付けがある ROI 資料は、営業だけでは作れない」
WARNING
Economic Buyer が特定できていない案件は、どれだけ技術評価が良くても予測に入れてはいけない。「誰が最終的に Yes と言うのか」が不明な案件は、コントロール不能だ。
D — Decision Criteria:意思決定の基準
「Decision Criteria は、顧客が製品を選ぶときの評価基準だ。技術要件とビジネス要件の両方がある」
「FDE の真の力は、Decision Criteria を "形成" できることだ。PoC やデモを通じて、顧客が重視すべき基準を教育できる。例えば、顧客が『レスポンスタイムが速いこと』だけを基準にしていたとする。でも FDE が PoC の過程で『エッジケースでのエラーハンドリング品質』の重要性を実証したら、それが新しい Decision Criteria に追加される。そしてその基準では、うちが圧倒的に強い」
# app/services/decision_criteria_tracker.rb
class DecisionCriteriaTracker
def initialize(deal)
@deal = deal
end
# PoC 結果から Decision Criteria を更新
def update_from_poc(poc_results)
poc_results.each do |criterion|
dc = @deal.decision_criteria.find_or_initialize_by(
name: criterion[:name], category: criterion[:category]
)
dc.update!(
weight: criterion[:weight], # 顧客の重視度(1-5)
our_score: criterion[:our_score], # 自社評価(1-5)
competitor_score: criterion[:competitor_score],
evidence: criterion[:evidence] # PoC での実証結果
)
end
end
# ギャップ分析:競合に負けている重要基準を洗い出す
def gap_analysis
@deal.decision_criteria.map do |dc|
gap = dc.our_score - dc.competitor_score
{ criterion: dc.name, weight: dc.weight,
our_score: dc.our_score, competitor_score: dc.competitor_score,
risk_level: gap.negative? && dc.weight >= 4 ? "high" : "low" }
end.sort_by { |r| r[:risk_level] == "high" ? 0 : 1 }
end
endINFO
Decision Criteria を形成するには、顧客が「なるほど、それは考えていなかった」と感じる視点を PoC の中で自然に提示する。押し付けではなく、実証を通じた気づきが最も効果的だ。
D — Decision Process:意思決定のプロセス
「Decision Process は、顧客の社内でどういうステップを経て購買が承認されるかだ」
「FDE が知っておくべきは、このプロセスのどこで技術的なインプットが必要になるかだ。セキュリティ審査では SOC2 レポートや暗号化方式の説明が必要になるし、技術評価では PoC の結果が求められる」
ソウタは気づいた。「Decision Process を把握しておけば、必要な資料を事前に準備できるということですね」
「そのとおり。後手に回ると致命的だ。セキュリティ審査で質問が飛んできてから資料を作り始めたら、1-2週間のロスになる。その間に競合が先に回答を提出していたら、印象がまるで違う」
I — Identify Pain:ペインの特定
「ここが FDE の最大の武器になる。営業は顧客の言葉でペインを聞く。でも FDE は顧客のコードを見て、インフラ構成を見て、本番のエラーログを見て——ペインを直接観察できる」
ソウタの記憶が蘇った。前月の PoC で、顧客のシステムに接続したとき、エラーログの量に驚いた。リトライ処理が延々とループしていた。顧客自身も気づいていなかった問題だった。
「あの時のことですか。ログを見せたら先方のエンジニアが青ざめていた」
「そう。営業には絶対に見えないペインだ。FDE だからこそ発見できる。そしてそのペインを解決できることを実証すれば、導入の urgency が一気に上がる」
# app/services/pain_identifier.rb
# 顧客環境の診断から Pain を自動分類するサービス
class PainIdentifier
PAIN_CATEGORIES = {
performance: { signals: %w[high_latency timeout retry_storm],
impact: "ユーザー離脱・売上機会の損失" },
reliability: { signals: %w[error_spike crash_loop data_inconsistency],
impact: "サービス停止・信頼性低下" },
scalability: { signals: %w[resource_exhaustion queue_backlog memory_pressure],
impact: "成長のボトルネック・インフラコスト増大" },
operational: { signals: %w[manual_process alert_fatigue deployment_failure],
impact: "エンジニアの生産性低下・バーンアウト" }
}.freeze
def self.analyze(diagnostic_report)
PAIN_CATEGORIES.filter_map do |category, config|
matched = diagnostic_report[:signals] & config[:signals]
next if matched.empty?
severity = matched.length * (diagnostic_report[:error_rate].to_f > 0.05 ? 6 : 2)
{ category: category, signals: matched, severity: severity,
business_impact: config[:impact] }
end.sort_by { |p| -p[:severity] }
end
endWARNING
ペインは顧客が自覚しているものだけではない。FDE が技術診断を通じて発見する「潜在ペイン」は、ディールの urgency を大きく変える。ただし、顧客の弱点を指摘する形にならないよう、伝え方には細心の注意を払うこと。
C — Champion:社内推進者
「最後の C は Champion。顧客社内で導入を推進してくれる人だ。Champion には3つの条件が必要だ」
- 影響力 — 社内で発言力がある
- アクセス — Economic Buyer に直接話ができる
- 動機 — 導入が自分の利益になる(昇進・評価・課題解決)
「田村さんには影響力と動機はあった。でも COO へのアクセスが弱かった。理想は Technical Champion と Business Champion の両方を押さえることだ」
Technical Champion 開発の3ステージ
Stage 1: 特定 — PoC やデモの場で最も質問が多く、技術的な深掘りをしてくる人。それが Champion 候補だ。
Stage 2: 教育 — 公式ドキュメントでは得られない実装のコツやアーキテクチャの設計思想を共有する。
Stage 3: 武装 — Champion が社内プレゼンで使える資料、ROI の数値、競合比較のデータを提供する。Champion は自分の言葉で語れるようになる必要がある。
MEDDPICC への拡張
「エンタープライズセールスでは2つの要素を追加した MEDDPICC を使うことが多い」
P — Paper Process:契約・調達プロセス
「Paper Process は法務審査、調達手続き、契約交渉のプロセスだ。ある調査では、B2B ディールの約28%が購買側の社内承認プロセスの問題で失注または大幅遅延している」
FDE が Paper Process に貢献できるポイントは明確だ。
- セキュリティ質問票への回答(技術的な正確性が求められる)
- アーキテクチャ図やデータフロー図の作成(法務・コンプラ向け)
- SOC2 / ISO27001 準拠の技術説明
- データ保管場所・暗号化方式の詳細資料
WARNING
Paper Process は「退屈な事務作業」に見えるが、ここで躓くディールは非常に多い。FDE が担当する技術系ドキュメントは早めに着手すること。後回しにすると全体のタイムラインが伸びる。
C — Competition:競合
「営業は市場でのポジショニングや価格比較はできる。でも技術的な競合分析——アーキテクチャの違い、スケーラビリティの限界、API 設計の哲学——これは FDE にしかできない」
「先月、Cortex ML との比較を求められた案件があった。営業は機能一覧の表を作ったけど、顧客が本当に知りたかったのは『大量データ投入時にどちらが安定しているか』だった。FDE が両製品のベンチマークを取って、具体的な数値で差を見せた。それで決まった」
FDE vs 従来のセールスロール:MEDDIC での役割分担
| MEDDIC 要素 | AE の役割 | SE の役割 | FDE の固有貢献 |
|---|---|---|---|
| Metrics | ビジネス KPI の合意 | デモでの数値提示 | 本番データでの実測値 |
| Economic Buyer | 関係構築・交渉 | 技術説明サポート | ROI の技術的根拠 |
| Decision Criteria | 基準の合意形成 | 技術要件の整理 | PoC で基準を形成 |
| Decision Process | プロセスの把握 | 技術審査への対応 | セキュリティ審査資料 |
| Identify Pain | ヒアリング | デモでのペイン訴求 | 現場で直接ペインを観察 |
| Champion | 関係構築 | 技術的信頼の獲得 | 深い技術教育で育成 |
| Paper Process | 契約交渉 | 技術ドキュメント | セキュリティ質問票回答 |
| Competition | 市場ポジショニング | 機能比較表 | 技術ベンチマーク |
SE は "説明" するのが仕事で、FDE は "実証" するのが仕事だ。FDE のアウトプットは常にエビデンスベースになる。それが最大の違いだ。
INFO
FDE の固有貢献の共通点は「実証ベース」であること。コード・データ・ベンチマークという具体的なエビデンスを提供できるのが、FDE がセールスプロセスで持つ最大の武器だ。
ディールスコアリングシステム
「各要素を 0〜3 で採点する。0 は情報なし、3 は完全に把握・コントロールできている状態。8要素 × 最大3点 = 満点24点。フォーキャストに含めるには 70% 以上——17/24 以上が目安だ」
| スコア | 意味 |
|---|---|
| 0 | 情報なし。まったく把握できていない |
| 1 | 部分的に把握。裏付けが不十分 |
| 2 | 概ね把握。一部に不確実性が残る |
| 3 | 完全に把握。エビデンスあり |
Rails でディールスコアリングを実装する
ソウタは Arclight AI の社内ツールとして、MEDDPICC スコアリング機能を構築した。
# app/models/deal.rb
class Deal < ApplicationRecord
has_many :decision_criteria, dependent: :destroy
has_many :paper_process_items, dependent: :destroy
belongs_to :account_executive, class_name: "User"
belongs_to :fde, class_name: "User", optional: true
MEDDPICC_ELEMENTS = %w[
metrics economic_buyer decision_criteria decision_process
identify_pain champion paper_process competition
].freeze
MAX_SCORE = MEDDPICC_ELEMENTS.length * 3 # 24
MEDDPICC_ELEMENTS.each do |element|
validates :"#{element}_score", inclusion: { in: 0..3 }, allow_nil: true
end
def meddpicc_total_score
MEDDPICC_ELEMENTS.sum { |e| send(:"#{e}_score") || 0 }
end
def meddpicc_percentage
(meddpicc_total_score.to_f / MAX_SCORE * 100).round(1)
end
def forecast_eligible?
meddpicc_percentage >= 70.0
end
def risk_elements
MEDDPICC_ELEMENTS.select { |e| (send(:"#{e}_score") || 0) <= 1 }
end
def health_status
pct = meddpicc_percentage
return :strong if pct >= 80
return :healthy if pct >= 70
return :at_risk if pct >= 50
:critical
end
end# app/controllers/deals_controller.rb
class DealsController < ApplicationController
def index
@deals = Deal.includes(:account_executive, :fde)
.where(stage: %w[evaluation negotiation])
.order(close_date: :asc)
@summary = {
total_pipeline: @deals.sum(:amount),
forecast_eligible: @deals.select(&:forecast_eligible?),
at_risk: @deals.select { |d| d.health_status == :at_risk },
critical: @deals.select { |d| d.health_status == :critical }
}
end
def update_scores
@deal = Deal.find(params[:id])
Deal::MEDDPICC_ELEMENTS.each do |element|
score = params.dig(:deal, :"#{element}_score")
@deal.send(:"#{element}_score=", score) if score.present?
end
if @deal.save
redirect_to @deal, notice: "MEDDPICC スコアを更新しました"
else
render :show, status: :unprocessable_entity
end
end
endINFO
スコアは定期的に更新すること。週次のパイプラインレビューで AE と FDE がスコアを確認し、低スコアの要素に対して具体的なアクションを決める。スコアは「成績表」ではなく「次のアクションを決めるためのツール」だ。
AWS 上でのダッシュボード構成
ソウタはダッシュボードのインフラ構成も考えた。Arclight AI は AWS をメインで使っている。
社内ツールだが、営業チームは外出先からもアクセスする。CloudFront + ECS Fargate でスケーラブルかつ低運用負荷な構成にした。ディールのスコア履歴は RDS に蓄積し、ダッシュボードの集計クエリは ElastiCache でキャッシュする。
MEDDPICC ワークフロー:FDE の貢献マップ
カイが最後にホワイトボードに全体像を描いた。
「FDE の日常的な技術活動——PoC、データ分析、ドキュメント作成——が、MEDDPICC の複数の要素に同時に効いている。だから FDE がセールスフレームワークを理解すると、同じ技術活動でもアウトプットの質がまるで変わる」
実践:週次スコアリングレビュー
カイは週次レビューの進め方を教えた。
# app/services/pipeline_review.rb
class PipelineReview
def self.generate_agenda(deals)
deals.map do |deal|
risk_items = deal.risk_elements
{
deal_name: deal.name,
total_score: "#{deal.meddpicc_total_score}/#{Deal::MAX_SCORE}",
health: deal.health_status,
forecast_eligible: deal.forecast_eligible?,
risks: risk_items.map { |e| e.tr("_", " ").capitalize },
recommended_actions: recommend_actions(risk_items)
}
end
end
def self.recommend_actions(risk_elements)
risk_elements.map do |element|
case element
when "economic_buyer" then "EB との面談を AE 経由で設定する"
when "metrics" then "PoC 結果から ROI 数値を算出する(FDE)"
when "champion" then "技術 Deep Dive で Champion 候補を育成(FDE)"
when "paper_process" then "セキュリティ質問票の回答を開始(FDE)"
when "competition" then "技術ベンチマーク比較資料を作成(FDE)"
when "identify_pain" then "顧客環境の技術診断を提案(FDE)"
when "decision_process" then "承認フローと関係者を確認(AE)"
when "decision_criteria" then "評価基準の一覧を顧客に確認"
end
end
end
endINFO
レビューで重要なのは「スコアが低い」と嘆くことではなく、「スコアを上げるために来週何をするか」を具体的に決めること。FDE が担当できるアクション(PoC、技術診断、ドキュメント作成)は即効性のある打ち手だ。
Nextera 案件の振り返り
セッションの終わりに、カイとソウタは Nextera の案件を MEDDPICC で振り返った。
# Nextera Healthcare 案件の MEDDPICC スコア(振り返り)
nextera_scores = {
metrics: 2, # PoC で改善率は示した。年間コスト削減額は未算出
economic_buyer: 0, # COO にアクセスできていなかった ← 致命的
decision_criteria: 3, # 技術評価では全項目クリア
decision_process: 1, # 技術評価後のプロセスを把握していなかった
identify_pain: 2, # 技術的ペインは特定。ビジネスペインへの変換が弱い
champion: 2, # CTO は味方だが EB へのアクセスが弱い
paper_process: 0, # 着手していなかった
competition: 1 # DataForge の存在は知っていたが分析不足
}
total = nextera_scores.values.sum # => 11/24 = 45.8%
# forecast_eligible? => false(70% 未満)「11/24——45.8%。とてもフォーキャストに入れられる状態じゃなかった」
ソウタは数字を見つめた。「事前にこのスコアリングをやっていたら、Economic Buyer のスコアが 0 だと気づけた。そこにリソースを集中できたはずなのに」
「そう。MEDDPICC は予言の道具じゃない。"何が足りないか" を早期に発見して、手を打つためのフレームワークだ」
INFO
失注の振り返りを MEDDPICC で行うと、感情論(「頑張りが足りなかった」「相性が悪かった」)ではなく、構造的な改善点が見える。同じ失敗を繰り返さないために、必ず振り返りを行うこと。
まとめ:技術力 × セールス理解 = 最強の FDE
帰り際、ソウタはカイに言った。
「正直、セールスフレームワークなんてエンジニアには関係ないと思っていました」
カイは立ち止まった。
「最高の技術を持っていても、それが正しい人に、正しいタイミングで、正しい文脈で届かなければ意味がない。MEDDPICC はその "届け方" の地図だ。FDE は技術の専門家であると同時に、技術の価値を翻訳して届ける専門家でもある」
ソウタは Nextera の失注を思い出した。もう同じ過ちは繰り返さない。
次の案件——MedCore Systems との商談が来週から始まる。今度は PoC に入る前に MEDDPICC スコアをつけて、Economic Buyer を特定するところから始める。
技術力だけでは勝てない。しかし、技術力にセールスの理解を掛け合わせた FDE は、誰にも止められない。
次章では、FDE が大規模案件で必ず直面する「エンタープライズセールスサイクル」の全体像——リードから契約締結までの長い旅路を、ソウタと共に歩んでいく。