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

関係者を整理|相談先を見極める:権限・影響・関心で考える

誰に相談すべきか分からず、会議で初めて反対意見が出る。肩書きだけで参加者を選ぶと、実際の業務や運用への影響が抜けることがあります。ステークホルダー整理では、関係者の権限・受ける影響・関心を確認し、必要な関与方法を決めます。人物を「味方・敵」に分類する表ではなく、合意に必要な条件を見つける表として使いましょう。

関係者を業務の前後から探す

発注者や承認者だけでなく、利用者、入力情報を渡す部門、結果を受け取る部門、運用・問い合わせ担当までたどります。外部サービスや委託先が関係するなら、その窓口と契約上の範囲を確認します。既存の体制図は出発点ですが、最新の実務と一致するとは限りません。部門名や役職だけでなく、「どの変更の影響を受けるか」を記録します。代理窓口と正式な判断者も分けてください。

権限・影響・関心を分けて書く

下表は、社内申請フロー変更の説明用です。

関係者 業務上の権限 受ける影響・関心 確認する条件
業務責任者 業務ルールの承認 承認漏れを防ぐこと 例外時の承認経路
日常の申請者 最終承認権限はない 入力の負担、差し戻し 実際の申請手順と例外
運用窓口 問い合わせ対応の調整 初期問い合わせの増加 案内、対応範囲、稼働枠
セキュリティ担当 所定の確認権限 権限・情報管理 必須確認項目と証跡
小さい画面では表を横にスクロールできます。

役職が高いほど影響が大きいとは限りません。承認権限がなくても毎日使う人の負担は大きい場合があります。本人に確認していない関心は、断定せず「仮説・確認待ち」とします。

マップから関与方法へ落とす

影響力と関心の二軸で配置すると、関与方法を考える手掛かりになります。ただし高低の境界は組織と案件で変わり、固定の採点基準ではありません。影響を強く受ける利用者には具体的な手順を確認してもらい、判断権限を持つ人には選択肢と条件を提示するなど、必要な参加を設計します。関心が低く見えても必須の専門確認は省略できません。マップ上の位置だけで共有対象から外さず、法令・契約・組織ルールの通知義務も確認します。配置は現時点の理解であり、判断の代わりではありません。

反対意見を人物評価でなく条件へ変える

「協力的でない」ではなく「現行運用では問い合わせ対応の枠が足りない」など、確認可能な懸念へ書き換えます。反対の理由に改善すべき条件が含まれているかもしれません。懸念、確認した根拠、未確認部分、必要な判断を区別します。本人に聞いた内容と別の人の推測を混ぜず、共有範囲も適切に管理します。意見が割れる場合は、決定権限と必要な材料を確認します。関係者全員を説得することだけを目標にせず、正式な判断の過程を整えます。

計画変更と担当交代で更新する

対象部門の追加、リリース範囲の変更、担当交代のときは見直します。関係者一覧に更新日と確認担当を付け、古い連絡先が正本として残らないようにします。個人の性格、人事評価、健康状態などを記載する必要はありません。業務上の権限・関与条件に絞り、閲覧権限のない人へ非公開情報を渡さないでください。一覧ができたら、各関係者に何を相談し、どの時点で判断が必要かを連絡計画へ落とします。関係者の数を増やすことより、必要な声と判断経路を見落とさないことが目的です。

次に確認したい実務ガイド

PMO実務テンプレート・確認表の一覧から、目的に合う記事を探せます。

参考情報とこの記事の位置づけ

関係者と関与方法を整理するマッピングの考え方を確認しました。個人の性格評価ではなく、業務上の確認表を提案しています。 Atlassian:Stakeholder Mapping(確認日:2026年10月11日)。記入例・確認表は当サイトが説明用に作成したもので、実在の案件・実績ではありません。

エンジニアとのコミュニケーションも必要な作業に合わせて参照してください。

アイキャッチ写真:Headway / Unsplash。職場の実写ではなくイメージ写真です。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!