見出し画像

【PMBOK対応】PM試験の知識体系まとめ(#2 スコープ編)

概要

スコープマネジメントとは、プロジェクトの「範囲」を決定・コントロールすることである。
範囲の指標は「成果物」と「タスク」であり、これが決まらないと他のプロセスが進められないため、計画はプロジェクトの初期段階に行う。

2スコープマネジメント

#2.1 スコープ・マネジメントの計画

プロジェクトにて、スコープがどのようにマネジメントされるかの「ガイダンス」と「方向性」を示す。

#2.2 要求事項の収集

要求事項を、プロジェクト目標に合致させるためのプロセス。
ステークホルダーのニーズ・要求事項を定義・決定・文書化し、マネジメントするプロセス。
ここでは優先順位を付けるところまで行い、決定するのは「スコープの定義」プロセスで行う。

#2.3 スコープの定義

「プロジェクト・スコープ記述書」を作成するプロセスである。

画像2

■#2.3.1 スコープとは
プロジェクト成果物(プロダクト・サービス・成果・文書等)一式のことである。
「成果物」と違い、「非機能要件」等の実物として残らないものも含まれる。

■#2.3.2 スコープ記述書
以下の観点を記述した文書である。
この観点を常に忘れないようにしてほしい。

スコープ記述書

①受入基準
成果物を受け入れるために必要な条件である。
「#5 品質」で触れる、「品質尺度」を用いる場合が多い。

②成果物
プロジェクト完了後、スポンサーへ引き渡される、プロダクト・サービス・文書等のことである。
プログラムソースや設計書・マニュアル等がこれにあたる。

③プロジェクトからの除外事項
スコープに含めない成果物や作業のことである。
これを記載することで、ステークホルダの過度な期待によるリスクを低減できる。

④制約事項
プロジェクトやプロセスの実行に、限度がある要素。
「自由が無い部分」と考えても良い。
例)予算・納期・マイルストーン・要員数等

⑤前提事項
プロジェクトを進めるうえで、「確実である」と断言できる要素。
もしくは、「期待して良い要素」と考えても良い。
例)連携するシステムはサービス終了しない、業務委託先との契約は継続する、PMが病欠することは無い・・等

#2.4 WBSの作成

成果物や作業を、細分化・分解(ブレークダウン)し、管理しやすい図(WBS)を作成する。

画像4

【参考】アウトプットの「スコープ・ベースライン」とは
・プロジェクト・スコープ記述書
・WBS(後述)
・WBS辞書(後述)
を合わせた総称である。

#2.4.1 WBS
プロジェクトを完了させるために必要な作業を洗い出し、細分化・分解し、階層構造で表現したもの。
以下ルールがある。
- 上位の要素から下位の要素に向かい、詳細化・分解される。
- 最上位要素にプロジェクト名を入れる
- 最下位の要素を、ワークパッケージという
- 最上位要素の直下に、「プロジェクトマネジメント(もしくはプロジェクト管理)」を入れる
- 下図のように識別コードを入れるとわかりやすいが、必須ではない。

画像5

#2.4.2 WBS辞書
WBSを補完する文書であり、WBS1つに対しWBS辞書1つが作られる。
しかし全ワークパッケージに対して作成されることは少なく、必要に応じて使われる。

【参考】WBS辞書の具体的な内容
識別コード、作業内容、前提条件、制約条件、担当組織、スケジュール/マイルストーン、関連するスケジュールのアクティビティ、必要な資源、見積もったコスト、品質要求、受入基準、技術的参照資料、合意情報

#2.5 スコープの妥当性確認

完成した成果物に対し、顧客・スポンサーがレビューし受け入れするプロセス。
要求・受入基準を満たしているか検査する。
「#5.2 品質のマネジメント」で品質確認できた成果物が、顧客に受け入れられることで、「受入れ済み要素成果物」となる。

#2.6 スコープのコントロール

計画したスコープの、監視とコントロールを行う。
ここでは、プロジェクトマネジメント計画書の「ベースライン(計画)」と「作業パフォーマンスデータ」を利用し、「差異分析」「傾向分析」を行う。
そこで発見された課題に対し是正処置・予防措置を含む「変更要求」がアウトプットされる。

画像6

#2.6.1 差異分析
ベースラインと実績を比較し、差異が閾値内であるか、
または
是正処置
②予防処置
が適切か判断するために行う。

#2.6.2 傾向分析
パフォーマンスが改善しているか悪化しているかを判断するため、継続して分析する。
例)アーンドバリューマネジメント(EVM)等

謝辞

以下利用させていただきました。感謝申し上げます。
いらすとや
XMind

この記事が気に入ったらサポートをしてみませんか?