こんにちは。ろっさんです。
今回は、「顧客の声を聞いたのに、なぜ外すのか｜JTBDと因果推論で作る検証される顧客洞察」と言うタイトルで解説していきます。長い記事ですがぜひ最後までお付き合いください！
0. はじめに｜「ヒアリングはしたんです。なのに刺さらなかった」
合格1年目の診断士が、ある金属加工業のA社を支援している場面を想像してみてください。従業員22名、売上2億円、主力顧客1社が売上の47%を占める町工場。勤続20年を超える熟練工が2名いて、その2人の手作業が品質の生命線になっている——そんな会社です。
経営者からの相談はシンプルでした。「新規の取引先を増やしたい。うちの強みは品質だと思うので、それを前面に出した提案資料を作ってほしい」。
私が最初にやったのは、王道のセグメント分析でした。業種別・規模別・地域別に見込み先を分類し、「中堅の精密機器メーカー向けに、高品質・短納期を訴求する」という方針を立てました。経営者にもヒアリングをしました。資料も丁寧に作りました。やるべきことはやった——そう思っていました。
ところが、提案先の反応は鈍いものでした。話を聞いてはくれる。でも「検討します」で止まる。あとで一社の調達担当者にそれとなく理由を聞くと、こう言われました。「品質がいいのは、御社に限った話じゃないんですよ。うちが本当に困っているのは、別のところでして」。
何が起きていたのか。私は「A社の強み」から出発して「誰に売るか（セグメント）」を決めていました。しかし顧客が本当に語っていたのは、「自分たちはどんな状況で、何を片付けたくて、何に邪魔されているか」——属性ではなく、文脈でした。
ここに、顧客理解の根本的な分かれ道があります。顧客を「属性の集合（セグメント）」として捉えるか、「片付けたい用事（ジョブ）を抱えた状況」として捉えるか。 この出発点の違いが、その後の調査・分析・提案のすべての精度を決めます。
そして、もうひとつ。「ヒアリングで良い話を聞けた」ことと「その洞察が正しい」こととは、まったくの別物です。都合の良い話だけを拾い、「刺さるストーリー」に仕立て、検証せずに意思決定へ持ち込む——これは私自身が一度通った道であり、多くの現場で繰り返されている失敗です。
本記事は、これまで個別に公開してきた3本の記事——「JTBDで顧客を深く理解し、定性・定量データ統合で洞察を生む方法」、「JTBDと定性・定量分析で解約理由を解明する顧客理解」、「顧客理解を深めるJTBDとデータ分析：洞察を仮説検証へ繋ぐ実践プロセス」——を、ひとつの「検証される顧客洞察」の設計論として統合して描き直す長編です。扱うトピックは次の通りです。
- 顧客理解を「セグメント」ではなく「JTBD（状況・進歩・障害）」で定義し直す
- 追加論点A：JTBDの2流派——Christensen流（状況・文脈の発見）とUlwick流ODI（望む結果の定量化・Opportunity Score）の使い分け
- 定性調査の設計——インタビュー・観察でジョブを掘り起こし、バイアス（都合の良い話だけ拾う）を回避する
- 定量分析の設計——ログ・購買・問い合わせデータを統合し、解約理由の仮説を立てる
- 追加論点B：カウンターファクチュアル思考と因果推論——相関≠因果、Rubin因果モデル、A/Bテストと差分の差分法、Simpson’s Paradox
- 洞察を「刺さるストーリー」で終わらせず、仮説として形式化し、実験と「やる／やらない基準」へ落とす
- 22名・主力顧客47%依存のA社で、この顧客理解の仕組みを回す組織設計（組織論応用）
この記事を貫く主張を、先に一行で言ってしまいます。「顧客の声を聞くこと」と「顧客を理解すること」は別であり、「洞察を得ること」と「その洞察が正しいこと」はさらに別である。 多くの現場は、この2つの“別”を飛ばして、聞いた声をそのまま物語にし、物語をそのまま意思決定にしてしまいます。本記事は、声と理解のあいだに「JTBD」を、洞察と正しさのあいだに「因果推論と仮説検証」を挟み込むための、ひとつながりの設計図です。
理論は基礎から段階的に、A社の事例と日常のたとえを交えながら積み上げます。試験で学んだマーケティングと統計を、合格後の現場で「外さない洞察を作る道具」に変えるための知的再武装として読んでいただければと思います。
1. なぜセグメントでは外すのか——「ジョブ」という見方
まず、JTBD（Jobs To Be Done）という考え方を、抽象的な定義から丁寧に置きます。
JTBDの中心命題はこうです。「顧客は商品を買うのではない。ある状況で生じた進歩（progress）を成し遂げるために、商品を“雇う（hire）”のだ」。 顧客が片付けたい用事そのものを「ジョブ」と呼びます。ジョブは「状況（どんな場面で）」「進歩（何を成し遂げたいか）」「障害（それを邪魔しているもの）」の3要素で記述します。
これは試験で習う「ニーズ」とどう違うのか。ニーズは「高品質を求めている」のように、しばしば属性や形容詞で語られます。ジョブは「来月の量産立ち上げで不良を出すと、自分が責任を問われる。だから初回ロットで品質を保証してくれる先に頼みたい」のように、状況と動機を含む“文章”で語られます。後者のほうが、なぜその選択をするのかという因果が見えます。
セグメント発想の限界を、たとえ話で説明します。ある人が朝、ファストフード店でミルクシェイクを買う。「30代・男性・年収◯◯万円」という属性をいくら積み上げても、なぜ朝にシェイクなのかは分かりません。実際にこの謎を解いた有名な調査（クリステンセンらが紹介したミルクシェイクの事例）では、観察の結果、「長い車通勤の退屈をしのぎ、昼まで空腹を持たせる」というジョブが見つかりました。競合はコーラやコーヒーではなく、バナナや退屈そのものだった——属性では永遠に見えない答えです。
A社に戻します。冒頭で私は「品質を訴求する」と決めました。これは「品質を重視する見込み客セグメント」を狙う発想です。しかし調達担当者が抱えていたジョブは、おそらくこうでした。「状況：主要部品の既存サプライヤーが1社で、その1社が止まると自分のラインが止まる。進歩：供給リスクを分散し、上司に『二社購買体制にしました』と報告できる状態にしたい。障害：新規サプライヤーの品質が読めず、切り替えの稟議が通しにくい」。
このジョブが見えると、A社が訴えるべきは「品質が高い」ではなく、「初回ロットの品質を数値保証し、稟議を通すためのエビデンス（検査記録・工程能力指数）をこちらから揃えて出す」だと分かります。顧客の本当の用事は“品質”ではなく“稟議を通して供給リスクを分散すること”であり、品質はその手段にすぎなかったのです。
ここで、なぜセグメントだと外れやすいのかを、もう一段だけ構造的に押さえておきます。セグメントは「属性が同じ人は同じように買う」という暗黙の前提に立っています。しかし現実には、同じ「中堅・精密機器・関東」というセグメントの中に、「供給リスクを分散したい人」「単価を1円でも下げたい人」「設計変更の手間を減らしたい人」が混在しています。属性は同じでも、抱えているジョブはバラバラです。だからセグメント単位で打ち手を決めると、平均的に誰にも刺さらない「最大公約数の提案」になります。私が冒頭で作った「高品質・短納期」という資料が典型でした。誰も否定はしないが、誰の用事も解決していない。
逆に、ジョブは「属性が違っても、同じ状況なら同じ進歩を求める」という見方をします。精密機器メーカーの調達担当者と、建設機械メーカーの調達担当者は、業種という属性は違いますが、「主要部品が1社購買で供給が止まると自分の責任になる」という状況とジョブは同じかもしれません。ジョブで括ると、業種をまたいで「同じ用事を持つ顧客群」が見えてきます。これがB2Bの新規開拓で効きます。属性で似た会社を探すのではなく、同じジョブを持つ会社を業種横断で探す。A社のような小さな会社にとって、これは「狭い業界の中で消耗戦をしない」ための重要な発想転換です。
セグメントは「誰が」を教えてくれますが、「なぜ買うのか／なぜ買わないのか」は教えてくれません。JTBDはここを反転させます。次章では、このJTBDに実は2つの流派があり、診断実務では場面で使い分ける必要があることを説明します。
2. 追加論点A｜JTBDには2流派ある——Christensen流とUlwick流ODI
JTBDを学ぶと、しばしば「JTBD＝ミルクシェイクの話」で止まってしまいます。しかし実務で使うには、JTBDに2つの流派があり、目的が異なることを理解しておく必要があります。
(1) Christensen流——状況・文脈の「発見」
クレイトン・クリステンセンらの流れは、「どんな状況で、なぜその商品を“雇った”のか」を発見することに主眼を置きます。手段はインタビューと観察。特に「最後に購入を決めた瞬間、その前に何が起きていたか」を時系列で語ってもらう手法（しばしば「スイッチのタイムライン」と呼ばれます）が中心です。何が問題なのかまだ分かっていない探索フェーズで強みを発揮します。
A社での応用：取引先の調達担当者に「御社に発注を切り替える、あるいは見送るとき、その直前に社内で何が起きていましたか」を時系列で語ってもらう。すると「設計変更が頻発して、そのたびに図面のすり合わせに3往復かかるのが本当に手間だった」「稟議で品証部門に止められた」といった、本人も明確に意識していなかった文脈（ジョブ）が立ち上がってきます。これは仮説を“生み出す”作業です。
(2) Ulwick流・ODI（Outcome-Driven Innovation）——望む結果の「定量化」
トニー・アルウィックの流れは、ジョブを機能的・感情的・社会的な側面に分解し、さらに「顧客が望む結果（アウトカム）」を測定可能な指標として書き出し、定量調査でスコアリングします。何が問題かはおおよそ見えていて、「どの機会が一番大きいか」を客観的に決めたい評価フェーズで強みを発揮します。
ジョブの分解の例（A社の調達担当者）：
- 機能的ジョブ：必要な部品を、必要な品質で、必要な納期に確保する
- 感情的ジョブ：「あのサプライヤーで本当に大丈夫か」という不安を減らしたい
- 社会的ジョブ：上司や品証部門に「適切な調達をしている」と見られたい
Christensen流を現場で運用するとき、私が頼りにしている補助フレームが「進歩を阻む／促す4つの力」です。顧客が今のやり方から新しいやり方へ“スイッチ”するかどうかは、4つの力の綱引きで決まると考えます。
- プッシュ：現状への不満（既存サプライヤーが1社で供給が不安、対応が遅い）
- プル：新しい解への魅力（A社なら初回ロットの品質保証を出してくれる）
- 不安：乗り換えへの不安（新規取引先の品質が読めない、トラブル時に困る）
- 惰性：変えない方が楽という慣性（今の取引先で大きな問題は起きていない、稟議が面倒）
多くの提案は「プル」（自社の魅力）を強める努力ばかりします。冒頭の私がそうでした。しかしスイッチを止めている真犯人は、たいてい「不安」と「惰性」です。A社が本当にやるべきだったのは、品質の高さ（プル）をさらに訴えることではなく、「乗り換えの不安を消す」打ち手——初回ロットの第三者検査データを先に渡す、トラブル時の連絡フローを契約前に明文化する——でした。Christensen流のインタビューは、この4つの力のうち「どれが効いて、どれが効いていないか」を聞き分けるために使います。漠然と「困りごとは?」と聞くのではなく、4つの力を仮説の枠として持って臨むと、聞くべきことが鋭くなります。
2流派の使い分けを、私はこう整理しています。
| 場面 | 適した流派 | 問い |
|---|---|---|
| 何が問題かまだ分からない（発見フェーズ） | Christensen流 | 「どんな状況で、なぜそれを選んだ／やめたのか」 |
| 機会の大きさを定量で比べたい（評価フェーズ） | Ulwick流ODI | 「どの“望む結果”が重要なのに満たされていないか」 |
冒頭の私の失敗は、発見フェーズをすっ飛ばして自社の強み起点で評価していたことにあります。まずChristensen流で文脈を発見し、次にUlwick流でその機会の大きさを定量化する——この順序が肝心です。次章では、Ulwick流の核心である「Opportunity Score」を具体的に計算してみます。
3. 追加論点A｜Opportunity Scoreで「過小サービスの機会」を数値化する
Ulwick流ODIの実務上の最大の武器が Opportunity Score（機会スコア） です。これは「重要なのに満たされていない領域＝underserved（過小サービス）」を、定量で特定する計算式です。
調査では、顧客が望む結果（アウトカム）を一つひとつ文に書き出し、それぞれについて2つを10点尺度で聞きます。
- 重要度：その結果は、あなたにとってどれくらい重要ですか
- 満足度：現状、その結果はどれくらい満たされていますか
そして次式でスコアを出します。
Opportunity Score ＝ 重要度 ＋ max（重要度 − 満足度, 0）
ポイントは `max(…, 0)` です。満足度が重要度を上回っている（=過剰に満たされている）領域は、差をマイナスにせず0として扱う。つまり「重要なのに満たされていない」領域だけがスコアを押し上げる設計になっています。スコアが高い順に、差別化の投資対象として優先する——これがODIの意思決定ロジックです。
A社の取引先・調達担当者へのインタビューを定量化したと仮定して、計算してみます（数値は説明のための仮想例です）。
| 望む結果（アウトカム） | 重要度 | 満足度 | Opportunity Score |
|---|---|---|---|
| 品質問題の原因を、できるだけ早く教えてほしい | 9 | 3 | 9 + (9−3) = 15 |
| 設計変更時の図面すり合わせの手間を最小にしたい | 8 | 4 | 8 + (8−4) = 12 |
| 初回ロットの品質を事前に保証してほしい | 9 | 7 | 9 + (9−7) = 11 |
| 単価をできるだけ下げてほしい | 7 | 8 | 7 + max(7−8,0) = 7 |
この表が語ることは明快です。A社が「品質の良さ」（重要度9・満足度7→スコア11）を前面に押し出しても、それは相対的に“すでに満たされている”領域です。一方、最高スコアは「品質問題の原因をすぐ教えてほしい」（スコア15）。つまり調達担当者にとって最大の不満は、品質そのものよりも「問題が起きたときの報告のスピードと透明性」だった、ということになります。
ここから導かれる差別化戦略は、冒頭の「高品質を訴求する」とはまったく違うものになります。「不良が出たとき、24時間以内に原因の一次報告を出す。隠さず、推測でも構わないので最速で共有する」——これが最も大きな“過小サービスの機会”です。価格（スコア7）は、すでに過剰供給気味で、ここで戦っても消耗するだけだと数字が教えてくれます。
スコアの読み方にも、診断士として一段の注意が要ります。第一に、スコアの絶対値ではなく順位と差で読むこと。15と12の差は実務的に意味がありますが、12と11.5の差を「2位より3位が劣る」と断じてはいけません。調査の誤差の中に埋もれる差です。第二に、取引先によってスコアの像が違う可能性を必ず疑うこと。主力顧客（売上の47%）と、それ以外の小口取引先では、最高スコアの機会が違うかもしれません。全体で平均すると、誰のジョブでもない平均像になります（これは§7のSimpson’s Paradoxと同じ構造の罠です）。だからスコアは、まず取引先の層ごとに出して見比べる。第三に、スコアが高い＝即着手ではないこと。スコアは「機会の大きさ」を示すだけで、「A社がそれを提供できるか（実現可能性）」「提供したら利益が出るか（経済性）」は別問題です。Opportunity Scoreは打ち手の優先順位づけの入口であって、結論ではありません。
注意点をもう一つ。Opportunity Scoreは「顧客が言語化できる望む結果」を前提にしています。顧客自身が気づいていない潜在的なジョブは、この定量手法では拾えません。だからこそ、Christensen流の発見（§2）で“望む結果のリスト”自体の質を担保してから、ODIで定量化する。発見と定量化は順番に使う相互補完の関係です。次章からは、この発見の現場——定性調査の設計に入ります。
4. 定性調査の設計——インタビュー・観察と「都合の良い話だけ拾う」病
ジョブは、アンケートの選択肢からは出てきません。インタビューと観察という定性調査から立ち上げます。ただし定性調査には、致命的な落とし穴があります。「都合の良い話だけを拾ってしまう」——確証バイアスです。私が冒頭で「品質が強み」という仮説を持ったままヒアリングに行ったら、相手のどの発言からも「やっぱり品質が大事なんだ」という材料を見つけられたでしょう。人間は、見たいものを見ます。
これを設計で防ぐための要点を、診断実務の粒度で整理します。
(1) サンプルの選び方——「語ってくれる人」だけ聞かない
満足している取引先や、話を聞かせてくれる協力的な担当者ばかりに会うと、像が歪みます（生存者バイアス）。意図的に、(a) 最近発注を増やした先、(b) 最近減らした・切り替えた先、(c) 一度検討して見送った先——の3群を必ず混ぜます。特に(c)の「断った人」は、ジョブと障害の宝庫です。B2Bの解約・失注理由が掴めないときほど、ここに会いに行く設計が要ります。
(2) 質問設計——意見ではなく「行動と出来事」を聞く
「品質は重要ですか？」という質問は、ほぼ全員が「はい」と答えるので情報量がゼロです。さらに、これは答えを誘導しています。代わりに、過去の具体的な出来事を時系列で聞きます。
- ✕ 誘導的：「短納期対応があると助かりますよね？」
- ◯ 行動ベース：「直近で発注先を切り替えた件について、決めた日の“前の週”に何が起きていたか、順番に教えてください」
意見（〜と思う）は後付けで作られますが、出来事（〜が起きた）は記憶に刻まれています。ジョブは出来事の中にあります。
(3) 誘導の回避——沈黙と「なぜを5回」
相手が答えに詰まったとき、こちらが選択肢を出して埋めてはいけません。それは相手の言葉ではなく、こちらの仮説を相手に言わせているだけです。沈黙に耐え、「もう少し詳しく」「それは具体的にどういうことですか」と展開を促す。表層の理由（「品質が」）から、なぜを繰り返して状況・進歩・障害まで降ろします。
(4) バイアスを設計で殺す——反証質問を必ず入れる
最も重要なのがこれです。インタビューガイドに、自分の仮説を否定しにいく質問をあらかじめ埋め込みます。「品質が決め手だ」と思っているなら、「品質が同等の他社ではなく、あえてA社を外したことはありますか。そのときの理由は？」と聞く。仮説を支持する話だけでなく、仮説が間違っているなら出てくるはずの話を能動的に探しに行く。これは§6以降の因果推論にもつながる、思考の基本姿勢です。
確証バイアスのほかにも、定性調査の場では複数のバイアスが同時に働きます。代表的なものを押さえておきます。社会的望ましさバイアス——相手は「角が立たない、模範的な答え」を返しがちです（「価格より品質を重視しています」と言いつつ、実際の発注は安い方に流れている）。だから言葉だけでなく行動データ（§5）と突き合わせる必要があります。直近性バイアス——人は直近の出来事を過大評価します。「最近クレーム対応が遅かった」が記憶に強く残り、半年前の良い対応は忘れられている。だから「いつの話か」を必ず時系列で固定します。権威バイアス——支援者である私が「品質が大事ですよね」と言えば、相手はそれに合わせます。聞き手の立場そのものが誘導装置になることを忘れてはいけません。
実際のインタビューが、どこで脱線するかを対話例で示します。
私「最近、A社さんへの発注を減らされたとうかがいました。理由を教えていただけますか」
担当者「うーん……まあ、いろいろありまして」
✕ 悪い展開：私「やはり価格でしょうか？ それとも納期ですか？」→ 担当者「ああ、納期……そうですね、納期はありました」（私が出した選択肢を相手が選んだだけ。これは相手のジョブではなく、私の仮説の確認）
◯ 良い展開：私「（沈黙を5秒待つ）……差し支えなければ、減らそうと最終的に決めた“その日”のことを、思い出せる範囲で教えてください。何があった日でしたか」→ 担当者「ああ、あれは……うちの設計が急に変わって、図面を3回送り直したのに、対応が後手に回って。上司に『なぜ二社購買にしておかなかった』と詰められた日でした」
後者でようやく、「設計変更時の手戻り」と「上司への説明責任」という二重のジョブが立ち上がります。前者のままなら、私は「納期改善が解約防止策だ」という外れた洞察を持ち帰っていたでしょう。選択肢を出した瞬間に、定性調査は死ぬ——これは肝に銘じるべき原則です。
定性調査は「正しい仮説を当てる」ためではなく、「自分の思い込みを壊す」ために行う——この姿勢の転換が、外さない洞察の出発点です。
5. 定量分析の設計——ログ・購買・問い合わせデータで解約／失注を読む
定性で立てたジョブの仮説は、そのままでは「n=数件の印象」にすぎません。定量データと統合して、初めて意思決定に耐える洞察になります。8-1-2が想定する「B2Bサービスで解約理由が掴めない」場面を、A社の文脈に置き換えて設計します。A社にとっての“解約”は、取引先が発注量を静かに減らし、いずれフェードアウトする現象です。アンケートを取っても「特に不満はない」としか返ってきません。本音は行動データに出ます。
統合すべきデータの例：
- 取引量の時系列：取引先別・品目別の月次発注額。減少の“折れ曲がり点”がいつかを特定する
- 対応リードタイム：見積依頼→回答、注文→納品、設計変更依頼→対応完了までの日数
- 問い合わせ・クレームログ：不具合連絡の件数、初回回答までの時間、解決までの時間
- 接点データ：訪問・連絡の頻度（減らした先ほど、その前にA社からの接点も減っていなかったか）
定量分析の目的は2つです。第一に、定性で立てた仮説を裏付ける／反証すること。「不良時の報告が遅いのが致命的だ」という§3の仮説が正しければ、発注を減らした先では“クレーム発生から発注減少までの間に、初回回答までの日数が長い案件があった”という痕跡が出るはずです。出なければ仮説を疑います。第二に、定性では見えない規模感を測ること。そのジョブを抱える取引先が全体の何割で、金額インパクトはいくらか。
ここで強調したいのは、定性と定量は「どちらが正しいか」ではなく役割が違うということです。
| 定性（インタビュー・観察） | 定量（ログ・購買データ） | |
|---|---|---|
| 得意 | なぜ・どんな状況で（ジョブの発見） | どれくらい・何割（規模と再現性） |
| 苦手 | 規模・代表性（n が小さい） | 動機・文脈（why が見えない） |
| 役割 | 仮説を“生む” | 仮説を“検証・定量化する” |
定性と定量を統合する手順を、A社の粒度で具体化します。
- 仮説を観測可能な変数に翻訳する：「報告が遅いと離れる」を、「クレーム発生→初回回答の日数」と「以降6か月の月次発注額」という測れる変数に置き換える
- 離脱の定義を先に決める：B2Bに明確な「解約」はないので、「3か月移動平均の発注額が、ピーク比で30%以上低下し、その後回復しない」を“静かな離脱”と操作的に定義する（定義を後出しすると、都合よく解釈できてしまう）
- 時系列を揃えて重ねる：取引先ごとに、離脱の折れ曲がり点を起点（0か月）に揃え、その前後でクレーム対応日数・接点頻度・見積回答日数がどう動いたかを重ねる
- 定性の声を“付箋”で貼る：インタビューで得た発言を、同じ時系列上の該当時期に貼る。数字の折れ曲がりと、担当者の「あの頃から不満だった」という証言が同じ時期に重なれば、仮説の確からしさが一段上がる
この作業を5社ほどやると、たとえば次のような像が出てきます。「離脱した4社のうち3社で、離脱の2〜4か月前に“クレーム発生から初回回答まで7日超”の案件があった。残り1社はクレームはなかったが、こちらからの定期接点が半年ゼロだった」。ここまで来て初めて、定性の印象が「再現性のあるパターン」に格上げされます。
定性で生まれた「報告スピードが鍵」という仮説を、定量で「クレーム後の初回回答が7日を超えた取引先は、その後6か月で発注額が平均◯%減少していた」という形に翻訳できれば、ようやく意思決定者の前に出せます。ただし——この「クレーム後の対応が遅い → 発注が減った」という一文には、罠が潜んでいます。それは本当に因果なのか。 次章から、ここを掘ります。
6. 追加論点B｜相関≠因果——カウンターファクチュアル思考とRubin因果モデル
データ分析で最も多く、最も高くつく誤りが、相関を因果と取り違えることです。
教科書的なたとえから。ある町で「アイスクリームの売上」と「水難事故の件数」を月次で並べると、きれいに連動します。だからといって「アイスを売るのをやめれば溺れる人が減る」とは誰も思いません。両方を動かしている第三の要因——夏の暑さ（交絡変数）——があるからです。これが相関≠因果の基本構造です。
診断実務での典型例はもっと厄介です。「経営支援を受けた企業は、受けていない企業より業績が伸びている。だから支援には効果がある」。一見もっともらしい。しかしここには選択バイアスが潜みます。そもそも「支援を受けようと動ける企業」は、経営者の意欲・情報感度・資金的余裕が高い傾向があります。伸びたのは支援のおかげなのか、それとも“元から伸びる力のある企業が支援も受けた”だけなのか——データを並べただけでは区別できません。
ここで効くのがカウンターファクチュアル（反事実）思考です。問いをこう立て直します。「支援を受けたA社が伸びた」ではなく、「もしA社が支援を受けなかったら、A社はどうなっていたか」。観測された事実ではなく、起こらなかった世界と比べる。これが因果を考えるということです。
これを厳密に定式化したのが Rubin Causal Model（潜在的結果フレームワーク） です。発想はシンプルで、ある対象（A社）には本来2つの潜在的結果があると考えます。
- Y(1)：処置を受けた場合の結果（支援を受けたA社の業績）
- Y(0)：処置を受けなかった場合の結果（支援を受けなかったA社の業績）
因果効果とは Y(1) − Y(0) です。ところが——同じA社で「受けた世界」と「受けなかった世界」を同時に観測することはできません。私たちは必ず片方しか見られない。これを因果推論の根本問題と呼びます。
だから因果推論とは、結局のところ「観測できない反事実 Y(0) を、何で代用するか」の技術なのです。最も理想的な代用は、よく似た対象を多数集めてランダムに処置の有無を割り当てること（ランダム化比較試験＝A/Bテスト）。ランダムなら「処置を受けた群」と「受けなかった群」が平均的にそっくりになり、受けなかった群が反事実の代わりになります。
実務で因果を疑うときに私が必ず通すチェックリストを置いておきます。「Aが起きた後にBが起きた、AとBは連動している」という主張を見たら、次の4つを順に潰します。
- 逆因果：BがAを引き起こしている可能性はないか（「優良顧客だから手厚く対応した」のか「手厚く対応したから優良顧客になった」のか）
- 交絡変数：AとBの両方を動かす第三の要因はないか（市況・季節・景気・経営者の交代）
- 選択バイアス：そもそもAが起きる対象は、最初から特別な性質を持っていなかったか
- 偶然：サンプルが少なすぎて、たまたま連動して見えているだけではないか（B2Bで取引先10社の話を「傾向」と呼んでよいか）
A社の例で言えば、「報告を早くした取引先は発注が増えた」を見たとき、(逆因果)もともと発注を増やすつもりの取引先に、こちらも安心して手厚く報告していたのではないか、(交絡)ちょうど業界の設備投資期と重なって全取引先の発注が増えていたのではないか——を先に疑う。この問いを口に出せるかどうかが、データを“読める”診断士の分かれ目です。
しかし中小企業支援の現場で、A社を2つに割って片方だけ支援する、などというA/Bテストは普通できません。次章では、A/Bができない現実の中で反事実をどう代用するか——差分の差分法と、集計データに潜むSimpson’s Paradoxを扱います。
7. 追加論点B｜A/Bが無理なら準実験——差分の差分法とSimpson’s Paradoxの罠
(1) A/Bテストが基本、しかしB2B少数取引では難しい
A/Bテスト（ランダム化比較）は因果推論の王道です。ECサイトのボタン色のように、対象が大量で、ランダム割付ができ、結果がすぐ出る領域では極めて強力です。しかしA社のようにB2Bで取引先が数十社、主力1社が47%を占める世界では、ランダムに「この取引先には新しい報告体制、この取引先には従来のまま」と割り当てるのは現実的でも倫理的でもありません。ここで準実験（疑似実験）の出番です。
(2) 差分の差分法（Difference-in-Differences）
A社が「不良時24時間以内一次報告」という新しい対応を、ある時点から導入したとします。導入前後でその取引先の発注額が増えた——だけでは因果と言えません。ちょうど同じ時期に市況が回復して、業界全体で発注が増えていたかもしれない（交絡変数）。
差分の差分法は、こう考えます。
- 処置群：新対応を導入した取引先の「導入前→導入後」の発注額の変化（差分①）
- 対照群：新対応を導入していない同業他取引先の「同じ期間」の発注額の変化（差分②）
- 因果効果の推定 ＝ 差分① − 差分②
対照群の変化が「市況など全体に共通の影響」を表してくれるので、それを引き算することで交絡を取り除き、新対応そのものの効果に近づけます。数字を入れてみます（説明用の仮想値）。
| 導入前の月次発注額 | 導入後の月次発注額 | 差分 | |
|---|---|---|---|
| 処置群（新報告体制を適用した取引先） | 1,000万円 | 1,180万円 | +180万円 |
| 対照群（従来のままの同業取引先） | 1,000万円 | 1,100万円 | +100万円 |
| 差分の差分（因果効果の推定） | +80万円 |
導入後だけ見れば「+180万円、18%増！」と言いたくなります。しかし対照群も+100万円増えている。これは新対応とは無関係な、市況回復など全体共通の押し上げ分です。これを引くと、新報告体制そのものの寄与は+80万円。「+180万円」ではなく「+80万円」が、反証に耐える数字です。前提は「新対応がなければ両群は平行に推移したはず（平行トレンド仮定）」であり、ここが崩れていないかは導入前の推移を見て必ず点検します。完璧ではありませんが、「導入後に増えました」とだけ言うより、はるかに反証に強い主張になります。中小企業の現場では完璧な実験はできません。だからこそ「対照群を置く」「全体共通分を引く」という発想だけでも持ち込めれば、意思決定の質は大きく変わります。
(3) Simpson’s Paradox——集計データだけ見て喜ばない
最後に、分析者が必ず備えるべき習慣の話をします。Simpson’s Paradox（シンプソンのパラドックス）——集計データでは「改善した」ように見えるのに、層別すると逆転している現象です。
A社の品質改善プロジェクトを例にします。全社の不良率が、施策前2.0%から施策後1.6%へ低下した。「改善成功」と報告したくなります。ところが製品ラインで層別すると——
| 施策前 不良率 | 施策後 不良率 | |
|---|---|---|
| 量産ライン（生産比率：施策前30%→施策後70%） | 1.0% | 1.2% |
| 試作ライン（生産比率：施策前70%→施策後30%） | 2.4% | 2.6% |
| 全社（加重平均） | 2.0% | 1.6% |
各ライン単体では、施策前より施策後のほうが不良率は上がっています。全社の数字が下がったのは、もともと不良率の低い量産ラインの構成比が増えた（生産ミックスが変わった）からにすぎません。施策は実は悪化させていた可能性があるのに、集計データだけ見ていれば「成功」と誤判定し、本来やめるべき施策を全社展開してしまう。
ここでの教訓は明快です。「集計データだけ見て喜ばない」。 全体の数字が動いたら、必ず「どの層が・どんな構成比の変化で・それを動かしたのか」を分解する。これは特別な統計技法ではなく、分析者の習慣の問題です。そしてこの習慣こそ、§4で述べた「自分の思い込みを壊す」姿勢の、データ分析側での表れです。
8. 洞察を「刺さるストーリー」で終わらせない——仮説の形式化と意思決定基準
ここまでで、ジョブの発見（§1〜§4）、定量での検証（§5）、因果の見極め（§6〜§7）が揃いました。最後の関門が、8-1-3が鋭く突く問題です。洞察が「刺さるストーリー」になってしまい、検証されないまま意思決定に使われる。
「不良時の報告スピードこそ顧客が本当に求めているものだったんです」——この一文は、会議で強い説得力を持ちます。経営者は頷きます。物語として完成しているからです。しかし完成度の高い物語ほど危険です。反証可能性が消えるからです。どんなデータを見ても「ほら、やっぱり報告スピードだ」と解釈できてしまうなら、それは洞察ではなく信仰です。
これを防ぐには、洞察を検証可能な仮説の形式に書き直します。私は次の型を使います。
「もし〔施策〕を行えば、〔対象〕の〔測定可能な指標〕が、〔期間〕で〔基準値〕変化する。もし変化しなければ、この洞察は誤り（または条件付き）である」
A社の例：
「もし不良発生時24時間以内の一次報告体制を導入すれば、それを適用した取引先群の6か月後の発注額が、対照群との差分の差分でプラス10%以上になる。10%に届かなければ、『報告スピードが最大の差別化機会である』という洞察は棄却し、Opportunity Score第2位の『設計変更時の図面すり合わせの手間』へ仮説を切り替える」
この形式の効能は3つあります。第一に、反証条件が明文化される（届かなければ棄却、という退路が先に決まっている）。第二に、検証手段が§7の準実験に直結する。第三に、意思決定基準（やる／やらない）が事前に確定するので、結果が出てから都合よく解釈をねじ曲げる余地が消えます。
意思決定への落とし込みは、次のゲート構造で管理します。
- 発見ゲート：Christensen流の定性で、ジョブ仮説が複数立った
- 定量ゲート：Opportunity Scoreと行動データで、機会の大きさと痕跡を確認した（規模が小さければここで棄却）
- 因果ゲート：相関ではなく因果か。準実験（差分の差分）で検証できる設計があるか。Simpson’s Paradoxの層別点検を通したか
- 意思決定ゲート：事前に決めた基準値を満たしたか。満たせば全展開、満たさなければ次の仮説へ。「物語が良かったから続行」は禁止
なぜ「刺さるストーリー」はこれほど危険なのか。理由は、物語が人間の納得感を、検証の代わりに使わせてしまうからです。よくできた物語は、登場人物（顧客）の動機が一貫し、原因と結果が滑らかにつながっています。聞き手の脳は、その滑らかさを「正しさ」と取り違えます。これは§4で見た確証バイアスの、意思決定段階での再来です。定性調査では「思い込みに合う発言だけ拾う」形で、意思決定では「思い込みに合う物語だけ信じる」形で、同じバイアスが二度顔を出す。だからこそ、定性（§4）と意思決定（§8）の両方に、別々の防御装置——反証質問と、棄却条件付きの仮説形式——を仕込む必要があります。
意思決定基準は、結果が出る前に表にしておきます。
| 検証結果 | 事前に決めた判断 |
|---|---|
| 差分の差分で +10%以上 | 全取引先へ展開（やる） |
| +3%〜+10%未満 | 対象を限定して継続検証（保留） |
| +3%未満／マイナス | 棄却し、Opportunity Score第2位の仮説へ（やらない） |
この表を結果を見る前に経営者と合意しておくことが決定的に重要です。結果が出てから基準を決めると、人は必ず「今回は特殊事情があった」と例外を作り、物語を延命させます。退路を先に塞ぐ。これが「検証される洞察」の最後の一手です。
「刺さるストーリー」は、人を動かすプレゼンには有効です。しかし意思決定の根拠にしてはいけない。物語は仮説の入口であって、結論の証明ではありません。この一線を引けるかどうかが、合格後に「データを使える診断士」と「データで物語を作る診断士」を分けます。
9. 組織論応用——22名・主力顧客47%のA社で、この仕組みを誰が回すか
理論を一通り敷きました。しかしA社は従業員22名、専任のマーケティング担当も分析担当もいない町工場です。「JTBDインタビューを設計し、Opportunity Scoreを計算し、差分の差分法で検証する」を、誰が・どう回すのか。ここを設計できなければ、机上論で終わります。
(1) 主力顧客47%依存という構造をJTBDで読み替える
A社最大の経営リスクは、1社で売上の47%を占める集中度です。通常の処方は「新規開拓で分散せよ」。しかしJTBDの視点を入れると、優先順位が変わります。まず、その主力1社の調達担当者に対してこそ、§2のChristensen流インタビューを行うべきです。「この47%は、なぜA社を雇い続けているのか。その雇用理由（ジョブ）が崩れる状況は何か」。依存先のジョブと“解約の引き金”を解像度高く掴むことは、新規10社を浅く回るより、まず先にやるべき守りの一手です。そのうえで、同じジョブを持つ別業種の見込み先に水平展開する——これが分散戦略の精度を上げます。
(2) 熟練工2名の暗黙知を「観察データ」に変える
A社の品質を支えているのは、勤続20年超の熟練工2名の手作業です。これは強み（§3で見たように、品質はすでに高い）であると同時に、属人化リスクです。ここで顧客理解の道具が、社内にも転用できます。観察（エスノグラフィ）の対象を、顧客だけでなく自社の熟練工に向けるのです。「彼らはどんな状況で、何を手がかりに、どう不良を未然に察知しているか」を観察・記述する。これは熟練工が片付けている“暗黙のジョブ”の発見であり、§3で最高スコアだった「不良の原因をすぐ報告する」体制の中身そのものになります。顧客洞察の手法と技能伝承が、ここで一本につながります。
この接続を、もう少し具体的にしておきます。§3で最大の差別化機会は「不良発生時に24時間以内で原因の一次報告を出すこと」でした。しかし“原因をすぐ言える”ためには、そもそも「なぜ不良が出たか」を即座に切り分けられる人が社内にいなければなりません。それが今は熟練工2名の頭の中にしかない。つまり、顧客が最も求めている機会（迅速な原因報告）と、A社最大の内部リスク（技能の属人化）は、同じ一点で交わっています。ここに気づくと、技能伝承は「いつかやるべき総務的課題」ではなく、「最大の顧客価値を持続させるための、最優先の顧客戦略そのもの」に格上げされます。具体的には、熟練工2名の不良察知の判断（どの音・どの手触り・どの工程で異常を感じるか）を、若手が横で観察し、月次で「今月のヒヤリ」を言語化して1枚に貯めていく。3年で、属人知が「原因報告の初動マニュアル」に変わります。顧客理解の手法を社内に向けることが、依存リスクと技能リスクを同時に下げる——小さな組織だからこそ、こうした“一石二鳥の設計”を狙う価値があります。
(3) 「専門家を雇う」のではなく「問いを置く」
22名の組織に分析専任は置けません。現実解は、仕組みを“軽く”することです。
- 四半期に1回、経営者と私（診断士）で主力顧客1社にだけChristensen流インタビューを実施（半日で足りる）
- Opportunity Scoreは、望む結果を10項目程度に絞り、簡易な質問票で。Excelで計算できる
- 検証は大掛かりなA/Bではなく、「ある対応を一部の取引先で先に始め、他と推移を比べる（簡易な差分の差分）」で十分
- 月次の数字を見る会議に、「この数字、層別したらどうなる？」を必ず問う係を1人置く（Simpson’s Paradox対策）
(4) 顧客戦略を「経営者の頭の中」から「1枚の表」へ出す
A社のような小さな組織で最も危ういのは、顧客戦略が経営者一人の経験と勘の中に閉じていることです。経営者が「あの取引先はうるさいが大事だ」と感じていても、それが言語化・共有されていなければ、熟練工2名が引退した後、誰もその顧客の本当のジョブを知らないという事態になります。そこで、ここまでの手順の出力を、四半期ごとに1枚の顧客戦略マップに落とします。列は「取引先（A社/B社/…）」「主たるジョブ（状況・進歩・障害）」「最高Opportunity Scoreの機会」「離脱の引き金（観測指標）」「次の検証アクションと判定基準」。この表があれば、顧客戦略は属人知から組織知に変わり、後継者にも引き継げます。中小企業診断士として支援に入るとき、立派な戦略文書を作るより、この1枚を経営者と一緒に毎期更新し続けることのほうが、はるかに実効性があります。
組織が小さいことは、顧客との距離が近いという強みでもあります。大企業のような大規模アンケートは打てませんが、主力顧客の調達担当者と経営者が直接話せる距離にある。仕組みの重さではなく、問いの質で勝負する——これが22名組織における顧客洞察の組織設計の核心です。
10. 合格直後の自分へ——「いい話を聞けた」を疑えるか
最後に、これから現場に出る合格直後の自分に向けて、申し送りを書きます。
合格直後の私が最も陥りやすかったのは、「ヒアリングで良い話が聞けた＝顧客を理解できた」という錯覚でした。冒頭のA社の場面がまさにそれです。丁寧に聞いた。相手も話してくれた。資料も作った。なのに外した。原因は、努力不足でも分析技術の不足でもなく、出発点と検証姿勢にありました。
申し送りを5つに絞ります。
① セグメントの前に、ジョブを問え。 「誰に売るか」を考える前に、「その人はどんな状況で、何を片付けたくて、何に邪魔されているか」を一文で書けるか。書けないなら、まだ顧客を理解していません。
② 発見と定量化を、順番に使え。 まずChristensen流で文脈を発見し、次にUlwick流のOpportunity Scoreで機会の大きさを測る。順序を逆にすると、自社の思い込みを定量化して安心するだけになります。
③ インタビューには、自分を否定する質問を必ず入れろ。 仮説を支持する話は、探せばいくらでも見つかります。価値があるのは、仮説が崩れる話です。確証バイアスは、根性ではなく設計（反証質問）で殺す。
④ 「相関」を見たら、反事実を口に出せ。 「Aをやったら良くなった」と言いたくなったら、必ず「もしAをやらなかったら、どうなっていたか」と言い直す。そして「集計データだけ見て喜ばない」。数字が動いたら、層別して分解する癖をつける。
⑤ 刺さる物語は、プレゼンの道具であって、意思決定の根拠ではない。 洞察は「もし〜なら〜が〜変化する。しなければ棄却する」の形に書き直すまで、仮説にすぎません。退路（棄却条件）を先に決めてから、検証に進む。
試験で学ぶマーケティングは「顧客志向」「STP」「ニーズ把握」と教えます。統計は「相関係数」「t検定」と教えます。どちらも正しい。しかし現場で価値を生むのは、その一段上のレイヤー——「セグメントではなく文脈で見る」「相関ではなく反事実で考える」「物語ではなく反証で詰める」という、見方の転換です。フレームワークの暗記は出発点にすぎません。
心構えだけでは現場で機能しません。最初の案件で、次の3つを実装してみてください。
実装①：インタビューガイドに「反証質問」を必ず1問入れる。 どんな簡単なヒアリングでも、自分の本命仮説を否定しに行く質問を最低1つ用意してから臨む。これだけで確証バイアスの大半は防げます。
実装②：洞察を「もし〜なら〜が〜変化する。しなければ棄却」の1文に書き直す。 報告書に「顧客は◯◯を求めている」と書きそうになったら、その横に必ず検証可能な仮説文と棄却条件を併記する。書けないなら、それはまだ洞察ではなく印象です。
実装③：数字を見る会議で「層別したら?」と1回は問う。 全体の数字が良くなった／悪くなったと報告されたら、必ず「どの層が、どんな構成比の変化で、それを動かしたのか」を一度は分解して確認する。Simpson’s Paradoxは、特別な統計知識ではなく、この一言の習慣で防げます。
試験で学ぶ顧客理解は「STP・ニーズ把握」、統計は「相関・検定」。それらは1年で身につきます。しかし「セグメントではなく文脈で見る」「相関ではなく反事実で考える」「物語ではなく反証で詰める」という見方は、案件のたびに意識して使い、失敗して、また使う——その反復でしか身につきません。合格は、その反復のスタート地点です。
合格おめでとうございます。最初の案件で顧客に「いい話」を聞けたとき、嬉しくなる前に一度だけ、自分にこう問うてみてください。「この話、私が聞きたかった話を、相手に言わせてしまっただけではないか」。その問いを持てる診断士になることが、外さない顧客洞察の、たぶん一番の近道です。
本記事は、中小企業診断士合格後の実務準備を目的とした記事群の一部です。試験対策ではなく「合格後の知的再武装」として、アカデミックと実務のギャップを埋めることをコンセプトにしています。チェックポイント8-1「顧客をセグメントではなく文脈/ジョブ（JTBD）で理解し、定性調査とデータ分析を統合した洞察生成を説明できる」に対応し、既存の3記事（JTBDで顧客を深く理解しデータ統合で洞察を生む方法／JTBDと定性・定量分析で解約理由を解明する顧客理解／JTBDとデータ分析を洞察の仮説検証へ繋ぐ実践プロセス）を、一つの「検証される顧客洞察」の設計論として統合・再構成したものです。本記事の一部はAIによる分析・生成を含みます。重要な経営判断は専門家による検証をお勧めします。
コメント