顧客と支払者｜顧客課題・検証・販売

このページはプロモーション（広告）を含みます。

顧客課題・検証・販売（初級・読む25分＋演習30分）

この授業のゴール

• 1つの事業案について、利用者・支払者・決裁者・影響者・反対者を分けて表に書ける
• 「誰が困っているか」と「誰がお金を出すか」が違う事例で、最初に話を聞く相手を理由付きで選べる
• 関心・利用意向・実利用・購入の4種類の証拠を区別し、手元の証拠がどれに当たるか判定できる
• 最初に狙う顧客を、業種・規模・場面・今の対処の条件で1文に絞り込める

仕事でどう使うか

起業の最初の失敗で多いのは、「使う人は喜んだのに、お金を出す人が買わなかった」というものです。使う人と払う人が違うと、使う人の「便利そう」は購入の理由になりません。この授業では、事業案ごとに誰が使い、誰が払い、誰が決めるのかを分けて書けるようにします。

成果物は関係者マップ（役割・関心・懸念・確認方法を並べた表）です。これは次の授業の課題仮説、L03の面談相手の選定、SU02の価格設計の土台になります。

前提

次の考え方を使います。不安があれば先に戻ってください。

• 業務の流れを担当者ごとに書く（誰がどの作業をするか）→ 「現状フロー」（有料版）
• 現場観察とヒアリングの基本（話を聞く前に目的を決める）→ 「現場観察とヒアリング」（有料版）
• 利用者と意思決定（分析結果を誰が何の判断に使うか）→ 利用者と意思決定

このモジュールでは、2つの架空ケースを通して使います。どちらも説明用に作った例で、実在の企業や人物ではありません。

大切な前提：このモジュールに出てくる顧客の発言や数字は、すべて説明用に作った架空のものです。架空ケースで作った面談記録や、AIを相手にした模擬面談は、実在の顧客の証拠にはなりません。実際の起業準備では、同じ型を使って本物の顧客候補に話を聞き、その記録だけを証拠として扱います。

身近な状況：「現場は大喜び、でも買われない」

ケースAの佐藤さんは、知り合いのネットショップ3社で試作品を見せました。顧客対応（CS：Customer Support）担当者の反応は上々でした。

3社とも「良い反応」に見えますが、お金を出す判断をした人が前向きだったのはZ社だけです。X社とY社では、喜んだのは使う人であり、払う人・決める人・止める人は別にいました。

この表から次のことがわかります。

1. 「欲しい」と言った人数（2人）は、購入の見込み数ではない。
2. 購入の判断には、使う人以外の関係者（社長、情報システム担当）が関わる。
3. 止める理由（今のやり方で回っている、個人情報）は、使う人に聞いても出てこないことが多い。

佐藤さんが最初にすべきだったのは、試作品を見せることより先に、この会社では誰が使い、誰が払い、誰が決め、誰が止めうるのかを確かめることでした。

直感的な説明：「使う人・払う人・決める人」は同じとは限らない

日常の買い物で考えると、違いがつかめます。

最後の行のように、小さな店では1人が3つの役割を兼ねることがあります。この場合は話が速く進みます。一方、会社の中で使う道具（B2B：Business to Business、企業向け取引）では、役割が分かれるのがふつうです。

役割が分かれると、それぞれが重視することも違います。

• 使う人は「毎日の作業が楽になるか」「覚えることが少ないか」を気にします。
• 払う人・決める人は「費用に見合う効果があるか」「失敗したとき誰が責任を負うか」を気にします。
• 止める人は「安全か」「規則に反しないか」「自分の仕事が増えないか」を気にします。

たとえ話の限界：個人向け（B2C：Business to Consumer）でも、家族が使い方に反対したり、無料版で十分と判断したりすることがあります。「個人向けなら役割は1人」と決めつけず、毎回確かめます。

正確な定義：5つの役割と4種類の証拠

このモジュールでは、次の言葉を使い分けます。

関係者の役割（1人が複数を兼ねることがある）

顧客という言葉は、このモジュールでは「支払者と利用者を含む、購入に関わる人や組織のまとまり」を指します。「顧客は誰か」と聞かれたら、役割ごとに答えます。

顧客セグメントとは、「同じ課題を、同じような場面で、同じような方法で対処している顧客の集まり」です。業種や規模だけでは足りません。「年商1〜10億円のEC事業者」だけでは広すぎ、「CS担当が2〜5人で、問い合わせ月300件以上を共有メールで手作業で仕分けている EC事業者」のように、場面と今の対処まで書くと、面談相手を探せる粒度になります。

証拠の4段階（下ほど強い）

4段階は別々の証拠です。「使いたい」が10件あっても、購入が0件なら、販売はまだ確認できていません。逆に、購入があっても実利用が続かなければ、継続して売れるかは不明です。

段階付き例題：ケースAの関係者マップを作る

入力：佐藤さんがZ社（社員30人のネットショップ、CS担当3人）について、社長Cさんとの30分の会話で聞いた事実（架空）。

• 問い合わせは共有メールに届き、CS担当のリーダーが毎朝振り分けている。
• 月50万円未満の支出は、EC事業部長の判断で決められる。それを超えると社長の承認が必要。
• 顧客の個人情報を扱う外部サービスは、情報システム担当（兼務1人）が確認する決まりがある。
• 返品の問い合わせは倉庫担当にも転送している。

ステップ1：役割の欄を作る。5つの役割を行にし、「誰か・関心・懸念・どう確かめるか」を列にする。

ステップ2：事実から埋める。聞いた事実で埋まる欄だけを埋め、推測には「（推測）」と書く。

ステップ3：空欄と推測を次の行動に変える。推測の欄が多いのは、支払者（事業部長）です。つまり、次に話すべき相手は事業部長で、聞くことは「CSにかけている費用」と「去年、何に予算を使ったか」です。

ステップ4：意味を読む。このマップから、「CS担当が喜ぶ」ことは購入の必要条件の1つにすぎないとわかります。購入までには、事業部長が費用対効果を認め、情報システム担当の確認を通る必要があります。

操作して理解する：役割の重なりを変えて、話の進み方を予想する

下の表の状況ごとに、「誰に最初に話を聞くか」「購入までに越える関門はいくつか」を予想してから、右の答えを見てください。

ここからわかるのは、最初に狙う顧客は「課題が強い」だけでなく「判断が速い」ことも大事だということです。役割が少数に集まっていて、今の対処に不満があり、予算を動かせる顧客をアーリーアダプター（初期採用者）と呼び、最初の販売相手の候補にします。

アーリーアダプターを見つける目安は次の4つです。

1. 課題を自覚している（言われなくても困りごとを話せる）。
2. 解決策を探している（調べた・試した・比べた経験がある）。
3. 自分で代わりの方法を作っている（表計算や手作業の工夫）。
4. 予算を出せる、または出せる人にすぐ相談できる。

4つのうち多く当てはまるほど、最初の顧客として有望です。

発展：役割の分け方の限界と、個人向け・研究向けの注意

5つの役割は、話を整理するための道具です。実際には次のような例外があります。

• 役割が時間で変わる：試用の段階では事業部長が決めても、本契約では社長の承認が必要になることがあります。金額の基準や手続きは会社ごとに違うので、必ず相手に確認します。
• 支払者が外部にいる：補助金や親会社の予算で払う場合、支払者の条件（対象経費、期間）が購入を左右します。補助金の制度は年度で変わるため、執筆時点（2026年）の一般的な説明にとどめます。最新の条件は公式情報で確認してください。
• 個人向け（B2C）：アプリの利用者と支払者が同じでも、「無料なら使うが有料なら使わない」人が大半ということがよくあります。B2Cでは、支払いを伴う行動（有料版への切り替え率）を早めに測ることが重要です。
• 研究シーズ型：共同研究に協力してくれる企業の研究部門は、技術への関心は高くても、製品購入の予算を持たないことが多いです。共同研究の合意は「関心」や「利用意向」の証拠であり、「購入」の証拠ではありません（「技術シーズと顧客」（有料版）で扱います）。

もう1つの限界は、関係者マップ自体が推測で埋まりやすいことです。「社長は費用を気にするはず」と書いた欄は、聞いて確かめるまでは仮説です。マップは一度作って終わりではなく、面談のたびに「事実」と「推測」の印を更新します。

よくある失敗

失敗1：利用者の「欲しい」を購入見込みとして数える

誤った例：「CS担当者10人に聞いたら8人が『欲しい』と言った。だから購入率は80%」。

なぜ誤りか：8人は利用者で、支払いを決める立場ではありません。また「欲しい」は利用意向の段階で、購入（お金を払う行動）ではありません。計算すると、確認できた購入率は $0 \div 10 = 0\%$ です。80%という数字は「言葉の上での好意の割合」であり、購入率とは別の量です。

直し方：記録表に「役割」と「証拠の段階」の列を作り、「利用者・利用意向：8人」「支払者・購入：0社」と分けて書きます。次の行動は、支払者に会う約束を取ることです。

失敗2：顧客セグメントを業種と規模だけで決める

誤った例：「対象は中小企業」「対象は全国のパン店」。

なぜ誤りか：全国のパン店の中には、仕込み量をすでに経験で正確に決められている店も、毎日大量に廃棄している店もあります。課題の強さも今の対処も違うので、同じ面談の質問が当てはまらず、結果が混ざって読めなくなります。

直し方：「場面」と「今の対処」を加えます。例：「1〜3店舗で、店主が前日夕方に翌日の仕込み量を勘で決めており、閉店時の売れ残りを毎日記録していない（または記録している）パン店」。記録の有無で分けると、後で廃棄の数字を聞けるかどうかも予想できます。

失敗3：反対者を想定せず、最後の段階で止まる

誤った例：利用者と支払者の両方が前向きだったので、契約書の準備を始めたら、情報システム担当の「顧客の個人情報を外部サービスに送る手続きが未整備」という指摘で止まった。

なぜ誤りか：反対者は購入の最終段階で現れることが多く、それまでにかけた時間が無駄になります。今回は「止める理由」を早い段階で聞いていなかったことが原因です。

直し方：最初の面談で「このような外部サービスを入れるとき、社内で確認が必要な人や手続きはありますか」と聞き、関係者マップの「反対者の候補」の欄を埋めます。個人情報の扱いなど法令に関わる条件は、執筆時点（2026年）の一般論として「確認が必要」と書くにとどめ、具体的な判断は相手の会社の担当者や専門家に確認します。

まとめ

• 利用者・支払者・決裁者・影響者・反対者を分けて書く。1人が兼ねることも、社外にいることもある。
• 関心・利用意向・実利用・購入は別の証拠。「欲しい」が何件あっても購入0件なら販売は未確認。
• 顧客セグメントは業種・規模に、課題の場面と今の対処を加えて、面談相手を探せる粒度にする。
• 関係者マップは事実と推測を分け、推測を「誰に何を聞くか」に変える。
• 架空ケースや模擬面談の記録は練習用で、実在の顧客の証拠にはならない。

用語

利用者（user）

製品を実際に操作し、日々の効果を受ける人。

支払者（payer / economic buyer）

費用を負担する予算の持ち主。利用者と別の人であることが多い。

決裁者（decision maker）

導入の最終判断をする人。金額や手続きによって変わることがある。

顧客セグメント（customer segment）

同じ課題を、同じような場面で、同じような方法で対処している顧客の集まり。

アーリーアダプター（early adopter）

課題を自覚して解決策を探し、自作の代替手段があり、予算を動かせる初期の採用者。最初の顧客候補。

関係者マップ（stakeholder map）

購入に関わる人の役割・関心・懸念・確認方法を並べた表。

よくある質問

なぜ最初から役割を分ける必要があるのですか？ まず作って見せればよいのでは？

作って見せると、喜ぶのはたいてい利用者です。支払者や反対者の判断材料（費用、責任、安全性）は試作品を見ても出てきません。先に役割を分けておくと、誰に何を聞くべきかが決まり、作る前に購入を止める理由を見つけられます。

「顧客」と「ユーザー（利用者）」は何が違いますか？

このモジュールでは、利用者は製品を操作する人、顧客は支払者・決裁者を含む購入に関わる人や組織のまとまりです。個人向けアプリでは同じ人のことが多いですが、企業向けでは別の人になるのがふつうです。

役割を間違えて把握していた場合、どこで失敗しますか？

多いのは、(1) 支払者に会わずに利用者の好意を数えて売上計画を作る、(2) 反対者の存在を知らずに契約直前で止まる、(3) 決裁の金額基準を知らずに、承認手続きの重い価格を提示してしまう、の3つです。

1人で全部の役割を兼ねる小さな店なら、この授業の考え方は不要ですか？

役割の数が減るだけで、考え方は同じです。むしろ1人で兼ねる人は忙しく、「便利そう」だけでは時間もお金も出しません。利用者としての困りごとと、支払者としての費用感の両方を同じ人に聞く必要があります。

仕事で、どの顧客を最初に狙うかはどう判断しますか？

「課題が強い」「解決策を探している」「自作の代替手段がある」「予算を動かせる」の4つと、「判断が速い（関門が少ない）」を表にして候補を比べます。売上が大きい顧客より、最初の購入が早く確かめられる顧客を優先するのが一般的です。

架空ケースや、AIとの模擬面談で関係者マップを練習した結果は、事業計画に使えますか？

型の練習にはなりますが、証拠としては使えません。架空の発言は自分の想像を写したものだからです。事業計画には、実在の顧客候補から聞いた事実だけを「事実」として書き、練習の結果は「仮説」として扱います。

確認問題

次に学ぶこと

次の 課題仮説 では、関係者マップで選んだ相手について、「どの場面で何に困り、今どう対処しているか」を検証できる課題仮説として書きます。

関連：業務の担当者ごとの流れは 「現状フロー」（有料版）、意思決定者の整理は 利用者と意思決定 で復習できます。支払者が価格をどう判断するかは 「価格と価値」（有料版） で扱います。この授業の確認問題だけでモジュールの習得とはせず、SU01の総合テストと自力課題で判定します。