プロジェクト目標の達成のためのステークホルダとのコミュニケーション
令和４年度 秋期 プロジェクトマネージャ試験 午後Ⅱ 問題の問２である。
問題文
システム開発プロジェクトでは，プロジェクト目標（以下，目標という）を達成するために，目標の達成に大きな影響を与えるステークホルダ（以下，主要ステークホルダという）と積極的にコミュニケーションを行うことが求められる。
プロジェクトの計画段階において，主要ステークホルダへのヒアリングなどを通じて，その要求事項に基づきスコープを定義して合意する。その際，スコープとしては明確に定義されなかったプロジェクトへの期待があることを想定して，プロジェクトへの過大な期待や主要ステークホルダ間の相反する期待の有無を確認する。過大な期待や相反する期待に対しては，適切にマネジメントしないと目標の達成が妨げられるおそれがある。そこで，主要ステークホルダと積極的にコミュニケーションを行い，過大な期待や相反する期待によって目標の達成が妨げられないように努める。
プロジェクトの実行段階においては，コミュニケーションの不足などによって，主要ステークホルダに認識の齟齬や誤解（以下，認識の不一致という）が生じることがある。これによって目標の達成が妨げられるおそれがある場合，主要ステークホルダと積極的にコミュニケーションを行って認識の不一致の解消に努める。
あなたの経験と考えに基づいて，設問ア～設問ウに従って論述せよ。
設問ア
あなたが携わったシステム開発プロジェクトの概要，目標，及び主要ステークホルダが目標の達成に与える影響について，800 字以内で述べよ。
設問イ
設問アで述べたプロジェクトに関し，”計画段階” において確認した主要ステークホルダの過大な期待や相反する期待の内容，過大な期待や相反する期待によって目標の達成が妨げられるおそれがあると判断した理由，及び “計画段階” において目標の達成が妨げられないように積極的に行ったコミュニケーションについて，800 字以上 1,600 字以内で具体的に述べよ。
設問ウ
設問アで述べたプロジェクトに関し，”計画段階” において生じた認識の不一致とその原因，及び “実行段階” において認識の不一致を解消するために積極的に行ったコミュニケーションについて，600 字以上 1,200 字以内で具体的に述べよ。
出題主旨
ステークホルダはプロジェクト目標の達成に様々な影響を及ぼす。プロジェクトマネジメント業務を担う者は，ステークホルダによって及ぼされる影響が目標の達成の妨げとならないように，ステークホルダと積極的にコミュニケーションを行う必要がある。
本問は，プロジェクト目標の達成に向けて，計画段階ではステークホルダの期待を的確にマネジメントするためのコミュニケーションについて，それぞれ具体的に論述することを求めている。論述を通じて，プロジェクトマネジメント業務を担う者として有すべき，ステークホルダマネジメントにおけるコミュニケーションに関する知識，経験，実践能力などを評価する。
採点講評
問題文中の事例や見聞きしたプロジェクトの事例を参考にしたと思われる論述や，プロジェクトの作業状況の記録に終始して，自らの考えや行動に関する記述が希薄な論述が散見された。プロジェクトマネジメント業務を担う者として，主体的に考えてプロジェクトマネジメントに取り組む姿勢を明確にした論述を心掛けてほしい。
計画段階におけるコミュニケーションについては，プロジェクトマネジメント業務を担う者として期待される経験が不足していると推察される論述が見受けられた。一方，実行段階におけるコミュニケーションについては，認識の不一致の原因や不一致の解消のためのステークホルダへの働きかけなどについて，具体的に論述できているものが多かった。プロジェクトマネジメント業務を担う者として，ステークホルダとの関係性の維持・改善を意識して，コミュニケーションのスキル向上に努めてほしい。
論文設計
章立てを作る
- プロジェクトの概要と目標，目標達成への影響
- プロジェクトの概要と目標
- 主要ステークホルダが目標達成に与える影響
- 計画段階のステークホルダの期待とその対処
- 主要ステークホルダの期待の内容
- 目標達成を妨げるおそれがあると判断した理由
- ステークホルダとのコミュニケーション
- 実行段階のステークホルダの認識不一致と解消
- ステークホルダの認識の不一致とその原因
- 認識の不一致解消のためのコミュニケーション
論文
第１章 システム開発プロジェクトの概要
１．１ システム開発プロジェクトの概要，目標
送配電事業を営むＡ社の事業部門では，ＤＸ推進のため設備保全システムの再構築プロジェクトを実施した。Ａ社事業部門の設備保全システムは，開発されてから約２０年間，大規模な改修が行われていない。
この再構築プロジェクトの目標は３つある。
- 業務プロセス見直しによるペーパーレス化
- 事業部門が管理する設備の保全データの一元管理を実現し，設備保全にアセットマネジメントの考え方を導入できるようにすること
- 設備保全システムのベースであるＳＡＰのバージョンアッププロジェクトが計画されており，そのプロジェクト開始までに本プロジェクトを完了させる（リリース時期は必達）
私はＡ社の事業部門のプロジェクトマネージャ（以下，ＰＭ）として，本プロジェクトに参加した。
１．２ 主要ステークホルダが目標に与える影響
本プロジェクトの主要ステークホルダは，Ａ社社長・事業部長の経営層，設備保全システムを使用する現場の事業部員である。事業部門では送電・変電・通信の設備を管理しており，それぞれの設備の保全を行っている。
経営層は，業務プロセスの見直しや設備保全データの一元化のための業務要件を最終決定するため，スコープの範囲や確定時期に影響を与える。プロジェクトの完了時期を厳守するためには，経営層の意思決定時期がマイルストーンとなる。
事業部員は，システムを利用する立場にあるため，業務プロセスの見直しについて受け入れてもらう必要がある。また，送電・変電・通信の各分野で業務プロセスの見直しのレベル感を一致させておく必要がある。システム再構築により設備の保全データを一元管理できるようになったとしても，事業部員がシステムを使わなければ，データの蓄積ができず，目標を達成できない。
第２章 計画段階のステークホルダの期待とその対処
２．１ 主要ステークホルダの期待の内容
経営層は，全社で取り組むＤＸ推進の方針に沿って，設備保全に関する業務プロセスを抜本的に見直すことを期待している。また，高経年化した送変電設備の更新計画にアセットマネジメントの考え方を取り入れるため，設備の保全データを一元的に管理できることを期待している。
事業部員は，設備保全システムで初めての大改修により，設備の巡視や点検の記録が入力しやすくなることを期待している。また，業務プロセス見直しによるペーパーレス化では，業務遂行に支障がないようにしてほしいと望んでいる。
２．２ 目標の達成を妨げるおそれがあると判断した理由
業務プロセス見直しの範囲が不明確であると要件がまとまらない。また，要件が増える可能性がある。また，事業部員が送電・変電・通信の現在の業務にこだわり，新たな業務要件を受け入れないおそれがある。
設備保全に関するデータを一元的に管理できるようシステムを再構築したとしても，ユーザがシステムを使わなければデータの蓄積が行われない。
業務プロセスの見直し要件が確定する時期の遅れや要件の増加によっては，システム再構築の完了が遅れる可能性がある。
２．３ ステークホルダとのコミュニケーション
ステークホルダの意思決定者を見極めて，要件の調整を図るため，ステークホルダ俯瞰図を作成することにした。俯瞰図には，組織名，意思決定者，ステークホルダ間の相関を記載し，要件調整のキーマンを把握し，的確にコミュニケーションを図るようにする。
送電・変電・通信それぞれのキーマンと要件調整を行うが，合意形成できない場合は，意思決定者である経営者の判断を仰ぐようにする。
業務プロセス見直しの範囲，システム開発時期を早期に確定させるため，Ａ社の経営会議でプロジェクトの方向性について審議を行った。プロジェクトの必要性，スコープ，開発時期を論点に審議を行い，了承された。これにより，本プロジェクトのスコープ，開発時期が確定できた。
第３章 実行段階のコミュニケーション
３．１ 実行段階において生じた認識の不一致とその原因
実行段階において，業務プロセスを確定する際，送電・変電・通信で見直した業務プロセスで足並みが揃っていないことが判明した。なぜ，足並みが揃っていないか，要件調整のキーマンにヒアリングしたところ，システム再構築の目標のうち業務プロセスの見直しについて具体化されておらず，各分野のキーマンで捉え方が異なることが原因と判明した。
また，巡視・点検記録を入力する画面の要件定義を行う際，事業部員が参加していなかった。システムベンダーに確認したところ，要件調整のキーマンが参加しており，事業部員の参加は不要と考えていたとのことであった。
３．２ 実行段階において積極的に行ったコミュニケーション
システム再構築の目標を全ステークホルダーで共有するため，業務プロセス見直しの目標を具体化した資料を作成した。資料作成に当たっては，経営層と意見交換を行い，経営層の思いを反映させ，了承を得た。その資料をもとに経営層自らシステム再構築の目標を語ってもらうことで，関係者全員が達成すべき目標を理解した。これにより，送電・変電・通信の業務プロセス見直しの足並みを揃えることができた。
システムを実際に使う事業部員の納得が得られなければ，再構築したシステムを事業部員が使用しない。そのことをシステムベンダーに伝え，画面設計の要件定義には，事業部員が参加してもらえるよう調整した。毎回，事業部員が要件定義に参加するのは困難なため，システムベンダーで入力画面のプロトタイプを作成してもらい，事業部員がプロトタイプでレビューを実施できるように配慮した。入力画面について，事業部員の意見を取り入れることで，ペーパーレス化しても業務に支障がないと，事業部員の納得感を得ることができた。
