第11章 顧客と課題を捉える

第10章では、初期設定未完了までの出来事をインタビューでたどりました。その結果、画面が分かりにくいという説明だけでは足りないことが分かりました。契約した人と設定する人が別である、管理者権限を誰に頼むか分からない、月末は面談時間を取れない。表面上は同じ「未完了」でも、止まる状況は異なります。

ここで「顧客の課題は設定画面の分かりにくさだ」とまとめると、証拠より早く一つの解決策へ寄ってしまいます。また、「中小企業の担当者」という人物像だけでは、誰が購入し、誰が使い、誰が許可し、どの場面で困るのかが分かりません。

ここで扱う顧客課題は、属性や要望の一覧ではありません。ある主体が特定の状況で進めたいことと、それを妨げる制約の仮説として捉えます。

今回の意思決定は、「どの顧客群へ、どの初期支援を試すか」です。第7章から第10章で得た仮想データと仮想インタビューを使い、誰のどの状況を対象にするかを決めます。本章の企業数、発言、役割は、方法を説明するための仮想例です。

関係する主体を分ける
  ↓
状況・行動・結果をたどる
  ↓
進めたいことと障害を仮説にする
  ↓
行動を変えられる単位で顧客群を分ける
  ↓
証拠、反対例、未確認を結ぶ
  ↓
対象、価値、次の検証を決める

小さな判断では、次の 6 点から課題仮説を始めます。

1. 誰が経験しているか
2. どの状況で起きるか
3. 何を進めようとしているか
4. 今はどう対処しているか
5. 進めないと何を失うか
6. 次に何を確かめるか

役割表、JTBD（顧客がある状況で達成したい進歩を見る考え方）、セグメント（似た課題や購買条件を持つ顧客群）、ペルソナ（調査に基づいて表現した代表的な利用者像）は、この 6 点を詳しくし、異なる選択肢を作る必要があるときに使います。すべての成果物を毎回作る必要はありません。

11.1 「顧客」を一人にまとめない

B2B（Business to Business、企業間取引）のサービスでは、お金を払う組織と、毎日使う人が違います。同じ組織の中でも、導入を提案する人、予算を承認する人、契約する人、設定する人、利用する人、管理する人が分かれます。

一人が複数の役割を担う場合もあります。小規模企業では経営者が購入、承認、利用を兼ねるかもしれません。役割表は組織図を作るためではなく、誰の行動を変えなければ導入が進まないかを見つけるために使います。

今回のインタビューで「管理者権限がない」と分かったなら、設定担当者だけへ説明を増やしても解決しません。権限を持つ承認者を特定し、依頼を届け、承認してもらう流れが必要です。

関心に加えて、権限と負担を置きます。

便益を得る人と負担を負う人が違えば、同じ価値提案では動きません。設定担当者には作業短縮、IT 管理者には必要情報と安全性、購入者には費用と契約条件が必要です。

役割は時間とともに入れ替わります。

問題を認識する
  → 候補を比較する
  → 予算・安全性を承認する
  → 契約する
  → 初期設定する
  → 利用・管理する
  → 更新・拡大・解約を決める

各段階で、誰が情報を集め、誰が拒否でき、誰が次へ引き渡すかを確認します。購入時の意思決定者と、更新時の意思決定者が同じとは限りません。

主体ごとに、次を確認します。

• 何を達成しようとしているか
• どの時点で関わるか
• 何を決め、何を決められないか
• 成功と失敗を何で判断するか
• 誰から情報、予算、権限を得るか
• 誰が便益を受け、誰が負担を負うか

利用者の便利さだけを改善しても、購入者が費用を承認しなければ導入されません。購入者に価値があっても、現場の負担が大きければ使われません。顧客理解は、一つの人物像ではなく、複数の主体の関係を理解することから始まります。

11.2 課題と解決策を分ける

顧客は「面談してほしい」「AI で自動化してほしい」「CSV（表形式のデータ交換ファイル）出力がほしい」と要望を語ります。要望は重要な証拠ですが、そのまま課題の定義ではありません。

要望:
管理者と一緒に設定する面談がほしい

状況:
設定担当者と権限を持つ人が別部署にいる

進めたいこと:
必要な権限を得て、期限までに初期設定を完了したい

障害:
誰に何を依頼すればよいか分からず、依頼後の進捗も見えない

解決策候補:
事前確認、依頼テンプレート、権限者の招待、合同面談、代行

要望を一段上の状況と結果へ戻すと、複数の解決策を比較できます。合同面談が有効な場合もあれば、時間を合わせられない顧客には逆効果です。

課題は、単なる不満でもありません。作業が少し面倒でも、顧客が対処でき、結果に影響しないなら、優先度は低いかもしれません。反対に、本人が強く不満を語らなくても、権限や制度の制約で重要な仕事を完了できないなら、事業上の課題になり得ます。

本書では、課題仮説を次の要素で書きます。

11.3 Jobs to Be Done を進歩の仮説として使う

Jobs to Be Done（JTBD）は、顧客が製品そのものを欲しいのではなく、ある状況で望む進歩を得るために製品や方法を選ぶ、と見る考え方です。JTBD には複数の実務的な流派があり、Job の定義や調査手順が完全に統一されているわけではありません。本書では、顧客を固定的な属性だけで捉えず、状況、進めたい結果、動機、制約、代替手段を結ぶ課題仮説を作る視点として使います。

今回なら、次のように書けます。

新しいサービスの運用を任されたとき、他部署の管理者へ必要事項を正しく依頼し、導入期限に間に合わせたい。そうすれば、権限待ちで計画が止まり、自分の責任として扱われることを避けられる。

この文は、確認済みの事実ではなく課題仮説です。「自分の責任として扱われることを避けたい」という動機が、全員にあるとは限りません。参加者の発言、実際の行動、反対例で確かめます。

JTBD を定型文へ埋めるだけでは、顧客理解になりません。

• 状況が広すぎる: 「仕事をするとき」
• 結果が解決策になっている: 「AI を使いたい」
• 動機を創作している: 「革新的な人と思われたい」
• 対象を平均化している: 「すべての中小企業」
• 制約と代替がない: 「効率化したい」

重要なのは文型ではなく、顧客が何を選び、何をやめ、どの状況で別の方法へ切り替えるかです。製品を導入しない、表計算で続ける、人へ依頼する、仕事自体を諦めることも代替です。

JTBD は、顧客の行動を説明する唯一の理論でも、結果を予測する法則でも、因果を自動的に証明する方法でもありません。状況と進歩を中心に仮説を作る実務上の視点として使い、ログ、インタビュー、試行で検証します。ここでいう進歩は顧客が望む変化であり、それ自体が安全、公平、他の主体にとって望ましいとは限りません。別の主体への負担とガードレールも評価します。

本章の用語は、次の関係にあります。

11.4 言葉より行動を上位に置くのではなく、差を見る

顧客が「面談なら使う」と答えても、実際には予約しないことがあります。言葉と行動が違うとき、「顧客は嘘をついた」と片づけてはいけません。

インタビュー時と実際の場面では、条件が違います。

• 面談の時間帯が合わなかった
• 上司や管理者の許可が必要になった
• 予約時に新しい情報の入力を求められた
• 問題の優先度が下がった
• 質問者に配慮して好意的に答えた
• 支援を受けることに心理的・組織的な負担があった

発言は、認識、期待、意味づけを知る証拠です。行動は、実際の制約下で何を選んだかを知る証拠です。どちらかを常に上位に置くのではなく、差が生じた条件を調べます。

行動も、内面の選好を直接見せるわけではありません。利用可能な選択肢、情報、予算、権限、制度、時間に制約された結果です。また、ログに記録されない行動もあります。言葉と行動の両方を条件付きの証拠として扱います。

表明された要望と観測された行動が一致しても、因果は確定しません。発言、行動、状況、結果をつなぎ、別の説明を残します。

11.5 現在の代替手段は課題の重要度を示す

顧客がすでに時間、費用、関係調整を使って対処しているなら、その行動は課題の重要度を考える手がかりになります。

今回の顧客は、管理者を探すために社内チャットで複数人へ連絡し、3 日待っていました。別の顧客は、外部の設定代行へ費用を払っていました。このような対処には、単なる「困っています」という発言とは異なる情報があります。

現在の代替を、次の観点で見ます。

切替の強さを見るには、現在の費用だけでなく、次を確認します。

• 何が起きたら今の方法を見直すか
• 誰が切替を提案し、誰が予算を持つか
• データ移行、学習、契約、社内承認に何が必要か
• 過去に別の方法を検討・購入・解約したことがあるか
• 新しい方法を試すために、すでに時間や費用を払ったか

代替手段がないことは、必ずしも巨大な未充足需要を意味しません。課題が重要でない、予算がない、解決できると思っていない、規制で動けない場合もあります。無行動の理由を確認します。

顧客が大きな費用を払っていても、自社がその価値を受け取れるとは限りません。既存の代替には、信頼、契約、社内政治、慣習など、機能以外の価値があります。置き換える対象を正確に捉えます。

11.6 セグメントは行動を変えるために作る

セグメンテーションは、顧客を似た群へ分けることです。年齢、企業規模、業種のような属性は使いやすい一方、属性だけでは同じ施策が効く理由を説明できないことがあります。

今回の目的は、初期支援の対象と方法を変えることです。そのため、次の切り口が候補になります。

よいセグメントは、少なくとも次を満たします。

1. 誰がどの群に入るか、一貫して判定できる
2. 群によって課題、選択、反応が意味のある形で違う
3. 必要な時点で識別し、到達できる
4. 群ごとに実際の施策や資源配分を変えられる
5. 十分な人数または事業価値がある
6. 差別、不公平、プライバシー上の危険を確認している

分けるほど理解が深まるわけではありません。群が小さすぎる、識別に高い費用がかかる、施策を変えられないなら、分ける実務価値は低くなります。

今回の仮説では、「小規模企業」をさらに、設定担当者が管理権限を持つ群と、他者承認が必要な群へ分けます。企業規模は募集の入口に使えても、支援方法を直接決めるのは権限関係かもしれません。

判定を運用できる仕様へ落とします。

識別できることと、原因であることは別です。他者承認が必要な群で未完了が多くても、企業規模、導入目的、契約時期などが同時に違う可能性があります。セグメントは試行対象と施策候補を決める仮説であり、その群で施策効果が大きいかは比較可能な試行で確かめます。

直接センシティブな属性を使わなくても、地域、役職、企業規模などが保護される属性や不利益の代理になる場合があります。分類によって誰が支援から外れ、どの負担が増えるかを確認し、必要以上の属性を集めません。

セグメントは固定的な人間分類ではありません。同じ企業でも、導入段階、担当変更、組織改編で状況が変わります。何の意思決定のための分類か、有効な時点はいつかを明記します。

11.7 ペルソナは証拠を圧縮する道具

ペルソナは、調査で見つかった行動、目標、制約のまとまりを、設計や意思決定で参照しやすくしたモデルです。名前、年齢、趣味、顔写真を付ければペルソナになるわけではありません。

今回なら、次のような短い記述にできます。

他部署承認待ちの設定担当者

契約後に初期設定を任されたが、管理権限は情報システム部門にある。導入期限はあるものの、依頼先と必要情報が分からない。同期面談は月末に取りにくい。現在は社内チャットで知人を探し、返答を待っている。

この記述の各要素は、参加者 ID、行動ログ、契約情報などへ戻れる必要があります。証拠がないのに「新しい技術が好き」「効率を重視」「SNS（交流・情報共有のためのオンラインサービス）で情報収集」のような設定を足しません。

ペルソナは実在の一人でも、平均的な人でもありません。複数の証拠を目的に応じて圧縮した仮説です。内部に重要な違いがあるなら、一つへ統合しません。ペルソナに合わない顧客を例外として捨てず、対象外とする理由や別の群を検討します。

顧客を理解するために、必ずペルソナが必要なわけでもありません。役割表、状況別セグメント、課題仮説の方が行動を決めやすいなら、それらだけで十分です。

11.8 課題仮説を証拠と反証へつなぐ

課題仮説は、確からしさの異なる内容を一文に混ぜず、構成要素ごとに証拠を置きます。

まず、仮説と証拠を置きます。

同じ ID で、限界と次の確認を置きます。

表の目的は、すべての欄を強い証拠で埋めることではありません。どこまで分かり、どこから推測かを見せ、次の確認を選ぶことです。

課題の重要度は、発言の強さだけでなく、次を組み合わせて判断します。

• 起きる頻度と対象数
• 顧客が失う時間、費用、機会、信頼
• 現在の対処へ払っている負担
• 事業成果との関係
• 自社が変えられる範囲
• 解決に伴う副作用と不公平
• 証拠の確かさ

頻度が高くても損失が小さい課題、損失は大きいが自社では変えられない課題があります。「重要」と「自社が解くべき」を分けます。

顧客にとって重要な課題でも、それだけで事業機会になるわけではありません。対象へ到達できるか、購入者が予算を持つか、提供費用に見合うか、自社の能力と方針に合うかを別に評価します。本章は顧客側の課題仮説を作り、競合・自社との適合は第12章以降、経済性は第5部へ引き渡します。

11.9 AI に顧客像を作らせず、証拠を整理させる

AI に業種と製品名だけを渡して「ペルソナを作って」と頼むと、もっともらしい名前、性格、悩み、行動を生成できます。しかし、それらは顧客調査の結果ではありません。一般的なパターンや文章上の補完を、実在顧客の事実として扱ってはいけません。

AI には、証拠の範囲を固定して依頼します。

意思決定:
どの顧客群へ、どの初期支援を試すか。

入力:
参加者 ID 付きの確認済み発言、行動ログの集計、契約条件。

依頼:
1. 主体、状況、進めたいこと、現在の行動、障害、代替へ整理する
2. 各記述に根拠となる参加者 ID またはデータ ID を付ける
3. 根拠がない内容を補わず「未確認」とする
4. 仮説を支持する証拠と反対例を並べる
5. 同じ属性でも行動が違う例を探す
6. セグメント候補ごとに、変えられる施策を示す
7. センシティブな属性による分類を警告する

AI が作ったテーマやセグメントは候補です。元の記録へ戻り、同じ証拠を重複して数えていないか、例外を落としていないか、複数人の発言を架空の一人へ統合していないかを確認します。

顧客名を消しても、企業規模、業種、役職、出来事の組み合わせから再識別できる場合があります。第10章と同じく、必要なデータへ限定し、承認された環境、アクセス、保存、出力共有を管理します。

11.10 対象、価値、検証を一文へ戻す

顧客理解の成果物は、人物紹介ではありません。誰のどの状況を優先し、何を変え、何をまだ確かめるかを意思決定者が選べる形にします。

今回なら、次のようにまとめます。

他部署の管理者承認が必要で、導入期限のある設定担当者を、最初の試行対象とする。IT 管理者へ必要情報と依頼方法を事前に届け、事業責任者の承認のもと、同期面談と非同期の依頼支援を選べるようにする。20 社で、14 日以内完了、支援工数、重大な苦情を比較する。企業規模だけでは対象を決めず、管理権限と期限を募集時に確認する。

この一文には、対象、状況、価値、支援の境界、検証が含まれます。ただし、まだ仮説です。試行結果が反対なら、対象条件、課題解釈、支援方法のどこを変えるかを記録します。

無料の試行へ参加したことは、継続利用や支払意思の証拠と同じではありません。この試行は、支援が設定完了と運用負荷をどう変えるかを主に学びます。購入、継続、価格を判断するには、実際の選択、更新、支払いを別の段階で確認します。

顧客課題を定めると、競合と自社を見る基準も変わります。同業他社の機能数ではなく、顧客が同じ進歩を得るために使う代替手段、自社がその状況へ到達できる能力、提供に必要な費用を比較できます。

考えてみる問い

最近聞いた顧客要望を一つ選び、主体、状況、進めたいこと、現在の代替、障害へ分けてください。その要望以外に、比較すべき解決策は何でしょうか。

顧客と課題を捉えるとは、もっともらしい人物像を詳しく描くことではありません。役割と状況を分け、要望を進めたいことへ戻し、言葉と行動の差、現在の代替、反対例を証拠として、誰の何を変えるかを選ぶことです。

第12章では、この顧客理解を 3C の「顧客」に置き、競合や自社能力との関係を見ます。3C の欄を埋めるのではなく、顧客が選ぶ代替に対して、自社がどの価値を実現できるかを判断します。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の役割表、課題仮説表、セグメント条件、AI 検証手順は、以下の資料を踏まえた本書独自の整理です。

• GOV.UK Service Manual ― Start by learning user needs ― サービス要件より先に利用者、目標、状況、課題を理解する原則を確認
• Christensen Institute ― Jobs to Be Done Theory ― 状況下で求める進歩として Job を見る実務的説明を確認
• Harvard Business Review ― Know Your Customers' “Jobs to Be Done” ― JTBD の背景、状況、機能・社会・感情面の説明を確認。閲覧環境により全文購読が必要
• OpenStax ― Principles of Marketing: Market Segmentation ― 市場セグメンテーションの定義と主要な切り口を確認