KPI定義のすり合わせ｜同じ指標なのに数字が食い違う理由

たとえば、営業の資料では今月の商談化が58件。ところがマーケのダッシュボードでは74件。

架空の例ですが、同じ会社の同じ月の数字としてはよくある光景です。

こういうとき最初に始まるのが、どちらの集計が間違っているのかという犯人探しです。ところが調べてみると、たいていどちらも正しく数えていて、数えている対象が違うだけだったりします。

この記事では、GTM（Go-To-Market：製品を市場へ届けるまでのマーケ・営業・カスタマーサクセスの一連の活動）の現場で数字が食い違う原因を分解します。そのうえで、指標の定義書をどう書き、部門をまたいでどう合意を取るかまでを扱います。

RevOps（Revenue Operations：部門ごとに分かれている売上プロセスを一つの運用としてつなぐ役割）を立ち上げるなら、最初に手をつける価値がいちばん高い仕事でもあります。

集計ミスより、定義のずれのほうが多い

数字が合わないと聞くと、まずツールの設定やクエリを疑いたくなります。もちろんそれもゼロではありません。

ただ実務で遭遇する食い違いの大半は、同じ言葉に別の定義がぶら下がっていることが原因です。

商談化という一語をとっても、営業は初回の打ち合わせが実施された時点を指し、マーケは打ち合わせの日程が入った時点を指していることがあります。どちらの定義にも業務上の理由があります。

やっかいなのは、この違いが会話に出てこないことです。お互い自分の定義が当たり前すぎて、わざわざ確認しません。

だから会議のたびに数字がずれ、そのたびに30分が溶けます。そして誰も定義を直さないまま、来月また同じ会話をする。

心当たりがあるなら、それは組織の能力の問題ではありません。定義を書いた紙が存在しないというだけの、わりと単純な問題です。

ずれを放置すると、意思決定が止まる

数字が食い違う組織では、会議の時間が説明に食われます。本来なら打ち手を決める時間です。

もっと深刻なのは、数字そのものが信用されなくなること。誰も信じていないダッシュボードは、そのうち誰も開かなくなります。

そうなると意思決定は、声の大きい人の感覚に戻ります。データ基盤にいくら投資しても、この一点でひっくり返ります。

ずれが生まれる場所は、だいたい四つ

原因を一つずつ探すと骨が折れますが、発生源はほぼ決まっています。四つの型を知っておくと、突き合わせの時間が一気に短くなります。

順に見る前に、全体像を並べておきます。

この四つのうち、議論が長引きやすいのは帰属です。広告とメールと検索のどれに1件を割り当てるかで、部門ごとの成果が変わってしまうからです。

帰属ルールの決め方そのものはアトリビューションの実務｜完璧を諦めて意思決定に使うで扱っているので、ここでは深追いしません。定義のすり合わせという観点では、ルールを一つに決めることより、どのルールを使ったかを数字に明記することのほうが大事です。

対象のずれ: 何を1件と数えるか

いちばん頻度が高いのがここです。分母や分子に何が入っているかが、部門ごとに違います。

たとえばリード件数。マーケは資料請求も無料トライアル登録もイベント来場も含めて数え、営業は電話がつながる見込みのある問い合わせだけを数えている。

どちらかが悪いわけではありません。ただ、同じリードという単語で会話している限り、永遠に噛み合いません。

とくに揉めやすいのがMQL（Marketing Qualified Lead：マーケ側が営業に渡してよいと判断したリード）の線引きです。この基準づくりはMQLの引き継ぎ設計｜マーケと営業が揉めない基準づくりにまとめました。

見落とされがちなのが除外の扱いです。社内アカウント、テスト送信、競合や採用目的の問い合わせ。

除外リストが片方にしかないと、それだけで数十件の差が出ます。

期間と重複排除のずれ

期間のずれは、基準にする日付が違うことで起きます。申込みが発生した日で数えるのか、承認された日で数えるのか。

月末月初にまたがる案件があると、この違いがそのまま件数の差になります。

もう一つ、遅れて入るデータの扱いも要注意です。月初に見た先月の数字と、二週間後に見た同じ月の数字が違う。

これは異常ではなく、あとから登録された案件が反映されただけです。だからいつ時点のスナップショットかを数字に添える運用にしておくと、無用な混乱が減ります。

重複排除は、集計のキーが何かという話です。同じ人が三回フォームを送ったら1件か3件か。

同じ会社から五人が問い合わせたら、5件か1件か。営業は会社単位で見ていて、マーケは人単位で見ている、という組み合わせは本当によくあります。

指標定義書は、集計できる形まで書く

定義を揃えようという話になると、たいてい言葉の定義から始まります。ところが言葉だけの定義は、必ず解釈が割れます。

有効なリード数とは質の高い問い合わせのこと、と書いても、来月同じ数字は出せません。

だから最初から、そのまま集計クエリに落とせる粒度まで書きます。一つの指標につき、A4で半ページもあれば足ります。

以下は架空の会社を想定した記入例です。項目の並びだけ持ち帰ってもらえれば十分です。

指標名: 商談化数（Meetings Held）  ※記入例
一文の説明: 営業担当が初回商談を実施し、実施済みに更新した件数

対象: 商談オブジェクトのうち status = held のもの
除外: 社内テスト、既存顧客のアップセル商談、キャンセル後の再設定分（親商談で1件）
期間の基準: held_at（実施日）。作成日ではない
重複排除のキー: opportunity_id（人でも会社でもない）
帰属ルール: 紐づくリードの初回接触チャネル（first touch, 2026-04版）
データの出どころ: CRMの商談テーブル
確定タイミング: 翌月5営業日で確定。それ以前は速報値
所有者: RevOps 田中 / 最終更新 2026-07-15

このうち省略されがちなのが、確定タイミングと所有者です。この二行があるだけで、数字が動いたときの問い合わせ先が決まります。

指標をツリー状に分解して整理する話はプロダクト指標の設計｜北極星指標とKPIツリーの作り方で扱っています。定義書は、そのツリーの各ノードに一枚ずつ付く付箋のようなものだと考えてください。

速報値と確定値を、最初から分けておく

数字が合わない原因の一つに、締めの前後で見ているという単純なものがあります。これは定義書で先に切り分けられます。

用途によって、求められる速さと正確さが違うからです。

速報値を否定する必要はありません。速報値と確定値が違うのは正常だと全員が知っている状態にするのが目的です。

そのためには、ダッシュボードの数字の隣に速報か確定かを表示しておくのがいちばん確実です。

差分は、感覚ではなく分解して潰す

定義を揃える作業は、いきなり理想形を決めても進みません。目の前の食い違いを一件ずつ分解するほうが、圧倒的に早く合意できます。

冒頭の58件と74件、差の16件をどう扱うか。仮の数値で、実際の突き合わせをやってみます。

マーケ集計: 74件  /  営業集計: 58件  /  差分: 16件

内訳を突き合わせた結果（すべて仮の例）
  1. 日程は入ったが未実施・キャンセル ........ 9件
     → マーケは日程確定で計上、営業は実施で計上
  2. 既存顧客へのアップセル商談 .............. 4件
     → 営業の新規商談レポートからは除外されていた
  3. 月またぎ（6/30日程確定・7/2実施） ....... 3件
     → 基準日が created_at か held_at かの違い
  合計 ........................................ 16件（差分と一致）

大切なのは、最後の行です。分解した合計が差分とぴったり一致するまで続けるのが条件になります。

一致しない残りが3件でもあれば、そこにまだ未知のずれが隠れています。ここでだいたい合ったからよしとしないのが、この作業の勘所です。

そして一致したあとに決めるのは、どちらが正しいかではありません。それぞれをどの用途で使うかです。

日程確定ベースの数字はマーケの週次の打ち手判断に向いています。実施ベースの数字は事業レビューと売上予測に向いています。

名前を変えて両方残す。それだけで、この手の揉め事はたいてい収まります。

合意には、進める順番がある

定義の統一は、正しさより進め方で決まります。全指標を一度に揃えようとすると、まず終わりません。

実際に動く順番は、だいたいこうなります。

• 全社で使われている指標を棚卸しし、食い違いが実害を出している3つに絞る
• 指標ごとに所有者を1人だけ決める（部門ではなく個人名で）
• 会議の前に、所有者が定義書のたたき台を書いて配る
• 会議では、差分の分解結果を見ながら用途の割り当てだけを決める
• 適用開始日を決め、過去分を遡って再計算するかどうかも同時に決める

三つ目が抜けると、会議がゼロから定義を作る場になって発散します。議論の材料は事前に作っておくのが鉄則です。

最後の項目も忘れないでください。過去分を再計算すると、去年の資料と数字が変わります。

再計算しないなら、切り替え日を境にグラフに縦線を引いておく。どちらでも構いませんが、決めずに進めるのがいちばん困ります。

会議で決まらないときの逃げ道

どうしても片方に寄せられない指標もあります。営業の評価に直結する場合は特にそうです。

そのときは無理に一本化せず、両方を別名で正式指標として登録するのが現実的です。商談化数（日程確定ベース）と商談化数（実施ベース）のように、名前に定義を埋め込みます。

一本化を諦めるかわりに、暗黙の定義をゼロにする。実務ではこちらのほうが揃います。

定義の土台がないと、AIは平気で違う数字を出す

GTM業務にAIを組み込む話が増えました。チャット画面をもう一つ足すのではなく、CRMやSlackやデータ基盤をまたぐ業務フローそのものに埋め込む形が現実的だと思います。

そしてその前提として効いてくるのが、共通のKPI定義とセマンティックレイヤー（各指標の計算方法を一か所にまとめ、どのツールから聞いても同じ答えが返るようにする層）です。

理由は単純です。定義が揺れているデータに自然言語で質問すると、もっともらしい形をした違う数字が返ってきます。

人間なら、あれ先月と違うなと気づきます。エージェントは気づかずに、そのままSlackへ投稿します。

だから順番としては、定義書とセマンティックレイヤーが先で、AIの導入はその後です。土台の作り方はGTMデータ基盤｜AIが正しく動くための土台づくりにまとめました。

どこに人間の承認を残すか

全部を自動化しないことが、実際の成否を分けます。判断が外に出る手前に、必ず人を挟みます。

具体的には、次の三つを人の承認が要る場面として決めておくと運用しやすくなります。

• 社外へ送るメッセージ（メール、チャット、提案書）
• 金額や契約条件に関わるレコードの更新
• 経営会議や社外報告に出る数字

どれも下書きまでは自動で構いません。送信や確定の一押しだけを人間が持つ、という切り分けです。

逆に、社内向けの下書き生成やデータの整形、入力作業の代行は止める理由がありません。入力の手間が減った結果としてデータが溜まりはじめる、というのは実際によく起きる順序です。

導入の前には、シャドーモードで走らせる期間を置くと安全です。エージェントに実行させず提案だけ出させて、人間の判断とどれくらい一致するかを見ます。

評価に使うのは、既知の質問と正解のセットです。先月の新規商談は何件か、といった答えが確定している質問を20問ほど用意して、定義書どおりの数字が返るかを確かめます。

ここで外すなら、原因はAIではなく定義です。エージェントの精度をいじる前に、定義書へ戻ってください。

人の判断手順を、先に文章にする

もう一つ、効き目のわりに地味な準備があります。社内でいちばん判断の速い人が、どの順番で何を見ているかを文章に起こすことです。

その手順が書けないうちは、エージェントに写しようがありません。逆に書けてしまえば、自動化する前の段階でチーム全体の精度が上がります。

対象は、頻度が高く、手順が毎回同じで、遅れるほど損が出る業務に絞るのが定石です。全社一斉より、深く狭く入れるほうが結果が出ます。

サイト側の行動も、同じ定義書に載せる

CRMの中の数字ばかり議論して、ウェブサイト側の指標が置き去りになることがあります。ところが流入元やコンバージョンの定義こそ、部門で解釈が割れやすい領域です。

同じ問い合わせでも、広告経由と数えるか自然検索経由と数えるかで、評価が変わります。

Strideはこの層、つまりサイト上の匿名の行動を正しく測る部分を担当します。ファネルの各ステップの到達と離脱、流入元の自動分類（検索・広告・メール・SNS・外部サイト・直接）、訪問者一人の行動をセッションをまたいで追う分析までがカバー範囲です。

一方で、リードを個人として特定してCRMへ紐づけたり、メールを配信したり、商談を管理したりはしません。CRMやMAツールと組み合わせて、サイト側の定義を供給する層として置くのが正しい使い方です。

計測タグはCookieを使わず、氏名やメールアドレスといった個人情報も集めません。IPは国の判定に一時的に使うだけで保存しない設計です。

また、MCPに対応しているので、先月の広告経由の申込みフォーム到達率を出して、といった依頼をClaudeなどのAIから直接投げられます。定義書が整っていれば、この問い合わせの答えは誰が聞いても同じになります。

まとめ

同じ指標で数字が食い違う原因は、集計ミスではなく定義のずれです。対象、期間、重複排除、帰属の四か所を疑えば、たいてい見つかります。

定義書は言葉ではなく、そのまま集計に落とせる粒度まで書く。除外条件、基準日、重複排除のキー、確定タイミング、所有者まで含めて一枚にします。

差分は感覚で埋めず、内訳を分解して合計が一致するまで詰める。そのうえで、どちらが正しいかではなく、どちらをどの用途に使うかを決めます。

一度に全部を揃える必要はありません。実害が出ている指標を三つ選んで、所有者を決めるところから始めてみてください。