ステークホルダーマネジメントとは
ステークホルダーマネジメントとは、プロジェクトに影響を与える人や組織を洗い出し、それぞれとの関わり方を設計して、プロジェクトへの協力を得ていく取り組みです。プロジェクトマネジメントの知識体系『PMBOKガイド』では、ステークホルダーを、プロジェクトに影響を与えたり、プロジェクトから影響を受けたりする可能性のある個人・グループ・組織と定義しています。「利害関係者」と訳されることが多い言葉ですが、実際の対象はそれよりずっと広いと考えた方が良いかなと思います。
プロジェクトが止まるきっかけは、プロジェクトの外から来ることが少なくありません。
- 上司から、急に「進捗を知りたい」と連絡が来て、資料づくりに追われる
- 顧客から仕様変更の依頼が来たが、対応すると納期に間に合わない
- 関係部署から「内容も分からないのに協力できない」と言われる
- 取引先から、部品の納期が遅れると連絡が来る
ステークホルダーには、プロジェクトマネージャーが直接やりとりできる相手と、そうでない相手がいます。メンバーやオーナー、窓口の担当者は、直接関わる分、手を打ちやすい。一方で、関係部署の責任者や、相手先の役員、取引先などは、直接やりとりする機会が少なく、気づいたときには反対や不満が大きくなっていることがあります。後から足を引っ張られるのは、たいていこちらの側です。外から来る火種がプロジェクトの炎上につながる流れは、プロジェクトが炎上する原因と立て直し方で書いています。
『PMBOKガイド』第6版では、計画のプロセスの名前が「ステークホルダー・エンゲージメントの計画」に変わりました。顧客や上司を、プロジェクトマネージャーがコントロールすることはできません。マネジメントするのは、相手との関わり方（エンゲージメント）だという考え方です。私もこの考え方に近いです。相手を思いどおりに動かそうとするほど、相手は身構えます。人から与えられたものには、反発が起きやすいからです。相手が自分から協力したくなる関わり方を、最初に設計しておくことが大切だと私は考えています。
ステークホルダーマネジメントの進め方：4つのステップ
ステークホルダーマネジメントは、次の4つのステップで進めます。
- ステークホルダー（顕在）を特定する：プロジェクトに関わる人と組織を洗い出し、権限の大きさと関心の高さを確かめる
- ステークホルダー（潜在）を特定する：それぞれが、プロジェクトをどう受け止めているか、表に出ていない姿勢を確かめる
- コミュニケーションプランを作る：一人ひとりに、なってほしい姿勢と、そのための関わり方を決める
- コミュニケーションを実施する：計画どおりに関わり、相手の姿勢の変化を見て計画を直す
いちばん大切なのは、最初の特定です。洗い出しから漏れた人がいると、まさにそこから問題が起きます。最初の打ち合わせにいなかった部門が、途中から「自分たちの業務も入れてほしい」と言ってくるのは、その典型です。範囲が広がり続ける問題は、スコープクリープとは？で詳しく書いています。もう一つ気をつけたいのは、プロジェクトの最初に思い描いた構図が、そのまま正しいとは限らないことです。
私自身、事業承継を支援するAI「アトツギ・ナビ」を開発したとき、最初は経営者が自分で使うツールとして考えていました。ところが、対象として考えていた経営者は50代後半から60代が中心で、ITを使いこなしてもらうのは難しい。そこで、経営者を支えるアドバイザー（専門家）が使うツールに切り替えました。誰が使うのか、誰が決めるのか、誰が影響を受けるのか。そこを思い込みで決めてしまうと、関わる相手を最初から取り違えることになります。ステークホルダーの特定は、プロジェクトの途中でも何度か見直す方が良いかなと思います。
ステークホルダーマップの作り方
ステークホルダーマップは、洗い出した関係者を図にして、誰にどう関わるかを決めるための道具です。よく使われるのは、縦軸に「権力（プロジェクトへの影響力）」、横軸に「プロジェクトへの関心」を取り、四つの区分に分ける方法です。
| 項目 | 関心が低い | 関心が高い |
|---|---|---|
| 権力が大きい | 満足な状態を保つ：要所で報告し、不満を持たれないようにする | 注意深くマネジメントする：頻繁に話し、重要な判断に巻き込む |
| 権力が小さい | 監視する：様子を見ながら、必要なときに情報を届ける | 常に情報を与える：進捗をこまめに伝え、意見を聞く |
次に、それぞれの関係者が、プロジェクトをどう受け止めているかを見ます。姿勢は五つの段階で考えます。
- 不認識：プロジェクトのことを知らない
- 抵抗：知っているが、支持していない
- 中立：知っているが、支持も反対もしていない
- 支持：知っていて、支持している
- 指導：知っていて、積極的に協力してくれる
この二つを合わせて、一人ひとりの「いまの姿勢」と「なってほしい姿勢」、そのための対策を一覧にします。仮の例で書くと、次のような形です。
| 関係者 | 重要度 | いまの姿勢 | なってほしい姿勢 | 対策と方針 |
|---|---|---|---|---|
| 社長（オーナー） | 大 | 指導（プロジェクトの言い出し手で協力的） | 指導（いまのまま） | 小さな成功を早くつくり、さらに後ろ盾になってもらう |
| 副社長 | 大 | 抵抗（当初から反対の立場） | 支持 | こまめに話し、副社長の意見を取り入れながら進める |
| 製造本部長 | 中 | 中立（メンバーだが一歩引いている） | 指導 | 定期的に1on1を行い、プロジェクトへの当事者意識を育てる |
| 営業本部長 | 小 | 支持（当初から賛成） | 支持（いまのまま） | 運営会議で、きちんと情報を共有しながら進める |
※ 仮の例です。社名・人物は実在しません。
抵抗している人を、敵として見ないことが大切です。意見が違うのは健全なことで、反対している人は、プロジェクトの弱いところを誰よりも先に教えてくれる人でもあります。また、この一覧は作って終わりではありません。人の姿勢は、プロジェクトの進み方で変わります。定例会のたびに見直し、対策を入れ替えていきます。誰が何を決めるのかは、RACI図とは？責任と権限の決め方とあわせて整理すると、役割と関わり方が一枚につながります。
表のキーマンと裏のキーマン
プロジェクトの立ち上げで大事なのは、組織を動かすテコになるキーマンを見つけることです。キーマンが見つかれば、話は速く進みます。見つからなければ、プロジェクトマネージャーがすべての調整に出ていくことになります。
キーマンには、二つのタイプがあります。
表のキーマンは、役職が高く、これまでの実績で社内から評価されている人です。考えが明快で、プロジェクトの実務を引っ張ってくれます。ただ、社内の人間関係によっては、プロジェクトで決めたことが、その人の力だけでは組織に落ちていかないこともあります。
裏のキーマンは、役職の影響力はそれほど大きくなくても、社内に人のつながりが広く、誰からも頼りにされている人です。意見が対立する人どうしの間を取り持つことができ、いざとなれば、相手の役職に関係なく自分の考えを率直に伝えられます。周りから一目置かれ、信頼されています。
仮の例で考えてみます。影響力の大きい会長が、プロジェクトに消極的だとします。実務の窓口になっている部長は熱心ですが、会長を動かせる立場にはありません。このとき、会長からも社長からも信頼されている社長室長に、プロジェクトの狙いを理解してもらい、会長に伝わる道をつくってもらう。組織図だけを見ていると、この人の存在には気づけません。
キーマンを仲間に迎えるときは、まず候補に目星をつけ、話を聞く機会をつくります。プロジェクトに必要な力や人のつながりがあるかを確かめ、関係を深めていきます。最後に、相手のこれまでの実績をきちんと認めたうえで、「あなたにしかお願いできない」という期待を込めて協力を頼みます。
ここで目指したいのは、相手をうまく操ることではなく、相手の本音を知ることだと私は考えています。誰が何を心配していて、プロジェクトに何を期待しているのか。それが分かれば、関わり方を相手に合わせて変えられます。本音を聞くには、公式の会議だけでなく、ふだんの何気ない会話の機会を増やし、相手の話をきちんと聴くことが近道です。聴き方の基本は、1on1ミーティングとは？で書いた考え方と同じです。
本音を聞くヒアリングの進め方
キーマンを見極め、相手の本音を知るための場が、ヒアリング（インタビュー）です。ところが、形だけのヒアリングになっていることも少なくありません。
- 聞きたいことだけを聞いて終わる
- 相手の愚痴を聞くだけで、問題にたどり着けない
- 表面的な問題しか聞き出せず、プロジェクトの後半で本当の問題が出てくる
- 信頼関係ができず、後から頼みごとをしても聞いてもらえない
ヒアリングで実現したいことは、大きく三つあります。課題を見つける糸口をつかむこと、キーマンを見極めること、信頼関係をつくってプロジェクトを円滑に始めることです。
相手の話は、氷山にたとえると分かりやすくなります。水の上に見えているのは「相手が言っていること」だけで、その下に「相手が言わんとしていること」「相手が言っていないこと」「相手が気づいていないこと」が隠れています。ヒアリングは、この下の層に少しずつ降りていく作業です。進め方は、次の6つの流れで組み立てます。
- セットアップとアイスブレイク
- ヒアリングのテーマを確かめる
- 現状をはっきりさせる
- 理想の状態をはっきりさせる
- 現状と理想の差をはっきりさせる
- まとめる（ラップアップ）
話が抽象的すぎるときは具体化し、細かすぎるときは抽象化します。「□□でお悩みとのことですが、具体的に教えていただけますか？」「その目標が達成できたかどうかは、どの数字で判断しますか？」と具体化する問い。「そもそも、この部署の役割は何ですか？」「問題があるのは分かりました。結局、何を実現したいのですか？」と抽象化する問い。この二つを行き来すると、言葉の下にあるものが見えてきます。
それでも、課題は本人にもなかなか言葉にできないものです。私はコンサルタントの頃から、よくある課題を一覧にして紙でお渡しし、「これは当てはまる」「これは当てはまらない」と選んでもらうやり方をよく使っていました。ゼロから聞かれると答えに詰まる人も、選択肢があると「そう、これです」と話し始めてくれます。あわせて、最初は過去の取り組みや強みのような答えやすい話から入り、数字や本音に関わる重い話は後に回します。相手に話しやすい形を用意することも、聞く側の役割かなと思います。