Wondershare EdrawMind
マインドマップギャラリー 第7章 プロジェクトのスコープ管理(2)
- 7
第7章 プロジェクトのスコープ管理(2)
ソフトウェア試験 / システム インテグレーション プロジェクト マネジメント エンジニア / 第 7 章 プロジェクト スコープ管理 (2) に合格 (作業分解構造の作成、スコープの確認、スコープ管理などを含む)
2024-02-24 02:13:01 に編集されました
- おすすめ
- アウトライン
第7章 プロジェクトの範囲管理 (2)
実装プロセス
ステップ(4) 作業分解構造 (WBS) を作成する [作業分解図]
意味
プロジェクトの成果物とプロジェクトの作業を、より小さく、より管理しやすいコンポーネントに分割するプロセス
これはプロジェクト管理の基礎です。プロジェクトのすべての計画と管理作業は、作業分解構造に基づいて行う必要があります。
これは、プロジェクト チームがプロジェクトの目標を達成し、成果物を作成するために実行する必要がある作業の全範囲を階層的に分類したものです。
プロジェクトの全体的な範囲を整理および定義し、承認された現在のプロジェクト範囲ステートメントで指定された作業を表します。
これは、その後の管理作業の主な基礎となり、プロジェクトの時間、コスト、人材、その他の管理作業の基礎となります。
効果
配信されるコンテンツの構造化されたビューを提供する
意義
（1） プロジェクトの関係者にプロジェクトを明確にする
（2） プロジェクト構造の体系性と整合性を確保する
（3） 万全のプロジェクト保証体制を確立可能
（4） 責任の分割と実施を容易にするために、プロジェクトに関与するすべての関係者の作業インターフェースを明確にする
（5） 最終的な WBS は、スケジュールの計画と管理のツールとして直接使用できます。
（6） プロジェクトのコミュニケーション管理を確立するための基盤を提供し、情報の重要なポイントを把握しやすくします。
（7） これは、プロジェクトの各サブプランおよび管理手段の策定の基礎および主要な基盤です。
（8） 要件やスコープクリープの防止に役立ちます
WBS の最下位の作業単位はワークパッケージと呼ばれ、スケジュール調整、コスト見積もり、関連アクティビティを分類するための監視などの基本的な作業パッケージです。
コンテンツ
1. プロジェクトのすべての作業は WBS に含める必要があり、WBS に含まれていない作業はプロジェクトの一部ではないため実行できません。そうしないと「金メッキ」されてしまいます。
WBS には作業の 100% を含める必要があり、含めることができます (100% ルール)
2. WBS の作成には、プロジェクト関係者全員の参加とプロジェクト チーム メンバーの参加が必要です。
3. WBS はレイヤーごとに分解されます。 WBS の最上位の要素は常に、プロジェクト全体またはサブプロジェクト全体の最終結果になります。次の各レベルは、前のレベルの対応する要素を細分したものであり、前のレベルは次のレベルの要素の合計です。 WBS の各ブランチの分解レベルは同じである必要はなく、通常は 3 ～ 6 レベルで制御する必要があります。プロジェクトが大きく、6 レベルを超える場合は、大規模なプロジェクトをサブプロジェクトに分割し、サブプロジェクトに対して WBS を実行できます。
4. WBS の各要素は比較的独立しており、相互の重複は最小限に抑える必要があります。
構造タイプ
（1） 階層ツリー構造
アドバンテージ
明確な階層、非常に直感的で高度に構造化されており、小規模および中規模のプロジェクトに適しています
欠点がある
変更するのは簡単ではなく、大規模で複雑なプロジェクトの場合、プロジェクト全体のビューを表現するのは困難です。
適用範囲
小規模で控えめなアプリケーション プロジェクト
（2） 表形式
アドバンテージ
プロジェクトのすべての作業要素を反映することができ、大規模で複雑なプロジェクトでよく使用されます。 [インデントされたグラフを使用する]
欠点がある
直感的ではない
適用範囲
大規模で複雑なプロジェクト
特徴
各層のすべての要素の合計は、次の層の作業の合計になります。
各作業要素は 1 つのレベルに明確に割り当てる必要があり、複数のレベルに割り当てないでください。
プロジェクト チームのメンバーが完了すべき作業を包括的に理解できるように、WBS には作業の範囲を説明する必要があります。
関連概念
マイルストーン
成果物またはフェーズの正式な完了を示します。
マイルストーン = 現時点で完了する必要がある特定の時間イベント
マイルストーンと成果物は密接に関連していますが、同じ概念ではありません。マイルストーンはイベントの完了に焦点を当てます。 WBS のタスクには開始時刻と終了時刻が明確であり、タスクの結果を期待される結果と比較できます。
ワークパッケージ
WBS の各ブランチの最下位レベルにある成果物またはプロジェクト作業コンポーネント
作業パッケージは完全に別の人や組織に割り当てられやすいため（各作業パッケージの担当者は 1 人のみ）、作業単位間のインターフェイスを明確にする必要があります。
作業パッケージは、責任者が自分のタスク、取り組みの目標、および責任を明確に理解できるように、非常に具体的である必要があります。作業パッケージは草の根のタスクまたは作業の割り当てであり、作業のテストと報告の機能もあります。
作業パッケージが大きすぎると、管理可能で制御可能な目標を達成することが難しくなります。作業パッケージが小さすぎると、WBS はプロジェクト マネージャーやチーム メンバーの多くの時間とエネルギーを消費することになります。
8/80 経験則: 作業パッケージのサイズが完了するまでに少なくとも 8 時間かかり、合計完了時間が 80 時間を超えないようにすることをお勧めします。
特徴
小規模で短時間（80時間）で完了可能
論理的に言えば、それ以上分割することはできません。
必要なリソース、時間、コストなどを比較的正確に見積もることができ、効果的な時間、コスト、品質、範囲、リスク管理を行うことができます。
コントロールアカウント
ブレークダウン ストラクチャを作成するプロセスでは、各ワーク パッケージが制御アカウントに割り当てられ、「アカウント コード」に基づいてワーク パッケージの一意の識別が確立され、コストの階層的な概要の階層構造が提供されます。スケジュールとリソース情報。
範囲、予算、実際コスト、スケジュールを統合し、達成価値と比較してパフォーマンスを測定する管理制御点です。
制御アカウントは、WBS によって選択された管理ノードに設定されます。各制御アカウントには 1 つ以上の作業パッケージを含めることができますが、1 つの作業パッケージは 1 つの制御アカウントにのみ属することができます。
WBS辞書
意味
いくつかのサポート ファイルを生成する必要があり、これらのファイルを WBS と組み合わせて使用する必要があります。
含む
WBSコンポーネントの詳細内容、アカウント番号、作業内容、責任者、進捗マイルストーンリスト
契約情報、品質要件、技術文献、計画された活動、リソースおよびコストの見積もり
WBSコーディング設計
WBS の情報交換プロセスを簡素化するために、通常、WBS 上の情報交換にはコーディング技術が使用されます。
コーディング設計と構造設計の間には対応関係があります。構造の各レベルはコード内の特定の桁数を表し、特定のコード番号が割り当てられています。
WBS コーディングでは、どのレベルの 1 つのプロジェクト要素も、他のすべてのサブレベルのプロジェクト要素の合計です。たとえば、2 番目の数字はサブプロジェクト要素を表します。コードの最初の桁はすべてのサブプロジェクトで同じであり、次の下位レベルの作業単位でも同様です。
コーディング設計は WBS の重要なテクノロジーです。コーディングを設計するときは、収集する情報とその収集方法を慎重に検討する必要があります。
伊藤
入力 入力
（1） プロジェクト範囲管理計画
（2） プロジェクトスコープステートメント
（3） 要件文書
（4） 事業環境要因
（5） 組織プロセス資産
ツールとテクニック ツール&テクノロジー
（1） 専門家の判断
（2） 壊す
実施された活動 ヒント: 糞便核の放出
1||| 成果物と関連作業を特定して分析する
2||| WBSの構造と配置を決定する
3||| 上から下へレイヤーごとに分解
4||| 識別コードを開発して WBS コンポーネントに割り当てる
5||| 成果物が適切な範囲に分割されていることを確認する
7つの原則
1||| プロジェクトの整合性を階層的に維持して、重要なコンポーネントの欠落を回避します
2||| 相互従属を避けるために、作業ユニットは上位レベルのユニットにのみ従属できます。
3||| 同じレベルのワークユニットには同じプロパティが適用されます
4||| 作業単位は異なる責任者と異なる作業内容を分離できる必要があります
5||| プロジェクト管理計画とプロジェクト管理のニーズを促進する
6||| 最下位レベルの作業は比較可能であり、管理可能であり、（定性的ではなく）定量的にチェックできる必要があります。
7||| 下請け作業を含むプロジェクト管理作業を含める必要があります
(本には載っていません) 3つの方法
1||| プロジェクトのライフサイクル フェーズを分解の第 1 レベルとして使用し、プロジェクトの成果物を第 2 レベルで整理します。
2||| プロジェクトの重要な成果物を分解の最初のレベルとして考慮します。
3||| サブプロジェクトを第1階層に配置し、サブプロジェクトのWBSを分解する
出力 出力
1||| スコープベースライン
コンテンツ
1. プロジェクトスコープステートメント
2. WBS
WBS の分解の各レベルは、プロジェクト作業のより詳細な定義を表します。
各ワーク パッケージを制御アカウントに割り当て、「アカウント コード」に基づいてワーク パッケージの一意の識別子を確立することが、WBS 作成の最後のステップです。
制御アカウントは、WBS で選択した管理ノードに設定されます
3. WBS辞書
内容には次が含まれます: アカウントコードの識別、作業の説明、前提条件と制約、責任組織、スケジュールマイルストーン、関連スケジュールアクティビティ、必要なリソース、コスト見積もり、品質要件、合格基準、技術リファレンス、契約情報
ベースラインへの変更は、正式な変更管理手順を通じてのみ行うことができます。ベンチマークは比較の基準として使用されます。
2||| プロジェクトファイルの更新
ステップ(5) 確認範囲 = 受理 ≠ 検証
意味
完了したプロジェクト成果物を正式に受領するプロセス
含意
プロジェクトのすべての作業が正確かつ満足のいく状態で完了していることを確認するために、成果物と作業成果物をレビューする必要があります。
プロジェクト全体を通して
範囲検証プロセスは、その完了を書面で文書化する必要があります。
顧客またはスポンサーによる品質管理プロセスから出力された検証済み成果物をレビューして、これらの成果物が満足に完了し、正式に受け入れられたことを確認します。
効果
各成果物を受け入れることで最終製品、サービス、結果が受け入れられる可能性を高めながら、受け入れプロセスに客観性をもたらします。
比較した
スコーププロセスの確認
成果物の受け入れに重点を置く
品質プロセスの管理
成果物の正確性と品質要件を満たしているかどうかに焦点を当てる
通常、品質管理プロセスは検証範囲プロセスに先行します。 ただし、両方を同時に行うこともできます
手順のヒント: クソ入札が足りません
1||| スコープをいつ確認する必要があるかを判断する
2||| スコープを検証するためにどのような入力が必要かを特定する
3||| 正式に受け入れられた範囲設定の基準と要素を決定する
4||| 範囲会議の組織的な手順を決定する
5||| 範囲確認会議を開催する
作業点
検証手順の開発と実装
プロジェクト関係者によるプロジェクト範囲の正式な認識
ステークホルダーは6つの側面を確認する必要があります
1||| 成果物が具体的であるか、確認可能であるか、検証可能であるか
2||| 各成果物には明確なマイルストーンがありますか? マイルストーンは明確で識別可能ですか?
3||| 明確な品質基準はありますか？
4||| レビューやコミットメントが明確に表現されているかどうか
5||| プロジェクトの範囲が、製品またはサービスを完成させるために必要なすべての活動をカバーしているかどうか。
6||| プロジェクト全体のリスク発生の確率、および管理者がプロジェクトに対する予見可能なリスクの影響を軽減できるかどうか
伊藤
入力 入力
（1） プロジェクト管理計画
（2） 要件文書
（3） 要件追跡マトリックス
要件と要件ソースを接続して、プロジェクトのライフサイクル全体にわたって要件を追跡します。
（4） 検証された成果物
完成し、品質プロセスによって正しいことが確認された成果物。
（5） 仕事のパフォーマンスデータ
これには、要件への準拠度、不一致の数、不一致の重大度、または特定の期間内に実行された検証の数が含まれる場合があります。
ツールとテクニック ツール&テクノロジー
（1） 診る
測定、レビュー、検証などの活動を実行して、作業と成果物が要件と製品受け入れ基準を満たしているかどうか、またプロジェクト関係者の要件と期待を満たしているかどうかを判断します。
レビュー、製品レビュー、監査、検査などとも呼ばれます。
確認範囲が完了したら、確認時に調整したWBSおよびWBS辞書を更新する必要があります。
（2） グループでの意思決定テクニック
プロジェクト チームやその他の関係者によって検証されると、グループ意思決定手法を使用して結論に達することができます。
出力 出力
（1） 受領のための成果物
受け入れ基準を満たす成果物は、クライアントまたはスポンサーによって書面で正式に署名および承認される必要があります。
顧客が受け入れなかった成果物も、受け入れられない理由とともに記録する必要があります。
プロジェクト成果物が利害関係者によって正式に受け入れられたことを示す正式な文書をクライアントまたはスポンサーから入手する必要があります。これらの文書は、プロジェクトまたはフェーズの終了プロセスに提出されます。
範囲の検証は段階的に行うことができるため、ここで説明する成果物は中間成果物である可能性があります。システム統合プロジェクトの受け入れは、最初にバッチで実行され、その後最終的に顧客からの書面による確認が必要になります。
（2） 変更要求
（3） 仕事のパフォーマンス情報
（4） プロジェクトファイルの更新
確認文書には、クライアントまたはスポンサーによる署名または連署の形式での承認が必要です。
補充する
範囲確認と要件確認は分離する必要がある
要件確認とは、プロジェクトの初期段階で要件検討会議を開催し、三者が協議して要件書を作成し、要件を確認することです。
範囲の確認は段階的な受け入れです
ステップ(6) スコープ制御
意味
プロジェクトと製品のスコープのステータスを監視し、スコープのベースライン変更のプロセスを管理します
関連名詞
スコープクリープ
製品またはプロジェクトの範囲が制御されずに拡大する (時間、コスト、リソースの対応する調整が行われない)
要点
変更とは、プロジェクトの関係者がプロジェクト環境やその他の理由により、プロジェクト範囲の計画を変更したり、再計画したりすることがよくあることです。
変更は避けられないため、すべてのプロジェクトで、何らかの形式の変更管理管理を文書化して実装する必要があります。
プロジェクト範囲の変更の制御と管理では、プロジェクトの既存の変更または潜在的な変更に対して正しい戦略と方法を使用して、プロジェクトのリスクを軽減します。
効果
プロジェクト全体を通じてスコープのベースラインを維持する
プロジェクト全体の変更管理との連携
スコープ変更に関するよくある質問
（1） プロジェクト範囲の拡大
プロジェクト マネージャーは、大規模な範囲の変更は認識していますが、小さな範囲の変更にはあまり注意を払いません
（2） 投資家の承認が得られなかった場合
通常、顧客はスコープの変更をリクエストすることしかできませんが、それを承認する権限はありません。
プロジェクトマネージャーには承認権限がない
プロジェクトのスポンサーのみが (スポンサーが他の人に権限を委任していない限り) スコープの変更を承認できます。
（3） プロジェクトチームは責任を果たせなかった
すべてのチームメンバーは、プロジェクト範囲の変更を速やかに特定し、プロジェクトマネージャーに報告する必要があります。
ユーザーニーズの変化への対応
ユーザーのニーズの変化は、制御可能な範囲内で制御する必要があります。
要件ベースラインはプロジェクトの範囲を定義します。要件が変更され、要件が見直されるたびに、新しい要件ベースラインを再決定する必要があります。プロジェクト チームは、要件ベースライン文書を維持し、緊急の必要に備えて要件ベースラインの各バージョンを保存する必要があります。プロジェクトが進行するにつれて、要件のベースラインはますます高く設定され、許可される要件の変更はますます少なくなります。
要件の変更と範囲の変更は、変更管理委員会によって確立された変更管理プロセスに従う必要があります。
伊藤
入力 入力
（1） プロジェクト管理計画
1||| スコープベースライン
2||| スコープ管理計画
3||| 変更管理計画
4||| 構成管理計画
5||| 需要管理計画
（2） 要件文書
（3） 要件追跡マトリックス
（4） 仕事のパフォーマンスデータ
（5） 組織プロセス資産
ツールとテクニック ツール&テクノロジー
偏差分析
実際のパフォーマンスがベンチマークとどのように、そしてなぜ異なるのかを判断するための手法です。
プロジェクトのパフォーマンス測定結果は、スコープのベースラインからの逸脱の度合いを評価し、スコープのベースラインからの逸脱の原因と範囲を特定し、是正措置または予防措置を講じる必要があるかどうかを判断するために使用できます。これはプロジェクトの重要なタスクです。スコープコントロール。
出力 出力
（1） 仕事のパフォーマンス情報
（2） 変更要求
（3） プロジェクト管理計画の更新
スコープベースラインの更新
その他のベースライン更新
（4） プロジェクトファイルの更新
（5） 組織プロセス資産の更新