スコープマネジメント
スコープマネジメントとは、プロジェクトの作業範囲や成果物を決めることです。プロジェクト失敗の原因の1つにスコープが不明確だったということがあります。ユーザーサイドと開発サイドで「何をするか」、「何を作るか」を明確に定義しておかないと、プロジェクトの終了間際になって「あれが漏れてる」「これも作ってもらわないと」というトラブルになりかねません。
そのため、PMBOKではプロジェクトの計画プロセスで作業範囲を取り決めることをスコープマネジメントとして定義しています。
ウォーターフォールの場合は、一般に見積時に概略スコープを提示し、要件定義工程で詳細なスコープを定義します。
作業スコープと成果物スコープ
PMBOKのスコープ管理では下記２種類のスコープが定義されています。
・プロジェクトスコープ…規定された特性や機能を持つ、プロダクト、サービス、所産などを生み出すために実行しなければならない作業
・成果物スコープ…プロダクト、サービス、所産に特有の特性や機能
少しわかりづらいので、プロジェクトスコープは「何をやるか」、成果物スコープは「何を作るか」と覚えておきましょう。
・プロジェクトスコープ（作業スコープ）…「何をやるか」
・成果物スコープ…「何を作るか」
なお、「プロジェクトスコープ」という言葉はぴんと来ないので、ここではあえて「作業スコープ」と呼ぶことにします。
プロジェクト規模とWBS
この２つのスコープの使い分けについて、簡単な例で説明しましょう。娘の誕生日パーティーで手作りケーキを作ることにしました。娘は楽しみにしています。娘はメロンが大好きなので奮発してメロンのスクエアケーキを作りました。ところが娘はたまたま帰るときにケーキ屋さんのウインドウで丸い苺ケーキを見たらしく、「苺のケーキじゃなきゃ嫌だ！それになんで丸くないの？」といわれてしまいました。
「わがままな娘だ！」と喧嘩するか「最初に訊いてから作れば良かった」と反省するか、あなたはどちらでしょうか。家庭なら「わがまま言わずに食べて！」となだめて済むと思いますが、ビジネスの場合、「思い込みで作ってしまった」ではプロジェクトは失敗です。
図１：誕生日ケーキ作成に対するスコープ
スコープの定義では、「何をやるか」「何を作るか」という範囲を明確にします。図１は誕生日ケーキを作るために「やるべきこと」と「つくられるもの」を分けたものです。このように作業スコープおよび成果物スコープは、それぞれ階層構造になります。前章で説明したWBS（Work Breakdown Structure）は、作業を分解してスコープを洗い出す図法でしたね。つまり、WBSで分解するのは成果物スコープではなく作業スコープです。
以前テレビで中国人の子供の誕生日会を紹介しているのを見たことがありますが、とてもとても豪勢な誕生日会でした。仮に誕生日ケーキを500個作ることになったということになれば、中間成果物を含め管理する必要がでてきます。１つの誕生日ケーキを作る際に「ヘタのとれた苺」まで管理する必要はないですが、500個だとそのレベルまで管理する必要があるのです。このように、同じアウトプット（苺ケーキ）を作る場合でも、どこまでBreakdownして洗い出すかはそのプロジェクトの大きさによっても異なるのです。
スコープは最初に定義して終わりじゃありません。例えば、途中で飾りつけにロウソクを追加する等の変更があるかもしれません。そのような場合は、速やかにスコープも見直しするようにします。
作業スコープと成果物スコープの使い分け
もう１つ「勤怠システム構築」といった開発プロジェクトで同じように考えてみましょう。
図２：勤怠システム構築に対するスコープ
① 作業スコープ
作業スコープは図２の左の部分のような「要求分析」「業務フロー作成」といった項目があげられます。これらはシステムでいうところの工程とタスク（作業内容）にあたります。「要求分析」という工程１つとっても実施するタスクはシステムによって異なってきます。「現行システムがあるのか」「他システムと連携をとる必要があるのか」「システム構成はクラウドを利用するのか」など、確認すべきことは多岐にわたります。そこで、やるべきことが漏れてしまわないためにも作業をWBSで展開して洗い出す必要があります。
②WBSの標準を持つ
作業を毎回、一から洗い出すとどうしても漏れが出やすくなります。そこでWBSの標準を持つことが重要になります。プロジェクトタイプ（開発スタイル、システム要件が同じようなプロジェクト）別に標準的なWBSを作っておき、それを新規に作成するプロジェクトに当てはめるようにするわけです。
当社の例でWBS標準を説明しましょう。当社ではOBPMというプロジェクト管理ツールを利用してプロジェクトタイプ別に作業スコープを標準化しています。図３の作業スコープ（工程タスク成果物登録）画面をご覧ください。この例はウォーターフォール型のWBS標準で、要件定義や基本設計などの工程の中に、現状業務のヒアリングと分析、新業務フロー策定、などのタスクが設定されています。
このようなWBSの標準化がきちんとされていない現場では、似たようなプロジェクトの作業スコープをコピーして作成するといった属人的なやり方が蔓延しています。標準化された作業スコープを利用することで、効率的なプロジェクト遂行が可能になります。
画面1：作業スコープ（工程タスク成果物登録）
③成果物スコープ
成果物スコープには図２の右の部分のような項目があげられます。プロジェクトが進むにつれスコープが変わる可能性もありますが、まずはこの「何を作るのか」を一覧にしてシステムの全体像をユーザーと意識をあわせる必要があります。
図3の成果物欄では「課題一覧表」「業務フロー」「機能一覧表」など、どのような成果物を作成・納品するかを定義しています。誕生日ケーキ作成の例でいうと苺ケーキをなす「スポンジ」「苺」「生クリーム」等が各機能（成果物）にあたります。これらは最終製品である苺ケーキの材料として用意するものなので、画面1の画面では納品対象欄のチェックがオフとなります。「勤怠管理システム構築」のようなシステム開発プロジェクトにおいては、最終的にシステムで使用する機能を漏れなく洗い出し、機能一覧にまとめます。
当社ではこの成果物スコープについてもOBPMで管理しています。「画面2：成果物スコープ（明細登録）」のような画面で機能の一覧とその要件、対応内容、種別、難易度を決めておき、見積やWBSへの連携を容易に行えるようにしています。
画面2：成果物スコープ（明細登録）
④スコープをもとにWBSを作成
「作業スコープ」が決まれば、それをBreakdownして図4のようなWBSを作成することができます。この時、最終的に機能レベルで管理するものは、「作業スコープ」をBreakdownし「成果物スコープ」と関連づけします。「勤怠システム構築」の例ですと「基本設計書作成」「詳細設計書作成」「コーディング」等については、それぞれが「成果物スコープ」の「機能」と結びついています。機能一覧で定義した「勤怠入力」「勤怠表」などの各機能（成果物スコープ）が3つのタスク（作業スコープ）に紐付いているわけです。
成果物は機能単位とは限りません。例えば、「データベース設計」という作業に対する成果物は「機能」までの落とし込みをする必要がなく、「ER図」という成果物で管理します。作業スコープに成果物が結びつかないものもあります。例えば、「データ移行」という作業スコープは、成果物を無理やり考えれば「移行されたデータ」ということになりますが、ばかばかしいので作業スコープだけで十分でしょう。
WBSの進捗管理を行うのに、「作業スコープベース」と「成果物スコープベース」の2通りが考えられます。どちらがいいでしょうか。これはよく議論にもなるテーマですが、実は実態のある成果物で進捗を管理した方が、正しい進捗が把握できます。そこで当社では、「成果物があるものは成果物ベース、ないものは（仕方がないので）作業スコープで管理するという方針にしています。
プロジェクト管理の三角形
プロジェクト管理の3大要素は、Quality（品質）、Cost（コスト）、Delivery（納期＝スケジュール）の頭文字を取ってQCDと呼ばれています。では、プロジェクト管理の三角形(The project management triangle)とは何でしょうか。こちらの方は、Cost（コスト）とTime（スケジュール）は同じなのですが、もう1つがQuality（品質）の代わりにScope（スコープ）となっています。 
図3：プロジェクト管理の三角形
前者の3大要素が守るべき目標なのに対し、後者の三角形は受ける成約(Constraint)です。そして、スコープとコストとスケジュールのうち、1つが変わったら必ず他の2つのうちどちらかを犠牲にしなければならないという鉄の法則になります。
例えば当初の計画よりも納期を縮める必要が出たとしたら、「人を増やしてコストを増やす」か「スコープを減らす」かどちらかを犠牲にしなければなりません。また、要件定義でスコープが増えた（仕様追加）場合は、「人を増やしてコストを増やす」か「納期を伸ばす」のどちらかで対応しなければスコープは完成しません。
プロジェクト管理の三角形は、アジャイル開発でよく登場します。例えば3週間のイテレーション期間内に計画したタスクが完了しない（納期が守れない）場合、「人を増やしてコストを犠牲する」か「スコープを減らすか」かどちらかを選択することになります（通常はスコープを犠牲にします）。
実は、QCDの3大要素も同じように、制約の均衡関係にあります。例えば予定より品質が悪かった場合、「人を増やして品質強化する（コスト増）」か「納期を伸ばして品質強化する（納期もコストも増）」となります。ただし、通常、品質は”犠牲”にできないので、何を犠牲にするかという観点では、品質の代わりにスコープを使ったトライアングルの方がよく使われるのです。もっともリーンスタートアップのクラウドサービスなどでは、品質を犠牲にしてスピード（納期）重視というケースもあって、一概に品質は犠牲にできないとも言えなくなりましたが…。
スコープマネジメントとOBPM
OBPMでWBSを作成する際、先にあげた明細登録（成果物スコープ）で、機能種別、難易度を登録しておくことにより、各タスクの作業工数（計画工数）が自動計算されるようになっています。ガントチャート上の「基本設計書作成」や「コーディング」といったタスクにこの機能（明細）を連携すると、自動的に計画工数分のバーが作成されますので、スケジュール設定が容易です。「作業スコープ」「成果物スコープ」をしっかり定義しておけばプロジェクトの計画はスムーズに進められるのです。
画面3：ガントチャート（チャート）
画面4：ガントチャート（表）
この記事の著者
株式会社システムインテグレータ 代表取締役会長
梅田 弘之
1995年に株式会社システムインテグレータを設立。2006年東証マザーズ、2014年東証第1部、2021年東証スタンダード上場。ECパッケージ「SI Web Shopping」や開発支援ツール「SI Object Browser」、統合型プロジェクト管理システム「OBPM Neo」など独創的なアイデアの製品を次々とリリース。また、ERP「GRANDIT」をコンソーシアム方式で開発。2019年に著書「AIのキホン」を出版し、現在はThinkITで「エンジニアならしっておきたいGPTのキホン」を連載中。
