stress-test

stress-test skillの概要

stress-testの用途

stress-test skillは、Claude型のエグゼクティブ・メンタリングで使う、事業仮説を検証するためのワークフローです。「エンタープライズ顧客は6か月のパイロットを受け入れる」「TAMは€2.3Bある」「12月までに$2M ARRに到達できる」といった戦略上の主張を、資金投下、採用、ロードマップ、投資家向けメッセージに組み込む前に、厳しく検証できるようにします。

計画が未完成であることではなく、魅力的な前提が計画全体を支えすぎていることがリスクである場合に使うのが適しています。

適したユーザーと意思決定

このstress-test skillは、大きな意思決定の前に、より鋭い下振れ分析が必要な創業者、経営陣、プロダクトリーダー、財務チーム、戦略担当者、アドバイザーに向いています。資金調達計画、Go-To-Market戦略、価格変更、市場参入の賭け、リテンション予測、採用拡大、競争優位性の主張、取締役会向けストーリーなどに適しています。

特にstress-test for Strategic Planningとして有用です。楽観に寄りがちな計画上の前提を、反証可能で明示的な主張へ変換し、検証できる形にしてくれます。

何が違うのか

一般的なプロンプトでも、AIに「リスクを見つけて」と依頼することはできます。stress-testのワークフローはもっと絞り込まれています。前提を切り出し、具体化し、反証となる材料を探し、計画がどこで崩れるのかを明らかにします。この焦点が重要です。曖昧な前提は反証しにくいからです。「市場は大きい」では弱い分析しか出ません。一方で、「ドイツのSMEは18か月以内にB2B支出管理ソフトウェアへ年間€Xを支払う」と書けば、モデルが検証できる対象になります。

stress-test skillの使い方

stress-testのインストールとリポジトリの前提

GitHubのskillリポジトリから、利用しているskill managerでインストールします。例:

npx skills add alirezarezvani/claude-skills --skill stress-test

skillの場所は次のとおりです。

c-level-advisor/executive-mentor/skills/stress-test

このリポジトリエントリは自己完結しているように見えます。最初に確認すべき重要なファイルはSKILL.mdです。提供されているツリー上では、補助的なrules/、resources/、references/、スクリプトは見当たりません。そのため、導入判断は主に、埋め込まれている手法が自社の計画策定ワークフローに合うかどうかに左右されます。

skillに渡すべき入力

広いテーマではなく、単一の前提を渡します。

/em:stress-test <assumption>

弱い入力:

/em:stress-test our enterprise strategy

より良い入力:

/em:stress-test enterprise buyers in regulated industries will tolerate a six-month unpaid pilot before procurement approval

強い入力:

/em:stress-test 40% of qualified enterprise prospects in US healthcare will accept a six-month unpaid pilot, and at least 25% of those pilots will convert to $120k ACV contracts within one quarter

強い入力では、セグメント、行動、タイミング、コンバージョン期待、商業上の影響が示されています。そのため、skillは汎用的な戦略リスクを並べるのではなく、それぞれの要素を個別に検証できます。

stress-testの推奨ワークフロー

このstress-testガイドは、意思決定が固まった後ではなく、計画が社内の既定路線になる前に使ってください。

1. 楽観に依存している計画を特定する。収益予測、市場参入、採用モデル、リテンション目標、価格変更、資金調達タイムライン、競争優位性の主張など。
2. もし誤っていた場合に計画へのダメージが最も大きい前提を1つ抜き出す。
3. 顧客セグメント、地域、期間、数量、価格、コンバージョン率、コストなどを含む、測定可能な主張に書き換える。
4. その前提に対して/em:stress-testを実行する。
5. 追加で質問する。「この前提を最短で反証できる証拠は何か？」「どの先行指標を見るべきか？」「この前提が間違っていた場合でも成立する、より低リスクな計画は何か？」

これはエグゼクティブレビューで特に有効です。自信と証拠を切り分けられるからです。

依存する前に読むべきファイル

まずSKILL.mdから確認してください。前提が失敗する理由、stress-testの方法論、前提の切り出し方、反証材料の探し方に関するセクションに注目します。見えている範囲では、このskillには追加のリファレンスパックや自動化がありません。そのため、市場データを取得したり、数値を独自に検証したりすることは期待しないでください。構造化された推論支援として扱い、自社の事実、ベンチマーク、顧客からの証拠、CRMデータ、財務モデル上の前提、投資家からの制約を持ち込む必要があります。

stress-test skill FAQ

stress-testはスタートアップ専用ですか？

いいえ。例は創業者向けに見えますが、このパターンは不確実性の中で賭けを行うあらゆる組織に適用できます。企業の戦略チームであれば、市場拡大、調達に関する前提、営業キャパシティ計画、変革プログラム、プロダクトポートフォリオの意思決定に使えます。必要なのは、検証可能な事業前提に依存している意思決定です。

Claudeにリスクを聞くより何が良いのですか？

通常のリスク洗い出しプロンプトでは、競争、予算、タイミング、実行、採用といった幅広いリストが返ってきがちです。stress-test skillは、計画を支えている重要な前提を明示し、それを直接攻めるよう促します。そのため、分析が意思決定に結びつきやすくなります。「営業は難しいかもしれない」ではなく、「ミッドマーケットの買い手はセキュリティレビューなしで、45日以内に$30k ACVで成約する」という具体的な信念に圧力をかけられます。

このskillを使うべきでない場面は？

市場調査、法務アドバイス、財務監査、顧客発見、統計的予測の代替として使うべきではありません。また、前提ではなくスローガンを入力した場合もうまく機能しません。問いが探索的なもの、たとえば「どんな事業を作るべきか？」であれば、まずディスカバリーや戦略の枠組み作りから始めてください。stress-testは、すでに精査すべき主張があるときに使うものです。

stress-testは初心者にも使いやすいですか？

はい。前提を明確に書けるなら使いやすいです。初心者の場合、まず曖昧な計画を複数の候補前提に分解するところをモデルに手伝わせ、その中で最もリスクの高いものを選んで/em:stress-testにかけると価値を得やすくなります。経験のある実務者は、最初から数値の閾値、既知の証拠、制約、意思決定上の重要性を含めるべきです。

stress-test skillを改善する方法

前提をより反証可能にする

stress-testの出力を改善するうえで最も重要なのは、曖昧さを取り除くことです。誰が、何を、どこで、いつ、どれくらい、どの結果が重要なのかを含めてください。

次のような書き方ではなく:

customers will love the product

次のように書きます:

at least 30% of finance teams at 200-1000 employee SaaS companies will switch from spreadsheets to our forecasting tool within 90 days if priced below $500/month

これにより、skillが検証すべき論点が明確になります。セグメント、緊急性、乗り換え行動、期間、価格です。

証拠と制約を最初から加える

stress-test skillは、既にどのような証拠があるのかを知っているほど、よりよく推論できます。顧客インタビュー、受注・失注メモ、パイプラインデータ、コンバージョン率、チャーンのコホート、営業サイクルの履歴、競合代替、予算サイクル、調達上の摩擦、投資家向けマイルストーンなどを含めてください。

より強いプロンプトには、次のような情報を加えます。

Known evidence: 12 discovery calls, 3 verbal pilots, no signed LOIs, average procurement cycle 4-7 months, current runway 9 months.

これにより、出力がすべての可能性を同じ確率で扱ってしまうのを防げます。

よくある失敗パターンに注意する

主な失敗パターンは、広すぎる、政治的すぎる、または意思決定から離れすぎた前提をstress testしてしまうことです。もう1つよくある問題は、チャレンジではなく承認を求めてしまうことです。有用な出力がほしいなら、「この計画がうまくいくことを証明して」とは書かないでください。「この前提に依存する前に壊して」と書くべきです。

また、多くの前提を1つのコマンドにまとめるのも避けてください。計画が市場規模、支払意欲、営業サイクル、リテンションに依存しているなら、それぞれを別々に検証します。

最初のstress-test後に反復する

最初の出力の後は、意思決定に使える粒度まで磨き込みます。

• “Rank the failure points by probability and severity.”
• “What evidence would change your view fastest?”
• “Design a two-week test for the riskiest assumption.”
• “Rewrite the plan so it still works if this assumption is 50% wrong.”
• “What board or investor question would expose this weakness?”

これにより、stress-testは単発の批評ではなく、実務的な計画ループになります。前提、チャレンジ、証拠、修正、意思決定という流れです。