asb-carol-dealbreakers

決定的な障壁：どんな条件でも決して購入しない顧客

購入者に3つの要となる条件がそろっていても、対象外になることがあります。SOC 2 が必須なのに、こちらが取得していなければ取引は成立しません。決定的な障壁は要となる条件に優先し、購買委員会もベンダーと同じくらい、これを残念に思います。このスキルでは、弱点のチャートからそうした対象外条件を明らかにし、その条件に該当する非ターゲット市場のセグメントを特定します。さらに、上流のすべてを明確にする重要な作業として、決定的な障壁によって求められる条件を加え、要となる各セグメントを絞り込みます。

基本的な考え方

弱点 → 決定的な障壁 → 非ターゲット市場

この手順は、要となる条件を特定する手順をもう一方の列でそのままなぞります。弱点ごとに、どのような状況でこの弱点が、単に煩わしいものや交渉材料ではなく、対象外となる決定的な理由になるのか？と問いかけます。そして、そうした状況にある実際の市場セグメントを特定します。これらのセグメントが非ターゲット市場です。つまり、潜在市場の範囲外です。標準的なチャートを例にすると、「高価」は、ウェブサイトの予算が月額5ドルの人（個人プロジェクト、米国価格を支払えない市場の小規模事業者）を対象外にします。「WordPress のみ対応」は、すでに別のものを基盤に構築している人全員を対象外にします。「デザインと構築が必要」は、今夜までに1ページのサイトを仕上げる必要がある人を対象外にします。

すべての弱点が決定的な障壁につながるわけではありません。市場の3分の1が嫌がっても、誰も購入を見送るほどではない弱点は摩擦要因です。比較検討で不利になりますが、境界線を引くものではありません。この違いを記録してください。摩擦要因は製品バックログに、決定的な障壁は市場マップに反映します。

決定的な障壁で要となる条件を絞り込む

この手順で得られる最も価値ある成果は、非ターゲット市場のリストではありません。決定的な障壁によって、要となるセグメントがどう変わるかです。「速度が収益につながる EC ストアを持っている」という条件に、「高価」という決定的な障壁を加えると、「月間5,000ドル以上の処理をしている EC ストアを持っている」になります。それ以下のストアはプレミアムな選択肢を購入できないため、そもそも本当の意味でそのセグメントには含まれていません。「WordPress のみ対応」を加えると、「…すでに WordPress で構築されている」になります。条件を絞り込むたびに、要となる条件の説明はより強力になります。広告でターゲットにしやすくなり、営業で適合性を見極めやすくなり、顧客の声がより参考になり、機能の優先順位も明確になります。説明が具体的になるほど、理想の顧客像に近づきます。

非ターゲット市場は意図的に避ける

非ターゲット市場は残念な副産物ではなく、指針です。マーケティング、営業、機能開発から、これらのセグメントを意図的に除外してください。

• 広告では、ターゲットに訴求しつつ、非ターゲット市場がクリックを思いとどまるような言葉を使います。「最も要求の厳しいウェブサイト向け」と伝えれば、月額5ドルの予算で探している人はスクロールを続けるでしょう。それがまさに狙いです。適合しないクリックはすべて費用がかかり、適合しないトライアルはすべてサポート時間を消費します。
• 製品では、非ターゲット市場に響く機能を作らないでください。そうした要望は、声高に寄せられるでしょう。しかし、それは戦略の基盤となる顧客ではなく、顧客基盤のうち利益を生まない層からの要望です。

今あるもので売る

決定的な障壁に直面するたびに、「でも、それを解決する機能を追加できるのでは」と言いたくなるでしょう。いつか、意図的な戦略上の判断として、そうすべきかもしれません。新しい市場に対応するには、1つの機能を追加する以上の取り組みが必要だからです。今日の仕事は、今のままの自分たちが勝てる市場を説明することです。解決策のアイデアは、戦略への入力として記録に残して保留します。決定的な障壁はそのままにし、現存する製品を基に条件を絞り込みます。

用語

• 致命的条件（D1、D2、…） — 弱点によって製品が完全に不適格となる状況です。その弱点の[W番号]を示します。
• アンチマーケット — そうした状況にある実際のセグメントです。マーケティング、営業、製品に関する意思決定から意図的に除外します。
• 摩擦要因 — 点数は下がるものの、誰かを不適格にはしない弱点です。そのように記録し、致命的条件は導き出しません。
• 精緻化 — 致命的条件によって必要となった限定条件を、要となるセグメントの説明に追加することです。番号を変更せず、キーストーンファイルを編集します。

精緻化を行う際の姿勢

気の利いた表現より、明快さを

感心されるためではなく、理解してもらうために書きます。ここで扱うのは難しい概念です。気の利いた比喩、言葉遊び、しゃれた言い回しは、理解を助けるどころか、難しくします。言いたいことを率直に述べてください。飾りを省いたほうが明快になる文なら、その飾りは削ってください。巧みにほのめかすのではなく、要点をそのまま述べてください。

参照先を言い換える。記号だけで示さない

番号や文字で示された項目に言及するときは、K4、W2、O17、H3などの記号だけでなく、それが何を指すのかを簡潔に説明してください（「K4 — キャリアをそのサイトに懸けている所有者」など）。数時間、数日前に定義を見た人にとって、記号だけでは意味が分かりません。記号は追跡可能性のために残し、説明は理解のために必ず添えてください。

キーストーンの規律に倣う

致命的条件の候補は、あなたのものもユーザーのものも自由に挙げ、それぞれを明確に検証してください。その状況は本当に不適格にするものか（単に不満を招くだけではないか）、実在するアンチマーケットのセグメントを特定できるかを確認します。ターゲットに対して行ったのと同じように、曖昧なセグメントを具体的な状況と行動に落とし込みます。さらに厳しく検証する方法として、悪魔の代弁者として問い詰めるスキルが環境にインストールされている場合（たとえば、この手法と同じ作者による Rude Q&A / asb-rude-qa）、次の要旨で草案に対して実行してください。これらの致命的条件に異議を唱えてください。実際には誰も拒否しない単なる摩擦要因にすぎないもの、意図的に除外するには曖昧すぎるアンチマーケットのセグメント、的を外していて鋭く踏み込めていない精緻化の限定条件を、すべて見つけてください。願望や自己弁護に基づく回答は受け入れないでください。 そのようなスキルが使えない場合は、自分でその検証を明示的に行います。候補はその場に記し、最後の総点検でまとめて問い詰めます。

市場を知るのはユーザー。仕組みは変えない

あるセグメントが本当に拒否するか、アンチマーケットが実在するかについては、一度率直に問いただした後は、ユーザーの市場知識を優先します。ただし、ユーザーの判断でも変えられないことがあります。拒否するセグメントがない致命的条件は、致命的条件ではなく摩擦要因です。精緻化で編集してもキーストーンファイルのK番号は固定し、変更履歴に1行を残します。「その弱点はすぐに修正する」という約束で、現時点のマップを甘く評価してはいけません。

精緻化は提案するものであり、押し付けない

精緻化の編集はそれぞれ1つの提案です。キーストーンの現在のセグメント行、そのセグメントと関係する致命的条件、限定条件を加えた書き換え案を、変更前・変更後の形で示し、判断はユーザーに委ねます。どの致命的条件にも該当しないキーストーンセグメントには手を加えず、そのことを伝えて先に進みます。限定条件によってキーストーンの内容が損なわれ、精緻化後のセグメントがほとんど空になってしまう場合は、その事実を率直に伝えます。このキーストーンの市場は、見かけより小さい可能性があります。

1回のやり取りにつき1項目

マッピングの進行では、1回のやり取りにつき弱点を1つ扱います。精緻化の進行では、1回のやり取りにつきキーストーンを1つ扱います。最初は小さく始めます。依頼があれば儀礼的な部分は簡潔にしますが、構成は変えません。

このスキルの使い方

フェーズ A — 取り込み

弱点（現在のディレクトリにある STRENGTHS-WEAKNESSES.md がデフォルトです。強みと弱みの両方に分類された属性は、弱みとして読む場合にここに含めます）と、キーストーンのファイル（KEYSTONES.md）を読みます。キーストーンのファイルに「判定」セクションがある場合（残ったキーストーンがゼロまたは1つの場合）は、絞り込みを始める前に提示してください。まだ魅力が十分でない製品の反市場を割り出すのは時期尚早かもしれないため、先に進むかどうかをユーザーに確認してください。 キーストーンのファイルが見つからない場合：マッピングは進められますが、絞り込みはできません。何ができないのかを伝え、そのファイルを作成する方法として、キーストーンの手順を「インストール済みなら呼び出す」形式で提示してください（例：Keystones ／ asb-carol-keystones）。弱点が見つからない場合（例：キーストーンの手順が簡易キャプチャから実行された場合）：今すぐチャットで、根拠のある弱点リストを作成してください。弱点を絞り込むための短い一般性チェックを行い、W番号を順次確定しながら、DEALBREAKERS.md の冒頭に記録します。ただし、精査されていない弱点から導かれるディールブレーカーも精査されていないことを注記してください。すでに DEALBREAKERS.md が存在する場合：進行中のヘッダーがあれば再開し、完了済みなら改訂するかどうかを確認してください。

出力：同じディレクトリに DEALBREAKERS.md を作成します。絞り込みによる編集は KEYSTONES.md に直接反映します。入力が貼り付けられたもので、ファイルの保存先が分からない場合は、何かを作成する前に、この手順で扱うファイルの保存先を確認してください（デフォルト：現在のディレクトリ）。ファイルを黙って別々の場所に散らかしてはいけません。

フェーズ B — ディールブレーカーをマッピングする

まずは小さく始めます。読んだ内容、失格要因になりそうな弱点と摩擦にすぎない弱点、そして最初の弱点を伝えます。弱点ごとに、次の手順を行います。

1. 鏡に映して問いかける — どんな状況なら、これは絶対に受け入れられないでしょうか？ユーザーの考えに加えて、候補も提示します。
2. 候補を一つずつ判定する：単に不快なだけでなく失格要因となること、そして意図的に除外できるほど明確に定義された反市場セグメントがあることを確認します。
3. [W-numbers] と反市場セグメントを添えてディールブレーカーを記録します。摩擦と判定したものは、理由を一行で記録します。
4. 「それなら修正できる」という案はすべて、戦略インプットのリストに保留します。アイデアは残しても、マッピングはその実現を待ちません。

作業しながらファイルに記録してください。 最初の項目が確定した時点で DEALBREAKERS.md を作成します（または、弱点を簡易キャプチャした場合は取り込み時に作成します。キャプチャ自体を残す価値があるためです）。ヘッダーの参照先は常に最新の状態に保ってください。記憶として残すのはファイルであり、チャットではありません。

フェーズ C — キーストーンを絞り込む

キーストーンのファイルを開き、やり取りごとにキーストーンを一つずつ確認します。それぞれについて、次の手順を行います。

1. どのディールブレーカーがそのセグメントと交差するかを示します（多くの場合、該当なしです。その場合はそう伝えて先に進みます）。
2. 条件を加えたセグメントの文案を、変更前と変更後の両方で提示します。各条件の根拠となる [D-number] も示します。
3. 合意したら、KEYSTONES.md を編集します。固定された K 番号のキーストーンについて、セグメントの行を更新し、そのファイルの末尾に日付入りの変更履歴を一行追加します（例：「2026-07-09: K1 のセグメントを絞り込み — 'processing ≥$5k/mo' [D1] と 'already built on X' [D2] を追加」）。初めて使う場合は変更履歴のセクションを作成します。編集、変更履歴の一行、ヘッダーの参照先の更新を一度に適用し、セッションが途中で終了しても、合意した変更がディスクに反映されないまま残らないようにします。番号は振り直さず、ユーザーからの依頼がない限り、セグメントの行以外のキーストーンの文言は変更しません。この確認で手を加えないキーストーンは、一度のやり取りで複数をまとめて確認しても構いません（判断を求めていないためです）。「K2、K4 を確認 — どのディールブレーカーにも影響されない」のように、まとめて一行の変更履歴を追加し、完了したファイルによって確認作業全体の実施を証明できるようにします。
4. 絞り込み後のセグメントがほぼ誰にも当てはまらなくなった場合は、その事実を明確に伝えます。正直に見積もった市場が小さいキーストーンは、隠すために条件を緩めるものではなく、戦略インプットです。

フェーズ D — 全体を見直して締めくくる

• 矛盾チェック — キーストーンセグメントと照らし合わせて、ディールブレーカーをもう一度確認します。ディールブレーカーの対象外となる人がまだ含まれているキーストーンセグメントがあれば、さらに条件を加えます。または、ディールブレーカーの反市場向けの表現が広すぎる場合は、絞り込みます（「単一拠点」を「管理スタッフのいない単一拠点」にするなど）。どちらの対応も妥当です。どちらが適切かは、証拠が示しています。
• 反市場向けの声明 — DEALBREAKERS.md に短い段落を 1 つ追加し、意図的に対象外とする顧客と、常設の指示（購買意欲を削ぐ広告表現を使うこと。要望がどれほど強くても、反市場向けの機能は追加しないこと）を記載します。
• 摩擦のリスト — 市場の境界線ではなく、製品バックログへのインプットとして読めることを確認します。

両方のファイルを仕上げます。進行中を示すヘッダーを削除し、キーストーンの前文にある「絞り込み前」という文を「セグメントを絞り込み済み — 変更ログを参照」に更新します。KEYSTONES.md の変更ログ（正式なヘッダーは ## Change log）に、どのように絞り込んだかが記されていることを確認します。最後に引き継ぎを行います。次のステップでは、きっかけとなる出来事を見つけます。つまり、ぴったり合う顧客が「購入できる」状態から「今日購入する」状態へ移るきっかけです。この手法の作成者によるきっかけイベントのスキルがインストールされている場合（例：Inciting Events / asb-carol-inciting-events）、次のように伝えます。「準備ができたら、これらのファイルを使って asb-carol-inciting-events を実行してください。」

ファイル構成

# Deal-breakers — <company / project name>

> ⚠️ IN PROGRESS — the walk is not complete. Weaknesses walked:
> <which W-numbers>; honing: <not started / K-numbers done>. If you
> are resuming, continue there. (This note is removed at
> finalization.)

<Two or three lines: which files this works from (name them), and
the company context. Deal-breakers disqualify outright and trump
keystones; the anti-market is deliberately excluded. Friction items
cost points but disqualify no one — they're backlog input, not
boundaries.>

## Deal-breakers

**D1.** <The disqualifying circumstance.>    [W2]
    Anti-market segments: <who lives there — sharp enough to
    deliberately exclude in ad targeting and sales qualification.>

**D2.** <…>    [W1]

## Friction (costs points; disqualifies no one)

- <Weakness> — <one line: who dislikes it, why nobody refuses over
  it>.    [W3]

## Anti-market statement

<One short paragraph: who is deliberately excluded and the standing
instructions — ad language that dissuades them from clicking, and no
features built for them, even though they'll ask.>

## Strategy-input list (fix-it ideas parked during the walk)

- <"We could add X to remove D2" — parked; addressing a new market
  is a strategy decision, not a qualifier dodge.>

## Next steps

<Two or three sentences of prose: find the inciting events — the
specific trigger moments that move a keystone-fit customer from
could-buy to buying-today; each couples to a keystone. That's the
next step of the method, and it works from the honed KEYSTONES.md;
this file's deal-breakers and anti-market feed the final
definition step.>

D 番号は一度記入したら固定です。説明は、番号を固定したまま、どの見直し時にもさらに明確にできます（絞り込み後に表現を修正した場合は、その条件が参照されている可能性があるため、絞り込み対象のキーストーンの変更ログの行に記録してください）。KEYSTONES.md の編集内容は K 番号ごとに記載し、変更ログの行を付けます。新しいセッションでは両方のファイルを読み込み、変更ログから絞り込みがどこまで進んだかを正確に把握できます（便利なヘッダー例：「絞り込み：K1 完了 — K2 から再開」）。

拒否条件

• 弱点がまったくない場合。 雰囲気だけで導き出したディールブレーカーは、誤った人々を対象外にします。分類のステップか、注意書きを添えた簡易記録を提案してください。
• 「弱点は修正するので、ディールブレーカーは不要です。」 現在提供できているものを売ります。このマップは現状を示すものであり、修正案は戦略へのインプットとして保留します。修正がリリースされるまでは、ディールブレーカーをマップから外しません。
• 大げさに見せるため摩擦をディールブレーカーに格上げする（または安心するためディールブレーカーを摩擦に格下げする）。 判断基準は、実際に拒否された証拠です。誰かが実際に対象外となるか、実際には誰も対象外とならないかを確認します。一度だけ問い直し、その後は証拠が裏付ける内容を記録します。
• 絞り込み条件が曖昧なままの場合。 「本気の顧客」は条件ではありませんが、「月に少なくとも 5,000 ドルを処理する」は条件になります。曖昧な条件は問い直すか削除します。中身のない条件で絞り込んだキーストーンには、何も絞り込まれていません。
• 反市場向けの顧客に合わせて構築する場合。 ユーザーがセッション中に対象外のセグメント向けの機能を計画し始めたら、そのルールを伝えます。そうした要望は裾野から来るものです。そのうえで保留します。
• ターゲットセグメントを選ぶ、または定義を書く場合。 それは後のステップで行います。このステップでは境界をマッピングし、ターゲットを明確にします。