ステークホルダーの特定
ステークホルダーという言葉は、なかなか聞きなれない言葉かもしれません。端的に言えば「利害関係者」のことですが、それは別にビジネス的なお金の繋がりだけのことを言っているわけではありません。たったそれだけで済むなら、「お客さま」「取引先」「カスタマー」などと言えばいいだけですからね。
ある仕事を介して、
・そうすることで得をする人
・そうしないことで損をする人、困る人
それらすべてをステークホルダーと言います。ですので、自分の会社から外部に発注しているのであれば、その業者や協力会社の収益にも関係するのでステークホルダー。マネージャーだけでプロジェクトが動くわけではないので、メンバーもステークホルダー。上司もそうだし、経営者もステークホルダーになるでしょう。
自分に与えられた、あるいはチームに与えられた仕事をこなさないことで困る人はすべてステークホルダーと思ってください。もし、家庭を持っている人がいれば、妻（夫）や子供達もステークホルダーということになるかも知れません。
そんな中でも、特に「プロジェクト」だけに限ってしっかり管理、コントロールしていこうというのがプロジェクトマネジメントの趣旨です。「仕事」とか「ビジネス」って言う枠に広げてしまうと、ステークホルダーが広すぎてマネジメントに支障をきたすためです。
そうしてステークホルダーに特化して行われるマネジメントを、
『ステークホルダー・マネジメント』
と言います。ステークホルダー・マネジメントには
13.1 ステークホルダー特定
13.2 ステークホルダー・マネジメント計画
13.3 ステークホルダー・エンゲージメント・マネジメント
13.4 ステークホルダー・エンゲージメント・コントロール
の４つが、PMBOK（プロジェクトマネジメントの知識体系）の中では要求されています。
実際、PMBOKと呼ばれる国際規格の中でも、2012年に第５版となった際に追加された知識エリアとなっています。かれこれ10年近くも前から、ステークホルダーの存在が重要性を増してきていることを、世界は認識しています。
ですが、日本ではまだまだステークホルダーの重要さを自覚している人は多くありません。プロジェクトマネジメントに優れたマネージャーでも、重要視している人は少ないのではないでしょうか。
これらは、PMBOKの「プロセス」という区切りで見た場合、
と言うように、それぞれマネジメントする時期やその内容が大きく異なります。
ステークホルダー特定
たいていのステークホルダー管理では、おそらく"13.1 ステークホルダー特定"しか行っていないことでしょう。これは本来、
・ステークホルダーの特定
・実際に発生する利害
・相互依存関係
等を明確化する立上げプロセスの仕事です。
「誰が決定権を持っているのか」
「誰を通さないと承認が下りないのか」
「何をする時には、誰の予定を考慮しなければならないのか」
「誰がOKと言ってくれないと、検収があがらないのか」
と言ったことを明らかにする作業です。これを特定することで、今後の計画時に
「誰をどこで関係させるのか？」
「誰をどの会議で巻き込むべきか？」
「フローの中で誰の承認を得ないといけないのか？」
等が見えてくるようになります。つまり、『責任の所在』をハッキリさせることができるというわけです。これができていないから、責任の所在を明確にすることなくプロジェクトを推進した結果、
「言った／言わない」
「うちのせいじゃない」
「おたくのせいで」
みたいな責任の擦り付け合いによるＩＴ調停が後を絶たなくなってしまうわけです。ステークホルダー一人ひとりに何の役割と、何の権限と、何の責任があるのかを明確にしておけば、そんな事態になることなどなかったはずなのに、（自社、顧客それぞれの）マネージャーが手を抜いてしまったがためにこうしたトラブルが引き起こされるのです。
ステークホルダーマネジメント計画
計画プロセスでは、"13.2 ステークホルダーマネジメント計画"を検討すべきものとなっています。
先ほども説明しました通り、具体的には、
「顧客のＡ氏が決定権を持っているので、
Ａ氏にはこのレビューとこの会議には必ず参加してもらおう」
→会議体における参加者の定義
→権限の定義
「検収には必ずＱＡ部門の承認印が必要だから、
忘れないようにスケジュール管理しよう」
→承認フローの定義（→アクティビティの定義（→スケジュール構築））
「チームが複数部門またがるので、情報共有のための環境を構築しよう」
→リソースの準備
→準備のためのスケジュール構築
と言った具合に、誰をどこで関係させるのかを明確にし、役割一つひとつにハッキリとした責任を持たせたり、作業環境の準備を行ったりします。
ステークホルダー・エンゲージメント・マネジメント
実行プロセスでは計画通りに進められるよう"13.3 ステークホルダー・エンゲージメント・マネジメント"によって、推進します。
ここで言うマネジメントは「やりくり」のことです。
計画に従って、ステークホルダーを必ず巻き込んで、ただしく運用できるようにあの手この手を使って計画通りになるようマネジメントしなさい、ということです。
具体的な手段が計画時に決められていなければ、「あの手この手」の手段は問いません（モラルに反しない限り、ビジネスに支障をきたさない限り）。逆に計画によって詳細に定められているのであれば、その通りに運用します。上手くいけばそれでよし。上手くいかなければ、「監視・コントロール」プロセスにて計画の見直しや微調整を行ってあげればよいのです。
ステークホルダー・エンゲージメント・コントロール
監視・コントロールプロセスでは、実際にステークホルダー間でより良いプロジェクト活動ができていることを確認しながら、微調整を行いコントロールする"13.4 ステークホルダー・エンゲージメント・コントロール"を実施します。
旧版では「期待のマネジメント」と呼ばれていましたが、第５版から「エンゲージメントマネジメント」という名称になり、計画に沿った期待通りのマネジメントをすることで、ステークホルダーのプロジェクトへの関与を強化するということが強調されたプロセス名になりました。
要するに、どんどんステークホルダーを巻き込んでいきなさいということです。特に注意すべきは
「『決裁権』がどこにあるか？」
です。プロジェクトでは、居心地がいい人とだけコミュニケーションをとってばかりいる多くのマネージャーが見落としがちです。取引先の窓口として担当されている方がイコール決裁者ということはまずありません。
数千万程度であれば主任相当。
数億規模でも課長クラス相当。
あたりの方が、お客さまがわの窓口担当されていることが多いのではないでしょうか。ですが、数千万と言えば課長～部長、億を超えれば役員が決裁権を持っている…というのはままあることです（大企業でもない限り）。そして、そういった決裁者は重要なプロジェクトの会議をはじめ、多くの場合、表に出てこようとしません。すべて部下からのまた聞きでしか状況を知ろうとしないのです。
これを
「そういうものだ」
と思って、過去に多くのプロジェクトを破綻させてきたから、2012年以降、国際規格として「ステークホルダーマネジメント」が取り上げられたんです。だから、未だに「そういうものだ」を思ってる人がいたら、その人は10年前から思考が停止していることを意味します。
それじゃダメなのです。
決裁者をどんどん巻き込んで、決裁権を行使しなければならないところで、必要な情報を必要な時に、必要なだけインプットとして入手し、そのうえで的確な権限と責任の行使をしてもらわなければならないのです。
エンゲージとは
そこで、エンゲージの意味とは何なのか？となります。
エンゲージメントとは、"約束"とか"婚約"という意味としてよく使われますが、一般的には組織や会社に対する愛着心を意味しています。
その意味をステークホルダーマネジメントという側面から考えますと、
「エンゲージメントとは、ステークホルダーの一人一人が、
プロジェクト組織に対して、ロイヤリティを持ち、
方向性や目標に共感し『心からの愛着』を持って、
絆を感じている状態である。」
となり、その状態にステークホルダーを持っていくためのマネジメントとして、コミュニケーションし、課題の解決を一緒に行うことが重要だということになります。
そのためのツールや技法として、PMBOK第５版では、
・コミュニケーション方法
・人間関係のスキル
（信頼の構築やコンフリクトの解消、積極的傾聴、変化への抵抗の克服）
・マネジメントスキル
（合意形成の促進、プロジェクトを支援するよう人々への働きかけなど）
がテーマとされています。計画では、上記ツールや技法を駆使して、どのようにエンゲージメントを実現するか検討し、実行では、実際にツールや技法を駆使して実現努力を図り、監視・コントロールでは、順調であることを適宜確認しながら、それでも順調に進まない場合は調整する…と言う流れを求めています。
事実、お客さま（ユーザー）と良好な信頼関係を築くことは、プロジェクトを成功させるための大きなファクターとなります。次プロジェクト以降の受注獲得（反復購買行動）に向けても大きな割合を占めることになるでしょう。
これを疎かにして、自分たちの中だけで好き勝手マネジメントしても、プロジェクトは成功しません。
かと言って、お客さま依存の主体性のないマネジメントでは、利益の有無にかかわらず現場の担当者が疲弊します。売上や利益等、目先の"収益"だけを見ているとついつい見落としがちですが、
ステークホルダー・マネジメントは非常に重要とされている所以です。
たとえば、ステークホルダーを特定するにあたり、ステークホルダーの分析を行ってみるとしましょう。
あるシステム導入プロジェクトがあるとします。
このプロジェクトにおける３人のステークホルダーを、分析マトリックスを用いて分類してみましょう。３人の登場人物の情報を以下に示します。
ステークホルダーを特定したら、それらのステークホルダーがどのようなスタンスなのか、どの程度の影響力を持っているのかを分析します。このとき、便利なのが「ステークホルダーのグリッド」です。
ステークホルダーのグリッドは、横軸に「プロジェクトへの関心度」、縦軸に「ステークホルダーの権力」を取り、各ステークホルダーがどこに位置するかをマッピングするものです。ここでいう権力とは、単に役職が高いというわけではなく、発言力があったり、業務上の影響力が強い人も含まれます。
ステークホルダーのグリッドを使って分析することで、それぞれのステークホルダーがプロジェクトにどのように影響を与えるのか、どのステークホルダーの意見や関心を考慮するべきかを検討できます。
最終成果物（納品物）に関しての話や、予算・スケジュールに関する話など、重要な決定を行う場に、誰を巻き込むべきかが見えてくることでしょう。そしてそれらを『計画』時点で決定し、合意を得ることができていれば
・必ず巻き込めるという確証が得られる
・権限を行使させ、責任を負わせることができる
・計画に従わないで問題が起きた場合、責任を取らせることができる
ことが可能になります。
●満足な状態を保つ（権力：高、関心度：低）
権力が大きいものの、プロジェクトに大きな関心を持っていない人たちは「満足な状態を保つ」必要があります。このエリアに分類される人たちは、役職が高い、あるいは発言力がある人たちですが、プロジェクトの結果から大きな影響を受けない、もしくは受けないと思っている人たちです。
本当に影響がなくて関心がないのであればいいのですが、業務プロセスの変革を伴う場合など、影響があるのに関心を持とうとしないケースもあります。その場合は、関心を持ってもらえるように働きかける必要があります。
●常に情報を伝える（権力：低、関心度：高）
権力は大きくないものの、プロジェクトへの関心が強い人たちは「常に情報を伝える」対象となります。
たとえば、業務部門の現場メンバーがこのエリアに位置されます。プロジェクトが自分たちの仕事にどんな影響があるのかは、誰しも興味があります。情報が展開されないままだと、いらぬ不安を生み出すことになり、プロジェクトへのマイナスの影響が出てしまう可能性があります。
●監視する（権力：小、関心度：低）
権力が小さく、関心度も低いステークホルダーには、最小限の対応ですませることで他のステークホルダーに注力します。
では、この３人をステークホルダー分析モデルに当てはめてみます。
このモデルを参考に３人をステークホルダー分析すると、支援を増加させ、マイナス影響を低減させるための戦略として取るべき方向性が見えてきます。
こうして特定できると、今後の計画プロセスにおけるステークホルダーマネジメントでは、具体的に
「どのように情報を伝え、共有すればいいか」
「どのような合意形成を描き、どのように定期的に満足してもらうべきか」
と言った計画が立てられるようになるわけです。
いいなと思ったら応援しよう！
