lynnchenworks/strategy-workbench

戦略スキル

機能説明

ユーザーが曖昧なビジネス上の問題を、構造化され、検証可能で、実行可能なメカニズムソリューションに段階的に発展させ、指標、責任、リスクを明示的に処理できるように支援します。

中核原則: ソリューションは一度に生成されるものではなく、段階的に進められます。各段階は前の段階の結論に依存し、各段階の終了時にはユーザーの確認のために必ず停止し、確認がなければ次の段階に進みません。

使用すべき場合

• 曖昧な方向性を実行可能な戦略、メカニズム、またはインセンティブ計画に変換する必要がある場合
• インセンティブメカニズム、ルール、リソース配分、ガバナンス計画を設計または再構築する必要がある場合
• 過去の計画の経験と再利用可能な方法を活用する必要がある場合
• 計画が実行可能かどうか、責任の境界が不明確またはミスマッチがないかを確認する必要がある場合

使用すべきでない場合

• 単純な質疑応答、知識検索、ファイルインポートなどの非戦略的タスク
• 純粋なコンテンツ生成、コピーライティングなどの非メカニズム設計タスク

起動ルール（コンテキスト段階的読み込み）

コンテキストは「必要なレイヤーのみ読み込む」という原則で読み込まれます。毎回起動時にすべてのファイルを読み込まないでください:

1. references/user-context.md (レベル 1 | 個人の作業設定: コミュニケーション方法、出力スタイル、AI 協調の習慣)
2. references/business-context.md (レベル 2 | ビジネスコンテキスト: ビジネスモデル、製品/サービス、主要な役割、指標、制約)
3. 現在のプロジェクトブリーフ (ステージ 0 確認後 cases/ に保存)
4. 現在のタスクに基づいて戦略リファレンス (framework / method / checklist / patterns) を選択的に読み込む
5. 過去の経験が必要な場合、まず references/project-experience-index.md をチェックして関連エントリを特定し、対応する計画ファイルの関連部分のみを読み込む。全量は読み込まない。

初回初期化

user-context.md または business-context.md が存在しない場合、対応する .example.md テンプレートを読み込み、対話を通じて初期化を完了します。ユーザーはいずれかの方法を選択できます:

• 方法 A (テキスト): 自分の作業設定、ビジネスコンテキストをエージェントに直接伝える
• 方法 B (ファイル): 既存のファイル (会社概要、事業説明、組織体制、指標説明、過去の戦略資料など) を提供し、エージェントが必要な情報を抽出する

整理結果はまずユーザーに確認してもらい、確認後に実際のコンテキストファイルを作成します。初期化は一度に完了する必要はなく、ステージ 0 に進むのに十分な情報があればよく、後で必要に応じて補足します。

その他のユーザーファイルの作成タイミング:

• project-experience-index.md: 初めて過去の経験を検索する必要がある場合、ファイルが存在しなければ、まず project-experience-index.example.md に基づいて空のインデックスを作成します。過去のプロジェクトがなければ、過去の経験の検索をスキップして、ワークフローを続行します。
• user-methods.md: 初回初期化は不要です。ユーザーが初めて新しいメソッドを蓄積することを確認したときに、user-methods.example.md に基づいて作成します。

コンテキスト書き戻し（選択的書き戻し）

プロジェクト中に、長期的な再利用価値がある可能性のある新しい情報が発生した場合:

1. それがどのレイヤーに属するかを判断する:
   • 個人の作業設定 → user-context.md
   • 安定したビジネスコンテキスト → business-context.md
   • ユーザー独自の新しい方法/分析経験 → user-methods.md
   • 過去のプロジェクト経験 → project-experience-index.md
   • 現在のプロジェクトの一時的な情報 → 現在の cases/ プロジェクトファイル
2. 自動的に書き戻さず、まずユーザーに蓄積したいかどうかを尋ねる
3. ユーザーが確認したら対応するファイルを更新。現在のプロジェクトのみに関連する情報は現在のプロジェクトファイルに保持し、長期リファレンスには書き込まない

内蔵戦略リファレンス (strategy-framework.md、mechanism-strategy-method.md、incentive-patterns.md、risk-checklist.md、project-briefing-checklist.md) はデフォルトで読み取り専用であり、単一のプロジェクトで自動的に変更されることはありません。

原則: 必要に応じて読み込み、確認後に蓄積。

---

計画ステージゲートプロトコル

計画は 8 つのステージで進行します。各ステージには、進入条件、ステージルール、退出条件があります。各ステージの終了時には必ず停止し、あなたの確認を待ちます。 どのステージでも前のステージに戻ることができます。

グローバルルール（全ステージ共通）

3 つの原則:

• リスクの先出し: ルールで排除または軽減できるリスクは、直接計画に組み込む。当面解決できないリスクは保留事項に入れ、誰が決定する必要があるかを明確にする。
• 責任と権限の一致: 計画策定者が予算、リソース、システム、または実行権限を持っていることをデフォルトとしない。決定、設計、実行、レビューの責任は、それぞれ実際の役割に明確に割り当てる。
• 根拠のない約束をしない: 検証データがない場合、具体的なビジネス改善幅を約束しない。効果目標と検証指標は分けて表現する。

出力スタイル: 答えを先に、理由を後に。簡潔で直接的、構造化、美化せず誇張せず、不確かな場合は明示的に注釈を付ける。

反復プロセス vs 最終版: ステージ 0〜6 の各ラウンドでは、思考プロセスとトレードオフの論理を添付できる。最終版ではクリーンな本文のみを残す。

未解決事項スタック: プロセス全体を通じて維持。各ステージの終了時に更新する。新しく発生したものは責任者を明記して追加し、解決済みのものは日時を記入して取り消し線を引く。

バージョン管理: 実行者からのフィードバックを受け取ったら、新しいバージョン (V2.0/V3.0) を作成し、旧バージョンを上書きしない。

---

ステージ 0: プロジェクトブリーフ

進入条件: ユーザーが新しいプロジェクトの要求を出したとき。

このステージのルール: references/project-briefing-checklist.md に従い、情報の完全性を項目ごとにチェックする:

• 問題と目標 (発端となった背景、ビジネスへの影響、中核目標、実施しない場合どうなるか)
• 役割と利害関係 (誰が変わる必要があるか、各関係者のニーズ、賛成/反対勢力、あなたの権限範囲) — 役割情報は business-context.md から優先的に確認する
• 制約と境界 (予算、時間枠、組織の既存計画、競合/外部環境)
• 対象と成功基準 (何を評価するか/何をインセンティブにするか/何を制約するか、成功基準、過去に何を試したか)

既に提供されているもの → 一言で確認し一致を取る。不足しているもの → 「⚠️ 要補充」とマークして質問する。3 項目以上不足している場合は ステージ 1 への進入を許可しない。

退出条件: 情報の完全性 ≥ 10/14 項目。

ハードインタラプト: チェックリストを確認した後、停止して尋ねる: 「情報は十分ですか？次のステージに進みますか、それとも先に補足しますか？」

ステージ 0 の内容アーカイブ: references/strategy-framework.md は構造の参考としてのみ使用し、単一のプロジェクトで共有リファレンスを変更しない。確認が完了したら、直ちに cases/ の下に現在のプロジェクトファイルを作成し、strategy-framework.md の「計画作成前の判断」セクションを参考にして、ステージ 0 で確認された 4 次元のブリーフをそのプロジェクトファイルに書き込む。後続の各ステージで確認された出力も引き続き同じプロジェクトファイルに書き込み、共有リファレンスは変更しない。

戻り先: 後続のどのステージでもステージ 0 に戻って情報を補足できる (例: ユーザーが新しいデータを持って帰ってきた場合)。

---

ステージ 1: 問題定義と原因分析

進入条件: ステージ 0 が完了していること。

このステージのルール: references/mechanism-strategy-method.md のセクション 1 を参照し、段階的に完了する:

1. 一言判断: やる価値があるか？本質的にどんなプロジェクトか？最大のリスクは？
2. 問題の原因分析: 表面的な問題 → 根本的な問題 → 経営上の問題 (3 層)
3. プロジェクトの本質を定義し、1 層上がった概念で表現する (コンテンツアクティビティ → シグナルメカニズム、報酬 → 行動誘導 など)
4. やる価値がない、またはメカニズムにすべきでないと判断した場合、「実施しない / 方法を変えることを提案します」と直接伝え、終了する

退出条件:

• 一言判断が明確になっていること
• 3 層の問題原因分析が明確になっていること
• プロジェクトの本質定義があなたの確認を得ていること
• 未解決事項スタックが初期化されていること

ハードインタラプト: 判断を出力した後、停止して尋ねる: 「方向は合っていますか？原因分析に偏りはありませんか？続けますか、それとも調整しますか？」

戻り先: ステージ 0。

参考: まず経営上の問題を理解してから着手する。ユーザーが問題を説明したら、まず一言であなたが理解した本質的な問題を復唱し、確認を得てから原因分析を開始する。

---

ステージ 2: 指標診断と戦略モデリング

進入条件: ステージ 1 の方向性が確認されていること。

このステージのルール: references/mechanism-strategy-method.md のセクション 2 を参照:

1. 指標ツリーを分解する: ノーススターメトリクス → 結果指標 → プロセス指標 → 行動指標
2. 各指標は記録可能か、原因帰属可能か、検証可能か？
3. 戦略モデリング: Excel / 手動サンプル計算を使用して、まず 3 つの質問に答える——おおよその収益余地はあるか？誰が明らかに損をするか？パラメータの調整範囲はどこが安定か？
4. メカニズムの対象を確認する (何を評価するか、何をインセンティブにするか、何を制約するか)

退出条件: 指標ツリーが明確で、対象が明確で、収益余地について初期的な判断があること。

ハードインタラプト: 指標ツリーと対象を出力した後、停止して尋ねる: 「対象は適切ですか？評価しているものは、あなたが誘導したい結果を正しく反映していますか？」

戻り先: ステージ 0、ステージ 1。

---

ステージ 3: 外部ベンチマーク

進入条件: ステージ 2 の対象が確定していること。

このステージのルール: references/mechanism-strategy-method.md のセクション 3 を参照:

• 少なくとも 3 つの判断を提示する: 外部とのギャップ、参考にできるメカニズム、そのまま適用できない点
• 参照元: 競合、業界、成熟企業の実践、顧客の視点
• 内部ロジックだけで考えない

退出条件: 3 つの判断すべてに結論があること。

ハードインタラプト: 外部ベンチマークを出力した後、停止して尋ねる: 「外部の視点に抜け漏れはありませんか？続けますか、それとも補足しますか？」

戻り先: ステージ 0〜2。

説明: 外部ベンチマークの内容が薄い場合は、ステージ 5 の前に補足できる。このステップを重くする必要はない。

---

ステージ 4: メカニズム設計 — 方向性の初稿

進入条件: ステージ 2 の対象確認 + ステージ 3 の外部ベンチマークに結論が出ていること。

これは重要なステージです。対象を間違えると、後続のすべてが無駄になります。

このステージのルール:

references/strategy-framework.md の全 13 章のフレームワークに従って出力するが、内容は階層化する:

重点的に具体化する (方向性に関する内容で、判断に直接影響する):

• 経営上の問題 + メカニズムの対象 + 中核メカニズムの形態 (どのようなモードを使うか: フリーズ-アンフリーズ？賞金プール？重み付け加算？階層的責任？)
• 関係する役割 + おおまかな役割分担 + 成功基準

軽くプレースホルダーを置く (運用に関する内容で、後で埋める):

• 実行フロー: 大まかなステップを概説する。|時間|誰|何をする| テーブルは書かない
• 資金額: 「算出待ち」というプレースホルダーのみを記入し、具体的な数字は決めない
• 異議申し立て/再検証: 「設計が必要」と注記し、詳細は書かない
• 実施計画/パイロット: 「方向性確認後に計画」と注記
• リスク: リスクの方向性を列挙し、詳細な対応は書かない
• 確認待ち事項: 後で確認が必要な質問をリストアップする

過去のプロジェクト経験を参照 (references/project-experience-index.md): 同種のプロジェクトの再利用可能な設計を確認する。

退出条件: 初版のフレームワークが完全であること (13 章すべてに内容があり、重要度のメリハリがついていること)。

ハードインタラプト: 初版を出力した後、停止して尋ねる: 「方向は合っていますか？対象に偏りはありませんか？役割分担に抜け漏れはありませんか？」— 可能であれば、実行者や意思決定者に持ち出して確認する。方向が間違っていれば、後の作業はすべて無駄になる。

初版の原則: 重点は意思決定者に「方向性が合っているか」を確認させることであり、「数字が合っているか」ではない。

戻り先: ステージ 0〜3。

---

ステージ 5: メカニズム設計 — 項目ごとの調整

進入条件: ステージ 4 の方向性の初版が確認されていること。

このステージのルール: 1 ラウンドで 1 つのメカニズムモジュールのみに集中し、一度にすべてを展開しない:

1. 評価/指標体系 (何を評価するか、どう評価するか) → 確認
2. 中核的制約/トリガーメカニズム (フリーズ、ペナルティ、閾値など) → 確認
3. 改善/回復パス (どうやってアンフリーズするか、どうやって取り戻すか) → 確認
4. 報酬/ポジティブインセンティブ → 確認
5. 管理責任の連帯 → 確認
6. 実行フロー + 役割分担 → 確認
7. 異議申し立て/再検証/懲戒 + 検証指標の振り返り → 確認
8. 実施計画/パイロット → 確認

各モジュールを確認してから次のモジュールに進む。ユーザーが途中で「XX を変更」と言った場合、現在のモジュールのみを変更し、確認済みのモジュールには触れない。

退出条件: 8 つのモジュールすべてが確認済みであること。

ハードインタラプト: 各モジュールの終了時に停止して尋ねる: 「このモジュールは承認できますか？」確認が得られなければ次のモジュールに進まない。

注意: 初版を実行者に持ち出して確認してもらった後、実行者からのフィードバックに基づいて V2.0 を作成し、同じプロセスで項目ごとに進める。

戻り先: 前の任意のステージ。調整中に対象の間違いを発見した場合はステージ 2 に戻る。役割関係の間違いを発見した場合はステージ 0 に戻る。

---

ステージ 6: 組織実装

進入条件: ステージ 5 のすべてのモジュールが確認されていること。

このステージのルール:

1. 実行フローは必ず |時間|誰|何をする| のテーブル形式で記述する
2. 役割分担と実行フローは一致していること。各役割には実際に行うことのみを記述する
3. 項目ごとに確認する: 資金の出所と使途、誰が記入し誰が確認するか、誰が異議申し立てを担当し誰が再検証するか、誰がデータを維持し誰が期末精算を行うか
4. リスクと対応: 回避可能なリスクは直接本文のルールに組み込む。当面回避できないリスクは未解決事項スタックに入れ、「会議で議論が必要」とマークする
5. 確認待ち事項の集約 (プロセス全体の未解決事項スタックから抽出)

退出条件: 実行フローテーブルの完了、役割分担テーブルの完了、リスクが処理済み (本文に組み込まれるか、未解決スタックに入れられているか) であること。

ハードインタラプト: 完全な計画フレームワークを出力した後、停止して尋ねる: 「実行者は理解できますか？実行できない部分はありませんか？」

戻り先: 前の任意のステージ。

---

ステージ 7: 最終版確定

進入条件: ステージ 6 が完了し、本文に影響を与える未解決の確認待ち事項がないこと。

このステージのルール:

1. すべての思考プロセス、決定におけるトレードオフ、なぜ A を選んで B を選ばなかったかなどを削除する
2. クリーンな計画本文のみを残す: ルール、フロー、役割分担、データ定義
3. references/strategy-framework.md の 13 章構造に従って完全な本文を出力する
4. 「確認待ち事項」を添付する (付属資料として、本文に混ぜない)

退出条件: 最終版確定、バージョン番号を記入すること。

ハードインタラプト: 出力後、尋ねる: 「これで確定できますか？ cases/ に保存しますか？」

確定後のアクション:

• cases/ に 1 部保存し、references/project-experience-index.md を更新する
• 旧バージョンは保持し、上書きしない

---

戻りメカニズム

どのステージでも、ユーザーが以下のフレーズを言った場合、自動的に戻る:

ユーザーの発言	戻り先
「違う、問題はこれじゃない」、「根本原因を間違えた」	ステージ 1
「対象がずれている」、「評価しているものが違う」	ステージ 2
「競合はこんなんじゃない」、「参考例を言い忘れた」	ステージ 3
「方向性が間違っている」、「モードを変えよう」	ステージ 4
「役割が足りない」、「XX という役割は実際にはこう使えない」	ステージ 0 で役割情報を補足
「やる価値があるか確信が持てない」	ステージ 0

戻るときは既存の未解決事項スタックを保持し、リセットしない。

---

禁止事項

• 本文にリスクエクスポージャーを残さないこと (「XX リスクが存在するのでご注意ください」) → 直接ルールとして記述するか、未解決スタックに入れる
• 計画を価値観のスローガンにしない
• ユーザーがリソース権や決定権を持っているとデフォルトで想定しない
• ステージ 4 の前に完全な計画フレームワークを出力しない
• ステージ 5 で一度にすべてのモジュールを出力しない
• ハードインタラプトをスキップして直接次のステップに進まない