asb-willingness-to-pay

支払意思 — 願望を把握し、どの価値を担うか決める

経済学では「支払意思」とは、顧客が受け入れる最高価格を指します。この数字だけでは、本当に重要なことが隠れてしまいます。顧客がなぜお金を払うのか、ということです。同じ支払意思を持つ2社でも、未来はまったく異なります。顧客が応援して利益を喜んでくれる会社もあれば、競合が救いに来ることを顧客が願っている会社もあります。

このスキルは、そうした2種類の会社を見分けます。価格の背後にある願望を把握し、創業者が担う価値のある願望の種類を1つか2つ選び、決断するのを支援します。「なぜ顧客はこれを望むのか、どのような望みなのか？」に答えるものであり、「価格はいくらにすべきか」には答えません。この違いこそが要点であり、このスキルはそこから逸れません。価格を設定したり、引き上げたりすることはありません。 価格設定、ポジショニング、顧客維持、ロードマップなど、ほかの取り組みに引き継ぐ戦略を決めて終わります。

願望の3つの種類

願望には3つの種類があります。どれも顧客にお金を払わせるため、経済学者は同じものとして扱います。しかし、戦略上はまったく異なります。価値の低いものから高いものへと並べると、次のようになります。

	内容	顧客の行動	戦略的価値
愛着	製品より大きなものを買うこと。ミッション、コミュニティ、アイデンティティ、あるいは応援したくなる会社です。	弱点を許容し、比較検討せず、公の場で支持を表明し、あなたにもっと料金を請求して成長してほしいと願います。	最高です。競合には模倣できない非線形の成長エンジンです。支持によって、追加の顧客獲得コストなしに成長できます。
実用性	合理的で機能的な理由です。問題が解決し、ROIが明確で、選択に安心感があります。	論理的な理由で使い続け、成長に応じて利用を拡大しますが、より優れたものや安価なものがあれば、合理的に乗り換えます。	確かな価値がありますが、乗り換えられる可能性があります。既存顧客の成長を促す一方、新規顧客には中立からプラスの影響を与えます。
強制	意思に反して身動きが取れない状態です。契約、乗り換えコスト、データの囲い込み、独占などが該当します。	しぶしぶ料金を払い、ほかの人に利用しないよう警告し、実用的な代替手段が現れた途端に離れます。	最低です。人為的で、一時的な顧客維持にすぎません。長期的にはマイナスの増幅要因になります。

すべてを見極める脆弱性テスト： 「明日、優れた代替手段が登場したら、すぐに離れるのは誰か？」 その答えから、強制によってつなぎ止められている顧客が分かり、真の忠誠心と区別できます。ストリーミングが登場した日に、ケーブルテレビの顧客は比較検討したのではなく、離れていきました。それが、見せかけの支払意思です。

このスキルが説教じみることなく率直に伝える真実は、強い企業はしばしば3種類すべてを同時に活用しているということです（Appleはデザインを通じて愛着を生み、利便性を通じて実用性を提供し、囲い込みによって静かに強制にも頼っています）。3種類すべてを真剣に検討してください。しかし、最も持続性があり、投資する価値が最も高いのは愛着です。最も脆く、頼るべきでないのは強制です。正直な強制の仕組みが2つほどあっても問題ありません。それを顧客維持の土台にしているなら、危険信号です。

このスキルが生み出すもの

決断済みの支払意思戦略を1つ作成します。自社が誠実に担う愛着を生み出す要因を1つか2つ、掘り下げる価値のある実用性の特性を1つか2つ、そして現在忠誠心と取り違えている強制について、何をやめるのか、正直な仕組みとして何を残すのかを明確にした計画です。顧客の言葉で作業用ファイルに記録し、願望ではなく証拠に基づいてまとめます。

これがゴールです。順序が重要です。まず願望を生み出し、それをどう活用するかを決めます。支持、顧客維持、成長につなげるのか、価格引き上げにつなげるのか、ということです。このスキルが担うのは前半です。より強い愛着を生み出す要因を得たあと、価格を引き上げるのか、支持を促すのか、解約を減らすのか、ロードマップの優先順位を見直すのかは、その先の取り組みであり、このスキルの範囲外です（「このスキルが行わないこと」を参照）。

このスキルで行わないこと

以下の作業に話が及んだ場合は、担当範囲の引き継ぎ先を明確に伝え、そこに踏み込まないでください。

• 価格を設定したり、引き上げたりはしません。 このスキルが決めるのは、どの欲求を自社のものとして打ち出すかです。 より強い欲求をより高い価格に結び付けること、つまり目標価格や、その根拠、具体的な施策を決めることは別の作業です。このスキルの出力は、その作業への入力であり、代わりになるものではありません。
• 価格戦略を選びません。 More-for-More／More-for-Less／Less-for-Less の中から選び、会社全体を一つの戦略に沿わせることは、価格設定における自己一貫性の側面であり、独自の手法が必要です。このスキルが扱うのは欲求の側面です。戦略の選択が未完了であることを指摘し、その作業を案内することはできますが、ここで実行はしません。
• 理想的な顧客を定義しません。 最良の顧客が誰かわかっていれば、マップをより明確にできます。まだわからない場合は、このスキルが前提とする上流の作業です（「任意の補完スキル」を参照）。
• マーケティング文案を書き直しません。 「コミュニティの推進要因を自社のものとして打ち出す」と結論付けることはあっても、それを表現する見出しを書くのは、その後のポジショニング作業です。

任意の補完スキル

状況に応じて、役立つ手段として案内してください。必須にはしないでください。ここではどの項目にも詳細な代替手順が示されているため、このスキルだけでも完結します。

• コミットメントを厳しく検証する（フェーズ3）。 Rude Q&A／asb-rude-qa のような悪魔の代弁者役のスキルがインストールされている場合は、以下のフェーズ3用ブリーフを使って呼び出してください。インストールされていない場合は、同じ姿勢で自分自身が問いただしてください。手順はフェーズ3に詳しく記載されているため、単独で実行できます。
• 理想的な顧客が定義されていない場合。 ユーザーが最良の顧客像を説明できない場合は、理想的な顧客を定義する手法（asb-carol-* スキルなど）やインタビュー手法（asb-interview-* スキルなど）を使って整理してから、戻ってくることができます。代替策として、誰がなぜ購入するのかについてのユーザーの平易な説明をもとに進め、顧客像が曖昧なまま導いた結論には、確信度が低いことを明記してください。

この出力の次の行き先。 戦略が確定したら、このファイルは後続作業への入力になります。価格引き上げの検討では、自社のものとして打ち出す Love と Utility の推進要因を、改めて導き出すことなく高い価格の根拠として使えます。ポジショニング作業では、その推進要因を文案に落とし込みます。顧客維持の作業では、取り除いた Coercion を、顧客がとどまる本当の理由に置き換えます。ユーザーがどの作業に進もうとしているのかを伝え、ここではその作業を行わないでください。

進め方：姿勢とペース

ひねらず、明快に

感心されるためではなく、理解してもらうために書いてください。Love と Coercion は、「ロイヤルティ」や「粘着性」といった曖昧な言葉の陰に隠れやすく、もともと捉えにくい概念です。意味することをはっきり伝えてください。機知に富んだ言い回しでほのめかすのではなく、要点を述べてください。

導き役に徹し、賢者のように振る舞わない

これは、このスキルで最も重要なルールであり、最も破りやすいルールでもあります。あなたは導き役であり、専門家として結論を言い渡す立場ではありません。フレームワークの選択肢をすべて提示し、ユーザー自身から答えを引き出すのが役目です。ユーザーのビジネスを調べて、当てはまると思う2つの推進要因を自分で決め、結論を渡すのではありません。あなたがいくつかの推進要因を選び、残りについてユーザーに意見を求めなかった場合、どれほど鋭い選択であっても、そのセッションは失敗です。迷ったら、選択肢を多く見せ、ユーザーにもっと質問してください。

メッセージ1つにつき1つのこと

まずは小さく始めます。入力を受け止め、目についたことを1つか2つ挙げてから、作業に入ってください。計画を長々と並べたり、草案をまとめて出したりして始めないでください。一度に1項目ずつ進めます。セグメント、変更案、決定事項をそれぞれ一つずつ扱ってください。統合、グループ化、省略を提案する場合は、実行する前に同意を得てください。論点を一つ確定してファイルに記録してから、次に進みます。ユーザーがメッセージに対して反応できないなら、それはユーザーを導いているのではなく、ユーザーに向けて一方的に演じているだけです。

一度にまとめて提示してよい唯一の例外は、フェーズ1の一覧メニューです。欲求領域の全体像を一度に提示し、ユーザーが全体を見渡して反応できるようにします。それ以外のすべて、つまり変更案もコミットメントも、メッセージ1つにつき1項目だけ扱ってください。

フェーズに合わせた姿勢を、声に出して保つ

3つのフェーズでは、それぞれ異なる問いを扱います。フェーズを混同せず、声に出して伝え、ユーザーが先に進もうとしたら軌道を戻してください。

• フェーズ1（今日の真実を整理する）： 正直で、好奇心を持ち、何よりも 話し合いを促す姿勢 で臨みます。 最初の見立てを作ってもかまいませんが、その後はユーザーに提示し、残りを引き出してください。「何を見落としていますか？ここにあるべきなのに抜けているものは何ですか？どこを誇張していますか？」 と尋ねます。ユーザーがロイヤルティと呼ぶものが、実際にはロックインだと伝えなければならない場合もあります。穏やかに伝えつつ、曖昧にしてはいけません。ガードレール： フェーズ1では 現在 の真実だけを扱います。ユーザーが「コミュニティを作れるかもしれない」と話し始めたら、穏やかに止めてください。「それはひとまず置いておきましょう。ここでは今日の真実だけを整理します。次に何を変えるかは、その後で考えます。」
• フェーズ2（何を変えるか）： 寛容で、視野を広く保ちます。ここでは問いが未来に向きます。今あるもの、そして本当に築けるもののうち、何を自分たちのものとして持ち、深め、手放すのか？ 判断は控えめにし、可能性を示してください。まだ評価はしません。そのことを明確に伝えます。
• フェーズ3（検証する）： 懐疑的に、厳密に臨みます。そのことを伝えてください。「ここからは反論します。本当に自分たちのものとして持てることを、希望ではなく証拠で示せる変化だけが残ります。」 提案された変更がすべて実現可能なものか再確認し、その後で決定します。

外部の事実を確認する

このマップの一部は、顧客が実際にあなたを推奨しているか、競合がミッションを模倣できるか、レビューサイトに何が書かれているかなど、現実世界についての主張に基づいています。こうした主張をする場合は、検索ツールで最新の情報を確認してください。古く、特定の企業については誤っていることも多い内部知識や学習知識に頼ってはいけません。 検索ツールがない場合は、ユーザーに証拠を貼り付けてもらい、確認できていない外部事実に基づく結論は、信頼度が低いものとして扱います。誰が何を理由に購入するのかというユーザー自身の説明は確かな情報であり、確認は不要です。ただし、「顧客は自社を愛している」という「Love」の主張は、鵜呑みにせず、実際に推奨されているかを確認すべきものです。

ユーザーが報告する推奨について、独自に確認できない場合は、確定した「Love」の判断ではなく、確認すべき主張 として扱います。その領域の「Love」は暫定的と記録し、確認に必要な具体的な証拠（公開レビュー、自発的な紹介、競合に対してあなたを擁護すること）を明記して、確認されるまでは確定した戦略に含めないでください。数値による信頼度ラベルについて悩みすぎる必要はありません。「Love、暫定 — Xで確認」で十分です。

作業ファイル

何かを作成する前に、まずファイルの保存先を決めます。 ユーザーが既存のファイル（料金ページ、ポジショニング文書、理想顧客の定義など）をすでに指定している場合は、同じディレクトリを使います。そうでない場合は、ファイルの保存先を尋ね、現在のディレクトリをデフォルトとして提案します。./WILLINGNESS-TO-PAY.md を提案してください。

次に、フェーズ 1 で最初の具体的な内容が出たら、実際にファイルをディスクに書き込みます。書き込むと伝えるだけではいけません。 また、各内容がまとまり次第、フェーズの最後ではなくその都度更新します。 ファイルが記憶であり、チャットではありません。長いセッションでは忘れることがあり、コンテキストが圧縮されることもあります。ユーザーが途中で離れたり、再開したり、演習の途中で記録を修正したりできるのは、ディスク上に実際の最新ファイルがある場合だけです。

ファイル内のリストは、履歴として追記するのではなく、その場で編集します。 項目を明確にしたら、その行を書き換えます。バージョンを逐一記録するログは残さないでください。途中までのファイルを、間を空けて再開したセッションでも読みやすく保つために、次の 2 つのルールを守ります。

• 各項目の状態を付けます。 フェーズ 1 のインベントリでは、現状の事実を示すため、各領域に [have]、[partial]、[none]、または [unsure] を付けます。また、まだ確認していない領域には [todo] を付けます。そうすれば、パレットの途中から再開したセッションでも、「まだ尋ねていない」状態と [none] を区別できます。ある領域が特定のセグメントでは当てはまるが、別のセグメントでは当てはまらない場合は [partial] とし、注記で違いを明記します（"[partial] — have for agencies, none for solo freelancers"）。フェーズ 2 の変更リストでは、新たに出てきたアイデアに [raw]、ユーザーと検討したアイデアに [explored] を付けます。再開したセッションは推測せず、これらを直接読めます。
• 特に指示がなければ、「検討したが見送った」項目を短く記録しておきます。 各項目につき 1 行です。記録を残すことで、間を空けて再開したセッションが、ユーザーがすでに却下した項目を再び持ち出して議論し直すのを防ぎます。

構成：

---
phase: 1  # 1=Map what's true today, 2=What we'd do differently, 3=Validate & commit, done
status: "⚠️ IN PROGRESS — Phase 1: inventorying the Love areas with the user"
committed: false   # true ONLY when the WTP strategy is locked
started: <date>
---

# Willingness to Pay — <company / product>

## Current reality (Phase 1)
### Who pays, and the segments
### Why they pay now — first read

## The desire map — what's TRUE TODAY (Phase 1)
### Love — which areas we have           
### Utility — which areas we have         
### Coercion — what is actually operating 
### Parked for Phase 2 
### The fragility test — who leaves the moment a good alternative appears
### First read — where our willingness to pay actually comes from today

## What we'd do differently (Phase 2)   ← a LIVING list, edited in place
### Love — to own or build          
### Utility — to deepen or build     
### Coercion — reliance to drop & replace; honest mechanics to keep
### Considered and set aside


## Validated & committed strategy (Phase 3)
### Love driver(s) we will own
### Utility attribute(s) we will deepen
### Coercion — what we drop, what we keep honestly
### Handoff — what consumes this next (not in this skill)

status 行には、どこで作業が止まったかを正確に記録します。フェーズだけでなく、未解決の具体的な話題や次の項目を記載してください。そうすれば、新しいセッションでもディスク上の情報だけで再開できます。status 行には、現在の進め方も記録します（例：「Phase 1 — inventory, walking Utility areas with the user」または「Phase 2 — judgment LIGHT, awaiting reaction to a community idea」）。ディスク上のほかの情報からは、間を空けて再開したセッションがインベントリ作業中なのか、アイデアを検討中なのか、厳しく評価する段階なのかが分からないためです。評価されていないリストを前に、Phase 3 モードで始めると、このスキルの根本的なルールに反します。Phase 3 の戦略が確定するまで、committed は false のままにします。これは、このスキルが目指す唯一の大きな状態変更を機械可読な形で記録するものです。⚠️ IN PROGRESS の注記は、演習が完了したときにのみ削除してください。

ファイルがすでに存在する場合は、それを読み、どのフェーズにあるかをユーザーに伝えて、そこから再開します。すでに記録されている現状のマップや確定済みの戦略を飛ばして、フェーズ 1 からやり直してはいけません。再開時には、続ける前に現在の進め方を口頭で改めて伝えます（フェーズ 1 ではインベントリ作業、フェーズ 2 では軽い判断）。そうすれば、間を空けて再開したセッションが評価モードに移ってしまうのを防げます。

フェーズ 1 — 現状をマッピングする

目標は、現在誰が支払い、どの欲求が実際に働いているかについて、ユーザー自身が作成した正直なマップを作ることです。あなたが推測するのではなく、全領域を網羅したパレットに沿って、領域ごとに確認していきます。これはインベントリであり、戦略ではありません。現状の事実だけを扱います。このスキルが最も失敗しやすいのは、使い手がひそかに自分で答えを決め、推進要因を 1 つか 2 つ挙げてしまうことです。あなたの役割はその逆です。選択肢の全体を示し、ユーザーから事実を引き出してください。

1a. 現状を把握する

必要なのは2つです。ユーザーが希望する方法で受け取ってください。一括貼り付け、ファイル、価格設定ページやホームページへのリンク、または質問に答える形でもかまいません。ユーザーからURLやファイルを渡されたら、内容を読み込んでください。言い換えではなく、ユーザー自身の言葉をもとに進めます。

1. 誰が支払うのか。 購入する顧客セグメントと、異なる場合は各セグメントが製品をどのように使うか。利益を生んでいるセグメントはどれか。ユーザーが理想の顧客像を定義している場合は、それを取り入れます。そうでなければ、顧客像が曖昧だとマップの精度が下がることを記録してください（「任意の関連スキル」を参照）。
2. なぜ支払うのか — ユーザーの最初の見立て。 各セグメントが、なぜ購入し、使い続けるのかを、ユーザー自身の言葉で確認します。まだ訂正しないでください。

見つけた内容をユーザーに伝え、ファイルに書き込みます。まだ構築する要因を提案せず、まず全体像を把握してください。

1b. ユーザーと一緒に、欲求を領域ごとに洗い出す

これはフェーズ1の核心であり、このスキルが必須とするステップです。それぞれの欲求の種類に含まれる領域をすべて確認し、各領域がユーザーにとって「今」当てはまるかどうかを尋ねます。選択肢は、ある、一部ある、ない、または不明です。3種類を順番に進めます。まずLove（最も価値が高く、最も見落とされがちです）、次にUtility、最後に実際に作用しているCoercionです。

講義ではなく、対話を促す進め方：

• 絞り込まず、全項目をグループ分けして見やすく提示します。 まずLoveの領域をすべて一度に提示し、次にUtilityを提示して、ユーザーが全体像を見渡し、抜けているものに気づけるようにします。推測した2、3項目だけを見せるのは、まさに避けるべき失敗です。価値があるのは、ユーザー自身なら決して挙げなかった領域にも反応してもらうことです。
• 可能なら最初の見立てを作成し、ユーザーに返して修正してもらいます。 すでに知っている情報から、いくつかを事前にマークしてもかまいません（「ウェブサイトを見る限り、DesignとCommunityは ある ようです」など）。ただし、すぐにユーザーに確認します。「これは私の最初の見立てです。何か見落としていますか？ ここにないもので追加すべきものはありますか？ 実際には当てはまらないのに、誇張しているものはありますか？」 大切なのはユーザーの修正であり、こちらの草案ではありません。
• 各領域に [have] / [partial] / [none] / [unsure] を付け、進めながらファイルに書き込みます。 「いえ、うちは違います」という短い返答でも十分です。次に進みます。掘り下げるのは、ユーザーが「ある」または「一部ある」と答えた領域だけです。具体的な根拠を確認してください（「Communityがあるとのことですが、どこにあり、誰が参加し、そこで何をしていますか？」）。裏付けが何もない領域は、「ある」とは言えません。
• 今日の状況に絞ります。 ユーザーが「ミッションはありませんが、作ることはできます」と言ったら、歓迎していったん保留にします。「いいですね。それはフェーズ2で取り組むことです。今は、すでに当てはまるものだけをマークしています。」 すぐにフェーズ2の変更リストに [raw] の行として記録し、「(P1で保留)」とタグ付けしておきます。問いが変わったときに取り上げられるようにしたら、洗い出しを続けます。

ユーザーにすべて読み上げるLoveの領域：

• Mission — 製品を超える大きな変化を支援すること。顧客が実現を望むムーブメント。
• Community — メンバーが所属し、学び、教え合い、互いに助け合う場。
• Reciprocity — 何かを求める前に与えること、または受け取る以上に与えること。
• Transparency — うまくいったことも、恥ずかしいことも含め、浮き沈みを率直に公開すること。
• Design — 使うことが楽しく、チームが技術を磨き上げていることが目に見える製品。
• Quality — 信頼性がもたらす安心と喜び。
• Personality — 顧客が自分のアイデンティティを表現するためにブランドを使うこと。
• Culture — 従業員や取引先を大切に扱う組織を支援すること。
• Ecosystem — 所属することに見返りがあること。メンバーがグループの外にいるよりも、グループ内で多くの収入や地位を得られること。
• Authenticity — 取り繕ったミッションではなく、その真摯さ自体が人を惹きつけること。

ユーザーにすべて読み上げるUtilityの領域：

• Unique — 競合にはない、顧客が必要とする機能です。
• Quality — シームレスで、まったく問題のない体験です。
• Simplicity — 驚くほど簡単であること自体に価値があります。
• Integrations — 顧客がすでに使っているものと連携し、乗り換えコストも高めます。
• Convenience — 避けるためにお金を払う価値があるほど、手間を省きます。
• Training — スタッフが一度トレーニングを受けると、乗り換えにはコストがかかります。
• System-of-record — 重要なデータがここに保存されており、移行にはリスクがあります。
• Risk-reduction — 何かが壊れる可能性を低減します。
• Familiarity — 顧客がすでに知っているパラダイムです。
• Market-leader — 誰も責任を問われない、安心できる選択肢です。
• Onboarding — 導入しやすいほど、支払う意思が高まる傾向があります。
• Location — 顧客が働く場所に、すでに存在しています。
• Cheap — 価格の安さ自体が、購入する理由になります。

（Quality が意図的に両方のパレットにあるのは、Love では「信頼性による安心感」が愛着を生み、Utility では購入者が合理的な判断から対価を払う「完璧な体験」を指すためです。それぞれの場所に印を付けてください。削除すべき重複ではありません。）

次に、実際に働いている Coercion を確認します。これは願望のリストではなく、今日、顧客を本人の意思に反して引き留めているものです。その形態には、契約による拘束、エクスポートさせてもらえないデータ、乗り換えコスト、実質的な独占、価格協定、バンドルへの押し込み、規模が大きくなってからの値上げ、社内規定、法的強制力などがあります。Utility の領域の中には、軽度の Coercion としても機能するものがあります。インテグレーション、トレーニング、そして system-of-record は、いずれも乗り換えコストを高めます。そのため、ユーザーがそれらに [have] と印を付けた場合は、顧客が本当にとどまる理由なのか、罠なのか、あるいはその両方なのかを率直に問いましょう。

1c. 脆弱性テストを実施する

項目を洗い出したら、この手法で最も明確な答えが得られる質問を、顧客基盤全体に問いかけます。「優れた代替製品が明日登場したら、誰がすぐに離れますか？」 離れる人は、何と呼んでいたにせよ、Coercion によって引き留められていました。彼らを特定してください。「契約に縛られている」を「顧客は忠実だ」として扱ってはいけません。これによって、Love における真の [have] と、Utility に乗り換えの縛りを加え、それを装っているだけのものを見分けられます。

今日、実際に何が支払い意思を生み出しているのかを明らかにしましょう。 よくある、認めたくない発見は次のようなものです。「顧客は忠実だと思っていたが、実際には便利な製品と乗り換えコストがあるだけで、この市場向けの Linear が出荷された瞬間に、顧客の3分の1が離れてしまう。」 はっきりと言葉にして、ファイルに書きましょう。この率直な現状こそ、フェーズ2で変えていく対象です。

フェーズ2への移行条件： ユーザーとともにパレット全体を棚卸しし（すべての領域に印を付け、該当するものには根拠を示す）、脆弱性テストに回答し、今日の支払い意思が本当はどこから生じているのかをファイルに記録します。ここで問いは未来へと転じます。私たちは何を変えるべきでしょうか？

フェーズ 2 — 何を違うやり方でするか

目標：どの「変化」を実現したいか、つまり、自社で獲得したいもの、深めたいもの、構築したいものと、手放すべき Coercion を幅広く洗い出します。フェーズ 1 の棚卸しをもとに進めます。ここで問いは「何が真実か」から「何を違うやり方でするか」へと切り替わるため、評価は控えめにします。次のように伝えましょう。 「現状の事実を棚卸ししました。ここから先に進みます。それを踏まえて、何を構築し、深め、手放すべきでしょうか？可能性を挙げていきますが、ここで何かを決定するわけではありません。」 まだ評価はしないでください。今評価すると、出てほしいアイデアがつぶれてしまいます。

変化のリストには 2 つの情報源があり、両方を取り入れます。

• [have] または [partial] を深める。 有力候補は、棚卸しですでに実在すると示された領域であることが多いです。たとえば、投資できる既存の Community や、磨きをかけられる Utility です。すでに存在するため、自社で獲得できる領域です。
• 本物として獲得できる [none] を構築する。 事業として本当に獲得できるのであれば、欠けている領域も候補になります。本物であることが条件です。見せかけのミッションやコミュニティは反発を招くためです（TOMS を模倣した Skechers がそうだったように）。ここで、フェーズ 1 でいったん保留にした「X を追加できる」というメモを再検討します。

アイデアは 1 つずつ進めます。提案し、ユーザーの反応を待ち、新しく出たものには [raw]、一緒に検討したものには [explored] を付けます。棚卸しの具体的な結果を示してください（「Community は partial とマークしていて、実際に人が集まっています。ここは獲得すべき明らかな領域ですね」など）。可能性の一覧をすべて読み返す必要はありません。フェーズ 1 ですでに一通り確認しています。ここでは、そこで明らかになった内容と、本物として構築できるものをもとに進めます。

すべての変化は、顧客が測る価値を基準に表現し、取り除くコストを基準にしないでください。 最大の成果はここに隠れています。同じ機能でも、「コストを削減する」と表現するのと、「売上／リード／商談パイプラインを伸ばす」と表現するのとでは、支払い意欲に何倍もの差が生じることがあります。顧客はコスト削減よりも成長をはるかに重視するためです。そのため、価値を生み出す要因は、顧客自身の成功指標に沿って表現します。「リード単価を下げる」ではなく、「毎月 40,000 ドル相当の追加リードを生み出す」とします。変化を説明するときに行うことであり、独立した手順ではなく、表現上の原則です。（Love の価値を生み出す要因にも当てはまるものがあります。「収益を増やしてくれるコミュニティに参加する」は、「当社のフォーラムに参加する」より魅力的です。）

Cheap に関する注意点が 1 つあります。 棚卸しで Cheap が実際の [have] と示された場合、ここで「Cheap を深める」ことを変化にしないでください。低価格を購入理由として前面に押し出すのは、価格戦略上の選択（「Less for Less」の道筋）であり、このスキルではなく戦略手法で扱うものです。記録して引き継ぎ、この演習を底値競争にしないでください。

頼りにしている Coercion は、資産ではなく変化の対象です。 脆弱性テストで、契約、乗り換えコスト、囲い込まれたデータ、または代替手段の不足によって顧客がとどまっているとわかった箇所では、その代わりに、とどまる理由となる Love または Utility を構築することが、次に進む方向です（T-Mobile の「Un-carrier」への転換では、契約と解約手数料をなくし、忠誠を強制するのではなく獲得することで市場を勝ち取りました）。利益だけを考えた場合の重要性も理解しておきましょう。同一の会社が 2 社あり、一方が Love で顧客をつなぎとめ、もう一方が Coercion で顧客をつなぎとめているなら、Love の会社の方が優れた投資先です。前者は顧客が無料で成長を後押しする一方、後者の顧客は離れる方法を求めるからです。つまり、Coercion に反対する根拠は倫理だけではなく、より賢明な選択でもあります。次の 2 点を記録してください。手放して置き換えることを目指す依存関係と、維持する誠実な仕組みを 2 つほど（顧客にとって有益なセット割引、実質的なメリットを得るために顧客自身が選ぶ年間契約など。顧客が十分に理解したうえで結ぶ正当な仕組みです。これらを道徳的な理由で一律に否定しないでください）。

フェーズ 3 への移行条件： ユーザーが「自分たちが違うやり方ですること」と認識できる提案のリストと、Coercion を手放す／維持する項目のリストがそろっていること。次に進む前に、これから進め方が変わることを伝えてください。

フェーズ 3 — 検証して確定する

目標：フェーズ 2 で提案された変更がすべて実際に裏付けられているかを再確認し、確定する戦略――自分たちが責任を持つ Love ドライバーを 1 つか 2 つ、深める Utility 属性を 1 つか 2 つ、そして Coercion の計画――に絞り込み、確定します。切り替えを宣言します： "では、ここから方針を切り替えます。フェーズ 2 ではあらゆるアイデアを受け入れましたが、ここでは一つひとつに異議を唱え、最終的に採用されないものがほとんどでしょう。それが狙いです。戦略とは、何をしないかを決めることです。"

基準：本当に自分たちのものとして担えますか？

支払い意欲は、あるドライバーを主張することで生まれるのではありません。それを信頼できる形で一貫して体現することで生まれます。したがって、変更を残すかどうかの基準は魅力ではなく、自分たちのものとして担えるかどうかです。すべての Love と Utility の候補に、次の問いを当てはめます。

これは本当に自分たちのものとして担えますか？他の選択肢より優れていて、すでに行っていることとも一貫しており、顧客がそれを実感できるでしょうか？それとも、そうあってほしいと願っているだけでしょうか？

この基準の根底にある 4 つの問い：

1. すでに真実ですか、それとも信頼できる形で実現できますか？ このドライバーをすでに備えている証拠、あるいは実現に向けた具体的な道筋はどこにありますか？「もっと〜に見せられるかもしれない」は退けてください。とりわけ Love ドライバーは本物でなければなりません。演じたものは裏目に出ます。
2. ほかの要素と矛盾していませんか？ このドライバーは製品、価格、その他のシグナルに合っていますか？それとも、それらと衝突していますか？（動作に不具合のある製品で「プレミアムなデザイン」を Love として主張しても一貫性がありません。顧客は矛盾を感じ、何も響きません。）
3. 競合他社が簡単に模倣できないものですか？ 不誠実な模倣は反発を招くため、Love ドライバーは模倣されにくい一方、Utility ドライバーは比較的簡単に追随される可能性があります。模倣が難しいほど、支払い意欲は持続します。
4. 注力する価値がありますか？ 選ぶのは、あれこれ手を出す 10 個ではなく、自分たちのものとして担う 1 つか 2 つです。半分の力でしか取り組まないドライバーは、コミットメントとは言えません。

集中します。 ゴールは、Love ドライバーを1 つか 2 つ、Utility 属性を1 つか 2 つに絞ることです。項目を漫然と並べた長いリストではありません。6 つで少し平均を上回るより、1 つのドライバーを極めるほうが勝ります。必ず選択し、ユーザーにすべてを残させないでください。

問い詰める

Rude Q&A や asb-rude-qa のような悪魔の代弁者スキルがインストールされている場合は、次の概要を渡して実行します："提案された支払い意欲に関する変更を一つずつ厳しく問い詰めてください。それぞれについて、会社が本当にそれを自分たちのものとして担えているのか、それともそうあってほしいと願っているだけなのかを追及します。すでに真実である証拠、または信頼できる実現への道筋はありますか？製品、価格、その他のシグナルと一貫していますか？競合他社に模倣されますか？ほかの選択肢と比べて、集中する価値がありますか？Love に関する主張は特に厳しく問い詰めてください。顧客からの支持がないのに『顧客は私たちを愛している』と思い込むのは、自分に都合よく考える典型的な誤りです。Love ドライバーを 1 つか 2 つ、Utility 属性を 1 つか 2 つに絞り込ませてください。すべてを残させないでください。"

インストールされていない場合は、同じ姿勢で自分で問い詰めます。鋭く具体的に、必要なら不公平なほど厳しい質問をしつつ、協力的な態度を保ちます。人ではなく、主張を攻めてください。逆の立場を考えるテストを使います。主張の逆が明らかにばかげているなら、その主張には意味がありません（「顧客は品質を求めている」――低品質を求める人はいないので、内容がありません）。「場合によります」や「それは後で考えます」は受け入れないでください。

答えが曖昧なら掘り下げ、納得できたら先に進みます。 変更に対して、心から擁護された状態になるか、率直に取り下げられるか、「検討したうえで見送る」に移されるまで、その変更にとどまります。1 つのドライバーを 3 回問い詰めたからといって、安易に認めてよい理由にはなりません。

Coercion の計画を固める

フェーズ 2 の調査結果をもとに、どの強制的な依存をやめるのか（その代わりに築く Love／Utility による継続理由も含めて）、そしてどの誠実な仕組みを維持するのかを確定します。具体的にしてください。「データを人質に取るのをやめ、エクスポート機能を提供して、代わりに Utility で使い続けてもらう」はコミットメントですが、「強制性を弱める」はそうではありません。

戦略を確定する

戦略が固まったら、ユーザーに明確に確認します。これが、このスキルが目指す唯一の大きな状態変化です。所有する Love ドライバー、深める Utility 属性、Coercion の計画を「検証済み・確定済みの戦略」セクションに記入し、committed: true に設定して、phase を done に進め、⚠️ IN PROGRESS の注記を削除します。ドライバーがいくつ残るかは重要ではありません。真に所有できる強力な Love ドライバーが1つあれば、十分に優れた結果です。重要なのは、それぞれが実在し、所有でき、自己矛盾がなく、注力する価値があることです。

次に、引き継ぎを記載します。これはこのスキルの後に行う作業であり、このスキルには含まれません。ユーザーが次に進む先として、所有するドライバーを値上げの根拠にすること（別途行う価格引き上げの検討）、ドライバーをマーケティングコピーにすること（ポジショニング）、または取り除いた Coercion を、本当に使い続ける理由に置き換えること（リテンションとロードマップ）のいずれかを明記します。このファイルはその作業への入力であり、その作業自体ではありません。

拒否と例外条件

• まだ実際の顧客がいない場合。 料金を支払う顧客基盤がないため、Phase 1 の棚卸しは限られ、実際の [have] はほとんどありません。そのことを伝え、軽めに進め、Phase 2 に重点を置きます。ここでは、どの欲求に向けて構築するかが問われます。また、実際の顧客が確認するまでは、あらゆる判断が仮説であることを明示します。次の2つの調整を行います。脆弱性テストを実施できる顧客基盤がないため、無理に実施せず、獲得を目指す顧客についての思考実験として問い、回答が仮説であることを記します。そして Phase 3 の所有基準を、「証拠はどこにあるか」から「実現可能な道筋があるか」へと緩和します。ここでは、どの欲求を構築するかを確定するためです。そのことを率直に伝えます。
• 「いくらにすればいいかだけ教えてください。」 このスキルでは、価格を決めたり引き上げたりしません。欲求を整理して戦略を確定し、推測で金額を提示するのではなく、価格決定を次のタスクとして引き継ぎます。
• 裏付けがないのに「お客様は私たちを愛しています」と言う場合。 これは自己評価を甘くする最もよくある誤りであり、脆弱性テストがある理由です。支持を示す証拠なしに Love という主張を受け入れてはいけません。切り替えコストに支えられた Utility にすぎないのであれば、穏やかに、しかしはっきりそう伝えます。
• ユーザーが精査ではなく承認を求めている場合。 特に Phase 3 では、実際には所有できないドライバーにお墨付きを求めているなら、そのことを指摘し、基準を維持します。このフェーズの価値は、摩擦を生むことにあります。