ステークホルダー整理の方法|権限・影響・関心から相談先を決める

誰に相談すべきか分からず、会議で初めて反対意見が出る。肩書きだけで参加者を選ぶと、実際の業務や運用への影響が抜けることがあります。ステークホルダー整理では、関係者の権限・受ける影響・関心を確認し、必要な関与方法を決めます。人物を「味方・敵」に分類する表ではなく、合意に必要な条件を見つける表として使いましょう。
関係者を業務の前後から探す
発注者や承認者だけでなく、利用者、入力情報を渡す部門、結果を受け取る部門、運用・問い合わせ担当までたどります。外部サービスや委託先が関係するなら、その窓口と契約上の範囲を確認します。既存の体制図は出発点ですが、最新の実務と一致するとは限りません。部門名や役職だけでなく、「どの変更の影響を受けるか」を記録します。代理窓口と正式な判断者も分けてください。
権限・影響・関心を分けて書く
下表は、社内申請フロー変更の説明用です。
| 関係者 | 業務上の権限 | 受ける影響・関心 | 確認する条件 |
|---|---|---|---|
| 業務責任者 | 業務ルールの承認 | 承認漏れを防ぐこと | 例外時の承認経路 |
| 日常の申請者 | 最終承認権限はない | 入力の負担、差し戻し | 実際の申請手順と例外 |
| 運用窓口 | 問い合わせ対応の調整 | 初期問い合わせの増加 | 案内、対応範囲、稼働枠 |
| セキュリティ担当 | 所定の確認権限 | 権限・情報管理 | 必須確認項目と証跡 |
役職が高いほど影響が大きいとは限りません。承認権限がなくても毎日使う人の負担は大きい場合があります。本人に確認していない関心は、断定せず「仮説・確認待ち」とします。
マップから関与方法へ落とす
影響力と関心の二軸で配置すると、関与方法を考える手掛かりになります。ただし高低の境界は組織と案件で変わり、固定の採点基準ではありません。影響を強く受ける利用者には具体的な手順を確認してもらい、判断権限を持つ人には選択肢と条件を提示するなど、必要な参加を設計します。関心が低く見えても必須の専門確認は省略できません。マップ上の位置だけで共有対象から外さず、法令・契約・組織ルールの通知義務も確認します。配置は現時点の理解であり、判断の代わりではありません。
反対意見を人物評価でなく条件へ変える
「協力的でない」ではなく「現行運用では問い合わせ対応の枠が足りない」など、確認可能な懸念へ書き換えます。反対の理由に改善すべき条件が含まれているかもしれません。懸念、確認した根拠、未確認部分、必要な判断を区別します。本人に聞いた内容と別の人の推測を混ぜず、共有範囲も適切に管理します。意見が割れる場合は、決定権限と必要な材料を確認します。関係者全員を説得することだけを目標にせず、正式な判断の過程を整えます。
計画変更と担当交代で更新する
対象部門の追加、リリース範囲の変更、担当交代のときは見直します。関係者一覧に更新日と確認担当を付け、古い連絡先が正本として残らないようにします。個人の性格、人事評価、健康状態などを記載する必要はありません。業務上の権限・関与条件に絞り、閲覧権限のない人へ非公開情報を渡さないでください。一覧ができたら、各関係者に何を相談し、どの時点で判断が必要かを連絡計画へ落とします。関係者の数を増やすことより、必要な声と判断経路を見落とさないことが目的です。
次に確認したい実務ガイド
PMO実務テンプレート・確認表の一覧から、目的に合う記事を探せます。
参考情報とこの記事の位置づけ
関係者と関与方法を整理するマッピングの考え方を確認しました。個人の性格評価ではなく、業務上の確認表を提案しています。 Atlassian:Stakeholder Mapping(確認日:2026年10月11日)。記入例・確認表は当サイトが説明用に作成したもので、実在の案件・実績ではありません。
エンジニアとのコミュニケーションも必要な作業に合わせて参照してください。
アイキャッチ写真:Headway / Unsplash。職場の実写ではなくイメージ写真です。
