leadership-stakeholder-management

リーダーシップとステークホルダー管理のスキル

プロダクトマネジメントの人間的な側面を極めましょう。ステークホルダーの足並みをそろえ、効果的にコミュニケーションを取り、対立を解決し、共通のビジョンに向けてチームを鼓舞します。

ステークホルダーのマッピングと分析

すべてのステークホルダーを特定する

┌─────────────────┬──────────────────┐
│   DECISION      │    INFLUENCE     │  ← POWER
│   MAKERS        │    MAKERS        │
│                 │                  │
│   CEO, Board    │  VP Eng, Design  │
├─────────────────┼──────────────────┤
│   USERS         │   SUPPORT        │  ← LOW POWER
│                 │   TEAM           │
└─────────────────┴──────────────────┘
     LOW              HIGH
     INTEREST    ← INTEREST →

ステークホルダー一覧

社内ステークホルダー：

経営陣

• CEO：会社の成功
• CFO：予算／収益性
• CTO：技術的な実現可能性
• COO：業務への影響

エンジニアリング

• エンジニアリング担当VP：技術戦略、リソース配分
• エンジニアリングリード：実装の難易度
• QAリード：必要なテスト期間

デザイン

• デザインリード：ユーザー体験、デザインシステムへの影響

マーケティング

• マーケティング担当VP：GTM、メッセージング
• デマンドジェネレーション：コンバージョンへの影響

営業

• 営業担当VP：営業支援、収益への影響
• 営業チーム：製品の機能

カスタマーサクセス

• CS担当VP：顧客満足度への影響

サポート

• サポートリード：サポート件数への影響

社外ステークホルダー：

• 投資家：事業指標
• 主要顧客：機能リクエスト
• パートナー：統合への影響
• コミュニティ：オープンソースプロジェクト

ステークホルダーの評価

各ステークホルダーについて、以下を評価します。

1. 関心度 - どの程度関心を持っていますか？
2. 影響力 - どの程度の権限を持っていますか？
3. 態度 - 支持的、中立的、または反対的ですか？
4. コミュニケーションのニーズ - 何を伝える必要がありますか？

エンゲージメント戦略：

• 密接に管理する（関心度が高く、影響力も強い） - 毎週の進捗報告、深い関与
• 満足度を保つ（関心度が低く、影響力は強い） - 月次の進捗報告、重要な意思決定
• 情報を共有する（関心度が高く、影響力は弱い） - 透明性、フィードバックループ
• 状況を監視する（関心度も影響力も低い） - 必要に応じた進捗報告

コミュニケーションのフレームワーク

BLUF（結論を最初に伝える）

構成：

1. 結論（1文） - 決定事項／ニュース
2. 状況（2～3文） - 背景と経緯
3. 影響（2～3文） - なぜ重要なのか
4. 次のステップ - 今後の予定

例：

BOTTOM LINE: We're pausing the mobile app to focus on web performance.

SITUATION: Our web app speed is 2x slower than competitors, causing
40% of free users to churn. Mobile app is only 5% of usage.

IMPLICATIONS: Focusing on web unlocks 10x retention improvements,
strengthens our core offering, and builds foundation for mobile later.

NEXT STEPS: Engineering team shifts Tuesday. We'll replan mobile for Q2.

SitRep（状況報告）

週次ステータステンプレート：

PROJECT: [Name]
STATUS: On Track / At Risk / Off Track
PROGRESS:
- Completed: [Achievement]
- In Progress: [Current work]
- Blocked: [Blockers]

METRICS:
- Metric 1: [Current vs Target]
- Metric 2: [Current vs Target]

CHALLENGES:
- Challenge 1 (Severity: High)
  Mitigation: [Plan]
- Challenge 2 (Severity: Medium)

NEXT WEEK:
- Next step 1
- Next step 2

1ページ資料の形式

2ページのエグゼクティブブリーフ：

1ページ目：

• タイトルと日付
• 要約（2～3文）
• 問題の説明
• 提案する解決策
• 期待される影響（収益／成長／NPS）

2ページ目：

• 詳細な根拠
• 成功指標
• タイムライン
• 必要なリソース
• リスクと軽減策
• 求める決定

経営陣とのコミュニケーション

取締役会への報告（月次／四半期ごと）

プレゼンテーションの構成（30分）：

1. ダッシュボード（5分）

   • 目標に対する主要指標
   • 緑／黄／赤のステータス
   • トレンドを示す矢印

2. 進捗（5分）

   • リリースした機能
   • 顧客の成功事例
   • チームの最新情報

3. 課題（5分）

   • 市場の課題
   • 競争上の脅威
   • 社内の阻害要因

4. 機会（5分）

   • 市場機会
   • 戦略的な賭け
   • 投資の必要性

5. 依頼事項（5分）

   • 必要なもの（資金、リソース、承認）
   • タイムラインと影響
   • 取締役会に求める決定

ピッチデッキ（投資家向け）

15～20枚：

1. 課題（顧客の悩み）
2. 市場機会（TAM/SAM/SOM）
3. ソリューション（開発するもの）
4. 製品デモ（動作を実演）
5. ビジネスモデル（収益化の方法）
6. Go-to-market（顧客獲得）
7. チーム（勝てる理由）
8. トラクション（顧客による実証）
9. 財務情報（収益予測）
10. 資金の使途（投資資金の使い方）
11. Q&A（質問に備える）

経営陣向けのストーリーテリング

ゴールデンサークル・フレームワーク：

       WHY?
      ░░░░░
    ┌────────┐
    │ What?  │
    │(Facts) │
    └────────┘

WHY: Why does this matter?
WHAT: What are we doing?
HOW: How will we do it?

例：

WHY: Every team wastes hours syncing data across tools
WHAT: We're building one unified hub for collaboration
HOW: Real-time sync, zero-config integrations, beautiful UX

部門横断の足並み合わせ

ステークホルダーとの調整会議

会議前（前週の金曜日）：

• アジェンダと背景情報を送る
• 要点をまとめた1ページ資料
• データ／根拠
• 提案する決定事項

会議（翌週月曜日、45分）：

• 開始（5分） - 目標と必要な決定事項
• 背景（10分） - なぜ重要なのか
• 提案（10分） - 推奨内容
• ディスカッション（15分） - 質問と懸念
• 決定（5分） - 明確な決定と次のステップ

会議後（翌週火曜日）：

• 要約を送る
• 決定事項を記録する
• 次のステップの担当者を決める
• フォローアップのスケジュール

対立の解決

ステークホルダーの意見が一致しない場合：

1. 深く耳を傾ける - 双方の視点を理解する
2. 共通点を見つける - 双方が重視していることは何か
3. 視点を変える - 双方が支持する、より大きな目標を見つける
4. トレードオフを提案する - 段階的に進めて両方を実現できないか
5. 決定する - 必要であれば、PMが決定する（エスカレーションの経路を設ける）

例：

エンジニアリングは技術的負債をさらに解消したいと考えています。 営業は顧客向けの新機能を求めています。

視点を変える： どちらも、満足して継続利用してくれる顧客を望んでいます。

• 技術的負債の解消：新機能をより速く、より高品質に提供できる
• 新機能：顧客が実際に必要としているもの

トレードオフ： 各スプリントで、新機能に70％、技術的負債の解消に30％を充てる

定例会議

毎週：

• プロダクトのスタンドアップ（15分） - 進捗報告
• エンジニアリングの同期（30分） - 技術的な議論
• デザインレビュー（30分） - デザインの進捗

隔週：

• プロダクト評議会（60分） - ロードマップに関する決定
• 部門横断の計画会議（60分） - 今後の作業

毎月：

• 全社ミーティング（30分） - 会社の最新情報
• 顧客諮問委員会（60分） - 顧客からのフィードバック

四半期ごと：

• 計画（8時間） - 次の四半期のロードマップ
• 振り返り（2時間） - 学び

プロダクトの推進

社内での推進

チームをビジョンに引き込む：

• 心に響くストーリーを伝える
• 顧客の声を共有する
• 成功を祝う
• インパクトを可視化する
• 当事者意識を育む

コミュニケーション：

• 毎週のメール更新
• 毎月の全社説明会
• Slackでのお知らせ
• 1対1のミーティング

社外での推進

専門性と信頼を築く：

執筆：

• 業界トレンドに関するブログ記事
• プロダクト思考に関するLinkedIn記事
• 顧客の成功事例

登壇：

• カンファレンスでの講演（選択的に参加する）
• ポッドキャストのインタビュー
• 顧客向けウェビナー
• メディアのインタビュー

コミュニティ：

• Twitter／LinkedInでの交流
• ユーザーの質問に答える
• ロードマップを透明性をもって共有する
• 公開の場でフィードバックを求める

メディアと広報

プレスリリースのテンプレート：

For Immediate Release

[Company] Launches [Product] to Help [Customer Type] [Benefit]

[City] - [Company] today announced the launch of [Product],
which [key benefit].

Key features:
- Feature 1
- Feature 2
- Feature 3

"[CEO quote about why this matters]," said [Name].

Availability: [Where/when available]

About [Company]: [1-2 sentence description]

Contact: [PR contact]

変更管理

方向転換が必要なとき

発表の枠組み：

1. 過去 - 何を学んだか、当時なぜそれが正しかったのか
2. 現在 - 新しい情報／市場の実情
3. 未来 - 新しい方向性と、それがより良い理由
4. 影響 - 各グループにどのような変化があるか
5. 支援 - 移行をどのように支援するか

例：

「SMB（Enterpriseではなく）が、私たちにとって最大の機会だと分かりました。 （これまでの注力先が逆でした。）

来月から、すべてのリソースをSMBのGTMに移します。 （変更内容。）

Enterpriseの営業チームは、SMBの営業チームへ移行します。 （影響。）

研修を提供し、他部門の役割も案内します。 （支援。）」

コミュニケーションの頻度

毎週

• 状況報告メール
• 部下との1対1のミーティング
• プロダクトのスタンドアップ
• ステークホルダーへの進捗共有

毎月

• 全社プレゼンテーション
• プロダクトのメールニュースレター
• 指標のレビュー
• ステークホルダーとの会議

四半期ごと

• 戦略レビュー
• ロードマップのプレゼンテーション
• チームのオフサイト
• 取締役会への報告

毎年

• 全社リトリート
• ビジョンの見直し
• 報酬／昇進サイクル

難しい話し合い

難しい知らせを伝える

構成：

1. 共感から始める - 「あなたに影響があることはわかっています」
2. 明確かつ率直に伝える - 遠回しに言わない
3. 理由を説明する - 背景と根拠
4. 相手の反応を待つ - 反応する時間を与える
5. サポートを申し出る - 「どのようにサポートするかお伝えします」

例：

「今四半期にモバイルアプリがリリースされると期待していたことはわかっています。解約につながっているウェブのパフォーマンス改善に注力するため、リリースを延期するという難しい決断をしました。厳しい決断でしたが、事業にとって正しい選択です。この移行を乗り越えられるようサポートしたいと思います。最も懸念していることは何ですか？」

断る

機能リクエストに対して： 「素晴らしいアイデアですね。[problem]の解決に役立ちます。現在は、より大きな機会である[strategic priority]に影響するため、[strategic priority]に注力しています。第2四半期のロードマップに追加します。仮置きしておいてもよいでしょうか？」

ステークホルダーからの圧力に対して： 「これが必要だということは理解しています。私たちのロードマップには、より大きな効果が見込める項目が多数あります。これが本当に重要なら、どの項目の優先度を下げますか？トレードオフを把握する必要があります。」

トラブルシューティング

よくある間違いと解決策

間違い	考えられる原因	解決策
ステークホルダーの反発	関与が不十分	早い段階から参加してもらう
意思決定の停滞	ステークホルダーが多すぎる	RACI マトリックス
意見の不一致	コミュニケーション不足	コミュニケーションの頻度を増やす
対立の深刻化	懸念への対応不足	1 対 1 のミーティング

デバッグチェックリスト

[ ] Tüm stakeholder'lar identified mi?
[ ] RACI matrix var mı?
[ ] Communication cadence set mi?
[ ] Decision rights clear mi?
[ ] Conflict early identified mi?

復旧手順

1. ステークホルダー間の対立 → 1 対 1 のミーティングを行い、懸念を理解する
2. 意思決定の行き詰まり → トレードオフマトリックスを作成し、上位者に相談する
3. 変化への抵抗 → 懸念に対応し、メリットを示す

---

リーダーシップを発揮し、優れた製品の実現に向けて組織を鼓舞しましょう！