プロジェクトの計画段階は非常に複雑です。様々な要因を考慮して最適な計画を作りこんでいく必要があります。
そうした計画段階の一工程であるスコープ定義は計画の出来を左右する重要な工程です。今回はそのスコープ定義の成果物であるプロジェクトスコープ記述書について説明していきます。
プロジェクトスコープ記述書とは
まずプロジェクトスコープ記述書とは何かについて以下の項目で説明していきます。
- プロジェクトスコープ記述書とは何か
- プロジェクトスコープ記述書の必要性
- プロジェクトスコープ記述書の作成タイミング
プロジェクトスコープ記述書とは何か
プロジェクトスコープ記述書とはスコープ定義工程の成果物です。プロジェクトスコープの定義とはこのプロジェクトにおけるゴールとこのプロジェクトに含まれるもの/含まれないものを明確にすることを言います。
これは立ち上げ当初はまだ不明確な部分が多いプロジェクトの輪郭を定義することと同義です。
そしてプロジェクトのスコープ定義のアウトプットの型がプロジェクトスコープ記述書です。
プロジェクトスコープ記述書の必要性
プロジェクトスコープ記述書を作成することはプロジェクトにおいて非常に重要です。
理由は3つあります。１つ目はプロジェクトのゴールと範囲を明確にすることでメンバー間の認識ずれを防ぐこと。２つ目は次の工程であるWBS作成のため。３つ目はプロジェクトが進むにつれ増える変更要求に対応するためです。
まず１つ目は文書化することでメンバー間での認識ずれを防ぐ役割があります。ご存じかもしれませんが、メンバー間の考えや理解がずれていると手戻りや修正が発生し、結果的にプロジェクトの遅延や失敗につながります。プロジェクトマネージャーとしてはこうした事態をなんとしても避けなければなりません。そのためにプロジェクトスコープ記述書を作成し、周知徹底するのです。
２つ目はプロジェクトの流れに関するものです。プロジェクトスコープ記述書の作成は計画段階の工程であり、次はタスクと成果物を定義するWBSを作成します。このWBS作成の際にスコープが不明確だとタスクや成果物が膨れ上がり、予算や期日を超えてしまいます。
３つ目はプロジェクトには変更がつきものだという話です。プロジェクトは予想外のことが必ず発生し、変更に迫られることがあります。こうしたときにスコープ記述書に照らし合わせて変更を定義したり、変更しない決定を下したりします。スコープ記述書が基準となるのです。
プロジェクトスコープ記述書の作成タイミング
プロジェクトスコープ記述書作成タイミングはスコープマネジメント計画工程の最初です。
プロジェクトの全体像から順にご説明します。
まずプロジェクトには立ち上げ→計画→実行→監視コントロール→終結という５つの段階があります。これをプロジェクトライフサイクルと呼びます。
この中でスコープ定義は計画の段階に含まれます。
さらに計画の中で以下の９つに分かれます。
- 統合マネジメント
- スコープマネジメント
- タイムマネジメント
- コストマネジメント
- 品質マネジメント
- 人的資源マネジメント
- コミュニケーションマネジメント
- リスクマネジメント
- 調達マネジメント
- ステークホルダーマネジメント
上記のスコープマネジメントの３つ目の工程がスコープ定義です。
具体的には以下の４工程となります。
- スコープマネジメント計画作成｜スコープマネジメント全体の管理や進め方を決定
- 要求事項収集｜顧客からの要求をまとめる要求事項収集を行う
- スコープ定義｜そして要求を元にスコープを定義します。
- WBS作成｜最後に定義したスコープをタスクや成果物に分解します
プロジェクトスコープ記述書の作成方法とサンプル
ここからは実際にプロジェクトスコープ記述書を作成する方法を説明していきます。また以下からサンプルがダウンロード出来ますので、サンプルを開きながら本章をご確認いただければと思います。
＜プロジェクトスコープ記述書の項目＞
- 基本情報
- 成果物スコープ
- プロジェクトスコープ
- 受入れ基準/完了基準
- 要素成果物
- 前提条件
- 制約条件
- 除外事項(Out of Scope)
- 承認
- 改定履歴
基本情報
まず基本情報としてプロジェクト名やプロジェクトマネージャー氏名や作成日、承認者等を記述します。
この資料がどのプロジェクトのものであるかを明確にするためのものです。
成果物スコープ
そしてまずこのプロジェクトで作る最終成果物を定義します。このプロジェクトはどういうアウトプットを出したらゴールと言えるのかを記述します。
この場合の成果物とは資料やプログラムなどアウトプットが明確なもののことです。
またこの時、現在分かっている範囲でなるべく具体的に記述します。この成果物スコープはゴールの役目を果たすのでずれがないように顧客やメンバーとコミュニケーションを図りながら齟齬がないようにしましょう。
プロジェクトスコープ
次にプロジェクトスコープです。これは成果物スコープを作成するための方法のこと。現在時点で想定している方法論を記述していきます。
資料なら顧客からのヒアリング方法や情報の取得方法など、コードならその開発手法や言語などがこれにあたります。
プロジェクトスコープを記述する際はどうしても細かい部分の具体論に目が行きがちですが、ここではあくまで最終成果物を作成するための方法を記載します。プロジェクトの開始から終了までの全体的な方法が分かるように記述しましょう。
受入れ基準/完了基準
方法と成果物が決まったら、次はそれらの受け入れ・完了の基準を作成します。システム開発での要件のように「〇〇を満たすこと」という記載方法だと明確になりやすいでしょう。
要素成果物
上記以外で現在把握している要素成果物を記載します。
プロジェクト全体における位置づけと品質などもわかる範囲で記述しておきましょう。
次工程のタスク定義やその後のスケジュールのマイルストーンなどの元になるのであいまいな表現は避けましょう。
前提条件
このプロジェクトにおける前提条件を記載します。プロジェクトの外部環境などがこれにあたります。市場の状況や国際情勢、業界内の規制などを記載します。
制約条件
プロジェクトの制約条件はいわゆる内部環境です。予算や人的資源の制約、設備環境の制約などがあります。
除外事項(Out of Scope)
先ほどの成果物スコープ、プロジェクトスコープの反対でこのプロジェクトには含まれない成果物と方法論を記載します。
この除外事項が明確になっており、顧客やプロジェクトオーナーと合意できていると余計な工程を省けるため、コストも時間も節約できます。
またメンバーも除外事項が明確だとアクションしやすくなるので自主性を発揮しやすくなるメリットもあります。
スコープの作成と同じくらい時間をかけて除外事項を作成しましょう。
改定履歴
最後にプロジェクトが進むにつれてスコープが改訂される場合があります。
そうした際におおもとのプロジェクトスコープ記述書に改定履歴がないと最終的に言った言わない問題に発展したり、一部のメンバーだけが勝手に改定した内容でプロジェクトを進めてしまったりといったことが起こります。
こうしたことがないようにおおもとのプロジェクトスコープ記述書に改定履歴を記載するようにしましょう。
また同様の理由で改定した場合は承認をもらうようにしましょう。
まとめ
今回はスコープ定義のアウトプット『プロジェクトスコープ記述書』についてまとめました。
プロジェクトをゴールまで導くプロジェクトマネジメントにはまだまだ他にもノウハウがあります。
