5.1 スコープ管理の概要
やるべき仕事を決める
5.1.1 製品範囲とプロジェクト範囲
(1) プロジェクトの境界を明確にする
(2) プロジェクトの実施状況のモニタリング
(3) 事業範囲の拡大防止
5.1.2 スコープ管理の重要性
プロジェクト スコープ マネジメントとは、プロジェクト チームのメンバーに、目標を達成するために具体的にどのような作業を行う必要があるかを知らせ、各作業におけるプロジェクトに関与するすべての関係者の明確な分業インターフェイスと責任を明確にすることです。
スコープ管理により、プロジェクトのコスト、スケジュール、およびリソースの見積もりの精度が向上します。プロジェクト スコープ管理は、プロジェクトの成功に影響します。
5.1.3 スコープ管理プロセス
スコープ管理の標準化、要件の収集、スコープの定義、WBS の作成、スコープの確認、スコープの管理の 6 つのプロセスがあります。
5.2 計画範囲管理
5.2.1 スコープ管理計画
プロジェクトの範囲がどのように定義、開発、監視、制御、および検証されるかを説明するプロジェクトまたはプログラム管理計画の一部です。
5.2.2 要件管理計画
要件管理計画では、プロジェクトのライフ サイクル全体で要件を分析、記録、および管理する方法について説明します。要件管理の内容には、次のものが含まれます。
(1) さまざまな需要活動を計画、追跡、報告する方法
(2) 需要管理に必要な資源
(3) 研修計画
(4) プロジェクト関係者が要件管理に参加するための戦略
(5) プロジェクトの範囲と要求事項との不一致を判断するための基準と是正手順
(6) 要件追跡構造
(7) 構成管理活動
5.3 要件の収集
5.3.1 要件の分類
(1) ビジネス要件
(2) ステークホルダーのニーズ
(3) ソリューション要件
(4) フィルター要件
(5) プロジェクト要件
(6) 品質要求事項
5.3.2 要件を収集するためのツールと技法
1.面接：時間調整が難しい、録音が難しい、コミュニケーションにスキルが必要
2. フォーカス グループ: グループ インタビュー
3. ガイド付きセミナー:
4.グループイノベーション技術：
1) ブレーンストーミングの方法
2) 公称パネル技法
3) デルファイ技術
4) コンセプト・マインドマップ
5) アフィニティ ダイアグラム: 核心はブレインストーミング法
6) 多基準決定分析
5. グループ意思決定の技法: コンセンサス、多数決原理、相対多数原理、独裁
6.アンケート
7. 観察
8. プロトタイプ法
9. ベンチマーク
10. システム相互作用図
11.ファイル分析
5.3.3 要件文書
トピックには、ビジネス要件、利害関係者の要件、ソリューション コミュニケーション、プロジェクト要件、移行要件、要件関連の前提条件、依存関係、および制約が含まれますが、これらに限定されません。
5.3.4 要件の追跡
1. デマンドトラッキングの内容：フォワードトラッキングとリバーストラッキングを含む双方向のトレーサビリティが必要
2. 要件トレーサビリティ マトリックス: 製品の更新をソースから要件を満たす成果物にリンクするフォーム。
(1) ビジネスの必要性、機会、目標および目的
(2) プロジェクトの目的
(3) 事業範囲
(4) 製品設計
(5) 商品開発が可能
(6) テスト戦略とテストシナリオ
(7) 高度な要求から詳細な要求へ
5.4 スコープの定義
5.4.1 範囲を定義するためのツールと技法
1.製品分析：製品分解、システム分析、需要分析、システム工学、価値工学、価値分析などを含む。
2. 代替案の生成: (1) 代替案の分析 (2) 水平思考
5.4.2 プロジェクト スコープ ステートメント
1. スコープステートメントの内容
(1) 製品範囲の説明
(2) 合格基準
(3) 成果物
(4) プロジェクトの除外事項
(5) 制約
(6) 仮定
2. スコープ ステートメントの役割
(1) 範囲の決定
(2) 通信基盤
(3) 企画・統制文
(4) 変更基準
(5) 計画根拠
5.5 作業分解図 (WBS) を作成する
5.5.1 WBS の階層
1. マイルストーン: 成果物またはフェーズの正式な完了を示します。
2. 作業パッケージ: WBS の各ブランチの一番下にある成果物またはプロジェクトの作業コンポーネントです。8/80 ルール (80 時間ルール) では、作業パッケージのサイズが完了するまでに少なくとも 8 時間かかり、合計完了時間が 80 時間を超えてはならないことが推奨されています。
3. コントロール アカウント: スコープ、予算 (リソース計画)、実際のコスト、およびスケジュールを統合し、それらをアーンド バリューと比較してパフォーマンスを測定する管理コントロール ポイント。
4. 計画パッケージ: コントロール アカウントの下では、作業内容の WBS コンポーネントはわかっていますが、詳細なスケジュール アクティビティはまだ利用できません。
5. WBS ディクショナリ: WBS を作成する過程で、WBS の各部分にアカウント パスワード識別子を付与する必要があります。これは、コスト、進行状況、およびリソース使用情報の要約の階層構造です。
5.5.2 分解
1. 分解の原理:
(1) 機能的または技術的原理
(2) 組織体制
(3) システムまたはサブシステム
2.作業工程
3. 注意事項
(1) 成果物指向であること
(2) プロジェクトの範囲に適合していること
(3) WBS 抑うつは計画と制御をサポートするべきである
(4) WBS の要素は責任を負わなければならない
(5) WBSの案内
(6) WBS には、プロジェクト管理業務だけでなく、下請け業務も含める必要があります。
(7) WBSDE の作成には、すべての (主要な) プロジェクト利害関係者の参加と、プロジェクト チーム メンバーの参加が必要です。
(8) WBS は不変ではなく、完了後も WBS を変更する必要がある場合があります。
5.5.3 WBS の役割
(1) プロジェクトの範囲を明確かつ正確に説明する
(2) プロジェクトの境界を明確にする
(3) 独立した各ユニットに人員を配置する
(5) 計画、予算編成、スケジューリング、原価計算の共通基盤を確立する
(6) プロジェクトの作業をプロジェクトの財務会計にリンクする
(7) 作業内容と作業順序の決定
(8) 需要クリープを促進する
5.6 確認範囲
5.6.1 検証範囲の概要
1. 範囲を決定する手順:
(1) スコープ確認がいつ必要かを判断する
(2) 確認範囲を特定するために必要なインプット
(3) 形式的範囲の基準と要素の決定
(4) スコープ確認会議の構成手順の決定
(5) 組織範囲確認会
2. 確認事項
(1) 成果物が明確で識別可能かどうか
(2) 成果物に明確なマイルストーンがあるか
(3) 明確な品質基準がある
(4) 見直しやコミットメントが明示されているか
(5) プロジェクトの範囲は、製品またはサービスを完成させるために実行する必要があるすべての活動をカバーしていますか?
(6) 事業範囲のリスクが高すぎませんか？
5.6.2 利害関係者の懸念
管理者は、プロジェクトのスケジュール、資金、およびリソースに対するスコープの影響を指すプロジェクト スコープに焦点を当てます。
顧客の主な関心事は、プロジェクトの成果物が製品またはサービスを完成させるのに十分かどうかに関係する製品の範囲です。
プロジェクト マネージャーは主に、成果物が十分であり、完了する必要があるかどうか、および時間、資金、およびリソースが十分であるかどうかに関心があります。
プロジェクト チーム メンバーは、自分が関与し、責任を負うプロジェクト スコープの要素に主に関心を持っています。
5.6.3 いくつかの用語の比較
1. スコープの確認と製品の検証
2. 範囲と品質管理を確認する
3. スコープとプロジェクトの終了を確認する
5.7 制御範囲
1. 範囲変更の理由
2. スコープが管理作業になる