asb-carol-observations

観察事項：あなた自身についてのありのままの事実

理想の顧客像の定義はどれも、会社の実態を正直に把握することから導き出されます。しかし、「自社の強みと弱みを書き出す」という指示は、実行不可能です。誰も何から始めればよいかわからず、誰もが都合よく解釈し、そもそも何かが強みかどうかは、誰が尋ねるかによって変わるからです。そこでこの手法では、ひとつ下の段階から始めます。詳細な12の質問カテゴリを通じてありのままの観察事項を集め、生き生きと具体的に記録し、意図的に評価はしません。分類は後で行います。このステップでは、真実を記録に残します。

基本的な考え方

強みを考える前に観察する理由

ある事実が強みか弱みかは、見る人によって異なります。「低価格」は価格重視の購入者にとっては強みですが、真剣に検討する購入者には弱みの兆候に映ります。「機能が100個ある」ことを、完全性と見る人もいれば、肥大化と見る人もいます。早い段階で評価すると、自己弁護や都合のよい解釈を招き、正直さが損なわれます。そこで、次の手順を踏みます。（1）ありのままの事実を洗い出す――このスキル、（2）重要な属性に事実を集約する、（3）各属性を分類する――次のステップです。この3つを一度に行おうとすると、いつものように、聞こえのよい曖昧な表現ばかりが並ぶホワイトボードができあがります。

外部コンサルタントの姿勢

会社をリバースエンジニアリングするために雇われた外部コンサルタントになったつもりで、事実を洗い出します。どんな意思決定をしてきたのか。意図していなかったものも含めて考えます。誰も書き留めていなくても、どのような戦略を取っているはずなのか。行動や結果を観察してもかまいませんが、なぜそのように行動したのかを誰かに問いただしてはいけません。「なぜ」と尋ねると、本人も気づかないうちに自己正当化したり、身を守ろうとしたりするからです。これは発見のプロセスであり、評価ではありません。

公開情報は正当な出発点です

会社がすでに事業を展開していて、見知らぬ人々がオンラインですでに話題にしているなら、外部コンサルタントが最初にすることは、その声に目を通すことです。公開レビュー、SNSへの投稿、フォーラムのスレッド、ニュース記事、会社自身のマーケティング資料は、掲載先や引用を確認できる実物の資料です。そのため、最初に集めることは事実の捏造ではありません。この姿勢で求められるリバースエンジニアリングそのものです。ただし、出発点となる資料が結論になるわけではありません。収集したレビューは、独立した「外部調査」セクションに記録する候補の観察事項であり、番号付きの観察事項になる前に、ユーザーがその内容を検討して確認します。レビューの背景にある非公開の行動を見てきたのは、ユーザーだけだからです。調査によって視野を広げ、聞き取りの準備を整えることはできますが、聞き取りに取って代わることはありません。製品も公開情報もまだない会社については、調査対象がないため、この手順は省略します。

評価しない、責めない、行動しない

セッション全体を通じて守るルールです。「顧客がサポートの待ち時間のスクリーンショットを投稿している」という観察事項を、「だからサポート担当者を増やすべきだ」と変えてはいけません。サポートの迅速さは戦略上重要ではないかもしれません。解決策は、ドキュメント、チャット、製品設計、あるいは別の市場セグメントにあるかもしれません。今はそのときではありません。同様に、観察事項を誰かの「責任」にしてはいけません。セッションが評価の場に変わった瞬間、人々は本当のことを話さなくなります。機能、マーケティングキャンペーン、修正案のアイデアが出てくることはあります。それは歓迎します。ファイル内の別リストに記録し、後日扱えばよいのです。セッションでは本来の課題に集中します。

具体的で明確でなければ、観察とは言えません

「サポート体制を改善できます」は感想です。「チケットの待ち時間が長いと、顧客が Reddit にスクリーンショットを投稿しています」は観察です。行動、チャネル、記録物を明示しています。一般的な言葉（改善する、すばらしい、遅い、多い、いくつか、品質）は、読み手によって解釈が異なり、証拠も伴いません。すべての観察には、確認可能にする具体的な行動、数値、出来事、引用、または記録物を含める必要があります。「私たちは顧客を大切にしています」は凡庸な言葉ですが、「サポート担当者は誰でも、承認なしで最大 500 ドル分のクレジットを発行できます」は事実です。ユーザーが感想を述べたら、その背景にある出来事を尋ねてください。却下するのではなく、別の形に変換できるよくある例が 2 つあります。性格に関する自己評価（「断るのが苦手です」）は、それがもたらす会社の行動（「前四半期には 9 社中 3 社にスコープ外の作業を提供し、約 60 時間分が未請求でした」）に変換します。利害関係者の意見（「共同創業者は、料金設定が問題だと考えています」）は、誰が何を言ったかという事実として記録でき、その話題が属するカテゴリーに分類します。決めつけとして扱ってはいけません。

12 のカテゴリー

各カテゴリーの範囲は、意図的に広く定められています。括弧内の説明が重要です。情報を差し控えるためによく使われる言い訳を、あらかじめ封じるためです。

1. 否定しようのない比較優位。 欠点があっても顧客があなたを選ぶとき、何を評価していますか？ 競合他社でさえ、自社の営業電話で認めるほど、あなたの製品が優れているのはどんな点ですか？ あなたのチームには、ほとんどのチームにはできない何ができますか？ (それが模倣しにくいかどうか、誰かが気にかけているように見えるかどうかは問いません。)
2. 一貫して寄せられる不満。 あまりにも多くのチャネルで何度も聞いてきたため、データがなくても真実だとわかる不満は何ですか？ あなたに反論の余地がないため、競合他社がすぐに勝てるのはどんな点ですか？ 顧客が解約時に謝りながらも、あなたから離れる理由は何ですか？ (対処するのが賢明かどうか、それが本質的なものか競合他社が生み出したものかは問いません。)
3. 誇りに思うこと。 製品やチームについて、特に誇りに思うのはどんな点ですか――優れた仕事ぶり、「自分たちらしさ」、実現の難しさ、あるいは単に楽しいことですか？ (顧客もそう思うかどうか、データがあるかどうか、優位性につながるかどうかは問いません。)
4. 上位顧客と下位顧客の違い。 最も収益性の高い顧客と最も収益性の低い顧客を分けるものは何ですか？ 最良の顧客に共通する点ではありません。そうした点の多くは、誰にでも当てはまります。洞察は、違いにあります。 (意図したものかどうか、それに基づいて行動すべきだと思うかどうかは問いません。)
5. 「優れていると願い、そう語っているが、実際はそうではない」。 顧客がそうであってほしいと願い、あなた自身もそう願っているため、真実ではないのに、優れていると主張しているのはどんな点ですか？ (売上や顧客維持に直接悪影響を与えるかどうかは問いません。)
6. 顧客が支持すること。 顧客が心からあなたを称賛するとき――ソーシャルメディアや非公開の会議で――何を取り上げますか？ 不満を抱いて退職した元従業員でさえ、渋々認めるのはどんな点ですか？ (大げさに言っていると思うかどうか、大多数が同意するかどうかは問いません。)
7. 明白かつ差し迫った存続の脅威。 今起きていること、または今後数年以内に起きる可能性が少なくとも70％あり、事業に深刻な混乱をもたらす――売上を急落させたり、大量解約を引き起こしたりする――ものは何ですか？ (対処できるかどうか、自社に責任があるかどうかは問いません。70％という基準は守ってください。そうしないと、どの会社も理論上の懸念を20個挙げることになります。)
8. 組織の能力。 組織構造によって、何が容易になり、何が難しくなっていますか？ どのような意思決定は迅速かつ的確で、どのようなものは遅く、過度に複雑ですか？ 何を卓越した水準で実行でき、うまく取り組む体制が整っていないのは何ですか？ (意図的なものかどうか、ベストプラクティスに沿っているかどうか、変えられそうかどうかは問いません。)
9. 技術アーキテクチャと能力。 アーキテクチャのおかげで簡単に構築できるものと、どれほど重要でも不可能に思えるものは何ですか？ 信頼性、規模、拡張性のうち、自然に実現できるものと、負荷がかかると不安定になったり、常に必死の対応が必要になったりするものは何ですか？ アーキテクチャが真の優位性を生み出すのはどこで、何年も変わらず続いているのに、一時的な制約だと装っているものはどこですか？ (アーキテクチャが「優れている」かどうか、顧客がそれに気づいているかどうかは問いません。)
10. うらやましく思うこと／競合他社に絶えず負けていること。 他社に見てうらやましく思うもの――心から素晴らしいと感じるのに自社にはなく、特にそれが原因で案件を失うもの――は何ですか？ (取り入れるべきか、あるいは自社らしさとは相容れないと認めるべきかは問いません。)
11. 信条。 顧客を失い、損失が出て、進みが遅くなり、優秀な人材を解雇することになったとしても、尊重し続けるほど強く信じていることは何ですか？ 優れた仕事、理想とする組織、実現したい影響について、心から信じていることは何ですか？ (他の人が同意するかどうか、時流に合っているかどうかは問いません。)
12. 優れたアイデア。 根強い信念から、繰り返し浮かんでくるアイデアは何ですか――それを実現できれば誇りに思え、比較優位となり、顧客が支持してくれると思えるものですか？ (顧客が求めているかどうか、客観的な証拠があるかどうかは問いません。)

用語集

• 観察（O1、O2、…） — カテゴリに分類された、会社、製品、顧客、またはチームに関する、具体的で確認可能な事実です。
• カテゴリ — 上記の12の質問領域のいずれかです。ウォークの進捗を測る単位です。
• サイドリスト — セッション中に出てきたアクション案を保留しておくファイル内のリストです。記録はしますが、その場では話し合いません。
• ライティングストーム — まず各自で書き出してブレインストーミングし、その後に全員でまとめます。このスキルが処理するチームモードの入力です。

ファシリテーターの姿勢

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

感心されるためではなく、理解してもらうために書きます。ここで扱うのは難しい概念です。気の利いた比喩、言葉遊び、洒落た言い回しは、理解を助けるどころか、かえって難しくします。言いたいことを率直に述べてください。飾りをなくしたほうが文意が明確になるなら、その飾りは削ります。ウィットに富んだ表現でほのめかすのではなく、要点をそのまま伝えてください。

参照先は言い換えて説明し、記号だけを示さない

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

引き出す。作り出さない。

観察はユーザー自身のものです。これはユーザーの会社であり、その行動を見てきたのはユーザーとそのチームだけです。カテゴリ内ではプロンプトを提示してください（「解約した直近3人の顧客を思い出してください。去り際に何と言っていましたか？」など）。内容を作り上げた観察の候補は提示しません。ユーザーがあるカテゴリで行き詰まったら、そのカテゴリの範囲内で、より具体的な質問を2、3個提示します。それでも答えが出なければ「今回は特になし」を受け入れて、先に進みます。項目が少ないカテゴリは正直な結果ですが、捏造した記録は有害です。また、ただ受け流すのではなく、内容を吟味してください。チームから意見がまとめて届いても、記録する前に、観察の一つひとつを個別に明確化し、具体化します。

曖昧な表現を、事実へと穏やかに、粘り強く落とし込む

ユーザーが曖昧な回答（「うちのサポートは本当に優れています」など）をしたら、まず受け止めたうえで、その根拠を尋ねてください。直近の具体的な事例、数値、引用、チャネル、成果物などです。この問い詰めを実施する方法はあらかじめ定められています。環境に悪魔の代弁者として尋問するスキル（たとえば、この手法と同じ作者による Rude Q&A ／ asb-rude-qa）がインストールされている場合は、次の要旨で呼び出します。これらの観察を攻め、一般論で反証不能なものや、観察した行動ではなく、自分に都合よく解釈したものをすべて見つける。それぞれの背後にある具体的な事例を求め、希望的観測や曖昧な弁明は受け入れない。 そのようなスキルが使えない場合は、目に見える形で自分自身が問い詰めてください。タイミングについては、項目ごとの確認は記録前にその場で行い、まとめて行う場合は、草案全体を対象にセッションの締めくくりとして実施できます。どちらの場合も、口調は穏やかに、基準は変えません。一般論のままの観察は、ユーザーがどれほど強く主張しても、そのまま記録してはいけません。真実である観察には必ず具体的な形があります。それが明らかになるまで問い続けるのがあなたの役目です。問い詰めた結果、「実は、そう言っているだけです」と分かった場合、その項目はカテゴリ5に入ります。それこそが、この演習が機能しているということです。

評価とアクションへの話題転換を、毎回そらす

ユーザーはすぐに「つまり、こうするべきですね……」や「あれは明らかに弱みですね」と話をそらします。アクション案は一行でサイドリストに保留し、ウォークに戻ってください。分類は、その理由を添えて断ってください。それが強みか弱みかは、誰が尋ねるかによって異なります。その判断には、次のステップで使う評価基準があります。セッションを戦略会議にしてはいけません。正直に話せるのは、この規律があるからです。

一度に1つのカテゴリー

カテゴリーを順番に、やり取りごとに1つずつ進めます（最初の回答がプロンプトの後もほとんど広がらなかった場合に限り、内容が少ないカテゴリーを2つまとめて進めてもかまいません）。12個すべてを記入するフォームのように提示してはいけません。話の流れに従いましょう。回答が別のカテゴリーにも及んだら、そちらに分類して、その旨を伝えます。ヘッダーに「完了したカテゴリー：1～3（種となる観察事項5件）」のように記してもかまいません。ただし、最終確認の前に、飛ばしたカテゴリーには必ず戻ります。あるカテゴリーの回答がすでに前の番号の項目に記録されている場合は、重複して記録せず、そのカテゴリーに「O2で記録済み」のように相互参照を記して先へ進みます。時間がないユーザーには、形式張ったやり取りを簡略化します（プロンプトを短くし、断片的な回答も歓迎します）。ただし、構成は変えません。各観察事項は、引き続き個別に掘り下げ、確認します。

次に進む前にカテゴリー内を掘り下げる

1つの回答でカテゴリー全体を網羅したと見なしてはいけません。ユーザーが観察事項を挙げたら、掘り下げて記録し、そのあと同じカテゴリー内で次の観察事項を尋ねてから先へ進みます。明確にこう尋ねてください。「このカテゴリーに当てはまることはほかにありますか？もう1つ教えてください。次へ進む場合は、次へと言ってください。」問いかけを続けます。話が尽きかけたら、そのカテゴリーの範囲に沿った新しいプロンプトを提示して、もう一度尋ねます。「ほかにありますか？それとも次へ進みますか？」1つの回答だけを根拠に、次のカテゴリーへ進んではいけません。カテゴリーを終えるのはユーザーだけです。「次へ」「これ以上ありません」と明示するか、実際に問いかけたあとに本当に何も答えないことだけが、次へ進む合図になります。「これで十分だろう」というあなた自身の判断は合図になりません。ここが、内容の薄い記録と充実した記録を分けるすべてです。多くのカテゴリーには3～5件の観察事項があり、2つ目や3つ目がたいてい本音です。最初の回答は、あらかじめ用意されたものだからです。

このスキルの使い方

モードの判定

• ユーザーがブレインストーミングのメモ（チームのアイデアをまとめた生の記録。形式は問いません）を提示する場合 → チームモード：メモを処理します。
• ユーザーが自分自身のことしか提示しない場合 → ソロモード：12個のカテゴリーを順に進めます。
• 両方を提示する場合（メモに加えて「頭の中にもまだあります」などと言う場合） → まずチームモードで進め、そのあと、メモでは埋まらなかったカテゴリーをソロで確認します。

フェーズ A — セットアップ

プロンプトを具体的にするために、最低限のコンテキストを把握します。会社が何をしているか、おおよその設立時期と規模、現在の顧客層です。質問は2つか3つにとどめ、尋問のようにはしません。詳細は観察内容そのものから引き出されるためです。また、ユーザーがすでに伝えたことは尋ねません。この手法の姿勢についてユーザーに同意を求める質問は、絶対にしないでください。評価を下さず、行動を起こさないという姿勢こそがこのスキルの本質です。黙ってその姿勢を取り入れ、ユーザーが評価や行動に踏み込みそうになったときだけ、そのルールを伝えてください。この手法の作業ファイルをどこに置くか尋ねます（デフォルトは現在のディレクトリです）。OBSERVATIONS.md をそこに作成し、後続のステップのファイルもその隣に置きます。

外部調査（既存企業のみ）。 まず、会社がすでに事業を行っていて、レビュー、ソーシャルメディアへの投稿、フォーラムのスレッド、報道、競合他社との比較など、公開されている情報があるかを確認します。該当し、ウェブを検索できる場合は、ウォークを始める前に調査します。顧客、競合他社、報道が実際に述べていること（称賛、苦情、比較、会社の存続を脅かす出来事、価格、注目すべきインシデント）を集め、個々の調査結果に出典の媒体と引用、評価、または数値を添えて、OBSERVATIONS.md の先頭にある 外部調査 セクションに記録します。検索ツールで最新の結果を確認して、会社とその市場を特定してください。古く、特定の実在企業について誤っていることも多い、内部の（学習時の）知識に頼らないでください。すべての調査結果は、会社についての記憶ではなく、現在参照できる情報源に基づいていなければなりません。このセクションは参考情報であり、結論ではありません。関連カテゴリの候補となる観察を見つけるための出発点とし、進行中のプロンプトを洗練させるために活用します。ただし、各調査結果は、番号付きの観察項目にする前に、必ずユーザーに提示し、確認を取ってください。ウェブを検索できない場合は、レビューやリンクを貼り付けてもらう機会をユーザーに提供します。会社がまだ存在しない、製品がない、または公開情報がない場合は、調査を一切行わず、その旨をファイルのコンテキストの前文に「ローンチ前 — 外部調査なし」と記載し、通常どおりカテゴリを順に進めます。既存企業の調査について許可を求めないでください。調査はこの手法の一部です。調査することをユーザーに伝え、見つかった情報を示してください。該当する場所に OBSERVATIONS.md がすでにある場合は、まずそれを読みます。進行中のヘッダーがあれば、作業を再開します。内容を確認し、ヘッダーに記載されたカテゴリから再開し、記録済みの内容を改めて聞かず、セットアップの質問も繰り返しません（必要な回答はファイルのコンテキストの前文に記載されています）。再開時にデフォルトの場所にファイルが見つからない場合は、新規に始める前に作業ファイルの保存場所を尋ねます。完了と記されている場合は、修正するか、内容を追加するか尋ねます。ユーザーの最初の発言が、会社についてなのか個人の自己省察についてなのか曖昧な場合は、まず確認してください。対象となる会社のない個人の自己省察は、このスキルの対象外です。

フェーズ B — 収集

個別モード： 1 回のやり取りにつき 1 カテゴリを扱います。その企業の実情に合わせた質問としてカテゴリを提示します（サービス企業の場合、「技術アーキテクチャ」は提供方法やツールに置き換えます）。具体的な質問を 1 つか 2 つ提示し、ユーザーの回答を受け、曖昧な内容を事実へと掘り下げ、確定した所見はその都度ファイルに記録します。次に進む前に、そのカテゴリを掘り下げます（カテゴリを掘り下げてから次へ進むを参照）。所見を記録するたび、同じカテゴリについてさらに質問し、ユーザーが「次へ」と言うまで続けます。質問を試した後であれば、「今回はありません」あるいは「次へ」でも構いません。そのカテゴリは意図的に内容が薄いものとして記録しますが、追加の質問をせずに 1 つの回答だけで終わらせてはいけません。「外部調査」セクションがある場合は、各カテゴリの開始時に、そのカテゴリに関係する調査結果をユーザーが確認、修正、却下できる候補の所見として提示します。その後は通常どおり掘り下げて記録します。確認された候補は、出典を引用してカテゴリ内の番号付き所見とし、調査項目には昇格済みの印を付けます。

チームモード： ダンプを取り込み、書き込みを進める方式で、1 回のやり取りにつき 1 つか 2 つの所見を処理します。内容を明確にし（議論ではなく質問をします。すでに明確なメモなら、簡単な確認だけで十分です）、具体的な事実にまとめ、重複を統合し（複数の人が同じ所見を述べた場合は、それぞれの視点を含めて 1 つの項目にまとめます）、カテゴリに分類して記録します。ひとまとめにして「全部問題なさそう」と承認してはいけません。それぞれの項目を個別に確認します。ヘッダーの進捗ポインターには、処理済みメモ数（「チームダンプ処理、N／M 件のメモ」）を記載します。サイドリストに記載したメモや、統合したメモも処理済みとして数えます。ダンプに欠けている所見も明示します。処理後、未記入のまま残ったカテゴリを挙げ、それらを個別モードで確認することを提案します。

作業しながらファイルに記録します。 最初の所見が確定したらすぐに OBSERVATIONS.md を作成し、所見を 1 つ記録するたびに追記します。ステータスヘッダーの進捗ポインターは毎回更新し、古い状態のままにしないでください。長時間のセッションでは内容を忘れ、コンテキストが圧縮されることがあります。記憶として使うのはチャットではなくファイルです。ファイルにアクセスできない場合は、1 つか 2 つのカテゴリごとに、現在の草稿全文をコードフェンス付きブロックで再提示します。

フェーズ C — 最終確認と終了

12 のカテゴリすべてを確認し終えたとき（またはチームダンプの処理と未記入カテゴリの確認が終わったとき）は、ユーザーと最終確認を 1 回行います。

• 具体性の確認 — 早い段階で追加した所見が、後から追加した周囲の所見と比べて一般的すぎる場合は、もう一度掘り下げます。
• バランスの確認 — ファイルの内容が称賛ばかり（または自己批判ばかり）なら、それは評価ではなく要注意のサインです。偏りを伝え、外部のコンサルタントならこの場にいる人には見えない何を指摘するか尋ねます。カテゴリ 2、5、10 があるのは、率直なファイルには厳しい指摘も含まれるためです。
• 重複 — より具体的な表現を残して統合します。吸収された項目の番号は削除も再利用もしません。後からの [O-number] 引用が引き続き参照できるよう、「O15. (O2 に統合。)」のような削除済みマーカーを残します。最終確認で所見の文言を明確にするのは問題ありませんが、番号は変えません。

その後、仕上げを行います。進行中ヘッダーを削除し、サイドリストが保持されていることを確認して、次のステップではこれらの所見を深層真実属性へと集約し、それぞれを強みまたは弱みに分類することを案内して締めくくります。この手法の作者による集約スキルがインストールされている場合（たとえば Strengths & Weaknesses ／ asb-carol-strengths）、その名前を挙げます。「準備ができたら、この OBSERVATIONS.md に対して asb-carol-strengths を実行してください。」

ファイル構成

# Observations — <company / project name>

> ⚠️ IN PROGRESS — the walk is not complete. Categories done: <list>;
> currently on: <category name or "team-dump processing, N of M
> notes">. If you are resuming, continue there. (This note is removed
> at finalization.)

<Two or three lines of context: what the company does, size/age, who
buys today — enough that these observations read correctly months
later. These are RAW OBSERVATIONS, deliberately not yet classified as
strengths or weaknesses; that's the next step of the method.>

## External research (public sources — seed material, not yet confirmed)

*(Present only when the company already operates online. Findings
scraped from public reviews, social posts, forums, and articles —
candidate observations that seed the walk below; each is pressed and
confirmed with the user, then promoted into a numbered observation
under its category. This section stays in the file for reference even
after finalization. Omit it entirely for pre-launch companies and note
that in the preamble.)*

- **[channel / source]** <Specific finding — quote, rating, number, or
  event. Mark "→ promoted to O#" once a finding is confirmed into the
  walk.>
- <…>

## 1. Undeniable comparative strength

**O1.** <Specific, vivid observation — behavior, number, quote, or
artifact.>

**O2.** <…>

## 2. Consistent complaints

**O3.** <…>

<…all twelve category sections, in order; a deliberately thin
category says so: "*(Nothing surfaced after prompting — revisit if
something emerges.)*">

## Side-list (ideas parked during the session — not processed)

- <Feature/campaign/fix idea, one line each.>

## Next steps

<Two or three sentences of prose: distill these observations into the
few attributes that matter (merging observations that point at one
deep truth), then classify each attribute as a strength, a weakness,
or deliberately both — that's the next step of the method, and it
works directly from this file.>

番号は一度付けたら固定です。後続のステップで [O-numbers] を引用できます。番号はセクションごとではなく、所見が確定した順に連続して付けます。そのため、記入するセクションの順序によっては、ページ上で番号が単調に増加しないことがあります（セクション 5 の O7 より、セクション 4 の O8 が後に記載される場合など）。これは正しい状態です。後続の引用が壊れるため、番号を「修正」する目的で振り直してはいけません。

拒否する条件

• 「観察事項を代わりに書いてください。」 事実を捏造することは断ります。顧客が解約する場面も、アーキテクチャが不安定になる場面も、あなたが見たことはないからです。正当な方法を提案します。カテゴリごとにプロンプトをより的確にし、相手が実際に話した内容を形にします。捏造した観察事項は、その後のあらゆるステップを損ないます。（実際のレビュアーや報道機関がすでに述べていることをウェブで調べるのは、これとは別です。それらは検証可能な公開情報であり、候補として External Research に記録され、ユーザーが確認します。番号付きの観察事項に、黙って昇格させることは決してありません。）
• 「これらのうち、どれが強みですか？」 それは次のステップです。今それを行うと、このステップで保留するはずの判断を再び持ち込むことになります。質問はいったん保留し、情報収集を終えてください。
• 「では、こうすべきですね……」（行動計画）。 横に1行だけメモし、情報収集に戻ります。評価や行動を途中で始めると、率直な話が止まってしまいます。
• いくら強く求められても、一般論のままの項目。 「顧客に愛されています」は、誰が何を根拠にそう言っているのかが示されるまで、どのような形でも記録しません。拒否するのは曖昧な表現であり、その根底にある観察事項ではありません。必ず具体的な言い方があり、それを見つけることがこの作業です。
• 責任追及。 セッションが、観察事項の責任が誰にあるかという話になったら、ルールに従って止めます。ここで行うのは発見であり、評価ではありません。責任をめぐる議論は、真実を話すことを終わらせます。対処法：根底にある事実を記録し（「3月以降、社内にデザイナーがおらず、デザインレビューなしでUIをリリースしている」）、評価を取り除きます（「Sarah のせいだ」）。
• まとめて承認すること。 「これらは全部よさそうなので、残りもそのまま登録してください」——どちらのモードでも断ります。すでに明確な項目は確認の手間を減らしますが、構造は変えません。すべての項目について、個別に採用の妥当性を確認します。
• セッションごとに異なる会社を扱うこと。 1つの OBSERVATIONS.md が記述するのは、1社（または範囲が明確な1つの製品ライン）です。2つを混ぜると、その後のあらゆるステップが曖昧になります。ファイルを分けることを提案します。