Wondershare EdrawMind
マインドマップギャラリー 第 5 章 プロジェクトのスコープ管理
- 3
第 5 章 プロジェクトのスコープ管理
上級ソフトウェア試験 - 情報システム プロジェクト マネージャ 第 5 章 知識ポイント: プロジェクト スコープ管理とは、本質的には、プロジェクトによって完了する作業の範囲を管理および制御するプロセスおよび活動である機能管理の一種を指します。
2022-09-16 09:50:39 に編集されました
- おすすめ
- アウトライン
第 5 章 プロジェクトのスコープ管理
スコープ管理の概要
スコープ管理とは、スコープ内で物事を行うことを意味し、スコープ内でのみ物事を行い、それ以上行うことも少なくすることも行いません。
範囲
含む
製品の範囲
機能性を重視し、結果を重視
プロジェクト範囲
仕事に集中し、プロセスを重視する
製品範囲はプロジェクト範囲の基礎であり、プロジェクト範囲はプロジェクト管理計画の基礎です
プロジェクト範囲のベースラインには以下が含まれます
プロジェクトスコープステートメント
WBS
WBS辞書
プロジェクト範囲管理タスク
プロジェクトの境界を明確にする
プロジェクトの実行を監視する
プロジェクトスコープのクリープを防ぐ
スコープのクリープと金メッキの挙動を区別する
スコープクリープ: 顧客がスコープのベースラインを超える新しい要件を作成する
スコープ金メッキ: 顧客からの新たな要件はありません。スコープのベースラインを超えた作業は販売者が自ら行います。
スコープ管理の重要性
プロジェクト チームのメンバーに、期待される目標を達成するためにどのような特定の作業を完了する必要があるかを知らせ、各作業におけるプロジェクトに関係するすべての関係者の明確な役割分担と責任を明確に理解させます。
スコープ管理により、プロジェクトのコスト、スケジュール、リソースの見積もりの精度が向上します
計画範囲管理
コンセプト: プロジェクトのスコープを定義、確認、管理するプロセスを書面で説明したスコープ管理計画を作成します。
役割: プロジェクト全体の範囲を管理する方法についてのガイダンスと指示を提供します。
ITTOプロセス
入力
プロジェクト計画書
プロジェクト管理計画
事業環境要因
組織プロセス資産
ツールとテクニック
専門家の判断
ミーティング
出力
スコープ管理計画
コンテンツ
プロジェクトスコープステートメントを作成する方法
プロジェクトスコープステートメントに基づいてWBSを作成する方法
WBS を維持および承認する方法
完了したプロジェクト成果物を確認して正式に受け入れる方法
プロジェクト スコープ ステートメントへの変更を処理する方法
需要管理計画
コンセプト: 要件管理計画は、プロジェクトのライフサイクル全体を通じて要件をどのように分析、記録、管理するかを説明します。
コンテンツ
さまざまな需要活動を計画、追跡、報告する方法
需要管理に必要なリソース
研修プログラム
プロジェクトの関係者が要件管理に参加するための戦略
プロジェクトの範囲と要件の間の不一致を判断するための基準と修正手順
要件追跡構造
構成管理アクティビティ
需要管理の基本タスク
1. ニーズを明確にし、ベースラインを確立する
2. 製品と需要の間の一貫性を常に維持するために、需要追跡機能のコンタクト チェーンを確立します。
要件を収集する
コンセプト: プロジェクトの目標を達成するために、関係者のニーズと要件を特定、文書化、管理するプロセス。
役割: 製品範囲を含むプロジェクト範囲の定義と管理の基礎を築く
要件の分類
ビジネスニーズ
組織全体の高レベルのニーズ
ステークホルダーのニーズ
利害関係者または利害関係者グループのニーズ
ソリューションの要件
過剰な要求
現在の状態から将来の状態に移行するために必要な一時的な機能
プロジェクトの要件
プロジェクトに必要なアクション、プロセス、その他の条件
品質要件
プロジェクト成果物の正常な完了または他のプロジェクト要件 (QFD) の達成を確認するために使用される条件または基準
ITTOプロセス
入力
スコープ管理計画
需要管理計画
ステークホルダー管理計画
利害関係者登録簿
プロジェクト計画書
ツールとテクニック
インタビュー
関係者との直接の会話を通じて情報を入手する公式または非公式の方法は、要件を収集する最も基本的な手段です。
フォーカスグループ
フォーカスグループはグループインタビューの一種です
ガイド付きセミナー
ガイド付きワークショップは製品要件の議論と定義に重点を置き、個別の会議よりも迅速に問題を解決します。
グループ革新技術
コンセプト: プロジェクトと製品の要件を特定するためにいくつかのグループ活動を組織します。
含む
ブレーンストーミング
全員が自分の意見を表明し、ブレインストーミングを行う
名義群法
さらなるブレインストーミングや優先順位付けに投票することで、最も有用なアイデアをランク付けします
デルフィ法
匿名またはバックツーバックの方法を使用すると、各専門家が独立して独自の判断を下すことができます。
予測プロセス中に数回のフィードバックを経て、専門家の意見が徐々に収束していきます。
データのバイアスを軽減し、個人がデータに不当な影響を与えることを防ぎます。
コンセプト/マインドマップ
マインド マップとも呼ばれ、ブレインストーミングから得られたアイデアを簡単な図に結び付けて、これらのアイデア間の共通点や相違点を反映し、新しいアイデアを導きます。
親和性図
KJ法とも呼ばれ、ある問題についてのさまざまな経験、知識、考え、意見などのデータを十分に収集し、それらを図的な方法で要約し、それらのデータを相互の親和性に従って要約して整理し、問題を明確にすることです。問題を知り、一致を求めます。
多基準の意思決定分析
意思決定マトリックスの助けを借りて、システム分析手法を使用して、複数のオプションを評価およびランク付けするための複数の基準を確立します。
グループでの意思決定テクニック
特定の望ましい結果が達成されなかった場合に、複数の将来の行動計画を評価することを指します。
製品要件の開発、分類、優先順位付けに使用可能
方法
全会一致で同意した
ほとんどの原則
相対多数の法則
独裁
アンケート
観察
プロトタイプメソッド
ベンチマーク
ベストプラクティスを特定し、改善のためのアイデアを生み出し、パフォーマンス評価の基礎を提供するために、実際のプラクティスまたは計画されたプラクティスを他の同様の組織のプラクティスと比較します。
システム相互作用図
これはスコープ モデルの例であり、システムがアクターとどのように対話するかを示す製品のスコープの視覚的な説明です。
ファイル分析
既存の文書を分析し、要件に関連する情報を特定することによるマイニング要件
出力
要件文書
コンセプト: 個々の要件がプロジェクトに関連するビジネス ニーズをどのように満たすかを説明する
コンテンツ
ビジネスニーズ
ステークホルダーのニーズ
ソリューションの要件
プロジェクトの要件
過剰な要求
要件に関連する前提、依存関係、および制約
要件追跡マトリックス
コンセプト：製品の要件をその源からそれを満たす成果物に結びつける形
役割: 要件と他の製品要素の間のリンク チェーンを表す最も一般的な方法。
何を追跡するか
ビジネスのニーズ、機会、目標および目的
プロジェクトの目的
プロジェクトの範囲 (WBS 成果物)
製品デザイン
製品開発
テスト戦略とテストシナリオ
大まかな要件から詳細な要件まで
要件追跡マトリックスに記録される一般的な属性には、一意の識別子、要件のテキスト説明、要件を含める理由、所有者、ソース、優先度、バージョン、現在のステータス、およびステータスの日付が含まれます。
現在のステータスは、進行中、キャンセル、延期、新規追加、承認、割り当て、完了です。
需要管理
CMMI では、要件管理は管理レベルの主要なプロセス領域です。
要件管理には、製品開発中に要件の一貫性と正確性を維持するすべての活動が含まれます。
管理要件のベースライン
プロジェクト計画を要件と一貫性のあるものに保つ
個々の要件および要件ドキュメントのバージョン ステータスを管理する
要件とリンク チェーン間の接続を管理する、または個々の要件と他のプロジェクト成果物間の依存関係を管理する
ベースラインで要件のステータスを追跡する
要件の追跡
要件の追跡とは、単一の要件と、さまざまな種類の要件、ビジネス ルール、システム コンポーネント、ヘルプ ファイルなどを含む他の要素との間の依存関係と論理的接続を追跡することです。
トレーサビリティはプロジェクト要件の重要な特性です
デマンドトラッキングの内容
各構成アイテムの要件には、関連する製品 (またはコンポーネント) の要件に対する双方向の追跡可能性が必要です。いわゆる双方向追跡には、順方向追跡と逆方向追跡が含まれます。
フォワードトラッキング: 要件文書内の各要件が、後続の作業成果物 (または結果) で対応する点を見つけられるかどうかを確認します。
逆トレース： 逆トレースとも呼ばれ、設計書、製品コンポーネント、テスト書などの作業結果が要件書にあるかどうかを確認することを指します。
要件の追跡には 5 つのタイプが含まれます
矢印は需要追跡機能のコンタクト チェーンを表しており、需要の使用サイクル全体、つまり需要の提案から配信までのプロセス全体を追跡できます。
左半分は、元のユーザー要件を要件文書まで遡ることができることを示しています。これにより、プロジェクト中またはプロジェクト終了後の変更によって影響を受ける要件を区別することができます。また、要件文書にすべての元のユーザー要件が含まれていることを確認できます。そして、それぞれのニーズの起源を確認します。
右半分は、プロジェクトの実施中に製品要件が設計やテストなどの実装要素に変換されるため、個々の要件と特定の製品要素の間のリンクチェーンを定義することで、要件文書から製品要素を追跡できることを示しています。この一連の接続により、プロジェクト チームのメンバーはどの製品要素が各要件に対応するかを知ることができるため、製品要素が各要件を確実に満たすことができます。 4 番目のタイプのリンク チェーンは、製品要素から要件文書に戻り、プロジェクト チームのメンバーが各製品要素の存在理由を参照します。設計要素とテスト ケースを要件文書まで遡ることができない場合、金めっきが発生する可能性があります。もちろん、分離された製品要素が正当な機能を示している場合、要件文書には要件が欠落しています。
5 番目のタイプのコンタクト チェーンは、要件ドキュメント間の追跡です。この追跡により、さまざまな要件間の論理的な相関関係の処理が容易になり、要件の分解プロセス中に発生する可能性のあるエラーや欠落がチェックされます。
範囲を定義する
コンセプト: プロジェクトと製品の詳細な説明を作成するプロセス
役割：収集した要件のうちどれをプロジェクト範囲に含め、どれをプロジェクト範囲から除外するかを明確にし、製品、サービス、成果の境界を明確にする。
ITTOプロセス
入力
スコープ管理計画
要件文書
プロジェクト計画書
組織プロセス資産
ツールとテクニック
製品分析
製品分析は、製品が成果物であるプロジェクトにとって効果的なツールです
代替世代
プロジェクト作業を実行するさまざまな方法を特定し、可能な限り多くの潜在的な代替案を指定するために使用される手法です。
ガイド付きセミナー
専門家の判断
出力
プロジェクト範囲ステートメント (詳細)
コンセプト: プロジェクト スコープ ステートメントは、プロジェクトのスコープ、主要な成果物、前提条件、および制約を説明するものです。
コンテンツ
製品範囲の説明
合否基準
成果物
プロジェクトの除外
仮定
制約
効果
範囲
コミュニケーションの基本
変更基準
計画の基本
計画と管理の基礎
プロジェクトファイルの更新
作業分解構造を作成する
概念: WBS の作成は、プロジェクトの成果物とプロジェクトの作業を、より小さく管理しやすいコンポーネントに分割するプロセスです。
役割: 配信されるコンテンツの構造化されたビューを提供する
関連概念
マイルストーン
マイルストーンは、成果物またはフェーズの正式な完了を示します。
重要なチェックポイントはマイルストーン、重要なマイルストーンはベースライン
ワークパッケージ
作業パッケージは、WBS の各ブランチの下部にある成果物またはプロジェクト作業コンポーネントです。
分割の原理
作業パッケージは、さまざまな人や組織単位に簡単に割り当てられる必要があります。
作業パッケージは非常に具体的である必要があります
8/80 ルールに従い、作業パッケージのサイズを完了するには少なくとも 8 時間を必要とし、合計完了時間は 80 時間を超えないようにします。
企画パッケージ
計画パッケージは、管理アカウントの下にあり、作業パッケージの上位にあり、作業内容はわかっているものの、詳細な進捗アクティビティが不足している WBS のコンポーネントを指します。状況が徐々に明らかになり、最終的に計画パッケージは次のように分割されます。作業パッケージとそれに対応する特定のアクティビティ。
コントロールアカウント
コントロールアカウントは管理コントロールポイントです
制御アカウントには複数の作業パッケージが含まれていますが、作業パッケージは 1 つの制御アカウントにのみ属します
WBS辞書
WBS 用語集とも呼ばれ、WBS のさまざまなコンポーネントを説明する文書です。
WBS は実行する必要がある活動を細分化します。
成果物と関連作業を特定して分析する
WBの構造と配置を決定する
分解は上から下までレイヤーごとに洗練されます。
識別コードを開発して WBS コンポーネントに割り当てる
成果物のコンポーネントへの分割が適切であることを検証する
WBS分割原則
機能的または技術的な原則
組織構造の原則
システムとサブシステムの原則
WBS分解法
プロジェクトのライフサイクルの各段階は、分解の第 2 レベルとして機能します。
分解の第 2 レベルとしての主要な成果物
プロジェクト チーム以外の組織によって実装される可能性のあるさまざまなコンポーネントを統合し、アウトソーシング作業の一環として、売り手は対応する契約 WBS を準備する必要があります。
WBSの表現形式
樹形
利点: 明確な階層、直感的かつ構造的
短所: 変更は簡単ではなく、大規模で複雑なプロジェクトの場合はプロジェクトの全体像を示すのが困難です。
テーブル形状
利点: あらゆる作業要素を反映できる
短所: 直感的ではない
フィッシュボーン形状
まれに使用される
WBSが注意すべき8つの側面
WBS は成果物指向でなければなりません
WBS はプロジェクトの範囲と一致している必要があります
WBS の基礎となる層は、計画と管理をサポートする必要があります。
誰かが WBS の要素に対して責任を負わなければなりません
WBS のガイダンス、WBS は 4 ～ 6 階で管理する必要があります
WBS にはプロジェクト管理作業と下請け作業を含める必要があります
WBS の作成には、プロジェクト関係者全員の参加とプロジェクト チーム メンバーの参加が必要です。
WBS は静的ではありません。WBS が完成した後も、WBS を変更する必要がある場合があります。
WBS作成の流れ
WBS は、誰か 1 人のプロジェクト チーム メンバーの責任ではなく、すべてのプロジェクト チーム メンバー、ユーザー、およびプロジェクト関係者によって完了し、全員一致で確認される必要があります。
ITTOプロセス
入力
スコープ管理計画
プロジェクト範囲の詳細な記述
要件文書
事業環境要因
組織プロセス資産
ツールとテクニック
壊す
専門家の判断
出力
スコープベースライン
プロジェクトファイルの更新
WBSの目的と使い方
プロジェクト チームのメンバーがタスクの性質と作業する必要がある方向性を明確に理解できるように、プロジェクトの範囲を明確かつ正確に記載します。
プロジェクトの境界を明確に定義する
個々の部門に人員を割り当て、その責任を指定することで、プロジェクトを完了するために必要な技術的および人的リソースが決まります。
独立したユニットの場合、時間、コスト、およびリソース要件を見積もり、見積もりの精度を向上させます。
計画、予算編成、スケジュール、コスト管理のための共通基盤を確立し、プロジェクトの進行と管理のベースラインを確立します。
プロジェクト作業をプロジェクトの財務アカウントにリンクする
作業内容と作業順序を決定し、プロジェクトを特定の作業タスクに分解し、作業タスクの論理的な順序に従ってプロジェクトを実装します。
需要の伝染を防ぐのに役立ちます
範囲の確認
概念: プロジェクトの完了した成果物を正式に承認するプロセス
機能: 受け入れプロセスを客観的にする
クライアントまたはスポンサーと一緒に成果物をレビューして、成果物が満足に完成し、クライアントまたはスポンサーから正式に承認されていることを確認することが含まれます。
範囲を確認する手順
検証範囲はプロジェクト全体に及ぶ必要があります
一般的な手順
スコープ検証が必要な場合を決定する
スコープの検証に必要な入力を特定する
正式に受け入れられた範囲設定の基準と要素を決定する
スコーピング会議の組織的な手順を決定する
組織範囲確認会議
チェックすべき6つの側面
成果物が確実で確認可能かどうか
各成果物には明確なマイルストーンがあり、マイルストーンには明確で識別可能なイベントがありますか?
明確な品質基準はありますか？
レビューと約束は明確に表現されていますか?
プロジェクトの範囲は、製品またはサービスを完成させるために必要なすべての活動をカバーしていますか? 漏れや間違いはありますか?
プロジェクト範囲のリスクが高すぎるかどうか、および予見可能なリスクが発生した場合に管理者がプロジェクトへの影響を軽減できるかどうか
利害関係者の懸念
経営者が懸念するプロジェクトの範囲とは、その範囲がスケジュール、資金、リソースに与える影響を指します。これらの要素が組織の範囲を超えているかどうか、またインプットとアウトプットの観点から妥当であるかどうかを指します。
顧客の主な関心事は、製品の範囲と、プロジェクトの成果物が製品またはサービスを完了するのに十分であるかどうかです。
プロジェクトマネージャーは主に、成果物が十分であるか、完了する必要があるか、時間、資金、リソースが十分であるかどうか、主な潜在的なリスクと準備された解決策に焦点を当てます。
プロジェクト チームのメンバーは、主に自分たちが関与し、責任を負うプロジェクト範囲内の要素に関心を持ちます。
ITTOプロセス
入力
要件文書
要件追跡マトリックス
検証された成果物
プロジェクト管理計画
仕事のパフォーマンスデータ
ツールとテクニック
診る
グループでの意思決定テクニック
出力
受領のための成果物
変更要求
仕事のパフォーマンス情報
プロジェクトファイルの更新
いくつかの用語の比較
範囲の確認と製品の検証
プロダクトの検証とは、プロダクトが完成しているかどうかを検証することであり、プロジェクト（またはフェーズ）の最後にスポンサーや顧客によって検証され、プロダクトが完成しているかどうかが強調されます。
範囲の確認は、プロジェクトの成果物に対するフェーズの終了時に顧客またはスポンサーによる受け入れを確認するプロセスです。
検証範囲と品質管理
確認範囲は主に、成果物が顧客またはスポンサーによって受け入れられることを重視し、品質管理は成果物が正確であり、成果物に対して策定された特定の品質要件（品質基準）を満たしていることを重視します。
品質管理は通常、スコープの確認前、または同時に行われ、スコープの確認は段階の最後に行われるのが一般的ですが、必ずしも段階の最後に行われるとは限りません。
品質管理は内部検査であり、実施組織の対応する品質部門によって実施されます。確認の範囲は、外部関係者（顧客またはスポンサー）によるプロジェクト成果物の検査と受け入れです。
範囲とプロジェクトの終了を確認する
範囲の確認とプロジェクトの終了作業は両方ともフェーズの最後に実行されますが、範囲の確認では成果物の検証と受け入れが強調され、プロジェクトの終了ではプロジェクト（またはフェーズ）を終了するために必要なプロセス作業が強調されます。
確認スコープとプロジェクトのクローズには両方とも受け入れ作業があります。確認スコープではプロジェクト成果物の受け入れが重視され、プロジェクトのクローズでは製品の受け入れが重視されます。
制御範囲
コンセプト: プロジェクトと製品のスコープのステータスを監視し、スコープのベースライン変更のプロセスを管理する
役割: プロジェクト全体を通じてスコープのベースラインを維持する
スコープの変更
範囲変更の理由
政府の政策問題
プロジェクト範囲の計画は完全かつ詳細ではありません。
新しいテクノロジー、新しい方法、または新しいソリューションの出現
プロジェクト実行組織自体の変更
顧客からの新たな要求
変化は避けられず、製品またはプロジェクトのスコープが制御されずに拡大することをスコープ クリープといいます。
範囲の変更には、変更を承認するために必要な文書、追跡システム、承認レベルが含まれます。
スコープ変更制御の主なタスク
範囲の変更につながる要因に影響を与え、それらの要因を好ましい方向に動かそうとする
スコープの変更が発生したかどうかを判断する
範囲の変更が発生したときに実際の変更を管理し、要求されたすべての変更がプロジェクト全体の変更管理プロセスに従って処理されるようにします。
ITTOプロセス
入力
要件文書
要件追跡マトリックス
仕事のパフォーマンスデータ
プロジェクト管理計画
組織プロセス資産
ツールとテクニック
偏差分析
出力
変更要求
仕事のパフォーマンス情報
組織プロセス資産の更新
プロジェクト管理計画の更新
プロジェクトファイルの更新