stakeholder-discovery

概要

ステークホルダーの特定とは、必要な合意と安全性を確保して先に進めるよう、「組織のエコシステム」を把握するプロセスです。意見を持つ人と「拒否権」を持つ人を区別し、重要な関係を早期に築きます。

絶対原則

検証済みのステークホルダーマップなしに成果物を出してはなりません 終盤で「拒否」されるのは、特定プロセスの失敗です。権力と利害を早期に把握することが、円滑なローンチと組織的な障害の分かれ目になります。

状態遷移図

digraph stakeholder_discovery_flow {
    "Start" [shape=doublecircle];
    "Step 1: Identify & Categorize Stakeholders" [shape=box];
    "Step 2: Power/Interest Analysis" [shape=box];
    "Step 3: Motivation Audit (Mutual Purpose)" [shape=box];
    "Gate: Map Validation" [shape=diamond];
    "Step 4: Establish Engagement Cadence" [shape=box];
    "Done: Stakeholder Context Established" [shape=doublecircle];

    "Start" -> "Step 1: Identify & Categorize Stakeholders";
    "Step 1: Identify & Categorize Stakeholders" -> "Step 2: Power/Interest Analysis";
    "Step 2: Power/Interest Analysis" -> "Step 3: Motivation Audit (Mutual Purpose)";
    "Step 3: Motivation Audit (Mutual Purpose)" -> "Gate: Map Validation";
    "Gate: Map Validation" -> "Step 4: Establish Engagement Cadence" [label="valid"];
    "Gate: Map Validation" -> "Step 1: Identify & Categorize Stakeholders" [label="invalid"];
    "Step 4: Establish Engagement Cadence" -> "Done: Stakeholder Context Established";
}

このスキルを使う場面

• 部門横断プロジェクトの開始時。
• 新しい役職や組織に加わったとき（「2つ下と2つ上」を把握します）。
• 複数の部門（財務、法務、人事など）の承認が必要なプロジェクト。
• 「横方向のマネジメント」が不足している、または予期しない障害が現れていると感じたとき。

このスキルを使わない場面

• 他者に影響せず、外部承認も不要な独立したタスク。
• すでに足並みが揃っている単一チーム内の、小規模で定型的なタスク。

コアプロセス

ステップ 1：ステークホルダーの特定と分類

• 「真の」ステークホルダーを特定する： 意見を述べる人と、製品やプロジェクトのローンチを阻止できる拒否権を持つ人を区別します。（出典：SVPG／Cagan）
• 「2つ下と2つ上」を把握する： 自分の2階層下と2階層上にいる人と役割を特定します。その人たちの動機を理解します。（出典：Johnson, Scaling People）
• 横方向の関係者を特定する： 障害を生み出したり防いだりする可能性のある同僚や他のリーダーを積極的に探します。（出典：Johnson, Scaling People）

ステップ 2：権力／関心度の分析

• 権力／関心度グリッドに配置する：
  • 権力が高く、関心度も高い（主要な関係者）： 密接に連携し、深く関与してもらいます。
  • 権力が高く、関心度が低い（満足度を維持）： 過剰な詳細を避けつつ、相談し、満足してもらいます。
  • 権力が低く、関心度が高い（情報を共有）： 関与する意欲はあるものの権限がないため、定期的に最新情報を伝えます。
  • 権力が低く、関心度も低い（状況を監視）： 主に状況の変化を監視し、最小限の労力にとどめます。（出典：SVPG／Cagan）
• 状況を把握する： 「状況が常に重要である」ことを忘れないでください。各ステークホルダーの経緯や現在のプレッシャーを理解し、すばやく適応します。（出典：Zhuo, The Making of a Manager）

ステップ 3：動機の確認（相互の目的）

• 相互の目的を特定する： 共通の目標を見つけます。「相互の目的は、対話の前提条件です。」（出典：Grenny, Crucial Conversations）
• 「ストレスと緊張」を理解する： システムの他の部門の立場に立って考えます。その人たちの性格や現在のプレッシャーはどのようなものでしょうか。（出典：Johnson, Scaling People）
• 合意形成のための CRIB：
  • Commit to seek Mutual Purpose（相互の目的を見つけることに取り組む）。
  • Recognize the purpose behind their strategy（相手の戦略の背景にある目的を認識する）。
  • Invent a Mutual Purpose if one isn't obvious（明確な目的が見当たらない場合は、相互の目的を考案する）。
  • Brainstorm new strategies together（新しい戦略を一緒にブレインストーミングする）。（出典：Grenny, Crucial Conversations）

ステップ 4：関与の頻度を確立する

• 1 対 1 のミーティングを活用する： 1 対 1 のミーティングを、情報交換とステークホルダーを適切な方向へ「促す」ための主な場として活用します。（出典：Grove, High Output Management）
• スタッフミーティングを観察する： 主要なステークホルダーのミーティングに参加し、そのチームの目標や、最善の協力方法を理解します。（出典：Johnson, Scaling People）
• マネジメントのレバレッジ： 多くの人に影響を与える活動や、ステークホルダーの長期的な成果を改善する活動など、レバレッジの高い取り組みに集中します。（出典：Grove, High Output Management）

他スキルの呼び出し

必須のサブスキル：problem-framing — 解決しようとしている問題が、ステークホルダーにとって実際に重要なものかを確認します。 推奨サブスキル：using-skills — ステークホルダーとの関わりに規律を保ちます。 推奨サブスキル：rapport-builder — Scaling People で述べられている非公式なつながりを築きます。

合理化テーブル

考え	現実
「草案ができてから関係者と話します。」	それでは遅すぎます。早期に関与してもらうことで、制約が「拒否権の行使」に発展する前に把握できます。
「法務／財務は単なる『チェック項目』にすぎません。」	拒否権を持つなら、重要な関係者です。後回しにすると、摩擦が生じます。
「CEO が何を望んでいるかは、すでに分かっています。」	リーダーシップの目標についての思い込みでは、「二つ上と二つ下」の状況を見落としがちです。
「会議は時間の無駄なので、メールで済ませます。」	会議はマネジメントの手段です。1 対 1 の面談なら、メールではできない「後押し」ができます。

危険信号

次のように考えているなら、いったん立ち止まってください。近道をしようとしています。

• 「パイロットの開始後に［部署名］のことを考えます。」→ 拒否権を持つ可能性のある人を無視しています。
• 「技術的な詳細を理解していないので、関与してもらう必要はありません。」→ 影響力があるからといって、技術的な知識があるとは限りません。
• 「きっと問題ないはずです。」→ 相手の「相互利益」を、自分の考えで置き換えています。

診断チェックリスト

• 「拒否権」を持つ人を全員特定し、関与してもらっていますか？
• 重要な関係者それぞれについて、明確な「相互利益」を確立していますか？
• 影響力と関心がともに高い関係者全員との 1 対 1 の面談、または定期的な同期ミーティングを予定していますか？
• 「二つ上」と「二つ下」の状況を把握していますか？
• マップには直属の報告系統だけでなく、部門横断的なパートナーも含まれていますか？

出典

• Johnson, Scaling People, 第 4 章（チーム開発）、第 5 章（マネジメント上の関係）
• Grove, High Output Management, 第 3 章（レバレッジ）、第 4 章（会議）
• Grenny, Crucial Conversations, 第 5 章（相互利益／CRIB）
• Zhuo, The Making of a Manager, 第 1 章（状況）、第 8 章（上司との関係管理）
• SVPG の記事：「関係者のマネジメント」と「関係者の特定」