stakeholder-influence-mapper

ステークホルダー影響力マッパースキル

プロダクトの取り組みを、構造化された影響力プランに変換します。誰との合意が必要か、どの順番で進めるか、それぞれの相手にどのような言葉で何を伝えるかを明確にします。

必要な入力情報

以下の情報が提供されていない場合は、ユーザーに尋ねてください。

• 取り組みの説明（何をしたいのか、なぜそうしたいのか）
• 主要なステークホルダーの一覧（名前、役割、取り組みとの関係）
• 期限の制約（いつまでに決定が必要か）
• 既知の反対意見や社内政治の背景（すでに把握していること）

プロセス

1. 以下を含むステークホルダーマップを作成します。役割、主な懸念事項、意思決定権限（阻止者／影響者／情報共有対象）、現在の立場（支持／中立／反対／不明）
2. 会話のクリティカルパスを特定します。誰を先に説得する必要があるかを明確にします
3. 各ステークホルダーに対して、こちらの要望ではなく、相手の懸念事項から話を始めます
4. 各ステークホルダーから想定される反対意見を1つ挙げ、それに対する回答を準備します
5. 他のステークホルダーとの合意が得られるまで、接触すべきでない相手を明示します
6. 検証 — すべての「阻止者」に具体的な方策があること（単に「会話する」だけではないこと）、および順序に社内政治上の依存関係が反映されていることを確認します

出力形式

ステークホルダーマップ：[取り組み名]

ステークホルダー	役割	主な懸念事項	権限	現在の立場
[名前]	[役割]	[懸念事項]	[種類]	[立場]

推奨する会話の順序

1. まず[名前] — [その人が他の人との合意を可能にする理由]
2. 次に[名前] — [最初の相手]との合意が得られたら [続ける...]

ステークホルダー別の話すポイント

[ステークホルダー名]

まず伝えること： [相手の機能への要望ではなく、相手の懸念事項] こちらの要望： [相手に求める具体的なことを1つ] 想定される反対意見： [相手が異議を唱えそうな点] 準備しておく回答： [防御的にならずにどう対応するか] 成功の状態： [相手との合意がどのような状態か]

メモ

• すべてのステークホルダーに同じメッセージを送らず、毎回内容を調整します
• エンジニアリングリードには、まず技術的な実現可能性を認めることが重要です
• 財務部門のステークホルダーには、何よりも先にROIの観点から説明します
• 法務／コンプライアンス部門のステークホルダーには、リスク軽減策を最初に示します

品質チェック

• すべての阻止者に具体的な方策がある（単に「話をする」だけではない）
• 会話の順序に社内政治上の依存関係が反映されている
• 各ステークホルダーに伝える内容が、こちらの議題ではなく相手の懸念事項から始まっている
• 「Xとの合意が得られるまで接触しない」という注意点を少なくとも1つ検討している
• 各ステークホルダーへの要望が、曖昧な「支援」ではなく、具体的なこと1つになっている

アンチパターン

• 影響力の大きい阻止者には、そのスポンサーとの合意を得る前に接触しないでください。接触の順序が結果を左右します
• こちらの議題から始まる話すポイントを作らないでください。必ずステークホルダーが示した懸念事項から始めます
• すべてのステークホルダーを同じ重要度で扱わないでください。意思決定者と主要な影響者に重点を置きます
• 「Xとの合意が得られるまで接触しない」という注意点を省かないでください。順序を誤ると、機会を永久に失うことがあります
• 組織図上の立場だけを基にマップを作らないでください。影響力は正式な権限の範囲外にあることも少なくありません