【スコープ 概念 1】

何かコトを起こす場合、目的があれば「何をどこまでやれるのか」はだいたい決まります。ただ、先例のないプロジェクトでは、いくら専門家が集まっても考慮漏れは発生するもの。プロジェクトが進行するにつれ最初に想定していなかった考慮点は発生してくるでしょう。

そのプロセスも含め、範囲をきちんと決めるのがこの知識エリアです。


プロジェクトスコープマネジメントでは

5.1 スコープ計画
5.2 スコープ定義
5.3 WBS作成
5.4 スコープ検証
5.5 スコープ・コントロール

が定義されています。


5.1 スコープ計画 (計画)
 プロジェクトでの作業を大まかに決めます。プロジェクトの重要度によって、今まで経験したものを元に簡単にすませるのか、時間を掛けて行うのかは変わってきます。

5.2 スコープ定義 (計画)
 スコープ計画と他の情報を基に、詳細化します。また、主な成果物も決めます。

5.3 WBS作成 (計画)
 WBSを作成します。WBSにはワークパッケージのレベルまでブレイクダウンして記載します。

 具体的にどこまでブレイクダウンすればいいのか、というだけでもかなりの説明がなされている。実際に使って慣れるのが一番であるし、経験上プロジェクトの規模によって、また立場によってレベル感の違うな、ということはあるのだが、「その作業を分解できないレベル」とされている。

 これも経験談だが、WBSに記載するのは成果物があるものだけではなく、他部署との同期をとるためのマイルストーンの埋め込みなども行った方が運営上無理が発生しにくい。


5.4 スコープ検証 (監視・コントロール)
 完了した作業の承認を受けます。


5.5 スコープ・コントロール (監視・コントロール)
 変更があった場合、スコープの修正を行います。

 

 経験上ですが、スコープがあとあとぶれる要因は「元の要件定義が甘い」「顧客が積極的に関与していない」ということが多いです。スコープが変わると当然費用も変わってくる場合が多いのですが、ITの孫請けより下の請けだと変更でも費用が取れず、泣き寝入りしているところもたくさんありました。


 余談ですが、IT産業が成熟するためにはこのプロセスが改善されることも一つの要素だと私は考えています。