asb-carol-strengths

強みと弱み：重要な属性

生の観察結果は証拠ですが、戦略には結論が必要です。このスキルでは、企業に関する率直な事実の山を、分類された属性を示す短いチャートにまとめます。将来の理想的な顧客が、あなたを選ぶ理由として評価する強みと、許容するか、敬遠するかに分かれる弱みです。順番に二つの作業を行います。観察結果を、その根底にある少数の深い真実へと凝縮し、次に、ほとんど何でも正反対の主張ができてしまう矛盾を解消する評価基準で、それぞれを分類します。

メンタルモデル

観察結果 → 深い真実

私たちが気づく事実は、たいてい何かより深いものの結果です。「チケットの待ち時間が長いことを示すスクリーンショットを、顧客が Reddit に投稿する」という事実が明らかにする属性は、「テクニカルサポートが遅い」です。「競合他社との比較スクリーンショットを並べて投稿し、顧客が自慢する」という事実が明らかにする属性は、「心をつかむ、際立ったデザイン」です。凝縮する際は、各観察結果（または観察結果のまとまり）について、次の問いを立てます。これは、製品と企業についてどのような深い真実を明らかにしているか。 弱い属性を多数挙げるより、強い属性を少数に絞るほうが有効です。少数のほうが頭に留めやすく、行動に移しやすく、確固たるものにしやすいためです。同じ真実を示す観察結果はまとめ、どこにもつながらない観察結果は取り除きます。

抽象化しすぎる落とし穴と反対テスト

凝縮で致命的な失敗につながるのは、属性を一般化しすぎてありきたりなものにしてしまうことです。「私たちはお客様を大切にしています」はあまりに一般的で、ほぼすべての企業が（たとえ実際にはそうでなくても）口にします。実行可能な内容ではなく、理想的な顧客とそれ以外を分ける優位性を生み出すこともありません。真実が「期待を超える対応をする」ことなら、その属性では仕組みを明記します。「承認を得なくても、すべての従業員が顧客の問題解決に最大 2,000 ドルまで使える」。真実が顧客との真摯な関係なら、「すべてのアカウントに四半期ごとのビジネスレビューを実施し、サポート窓口では知識のある人間だけが対応する」です。

判断の基準となるのが反対テストです。主張の反対を作り出し、成功している企業がそれを合理的に選ぶことがあるかを考えます。「使いやすい」は不合格です。誰も「使いにくい」とは言いません。「料金体系が透明でシンプル」は合格です。エンタープライズソフトウェアでは、料金を問い合わせる方式が誇りをもって採用されており、主要なクラウドサービスは、料金管理を専門とする企業が存在するほど複雑な価格設定で成功しているからです。反対テストに不合格の属性は、どれほどユーザーが好意的に感じていても、どのような形でも記録しません。真の属性には必ず具体的な表現があり、それを見つけることが作業の本質です。（原文にある例外がひとつ認められています。反対の主張が誰にも口にされない属性でも、その分野で大差をつけて優位に立っているなら、合格することがあります。「測定した結果、競合より 4 倍速い」は、誰も「遅い」とは主張しないとしても、実際の属性です。優位性は、具体的かつ大きなものでなければならず、単なる印象ではいけません。）

弱みを示す属性、つまり何かの欠如や不足に対しては、反対向きにテストします。その要素を備えることは、誰かが誇りをもって追求する本物の戦略なのか。「スケジューリングモジュールがない」は合格です。ベストオブブリードのベンダーは意図的にバンドルを避け、バンドルを提供する企業はその方針を誇りにしているからです。この欠如は実際の立ち位置であり、埋め草ではありません。「ウェブサイトに誤字がある」は不合格です。誤字を目指して戦略を立てる人はいないため、属性ではなく欠陥の記録です。

分類基準

ある特性が強みか弱みかは、見る人によってまったく異なります。「安価」は価格を重視する購入者を引きつける一方、本格的な購入者を遠ざけます。そのため、次の2つの具体的な質問で判断します。

1. 強み — 次のいずれかに当てはまりますか？ a. 市場の3分の1を超える人が、これを強みと見なしています。 b. これをとても気に入っている、または必要としている顧客がいて、これだけを理由に購入します。
2. 弱み — 次のいずれかに当てはまりますか？ a. 市場の3分の1を超える人が、これを弱みと見なしています。 b. 一部の顧客にとって、これがあると製品を使うことが不可能になり、これだけを理由に購入を拒みます。

通常、該当するのはどちらか一方だけです。非常に高速なインターフェースは強み（1a）であり、弱みと呼ぶ人はいません。セキュリティ認証がないことは弱み（2b）ですが、市場の大多数は気にしません。ただし、同じくらい重要な結果があと2つあります。

• 両方に「はい」 → その特性は両方に該当し、両方の列に記載してフラグを付けます。市場セグメントによって意見が異なるため、明確な戦略上の選択が待っています（「機能が100個ある」ことを、ある人は充実と捉え、別の人は過剰と捉えます。いずれは誰を満足させるか選ばなければなりません）。これは解決すべき問題ではなく、見つけることが最も有益な特性です。
• 両方に「いいえ」 → 誰も気にしていません。その特性は削除し、理由を1行添えて削除リストに記録します。これにより、関心を持つ人がいない事柄に注意を向けずに済みます。

願望は特性ではありません

観察事項ファイルには、実態が伴わない自己評価が記載されていることがあります（停止の記録があるのに信頼性を主張する、「シームレスな連携」が実際には夜間に実行されるCSVジョブである、など）。これらは主張ではなく、記録に基づいて分類します。通常、根底にある事実は弱みの候補であり（「連携の幅広さをうたっているが、実際は浅い」）、強みではありません。願望そのものは、後で戦略の材料になるかもしれませんが、現在のあなたを構成する特性ではありません。

用語

• 特性 — 会社または製品についての、凝縮された深い真実を1つ表すものです。反対テストに合格できるほど具体的な表現にします。
• S1、S2、…／W1、W2、… — 分類された特性です。両方に該当する特性には、各列で番号を付け、相互に参照します。
• 両方 — 分類基準の2つの質問がどちらも「はい」であり、保留中の戦略上の選択としてフラグが付けられている状態です。
• 削除 — どちらの質問も「いいえ」であり、理由を記録したうえで削除されるものです。
• [O-番号] — その特性を導き出した観察事項です。すべての特性に、根拠となる情報を記載します。

分類担当者の姿勢

気の利いた表現ではなく、明快さを優先する

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

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

番号や文字を付けた項目（K4、W2、O17、H3など）に触れるときは、その内容を平易な言葉で補足します（「K4 — このサイトにキャリアを懸けているオーナー」など）。記号だけでは、定義を数時間または数日前に見た人間には意味が分かりません。タグは追跡可能性のため、補足は理解のためにあります。正確さを保つためにタグを残し、必ず補足を付けてください。

根拠から提案し、ユーザーが訂正する

情報収集（内容を作り出すとファイルが汚染される作業）とは異なり、抽出はすでに記録された根拠を分析する作業です。そのため、ここでは自由に提案できます。観察事項を読み、まとめ、[O-番号]の引用と提案する表現を添えて、特性の候補を1つずつ提示してください。ただし、候補を訂正して確定するのはユーザーです。根拠のどの読み方が正しいかを知っているのはユーザーだからです。まとめて一括で了承してもらうのではなく、特性は1つずつ、その価値を確認します。観察事項が2通りの異なる抽出を裏付けている場合は、両方を示してユーザーに選んでもらいます。

逆のテストは交渉の余地がありません

どれほどユーザーが「でも事実だから」と主張しても、ありきたりな属性をファイルに入れてはいけません。それは基準ではありません。基準となるのは、際立っていることです。自分の候補も含め、すべての候補に対して、このテストを目に見える形で実施してください。さらに厳しく問い詰めるための方法があらかじめ用意されています。環境に悪魔の代弁者として問い詰めるスキル（たとえば、この手法と同じ作者による Rude Q&A / asb-rude-qa）がインストールされている場合は、次の依頼文を添えて、属性リストの草稿に対して実行してください。これらの属性を攻めてください。成功している企業ならどこも逆のことを主張しない属性、理想の顧客とそれ以外を区別できないほどありきたりな属性、実績を説明するのではなく願望におもねる属性をすべて見つけてください。曖昧な弁明や希望的観測による弁明は受け入れないでください。 そのようなスキルが使えない場合は、自分でその問い詰めを行い、目に見える形で示してください。タイミングとしては、候補ごとのテストは、何かを記録する前にその場で行います。委任して行う（または自分で行う）一括の厳しい検証は、フェーズCでチャート全体を再検討するときに行います。拒否するのは常にありきたりな言い回しであって、その根底にある事実ではありません。合格するまで、より鋭い書き換え案を出し続けてください。

分類は、ルーブリックに照らしてユーザーが判断します

ルーブリック、証拠、候補となる回答を提示するのはあなたです。市場に関する判断（「市場の3分の1がそのように見るだろうか？」「これだけを理由に購入した人はいるだろうか？」）を下すのはユーザーです。観察事実そのものがルーブリックの問いに答えている場合（解約メールは「これだけを理由に購入を拒否するか」の証拠です）は、その事実を引用してください。ユーザーの判断が自身の証拠ファイルと矛盾する場合は、一度だけ説明を求めてください（「O5には、この理由で2人の顧客が解約したとあります。それなのに、これを理由に購入を拒否する人はいないと言うのですか？」）。そのうえで、ユーザーの判断を記録してください。ただし、例外が一つあります。作成上のルールは、ユーザーへの追従より優先されます。どれほど弁明した後にユーザーが主張しても、願望を実績に反する強みとして分類してはいけません。ありきたりな言い回しを採用してはいけません。「両方」を一つの列にまとめてはいけません。これらが、後続の工程で意味のあるチャートにするための関門です。議論を避けるために、属性を未分類のままにしてはいけません。

1回のやり取りにつき属性は1つ

属性を提案し、根拠を示し、テストし、分類し、記録してから、次の属性に進んでください。候補となる属性を一度に大量に並べてはいけません。最初のやり取りは簡潔にします。何を読んだか、属性のクラスターがおよそいくつ見つかったかを伝えたうえで、最初の候補を提示します。ユーザーから進行を速めるよう求められた場合は、手順を崩さず、形式的な部分を簡略化してください（表示を短くする、明らかなものは確認を一言で済ませるなど）。

後の工程で見つかったことは保留し、ここでは解決しないでください

情報を絞り込むと、後の工程で扱うべき事柄が見つかることがあります。たとえば、絶対的な弱点で、それ自体が取引を断念させる要因に見えるもの、明らかに購入を促すきっかけとなるもの、要石を検討する際に覚えておく価値のある市場セグメントなどです。これらを追究してはいけません。この工程では属性を分類するのであって、購入を断念させる要因や購入を促す出来事、要石を扱うのではありません。ここで解決しようとすると、チャートが曖昧になります。ただし、見つけたことを失くしてもいけません。それぞれを専用の 後続工程向けメモ セクションに記録し、どの工程に向けたものかをタグ付けして、1行でまとめてください。強み／弱みの属性とは厳密に分け、チャートを整理した状態に保つと同時に、発見事項を後の工程に引き継げるようにします。ユーザーがそうした事柄を持ち出したら、認識したうえでそこに保留し、いま扱っている属性に戻ってください（これは戦略メモの考え方とは異なります。戦略メモは「今日」の真実ではあっても顧客に伝えるものではない事実を扱いますが、こちらは手法の「将来の」工程に向けた発見事項です）。

このスキルの使い方

フェーズ A — 取り込み

観察事項を読みます（デフォルトは現在のディレクトリにある OBSERVATIONS.md。または貼り付けられた内容）。コンテキストの前置きには会社の背景が記されているため、注意してください。また、サイドリストには手を加えません。観察事項がまったくない場合は、何もないところから抽出しないでください。正直な導入手順を提案します。この手法の作成者による観察事項収集スキル（たとえば Observations / asb-carol-observations）がインストールされている場合は、まず収集ステップを実行するか、同じ具体性の基準を保ちながら、今すぐチャット内で簡単に収集するかのいずれかです。ただし、材料が少なければ図表も薄くなることを伝えます。簡単に収集する場合は、最も重要な点をカバーする次の3つの質問を使います。顧客が実際に称賛していること（引用または出来事）、弁明の余地がない苦情、そして最良の顧客と最悪の顧客を分けるものです。集めた内容には、まとまったものから O1、O2、…と番号を付け、後の本格的な収集で最初からやり直さずに追記できるよう、OBSERVATIONS.md への書き込みを提案します。また、材料がチャットから得られたことを図表の前置きに記します。フェーズ C の分量に関する指針は、材料が少ない場合には適用しません。観察事項が6件しかない中で強みが2つというのは、少なすぎるのではなく、正直な結果です。対象の場所に STRENGTHS-WEAKNESSES.md がすでにある場合は、読み込みます。作業中を示すヘッダーがあれば、そこから再開します。すでに確定した属性を再検討せず、記載された箇所から続けます。完了と記されている場合は、修正するか置き換えるかを尋ねます。

出力先：入力ファイルと同じディレクトリにある STRENGTHS-WEAKNESSES.md。入力が貼り付けられた内容で、パスが不明な場合は、作成を始める前に、この手法のファイルをどこに置くかを尋ねます（デフォルトは現在のディレクトリ）。ファイルを黙ってあちこちに作成してはいけません。

フェーズ B — 属性を1つずつ抽出して分類する

まずは簡潔に始めます。読んだ内容（観察事項の数、特に重要な根拠となるものがあるか）、見つかった属性クラスターの数、そして最初の候補を示します。次に、属性ごとに以下の手順を繰り返します。

1. 提案 — 属性を、それを裏付ける [O番号] と具体的な表現とともに提示します。根拠から2通りの解釈が成り立つ場合は、両方を示します。
2. 反対テスト — 目に見える形で行います。テストに通らない場合は、通るか、ユーザーが凡庸な内容だと同意するまで、仕組みに即した表現に言い換えます。
3. 分類 — 判定基準に沿って行います。2つの質問と4つすべてのサブ基準を含めます。ユーザーは市場に関する知識から回答し、あなたは観察事項がすでに答えを示している箇所を引用します。両方に当てはまる場合は、両方の列に記載してフラグを立てます。どちらにも当てはまらない場合は、削除リストに入れます。
4. 記録 — ファイルに記録して次に進みます。

すべての観察事項は、いずれかの属性で引用するか、意図的に色合いとして残す（「補足的な詳細であり、それ自体が属性ではない」）か、削除する理由の中で明記する必要があります。完了前に、どこにも使われていないものがないか確認してください。無理に逆方向へ進めてはいけません。属性には少なくとも1つの観察事項による裏付けが必要です。根拠のない属性は願望にすぎず、収集ステップに戻すべきものです。

進めながらファイルに記録します。 最初の属性が確定した時点で STRENGTHS-WEAKNESSES.md を作成し、その後は属性ごとに追記して、ヘッダーのポインターを最新の状態に保ちます。記憶の役割を担うのはチャットではなくファイルです。ファイルにアクセスできない場合は、属性を1つか2つ進めるごとに、草案全体をコードフェンスで囲んで再掲します。

フェーズ C — 見直して締めくくる

• 網羅性 — すべての観察事項に対応している（根拠を引用する、色分けする、または削除する）。根拠のない属性はありません。
• 分量 — チャートは短くまとめます。有効な目安は、強みが4〜8件程度、弱みも同程度です。膨らみすぎた場合は、さらにまとめて、数を減らし、一つひとつを強くしてください。
• 反対テストの再実施 — 初期の項目は、後の項目と並べると一般論に見えることがあります。もう一度、厳しく検証してください。
• 両方のフラグ — 内容を読み返してください。それぞれが、後続ステップで迫られる戦略的な選択を示している必要があります。意見が分かれているセグメントを、それぞれ明記してください。
• 後続ステップ用の保留事項 — 後のステップに関係する内容が出てきたら、ステップ番号を付けて後続ステップ用のメモに記載し、属性の列には決して入れないでください。

仕上げ：進行中のヘッダーを削除し、引き継ぎの言葉で締めくくります。次のステップでは、強みをキーストーン、つまり特定の顧客が強みの極端な形を必要とする特徴へと精緻化し、そうした顧客を代表する市場セグメントを特定します。この手法の作者によるキーストーン用スキル（たとえばKeystones／asb-carol-keystones）がインストールされている場合は、その名前も挙げてください。「準備ができたら、このファイルに対してasb-carol-keystonesを実行してください。」

ファイル構造

# Strengths & Weaknesses — <company / project name>

> ⚠️ IN PROGRESS — distillation is not complete. Attributes settled:
> <count>; observations processed: <which>; currently on: <the
> cluster being worked>. If you are resuming, continue there. (This
> note is removed at finalization.)

<Two or three lines: which observations file this distills (name it),
and the company context carried over from its preamble. Attributes
are classified with the two-question rubric; a both-classified
attribute appears in both columns, cross-referenced.>

<One line: the best-vs-worst customer differential, carried over from
the observations' head/tail category — or "no differential recorded."
Later steps (keystones, the final definition) mine it, and it must
travel with this chart even when the chart is pasted without its
observations file.>

## Strengths

**S1.** <Specific attribute wording.>    [O1, O11]
    Rubric: <which criterion made it a strength — e.g. "1b: two
    referral customers named this as the reason they signed">.

**S2.** <…>    [O5]

## Weaknesses

**W1.** <Specific attribute wording.>    [O4, O5]
    Rubric: <which criterion — e.g. "2b: both recent cancellations
    cited it">.

**W2.** <= S4; deliberately both — segments disagree: <who reads it
    which way>. A strategic choice is pending here.>    [O9]

## Cuts (nobody cares — attention stops here)

- <Attribute candidate> — no to both rubric questions: <one line of
  reasoning>.    [O13]

## Notes for downstream steps (parked, not attributes)

<Findings that surfaced during distillation but belong to a LATER step
of the method — recorded so they aren't lost, kept out of the attribute
columns so the chart stays clean. Each line tags the step it's for.>

- <finding> — for <keystones / deal-breakers / inciting-events /
  definition>: <one line of what was noticed and why it's parked here>.

## Next steps

<Two or three sentences of prose: refine each strength into the
keystones — the characteristics, behaviors, or circumstances that
make a customer NEED an extreme version of it — and name the
real-world market segments that typify each; then do the mirror work
on weaknesses (deal-breakers and the anti-market). That's the next
step of the method, and it works directly from this file.>

S番号とW番号は、一度記載したら変更しません。後続のステップで参照するためです。両方の属性は各列に1つずつ番号を持ち、相互参照を明記します。確定後の件数と分量の集計では、属性1つとして数えます。各列では、その列の解釈を裏付ける根拠を引用し（フラグには根拠一式を記載）、両方の側に評価基準を記載します。番号は振り直さないでください。統合または言い換えた項目も、元の番号を維持します。ユーザーが事前に許可しており、各項目の理由が本当に一行で済む場合は、削除項目を一度のやり取りでまとめて処理できます。

拒否条件

• 観察事項がない。 記憶や感覚をもとにまとめると、この手法が防ごうとしている、もっともらしいが一般的なチャートになります。まず情報収集のステップ、または簡潔で率直な記録から始めるよう提案してください。
• 一般的な属性を強く求められても受け入れない。 「優れたカスタマーサービス」は、競合他社が合理的な理由で持ち得ない仕組みを明示するまで、ファイルに加えません。表現は断り、真実は保ったうえで、言い換えを提案してください。
• 願望を強みとして扱う。 記録が主張と矛盾する場合（障害が発生しているのに「信頼性が高い」とするなど）、属性の分類は記録に従います。願望は強みとして記録せず、願望として記載します。
• 「評価基準は省略してください。自社の強みはわかっています。」 評価基準があることで、チャートは後続のステップにとって意味を持ちます。誰も単独では対価を払わず、あなたしか信じていないような強みこそ、評価基準で捉えるべきものです。実施してください。属性ごとに一度のやり取りで済みます。
• 整理のために、両方の属性を一方の列にまとめる。 「両方」は調査結果であり、戦略的な選択を示します。両方として記録し、フラグを付けてください。選択はここで既定の方針に従って決めるのではなく、後続のステップで十分に理解したうえで行います。
• キーストーン、取引の決め手、または戦略。 誰がこれらの強みを必要とするのか、誰がこれらの弱みのために除外されるのか、あるいはこれらにどう対処すべきかを導き出すのは、後続ステップの役割です。ここでの成果物はチャートです。