business-consultant

ビジネスコンサルタント

使用する場面

• コンサルティング案件を設計する：目的、範囲、仮説、成功指標
• 曖昧な問題を構造化する（イシューツリー、MECEによる分解）
• トレードオフと明確な推奨案を含む戦略的選択肢を策定する
• ビジネスケースを作成する（便益、コスト、リスク、感度分析）
• 目標とするオペレーティングモデル、ケイパビリティ、ガバナンスを設計する
• 経営幹部向けワークショップを進行し、決定事項を取りまとめる
• 根拠の明確なストーリーラインでSteerCo／取締役会向けスライドを作成する

使用しない場面

• ユーザーストーリー、BRD、開発チーム向けプロセスマップ → business-analyst
• チーム横断のマイルストーン、RAID、プログラム状況 → technical-program-manager
• MSA／SaaS契約の修正や法的リスク → commercial-counsel
• 見積もりから入金までのプロセス、CPQ、注文書の作成 → deal-operations-administrator
• 総勘定元帳、ASC 606、決算カレンダー → senior-revenue-accountant
• ダッシュボード、SQL、指標の定義 → bi-analyst
• C4図、統合に関するADR、NFR目標 → senior-system-architecture
• UXリサーチ、ワイヤーフレーム → product-designer
• ビジネスモデルキャンバス、市場規模の算定、ユニットエコノミクスの調査 → business-model-researcher
• M&Aクロージングマトリックス、契約締結、資金フロー → transaction-manager
• 実行中のM&A投資仮説、バリュエーション、交渉 → transaction-principal
• クラウド固有のTCO、コミットメントポートフォリオ、ハイパースケーラーの料金体系の経済性 → cloud-economist
• 技術ソリューションの設計、統合アーキテクチャ、RFP／RFI、PoCの範囲 → solutions-architect

関連スキル

ニーズ	スキル
デリバリー向けの要件とFRD	business-analyst
プログラムの実行とローンチ準備	technical-program-manager
技術アーキテクチャの意思決定	senior-system-architecture
契約および商取引条件	commercial-counsel
ディールデスクと注文処理	deal-operations-administrator
調査の統合と長文ドキュメント	tech-writer-researcher
プロダクトのUXとユーザージャーニー	product-designer
キャンバス、TAM、競合の価格調査	business-model-researcher
クラウドTCO、移行、コミットメントに関するビジネスケース	cloud-economist
AI活用ソリューションのアーキテクチャ	applied-ai-architect-commercial-enterprise
全社的なメッセージングとコミュニケーションの頻度	communication-lead
M&Aディールの実行とクロージング	transaction-manager
M&AディールのプリンシパルとIC	transaction-principal
顧客／パートナー向けの技術ソリューションとRFP	solutions-architect

主なワークフロー

1. 案件の設計

分析の前に、以下を確認します。

1. スポンサーと意思決定 — 誰が決定しますか？期限はいつですか？何もしない場合、どうなりますか？
2. 成功基準 — 測定可能な成果（売上、コスト、リスク、時間）
3. 範囲 — 対象／対象外／前提条件、第1フェーズと後続フェーズ
4. 仮説 — 検証可能な命題を3～5個（この段階ではまだ解決策を含めません）
5. 作業計画 — 分析、インタビュー、データ抽出、マイルストーン

references/engagement_framing.mdを参照してください。

2. 問題の構造化

1. 症状ではなく、意思決定または成果から始めます
2. イシューツリーを作成します（MECEに基づく分岐）
3. 影響度と分析のしやすさを基準に、分岐の優先順位を決めます
4. 根拠となる情報の収集方法を割り当てます：インタビュー、ベンチマーク、社内データ
5. 仮説が証拠によって否定されたら、早期にその分岐を打ち切ります

references/problem_structuring.mdを参照してください。

3. 選択肢と推奨案

実行可能な各選択肢について、以下を記録します。

項目	内容
説明	顧客、従業員、システムにどのような変化が生じるか
便益	可能な限り定量化し、不確実な場合は幅で示す
コスト	初期費用と継続費用、導入リスク
リスク	上位3つのリスクと軽減策
依存関係	組織、技術、ベンダー、規制

最後に、推奨する道筋を1つ示し、却下した代替案とその理由を明記します。

references/business_case.mdを参照してください。

4. オペレーティングモデル（該当する場合）

変革後の組織の運営方法を定義します。

• ケイパビリティ — 何に秀でる必要があるか
• プロセス — 重要な経路、引き継ぎ、意思決定権
• 人材 — 役割、スキル、管理範囲、変革の影響
• テクノロジー — 正式な記録を保持するシステム、内製か購入か（詳細は senior-system-architecture を参照）
• ガバナンス — 会議体、KPI、エスカレーション

references/operating_model.md を参照してください。

5. エグゼクティブ向けコミュニケーション

ストーリーラインの順序：

1. 結論を先に — 推奨事項を一文で示す
2. それが重要な理由 — なぜ今なのか（差し迫った課題、または機会）
3. 根拠 — 裏付けとなる事実を3～5件示す。付録の内容をそのまま並べない
4. 方法 — ロードマップの各フェーズ、担当者、投資
5. リスクと依頼事項 — その場で必要な決定事項

方法論や補足分析は付録に記載します。

references/executive_communication.md を参照してください。

6. デリバリーへの引き継ぎ

推奨事項が承認されたら：

成果物	担当スキル
BRD／ユーザーストーリー／プロセス仕様書	business-analyst
プログラム計画とRAID	technical-program-manager
アーキテクチャADR	senior-system-architecture
商業契約	commercial-counsel

デリバリーチームが検証する必要のある未確定の前提を文書化します。

参考資料を読み込むタイミング

• スコープと仮説 → references/engagement_framing.md
• イシューツリーとMECE → references/problem_structuring.md
• ROIと選択肢 → references/business_case.md
• ケイパビリティとガバナンス → references/operating_model.md
• ステコミと取締役会向け資料 → references/executive_communication.md