mcpField
S
Stakeholder Analysis

Stakeholder Analysis

github.com/danhvb生産性95 回インストール
リポジトリ

Stakeholder Analysis について

Stakeholder Analysisは、プロジェクト関係者の特定と管理を支援するスキルです。プロジェクト計画や要件整理、変更管理に向けて、権力・関心マトリクス、RACI、関係者台帳、コミュニケーション計画を活用します。

主な機能

  1. 01プロジェクト関係者の特定
  2. 02権力・関心マトリクスでの分類
  3. 03RACIによる責任分担
  4. 04関係者台帳の管理
  5. 05コミュニケーション計画の作成

活用シーン

  1. 01プロジェクト開始と計画の準備
  2. 02要件ヒアリングの設定
  3. 03変更時の連絡と関与の計画

インストール

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

$npx skills add https://github.com/danhvb/my-ba-skills --skill stakeholder-analysis

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

詳細

ステークホルダー分析スキル

目的

プロジェクトのライフサイクル全体を通じて、適切な関与、コミュニケーション、管理を確実に行うため、プロジェクトのステークホルダーを特定して分析します。

使用するタイミング

  • プロジェクトの開始と計画
  • 要件収集の準備
  • 変更管理の計画
  • コミュニケーション戦略の策定
  • リスク評価（ステークホルダー関連のリスク）

ステークホルダーの特定

ステークホルダーの情報源
  • プロジェクトスポンサーと経営幹部
  • ビジネスオーナーと部門長
  • エンドユーザー（社内および社外）
  • IT チームと開発チーム
  • 外部ベンダーとパートナー
  • 規制機関
  • 顧客とクライアント
特定手法
  1. 組織図の確認：影響を受ける部門を特定します
  2. チームでのブレインストーミング：影響を受けるのは誰か、影響力を持つのは誰かを確認します
  3. ドキュメントの確認：過去のプロジェクト、契約書を確認します
  4. インタビュー：「ほかに誰に話を聞くべきですか？」と尋ねます
  5. プロセス分析：各ステップを担当する人を確認します

権力／関心度グリッド

マトリックス
High Power │ Keep Satisfied │ Manage Closely │
           │    (Latents)   │  (Key Players) │
           ├────────────────┼────────────────┤
Low Power  │    Monitor     │ Keep Informed  │
           │   (Apathetics) │  (Defenders)   │
           └────────────────┴────────────────┘
             Low Interest    High Interest
象限ごとの戦略

密接に管理する（権力：高、関心度：高）：

  • 定期的な1対1のミーティング
  • 重要な意思決定に参加してもらう
  • 詳細な最新情報を提供する
  • 意見と承認を求める
  • 例：プロジェクトスポンサー、ビジネスオーナー、CTO

満足度を維持する（権力：高、関心度：低）：

  • 定期的に概要レベルの最新情報を提供する
  • エグゼクティブサマリーを提供する
  • 重要な意思決定のみに参加してもらう
  • 詳細を伝えすぎない
  • 例：CFO、CEO、取締役会メンバー

情報を提供する（権力：低、関心度：高）：

  • 定期的に最新情報を提供する（メール、ニュースレター）
  • UAT やフィードバックに参加してもらう
  • 懸念に耳を傾ける
  • 詳細な要件を把握するうえで重要な情報源となる
  • 例：エンドユーザー、チームリーダー

状況を監視する（権力：低、関心度：低）：

  • 最小限の労力にとどめる
  • 一般的な連絡のみ行う
  • 関心度や権力の変化を把握する
  • 例：直接関与していない外部ベンダー

RACI マトリックス

定義
  • R - 実行責任者：作業を実行します
  • A - 説明責任者：承認または最終承認を行います（各タスクにつき1人のみ）
  • C - 協議先：意見を提供します（双方向のコミュニケーション）
  • I - 報告先：進捗を共有します（一方向のコミュニケーション）
テンプレート
アクティビティPMBA開発リードビジネスオーナーエンドユーザー
要件収集ARCCC
BRD の承認IRIAI
技術設計ICR/AII
開発IIAII
UAT の計画CRCAC
UAT の実施ICICR
本番稼働の承認CICAI
ルール
  • 各タスクの説明責任者は必ず1人にします
  • 各タスクに少なくとも1人の実行責任者を割り当てます
  • 協議先を増やしすぎないようにします（会議疲れを防ぐため）
  • ステークホルダーと内容を確認します

ステークホルダー登録簿

テンプレート
ID名前役割部門権力関心度関与度コミュニケーションの希望備考
SH-001John Smith営業担当副社長営業高高推進者メール、週次1対1主要スポンサー
SH-002Sarah LeeサポートマネージャーCS中高支持的Slack、スプリントデモUAT リードの適任者
SH-003Mike ChenCFO財務高低中立月次エグゼクティブサマリー予算の承認
SH-004Lisa Wongエンドユーザーオペレーション低高支援者チームミーティング主題の専門家
SH-005Tom BrownIT ディレクターIT高中反対的1対1のミーティングセキュリティ上の懸念
関与レベル
  • 推進者：プロジェクトを積極的に推進します
  • 支持的：前向きで、求められれば協力します
  • 中立：支持も反対もしません
  • 反対的：懐疑的で、反対する可能性があります
  • 敵対的：プロジェクトを積極的に妨害します
エンゲージメント戦略

推進者 → 推進者：支援を活用し、コミュニケーションに参加してもらいます 支援的 → 推進者：貢献を認め、主体的に取り組んでもらいます 中立 → 支援的：メリットを伝え、懸念に対処します 抵抗的 → 中立：懸念を理解し、意思決定に参加してもらいます 敵対的 → 抵抗的：1対1で話し合い、共通点を見つけ、必要に応じてエスカレーションします

コミュニケーション計画

テンプレート
ステークホルダーグループ必要な情報頻度チャネル担当者
経営陣プロジェクトの状況、リスク、意思決定事項毎月メールレポート、会議PM
事業オーナー詳細な進捗、阻害要因毎週状況報告会議PM
開発チーム要件、優先順位毎日朝会、SlackBA
エンドユーザートレーニング、スケジュール、変更点必要に応じてメール、TeamsBA
コミュニケーションチャネル
  • 公式：メール、プレゼンテーション、レポート
  • 非公式：Slack/Teams、短時間の電話
  • 会議：1対1の面談、チーム会議、ワークショップ
  • ドキュメント：Confluence、Notion、SharePoint

ステークホルダーエンゲージメントのヒント

関係の構築
  1. 相手の目標と課題を理解します
  2. 相手の言葉で話します（技術的な視点か、ビジネスの視点か）
  3. 迅速かつ確実に対応します
  4. 約束を果たします
  5. 相手の貢献を認めます
抵抗への対処
  1. （返答するためではなく）理解するために耳を傾けます
  2. 深掘りする質問をします
  3. 抵抗の根本原因を突き止めます
  4. 懸念に直接対処します
  5. 双方にメリットのある解決策を見つけます
  6. 必要に応じてエスカレーションします
期待値の管理
  1. スコープとスケジュールを明確にします
  2. リスクを早期に伝えます
  3. 約束は控えめにし、成果は期待を上回るようにします
  4. 決定事項と合意事項を記録します
  5. 定期的に状況を報告します

ドメイン固有のステークホルダー

Eコマース
  • プロダクトマネージャー、マーチャンダイジング担当者
  • マーケティング（プロモーション、キャンペーン）
  • カスタマーサービス
  • フルフィルメント／倉庫
  • 決済／財務
  • IT／セキュリティ
ERP
  • 財務（CFO、コントローラー、会計担当者）
  • 人事（CHRO、給与担当者）
  • サプライチェーン（調達、物流）
  • 製造（工場長）
  • IT（CIO、エンタープライズアーキテクト）
  • コンプライアンス／監査
CRM
  • 営業（営業担当副社長、営業マネージャー、営業担当者）
  • マーケティング（CMO、マーケティング運用担当者）
  • カスタマーサービス（サポートマネージャー）
  • IT（CRM管理者）
  • 経営陣（CEO、収益部門の責任者）
CDP
  • マーケティング（CMO、キャンペーンマネージャー）
  • データ／分析（最高データ責任者）
  • IT／エンジニアリング（データエンジニア）
  • プライバシー／法務（DPO、法律顧問）
  • カスタマーエクスペリエンス

ベストプラクティス

✅ 推奨事項：

  • ステークホルダー分析を定期的に更新します
  • ステークホルダーに合わせてコミュニケーションのスタイルを調整します
  • ステークホルダーとのやり取りを記録します
  • ステークホルダーの貢献を称えます
  • 対応が難しいステークホルダーに先回りして対応します

❌ 避けるべきこと：

  • ステークホルダーのニーズを決めつけます
  • 「対応が難しい」ステークホルダーを無視します
  • 全員に過剰なコミュニケーションを行います
  • フィードバックへの対応を完了し忘れます
  • 悪い知らせを突然ステークホルダーに伝えます

ツール

  • Lark/Notion：ステークホルダー登録簿データベース
  • Figma/Miro：影響力／関心度グリッドの可視化
  • Lark Meetings：会議メモとアクションアイテム
  • Email/Slack：定期的なコミュニケーション

次のステップ

ステークホルダー分析の後：

  1. コミュニケーション計画を作成します
  2. 要件抽出のスケジュールを計画します
  3. 変更管理のニーズを特定します
  4. 要件ワークショップの準備をします

参考資料

  • PMBOK Guide - ステークホルダー管理
  • BABOK Guide - ステークホルダー分析
  • Influence Without Authority（Cohen & Bradford）

コメント

Markdown 対応