ステークホルダー・マネジメントの7つのプロセス｜「メテオフォール型開発」を防ぐPMBOK第8版の実務

少し前に「日本のプロジェクトマネジメントはメテオフォール型だ」という投稿がインターネット上で話題になったことがあります。

メテオフォール型開発とは、開発現場の上空に「神」が存在し、その気まぐれな一言（＝隕石／メテオ）によって、実装も設計も要件定義も一瞬で吹き飛ばされる、という風刺です。順調に進んでいたはずのプロジェクトが、社長や役員のちゃぶ台返しで一夜にして白紙に戻る——笑い話として広まりましたが、心当たりのある方も多いのではないでしょうか。

私はこの状態を、ステークホルダー・マネジメントがうまく機能していないことの分かりやすい症状だと考えています。今回はPMBOK第8版が定義するステークホルダー領域の7つのプロセスを見ながら、こうした事態をどう防ぐかを考えていきます^[1]Project Management Institute, Inc., The Standard for Project Management and A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition, 第2部 セクション2.5.2 … Continue reading。

7つのプロセスの全体像

まず全体像です。この領域には、プロジェクトの立ち上げから監視、クローズまでを通じて機能する7つのプロセスが定義されています。

#	プロセス	段階
1	ステークホルダーの特定	特定
2	ステークホルダー・エンゲージメントの計画	計画
3	コミュニケーション・マネジメントの計画	計画
4	ステークホルダー・エンゲージメントのマネジメント	実行
5	コミュニケーションのマネジメント	実行
6	ステークホルダー・エンゲージメントの監視	監視
7	コミュニケーションの監視	監視

「エンゲージメント系」と「コミュニケーション系」が、計画・実行・監視の各段階で対になっているのが分かると思います。この対応関係を頭に入れておくと、7つを丸暗記しなくても構造で理解できます。

ステークホルダーの特定（Identify Stakeholders）

ここで押さえておきたいのは、「定期的かつ継続的に」という表現です。PMBOKは、プロジェクトの進行や環境の変化に伴ってステークホルダーを特定し続けることが、環境の変化に適応するためのリスク管理戦略としても機能する、と位置づけています。

冒頭のメテオフォールの話に戻ると、隕石を落としてくる「神」は、多くの場合プロジェクト開始時点から存在しています。存在しない人が突然現れるわけではなく、関係者として認識されていなかっただけです。

だからこそ、社長のような最終決裁者はもちろん、プロジェクトに影響を与えそうな人物をできる限り洗い出し、ステークホルダー登録簿などに対策とともにまとめておくことが大切だと思います。

そのためのヒントは、実は日々の会議の中にあります。

• 「これって営業部の○○さん、どう思うかな」
• 「技術部には確認が必要なんだっけ？」

こうした何気ない会話は、まだ特定できていないステークホルダーの存在を教えてくれるサインです。聞き流さずに拾い上げ、不安材料をひとつずつ潰しておくことをおすすめします。

ステークホルダー・エンゲージメントの計画（Plan Stakeholder Engagement）

ここでのポイントは、相手を一律に扱わないことです。
プロジェクトに対して支持的（Supportive）なのか、中立（Neutral）なのか、抵抗的（Resistant）なのか。そのエンゲージメントレベルに応じて、支持を高めてもらうための個別の対話戦略を考えます。

この計画は作りっぱなしにせず、フェーズの移行といった節目で定期的にレビューし、更新していきます。

コミュニケーション・マネジメントの計画（Plan Communications Management）

このプロセスは、ステークホルダーの特定・分析・優先順位付けと動的に重なり合っており、エンゲージメント計画と密接に連動します。切り離して考えるものではない、ということです。

実務上の基礎になるのが、扱う情報のカテゴリ分析です。

• 内部向けか、外部向けか（Internal / External）
• 極秘か、公開してよいか（Sensitive / Public）
• 大枠でよいか、詳細が必要か（General / Detailed）

この整理をしておくと、「誰に何をどこまで伝えるか」で迷う場面がぐっと減ります。

ステークホルダー・エンゲージメントの管理（Manage Stakeholder Engagement）

PMBOKがここで明示しているのは、チームメンバーとのやり取りだけでなく、プロジェクトスポンサーとも積極的に連携すべきだという点です。スポンサーのニーズや期待を満たし、課題に対処し、適切な関与を維持・促進していきます。

もし社長の確認が必要なプロジェクトなのであれば、定期的に報告の場を設け、確認すべきことをその都度確認しておく。これはまさにこのプロセスの実践であり、隕石が落ちてくる前に軌道を変えておく作業だと言えます。

コミュニケーションのマネジメント（Manage Communications）

スポンサー、顧客、エンドユーザー、外部ベンダーなど、宛先はさまざまです。それぞれに応じて、最適な手段を選びます。PMBOKでは伝達の方法として、双方向（Interactive）、プッシュ型（Push）、プル型（Pull）といった区分が示されています。会議のように相互にやり取りするのか、メールで一方的に送るのか、共有フォルダに置いて必要な人に取りに来てもらうのか、という違いです。

そして、プロジェクトやステークホルダーのニーズは変化します。手段や技術を柔軟に切り替えられることが求められます。

ステークホルダー・エンゲージメントの監視（Monitor Stakeholder Engagement）

実務では、現在の関与レベルと、プロジェクト成功に必要な「あるべき関与レベル」のギャップをマトリクスなどで分析し、その差を埋めるための行動が機能しているかを見ていきます。

「報告はしているのに、いつも上の空だ」という相手がいるなら、それは関与レベルにギャップがあるサインかもしれません。

コミュニケーションの監視（Monitor Communications）

ここで評価するのは、送ったかどうかではありません。計画した情報が必要な人に届いているか、正しく理解されているか、そして期待した意思決定やリスク管理につながっているかまでを継続的に見ていきます。

「報告書は毎週出していたのに、決裁者は読んでいなかった」という事態は、このプロセスが機能していないときに起こります。

メテオフォールは防ぐことができる！

7つのプロセスを見てきましたが、冒頭のメテオフォール型開発に立ち返ると、隕石が落ちてくる状況には、たいてい次のいずれかが起きています。

つまり、ちゃぶ台返しは突発的な事故というより、管理と監視が抜けていたことの結果として現れます。

もちろん、どれだけ丁寧にやっても防ぎきれない場面はあります。それでも、影響力のある人物を早い段階で洗い出し、その人に届く形とタイミングで情報を渡し、関与が薄れていないかを見続けることで、被害の大きさはかなり変えられるはずです。

まとめ

ステークホルダー領域の7つのプロセスは、「エンゲージメント」と「コミュニケーション」の2系統が、計画・実行・監視という段階でそれぞれ対になった構造をしています。

そして起点になるのは、プロセス1の「特定」です。ここが一度きりの作業で終わっていないか、会議で出てきた名前を拾えているか。この地味な積み重ねが、後半の混乱を減らしてくれます。