asb-carol-define について
重要な顧客条件、除外条件、購入のきっかけを統合し、行動に結びつく理想顧客像を定義するマーケティングスキルです。市場セグメントが分かれる場合は、主要対象を選ぶ手順も示します。
主な機能
- 01顧客分析の前段階を統合
- 02実行可能な顧客特性を定義
- 03異なるセグメントから主要対象を選択
- 04定義と参照情報を分離
活用シーン
- 01共通の理想顧客像の作成
- 02マーケティング、営業、製品の目標特性を統一
- 03顧客群が分かれる場合の主要セグメント選定
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ asmartbear/ asb-skills --skill asb-carol-defineインストール後、Claude Code で/asb-carol-defineを入力して読み込まれたか確認します。
詳細
Carol を定義する:あらゆる取り組みが目指す理想の顧客
Carol は、最も純粋な形では存在しないかもしれません。最も有利な特性を集めて人工的に構築された理想像です。しかし、空想の産物ではありません。彼女の定義に含まれるすべての指標は、これまでのステップで明らかになったこと、つまり、あなたの強みを極端な形で必要とするのは誰か、弱みのために誰が対象外になるのか、そしてどの瞬間に適合性が購入へと変わるのか、に基づいています。このスキルは、その定義を組み立て、すべての項目が実行可能性の基準を満たすようにし、会社の他のメンバーが参照する唯一のファイルを作成します。
基本となる考え方
ここで完結する5段階の導出
- 強みと弱み — 自分が何者かを率直に見つめます。
- 要となる条件 — 強みを極端な形で必要とする顧客の状況と、それを典型的に示すセグメントです。
- 取引を妨げる条件 — 対象外となる条件、アンチマーケット、そして要となるセグメントに課す、対象を絞り込むための条件です。
- きっかけとなる出来事 — 要となる条件に合う顧客が「購入できる」から「今日購入する」へと移るきっかけです。
- Carol — このステップでは、要となる条件、取引を妨げる条件、きっかけとなる出来事を統合し、チームが行動に移せる行動面・態度面の特徴として表現します。
人口統計を超えて
従来の市場の説明 — 企業規模、地域、年齢、B2B と B2C の区別 — は、たいていターゲットを誤って描写します。あるシットコムは、人口統計上のプロフィールでは「45歳以上の女性」とされていましたが、その一方で、鋭く人物描写に優れた風刺コメディを好む若い男性の間でカルト的な人気を博していました。その人口統計は平均的な視聴者については正しかったものの、次の視聴者を見つけるには役立ちませんでした。メールクライアントの本当のターゲットは、企業規模や国ではありません。1日に何百通ものメールを受け取る人、メール処理を担当するアシスタントがいる人、あるいは体系的なアウトバウンド活動を行う人です。ターゲット市場を定義するのは、優良顧客に実際に共通するもの、つまり要となる条件、取引を妨げる条件、きっかけとなる出来事のパターンです。人口統計を用いるのは、それが本当に決定的な場合に限ります。たとえば、ノルウェーの歯科医向けバックオフィスソフトウェアなら、「ノルウェーの歯科医」と正直に言えるでしょう。判断基準は予測力です。その指標は優良顧客と不良顧客を見分けられるでしょうか。それとも、誰にでも当てはまることを丁寧に説明しているだけでしょうか。
人口統計以外の切り口の一覧
人口統計は安易な切り口です。以下の次元こそ、優良顧客と不良顧客を実際に分けるものです。この一覧は2つの方法で活用してください。1つ目は、候補となる指標を検証することです — 「スピード」はセグメントではないため、これが実際にはどの切り口なのかを問いましょう(緊急か慎重かを分けるきっかけなのか、意思決定サイクルの違いなのか、問題のオーナーシップの違いなのか)。2つ目は、1つの Carol が正直に両方をカバーできるかどうかを判断する前に、2つのセグメントが分かれる軸を明確にすることです。これらは例であり、すべてを網羅しているわけではありません。 2つの方法を同時に使ってください。文脈に合うものはそのまま活用し、残りは、この特定のビジネスに必要な同じ種類の切り口を生み出すためのモデルとして使います。最も鋭い指標は、どの一覧にも載っていない次元であることがよくあります。これは思考を促すための出発点であり、完了すべきチェックリストでも、対象となる切り口の境界でもありません。どのケースでも、ほとんどは当てはまらず、正直な答えはたいてい「わからない」か「気にしない」です。(*ターゲット市場の選び方*より。ここでは、これらを網羅的な一覧ではなく、考え始めるための材料として紹介しています。) 人物とその役割
- 個人かチームか — 1つの製品が2つの市場を対象とすることがあります。「両方」の場合もあります(無料の個人モードでユーザーを引きつけ、チームから収益を得ます。Asana、Notionなど)。
- 社内での役割 — 顧客対応か社内向けか、周囲から何を期待されているか。
- 役職 — 特に業界や企業規模によって、通常はさまざまです。
- 作り手か管理者か — 作成・制作・提供を行うのか、それとも管理・監視・分析・報告を行うのか。
- 問題のオーナーシップ — 解決する問題を誰が「所有」しているのか。1つの役割が担うのか、分散しているのか。問題のオーナーが解決策のオーナーでもあるのか。
- 技術的な知識 — 「アルゴリズムについて議論するエンジニア」から、「嫌いなデバイスを仕方なく使うテクノロジー嫌い」まで。
- 学習スタイル — 動画、ドキュメント、1対1のトレーニング、または自分で試して学ぶスタイルです。オンボーディング、サポート、マーケティングに影響します。
成功の意味
- ジョブ達成の成功 — どのような目標数値で評価されるのか。何が必須で、何が業務上の指標なのか。何を達成すれば満足で、何を最大化するのか。どの数値が変われば昇進または解雇につながるのか。
- 個人的な成功 — 何にやりがいを感じ、どのような摩擦なら受け入れ、社内であなたを推奨するきっかけになるのか(ニーズスタック)。
- キャリア上の成功 — どのように評価・昇進するのか。キャリア初期・中期・後期では、企業規模にかかわらず優先事項が異なります。
- 企業目標 — 売上成長率、売上規模、利益額、利益率、市場シェア、Rule-of-40、コスト削減、GPM。
組織
- 組織の規模 — 中小企業向け製品は大企業に購入されることがよくありますが、その逆はあまりありません。トップダウンで販売する場合や、組織自体が対象となる場合(HR ソフトウェアなど)に特に重要です。
- 成長の軌道 — 急成長、安定、または衰退のいずれかによって、優先事項や制約が異なります。
- 規制環境 — 規制の厳しさと、その規制を行う機関です。必要な機能、コンプライアンス、リスク許容度を左右します。
- 文化的特性 — 生産性とワークライフバランス、倫理的な姿勢、外部のイノベーションと内部の効率性。
- キャズム越えの段階 — イノベーター(試行錯誤を好む人)、アーリーアダプター(優位性を得るためにリスクを取る人)、アーリーマジョリティ(慎重で、完全な製品を必要とする人)、レイトマジョリティ(圧力を受けて導入する人)。
- リスク許容度 — 新しい市場には、リスクを受け入れる顧客が必要です。企業規模との相関はありません。
- 技術スタックに対する考え方 — オープンソース、プロプライエタリ、クラウドネイティブ、またはオンプレミス。通常は単なる技術的要件ではなく、価値観の表れです。
購入と意思決定の方法
- 予算の種類 — 固定・年次、柔軟、または必要に応じて資金を確保する形式です。販売の形が変わる予算の境目はあるでしょうか。
- 販売プロセス — トップダウンか、ボトムアップ/PLG/フリーミアムか(トップダウンは企業規模と相関することが多く、ボトムアップはそうとは限りません)。
- 意思決定のサイクル — 数時間、数週間、または数四半期です。
- 緊急対応か慎重な検討か — セキュリティ侵害のような緊急のきっかけによるのか、調査・比較・試験導入を経て決定するのか。
- ビジネスモデル — サブスクリプション、買い切り、トランザクション、従量課金、フリーミアム、広告モデル。重視する指標や支払い方法を左右します。
使用するツールとワークフロー
- インテグレーション — 製品を連携させる必要があるもの(ワークフロー、AI、ToDo、プロジェクト管理、チャット)。
- 日常的に使う他のソフトウェア — 期待や利用体験の特徴を把握できます。
- プロセス — 使用している、または実現を目指しているワークフローです。特に、製品と交わる部分が重要です。
- 働き方 — リモート/オフィス/ハイブリッド、タイムゾーンの分散、労働時間、同期型か非同期型か。
- 更新頻度 — 頻繁で段階的な更新か、頻度は低いが大規模な更新か。製品のリズムを左右します。
- コミュニケーション文化 — メール中心、Slack 依存、または会議中心。
なぜを繰り返す連鎖
最初の答えが決め手になることはほとんどありません。「最も優良な顧客は速度を重視します」――速度は機能であって、セグメントではありません。なぜかを尋ね、問い続けます。速度 → なぜなら、eコマースではチェックアウトの速度が売上に直結するから。速度 → なぜなら、メディアではセッションあたりのページ数が広告収入につながるから。速度 → なぜなら、B2B のランディングページでは、わずか数千回の訪問に予算全体が集中するから。連鎖の行き着く先は、一人の人物です。ウェブサイトが速くなれば売上が直接増え、100 ミリ秒の価値を金額で計算できる人。 これが、マーケティングがターゲティングでき、セールスが見込み顧客を評価でき、プロダクトが大いに喜ばれる機能を作れるような定義です。CAROL.md のすべてのマーカーが満たすべき基準です。
的の中心:Carol だけを狙うことで、すべての人に勝てる理由
Carol だけをターゲットにすると市場を縮小させるように感じますが、実際は逆です。Carol の周囲には、同じトレードオフの大半を重視し、それ以外には関心がない顧客層があります。その数はおよそ 10 倍です。その周囲には、トレードオフを比較検討し、あなたが自社の立場を明確かつ自信を持って示したことで、自社が最適だと判断する、さらに大きな顧客層があります。その数は最大で 100 倍に上ります。明確なトレードオフを自信を持って示すことが、人々が実際に購入する方法です。誰にでも向けた一般的なポジショニングでは、3 つの層すべてを同時に逃してしまいます。メッセージが Carol さえ惹きつけられないなら、ほかの誰かを納得させることもできません。これが戦略上の根拠であり、定義ファイルに簡潔に記すことで、すべての読者がなぜ狙いをこれほど絞るのかを理解できます。
セグメントが分かれるなら、選択が必要です
洗練されたキーストーンが、本質的に異なるセグメント――たとえば、異なる価格で異なるニーズを持つ個人経営の店舗と複数拠点を持つグループ――を示している場合、Carol をその平均にすることはできません。中間点に設定した定義では、実在する誰も描写できません。ときには、「なぜ」の連鎖によって、その下に共通する状況が見つかり、ひとりの Carol で各セグメントを正直に表せることもあります。そうでない場合、ユーザーは主要セグメントを選ばなければなりません。キーストーンが集中している場所、観察されたきっかけとなる出来事、利益を示す証拠がどのセグメントを支持しているかを参考にして選び、定義では誰を選んだのか、誰がサービス対象ではあるものの二次的な市場にとどまるのかを明記します。選択するのはユーザーです。選択を避けること(または曖昧な表現に隠すこと)は、この作業の目的を損ないます。
用語
- Carol — 理想的な顧客です。完全な形では実在しない可能性もある複合的な人物であり、そのマーカーはすべて作業ファイルから導き出されます。
- Marker — 定義に含まれる行動、態度、状況に関する特徴です。それぞれ、ターゲティングでき、適合性を評価でき、そのための製品や機能を作れるものでなければなりません。
- 適合条件/除外条件 — セールスが見込み顧客を Carol に近いか遠いかで振り分ける際に使う質問やサインです。キーストーンと取引の阻害要因から導き出されます。
- 主要セグメント — セグメントが分かれる場合に、Carol の定義対象となるセグメントです。それ以外は混ぜ合わせず、二次的なセグメントとして明記します。
定義を行う際の姿勢
気の利いた表現より、明快さを優先する
感心されるためではなく、理解してもらうために書きます。ここで取り組むのは難しい概念です。気の利いた比喩、言葉遊び、しゃれた言い回しは、理解を助けるどころか難しくします。言いたいことを率直に述べます。飾りをなくしたほうが文が明確になるなら、その飾りは削ります。機知に富んだ言い回しでほのめかすのではなく、要点をそのまま述べます。
参照先を言い直す。記号だけを引用しない
K4、W2、O17、H3 など、番号や文字で示された項目をユーザーに伝えるときは、それが何を表すのかを簡単な言葉で補足します(「K4 — キャリアがサイトにかかっているオーナー」など)。その記号が定義されたのを何時間も、あるいは何日も前に見た人にとって、記号だけでは意味が分かりません。タグは追跡可能性のため、説明は理解のために使います。正確さのためにタグを残し、必ず説明を添えてください。
読む人は2種類、ファイルは1つ — 定義を先に
CAROL.md は、ざっと目を通す人間(簡潔で明快な定義を冒頭に)と、下流の作業者やツール(引用付きの参考セクションを後半に)の両方に役立ちます。定義セクションは、除外によって文体を厳しく制御します。各マーカーは、具体的な特徴を端的に示すものです。引用も、導出の経緯も、「これは私たちの強みである……に由来し」といった説明も、曖昧な表現も入れません。誤り:「~価値観が品質を重視する(S2 から導出。ただしセグメントによって異なる)。」正解:「給与計算を自分で行い、夜間や週末も働き、オフィススタッフはいない。」導出の経緯は参考セクションに記載します。そこでは、すべての要石、取引を左右する要素、イベントに、作業ファイルに戻れる [K]/[D]/[E] の番号を付けます。
再検討ではなく、統合する
作業ファイルはすでに各自の審査を通過しています。決着した分類を再び持ち出したり、練り上げたセグメントを再検討したりしないでください。ここで行うのは、組み立て、理由の連鎖をたどった圧縮、そして実行可能性の基準への適合です。例外として、統合によってファイル間の実際の矛盾が明らかになった場合(反市場分析で要石となるセグメントが取り込まれていた、誘因となるイベントの対象が誰もいないなど)は、所見として示します。上流の修正が必要なら、どのファイルを修正すべきかを伝え、黙って編集することは避けてください。
すべてのマーカーを基準に照らす
候補となる各マーカーについて、迷ったときは声に出して確認します。マーケティングはこれをターゲティングできますか(広告チャネル、検索語句、リストなど)。セールスは1、2問で適格性を判断できますか。プロダクトは、この人物が特に魅力を感じる機能を具体的に挙げられますか。3つすべてに当てはまらないマーカーは、定義ではなく単なる描写です。理由の連鎖をたどり(次元メニューに照らして検証し)、掘り下げるか、削除してください。あらかじめ定められた掘り下げ方として、環境に悪魔の代弁者として問い詰めるスキル(たとえば、この手法と同じ作者による Rude Q&A / asb-rude-qa)がインストールされている場合は、次の要件を添えて草案の定義に対して実行してください。*この理想顧客の定義を攻撃してください。人口統計に頼った安易なマーカー、優良顧客と不良顧客を区別できないほど一般的なマーカー、広告でターゲティングできず営業担当者も適格性を判断できないマーカー、そして異なる2つのセグメントを選ばずに平均化した箇所をすべて見つけてください。都合のよい願望や曖昧な弁明は認めないでください。*そのようなスキルが利用できない場合は、レビュー工程として、目に見える形で自らこの問い詰めを行ってください。
選択するのはユーザー。平均化しないことは譲れない
セグメント間に違いがある場合は、候補となる各主要セグメントについて証拠を提示します(要石の集中度、観察されたイベント、強みファイルにある差別化要素から得られる利益の兆候など)。そのうえで、ユーザーに選択してもらいます。選択がユーザー自身の証拠と矛盾する場合は、率直に一度だけ指摘し、それでもユーザーが下した判断を、その理由とともに記録します。決して認めてはならないのは、両方を網羅できるほど曖昧な定義です(「効率を重視する成長企業」など)。それは、この手法が防ごうとしている平均化そのものです。どんな言い回しであっても、記述してはいけません。
このスキルの使い方
フェーズ A — 取り込み
4 つの作業ファイル(デフォルトではカレントディレクトリにある以下のファイル)を読み込みます。
STRENGTHS-WEAKNESSES.md、KEYSTONES.md、DEALBREAKERS.md、
INCITING-EVENTS.md。実用最小限の入力は、磨き込まれたセグメントを含むキーストーンファイルと、ディールブレーカーです。インサイティングイベントがない場合、定義の「購入のきっかけ」セクションが弱くなります(その旨を伝えてください。セクション内でも不足を記します)。強み/弱みがない場合は、トレードオフの枠組みが弱くなります。最小限の入力すらない場合、雰囲気で定義してはいけません。上流のステップを「インストールされていれば呼び出す」形式で示します(最初のステップは Observations / asb-carol-observations)。ユーザーが希望する場合に限り、暫定的なスケッチを提示し、暫定版であることを明示します。キーストーンの変更履歴を確認し、磨き込みが行われているか確認します。磨き込まれていないセグメントがある場合、定義は範囲の広すぎる指標を引き継ぐことになるため、その旨を指摘します。CAROL.md が存在する場合、作業中のヘッダーがあればレビュー済み箇所を示すポインターから再開し、完了済みであれば改訂するかどうかを尋ねます。
出力:同じディレクトリに CAROL.md を作成します。入力が貼り付けられたもので、保存先のパスが不明な場合は、作成を始める前にメソッドのファイルをどこに置くか尋ねます(デフォルト:カレントディレクトリ)。ファイルを黙ってあちこちに作成してはいけません。
フェーズ B — 統合して全体の草稿を作成
内部で次の確認を行います。磨き込まれたキーストーンのセグメントを分類し(同じ状況を共有しているか、異なる状況に分かれているか)、候補となる各指標について「なぜ」を掘り下げ、キーストーンとディールブレーカーから限定条件と除外条件を拾い上げ、イベントファイルから購入のきっかけに関する材料を取り出し、ファイル間の矛盾を確認します。セグメントが分かれている場合、草稿の作成を止め、まずユーザーと選択を行います。主要な判断はすべての文面を形作るため、レビューまで先送りにはできません。判断が下されたら、すぐにディスクへ記録します(ヘッダーだけの CAROL.md を1行作るだけでも十分です)。これにより、セッションが途中で終わっても判断が失われません。記録後は、「両方を対象にできない?」といった曖昧な言い換えで選択をやり直してはいけません。折衷案は拒否し、ユーザーが本当に主要対象を切り替えたいのであれば、根拠に照らして選択をやり直すことを提案します。
その後、作業中のヘッダーを付けた完全な草稿をディスクに書き込みます。ファイルが記憶の役割を果たします。草稿全体をレビュー用に提示し、やり取りごとに1~2セクションずつ、ファイルの先頭から順に進めます(レビュー済み箇所のポインターはこの順序を前提としており、再開したセッションでもこれに従います)。各レビュー後、ディスク上のポインターを最新の状態に保ちます。最終確定の前に、定義全体に対する悪魔の代弁者による検証を、方針に応じて委任するか自分で行い、レビュー過程として見える形で実施します。事実関係の修正は作業ファイルに反映します(記憶よりファイルを優先します。再開時に作業ファイルを読み直すのは、まさにこのためです)。表現や強調の仕方はユーザーが決め、指標は基準を満たした場合にのみ変更します。レビューコメントから上流ファイルの誤りが示唆される場合(反市場セグメントが二次的なものとして書き換えられている、イベントのステータスが以前とは異なる形で記憶されている、など)は、統合時の矛盾と同じルールを適用します。どのファイルに属する問題かを伝え、黙って編集することは避けます。CAROL.md がソースをひそかに上書きすることは決してありません。
ファイル構成
# Carol — <company / project name>
> ⚠️ IN PROGRESS — review not started; begin at the definition.
> (Later: "draft under review; reviewed through <section>." Removed
> at finalization.)
<One line: synthesized from which files, as of when. If a primary
segment was chosen over others, one line naming the choice.>
## Carol
<The definition. A short prose portrait (2–4 sentences) followed by
the markers — each a bare, specific behavioral/attitudinal/
circumstantial characteristic. No citations, no derivation, no
hedging here. Numbers are welcome when they quantify a predictive
circumstance ("20 or more tipped employees" — the number IS the
keystone threshold); numbers as proxies are not ("$2M+ revenue" —
a list-building heuristic wearing a marker's clothes; press to the
circumstance it stands for).>
- <Marker: circumstance — "runs 3+ locations with staff floating
between them">
- <Marker: behavior — "does payroll personally, Sunday nights">
- <Marker: attitude — "treats compliance as an existential risk, not
paperwork">
- <Marker: economics — "values one prevented violation above a year
of fees">
## How to recognize Carol (qualifiers and disqualifiers)
Qualify toward: <the one-or-two-question sorts, from the keystones —
"do you take the tip credit, and in which states?">
Disqualify away: <the anti-market signals, from the deal-breakers.>
## Why aiming only at Carol wins the whole market
<Three or four sentences: the bullseye — the ~10x ring who share her
trade-offs, the ~100x ring who weigh them and pick you because the
trade-offs were stated clearly; if the message can't excite Carol it
convinces no one. If a primary segment was chosen, name the secondary
markets that remain served-but-not-targeted.>
## Keystones (reference)
<One line each, with [K-numbers] — what circumstance requires which
strength, and the honed segment.>
## Deal-breakers and anti-market (reference)
<One line each with [D-numbers]; the anti-market statement carried
over — deliberately excluded, dissuasive ad language, no features for
the tail.>
## Inciting events (reference)
<One line each with [E-numbers] and status (observed/hypothesized) —
the buying moments, with findability in a word or two. If the events
file was missing or thin: the gap, named, with the validation path.>
## Provenance
<Which files, as of which dates/change-log states; contradictions
surfaced during synthesis and where they were sent.>
フェーズ C — 最終確定
すべてのセクションがレビュー済みになるか、ユーザーが残りのレビューを明示的に省略した場合に最終確定します。ヘッダーを削除し、定義を最後にもう一度読み返します。誰もが引用するのはこの部分です。最後に引き継ぎ事項を伝えます。このファイルは後続作業への 入力 です。ポジショニングは Carol の言葉で語り、マーケティングは彼女の関心を引き、営業は彼女を指標に照らして見極め、プロダクトは彼女を夢中にさせるものを作ります。それぞれの作業は、対応する参照セクションから始めます。定義が仮説に基づくインサイティングイベントや、検証されていない仮説に依拠している場合は、その旨を伝えます。関連する顧客インタビューのメソッド(インストールされている場合、最初のスキルは asb-interview-goals)を使えば、実際の顧客を対象に定義を体系的に検証できます。最初の標準的な目標は、文字どおり「Carol はどのような人物か?」です。
拒否条件
- 上流のファイルがない場合。 雰囲気だけで定義された Carol は、ペルソナのポスターであって、計器ではありません。手法の最初のステップを示し、求められた場合に限り、暫定版であることを明示したスケッチのみを提示します。
- 人口統計で安易に分類すること。 「中小企業」「ミレニアル世代」「売上高100万ドル超の企業」は、実際に決定要因となる場合を除き、定義に含めません。購入を予測する状況に行き着くまで「なぜ」を掘り下げるか、その指標を削除します。
- セグメントを平均化すること。 要となるセグメントが異なる場合、両方を曖昧にカバーする表現は決して書きません。どちらかを選び、その選択を明示して理由を述べます。そうでなければ、相違を未決の事項として記録し、定義は保留します。
- 基準を満たさない指標。 どの広告でもターゲティングできず、どの営業担当者も見極められず、どの機能でも心を躍らせられない特性は、どれほど真実らしく感じられても記録しません。
- 後工程の作業を行うこと。 ポジショニングステートメント、広告コピー、ホームページの文言、機能ロードマップなどは引き受けません。参照セクションはそれらのインプットであり、それぞれに専用のセッションが必要です。
- 統合を省略すること。 作業ファイルなしに「すでにあるペルソナを少し整えてほしい」と言われた場合は、率直にこう答えます。この手法では証拠から Carol を導き出します。導出されていないペルソナを整えても、推測を引き継ぐことになります。存在するファイルを使って導出を行うことを提案します。