プロジェクトマネージャ試験のステークホルダのポイント（情報処理教科書プロジェクトマネージャITのプロ46 (著), 三好康之 (著)の第１章）

プロジェクトマネージャ試験のステークホルダのポイント
1. ステークホルダ
■ソフトウェア開発の名著の紹介

プロジェクトマネージャ試験のステークホルダのポイント

情報処理教科書プロジェクトマネージャ 2021年版

を読んでインプットした内容を、要点を引用したり、重要だと思った点を要約したり、
私の感想や考察することで、このブログでアウトプットしようと思います。

情報処理教科書プロジェクトマネージャ 2021年版

作者:ITのプロ46,三好康之
発売日: 2020/09/23
メディア: 単行本（ソフトカバー）
本書は、プロジェクトマネージャ試験に合格するための知識とテクニック、
学習方法など、さまざまな情報を結集した対策テキストです。

の「第1章　ステークホルダ」のポイントを紹介します。

第１章　ステークホルダ

1. ステークホルダ

問題発生時にPMの取れる対策の最有力候補の一つが、人に働きかけること（体制の組換え、要員の交代など）になる。

1.1 基礎知識の確認

▼プロジェクト資源マネジメントとは
PMBOKでは
「プロジェクトを成功して完了させるために必要な資源を特定し、入手して、
そのマネジメントするプロセスとなる」と定義されている。
ここでいう資源とは、
チーム資源（プロジェクトメンバ、要員）
と
物的資源（装置、資材、施設、インフラストラクチャ）
のことである。

▼プロジェクトコミュニケーションマネジメントとは
PMBOKでは
「プロジェクト情報の計画、収集、作成、保管、検索、マネジメント、
コントロール、監視、最終的な廃棄を適時かつ適切な形で確実に行うためにに
必要なプロセスからなる。」と定義されている。

▼プロジェクトステークホルダーマネジメントとは
PMBOKでは
「プロジェクトに影響を与えたり、プロジェクトに影響を受けたりする
可能性がある個人やグループを特定し、ステークホルダーの期待とプロジェクトへの影響力を分析し、
ステークホルダーがプロジェクトの意思決定や実行に効果的に関与できるような
適切なマネジメント戦略を策定するための必要なプロセスからなる。」と定義されている。

1.1.1 要員数の計算

STEP 1. 必要要員数の計算
開発規模と納期の制約に、過去の経験値（会社にあるプロジェクト管理に関するデータ、資産）から、各月の必要要員数を算出する。

STEP 2. 前提条件（制約条件）への配慮
例のような前提条件を与えられ、それに基づいて要員配置を
調整する。

- 要件定義と外部設計は自社要員だけで実施する（ノウハウ流出の防止等）
- 外部設計は8割以上自社要員（教育・育成の観点等）
- プログラミング要員は自社では抱えない方針
- 同じ部署のメンバーで体制を作ることが前提（SIベンダー）
- 6人しかいない
- 全員が常に待ち時間がないようにする。
- 他の業務や他のプロジェクトで忙しい（専任できない、時間的制約など）

STEP 3. 山積み、山崩し
　制約条件の中でも、「A社要員を、全期間を通して一定の人数＝12人にする」
という条件は重要であるが、この点に配慮せずに、必要要員数を積み上げたものを「山積み」という。
作業の平準化のために、一定の人数にしたり、増減を最小限にする作業を
「山崩し」という。

1.1.2 プロジェクト体制

　午後の問題では、プロジェクト体制図（プロジェクト組織図）が示される場合が多い。
　体制図がない場合は、文章のみの場合は、余白に体制図を描いて整理するのが望ましい。

●ステークホルダ（利害関係者）
　ステークホルダとは、プロジェクトによってプラスまたはマイナスの影響を受ける利害関係者である。
プロジェクトの登場人物と呼んでもいいが、プロジェクトに直接関与する人やそのプロジェクトの影響を受ける人も含む概念になる。

●スポンサー
　スポンサーはプロジェクトに対する財政的支援（費用の負担）を決定、提供する人物である。顧客企業の社長や決裁権を持つCIOで、プロジェクト責任者とも呼ばれ、
プロジェクトマネージャより上位に位置するとされる。プロジェクトマネージャのコントロールを超える問題に対応する人物である。

●ステアリングコミッティ
　PMBOKでは例示されていないが、プロジェクトにおける意思決定機関としてステリングコミッティを組織する場合がある。

●プロジェクトチーム
　PMBOKでは、プロジェクトマネージャ、チームリーダ、メンバ、その他を
プロジェクト・チームとして例示している。

●利用者側（業務担当者）
　自社プロジェクトの場合、PM配下に、実際の利用者（業務担当者）を配置することもあるが、利用者側が、異なる法人である場合は、PMに指揮命令権がないことにより、別プロジェクトとなる。

1.1.3 責任分担マトリックス

プロジェクト・スコープ・マネージメントで作成されたWBS
の作業項目ごとに、資源と責任の関係をまとめた表を
責任分担マトリックス（責任分担表・RAM：Responsibility Assignment Matrix)という。

責任分担マトリックスは、
工程、作業項目毎に、プロジェクトメンバーが、どの責任をおっているか、
責任は、
R(Responsible) 実行責任：作業を実際に行い、成果物などを作成する。
A(Accountable) 説明責任：作業を計画、進捗や成果物の品質を管理し、作業の結果に責任を負う。
C(Consult) 相談対応：直接は作業しないが、助言や相談など作業の支援をする。
A(Inform) 情報提供：作業の結果報告、進捗の状況管理、作業遂行に必要な情報を提供する。

●責任分担マトリックスの必要性
責任分担マトリックスな必要な理由は以下の３点である。
①　人的資源の効率性や必要最小限なものが一覧で確認できる。
②　メンバーの能力や実績が不足している場合、教育、調査、有識者の支援などの対策
が必要で、どんな対策が必要か判断しやすい。
③　関係者と事前に合意形成することで、メンバの自覚や参画意識を高める。

●体制構築のポイント
体制構築時の留意点は以下の通りである。
- 特定の人に負荷は集中していないか。
- 専任、兼任は適当か。
- 指揮命令関係は適当か。指揮者の命令、年齢、経験は問題ないか、複数の命令系統になる場合の優先度を明確にしておく。
- 教育や育成、問題発生時の支援（フォロー）については考慮されているか。　

1.1.4 要員管理

要員管理の目的は、組織の見直し、見直しの必要性の判断である。
留意点としては、
要員のモチベーションの維持、
要員の離脱、交代、増員に対する判断、
プロジェクト内での要員教育
である。
具体的な方法は、
特定の要員に起因する生産性低下がないかモニタリングしたり、
計画された育成計画を立案、実行する。

●要員に関する問題の早期発見
　
要員別の進捗管理表や要員別の工数（生産性）管理、勤怠管理や現場の状況で、問題を早期発見して、
進捗遅延、費用超過、品質不良を防止する。

1.1.5 組織の制約

プロジェクト計画時に影響を受ける制度の確認
　プロジェクトに関連する企業がISMSやプライバシーマーク制度などの認証制度を取得している場合、
作業内容や作業場所の制約を確認する。
　認証の取得がなくても、作業内容や作業場所の制約がある場合もあり、確認が必要であうう。
　その場合、機密情報の取り扱いルール、取り扱い計画を定める必要がある。
機密情報の取り扱いには以下の対策が必要とされる

①　技術的対策
　ストレージの暗号化やネットワークのファイヤーウォールの設定などである。

②　人的対策
　不注意や不正に大差る対策で、資料の保管場所の施錠や廃棄の実施などである。

③　物理及び環境的対策
　開発環境の施設の入退室管理やネットワークの遮断などである。

④　その他
　ルールの周知、教育や遵守状況のチェックなどである。

1.2　午前Ⅱ　章別の対策

以下のテーマで、午後Ⅱの問題は出題された。

①　チーム編成と運営

②　チーム育成

③　ステークホルダーや利用者の関係

④　機密管理

⑤　人間関係のスキル

1.3　午後Ⅰ　章別の対策

【優先度１】必須問題、時間を測って解く　＋　覚える問題
午後１の対策として、問題文と設問、回答をセットで覚えると午後2の対策にもなる。
そういった問題は必須問題である（平成10年度問２や平成30年度問３など）。

【優先度２】推奨問題、時間を測って解く問題
午後1の対策として、過去問題を時間は図って解くのが望ましい。

1.4　午後Ⅱ　章別の対策

過去に出題された午前Ⅱ問題のテーマは以下の通りである。

■チーム編成：チーム編成
■要員計画：山積みの計算・要員数の計算
■責任分担マトリックス：責任分担マトリックス・RACIチャート
■教育技法：教育技法・問題解決能力の育成
■文書構成法：帰納法・軽重順序法
■ステークホルダ：ステークホルダ・プロジェクトガバナンスを維持する責任者
■資源マネージメント：ブルックスの法則・コンフリクトマネジメントの指針・組織とリーダーシップの関係・
集団思考・タックスモデル
■資源サブジェクトグループ：資源コントロールプロセス
■コミュニケーション：コミュニケーションマネジメント計画書の内容