ステークホルダー管理の実務手順：特定・分析・エンゲージメント計画・コミュニケーション運用

誰を数え忘れると、あとで一番高くつくか

情報システム部門、法務、購買、内部監査。このどれかが終盤に登場して要件を追加してきた経験は、たいていのPMにあります。ステークホルダー管理が形になっていない現場は、関係者一覧をExcelで作ったところで止まり、キーパーソンには挨拶したがその後は何もしていない、という状態のままリリース直前を迎えます。

手順は、特定、分類、態度の評価、エンゲージメント計画、コミュニケーション計画、変化への追従の順に進みます。この順序には意味があります。特定で漏れた相手は、以降のどの工程でも拾えないからです。分類の精度をいくら上げても、リストに載っていない部門は象限のどこにも現れません。

並びはPMBOKガイドの体系に沿っています。ステークホルダーは独立したパフォーマンス領域として位置づけられており、2025年11月に英語版が公開された第8版でも、特定、エンゲージメントの計画、コミュニケーションの計画、エンゲージメントとコミュニケーションのマネジメント、そして両者の監視という営みが、ライフサイクル全体にまたがるものとして整理されています。単発の作業ではなく、プロジェクト全期間にわたって続くものだという扱いです。

手順1：ステークホルダーを特定する（漏れやすい相手の具体名）

ステークホルダーとは、プロジェクトに影響を与える、あるいはプロジェクトから影響を受ける個人や組織のことです。定義が広いため、「うちの顧客とうちの開発チーム」で止めると必ず漏れます。特定の網羅性が以降すべての工程の質を決めるので、ここに時間をかける価値があります。

典型的に漏れやすい相手を、具体的に挙げます。第1に情報システム部門です。業務部門主導で始まったプロジェクトほど、ネットワーク、認証基盤、既存システムとの接続、社内標準への適合といった論点で終盤に呼ばれ、そこで初めて要件が増えます。第2に法務部門です。契約書のレビュー、個人情報の取り扱い、利用規約の改定などは、着手が遅れるとそのままリリース遅延に直結します。第3に購買・調達部門です。ベンダー選定や発注の手続き、支払条件には社内ルールがあり、想定より長い期間を要します。第4に内部監査部門で、統制上の要件を後出しされると設計のやり直しになります。

さらに漏れやすいのが、現場のキーユーザーです。役職はないが業務を最もよく知っていて、周囲の同僚が意見を聞きに行く人物が、どの職場にもいます。この層が反対に回ると、システムが完成しても使われません。管理職の合意だけを取って現場を素通りする進め方が、この失敗を生みます。

組織の外にも目を向けます。規制当局や業界団体、監督官庁への届出が必要な領域であれば、その手続きと審査期間はプロジェクトの制約そのものです。委託先やベンダーも受け身の供給者ではなく、能動的なステークホルダーとして扱う必要があります。加えて、退任や異動が予定されている役員のような「近いうちにいなくなる人」と「これから来る人」も忘れてはいけません。前任者と合意した内容が後任に引き継がれていない、という事態は頻繁に起こります。

洗い出しの実務としては、組織図をなぞるだけでは足りません。業務プロセスの流れに沿って「この工程の承認者は誰か」と辿る、過去の類似プロジェクトの関係者リストを参照する、すでに特定した相手に「ほかに話を通しておくべき人はいますか」と直接尋ねる、という3つを組み合わせると精度が上がります。

ステークホルダー登録簿に何を書くか

特定した結果をまとめる文書が、ステークホルダー登録簿です。記録する内容は大きく3つに分けられます。第1が識別情報で、氏名、所属と役職、所在地や連絡先、プロジェクト上の役割です。第2が評価情報で、主要な要求事項、期待、プロジェクトの成果に影響を及ぼしうる度合い、そしてライフサイクルのどの段階で最も影響力を持つかです。第3が分類で、社内か社外か、影響度と関心度の位置づけ、影響の向きなどを記します。

注意が必要なのは、この文書が機微な情報を含む点です。ある相手について「反対的」「影響力は小さい」といった評価を書く以上、本人に見られると人間関係を損ないます。実務では、登録簿はプロジェクトマネージャーと限られた主要メンバーだけが参照する非公開文書として扱い、共有範囲を明示的に決めておくのが安全です。

手順2：分類して優先順位をつける（分類モデルの出所）

全員に同じ密度で接することはできません。そこで、洗い出した相手を分類し、関与の濃さを変えます。最も広く使われるのが、権力（パワー）と関心度（インタレスト）の2軸で四象限に配置する、いわゆる権力／関心度グリッドです。

この考え方の出所を整理しておきます。ステークホルダーという概念自体は、R・エドワード・フリーマンが1984年の著書『Strategic Management: A Stakeholder Approach』で広めたものです。権力と関心度の2軸による分類はオーブリー・メンデロウが1991年の論文で提示したものとされ、この可視化を広めたのはジョンソンとスコールズの『Exploring Corporate Strategy』第2版（1993年）です。プロジェクトマネジメント固有の発明ではなく、経営戦略から持ち込まれた道具だと知っておくと、使い方を誤りません。

PMBOKガイドの第5版では、分類モデルとして4つが挙げられていました。権力／関心度グリッド、権力／影響力グリッド、影響力／インパクトグリッド、そしてサリエンス（顕著性）モデルです。前の3つは2つの属性で分類する点で似ており、軸の名前が違うだけとも言えます。サリエンスモデルだけは性格が異なり、権力、正当性、緊急性の3属性で評価します。ミッチェル、アグル、ウッドが1997年に『Academy of Management Review』誌で発表した理論に由来します。

使い分けの目安はこうです。関係者が十数名程度で力関係が単純なら、権力／関心度グリッドで十分です。相手が多く、「声は大きいが本来その件に口を出す立場ではない人」と「静かだが正当な権限を持つ人」が混在するなら、正当性の軸を持つサリエンスモデルのほうが実態を捉えられます。いずれにせよ軸の意味を言語化しておかないと、評価が人によってばらつきます。

四象限への対応方針は一般に次のように整理されます。権力が高く関心も高い相手は密接に関与させる。権力は高いが関心が低い相手は、満足した状態を保つよう必要な情報を絞って届ける。権力は低いが関心が高い相手には、十分な情報提供を続ける。どちらも低い相手は最小限の監視にとどめる。ただしこれは出発点です。関心度は固定値ではなく、働きかけで動きます。

手順3：エンゲージメント評価マトリクス（現状Cと望ましい状態D）

分類の次は、相手一人ひとりについて「いまどういう態度か」と「どういう態度になってほしいか」を定義します。ここで使うのが、ステークホルダー・エンゲージメント評価マトリクスです。PMBOKガイドの体系では、エンゲージメントの水準を5段階で表します。

5段階とは、第1に不認識で、プロジェクトの存在や自分への影響を知らない状態。第2に抵抗で、プロジェクトを認識したうえで反対している状態。積極的に反対を表明する場合もあれば、協力や資源の提供を控えるという受動的な形をとる場合もあります。第3に中立で、認識しているが賛成も反対もしていない状態。第4に支持で、内容を理解したうえで賛同し、必要なときに協力してくれる状態。第5に指導で、成功のために自ら能動的に動いてくれる状態です。

実務での使い方は単純です。縦に関係者名を並べ、横に5段階を並べ、現状（Current）の位置にC、望ましい状態（Desired）の位置にDを記します。同じ欄にCとDが並べば、その相手については現状で問題ないという意味です。CとDがずれている相手が、働きかけの対象になります。この可視化の利点は、「何となく関係が悪い」という感覚を、「不認識から支持まで2段階引き上げる必要がある」という具体的な作業に変換できることです。

ここで気をつけたいのは、全員のDを最上位の「指導」に設定しないことです。自分から旗を振ってくれる人は、多くても数名で足ります。多くの関係者にとって望ましい状態は「支持」であり、直接の関与が薄い相手なら「中立」で十分な場合もあります。Dを高く置きすぎると、必要のない働きかけに時間を使うことになり、本当に動かすべき相手への集中が薄まります。

手順4：エンゲージメント計画に落とす（誰が接点を持つか）

働きかけの内容は、現状の水準によって変わります。不認識の相手に必要なのは、まず情報を届けることです。プロジェクトの目的と、その人の業務にどう影響するかを、専門用語を避けて伝えます。中立の相手を支持に動かすには、その人にとっての利点を具体的に示すことが要ります。抵抗している相手には、反対の理由を聞き取ることが最初の作業です。反対には理由があり、それが正当な懸念であることも珍しくありません。過去の類似案件で痛い目に遭っている、自分の業務量が増えると見込んでいる、意思決定の過程から外されたと感じている、といった事情が出てくれば、対処の方向も決まります。

誰が接点を持つかも明示的に決めます。相手の役職や立場によって、プロジェクトマネージャーが直接話すべき場合と、スポンサーや役員から話してもらうべき場合があります。序列を重んじる組織では、実務担当者からの説明が届かない相手に、同格の役職者からの一言が効くことがあります。この「誰から伝えるか」の設計を省くと、正しい内容を伝えているのに動かない、という事態になります。

役割の明確化には、責任分担マトリックスの一種であるRACIチャートが使えます。作業や意思決定ごとに、実行する人（Responsible）、成果に説明責任を負う人（Accountable）、事前に意見を求める人（Consulted）、結果を知らせる人（Informed）を割り当てるもので、PMIもステークホルダーの関与を定義する一般的な責任分担マトリックスとして定義しています。運用上の要点は、Aを必ず1人にすることと、CとIを取り違えないことです。意見を聞くべき相手をIにすると、決まった後に異議が出ます。

手順5：コミュニケーション計画に書く中身

エンゲージメント計画と表裏一体なのが、コミュニケーションマネジメント計画です。この文書が決めるのは、どの情報を、誰に、いつ、どの形式で、どの経路で届けるか、そして誰が届ける責任を持つか、という5点です。第1の「誰に」は、ステークホルダー登録簿の分類がそのまま入力になります。密接に関与させる相手と、満足した状態を保てばよい相手とでは、届ける情報の粒度が違います。第2の「何を」は、伝える情報の内容、詳細度、書式です。ここで頻発する失敗が、全員に同じ進捗報告書を送ることです。経営層が知りたいのは、目標に対して着地がどうなるかと、判断を仰ぎたい事項は何かの2点であって、タスク単位の消化率ではありません。逆に実務担当者に経営層向けの要約だけを送ると、自分が何をすべきか分かりません。相手ごとに情報を作り分けることが、計画の中心です。

第3の「いつ・どの頻度で」は、定期的な配信と、条件が満たされたときの配信の2種類に分けて決めます。週次の進捗報告のような定期の枠に加えて、赤信号になったとき、想定を超える変更要求が出たとき、といった発火条件を先に決めておくと、悪い知らせの報告が個人の勇気に依存しなくなります。第4の「どの媒体で」は、会議のように相互にやり取りする形式、報告書やメールのように送り手から押し出す形式、共有フォルダやダッシュボードのように受け手が取りに行く形式を、内容の重さで使い分けます。込み入った判断や機微な話題は、その場で疑問を解消できる相互形式が向いています。第5の「誰が」は、発信の責任者を個人名で決めることです。

もう1つ、PMIの体系で明示されている原則があります。明確な伝達の責任は送り手にある、という考え方です。送り手は情報を発信するだけでなく、それが受け取られ正しく理解されたことを確認する責任を負います。「メールで送りました」は、伝えた証明になりません。

手順6：変化に追従する（監視と再評価）

ステークホルダー管理で最も多い形骸化は、立ち上げ時に登録簿とマトリクスを作り、そのまま更新しないことです。プロジェクトが半年も走れば、組織改編で担当者が代わり、経営の優先順位が変わり、当初は支持していた部門が別案件との資源競合で態度を変えます。初期に作った評価は、時間とともに必ず現実からずれていきます。

運用の型としては、定例のプロジェクト会議に「関係者の状況」を固定議題として置くのが確実です。毎回全員を見る必要はありません。エンゲージメント評価マトリクスでCとDがずれている相手について、前回からの変化と実施した働きかけの結果を確認し、あわせて新しく現れた関係者がいないかを問う、という進め方で足ります。フェーズの切り替わり、大きな変更の承認、組織改編や人事異動のタイミングでは、全件の棚卸しを行います。

態度の変化を早めに掴む兆候にも型があります。定例への出席者が本人から代理に変わった、依頼への返答が遅くなった、会議で発言しなくなった、といった変化は、関心の低下や不満の表れであることが多いものです。こうした兆候を察知したら個別に時間をもらって話すという習慣が、問題が大きくなる前の是正につながります。

新しく現れる関係者の把握も、監視の一部です。実装や移行の段階に入ると、それまで無関係だった運用部門やヘルプデスク、教育担当が当事者になります。段階が変われば関係者も変わる前提で、フェーズの入口ごとに特定をやり直してください。

よくある失敗と、その対処

第1の失敗は、決裁者が定例に出てこないことです。代理が出席し、その場では何も決まらず、持ち帰った内容が本人に正しく伝わらないまま時間が過ぎます。対処は2つあります。1つは、その相手に必要なのは定例への出席ではないと割り切り、判断が必要な事項だけに絞った短時間の個別枠を確保することです。もう1つは、代理者の決定権限の範囲を明文化してもらうことです。「この金額まではこの人が決められる」と決めておけば、空回りは減ります。

第2の失敗は、伝えたつもりです。会議で説明した、資料は共有フォルダに置いた、メールで送った。しかし相手は読んでいないか、読んだが別の意味に理解しています。前述のとおり、明確な伝達の責任は送り手にあります。後戻りの効かない事項については、相手の言葉で理解を返してもらう、議事録に決定事項として書いて明示的に確認を取る、といった受領の確認をひと手間かけてください。相手に不利な内容や作業負荷が増える内容ほど、確認の必要度は上がります。

第3の失敗は、悪い知らせの報告が遅れることです。これは個人の資質の問題ではなく、組織的に繰り返し観察される現象で、情報システム分野の研究では「マム効果（mum effect）」として扱われてきました。スミスとカイルらの研究は、失敗の兆候が現場では見えているのに上位に伝わらない、あるいは伝わる過程で大きく歪められることが、プロジェクトの暴走と失敗に寄与する重要な要因だと指摘しています。

対処は、報告する側の勇気に頼らない仕組みを作ることです。第1に、報告の発火条件をあらかじめ決めておきます。指標が閾値を超えたら自動的に報告される形にすれば、報告するかどうかの判断そのものが不要になります。第2に、悪い報告を持ってきた人を責めない姿勢を、プロジェクトマネージャーが繰り返し行動で示します。最初に上がってきた悪い知らせへの反応を、周囲は見ています。第3に、報告と同時に対策を求めないことです。「対策を考えてから来い」という運用は、報告を遅らせる方向にしか働きません。

明日の1時間で、ここまでは終わる

チームで1時間取り、関係者を書き出します。このとき、情報システム、法務、購買、監査、現場のキーユーザー、社外の規制当局と委託先という6つの分類を必ず一巡してください。ここで漏れた相手は、以降のどの工程でも拾えません。書き出したら権力と関心度の2軸に並べ、上位に来た相手だけ、現状の態度と望ましい態度を5段階で記します。CとDがずれた相手について、誰がいつ何をするかを決める。最後に、誰に何をどの頻度でどの媒体で誰が届けるかを一枚にまとめ、悪い知らせの発火条件をそこに書き加えます。

ただし、この一巡が効くのは組織の構造がある程度固まっている場合に限ります。合弁の立ち上げ直後や、買収後まもない時期で、どの部門にどこまでの決裁権があるかが本人たちにも分かっていない状況では、書き出した内容が翌月には古くなります。その場合に一覧の精度を追うのは無駄で、決裁権の所在を確かめること自体を最初のタスクに置くほうが早いです。

作ったものは定例の固定議題に載せます。ステークホルダー管理が機能しなくなる原因のほとんどは、道具の精度不足ではなく、作ったまま更新されないことです。様式の洗練は後からで間に合いますが、更新の習慣は最初に作らないと後から入りません。

道具の目的も取り違えないでください。分類は相手を操作するためのものではなく、限られた時間をどこに使うかを決めるためのものです。象限の線引きに1時間かけるより、上位に来た相手と実際に話す30分のほうが、たいてい成果につながります。