プロジェクトマネジメントのステークホルダーってなに？
ステークホルダーはどうやって管理すればいいの？
ステークホルダーを管理するリストを知りたい！
あなたのプロジェクト、ステークホルダーが漏れていませんか？会社から指名されたメンバーだけで構成したプロジェクトはステークホルダーが漏れているかもしれません。
ステークホルダーが漏れると大変です。最悪、システム稼働後に機能不足が発覚して失敗プロジェクトになるかもしれません。
それ以外にもステークホルダーがプロジェクトに与える影響は様々です。ステークホルダーが与える影響を知り、プロジェクトマネージャー自らがステークホルダーを適切にマネジメントすることが重要です。
ここでは、プロジェクトマネジメントにおけるステークホルダーの管理方法をわかりやすく解説します。少しでもプロジェクトマネジメントの参考になれば幸いです。
ステークホルダーとは
ステークホルダーとは、企業の事業活動に関わる利害関係者を指します。
システム開発のプロジェクトにおけるステークホルダーは、 開発メンバーはもちろん、お客様は責任者だけではなく、業務を詳しく知る担当者も含まれます。
もし、社内・社外問わず、データ連携先があれば、その連携先（社外の場合はその会社）の責任者や担当者、開発を請け負っているシステム開発会社の方々もステークホルダーです。
ステークホルダー（stakeholder）とは、企業・行政・NPO等の利害と行動に直接・間接的な利害関係を有する者を指す。日本語では利害関係者（りがいかんけいしゃ）という。具体的には、消費者（顧客）、労働者、株主、専門家、債権者、仕入先、得意先、地域社会、行政機関、利益団体（業界団体・労働組合等）の構成員など。
引用：ウィキペディア｜ステークホルダー
ステークホルダーがプロジェクトに与える影響
当たり前ですが、プロジェクトはひとりが頑張っても進みません。プロジェクトの目的を達成するために、ステークホルダー全員が携わって進めていく必要があります。
まずは、ステークホルダーがプロジェクトにどのような影響を与えるのか、主なものを列挙します。
ステークホルダーが漏れるとシステム化要件も漏れる
ヒアリングしなければいけないステークホルダーが漏れていると業務の洗い出しが不十分になり、システム化要件も漏れてしまいます。 最悪、お客様の受入テスト段階で機能漏れが発覚すると手戻りによるスケジュール遅れ、開発工数の増加により失敗プロジェクトへまっしぐらです。
要件の抜け漏れや曖昧な内容の要求は、要件定義で解消しておく必要があります。それ以外の要件定義の失敗事例、要件定義を失敗しないための7つのポイントをこちらで解説しています。
ステークホルダーから様々な意見や要望が出る
システム開発のプロジェクトにはシステム開発者をはじめ、多くのステークホルダーが参画します。それぞれ過去の経験や考え方の違いから、様々な意見や要望があるのは当然です。
とりわけ、経営層と業務部門の担当者とは目的意識が違うことを理解しておくべきです。業務担当者は目先の現行システムの改善要望が多くなる傾向にあり、自分達の業務範囲の意見や要望となるために後工程の業務効率まで目が届きません。ましてや、プロジェクトの目的が曖昧であったり、目的の共有が不十分だと要求事項がまとまらず、スケジュールが遅延する事態になるでしょう。
ステークホルダー全員のベクトルを合わせるためにプロジェクトの判断基準であるプロジェクト標準を用意することが大事です。プロジェクト標準についてこちらで解説しています。よろしければ合わせてお読みください。
ステークホルダーの要求は変化する
ステークホルダーの要求は変化するものです。要求が変化することを前提にしたプロジェクトマネジメントが必要となります。
プロジェクトに対するステークホルダーの影響度合いを把握せずに進めると、声の大きい人（影響度が高い人）に振り回されることになります。もちろん、これによるスケジュール遅延や予算オーバーは言い訳になりません。
ステークホルダーのメンバーが交代する
プロジェクトにリスクはつきものです。ステークホルダーのメンバーが途中で交代することもリスクです。プロジェクトの業務キーマンだったメンバーが人事異動で交代したり、他のプロジェクトに引き抜かれることも考えておかなければなりません。
リスクの影響を最小限にするためにリスク管理があります。こちらで解説していますので、合わせてお読みください。
このように、ステークホルダーを漏れずに洗い出し、様々な意見や要望があるステークホルダーと適切に関わり合い、時にはメンバー交代のリスクにも向き合ってプロジェクトを運営していくことが重要だということがわかります。
つまり、会社から指名されたメンバーだけでプロジェクトを運営するのではなく、プロジェクトマネージャー自らがステークホルダーを適切にマネジメントすることが必要になるわけです。
では、どのようにしてステークホルダーをマネジメントすればいいのでしょうか？
ここからは、ステークホルダーの管理方法を説明します。
ステークホルダーを特定する
プロジェクトマネージャーに任命されたら、企画構想を理解し、ステークホルダーが誰なのかを特定することから始まります。
プロジェクトに関わるステークホルダーが誰なのかを特定し、プロジェクト推進の体制を構築する必要があります。特に規模の大きいプロジェクトの場合は、システム化対象の範囲が広いためにステークホルダーの特定も難しくなります。
前述の通り、ステークホルダーを漏らしてしまうと、システム化要件が不足していることに気づかずにプロジェクトが進んで、システム稼働後に機能不足が発覚する最悪なシナリオが待っています。そのため、要件定義を開始する前の段階でステークホルダーを漏らさずに特定することが重要なのです。
対象業務に直接影響するステークホルダー
業務部門責任者、業務部門担当者、システム運用者、システムベンダー、システムのエンドユーザーなど
対象業務に間接的に影響するステークホルダー
対象業務の前工程や後工程の業務部門責任者・業務部門担当者、取引先、システムが連携している外部システムとその責任者・担当者・システム運用者・システムベンダーなど
ステークホルダーを理解する
それぞれのステークホルダーの目的意識や価値観、ステークホルダー間が対立関係にあるのか、協力関係にあるかを事前に知っておくことも大事です。
プロジェクトは、常にステークホルダーと合意しながら進めていく必要があります。時にはステークホルダー間で意見が合わず、要求内容の調整に時間がかかることもあるでしょう。ですが、事前にステークホルダーの関係を理解しておくことで最適な解決策を提示することも可能になります。
また、声の大きい人（影響度が高い人）にプロジェクトが引っ張られることもよくあることです。時間をかけて要求内容が決まったと思ったら、声の大きい人が現れて要求があっさり変更されることが無いように、ステークホルダーのプロジェクトへの影響度合いを知っておくことも重要です。
あくまでもプロジェクトの目的・目標を達成することが前提になりますが、ステークホルダーの関係性やプロジェクトへの影響度合いを見定めて、円滑にプロジェクトが進む方向に導いていきましょう。
ステークホルダー分析
プロジェクトの規模によりますが、ステークホルダーが多くなると全員に同じ対応を行うことは難しくなります。プロジェクトには期限がありますので、ステークホルダーにも優先順位をつけて対応することが必要になります。
業務やシステムに詳しい担当者を優先して要求事項をまとめても、影響度が低くて関心も無いステークホルダーであれば、影響度の高いステークホルダーによって要求が変わるかもしれません。
下図のように、プロジェクトへの影響度と関心度でステークホルダーを分類することで優先順位を明確にすることができます。それぞれのステークホルダーがどの位置に該当するかマッピングして整理しましょう。
ステークホルダーを監視する
プロジェクト開始時にステークホルダーを漏らさずに特定することが重要ですが、プロジェクトが動き出してから気づくステークホルダーもいるでしょう。
プロジェクトの状況によってはステークホルダーの影響度合いが変わることも考えられます。人事異動でステークホルダーが交代する場合がそれです。プロジェクトを進めていくうちに途中からステークホルダーが増員される場合もありますので、常にステークホルダーに変化が無いかを監視しましょう。
ステークホルダー一覧を作成する
ステークホルダーを特定できたらリストを作成しましょう。ステークホルダー一覧に記録すべき項目を下記にまとめます。
いずれもプロジェクトマネージャーは把握しておくべき内容です。重要度の高いステークホルダーは誰かを明確にし、ステークホルダーに適した提案を心掛けることで、プロジェクト運営を円滑に進めることができます。
| 項目名 | 項目内容 |
|---|---|
| 会社名 | ステークホルダーの会社名 |
| 組織名 | ステークホルダーの組織名（部門名） |
| 氏名 | ステークホルダーの名前 |
| 役職 | ステークホルダーの役職 |
| 役割 | プロジェクトの役割や職務 |
| 承認権限 | 決定事項に対する承認権限の有無 |
| 影響度 | プロジェクトにおける影響度合い（良い影響・悪い影響） |
| 関係性 | ステークホルダー間の関係性（対立関係・協力関係） |
| 重要度 | 総合した重要度の評価（例：大・中・小） |
各ステークホルダーが自覚すべきこと
プロジェクトに参画するステークホルダーはどのようなことを自覚すべきなのでしょうか？それぞれの立場で意識してほしいことを列挙します。
経営層に意識して欲しいこと
- プロジェクトへの積極的な参加とリーダーシップ
- 既存システムの問題・課題の正しい認識と改革意識
- プロジェクトの企画構想の明確化
業務部門に意識して欲しいこと
- 業務部門のリーダーシップ
- 自社全体の利益を優先した意思決定（部分最適ではなく全体最適）
- 現行業務の説明義務と業務プロセス改革意識
システム部門に意識して欲しいこと
- システム構築のプロジェクトマネジメント
- 既存システムの問題・課題の明確化と説明責任
- プロジェクトの目的に最適なシステム化要件の提案
ベンダ企業に意識して欲しいこと
- ビジネスパートナーとしてのプロジェクト参画
- プロジェクトマネジメント支援
- システム開発の品質確保
プロジェクトマネージャーに意識して欲しいこと
- 企画構想とシステム化対象の業務の理解
- 品質（Quality）、コスト（Cost）、納期（Delivery）の遵守と優先順位づけ
- プロジェクト状況の定期的な報告（状況変化時は随時報告）
ステークホルダーと協力関係を構築・維持しよう
プロジェクトの決定事項についてステークホルダーと合意形成を図り、プロジェクト運営を円滑に進めることはプロジェクトマネージャーの責務です。
そのためには、ステークホルダーとのコミュニケーションを適切に行い、お互いが協力し合える関係を構築し、プロジェクトが成功するまで維持する必要があります。
時にはプロジェクトマネージャーより上位の権限を持つステークホルダーに対して厳しい意見を述べたり意思決定を迫ることもあるでしょう。そのような場面で協力してもらえる関係をステークホルダーと築いていれば、プロジェクトは成功したも同然です。
それこそがプロジェクトマネージャーの腕の見せ所なのだと思いますが、プロジェクトの目的を見失わずに、誠心誠意尽くすことが何より必要なのではないでしょうか。
是非とも、今取り組んでいるプロジェクトのステークホルダーと協力関係を築き上げて欲しいと思います。
もし、ステークホルダーとのコミュニケーション計画に不安のある方は、プロジェクトで実施すべき会議体の種類とポイントの記事をまとめていますので、こちらも合わせてお読みください。ステークホルダーとより良い関係を築けることを願っています。
