asb-carol-inciting-events

きっかけとなる出来事：今日、購入を決める理由

見込み客は、製品が自分たちにぴったりだと認め、要となる強みがまさに求めているもので、購入を妨げる要因もなく、価格も妥当だと考えていても、購入しないことがあります。相手の言い分は本当です。「今は導入できません。9か月後にまた連絡してください」。購入を決める権限を持つ人が最優先にしていることは1〜3つあり、あなたの製品はそのどれにも入っていません。あなたを最優先に押し上げるのは、きっかけとなる出来事です。今日こそ買おうと、何の前触れもなく決める人はいません。人生に何かが起き、行動を起こさなければならない苦境に立たされる瞬間があります。このスキルでは、要となる強みごとに、そのような瞬間を整理します。

考え方のモデル

きっかけとなる出来事が購入を決定づける

3つの要素を順番に見ていきます。きっかけとなる出来事が、人々が何かを買う理由です（今すぐ行動せざるを得なくなる苦境）。要となる強みが、あなたから買う理由です（あなたの強みが欠かせなくなる状況）。そして、購入を妨げる要因が対象外となる顧客を切り分けます。要となる強みがあるということは、顧客がその問題を気にかける可能性があるということです。きっかけとなる出来事によって、その問題が、今日解決したい最優先事項の一つに押し上げられます。だからこそ、実際のきっかけとなる出来事はすべて、要となる強みと結びついています。結びつく強みがない出来事は、別の何かを買うきっかけにすぎません。代表的な組み合わせは次のとおりです。速度という強みにつながる出来事は、「SEOコンサルタントに、パフォーマンスの悪さが検索順位を妨げていると言われた」と「サイトの表示が速いほど収益につながるコンバージョンが増えるという調査を見た」でした。スケールという強みにつながる出来事は、「年間で最もアクセスが多い日にサイトが落ちた。もう二度と繰り返したくない」でした。セキュリティという強みにつながる出来事は、「ハッキングされて、本当に恐ろしい思いをした。コンサルタントに1時間300ドルを払ったのに、まだ修復できたかどうかも分からない」でした。サポートという強みにつながる出来事は、「助けを求めて電話したら、『サーバーの電源を入れたままにするのが私たちの仕事です』と言われた」でした。

仮説より観察を優先し、どちらにもラベルを付ける

きっかけとなる出来事を特定する確実な方法は、顧客に、何がきっかけで調べ始めたのか、なぜあなたを選んだのかを尋ねることです。できれば購入直後に、記憶が新しいうちに聞きましょう。そのため、インタビューの証拠（調査結果レポート、インタビューごとの振り返りファイル、オンボーディングアンケートの回答）がある場合は、まずそこから情報を集めます。顧客自身の言葉で語られた実際のきっかけを拾い、出典を添えて観察済みと記します。その後、情報の空白をさかのぼって補い、仮説と記します。これは誠実なラベルです。仮説に基づく出来事は、計画をまとった推測にすぎず、次の顧客との対話で検証すべきだからです。ブレインストーミングで出た案を、証拠のように装ってはいけません。

さかのぼって考えるための視点

仮説を立てるときは、顧客が今日、緊急性と予算を備え、事前承認も得たうえで行動を起こすのは、どのような場合かを考えましょう。次の視点からブレインストーミングします。

• 即座の行動を迫る危機 — 公になった情報漏えいやデータ損失、重要ベンダーの買収や事業停止、主要顧客からの最後通告、訴訟や規制当局による調査、経営陣の交代、広報上の大失態、競合他社の発表によって明らかになる自社の弱点。
• 季節ごと・定期的に訪れるサイクル — 年次計画、会計年度末、納税シーズン、四半期レビュー、コンプライアンス監査、カンファレンスの締め切り、業界の繁忙期が近づくこと。
• 戦略上の好機 — コンプライアンスの期限、必須の認証取得、新市場への参入、買収の完了、IPO準備、レガシーシステムの刷新、新たな資金調達により予算と期待の両方が生まれること。
• 個人の生活の変化（消費者向け製品や個人事業者向け製品の場合） — 親になること、退職、病気の診断、家族の死、結婚や離婚、起業、転職、卒業、初めての家の購入。

見つけやすさによって、ファイルが実用的になります

各イベントについて、次の問いに答えてください。この状況にある見込み客を、どうすれば見つけられるでしょうか？ サイトをハッキングされたばかりの人は、「安全なホスティング」を検索するのではありません。「自分のサイトがハッキングされたかどうかを見分ける方法」を検索したり、「助けて！サイトがハッキングされた！」と誰もいない場所に投稿したりします。見つけやすさを示すシグナルには、公式発表、経営幹部のポッドキャスト出演、製品の発表やプレスツアー、求人情報の変化、レビューやソーシャルメディアに繰り返し寄せられる苦情、アナリストレポート、規制変更の通知、経営陣の交代、資金調達のニュース、そして何より、その状況にある人が検索ボックスに入力する正確なフレーズが含まれます。外部から検知できないイベントも記録する価値はありますが、その点を明記してください。活用できるのはメッセージングのみで（「もし、これが今あなたに起きたのなら……」）、ターゲティングには使えません。イベントは、分割されていることがよくあります。たとえば、執行措置のうち、訴訟に関する部分は公開記録である一方、監査通知に関する部分は見えません。どの部分がターゲティング可能で、どの部分がメッセージング専用なのか注記してください。ユーザーからトリガー（最近の規制変更、資金調達のニュース、季節的なサイクル、競合他社の動きなど）の調査を依頼された場合は、検索ツールで得られる最新の結果を使って確認してください。今年の実際のイベントを見落とし、情報が古くなっている内部知識（トレーニングデータ）に頼ってはいけません。

生々しくなければ、広告になりません

広告では、きっかけとなるイベントが基盤となる価値よりも効果的なことがよくあります。顧客の現在の体験に直接語りかけるからです。顧客は製品の属性を探しているのではなく、自分の状況に反応しています。ただし、それが機能するのは、イベントが生々しく描かれている場合に限ります。具体的な瞬間、感情、数字を示してください。「ウェブサイトをハッキングされるのは、個人的な侵害です。時給300ドルのコンサルタントに相談しても、また攻撃されるのではないかと不安が残ります」は広告になります。「顧客はホスティングサービスに不満を感じる」は広告になりません。「より良い解決策が必要だと気づく」のような一般的なイベントは、どのような形でも記録しません。本当のトリガーには必ず具体的な瞬間があり、それを見つけることがこの作業です。

用語

• きっかけとなるイベント（E1、E2、…） — 基盤との適合性がある顧客を、今すぐ購入するよう動かす具体的なトリガーの瞬間です。該当する[K番号]を示します。
• 観察済み／仮説 — 証拠の状態です。実際の顧客アカウントから収集したもの（出典あり）か、逆算して導き出したもの（要検証）かを示します。認められている補足的な表現は2種類です。実際のアカウントについてユーザーが思い出した内容には「OBSERVED（記憶に基づく）」を使います。これは真正な証拠ですが、出典の裏付けは弱いため、検証時に再確認してください。単一のアカウントに結び付かない、営業電話で繰り返し見られるパターンを組み合わせたものは、HYPOTHESIZEDのままにします。仮説上のイベントには、裏付けとなるもののトリガーではない証拠（「妥当性は支持されるが、証明はされていない。6月のデブリーフで語られた、常に付きまとう不安が裏付けとなる」など）を記載できますが、その場合もSource行は追加しません。
• 見つけやすさ — イベントの状況にある見込み客を、外部からどのように検知または接触できるかを指します。見込み客が使いそうな検索フレーズも含みます。

マッパーの姿勢

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

感心されるためではなく、理解してもらうために書きます。ここで扱うのは難しい概念です。巧みな比喩、言葉遊び、気取った言い回しは、理解を助けるどころか妨げます。言いたいことを平易に述べてください。華やかな表現をなくしたほうが文が明快になるなら、その表現は削ってください。気の利いた言い方でほのめかすのではなく、要点をそのまま伝えてください。

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

番号や文字で示された項目（K4、W2、O17、H3など）に言及するときは、実際に何を指すのか、簡単な説明を添えてください（「K4 — キャリアがサイトにかかっているオーナー」など）。記号だけでは、何時間も、あるいは何日も前に定義を見た人には理解できません。タグは追跡可能性のため、説明は理解のために使います。正確さを保つためにタグを残し、必ず説明を添えてください。

ブレインストーミングの前に収集する

インタビュー資料がある場合（トリガーストーリーを含む調査結果レポート、インタビューごとの振り返りファイル、解約時またはオンボーディング時のアンケートなど）は、まずそれを読み、何かを仮説として立てる前に、トリガーストーリーをすべて候補イベントに取り込みます。取り込んだイベントは、それが後のウォークで扱うキーストーンに属する場合でも、確認された時点で記録します。E番号はキーストーンの順ではなく、確定した順に付けます。ユーザーの記憶も証拠に含めます（「直近の顧客3人は、何がきっかけで調べ始めたと言っていましたか？」）。その場合は「記憶に基づく観察」と明記します。証拠が尽きたところで初めて、レンズを持ち出します。ユーザーにインタビューの証拠がまったくない場合は、このファイルに記載する内容は顧客に尋ねるまですべて仮説であり、尋ねることが検証の道筋であると、はっきり伝えます。

きっかけとなった瞬間を鮮明にする

ユーザーが曖昧なきっかけ（「今使っているツールに嫌気が差したとき」など）を挙げたら、その瞬間を掘り下げます。何が起きて嫌気が差したのですか？ その朝、何がありましたか？ どんな損失がありましたか？ その夜、Google に何と入力しましたか？ さらに厳しく問い詰める方法として、環境に悪魔の代弁者として問い詰めるスキル（たとえば、この手法と同じ作者による Rude Q&A ／ asb-rude-qa）がインストールされている場合は、次の要領で草案に対して使います。これらのきっかけとなるイベントを攻めてください。単なる気分であって具体的な瞬間ではないもの、裏付けとなる実際の顧客の話も、もっともらしい状況もないもの、事実として扱われている「仮説」、そして行動に移せないほど曖昧な見つけやすさに関する記述をすべて見つけてください。願望や曖昧な弁明は受け入れないでください。 そのようなスキルが使えない場合は、自分で目に見える形で問い詰めます。候補への指摘はその場で行い、締めくくりの見直しで一括して検証します。

すべてのイベントをキーストーンに結び付ける

どのキーストーンにも結び付かないイベントは、記録項目ではなく警告です。売っていないものを購入するきっかけなのか、それとも前の手順で見落としたキーストーンを示しているのか、どちらに見えるかを伝えます。実在するキーストーンが抜けているとユーザーが考える場合は、キーストーンのファイルに持ち帰るべき発見であり、孤立したイベントを記録する理由にはなりません。

1回のやり取りにつきキーストーンは1つ

キーストーンを順番に、1回のやり取りにつき1つずつ進めます。1つのキーストーンから、1つまたは複数のイベントが見つかる場合があります。最初は簡潔に、何を読んだか、どのキーストーンに観察されたトリガーの材料がすでにあるかを伝えてから、最初のキーストーンに進みます。求められた場合は手続き的な説明を短くしても、構成は崩しません。

このスキルの使い方

フェーズ A — 取り込み

キーストーンのファイルを読みます（既定では、現在のディレクトリにある KEYSTONES.md。理想的には、購入を断念する要因となる条件を明確にしてあります。変更履歴に見直しの記録がなければ、そのまま進めますが、区分がまだ広すぎる可能性があると伝えます）。顧客の証拠があるか尋ね、提示されたものを読みます。顧客インタビューの調査結果レポート、インタビューごとの振り返りファイル、アンケートのエクスポート、あるいは最近の顧客が何をきっかけに調べ始めたと話していたかについてのユーザーの記憶だけでも構いません。キーストーンのファイルがなければ、対象が不明なままトリガーを対応付けないでください。導入手順を案内し、まずキーストーンの手順を実行するよう提案します（この手法の作者によるキーストーンのスキルがインストールされている場合は、たとえば Keystones ／ asb-carol-keystones のように名前を挙げます）。または、キーストーンを審査しないままではイベントも未審査になるという注意を添えて、チャット内に最小限のキーストーン一覧を作成します。INCITING-EVENTS.md がある場合は、進行中のヘッダーがあれば再開します。ファイルにない内容は、まだ確定されていません。終了したセッションで提案されかけた内容を誰かの記憶から再構成するのではなく、証拠から導き直します。完了している場合は、修正するかどうかを尋ねます。（質問と対応付けられた形式のインタビューごとの振り返りファイルがあること自体が、インタビュープロセスを運用している証拠です。尋ねずに内容を取り込みます。）

出力：同じディレクトリに INCITING-EVENTS.md を作成します。入力が貼り付けられたもので保存先のパスがわからない場合は、何かを作成する前に、この手法のファイルをどこに置くか尋ねます（既定では現在のディレクトリ）。ファイルを黙ってあちこちに作成してはいけません。

Phase B — キーストーンを順に確認する

まずは小さく始めます。読む内容、証拠にすでに観測済みの きっかけとなる出来事が紐づいているキーストーン、そして最初の キーストーンを確認します。キーストーンごとに、次を行います。

1. 証拠から観測済みの出来事を拾い上げる — 顧客自身の言葉と、 出典（「FINAL-REPORT.md F5」／「6月12日のインタビューの 振り返り」／「Meridianの取引に関するユーザーの記憶」）を記録します。
2. レンズを通してギャップを仮説化する — 仮説であることを明記します。
3. 各出来事を具体的に掘り下げる — その瞬間、感情、数値を確認します。
4. 見つけやすさ — その状況にある人をどう検知、または見つけるかを、 想定される検索フレーズも含めて記録します。外部から検知できない場合は、 その旨を明記します。
5. [K番号]、証拠のステータス、見つけやすさとともに記録し、 次のキーストーンに進みます。

作業しながらファイルに記録します。 最初の出来事が確定した時点で INCITING-EVENTS.md を作成し、ヘッダーのポインターを最新の状態に保ちます （「確認済みのキーストーン：K1；現在確認中：K2」）。記憶を保持するのは チャットではなく、このファイルです。

Phase C — 全体を確認して締めくくる

• 関連付けの確認 — すべての出来事にキーストーンが記載されていること、 すべてのキーストーンに少なくとも1つの出来事、または率直なギャップの 記録（「きっかけはまだ不明 — 次の5人の顧客に何がきっかけで始めたか尋ねる」） があることを確認します。
• 証拠の監査 — まとめて確認します（委任でも自分で実施しても構いません）。 仮説上の出来事が事実のように読める記述になっていないこと、観測済みの 出来事に出典が必ずあること、一般論が残っていないことを確認します。
• 検証の進め方 — 仮説上の出来事について、顧客に尋ねる質問 （「何がきっかけで探し始めましたか？」）と、そのタイミング （購入直後など、記憶が新しいうち）を記録します。このメソッドの作成者による 顧客インタビューのプロセス（目標設定スキルは asb-interview-goals）が インストールされている場合は、それを検証を体系的に進める方法として 明記します。インストールされていない場合は、具体的に説明します。 新規顧客全員にオンボーディング時に毎回尋ね、回答を記録し続けます。

最終化して（ヘッダーを削除して）、次のステップへの引き継ぎで締めくくります。 次のステップでは、強み、キーストーン、取引を断念する要因、そしてこれらの 出来事をすべて統合し、理想の顧客像を定義します。このメソッドの作成者による 定義スキル（たとえば Define Carol ／ asb-carol-define）がインストールされて いる場合は、スキル名を明記します。「準備ができたら、これらのファイルを使って asb-carol-define を実行してください。」

ファイル構成

# Inciting events — <company / project name>

> ⚠️ IN PROGRESS — the walk is not complete. Keystones walked:
> <which>; currently on: <K-number>. If you are resuming, continue
> there. (This note is removed at finalization.)

<Two or three lines: which keystones file this maps triggers for
(name it), what customer evidence was available, and the standing
rule — observed events carry sources; hypothesized events are
guesses to validate with customers, not facts.>

## Inciting events

**E1.** <The specific trigger moment, written vividly — what
happened, what it cost, how it felt.>    [K2] — OBSERVED
    Source: <where this story came from.>
    Findability: <how to detect/reach someone in this condition;
    likely search phrases in quotes.>

**E2.** <…>    [K1] — HYPOTHESIZED (validate: ask new customers what
    prompted them to look)
    Findability: <…>

## Gaps

- <K-number> — no trigger known yet; <the question to ask the next
  customers>.

## Next steps

<Two or three sentences of prose: validate the hypothesized events by
asking customers — right after purchase, while fresh — what prompted
them to start looking; then synthesize strengths, keystones,
deal-breakers, and these events into the ideal-customer definition.
That's the final step of the method, and it works from all four
files.>

E番号は、一度記載したら固定です。番号を振り直してはいけません。顧客が 確認したことで出来事のステータスが変わった場合（仮説から観測済みになった場合） も、番号はそのままにして出典を追加します。

対応できない条件

• キーストーンがない。 対象が定まらないままきっかけを洗い出しても、 誰にでもあるつらい一週間を説明するだけです。キーストーンを確認する手順、 または注意事項を付した簡易記録を提案します。
• 証拠を装ったブレインストーミング。 ユーザーが確信していても、仮説上の 出来事からラベルを外してはいけません。実際の顧客の証言が裏付けた時点で 観測済みに変更します。そのために検証の進め方があります。
• いくら主張されても一般的な出来事。 「もっと良いものが必要だと気づいた時」 は、どんな形でも記録しません。真のきっかけの背後には必ず具体的な瞬間があり、 それを掘り下げることがこの作業です。
• 孤立した出来事。 どのキーストーンにも関連付けられていない出来事は、 要注意の印です。対象外であるか、そのファイルに戻って検討する価値のある キーストーンが抜けている可能性があります。いずれの場合も、項目として 記録してはいけません。
• 広告文を書く。 出来事は広告やポジショニングを作るための素材です。 コピーの作成は、その後に行う別の専門作業です。見つけやすさの記録には どこで誰に訴求するかを記載し、言葉を考えるのは後にします。
• 顧客の発言を捏造する。 観測済みとは、出典のある実在の顧客による 実際の証言を意味します。作り物の具体性を加えると、推測に勝るという このファイル唯一の利点が損なわれます。