【第8章】作業スコープと成果物スコープの使い分け:スコープマネジメントとは

 2017.04.27  株式会社システムインテグレータ

スコープとは

075072.jpg望遠鏡(テレスコープ)を思い浮かべてみてください。「北の方向をみてください」と言っても人によって見えるもの、範囲は変わりますよね。この範囲を明確にし、皆が同じ方向をみることが重要です。スコープ管理では「何をやるか」「何を作るか」という範囲を明確に決め、プロジェクト関係者と認識をあわせ進めていきます。

作業スコープと成果物スコープ

プロジェクトのはじめには、ステークホルダー(プロジェクト関係者)と共通認識をもってゴールに向かうべくプロジェクトでやるべき範囲を決定します。

PMBOKのスコープ管理では下記2種類のスコープが定義されています。
・プロジェクトスコープ…規定された特性や機能を持つ、プロダクト、サービス、所産などを生み出すために実行しなければならない作業
・成果物スコープ…プロダクト、サービス、所産に特有の特性や機能

少しわかりづらいので、プロジェクトスコープは「何をやるか」、成果物スコープは「何を作るか」と覚えておきましょう。
・プロジェクトスコープ(作業スコープ)…「何をやるか」
・成果物スコープ…「何を作るか」

なお、「プロジェクトスコープ」という言葉はぴんと来ないので、ここではあえて「作業スコープ」と呼ぶことにします。

スコープを洗い出す(例:誕生日ケーキ)

112392.pngこの2つのスコープの使い分けについて、簡単な例で説明しましょう。娘の誕生日パーティーで手作りケーキを作ることにしました。娘は楽しみにしています。娘はメロンが大好きなので奮発してメロンのスクエアケーキを作ったとします。ところが、たまたま帰るときにケーキ屋さんのウインドウで丸い苺ケーキを見たらしく、「苺のケーキじゃなきゃ嫌だ!それになんで丸くないの?」といわれたらどうでしょう。

「わがままな娘だ!」と突き放すか「最初に訊いてから作れば良かった」と反省するかは人それぞれと思いますが、「わがままな客だ!」「思い込みで作ってしまった」ではプロジェクトは失敗です。

極端な例かもしれませんが、意思疎通はとれているものと勝手な思い込みは大変危険です。細かなことはプロジェクトの途中で決めていくとしても、大枠について最終的なイメージがぶれないように、最初にスコープをしっかりと定義しなければなりません。

01-1.png図1:誕生日ケーキ作成に対するスコープ


スコープの定義では、「何をやるか」「何を作るか」という範囲を明確にします。図1では誕生日ケーキを作るために「やるべきこと」「作られるもの」を洗い出しました。この例では、料理器具(システムでいうところのサーバー等)はそろっているものと考えてください。ここでは「材料」や「苺ケーキの具材」といったものまで成果物として含めてみました。

1つのケーキを作るには少々大げさなスコープになっているかもしれませんね。以前テレビで中国人の子供の誕生日会を紹介しているのを見たことがありますが、とてもとても豪勢な誕生日会でした。仮に誕生日ケーキを500個作ることになったということになれば、中間成果物を含め管理する必要がでてきます。1つの誕生日ケーキを作る際に「ヘタのとれた苺」まで管理する必要はないですが、500個だとそのレベルで管理すべきかも知れません。どこまでBreakdownして洗い出すかはそのプロジェクトに適した粒度で行ってください。

スコープは最初に定義して終わりじゃありません。例えば、途中で飾りつけにロウソクを追加する等の変更があるかもしれません。そのような場合は、速やかにスコープも見直しするようにします。 

プロジェクト管理に関するお役立ち資料

スコープを洗い出す(例:勤怠システム構築)

では実際のプロジェクト、例えば「勤怠システム構築」といったプロジェクトで同じように考えてみましょう。

02-2.png図2:勤怠システム構築に対するスコープ

① 作業スコープ
作業スコープは図2の左の部分のような「要求分析」「業務フロー作成」といった項目があげられます。システムでいうところの工程とタスク(作業内容)にあたります。「要求分析」1つとっても実施するタスクはシステムによって異なってきます。「現行システムがあるのか」「他システムと連携をとる必要があるのか」「システム構成はクラウドを利用するのか」確認すべきことは多岐にわたります。確認の結果、やるべきことが漏れてしまわないためにも作業をWBSで展開して洗い出す必要があります。

作業を毎回、一から洗い出すとどうしても漏れが出やすくなります。そこでWBSの標準を持つことが重要になります。プロジェクトタイプ(開発スタイル、システム要件が同じようなプロジェクト)別に標準的なWBSを作っておき、そこから自身のプロジェクトに当てはめるようにします。
 [RELATED_POSTS]
当社の例でWBS標準を説明しましょう。当社ではOBPMというプロジェクト管理ツールを利用してプロジェクトタイプ別に作業スコープを標準化しています。図3の作業スコープ(工程タスク成果物登録)画面をご覧ください。この例はウォーターフォール型のWBS標準で、要件定義や基本設計などの工程の中に、現状業務のヒアリングと分析、新業務フロー策定、などのタスクが設定されています。

このようなWBSの標準化がきちんとされていない現場では、似たようなプロジェクトの作業スコープをコピーして作成するといった属人的なやり方が蔓延しています。標準化された作業スコープを利用することで、効率的なプロジェクト遂行が可能になります。

03-1.png図3:作業スコープ(工程タスク成果物登録)

② 成果物スコープ
成果物スコープには図2の右の部分のような項目があげられます。プロジェクトが進むにつれスコープが変わる可能性もありますが、まずはこの「何を作るのか」を一覧にしてシステムの全体像をユーザーと意識をあわせる必要があります。

「帳票を作成するか」「スマートフォンについては、勤怠入力のみにする」等最終的な成果物のイメージを固めます。誕生日ケーキ作成の例でいうと苺ケーキをなす「スポンジ」「苺」「生クリーム」等が各機能(成果物)にあたります。調理の過程で形を変えていきますが、どれも最終的に必要な具材になります。「勤怠管理システム構築」でも同様に、最終的にシステムで使用する機能を漏れなく洗出し、機能一覧にまとめます。

当社ではこの成果物スコープについてもOBPMで管理しています。「図4:成果物スコープ(明細登録)」で機能の一覧とその要件、対応内容、種別、難易度を決めておき、見積やWBSへの連携を容易に行えるようにしています。

04.png図4:成果物スコープ(明細登録)

③ スコープをもとにWBSを作成
「作業スコープ」が決まれば、それをBreakdownしてWBSを作成することができます。この時、最終的に機能レベルで管理するものは、「作業スコープ」をBreakdownし「成果物スコープ」と関連づけします。「勤怠システム構築」の例ですと「基本設計書作成」「詳細設計書作成」「コーディング」等については、それぞれが「成果物スコープ」の「機能」と結びついています。

成果物は機能単位とは限りません。例えば、「データベース設計」という作業に対する成果物は「機能」までの落とし込みをする必要がなく、「ER図」という成果物で管理します。作業スコープに成果物が結びつかないものもあります。例えば、「データ移行」という作業スコープは、成果物を無理やり考えれば「移行されたデータ」ということになりますが、ばかばかしいので作業スコープだけで十分でしょう。

WBSの管理を作業スコープベースで行うか、成果物スコープで行うか、どちらがいいでしょう。実は成果物で進捗を管理した方が、正しい進捗が把握できます。当社では、「成果物があるものは成果物ベース、ないものは(仕方がないので)作業スコープで管理するという方針にしています。

ちなみにOBPMでWBSを作成する際、先にあげた明細登録(成果物スコープ)で、機能種別、難易度を登録しておくことにより、各タスクの作業工数(計画工数)が自動計算されるようになっています。ガントチャート上の「基本設計書作成」や「コーディング」といったタスクにこの機能(明細)を連携すると、自動的に計画工数分のバーが作成されますので、スケジュール設定が容易です。「作業スコープ」「成果物スコープ」をしっかり定義しておけばプロジェクトの計画はスムーズに進められるのです。

05.png図5:ガントチャート(チャート)

06.png図6:ガントチャート(表) 

(株式会社システムインテグレータ 羽佐田奈津美)

recruit

ranking

プロジェクト管理ツール:OBPMイラスト図解でよくわかるガイド

RELATED POST関連記事


RECENT POST「プロジェクトマネジメント講座」の最新記事


この記事が気に入ったらいいねしよう!
プロジェクト管理ツール比較ガイド:全7製品を10項目で徹底調査
ブログ購読のお申込み

RANKING人気資料ランキング

RECENT POST 最新記事

RANKING人気記事ランキング