#060 プロマネのお仕事(本編10) - スコープ・マネジメント(今やらなくていいことを明確にしよう)
こんにちは。中小企業診断士の多田と申します。
いよいよ今回でプロマネのお仕事(本編)は最終回となりました。
最後はスコープ・マネジメントです。
# 051: 資源マネジメント
# 052: コミュニケーション・マネジメント
# 053: ステークホルダー・マネジメント
# 054: リスク・マネジメント
# 055: スケジュール・マネジメント
# 056: コスト・マネジメント
# 057: 品質マネジメント
# 058: 調達マネジメント
# 059: 統合マネジメント
# 060: スコープ・マネジメント ← 今回
スコープとは「範囲」のこと。スコープを定めることで、このプロジェクトで本当にやるべき仕事にリソースを集中させることができます。
普通なら「このプロジェクトでは何をやるのか」を決めていくのですが、ちょっと視点を変えて、「このプロジェクトでは何をやらないのか」を明確にするように心掛けると良いと思います。
「スコープ・マネジメント」とは
PMBOKの10の知識エリアでは2番目。計画と、監視・コントロールが主な仕事です。
PMBOKでの定義は以下のとおり。
「プロジェクトを成功裏に完了するために必要なすべての作業、かつ必要な作業のみが確実に含まれるようにするプロセスからなる。」
(PMBOK 第6版 p.23)
「すべての、かつ、必要な作業のみ」という言い回しから、「MECE」というキーワードが浮かんだ方も多いのでは。
「MECE」とは「Mutually Exclusive and Collectively Exhaustive」のことで、「お互いに重複せず、全体に漏れがない」という意味です。
「みーしー」とか「みっしー」と読みます。
PMBOK に書かれているプロセス
「スコープ・マネジメント」に書かれているプロセスは以下の6つ。計画プロセス群多めです。
(1) 「スコープ・マネジメントの計画」
→ (2) 以降のスコープ・マネジメントの進め方を決めて、文書化しておきます。
→ アウトプット文書: スコープ・マネジメント計画書、要求事項マネジメント計画書
(2) 「要求事項の収集」
→ ステークホルダーがこのプロジェクトで実現したいこと(ステークホルダーのニーズや要求)を集めて、文書化します。
→ この要求事項を満たしていくことが、他でもない、このプロジェクトの目的になります。
→ アウトプット文書: 要求事項文書
(3) 「スコープの定義」
→ プロジェクトのスコープ(範囲)を定義して、文書化しておきます。
→ スコープは、成果物の範囲(プロダクト・スコープ)と、作業の範囲(プロジェクト・スコープ)の2つからなります。
→ アウトプット文書: プロジェクト・スコープ記述書
(4) 「WBSの作成」
→ このプロジェクトの WBS (Work Breakdown Structure) を作成します。
→ 詳細は、#055 スケジュール・マネジメントも参考にしてみてください。
→ アウトプット文書: スコープ・ベースライン(スコープ記述書、WBS、WBS辞書)
(5) 「スコープの妥当性確認」
→ 成果物が完成したら、その成果物が要求を満たしているかどうか確認し、ステークホルダーの承認を受けます。
→ このプロセスが終了したらプロジェクトは終結フェーズに移行します。
(6) 「スコープのコントロール」
→(3) で決めたスコープを監視し、何か変更が生じた場合にはその変更をコントロールします。
これらの文書を全部きちんと作ろうとしてもなかなか難しいと思いますので、
以下、ポイントを3つにしぼって、最低限これだけはやっておいた方が良いことをまとめてみます。
「要求事項の収集」→ お客様の声に耳をかたむけよう!
基本的に、要求事項を収集する際には、ステークホルダーの意向を最優先で考えます。
しかし、個人的には、この段階で、ステークホルダーの方の意向がお客様の要求と合致しているかどうかについて、プロマネの視点からある程度助言しておくのが良いと考えています。
なぜなら、ここで決めたプロジェクトの目的がずれてしまっていると、そのあといくら頑張ってもプロジェクトとしてのアウトプットにつながりにくいからです。
例えば、最近のマーケティング用語で 「UPS」(Unique Selling Proposition、その製品・サービスの、自社固有の提供価値)というのがあります。
他社との競争に勝つためには、この UPS を明確にし、顧客に打ち出していくことが重要とのこと。
しかし、実際の商品開発やサービス開発の現場では、お客様のことを考えずに自社のユニークな技術だけにフォーカスして作成した UPS が多いように見受けられます。
こうした、差別化のために自社の技術を無理やり前面に出すやり方は、右肩上がりだった昭和の時代には通用しても、今の時代にはもうお客様に刺さらないと思います。自社の製品は、自社の技術発表の場ではありません。
プロジェクト開始時にこのような間違いを犯してしまうと、その後プロジェクトに投入されるであろうリソースが全て無駄になってしまいます。
「スコープの定義」→ 今やらなくていいことを明確にしよう!
スコープを定義する際には、やることにフォーカスするよりも、やらないことを明確にする方が簡単だし、意志決定がはっきりしてきます。
プロジェクトの途中で、ステークホルダーの方から「○○もできるといいねー」みたいな気軽な要求が飛んでくることがあります。
こういう会話は、楽しいし、前向きな話が多いので、その場も盛り上がることが多いです。
しかし、プロマネとしては、安易に「社長、それやりましょう!」などと安請け合いすることは避けるべきです(その場では社長からの評価は上がるでしょうが…)。
その機能は今回のプロジェクトのスコープに入っていないことを確認した上で、どうしても追加したい場合は、前回ご紹介した統合マネジメントの変更管理のプロセスを踏むべきです。
とはいえ、「それはできません」と冷たく言ってしまうと場の雰囲気が悪くなってしまうと思うので、「是非それは次のフェーズで検討しましょう!」などと前向きに発言すると良いと思います。
これならば、言われた方も否定された感じにならないし、次の仕事にもつながっていくように思います。
「WBSの作成」 → 「できると思います」は御法度。「いつならできるか」きちんと確認しよう!
WBS はプロジェクト管理の基本です。作成したWBSをベースラインとして日々の進捗確認を行っていきます。WBSの存在しないプロジェクトはあり得ません。
…なのですが、
実際には、WBSの精度が甘かったり、既に進捗と合っていないにもかかわらず WBS が更新されていなかったりするプロジェクトも散見されます。
そうなってしまうと、ステークホルダーやメンバーから「あの作業はいつ終わりますか」と聞かれても、プロマネが状況を即答できない状況になってしまいます。
そのような場合にプロマネが最もやってはいけないのが、「多分その作業は○○くらいには終わります」という、無責任な発言をしてしまうことです。
プロマネがこれをやり始めると、プロジェクトは際限なく混乱します。
こういうときほど、一旦立ち止まって、メンバーから状況を聞くなどして WBS の引き直しを行うべきです。
プロマネは、こうした「多分できると思います」といった曖昧な発言をしてはいけません。
できる、というのであれば、必ず条件を明確にすることが必要です。
例えば、あと100万円予算があればできます、とか、あと5日あればできます、とか、○○を仕様から削って良ければできます、など、条件と根拠を伴った発言ができれば、ステークホルダーやメンバーからの信頼を受けることができるのではないでしょうか。
ただ、そうは言っても、プロジェクト後半の WBS は細かく作れないことはあると思います。
そういう場合には、直近のところ(概ね3ヶ月程度)は詳しく、それ以降の WBS はざっくり作っておき、1ヶ月毎くらいの期間で WBS を作り直していくようにするのが良いと思います。
(こうした WBS の作り方を、「ローリングウェーブ計画法」と呼びます。)
次回以降について
今回までの「本編1〜10」で、PMBOKの10の知識エリアについてまとめてきました。
正直ちょっと教科書的な話に寄りすぎてしまった感がありますので、もうちょっと身近な例をあげつつ、あと数回、PMBOK の重要性について書いてみようと思っています。
ちなみに、少々種明かしをしてしまうと、
今回この連載をやってみようと思った理由の1つに、4/19(日)に開催が予定されていた IPA のプロジェクトマネージャ試験に向けて、自分の知識を再整理したいという狙いがありました。
資格試験などの勉強をするにあたって、こうした強制的なアウトプットの機会を作って自分に課題を課すというのは個人的には常套手段だったりします。
残念ながら今回の試験は諸般の事情で中止になってしまいましたが、また次回機会があれば受験を検討したいと思っています。
IPA 独立行政法人 情報処理推進機構：制度の概要：プロジェクトマネージャ試験
https://www.jitec.ipa.go.jp/1_11seido/pm.html
まとめ。
(1) 「スコープ・マネジメント」とは、そのプロジェクトの成果物と作業を、漏れなく・ダブりなくリストアップし、管理していく仕事のことです。スコープは、プロジェクトのステークホルダーの意向を元に、お客様の視点も取り入れながらプロジェクトの開始時に定義しておきます。
(2) スコープを管理する際には、やることに目を向けるのはもちろんですが、「今はこのプロジェクトでやらなくても良いこと」に目を向けることも同じように重要です。油断しているとどんどん仕事は増えていきますが、場合によっては今のプロジェクトが終わった後、次のプロジェクトで実現するなどのコントロールも必要です。
(3) プロジェクトのベースラインが WBS できちんと管理されていないと、そのスコープに含まれている仕事がいつまでに完了するか把握できない事態に陥りがちです。常にベースラインを最新のものにアップデートすることで、ステークホルダーやメンバーからの「この仕事はいつ終わるのか」という質問に対して責任ある回答をすることがプロマネには求められます。
----------
(ここに書かれている内容はいずれも筆者の経験に基づくものではありますが、特定の会社・組織・個人を指しているものではありません。)