• 戻る（PMP：計画）

• 要求事項収集技法を使用して、

  • 計画会議
  • ブレーン・ストーミング（データ収集）
  • フォーカス・グループ（データ収集）

• ステークホルダーと共にプロダクトの詳細を評価し、

  • 要求事項
  • 制約条件
  • 前提条件

• スコープに関する記述を行う。

  • プロダクト・スコープに関する記述を行う。

    • 成果物（プロダクト / サービス / 所産）に含まれるもの
    • 成果物（プロダクト / サービス / 所産）に含まれないもの

  • プロジェクト・スコープに関する記述を行う。

    • プロジェクト・マネジメントに含まれるもの
    • プロジェクト・マネジメントに含まれないもの

• これらは、WBS作成の土台になる。

  • プロダクトをマネジメントするために、スコープを分解して、WBS作成する。

※ 計画プロセス群の肝（≒ SIだと要件定義などと呼ばれるフェーズ）。

※ 本ページで頻出する「成果物（プロダクト / サービス / 所産）」は、
　PMP：共通の該当節で定義されている用語。

• 成果物（プロダクト / サービス / 所産）の機能
• スコープの完了は、プロダクト要求事項に照らして測定される。

• 成果物（プロダクト / サービス / 所産）を産み出すために実行する作業
• スコープの完了は、プロジェクト・マネジメント計画書（PMP：計画の該当節を参照）に照らして測定される。

表中で参照しているページは以下（元の PukiWiki ではセル内がリンクだった）。

• PMP：立上（プロジェクト憲章、前提条件ログ、ステークホルダー登録簿、 プロジェクト・マネジメント・ビジネス文書、合意書）
• PMP：計画（プロジェクト・マネジメント計画書、ステークホルダー・エンゲージメント計画書）
• PMP：計画 - 資源（品質マネジメント計画書）
• PMP：環境（組織体の環境要因、組織のプロセス資産）
• PMP：実行（教訓登録簿）

#	プロセス	インプット	ツールと技法	アウトプット	知識エリア
2	スコープ・マネジメント計画	・プロジェクト憲章 ・プロジェクト・マネジメント計画書 　　(p) 品質マネジメント計画書 　　(p) プロジェクト・ライフサイクルの記述 　　(p) 開発アプローチ ---------- ・組織体の環境要因 ・組織のプロセス資産	・専門家の判断 ・データ分析 　　(p) 代替案生成 ・会議	★スコープ・マネジメント計画書 ★要求事項マネジメント計画書	プロジェクト・スコープ・マネジメント
3	要求事項収集	・プロジェクト憲章 (p) プロジェクト・マネジメント計画書 　　★スコープ・マネジメント計画書 　　★要求事項マネジメント計画書 　　・ステークホルダー・エンゲージメント計画書 (p) プロジェクト文書 　　(p) 前提条件ログ 　　(p) 教訓登録簿 　　★ステークホルダー登録簿 (p) プロジェクト・マネジメント・ビジネス文書(6) (p) 合意書 ---------- (p) 組織体の環境要因 (p) 組織のプロセス資産	・専門家の判断 ・データ収集 　　(p) ブレーン・ストーミング 　　・インタビュー 　　・フォーカス・グループ 　　・アンケートと調査 　　・ベンチマーキング ・データ分析 　　・文書分析 ・意思決定 　　(p) 投票 　　(p) 独裁的意思決定 　　(p) 多基準意思決定分析 ・データ表現 　　(p) 親和図法 　　(p) マインドマップ法 ・人間関係とチームに関するスキル 　　(p) ノミナル・グループ技法 　　・観察と対話 　　・ファシリテーション ・コンテキスト・ダイアグラム ・プロトタイプ	★要求事項文書 ★要求事項トレーサビリティ・マトリックス	〃
4	スコープ定義	・プロジェクト憲章 (p) プロジェクト・マネジメント計画書 　　★スコープ・マネジメント計画書 (p) プロジェクト文書 　　(p) 前提条件ログ 　　★要求事項文書 　　(p) リスク登録簿 ---------- (p) 組織体の環境要因 ・組織のプロセス資産	・専門家の判断 ・人間関係とチームに関するスキル 　　・ファシリテーション ・データ分析 　　(p) 代替案生成 ・意思決定 　　(p) 多基準意思決定分析 ・プロダクト分析	★プロジェクト・スコープ記述書 ・プロジェクト文書更新版 　　(p) 前提条件ログ 　　・ステークホルダー登録簿 　　・要求事項文書 　　・要求事項トレーサビリティ・マトリックス	〃
5	WBS作成	(p) プロジェクト・マネジメント計画書 　　★スコープ・マネジメント計画書 (p) プロジェクト文書 　　★要求事項文書 　　★プロジェクト・スコープ記述書 ---------- ・組織体の環境要因 ・組織のプロセス資産	・専門家の判断 ・要素分解	★スコープ・ベースライン 　　・WBS 　　・WBS辞書 ・プロジェクト文書更新版 　　(p) 前提条件ログ 　　・要求事項文書 　　・プロジェクト・スコープ記述書 　　・プロジェクト・マネジメント計画書 　　・その他のプロジェクト文書	〃

• スコープ（成果物（プロダクト / サービス / 所産））から、プロジェクトの作業であるものと無いものを選別する。
• 「スコープ・マネジメント計画書」と「要求事項マネジメント計画書」の２つのアウトプットを生成する。

• プロジェクトの背後の環境・目的を理解する。

• 対象
  成果物（プロダクト / サービス / 所産）

PMP：立上の該当節を参照。スコープに影響。

• プロジェクトの目的
• ハイレベルの要求事項
• 一部の成果物（プロダクト / サービス / 所産）の記載

PMP：計画の該当節を参照。

PMP：環境の該当節を参照。スコープの管理方法に影響。

• 市場の状況

• 組織の

  • 文化、人事管理
    • 人的資源の上申のスキル、知識、能力
  • 経済な状況
  • インフラストラクチャー
    • 物理的
    • 技術的

PMP：環境の該当節を参照。

• スコープの管理方法に影響

  • 方針・ガイドライン、手順

    • 組織の
    • 業界の

  • 過去の情報
    規模とスコープが類似している過去のプロジェクト。

PMP：立上の該当節を参照。

• プロジェクト・スポンサー
  （オーナー、イニシエータ、顧客であることもある）

• 上級管理職（立上の人物/組織）

• 業界の専門家

• 専門的な訓練を受けたチーム・メンバ

• 類似プロジェクトの経験のあるPM

スコープ・マネジメント計画書に含める内容を会議で決定する。

• スコープ決定のプロセスを記述する。

  • スコープの定義方法
  • スコープの検証方法
  • スコープの制御方法
  • スコープの変更方法

• WBSを容易に作成できるようにする。

• 成果物（プロダクト / サービス / 所産）の検証/受入の方法を記述する。

• プロセスの相互作用と依存関係から、
  変更の監視・制御の方法を記述する。

• 構成要素

  • プロジェクト・スコープ記述書の作成プロセス
  • WBSの作成、承認、維持のプロセス
  • 成果物（プロダクト / サービス / 所産）の正確性を検証し、受入をするプロセス
  • プロセスの相互作用と依存関係から、変更の監視・制御のプロセス。
    （変更要求（PMP：実行の該当節を参照）の手順・書式を入手する方法などを含む）

• プロジェクト全期間に渡って要求事項を
  分析/文書化/追跡/報告/マネジメントする方法を記述する。

• スコープ・マネジメント計画書と似ているが、
  プロジェクトの要求事項に重点を置いている点が異なる。

• このプロセスの鍵は要求事項のマネジメントにある。

  • フェーズ間の関係（PMP：共通の該当節を参照）は、要求事項のマネジメント方法に影響を与える。

  • 例：

    • 直列関係：フェーズの開始時に要求事項が完成している必要がある。
    • 並列関係：段階的に詳細化されるため、開始時に完全に定義されない。

• プロセスの相互作用と依存関係から、
  変更の監視・制御の方法を記述する。

• 構成要素

  • 要求事項の各アクティビティの実行方法

    • 計画アクティビティ
    • 追跡記録アクティビティ
    • 報告アクティビティ

  • 要求事項の

    • 優先度付
    • 追跡に使用される評価基準
    • 変更の要求/追跡記録/分析
      （他のコンフィグレーション・マネジメントのアクティビティとともに）

  • トレーサビリティ・マトリックス

    • 含める要素
    • 要素の属性

• 成果物（プロダクト / サービス / 所産）の完成形態を定義する。

• ここでは、まず、スコープに含まれるものを収集する。

• 収集された要求事項をプロジェクトに含めるかどうかは次のプロセスで決定する。

• ステークホルダーの関心・期待、ニーズ、要望（要求事項）を理解するため、
  立ち上げプロセス群のアウトプットから、要求事項を収集・定量化し、文書化する。

  • プロジェクト憲章（PMP：立上の該当節を参照）
  • ステークホルダー登録簿（PMP：立上の該当節を参照）

• 要求事項

  • 測定 / 追跡 / テストが可能であるものであること。

  • 以下のカテゴリーがある。

    • ビジネス
    • ステークホルダー
    • ソリューション
    • 機能
    • 非機能
    • 移行
    • プロジェクト
    • 品質

• コミュニケーション・スキルが重要になるプロセス。

  • 心を読む力
  • 要求事項を引き出す的確な質問を投げかける。

• ターゲット

  • ステークホルダー

    • 多くの場合、どのような成果物（プロダクト / サービス / 所産）が望ましいか解っている。
    • しかし、それを上手く表現できないことがある。

  • （バリュー・チェーン中の）
    ビジネス・プロセスのオーナー

    • 中間管理職やライン・マネージャ
    • ライン（製造）以外のビジネス・エキスパート

• 目標達成のための成果物（プロダクト / サービス / 所産）の特性を記述する。

  • 満たすべき条件
  • 満たすべき機能

PMP：立上の該当節を参照。

以下のものがある。

• ブレーン・ストーミング
• インタビュー
• フォーカス・グループ
• アンケートと調査
• ベンチマーキング

詳細は、PMP：グループ意思決定技法を参照。

• 文書分析
  • 組織のビジネス計画
  • マーケティング計画
  • 契約、ビジネス規則
  • 戦略計画

以下のものがある。

• 投票
• 独裁的意思決定
• デルファイ法
• 多基準意思決定分析

詳細は、PMP：グループ意思決定技法を参照。

以下のものがある。

• 観察と対話
• ノミナル・グループ技法
• ファシリテーション

詳細は、PMP：グループ意思決定技法を参照。

• 成果物（プロダクト / サービス / 所産）のモックアップを開発してユーザに実験してもらう。
• ストーリー・ボードをベースにして、プロトタイプのフィードバックを得て修正する反復プロセス

• アクターとビジネス・プロセス（機器）の相互作用を視覚化する。
• UMLダイアグラムで言う所の、コンテキスト図に該当する。

要求事項を文書化する。

• プロジェクトが長期化すると

  • ステークホルダーは要求事項を忘れる。
  • また、要求事項は段階的に詳細化される。

• 従って、文書化してステークホルダーからの承認を得ることが重要。

• これをベースにプロジェクト全期間に渡って要求事項を分析/文書化/追跡/報告/マネジメントする。

• 要求事項が要求事項文書に記録される。

• また、ステークホルダーの署名が必要になる。

• 構成要素

  • プロジェクト

    • のビジネス・ニーズ
    • の達成したいビジネス目標
    • が選定された理由

  • 各種要件

    • 機能要件

    • 非機能要件

    • 品質要件

    • 受入基準
      発注元の要件を満たすか。

    • 引渡要件
      発注元の定常業務・エンドユーザの要件を満たすか。

    • サポートとトレーニングに関する要件

  • その他

    • ビジネス規則
    • 制約条件
    • 前提条件

#	要求事項	内容
1	ビジネス要求事項（PMP：立上の該当節を参照）	課題・好機など組織のハイレベルなニーズとPJ採用理由
2	ステークホルダー要求事項（PMP：立上の該当節を参照）	ステークホルダー（グループ）のニーズ
3	ソリューション要求事項	≒ プロダクト・スコープ
3-1	機能要求事項	機能要件
3-2	非機能要求事項	非機能要件
4	プロジェクト要求事項	≒ プロジェクト・スコープ
5	品質要求事項	スコープ妥当性確認（PMP：監視・制御 - その他の該当節を参照）に必要な条件や基準
6	移管および準備状況への要求事項	TO-BEを定常業務化するためのデータ移行、トレーニングなどの要求事項（移行計画的な）

• ココで記録・文書化するモノ

  • 要求事項の発生源
  • 要求事項の追跡の基準

• これにより、追跡を引渡 or 完了まで継続する。

• 記述項目
  マトリックスと言うよりリスト？

  • ID

  • 要求事項の説明（要求事項名）
    簡潔な、要求事項を特定可能な情報

  • 発生源

    • ビジネス・ニーズ
    • プロジェクト目標（スコープ / スケジュール / コスト / 品質）
    • WBS成果物
    • 成果物（プロダクト / サービス / 所産）の設計・製造

  • テスト・シナリオ
    要求事項のテスト方法とフェーズ

  • 優先度

  • オーナー
    要求事項のオーナー、合否判定も行う。

    • 状態

  • IPAの例、こちらの例はVモデルに準拠。

    • 要求仕様
    • システム設計書
    • 基本設計書
    • 詳細設計書
    • ソースコード
    • 単体検査仕様書
    • 結合検査仕様書
    • システム検査仕様書

• これにより、

  • 要求事項がプロジェクト目標、ビジネス目標にリンクされる。
  • プロジェクト完了時の事業価値の実現の可能性が高くなる。

• インプットをプロセス（ツールと技法）で処理してプロジェクト・スコープ記述書を作成する。

• プロジェクト・スコープの定義が
  成果物（プロダクト / サービス / 所産）の、
  プロダクト・スコープを厳密に定義することにつながる。

  • プロジェクトの成功に直結

    • プロセスの正確さと完全性に特に注意する必要がある。
    • 不完全な定義は、コスト増加、手直し、スケジュール遅れ、士気の低下を招く。

  • 収集された要求事項をプロジェクトに含めるかどうかはこのプロセスで決定する。

• 以下の作成と文書化にも利用される。

  • 成果物（プロダクト / サービス / 所産） 自体
  • 成果物（プロダクト / サービス / 所産）の生成に必要な作業

要求事項 → 成果物（プロダクト / サービス / 所産）の詳細な説明
予備的なスコープに含まれている情報を収集する。

PMP：立上の該当節を参照。

プロジェクトの最終結果がプロダクトであるとき最も役に立つ。

• インプット・アウトプット

  • インプット

    • プロジェクト目標
    • プロジェクト・スコープ記述書の構成要素

  • アウトプット（重要成功要因）
    合意された基準に基づいて生成されるようにプロジェクトをマネジメントする。

    • 要求事項（成果物（プロダクト / サービス / 所産）の仕様）
    • 成果物（プロダクト / サービス / 所産）（測定可能なゴールや目標の構成要素を記述）

• 構成要素

  • 価値

    • 価値分析（VA：Value Analysis）
    • 価値工学（VE：Value Engineering）

  • システム

    • システム分析（SA：System Analysis）
    • システム工学（SE：System Engineering）

  • プロダクト・ブレークダウン、要求事項分析（RA：Requirement Analysis）

プロジェクト作業を実行するための異なる技法・方法を発見する技法

• ブレーン・ストーミング（データ収集）

• 水平思考（ ---> 水平思考パズル）
  従来の論理的思考や分析的思考を垂直思考（既に掘られている穴を奥へ掘り進める）とし、
  既成の理論や概念にとらわれずアイデアを生み出す（新しく穴を掘り始める）方法。

  • ランダム発想法
    無作為に選び、興味分野と関連付けて発想を広げる。

  • 刺激的発想法
    誇張、またはその逆を行い、アイデアの源にする。

  • 挑戦的発想法
    既成事実を分析し、アイデアの源にする。

  • 概念拡散発想法
    ある概念を他の事物に広く応用する。

  • 反証的発想法
    説得力のある反証を試みる。

• 一対比較
  判断の対象となる選択肢を2つ一組とし、どちらがよりよいか選択する。

意思決定を参照。

人間関係とチームに関するスキルを参照。

詳細に、要求事項（重要成功要因）を再文書化する。

• 目的
  すべてのステークホルダーにスコープを理解してもらう。

  • プロジェクト・チームと顧客との合意書。
  • 意思決定の基準として使用する。
  • プロジェクト作業の指揮の際に使用する。
  • 段階的に詳細化され、タスクやアクティビティに分解される。

• 内容

  • 成果物（プロダクト / サービス / 所産） 自体
  • 成果物（プロダクト / サービス / 所産）の生成に必要な作業

大きなプロジェクトでは、個々の成果物（プロダクト / サービス / 所産）ごとに生成される。

• 成果物（プロダクト / サービス / 所産）の特性

• 一部は、プロジェクト憲章（PMP：立上の該当節を参照）に含まれている。

• 受入基準
  成果物（プロダクト / サービス / 所産）の受入のための

  • 仕様の定義

  • 基準の定義

    • 品質標準
    • 使用適合性
    • パフォーマンス測定基準

  • 受入プロセスの定義

• 成果物（プロダクト / サービス / 所産）（重要成功要因）

  • 成果物（プロダクト / サービス / 所産）の定義

    • プロダクト / サービス / 所産
    • 補助的な成果物（プロダクト / サービス / 所産）を含むこともある。
    • 測定可能な成果・結果、特定の項目。
    • 具体性のある検証可能なもの。

  • 目的

    • 成果物（プロダクト / サービス / 所産）の文書化。
    • プロジェクト期間全体で成果物（プロダクト / サービス / 所産）の進捗を監視する。

• 除外事項
  ステークホルダー・エンゲージメント・マネジメントの継続のため。

• 制約条件
  計画プロセス群の後続を行うための役に立つ。
  （スケジュール作成、見積、プロジェクト・マネジメント計画書作成（PMP：計画の該当節を参照））

  • 三大制約条件
    プロジェクト目標や要求事項を導き出すのにも必要になる。
    三大制約条件にどう対処するかで、範囲と品質が決定される。
    範囲と品質を守るために、時間・予算のバランスを図るケースが多い。
    （時間・予算どちらか一方は可能だが、両方は無理。
    その場合、範囲や品質などの変更が必要になる。）。

    • 範囲（スコープ）
    • 時間（≒ 締め切り、≠ スケジュール）
    • 予算（コスト）

  • 競合する要求
    上記に加え、以下のものがある。

    • 品質
      プロジェクト・スコープ記述書の構成要素に記述された、
      成果物（プロダクト / サービス / 所産）の仕様によって課せられる。

    • 人的資源
      非人的資源の、入手可能性や品質。
      人的資源の、入手可能性やスキル・レベル。

    • リスク
      ・・・。

  • その他

    • スケジュール
      締め切りではなくてアクティビティの日程

    • 技術
      リリース時期、テスト完了時期

    • 指示
      経営陣からの方針、契約条項など。

• 前提条件
  プロジェクト / ステークホルダーの本当だと信用できる情報（確定ではない）。
  前提条件が間違っていたり、文書化されていなかったりすると、
  それが、プロジェクトにとって命取りになることがある。

  • 前提条件の例

    • 主要なチーム・メンバが支障なく働ける。
    • プロジェクト計画の精度（契約締結日、プロジェクト開始日、フェーズ開始日）
    • 調達（ベンダーの納期、製品の入手可能性、コンストラクターの確保可能性）

  • プロジェクトの前提条件の例

    • 資材の入手可能性（コモディティは入手容易で値段も手頃）
    • 契約労働者の雇用（景気や地域の労働市場状況により左右される）

  • ステークホルダーの前提条件の例

    • ・・・

  • 前提条件の確実化の例

    • ベンダーにコンティンジェンシー・プランの実行を義務付ける。

※ 引掛けが多いが、制約条件は、

• 時間 > コストとなることが多い。
• また、資源の調達は予め既知の範囲で限定しない。

• プロジェクト憲章（PMP：立上の該当節を参照）と同様に、合意後に承認を受けて発行 / 配布する。
• 公式のアウトプットではなく、全てに合意 / 承認が必要と言う訳ではない。
• これにより、ステークホルダーは能動的プロジェクト参加者で有り続ける。

対象のプロジェクト文書（インプット・アウトプット（ITTO））の更新後、
プロジェクト・スコープ記述書の再発行を行う。

• 要求事項（重要成功要因）を明確にした後、作業を構成要素に分解する（要素分解）。
  ※ ワーク・ブレークダウン・ストラクチャー（WBS : Work Breakdown Structure）

• 定義するもの

  • プロジェクト作業スコープ
  • プロジェクト作業の内容

• これにより、構成要素毎に、

  • アクティビティ定義（PMP：計画 - 時間の該当節を参照）
  • コストと資源の見積（PMP：計画 - 時間の該当節を参照）
  • スケジュール作成（PMP：計画 - 時間の該当節を参照）
  • 監視・制御（進捗）
    • WBSセグメントに割り当てられた見積と測定基準によって判断される。

  できる。

• 従って、以下で重要な役割を果たす。

  • コスト・資源の見積（PMP：計画 - 原価の該当節を参照）
  • スケジュール作成（PMP：計画 - 時間の該当節を参照）
  • 品質マネジメント計画（PMP：計画 - 資源の該当節を参照）

• このため（重要な前提条件であるコストやスケジュールを狂わせるため）、正確さと完全性が要求される。

  • 正確さ：WBS検証、専門家の判断で正確さを判定できる。
  • 完全性：集合的にプロジェクトのすべての作業を網羅する（100％ルール）。

• スコープ・マネジメント計画書

  • WBSの作成方法
  • WBSの承認方法
  • WBSの維持方法

• プロジェクト・スコープ記述書
  主要なインプット。最新版を使用する。

• 要求事項文書
  補助的なインプット。

---

• 組織体の環境要因（PMP：環境の該当節を参照）

• 組織のプロセス資産（PMP：環境の該当節を参照）

  • プロセスと手順、企業知識ベース
  • テンプレート, ツール, etc.

• 目的
  成果物（プロダクト / サービス / 所産）を簡単に
  計画、実行、監視・制御、終結させることができるように要素に分解する。

• 作業
  ブレークダウン・プロセス（要素分解プロセス）の5ステップ。

  • プロジェクト・スコープ記述書により、
    主要な成果物（プロダクト / サービス / 所産）を特定する。

  • WBSの構造を決定し、プロジェクト作業を体系化する。

    • プロジェクト
      プロジェクト・レベルをWBSの第１レベルとする。

    • 主要な成果物（プロダクト / サービス / 所産）とサブ・プロジェクト
      要素分解の第１レベル（＝WBSの第２レベル）として使用する。
      ※ 従って、例えば、各プロダクトを第１レベルに設定することもできる。

    • プロジェクト・フェーズ
      要素分解の第２レベル（＝WBSの第３レベル）として使用する。

    • プロジェクト要素成果物（PMP：共通の該当節を参照）
      要素分解の最下位レベルをワーク・パッケージ・レベルと言う。

    • アクティビティ（PMP：計画 - 時間の該当節を参照）

  • WBSの構成要素を下位レベルの構成要素に分解する。

    • 主要な要素成果物を、小さく、管理しやすい作業に対応する要素成果物に分解する。
      ※ WBSの最下位レベル（ワーク・パッケージ・レベル）まで分割する。

    • この場合、測定・検証が可能な形式で、要素成果物を定義・記述する必要がある。

  • プロジェクト・チームの外部で実施される可能性のあるサブ・プロジェクトのWBS

    • 契約作業の一環として、納入者（コンストラクター、サプライヤー、別の部署）によってWBSが作成される。

    • このため、実施時期が近くならないとWBSが作成されないことがある。
      ローリング・ウェーブ計画法では現時点で解っている範囲で詳細化する。
      （TTとしてローリング・ウェーブ計画法。効果として段階的詳細化。）

    • このサブ・プロジェクトは元プロジェクトのワーク・パッケージ・レベルになる。
      サブ・プロジェクトは、要素分解の第１レベル（＝WBSの第２レベル）で、
      元プロジェクトのワーク・パッケージ・レベルと同じ階層でなくてイイ。

  • WBSの構成要素にWBSコードを割り当てる。

    • 各レベルに割り当てられたIDをハイフンで繋げてWBSコードを作成

    • この識別コードはコントロール・アカウントと呼ばれ追跡に使用される。

    • コストの追跡の場合、会計システムの勘定科目に関連付けられる。
      ※ 作業時間・割当資源の追跡というひっかけがあったが、「コスト追跡」が目的。

  • WBSを検証する。
    構成要素が明確で完全なものであるか判断する。

    • 絶対不可欠なものか？
    • 作業を記述するに十分なものか？

• 補足

  • ワーク・パッケージ・レベル

    • チーム・メンバにとって解り易く、適切な時間内に完了するようにする。
      過度の分解は非効率であり、細部までの定義はチーム・メンバの創造性を阻害する。

    • ワーク・パッケージ・レベルを、測定・検証の責任を持つ組織に割り当てる。

    • ワーク・パッケージ・レベルによって、コストと資源の見積、スケジュール作成を行う。

    • ワーク・パッケージ・レベルは、アクティビティ（PMP：計画 - 時間の該当節を参照）より上位になる。
      （通常、アクティビティはWBSの一部ではないということになっているため）
      しかし、小規模プロジェクトでは＝アクティビティというケースもある。

PMP：立上の該当節を参照。

• 上級管理職（立上の人物/組織）
• プロジェクト・スポンサー
  （オーナー、イニシエータ、顧客であることもある）
• 業界の専門家
• 専門的な訓練を受けたチーム・メンバ
• 類似プロジェクトの経験のあるPM

• 補助計画書（PMP：計画の該当節を参照）（ベースライン）の一部。

• プロジェクト・スコープ記述書で定義された作業を
  ブレークダウンして更に厳密に定義する。

• 内容
  プロジェクトのすべての作業が記載される。

  • 承認済みの、プロジェクト・スコープ記述書
  • WBS
  • WBS辞書

• 利用

  • アクティビティ定義（PMP：計画 - 時間）
  • コストと資源の見積
  • スケジュール作成
  • 監視・制御（進捗）

• 概要

  • スコープ・ベースラインの子要素。
  • 作業構成要素（ワーク・パッケージ）（要素分解）の内容が文書化される。

• 要素

  • WBS識別コード

  • 作業の記述

  • 前提条件

  • 制約条件

  • 担当組織

  • 重要な前提条件

    • コストの見積
    • 資源の見積
    • スケジュール
      スケジュール・マイルストーン
      関連するスケジュール・アクティビティ
    • 品質要求事項

  • 受入基準

  • 技術的参照資料

  • 合意情報

対象のプロジェクト文書（インプット・アウトプット（ITTO））の更新作業を行う。

• 要求済み変更の見直し
• 修正対象の修正
• 変更管理プロセスを利用して変更を承認 / 却下
• 修正対象に反映（プルリク・マージ的な）

移行メモ

• 誤記・脱字を修正した。「立ち上げプロセス群れ」→「立ち上げプロセス群」、 「合意されてた基準」→「合意された基準」、 「短な、要求事項を特定可能な情報」→「簡潔な、〜」、 「相互作用の視覚化する」→「相互作用を視覚化する」、 「予備的なスコープに含まれれている情報」→「含まれている情報」、 「労働市場状況によ左右される」→「により左右される」、 「価値分析（VA：Value Analysis)」の閉じ括弧を全角に統一。
• 「プロダクト分析」の冒頭「プロダクトの最終結果がプロダクトであるとき」は 「プロジェクトの最終結果がプロダクトであるとき」の誤りのため修正した。
• 「プロダクト・スコープ記述書」というラベルのリンクが 2 箇所あったが、 リンク先は「プロジェクト・スコープ記述書の構成要素」の節だったため、 ラベルをリンク先に合わせた。
• ITTO の表はセル内が全てリンクだったため、 セルの内容をプレーンテキストとし、参照先ページを表の直上に列挙した。 セルの縦結合（~）は 〃 に置き換えた。
• 「要求事項文書」の表は、元の PukiWiki が横結合（>）で 番号列を 2 列分に広げていただけだったため、3 列の表に整理した。
• 同名の見出し（「インプット」「プロセス（ツールと技法）」「アウトプット」 「専門家の判断」「プロジェクト文書更新版」）が複数あり、 GitHub Wiki ではアンカが衝突するため、括弧で文脈を補って一意にした。
• 頻出する「成果物（プロダクト / サービス / 所産）」は、元の PukiWiki では すべて PMP：共通 の該当節へのリンクだったが、 数が多く可読性を損なうため、冒頭に一度だけ参照先を示す形にした。

---

Tags: 移行, PMP, 計画, 範囲, スコープ, 要求事項収集, スコープ定義, WBS, WBS辞書, スコープ・ベースライン, ITTO