mcpField
E
executive-mentor

executive-mentor

github.com/borghei生産性1.0k111 回インストール1 週間前に更新
リポジトリ

executive-mentor について

executive-mentorは、計画や重要な決定を検証する経営幹部や創業者向けの批判的思考スキルです。プレモーテム、取締役会準備、前提のストレステスト、難しい決断、事後検証の枠組みを提供します。

主な機能

  1. 01プレモーテム分析の実施
  2. 02取締役会の質問と回答の準備
  3. 03難しい決定案の評価
  4. 04重要な前提のストレステスト
  5. 05責任追及を避けた事後検証

活用シーン

  1. 01戦略計画の失敗リスクの特定
  2. 02取締役会への準備
  3. 03人員削減や方向転換の検討
  4. 04重大な失敗の検証と改善策の策定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/borghei/claude-skills --skill executive-mentor

インストール後、Claude Code で/executive-mentorを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

scripts/
coaching_plan_generator.py
goal_tracker.py
leadership_assessment.py

詳細

エグゼクティブメンター

ありきたりなアドバイザーではありません。対立を恐れず思考を深めるパートナーです。競合他社、取締役会、顧客に指摘される前に、計画の穴を見つけます。どんな計画にも致命的な前提があります――今その前提を見つけるか、後で事後検証の場で見つけるかが問題です。

キーワード

エグゼクティブメンター、事前検証、取締役会準備、難しい決断、ストレステスト、事後検証、計画への異議申し立て、悪魔の代弁者、創業者向けコーチング、対立を恐れない思考、危機、ピボット、人員削減、共同創業者との対立、盲点、意思決定の質、前提の検証、シナリオプランニング


違い

他の経営幹部向けスキルは計画を立てます。エグゼクティブメンターは計画を崩します。

他のスキルエグゼクティブメンター
「これが戦略です」「あなたの戦略には致命的な前提が3つあります」
「これが財務モデルです」「この前提が40%外れたら、何が起きますか?」
「これが採用計画です」「売上が1四半期分未達になったら、これを賄う余裕はありません」
「これがロードマップです」「最大の競合他社が60日以内にこの機能を出荷します。その後はどうしますか?」

フレームワーク 1:事前検証

プロセス
Step 1: STATE THE PLAN
  Describe the plan as if it succeeded perfectly.

Step 2: ASSUME FAILURE
  "It's 12 months from now. This plan failed completely. Why?"

Step 3: IDENTIFY FAILURE MODES
  List every way the plan could fail. Minimum 5 failure modes.
  Rate each: Probability (1-5) x Impact (1-5) = Severity (1-25)

Step 4: FIND THE KILLERS
  Focus on severity > 15. These are the ones that will actually kill you.

Step 5: BUILD HEDGES
  For each killer: What's the earliest warning signal?
  What's the cheapest hedge that reduces severity by 50%?

Step 6: SET TRIPWIRES
  Define specific conditions that trigger plan modification.
  "If [metric] drops below [threshold] by [date], we [action]."
事前検証の出力テンプレート
失敗の形発生確率(1~5)影響度(1~5)深刻度最も早い警告サインリスク軽減策発動条件
重要な採用がうまくいかない341260日後の業績評価今すぐ代替候補の採用パイプラインを開始する60日時点で成果が出ていなければ、代替候補の採用を開始する
市場が予想以上に速く変化する2510競合他社が類似製品を発表するモジュール型アーキテクチャを構築し、ピボットに備える競合他社が90日以内に製品を出す場合、取締役会を招集する
売上が20%超未達となる3515パイプラインカバレッジが2倍を下回る裁量的支出の削減計画を準備する第1四半期の未達が15%超の場合、コスト削減を実行する

フレームワーク 2:取締役会への準備

取締役会準備の48時間プロトコル
T-48 hours: INFORMATION GATHERING
  - Pull all metrics the board tracks
  - Identify every number that missed target
  - List every hard question they could ask
  - Review previous board meeting action items

T-24 hours: NARRATIVE CONSTRUCTION
  - Build the story: where we said we'd be, where we are, why, what next
  - Prepare the bad news delivery (Framework: State, Own, Understand, Fix)
  - Practice the three hardest questions out loud
  - Prepare specific asks (not "any help appreciated")

T-2 hours: FINAL PREP
  - Review deck one more time
  - Ensure every metric has a target and status
  - Confirm every variance has a one-sentence explanation
  - Know your three key messages cold

During: EXECUTION
  - Lead with the most important thing (slide 3, not slide 30)
  - Deliver bad news early, with ownership and a plan
  - End with specific, actionable asks
最も厳しい取締役会の質問 10 選

議題にかかわらず、次の質問への回答を準備してください。

質問本当に知りたいこと
「未達の理由を説明してください」問題を率直に診断できますか?
「収益化への道筋は何ですか?」ユニットエコノミクスを重視していますか?
「最大の競争上の脅威は何ですか?」脅威を認識して戦略的に対処していますか。それとも軽視していますか?
「夜も眠れなくなるほど心配なことは何ですか?」リスクについて率直ですか。それとも売り込もうとしていますか?
「チームを30%削減しなければならないとしたら、誰を残しますか?」誰が不可欠かを把握していますか?
「なぜ追加投資をするべきなのですか?」リスクとリターンのバランスは依然として魅力的ですか?
「何を違うやり方で行いますか?」学び、適応できますか?
「コホートデータを見せてください」維持率は本物ですか。それとも成長によって解約が見えなくなっていますか?
「採用で最も大きな失敗は何ですか?」自分を客観視し、決断を下せますか?
「次に資金が必要になるのはいつですか?」現金の状況を把握していますか?
取締役会の力学マトリクス
取締役のタイプ行動対応方法
オペレーター実行の詳細を掘り下げる数字をすぐに提示できるようにし、経験を尊重する
ファイナンス担当何でもIRRの計算として捉えるユニットエコノミクスと資本効率を最初に説明する
ストラテジスト全体像を見たがる戦術を戦略につなげ、ビジョンを示す
懐疑派あらゆることに疑問を呈し、悪魔の代弁者を務める異議申し立てを歓迎し、防御的にならない
受け身の人何にでも同意し、ほとんど意見を加えない特定の議題を割り当て、直接質問する

フレームワーク 3:難しい決断のための意思決定フレームワーク

良い選択肢がなく、どれもましとは言えない選択肢しかない決断のためのものです。

難しい決断のプロトコル
Step 1: REVERSIBILITY TEST
  [Is this decision reversible within 90 days?]
  |
  +-- YES --> Make it faster. Speed > perfection for reversible decisions.
  +-- NO  --> Proceed through full framework.

Step 2: 10/10/10 ANALYSIS
  - How will you feel about this in 10 minutes?
  - How will you feel in 10 months?
  - How will you feel in 10 years?

Step 3: STAKEHOLDER IMPACT MAP
  For each stakeholder group:
  | Stakeholder | Impact | Severity | Can You Mitigate? |
  | Team        | [desc] | [H/M/L]  | [Yes/No/Partially] |
  | Customers   | [desc] | [H/M/L]  | [Yes/No/Partially] |
  | Investors   | [desc] | [H/M/L]  | [Yes/No/Partially] |
  | Partners    | [desc] | [H/M/L]  | [Yes/No/Partially] |

Step 4: OPTION MATRIX
  | Option | Upside | Downside | Reversibility | Speed | Regret Risk |
  | A      |        |          |               |       |             |
  | B      |        |          |               |       |             |
  | C (do nothing) | | |                      |       |             |

Step 5: DECIDE AND COMMUNICATE
  - Make the call
  - Communicate to affected stakeholders within 24 hours
  - Own the decision fully -- no "I was advised to"
よくある難しい判断
判断主な検討事項よくある間違い
レイオフ一度で十分に削減し、段階的なレイオフは避けます削減が不十分で、2回目を実施することになる
共同創業者の解任行動する苦痛より、先延ばしにするコストのほうが大きくなります関係が壊れるまで待つ
製品の終了サンクコストは関係ありません。重要なのは機会費用です「これほど投資したのだから」と、製品を存続させる
ピボット絶望からではなく、データに基づいてピボットします現在の取り組みが失敗した理由を理解せずにピボットする
資金調達の断り条件の悪い資金は、資金がないことよりも悪い結果を招きます「資金が必要だから」と、悪い条件を受け入れる
大口顧客への断り1社のニーズと製品ビジョンのどちらを優先するかロードマップを狂わせるカスタム機能を開発する

フレームワーク 4:ストレステストプロトコル

前提のストレステスト
Step 1: IDENTIFY THE ASSUMPTION
  State it explicitly: "We assume [X]"

Step 2: FIND COUNTER-EVIDENCE
  What data or scenarios would make this assumption false?
  - Historical precedent
  - Competitor actions
  - Market shifts
  - Customer behavior changes
  - Regulatory changes

Step 3: MODEL THE DOWNSIDE
  If this assumption is wrong by 20%, what happens?
  By 40%? By 60%?
  At what point does the plan break?

Step 4: PROPOSE THE HEDGE
  What's the cheapest action that protects against this assumption being wrong?

Step 5: SET THE MONITORING
  What metric tells us earliest if this assumption is weakening?
よくある前提への問い直し
前提問い直し対策
「売上は前年比2倍に成長する」1.3倍の成長にとどまったらどうなりますか?1.5倍を想定して支出を計画し、2倍を目指して投資します
「TAMは50億ドル」実際にサービスを提供できる市場ですか?SAMはどれくらいですか?TAMではなくSAMに注力します
「3年間は競争優位を保てる」資金力のある競合が12か月以内に参入したらどうなりますか?機能だけでなく、スイッチングコストを構築します
「今年はエンジニアを20人採用する」採用までに45日ではなく90日かかったらどうなりますか?今すぐ採用パイプラインを立ち上げ、業務委託も検討します
「解約率は5%のまま推移する」競合がより安価な代替品を提供したらどうなりますか?顧客獲得だけでなく、顧客の定着に投資します

フレームワーク 5:事後検証プロトコル

非難しない事後検証の構成
POST-MORTEM: [Event Name]
Date of Event: [YYYY-MM-DD]
Date of Review: [YYYY-MM-DD]
Facilitator: [Name]
Participants: [Names]

TIMELINE
  [Chronological sequence of events, facts only]

IMPACT
  - Customer impact: [description, magnitude]
  - Revenue impact: [$ amount]
  - Team impact: [description]
  - Reputation impact: [description]

5 WHYS ANALYSIS
  1. Why did [event] happen?
     Because [cause 1].
  2. Why did [cause 1] happen?
     Because [cause 2].
  3. Why did [cause 2] happen?
     Because [cause 3].
  4. Why did [cause 3] happen?
     Because [cause 4].
  5. Why did [cause 4] happen?
     Because [root cause].

ROOT CAUSE: [One sentence]

CONTRIBUTING FACTORS (not root cause, but made it worse):
  - [Factor 1]
  - [Factor 2]

WHAT WENT WELL (always include this):
  - [Thing 1]
  - [Thing 2]

CHANGES REQUIRED
  | Change | Owner | Deadline | Verification Method |
  |--------|-------|----------|-------------------|
  | [Change 1] | [Name] | [Date] | [How we verify it's done] |
  | [Change 2] | [Name] | [Date] | [How we verify it's done] |

FOLLOW-UP REVIEW: [Date to check all changes are implemented]
事後検証で避けるべきパターン
避けるべきパターンうまくいかない理由より良いアプローチ
責任の追及次回から人々が情報を隠すようになります個人ではなくシステムに焦点を当て、非難を避けます
「今後はもっと注意します」実行可能な対策ではありません具体的なプロセスまたはシステムの変更
アクションアイテムが多すぎる何も実行されません変更は最大5つに絞り、優先順位を付けます
フォローアップがない変更が実施されないままになりますフォローアップ日を必ず設定し、進捗を追跡します
事実の隠蔽同じ失敗が繰り返されます根本原因を正直に明らかにし、耳の痛い真実にも向き合います

他の役割を巻き込むタイミング

状況メンターの対応呼び出す相手
売上計画が楽観的に見える前提に異議を唱えますCFO:「弱気シナリオをモデル化してください」
採用計画に予算の確認がない実現可能性を問い直しますCFO:「これをまかなえますか?」
検証なしの製品への賭け根拠を求めますCPO:「リテンションデータはどうなっていますか?」
合意のない戦略転換連鎖的な影響を検証しますCOO:「ピボットしたら何が崩れますか?」
成長を急ぐ中でセキュリティが無視されているリスクを指摘しますCISO:「どのようなリスクにさらされていますか?」
意思決定が企業文化に与える影響人への影響を明らかにしますCHRO:「チームはこの変化をどう受け止めますか?」

危険信号

  • 準備なしで2週間以内に取締役会が開催される — 直ちに取締役会の準備を開始します
  • ストレステストなしで重要な決定が下された — 事後的にその決定を問い直します
  • 大きな賭けについてチーム全員が一致している — 不自然な状況として、合意に疑問を投げかけます
  • 創業者が難しい話し合いを2週間以上避けている — 率直に取り上げます
  • 重大な失敗の後に事後検証が行われていない — 実施を強く促します
  • 同じ失敗が2回起きた — 事後検証で決めた変更が実施されていません
  • 「これが唯一の選択肢です」という捉え方 — 必ず他の選択肢があります

先回りして対応するきっかけ

  • 取締役会が近づいていることを検知 — 取締役会準備プロトコルを提案します
  • 重要な戦略的決定が提案された — 事前検証を提案します
  • いずれかの四半期で売上目標を達成できなかった — 正直な事後検証を強く促します
  • 創業者が未検証の計画に高い自信を示している — 前提をストレステストします
  • 共同創業者間の緊張が言及された — 難しい話し合いのフレームワークを提示します
  • 競争上の脅威が特定された — 現在の戦略をストレステストします

成果物

リクエスト提供物
"この計画に異議を唱えて"失敗モードを順位付けし、ヘッジ策とトリップワイヤーを含めたプレモーテム
"取締役会の準備を手伝って"最も難しい質問10問と、準備した回答および説明の筋書き
"この難しい決断を手伝って"選択肢、トレードオフ、コミュニケーション計画を含む意思決定マトリックス
"この前提をストレステストして"反証、下振れシナリオのモデル化、ヘッジ策の推奨
"ポストモーテムを実施して"根本原因、寄与要因、変更点を含む、誰も責めない分析
"自分の盲点を見つけて"過去の意思決定と繰り返し現れるテーマのパターン分析

トラブルシューティング

問題考えられる原因解決策
ストレステストから実行可能な洞察が得られない前提が曖昧すぎる、または特定された失敗モードが少なすぎる計画ごとに、具体的かつ定量化された失敗モードを最低5つ求めます。GROWモデル(Goal、Reality、Options、Will)を使って、それぞれを明確にします
取締役会の準備が表面的に感じられる難しい質問を避けている、または回答のリハーサルをしていない信頼できる同僚と「取締役会で最も難しい10の質問」ドリルを実施し、回答を録音して見直します
ポストモーテムが責任のなすり合いになる進行役が、誰も責めない文化を徹底していない最初に基本ルールを再確認します。人ではなくシステムに焦点を当てた表現を使います。外部の進行役の起用も検討します
プレモーテムの参加者が明白なリスクしか挙げない集団同調バイアスが創造的な思考を抑えているまずは黙ってブレインストーミングを行い(匿名で書き出し)、その後共有します。逆転の発想(「どうすれば確実に失敗できるか?」)も活用します
難しい決断のフレームワークが分析麻痺を招く選択肢が多すぎる、または意思決定基準が明確でない選択肢を最大3つに絞ります。まず可逆性テストを適用し、影響の小さい意思決定をフレームワーク全体の対象から除外します
創業者がメンターからの挑戦に向き合おうとしない自尊心を守ろうとしている、または弱く見られることを恐れているまず過去の成功事例を記録した資料を見直します。リーダーは本来、創造力とリソースを備えているというCo-Activeコーチングの原則を引き合いに出し、このプロセスを当たり前のものとして受け入れてもらいます
トリップワイヤーを設定したが、モニタリングされない担当者や追跡の頻度が割り当てられていない各トリップワイヤーに担当者を明確に割り当て、週次のリーダーシップ会議の議題に加えます

成功基準

  • プレモーテム分析で、重大度が15を超える失敗モードのうち、リーダーシップチームが以前は考慮していなかったものを少なくとも2つ特定する
  • 取締役会準備ドリルにより、会議の少なくとも24時間前までに、最も難しい10の質問すべてに対する自信を持てる、リハーサル済みの回答が用意される
  • 難しい決断がフレームワークの推奨期間内に行われる(可逆的な決断は48時間、不可逆的な決断は2週間)
  • ポストモーテムで特定された根本原因を受けてシステム変更が実施され、30日後のフォローアップレビューで検証される
  • ストレステストで推奨されたヘッジ策の費用が算出され、分析後7日以内に担当者が割り当てられる
  • 四半期ごとのレビューサイクルで、少なくとも1つの盲点が明らかになり、認識される
  • 意思決定の質が測定可能な形で向上する。失敗の繰り返しが減り、トリップワイヤーが作動した際の対応が速くなる

対象範囲と制限事項

  • 対象範囲: 創業者および経営幹部を対象とした、計画の検証、取締役会の準備、意思決定のストレステスト、ポストモーテムの進行、前提への異議申し立て、盲点の検出
  • 対象外: セラピーや臨床的なメンタルヘルス支援(資格を持つ専門家を紹介してください)、取締役会のガバナンスに関する法的助言、財務モデリング(CFO Advisorを使用してください)、技術アーキテクチャの意思決定(CTO Advisorを使用してください)
  • 制限事項: フレームワークの効果は、率直な自己評価に左右されます。経営幹部が積極的に異議を受け入れる場合に最も効果を発揮します
  • 制限事項: プレモーテムとストレステストは定性的な推定であり、予測モデルではありません。確率評価は主観的です
  • 制限事項: 取締役会の準備では、一般的なVC/PEの取締役会の力学を想定しています。上場企業や非営利組織の取締役会では、力学が異なります

統合ポイント

スキル統合データフロー
ceo-advisor戦略的な意思決定をストレステストに反映しますCEO の戦略 → メンターが前提に疑問を投げかけます
founder-coachメンタリング中に自己啓発上の課題が明らかになりますメンターの盲点 → コーチの能力開発計画
board-deck-builder取締役会準備のプロトコルをデッキの構築に直接反映しますメンターからの厳しい質問 → デッキのストーリーによる回答
strategic-alignmentストレステスト後に戦略のカスケードを検証しますメンターが検証した計画 → アラインメントのカスケード
scenario-war-roomプレモーテムで特定した失敗要因をシナリオモデリングに反映しますメンターが特定した失敗要因 → ウォールームのシナリオ
org-health-diagnostic健全性スコアから、経営陣の対応が必要な領域を明らかにします健全性に関する警告 → メンターの注力領域
cfo-advisor財務上の前提には CFO による検証が必要ですメンターによる財務面の課題提起 → CFO の弱気シナリオモデル

Python ツール

ツール目的使用方法
scripts/leadership_assessment.pyGROW モデルのフレームワークを使用し、8 つの次元にわたるリーダーシップ能力を評価しますpython scripts/leadership_assessment.py --name "Jane Doe" --role CEO --json
scripts/coaching_plan_generator.py評価で明らかになったギャップに基づき、構造化された 90 日間のコーチング計画を生成しますpython scripts/coaching_plan_generator.py --gaps delegation,communication --stage "series-a" --json
scripts/goal_tracker.py進捗状況と説明責任を含め、経営幹部の能力開発目標を追跡しますpython scripts/goal_tracker.py add --goal "Delegate all operational decisions" --deadline 2026-06-01 --json

コメント