専門家が教えるPMBOKの理論と実践 
本記事は「専門家が教えるPMBOKの理論と実践」第3回です。
→ 連載一覧を見る
PMBOKはプロジェクトマネジメントの知識体系がまとめられたガイドブックです。第7版では原理・原則ベースの構成に変わりましたが、旧版の実用性は損なわれていません。プロジェクトマネジメントの実務において、第6版の知識体系は現在も有用です。
そこで本連載では、第6版に記された「10の知識エリア」に着目。まずはプロジェクトの成否に直結する「スコープマネジメント」について解説します。記事の監修者はRidgelinez（戦略から実装まで支援する総合プロフェッショナルファーム）のプロジェクト経験豊富なエキスパートたち。同社の尾形順一氏は、日本プロジェクトマネジメント協会および大学の講師も務めています。各分野の専門知識を身につけ、プロジェクト管理を強化しましょう。
スコープマネジメントとは？ PMBOKの基礎知識
プロジェクトの3要素
本題に入る前に、プロジェクトの基本要素を押さえておきます。それは「機能」「期間」「予算」の3つ。これらの関係を表したものが“鉄の三角形”です（下図参照）。
三角形の各頂点はPMBOKの知識エリア「スコープマネジメント」「スケジュールマネジメント」「コストマネジメント」に対応しています。
左右の違いを比較するために、どちらの三角形も「新幹線の予約アプリを開発するプロジェクト」と仮定しましょう。左のウォーターフォール型の場合、最初にプロダクトの機能（スコープ）を固定します。たとえば、以下6つの機能です。
機能要件
- 新幹線の時刻表を閲覧できる
- 新幹線の乗車予約ができる
- 新幹線の座席指定ができる
- クレジットカード決済ができる
非機能要件
- 同時アクセス数10万名に耐えられる
- 二要素認証を備える
上記の機能を実装するために、必要な予算と期間を見積もります。固定したはずの機能を後で増やす場合は、予算の増額や期間の延長が必要です。理論上は当然の措置ですが、それが果たされないケースもしばしば。PMBOKには、この問題を防ぐ方法が示唆されています。
右のアジャイル型の場合、まず予算と期間を固定します。その制約条件を前提に、開発可能な機能を見積もります。ウォーターフォール型より変化に対応しやすい利点はありますが、場当たり的な対応は禁物です。例示した6つの機能など、求める要件を明確化しておきましょう。
スコープの2分類
PMBOKにおける「スコープ」は以下の2種類に分けられます。混同しないように、それぞれの意味と完了基準を説明します。
プロダクトスコープ
「何をつくるか」という成果物を定義したものです。プロダクトやサービスなどを特徴づける特性・機能をさします。新幹線予約アプリを開発する場合、例示した6つの機能がプロダクトスコープです。この完了は「プロダクト要求事項」を基準に判断します。
プロジェクトスコープ
「何をやるか」という作業を定義したものです。規定された特性や機能を持つプロダクトやサービスなどを生み出すために行う作業範囲をさします。新幹線予約アプリを開発する場合、予算や期間の見積もり・計画・進捗管理などの作業全体がプロジェクトスコープです。この完了は「プロジェクトマネジメント計画書」を基準に判断します。
ビジネスアナリスト
特に補足のない場合、プロジェクトスコープのマネジメントを「スコープマネジメント」と呼びます。ここで求められるのは、ステークホルダーの要求事項を引き出し、文書化し、管理すること。そして、要求事項関連の活動を時間通り、かつ予算内に実行し、プロジェクトの価値を確実に生み出すことです。
このようなスコープマネジメントに関して、欠かせない取り組みがあります。それはビジネスアナリシス（業務分析／要求分析）。ビジネスニーズを特定し、適切な解決策を推奨する活動です。平たくいえば、要求事項の取りまとめです。
これを実行するのが「ビジネスアナリスト」です。専門職を置いていない場合、ビジネス側（顧客や営業部門）とシステム側（開発部門）双方の知識を備えた人材を起用しましょう。社内に適任者がいなければ、外部コンサルタントの活用も選択肢のひとつ。ビジネスアナリストとプロジェクトマネージャーの相互理解がプロジェクト成功のカギを握ります。
スコープマネジメントの流れ
スコープ管理の6ステップ
ここからは「スコープマネジメント」について、詳しく解説します。それはプロジェクトの具体的な作業を明確化し、その範囲を定義・管理する一連の活動。ウォーターフォール型の場合、具体的なステップは以下の6段階に分けられます。
要求事項の収集とスコープの定義
着目すべきは計画プロセス群。特に第2ステップ「要求事項の収集」と第3ステップ「スコープの定義」の区分が重要です。このステップを混同すると、後々に作業範囲が増えかねません。各段階で作成する文書や成果物などを追加し、それぞれの関係を下図に整理しましょう。
第2ステップ「要求事項の収集」を主導するのが、前述のビジネスアナリストです。ここでビジネスニーズ、ステークホルダーの要求、成果物の品質要求など、多面的な要求事項を取りまとめます。それらを整理したものが「要求事項文書」です（上図右上）。
この文書の作成後、第3ステップ「スコープの定義」を行います。プロジェクトマネージャーが主導し、プロジェクトの作業範囲・前提条件・制約条件・成果物などを定義。「プロジェクトスコープ記述書」を作成します（上図左）。
大切なのは、やること（スコープ）だけでなく、やらないこと（除外事項）も明記すること。そしてビジネス側とシステム側の合意を形成し、ステークホルダーやプロジェクトチームの共通理解を得ます。そうすれば、意図しないスコープ拡大を防げるでしょう。
要件定義≠スコープ定義
この計画プロセス群を軽視する企業は少なくありません。徹底的な「要求事項の収集」を行わずに、一足飛びに「要件定義書」を作成してしまうのです。これは日本企業の慣習に過ぎず、PMBOKの方法論とは異なります。
あえてPMBOKになぞらえるなら、「要件定義書」は「要求事項文書」と「プロジェクトスコープ記述書」を合わせたような文書です。しかし、大抵の「要件定義書」は要求事項の洗い出しが不十分であり、やらないこと（除外事項）が明記されていないことも珍しくありません。
その結果、設計・開発段階で新たな要求事項が出たり、多数の仕様変更などが発生したりします。このような事態を防ぐために、計画プロセス群の各ステップを確実に踏みましょう。
WBSの作成
第4ステップは、WBS（Work Breakdown Structure：作業分解構成図）の作成です。これは成果物の作成プロセスなどを階層的に分解し、作業管理の単位（ワークパッケージ）に分けた樹形図です（下図参照）。
WBSの作成において重要なのは、プロジェクトの全作業を抜け漏れなく洗い出すこと。そして、各作業の内容を明確化することです。より詳細な分解方法については、次回の記事（スケジュールマネジメント）で解説します。
仕様変更を防ぐスコープ管理のポイント
ビジネスアナリストを配置
適切なスコープマネジメントには、ビジネスアナリシス（業務分析／要求分析）が欠かせません。専任のビジネスアナリストを配置し、多面的な要求事項を収集しましょう。プロジェクト成功のカギを握るのは、ビジネスアナリストとプロジェクトマネージャーの相互理解です。
やらないことも明文化
「要求事項の収集」「スコープの定義」という2段階を踏んで「プロジェクトスコープ記述書」を作成します。そこで大切なのは、やることだけでなく“やらないこと”も明記すること。ビジネス側とシステム側の合意を形成し、ステークホルダーやプロジェクトチームの共通理解を得ましょう。
詳細なWBSを作成
WBSを作成して「何をやるか」を徹底的に明確にしてください。ここが不明瞭だと、必要な期間や予算の見積もりが正確にできません。プロジェクトの全作業を抜け漏れなく洗い出し、小さな作業単位（ワークパッケージ）に分解しましょう。
この記事に関するよくある質問 (FAQ)
スコープマネジメントとは、プロジェクトの具体的な作業（何をやるか・何をやらないか）を明確化し、その範囲を定義・管理する一連の活動です。PMBOKでは、要求事項の収集からWBSの作成・変更管理までを含む体系的なプロセスとして定義されています。このスコープマネジメントを行うことで、作業漏れやムダな工程を防ぎ、プロジェクトの成功率を高めます。
スコープ定義は「プロジェクトの作業範囲などを定義する活動」です。一方、要件定義は「顧客の要求をシステムなどの機能・性能に変換する工程」です。PMBOKでは、要件定義より上位の概念としてスコープマネジメントが位置づけられています。両者を混同すると作業漏れや仕様変更が発生する可能性が高まるため、文書化と合意形成が重要です。
▶関連項目：第2回記事「要求と要件の違い」スコープ変更を防ぐには、あらかじめ除外事項（やらないこと）を明文化することが大切です。「要求事項の収集」「スコープの定義」という2ステップを踏んで、ビジネス側とシステム側の合意を形成してください。そして、ステークホルダーやプロジェクトチームの共通理解を得ましょう。
WBSは「成果物や作業内容を抜け漏れなく整理する」ための作業分解構成図です。その作業単位（ワークパッケージ）は1〜2週間で完了できる粒度が目安です。粒度が細かすぎると管理コストが増え、粗すぎると作業内容があいまいになります。スケジュールマネジメントを行う際は、ワークパッケージをさらに細分化します。
▶関連項目：第4回記事「アクティビティの定義」  | ＜お役立ち資料＞ Lychee RedmineでできるPMBOK この記事で紹介した「PMBOK（ピンボック）」と、Lychee Redmineの活用方法を結びつけて解説した資料です。 この資料でわかること
|
監修者プロフィール
 | Ridgelinez株式会社 プロジェクトマネジメントおよびアジャイルDevOpsの専門家。日立製作所、デロイトトーマツコンサルティングなどを経て現職。大規模アジャイルおよびアジャイルシフト、DXにともなう組織的変革管理（OCM）において、数多くの実践経験を有する。日米欧のプロジェクトマネジメントおよびアジャイル標準に精通し、日米欧3団体の最上位認定を保有。企画・要件整理・設計・開発・テスト・運用・内製化まで、実践型の伴走を行う。これまでに40件以上のプロジェクトマネジメントを経験。日本プロジェクトマネジメント協会のPMBOK講座のほか、私立大学でもプロジェクトマネジメント論の講師を務める。 【保有学位】 【保有資格】 |
 | Ridgelinez株式会社 富士通システムソリューションズに入社後、フィールドSEとして流通業や運輸業などの基幹システム再構築プロジェクトに参画。富士通へ転籍後、プロジェクトマネージャーとして、総合商社・専門商社の基幹システム再構築プロジェクトを担当。2021年、アジャイル開発プロジェクトの実践経験を活かし、部門全体のアジャイル普及に向けた商談プロセス・商材の標準化や、アジャイル研修の設計・作成と講師などの活動を行う。2024年より現職。 【保有資格】 |
30日無料トライアルをはじめる
- 多機能ガントチャート/カンバン/バックログ/リソース管理/CCPM/レポートなど
- ・ クレジットカード登録不要
- ・ 期間終了後も自動課金なし
- ・ 法人の方のみを対象
このサイトはreCAPTCHAによって保護されており、Googleのプライバシーポリシーと利用規約が適用されます。
