【PMBOK】スコープマネジメントとは？｜失敗しない3つのコツ！

こんにちは、MARCUS(マーカス)です。

そんなPM初心者のあなたの悩みにお答えます。

プロジェクト計画で最初に作業をする『スコープマネジメント』。

今回は、そんなスコープマネジメントの目的や手順を書いていきます。

プロセス実施の3つのコツも合わせてご紹介しますので、読み終えれば「プロジェクト成功の確率がグッと上がるようになる」と思いますよ。

それではプロマネ歴13年、現役PMPのわたしが書いていきます。

スコープマネジメントとは？とその目的

スコープマネジメントとは一言で言えば、『何をするのか、もしくは何をしないのかを事前に明確にすること』です。

スコープマネジメントで規定された作業範囲をベースに「予算⇒スケジュール」と見積もり作業を進めますので、『プロジェクトの3大管理要素のはじめの起点となる最も重要な管理要素』になります。

プロジェクトマネジメントとは、限られた予算・納期で求められた品質をクリアーすること。

限られた予算と納期内で作業を実施しますので、対象となる『作業の範囲』は狭ければ狭いほど工数にかかる費用も少なくて済みますし、すること・しないことが明確であればあるほど、作業量の見積もり精度が上がりスケジュールの立案も容易になります。

例えば、あなたが工務店を営んでおり、施主に依頼されて家を新築する場合を例にするとわかりやすいと思います。

土地の購入・設計作図・官庁への申請・家の建設・家具や家電品の購入・外構工事など実際に家を建てて、施主が住み始められるようになるまでには多くの工程や作業があります。

新築の見積を依頼されたあなたは、まずは施主と打ち合わせをし、何があなたの仕事の範囲になるのかを明確にしなければいけません。

『何があなたの仕事範囲になるのか？または何が範囲外で施主が自分たちで手配することになるのか？』、仕事の範囲を1つづつ丁寧に決めていきます。

作業前の見積段階でできるだけ細かく仕様・範囲を決めることは、作業の漏れを防いだり、費用やスケジュールの精度を上げることにつながります。

「作業前に目標をより具体的にすること」で、実現性や現実性をあらかじめ検証することができますので、はじめから目標達成が困難な件名を引き受けてしまうというようなことがなくなり、プロジェクトの成功確率をグッと向上します。

スコープマネジメントは施主からの急な変更依頼にも非常に有効です。

明確なスコープとそれを元にしたコスト・スケジュールを事前に作成・承認を得ておくことで、急な変更による影響を施主に示すことができます。

根拠を示して追加費用の請求やスケジュールの変更を話しすることで、施主とのトラブルも少なく、スムーズに仕事を進められるようになります。

見積の範囲があやふやなまま仕事を受注して、施主との打合せのたびに言った言わないなんて議論をしていたのでは、施主からの信用もなくしますし、スケジュールも予定通りに進まずに当初の目標を達成することは難しいという状況になるでしょう。

プロジェクトの成功確率を上げたり、変更による不要なトラブルを予防することができます。

スコープマネジメントは、10あるプロジェクトマネジメントの知識エリアの中で唯一「何をするのか（What）」を規定するプロセスです。

スコープマネジメントは、プロジェクトの成否に影響を与える最重要項目を言えますね。

スコープマネジメントの6つのプロセス

それでは、実際の手順やプロセスについてご説明します。

スコープマネジメントは、PMBOK5つのプロセスのうち「計画プロセス群」と「監視・コントロールプロセス群」で合計6つのプロセスです。

①スコープ・マネジメント計画書

プロジェクトスコープ、プロダクトスコープがどのように定義され、妥当性が確認され、コントロールされるかを文書化するプロセスです。

何か具体的な数値目標を決めるとか言ったプロセスではなく、『プロジェクトを通してどのようにスコープを管理していくかというルールを決めるプロセス』になります。

５W1Hにしたがって「いつだれが何をどのように決めてるのか？なにを確認するのか？」といった具体的な管理運用方法を検討します。

プロジェクトは大人数のチームスタッフを作業を進めていくことになるので、いつでも誰でも勝手にスコープを変更できるような運用ルールでは、プロジェクトに混乱が起きて、間違いなくトラブルの原因になります。

それらを予防するために、事前に運用ルールをチーム内で共通認識するということが計画書作成の目的になります。

実際の数値目標や作業を規定する前に『それらを決めていく手順・ルールを予め決めておくプロセス』だということを理解しておいてください。

②要求事項の収集

要求事項の収集では、ステークホルダー（関係者）からプロジェクトに対するニーズや要求事項をヒアリングし、文書化します。

『プロジェクトスコープの根拠となる資料』を用意するためです。

立上げプロセスのプロジェクト憲章の作成では、おおまかな目標や要領が組織上位の役職者（オーナーや承認者）によって決められます。

しかし、実際に作業をしていくにあたっては組織上位の役職者だけではなく、中間管理者や担当者の協力を得ながら進めることが重要です。

組織上位者が知り得ないような現場の声や注意点をヒアリングすることで、プロジェクト結果の効果最大化を期待できますし、成功の確率もグッと上げることができます。

この作業の他のメリットは『ステークホルダー達にプロジェクトへの参画意識付けができること』『打合せでお互いを知ることで協力をお願いするときに、コミュニケーションがスムーズになる』という面もあります。

ヒアリングした結果については、『誰が・いつ・なにを要望したか』と言ったような形でまとめ、さらに『定量的、定性的な優先順位をつけること』で実際にどの要望をスコープに入れるのかを明確に評価しておきましょう。

「なんでこんなスコープが入っているんだ？」というような質問が組織上位者から出たときに、要求事項収集からの検討根拠を示すためです。

組織上位者が不要と判断すれば、スコープから削除すれば良いでしょうし、また、その判断結果を要望を出した担当者へ説明するときにも役立ちます。

せっかく要求事項収集で要望を出してもらっても、それがプロジェクトに反映されていなくてはステークホルダーががっかりするかもしれませんので、スコープから外されたような場合には、その結果や理由についても関係者に共有するようにしましょう。

要求事項の収集は、スコープの根拠、ステークホルダーとの最初のコミュニケーションということがわかっていただけたのではないでしょうか。

③スコープの定義

プロジェクト、プロダクトスコープに関する詳細を『プロジェクトスコープ記述書』にまとめるプロセスです。

何をするのか・しないのかのスコープ、その受入基準などを文書にします。

スコープ記述書の項目については、各組織のテンプレートを使用すれば良いと思いますが、一般的な目次は以下のようになります。

プロジェクト憲章のハイレベル情報、要求事項収集で特定された要求事項をベースにスコープの詳細や補足情報について、記載作成します。

前提条件は言葉の通り、プロジェクトを実行するにあたって『こうなるだろうと仮定している条件』ということです。

仮定が崩れれば、全ての計画が変わってきます。

もしもその前提条件が発生しなかったらどうなるのか、どのような影響がプロジェクト全体や各プロセスにあるのかを記載します。

前提条件はプロジェクトリスクに直結し、その内容も多岐に渡りますので制約条件とともによく検討し、その影響をステークホルダーに周知、承認してもらうようにしましょう。

④WBSの作成

WBSとは、Work Break Down Structureの略で、プロジェクトの成果物や作業をより細かく、マネジメントしやすいように要素分解するプロセスです。

これから実行するプロジェクトで『何を完了するべきかというタスクの一覧表（枠組み）』を作成します。

どこまで要素分解するかは、プロジェクトのアプローチによって異なりますが、工程別や成果物別にスコープを区分し、なおかつ詳細化のレベルについては一人の担当者が作業する最小単位を目安にすると良いと思います。

WBSは、スコープベースラインとなる資料です。

『WBSの全タスクが完了すればプロジェクト完了』となるように、また作業の取りこぼしや余分な作業を行うこともない、というようにまとめ上げるようにしてください。

⑤スコープの妥当性確認

スコープの妥当性確認では、完成した成果物を顧客やオーナーに正式に受け入れを承認してもらうプロセスになります。

各成果物の妥当性を必要に応じて都度、客観的に承認してもらうことで『最終的なプロジェクトの結果が顧客やオーナーに問題なく受け入れられる可能性を高めること』が目的です。

学校や仕事でレポートを作成するときでも、途中での確認なしにいきなり100%作り込んで提出して、全く内容がなってないなんて大きなダメ出しをもらったなんて経験ありますよね。

ある程度レポート作成が進んだ段階で上司や先輩に内容を見てもらい、方向性や内容に齟齬がないかを確認していったほうが最終提出で問題なくOKをもらえる可能性が高くなります。

『スコープの妥当性確認は、顧客やオーナーの成果物の受け入れを関心事をして行うプロセス』であることをよく理解しておいてください。

⑥スコープのコントロール

スコープのコントロールでは、スコープ記述書やWBSで規定されたスコープ通りに作業が進んでいるかを監視し、スコープベースラインへの変更を管理するプロセスです。

すべての元情報になるスコープの変更は、他のプロセスに大きな影響を与えます。

コストやスケジュール、資源など関連するプロセスをコントロールすることなくスコープが拡大することがないように、『スコープの変更要求や提案が必ず統合変更プロセスを通して処理』されるように監視・コントロールします。

知らない間にチームがしなくてよい作業をしていて、予算や時間を無駄にしていたなんてことがないように、注意深く監視していくことが重要です。

スコープマネジメント　失敗させないの3つのコツ！

わたしの経験を元に『失敗しないための3つのコツ』をご紹介します。

①常にスコープ関連資料を最新版に更新する

実際のプロジェクトでは、場面や状況に合わせて進行中に作業内容が変更されるということがよく起こります。

顧客の要望で作業量が増えることもありますし、予算の都合で計画の見直しが入ったり、作業途中で中止の判断が下るときもあります。

ここで注意したいのは計画が見直されるということは、それに合わせてスコープも見直されるということです。（あたり前ですが）

プロジェクトのWhatの領域にあたるスコープマネジメントは、全ての知識エリアと関連しますので、変更があるたびに常に資料を最新版に更新し、他のプロセスへと反映することが重要になってきます。

ちょっとの変更だからまあいいかと後回しにはせずに、どんな些細な変更でもスコープ資料の更新を続けることはスコープマネジメントでは最重要とも言える作業です。

あたり前のように聞こえますが、これが出ていなくて作業の漏れやムダからプロジェクト全体がうまく行かなくなったという例をいくつも見ていますので十分注意してくださいね。

②要求事項の収集は十分するが、ほどほどに

要求事項の収集は、打合せの場を設けたり期限を決めたりして実施するようにしてください。

スコープを決めるためにはステークホルダーのニーズや要求は非常に重要ですが、いつまでも意見を聞いていてはキリがなく、また、スコープとして採用するか洗い出しをする労力も馬鹿にならないためです。

ただし、ステークホルダーに参画意識を持ってもらったりコミュニケーションを取るためには、要求事項の収集は非常に有効なプロセスになります。

ステークホルダーたちの機嫌を損ねないように『十分に意見を聞くが、ほどほどに』というさじ加減に注意して作業を進めるようにしてください。

③スコープはスケジュールとともに可視化して共有する

最新のスコープを可視化して、チームメンバー全員に共有してください。

全員でスコープを共有確認することで、作業の漏れやあいまいなスコープをなくし、またチームメンバーとの認識のズレを防止することができます。

プロジェクトマネージャーだけがスコープを把握していたのでは、漏れや無駄を見落とすかもしれませんが、全員の目で見ていればより安心です。

一人の目よりみんなの目。メンバーを信頼して協力してもらいましょう。

まとめ　スコープマネジメントとは？｜失敗しない3つのコツ！

今回は、スコープマネジメントについて書きました。

わたしの経験から言いますと、PMBOK10つの知識エリアのなかで『スコープマネジメントが最重要管理要素』です。

そのことをまずは十分理解して頂いて、これからもPMBOKを学習していってもらえれば、プロジェクトの成功にまた一歩近づいたと思いますよ。

それでは、今回は以上です。