フレームワーク活用ガイドひとことで言うと#
プロジェクトに関わる全関係者を影響力（Power）と関心度（Interest）の2軸でマッピングし、対応の優先度を色の濃さで示す手法。限られたコミュニケーションリソースを「誰に・どの程度・どの頻度で」配分するかを決める基盤になる。
押さえておきたい用語#
- 影響力（Power）
- その人がプロジェクトの意思決定に与える実質的な力。予算承認権、人事権、技術的な拒否権などが該当する。
- 関心度（Interest）
- その人がプロジェクトの成果や進捗に対して持つ注目の度合い。日常業務に直接影響するほど関心度は高い。
- キープレイヤー（Key Player）
- 影響力も関心度も高い関係者。プロジェクトの成否を左右するため、最優先で密にコミュニケーションを取る対象。
- コンテキストセッター（Context Setter）
- 影響力は高いが関心度が低い関係者。普段は静かだが、不意に介入すると大きな方向転換を引き起こす存在。
ステークホルダーヒートマップの全体像#
こんな悩みに効く#
- 関係者が多すぎて全員に同じ密度で対応しようとしてリソースが枯渇する
- キーパーソンを見落とし、後からちゃぶ台返しを食らう
- 「この人にはどの程度の情報を、どの頻度で共有すべきか」がチーム内で統一されていない
- プロジェクト途中で「聞いてない」と言い出す関係者が出てくる
基本の使い方#
プロジェクトに関わる、または影響を受ける人物・部門を漏れなくリストアップする。
- 直接関わるメンバーだけでなく、間接的に影響を受ける部門も含める
- 社内だけでなく、外部ベンダー、クライアント、規制当局なども対象
- 「この人を見落とすと後で困る」という観点でチームでブレストする
各関係者について、影響力と関心度をそれぞれ1〜5のスコアで評価する。
- 影響力の評価基準: 予算承認権、人事権、技術的決定権、組織内の発言力
- 関心度の評価基準: プロジェクト成果が日常業務に与える影響度、過去の関与頻度
- 評価は複数人で行い、認識のズレがあれば議論して合わせる
- 影響力は「役職」だけで決まらない。非公式な影響力（社長の信頼が厚い社員など）も考慮する
4象限それぞれに対応戦略を設定する。
- 密に管理（高影響力×高関心）: 週次1on1、意思決定への積極的な参画依頼
- 満足させ続ける（高影響力×低関心）: 月次サマリーで安心感を提供。不意打ちを避ける
- 情報を提供する（低影響力×高関心）: ニュースレターやSlackチャンネルで透明性を確保
- 最低限の対応（低影響力×低関心）: 必要時のみ連絡。リソースを割きすぎない
象限ごとの方針を具体的な行動に変換する。
- 各関係者に連絡手段・頻度・共有情報のレベルを設定する
- コミュニケーション計画をドキュメント化し、チーム全員がアクセスできるようにする
- フェーズの切り替わり時にマップを見直す（キックオフ時と実行フェーズでは位置が変わる）
具体例#
従業員300名の製造業が基幹システムを刷新するプロジェクトを発足。PMが最初にリストアップした関係者は8名だった。
ヒートマップを描いたところ、チームから「製造部の現場リーダー3名が漏れている」と指摘された。彼らは役職は低い（課長補佐）が、現行システムのヘビーユーザーで事実上の業務プロセス決定権を持っていた。
マッピング結果:
| 関係者 | 影響力 | 関心度 | 象限 |
|---|---|---|---|
| 経営企画部長 | 5 | 4 | 密に管理 |
| 情報システム部長 | 5 | 5 | 密に管理 |
| 製造部長 | 4 | 2 | 満足させ続ける |
| 現場リーダー3名 | 3 | 5 | 情報を提供する |
| 経理部 | 3 | 3 | 情報を提供する |
| 外部SIer | 2 | 5 | 情報を提供する |
当初の計画では現場リーダーへの説明会は「リリース前に1回」の予定だったが、ヒートマップの結果を受けて月次の意見交換会に変更。現場の業務フローに合わないUI設計を3回修正でき、リリース後のクレーム件数は類似プロジェクトの平均と比べて70%少なかった。
IT企業の新規事業チーム5名が、社内承認を得て新サービスの開発を開始した。事業部長（承認者）は「任せた」と言って以降、進捗にほとんど関心を示さなかった。
3か月後のデモで事業部長が突然「ターゲット市場が違う。エンタープライズ向けに変更すべき」と発言。チームは方向転換を余儀なくされ、6週間分の開発が無駄になった。
振り返りでヒートマップを描き直し、事業部長が「高影響力×低関心」＝コンテキストセッターであることを認識した。対策として以下を導入した。
- 月1回の15分ブリーフィングを事業部長のカレンダーに固定
- ブリーフィングでは「方向性に変更はないか」を必ず確認
- 大きな方向判断の前にはドキュメントで事前共有し、沈黙＝承認のルールを合意
以降、不意のちゃぶ台返しはゼロになった。コンテキストセッターへの「定期的な軽いタッチ」が、プロジェクトの安定に直結した好例。
日本本社とアメリカ・シンガポール拠点を横断するERPロールアウトプロジェクト。関係者が42名に膨れ上がり、PMが「誰に何を伝えるべきか」を把握しきれなくなっていた。
ヒートマップを地域別に色分けして作成:
| 象限 | 日本 | アメリカ | シンガポール |
|---|---|---|---|
| 密に管理 | CIO、経理部長 | VP of Ops | Regional Director |
| 満足させ続ける | 社長 | CFO | — |
| 情報を提供する | 現場リーダー5名 | IT Lead | IT Lead |
| 最低限 | 総務、広報 | HR | Admin |
このマップからコミュニケーション計画を導出:
- 密に管理の6名: 週次のグローバルSteeringミーティング（時差を考慮し日本時間21時）
- 満足させ続けるの2名: 月次エグゼクティブサマリー（A4で1枚）
- 情報を提供するの9名: 隔週のニュースレター＋Slackチャンネル
- 最低限の残り: 四半期レポートのみ
コミュニケーションコストが整理され、PMの週あたりの報告作成時間が12時間 → 5時間に削減。「聞いてない」クレームもゼロになった。
やりがちな失敗パターン#
- 役職だけで影響力を判断する — 組織図上は中間管理職でも、CEOの右腕のような存在は実質的な影響力が高い。非公式な権力構造を見落とさない
- コンテキストセッターを放置する — 「関心がないなら放っておこう」は危険。影響力が高い人が突然動いたときのインパクトは甚大。定期的な軽いタッチで先手を打つ
- マッピングを一度きりで終える — プロジェクトのフェーズが変わると関心度は動く。要件定義時は無関心だった運用チームが、移行フェーズでは最重要ステークホルダーになる
- 全員を「密に管理」に入れようとする — 全関係者に同じ密度で対応するのは不可能。メリハリをつけることがこのフレームワークの本質
まとめ#
ステークホルダーヒートマップは、関係者を影響力と関心度の2軸で分類し、限られたコミュニケーションリソースの配分を最適化するツールである。最も注意すべきは「高影響力×低関心」のコンテキストセッターで、放置すると不意のちゃぶ台返しを招く。マップはプロジェクトのフェーズに応じて更新し、「誰に・何を・どの頻度で」を常に最新に保つことが運用の鍵である。