高頻度テストポイント（要件収集、WBS作成、範囲確認、範囲管理）

頻繁にチェックする

製品またはサービスの特徴と機能を表します。

製品やサービスが指定された機能を備えているようにするために実行する必要があるすべての作業。

承認された詳細なプロジェクト スコープ ステートメント、WBS、および WBS 辞書

プロジェクトの範囲と製品の範囲を定義、検証、管理し、範囲管理計画を作成する方法を文書化するプロセス

プロジェクト全体を通じてプロジェクト範囲を管理する方法についてのガイダンスと指示を提供する

1. プロジェクトスコープステートメントの作成方法

2. スコープステートメントに基づいて WBS を作成する方法

3. WBSの維持・承認方法

4. 完了したプロジェクト成果物を確認し、正式に受け入れる方法

5. 変更管理プロセス全体の実装に直接関係するプロジェクト スコープ ステートメントの変更をどのように処理するか

注: 上記の内容には需要収集の内容については言及されていませんが、対応する内容は需要管理計画に反映されます。出力のポイント 2 を参照してください。

入力

ツール技術

出力

プロジェクトの目標を達成するために、利害関係者のニーズと要件を特定、文書化、管理するプロセス

製品範囲を含むプロジェクト範囲を定義および管理するための基礎を築く

入力

ツール技術

出力

詳細なプロジェクトと製品の説明を作成するプロセス

収集した要件のうち、どの要件をプロジェクトのスコープに含め、どの要件をプロジェクトのスコープから除外するかを明確にし、製品、サービス、または成果の境界を明確にします。

入力

ツール技術

出力

1. 製品範囲の説明

2. 成果物

3. 製品の合格基準

4. プロジェクトの除外事項（プロジェクトの範囲外のもの）

5. 制約 (例: 必須の日付)

6. 仮定（検証せずに正しいとみなせる要素）

試験の説明: 事例分析とエッセイの両方がテストされる場合があります

1. 範囲を決定する

2. コミュニケーションの基礎（コンセンサス）

3. 基準を変更する（範囲外かどうかを判断する）

4. 計画の根拠（コスト、スケジュール等の計画の根拠）

5. 計画と管理の基礎

試験の説明: 事例分析とエッセイの両方がテストされる場合があります

プロジェクトの成果物とプロジェクトの作業を、より小さく、より管理しやすいコンポーネントに分割するプロセス

配信されるコンテンツの構造化されたビューを提供する

入力

ツール技術

出力

1. 成果物と関連作業の特定と分析

2. WBSの構造と配置方法を決定する（ツリー型、リスト型）

3. 上から下まで層ごとに精製および分解されます。

4. マーキング コードを作成して WBS コンポーネントに割り当てる

5. 作業分解のレベルが適切であることを確認する

1. プロジェクトのライフサイクルの各段階を分解の第 2 レベルとして使用し、製品とプロジェクトの成果物を第 3 レベルに置きます。

2. 主要な成果物を分解の第 2 レベルとして使用する

1. WBS は成果物指向でなければなりません。

2. プロジェクトの範囲を遵守し、すべてのレベルでプロジェクトの整合性を維持し、必要なコンポーネントの欠落を避ける必要があります (100% ルール)。

3. 最下位レベルの作業は、計画と制御をサポートし、比較可能で管理可能で定量的に検査可能である必要があります (8 ～ 80 時間ルール)。

4. 作業単位は、異なる責任者と異なる作業内容を分離できる必要があります（各作業単位に責任者があり、担当者は 1 人だけです）。

5. ワークユニットは、相互従属を避けるために、上位レベルのユニットにのみ従属することができます (レイヤー 4 ～ 6)

6. 下請け作業を含む、プロジェクト管理作業を含める必要があります (管理はプロジェクトの特定作業の一部であるため)。

7. WBS の作成には、プロジェクトの (主要な) 関係者全員の参加が必要です。

8.WBS は静的ではありません。

9. 同じレベルの作業単位は同じ性質を持つ必要があります。

10.WBS の最下位の作業単位は作業パッケージです。プロジェクトの WBS を作業パッケージに分解するかどうかは、プロジェクトの段階、複雑さ、規模によって異なります。一般に、初期のプロジェクト、複雑なプロジェクト、または大規模なプロジェクトの場合、WBS 分解の粒度はより大きく、より粗くする必要があります。

企画パッケージ

コントロールアカウント

WBS辞書

マイルストーン

ワークパッケージ

1. プロジェクトレベルのメンバーがタスクの性質と取り組む必要がある方向性を明確に理解できるように、プロジェクトの範囲を明確に示します。

2. プロジェクトの境界を明確に定義し、プロジェクトの関係者が合意した、実行する必要がある作業と実行する必要のない作業を提供します。

3. 独立した各部門に人員を割り当て、プロジェクトを完了するために必要な技術的および人的リソースを決定するためのこれらの人員の責任を指定します。

4. 独立したユニットの場合、時間、コスト、およびリソースの要件を見積もり、見積もりの​​精度を向上させます。

5. 計画、予算編成、スケジュール、コスト管理のための共通の基盤を築き、プロジェクトの進行と管理のベースラインを決定する

6. プロジェクト作業をプロジェクトの財務口座にリンクする

7. 作業内容と作業順序を決定し、プロジェクトを特定の作業タスクに分解し、作業タスクの論理的な順序に従ってプロジェクトを実装します。

8. プロジェクト全体とプロセス全体のコストを見積もる

9. 需要の伝染を防ぐのに役立ちます

完了したプロジェクト成果物を正式に承認するプロセスです

各成果物を受け入れることで最終製品、サービス、結果が受け入れられる可能性を高めながら、受け入れプロセスを具体的かつ客観的にします。

入力

ツール技術

出力

仕事のパフォーマンスデータ

仕事のパフォーマンス情報

仕事のパフォーマンスレポート

技術的パフォーマンスの測定

品質管理測定結果

1. 範囲を確認し、成果物が受け入れられるかどうかを強調する

2. 品質管理は成果物が正しいかどうかを重視します

検査の焦点が違う

3. 品質管理は通常、範囲を確認する前に実行されますが、同時に実行することもできます。

4. 範囲の確認は通常、段階の最後に行われ、品質管理は必ずしも段階の最後に行われるわけではありません。

検査時間が異なります

5. 品質管理は社内検査であり、実施組織が実施します。

6. 確認範囲は外部の顧客またはスポンサーによって検査され、受け入れられます。

検査官は違う

7. ますます詳細な検査で製品、品質管理、検証範囲を検証します

プロジェクトと製品のスコープのステータスを監視し、スコープのベースライン変更のプロセスを管理します

プロジェクト全体を通じてスコープのベースラインを維持する

入力

ツール技術

出力

なお、制御…、確認…を伴う処理は、データを入力とする処理と情報を入力とする処理は一般的に同じ内容である。

1. スコープ変更につながる要因に影響を与え、それらの要因が好ましい方向に発展するよう努める

2. スコープの変更が発生したかどうかを判断する

3. 範囲の変更が発生したときに実際の変更を管理し、すべての変更リクエストがプロジェクトの全体的な変更管理プロセスに従って処理されるようにします。

集中

4. 制御範囲は他の制御プロセスとも組み合わせる必要があります

1. プロジェクトの外部環境の変化

2. プロジェクト範囲計画が慎重に作成されておらず、特定の誤りまたは欠落が含まれています。

3. 新しい技術、新しい方法、新しいソリューションが市場に登場するか、設計者がそれらを提案します。

4. 事業実施組織自体の変更

5. プロジェクト、プロジェクト製品またはサービスに対する顧客の要件の変更

ビジネスアナリスト

要件を確認する