序盤に作った関係者図のまま進めたら、主役の交代を見逃した ― ステークホルダー・パフォーマンスドメイン

キックオフで影響度×関心度の相関図を作り、決裁者も押さえ、月次の個別報告枠まで用意した。我ながら良い立ち上がり——のはずが、フェーズが進むと関係者の主役が静かに入れ替わっていて、気づくのが遅れた私は「聞いていない」という不満を浴びかけました。この記事では、その顛末から始めて、8つのパフォーマンスドメインの一つ目「ステークホルダー」を、原則との違いも含めて説明します。

この記事でわかること

「特定して終わり」の関係者図が現実とズレていく仕組み
ステークホルダー「ドメイン」が、原則とどう違うのか
関与度の変化を定点観測する、現場の運用の工夫

筆者はSIerのPMとして、関係者マップを何度も作り直してきました。PMPの学び直しと並行して、その実感を記事にしています。

ステークホルダー・パフォーマンスドメインは、関係者の特定→分析→関与→監視を、プロジェクトの間ずっと回し続ける活動の領域です。原則③「ステークホルダー」が語るのは「あり方・心構え」でしたが、ドメインは「期間を通じて具体的に何をやり続けるか」という運用に踏み込みます。姿勢が原則、運用がドメイン、と捉えると混乱しません。

序盤に作った関係者図が、途中で古くなっていた
関係者リストは「一度作れば十分」だと思っていた
なぜ「監視」まで含まれているのか
今、意識していること
ここでよく迷うところ
振り返って
関連記事

序盤に作った関係者図が、途中で古くなっていた

複数社が関わる基幹システムの刷新案件を、まだ駆け出しのPMとして担当したときのことです。私はキックオフで、きちんとステークホルダーの相関図を作りました。影響度と関心度の二軸で関係者を並べ、「この役員が最終決裁者だ」と押さえたうえで、月次で個別報告の枠も用意した。ここまでは、我ながら良い立ち上がりでした。

つまずきかけたのは、プロジェクトが要件定義から開発フェーズへ移った頃です。序盤に主役だった業務部門のキーパーソンの関心が、実は徐々に薄れていました。異動の話も出ていたのです。一方で、開発フェーズになって存在感を増したのは、運用を引き継ぐ情報システム部門でした。ところが私は、序盤の関係者図のまま動いていて、この「主役の交代」に気づくのが遅れました。運用部門への説明が後手に回り、受け入れ段階で「聞いていない」という不満が噴き出しかけたのです。

そこで、登録簿に「フェーズごとの見直し日」を設定し、関与度を定点観測する運用に切り替えました。誰の関心が上がり、誰が薄れているか。それを定期的に描き直し、関与が薄れた相手には接点を増やす。関係者図を「生きた地図」として更新し続けることで、以降は主役の交代を先回りして拾えるようになりました。作るのは一度、でも見直すのは何度も。それが「関与を続ける」の実際でした。

関係者リストは「一度作れば十分」だと思っていた

正直に言うと、私はかつて「ステークホルダー管理=関係者リストを作ること」だと捉えていました。立派な相関図を一枚作れば、仕事をした気になっていたのです。

でも、教科書が「継続的なプロセス」と書いているのに対し、現場では「キックオフで一度作った表」が更新されずに放置される——これが最頻出の落とし穴です。関心度も影響度も、異動やフェーズ移行で簡単に変わるのに、初期のスナップショットのまま突き進んでしまう。もう一つ、「関心度が高い人=重要」という直感も危うい。優先すべきは、あくまで影響度(決裁・予算への力)が高い相手です。関心の高さと重要度を、つい混同してしまうのです。

なぜ「監視」まで含まれているのか

関係者の関心や影響力は、固定されていません。フェーズが変われば主役が変わり、人事異動で登場人物が入れ替わり、関与が薄れていく人も出てきます。だから、最初に描いた関係者図は、放っておけばすぐに現実とズレます。ステークホルダー・ドメインが監視(モニタリング)まで含むのは、この「動き続ける前提」があるからです。