【目次】
・概要
・スコープ・ベースラインとは
- プロジェクトスコープ記述書
- WBS
- WBS辞書
・スコープ・ベースラインの作成方法
- 要求事項の収集
- 要求事項を一覧にする
- 要求事項から成果物を定義する
概要
プロジェクトでは様々な作業を行ったり、成果物を作成します。
その作業範囲を定義するのが「スコープ・ベースライン」です。
スコープ・ベースラインを作成することで、作業範囲を明確にするだけでなく「いつの間にか作業量が増えていた」という状況を回避したり、変更要求が発生したときの管理資料にもなります。
このスコープ・ベースラインはプロジェクト計画を作成するときに検討されますが、プロジェクト遂行中も必要に応じてメンテナンスします。
スコープ・ベースラインとは
スコープ・ベースラインの構成要素を説明します。
プロジェクトスコープ記述書
プロジェクトのスコープ(作業範囲)や成果物を定義します。
プロジェクトスコープ記述書には、「プロジェクトスコープ」「プロダクトスコープ」の2つがあります。
プロジェクトスコープ
プロジェクトを完遂するために必要となる作業、作成する成果物を定義します。
プロジェクトの制約事項や除外事項についても言及します。
作業範囲を定義したら、作業ごとの担当についても明確にします。
例えば設計、製造、結合テストはベンダーが実施するが、システムテストは発注者が主担当、といった役割を設定します。
プロダクトスコープ
特定の製品、サービス、または結果の特性や機能を記述します。
例えば、製品や成果物の具体的な特性、機能、性能基準を定義します。
これには製品の品質、デザイン、サイズ、色、機能などの情報も含まれます。
プロジェクトスコープは、製品を作成または提供するために実施する必要がある作業の範囲を定義します。
それに対してプロダクトスコープは、その製品自体の特性や要件に焦点を当てます。
両者は相互に影響するため、プロダクトスコープを変更するときはプロジェクトスコープにも影響を及ぼします。
WBS
プロジェクト成果物のWBS(Work Breakdown Structure)を定義します。
WBSの目的はプロジェクトの全作業をより小さく管理しやすい単位に分解することです。
WBSは階層的な構造を持ち、大きなプロジェクトをより小さな単位に分割します。
最上位レベルはプロジェクト自体であり、そこから下位レベルに分岐していきます。
詳細スケジュールで担当と作業期間を割り当てられるタスクまで落とし込みます。
WBSを作成してプロジェクトの全体像を把握し、各タスクに対する明確な理解を促進することで計画、実行、監視の各フェーズでの効率性と効果性を高めることができます。
WBS辞書
WBS辞書はプロジェクト管理の文脈においてWBSに記載されている各要素に関する詳細情報を定義します。
WBSがプロジェクトのタスクや成果物を階層的に分解するのに対し、WBS辞書はそれらの各要素に関する具体的な説明、責任、スケジュール、予算などの情報を記載します。
スコープ・ベースラインの作成方法
スコープ・ベースラインは以下の順序で作成します。
要求事項の収集
スコープ・ベースラインのインプットはプロジェクト憲章が基準となりますが、RFPや要求文書のように要求事項を抽出する情報をかき集めて作成することもあります。
しかし文書だけでは不足や誤認が発生する可能性もあるため、ステークホルダーに対して次のようなアプローチを行い情報収集します。
- ブレーンストーミング
- インタビュー
- フォーカスグループ
- アンケート・調査
- ベンチマーキング
<補足>
フォーカスグループ
専門家や有識者を集めて成果物に対する期待や意見を収集します。
ベンチマーキング
類似プロジェクトなど比較対象を設定して検討します。
「要求事項の収集」で重要なのは、風呂敷を広げることが目的であり潜在的な要求事項を洗い出すことです。
プロジェクトの後半で真なる要求事項が出てくるのを抑止するためです。
要求事項を一覧にする
収集した要求事項を整理して一覧化します。
その際、各要求事項に対して重要度や優先順位を入れていきます。
優先順位は現場のユーザにヒアリングしても決められません。
プロジェクトの業務有識者やプロジェクトオーナーなど、業務を決定する権限あるメンバを含め検討します。
要求事項から成果物を定義する
要求事項一覧をもとに、成果物一覧や前提条件などを定義します。
最初に広げた風呂敷をたたみ、プロジェクトで対応するスコープを選定していきます。
全ての要求事項を取り込めるとは限らないため、取捨選択や代替案、妥協案の検討も行います。
「プロジェクトスコープ」で作成する、各フェーズで作成するドキュメントや管理資料は、テンプレートや過去プロジェクトの情報を参考にしながら、プロジェクト特性を見て選定するのが良いでしょう。
そのうえで、プロダクトスコープを定義する場合、取り込む要求事項と製品や機能を比較します。
そして成果物一覧、および作業範囲、前提条件、制約事項、受入基準を文書にします。
この文書をステークホルダーの合意を得ることで、正式なスコープ・ベースラインとします。