このシリーズは、私がこれまで経験したプロジェクトで培ったマネジメントノウハウを、PMBOKの知識体系に沿って、駆け出しPMの方々や新入社員向けの読み物的な位置づけでノウハウや考え方をまとめています。ぜひご覧ください。
スコープマネジメントにおける各プロセスは以下の通りです。
ここでは、スコープマネジメントを行っていくうえでの注意点やコツ、そしてWBSについて触れていきます。
スコープ定義の重要性
スコープ定義は、ベンダーを守る生命線です。
言わば、何をどこからどこまでの範囲で実施するのか、責任を持つのかということです。
そんなスコープは幅と深さで考えると良いです。
例えば、あるシステムのある機能についてちょっとした改修を顧客から依頼されたとしましょう。
しかし、その機能を要望・要求通りに実現する場合、現行運用を変える必要が出てくることが分かったとします。その場合、現行どのような運用（AsIs）になっており、どのような運用に変える必要があるか（ToBe）まで検討する必要があるのかないのかについて、担当者間で協議する必要があります。
当然、顧客からしたら運用要件まで検討して、改善を提案してほしいに決まっています。しかし、ベンダー側はそのような工数まで当初の見積の中で見込んでいたのかという話に当然なります。
そのため、往々にしてベンダーと顧客との間で押し問答が繰り広げられます。
こうした事態を防ぐためにスコープ定義が重要となります。
そして、そのコツが、見積時及び作業開始時に、前提条件を明確にしておくことです。
前提条件の具体例を挙げていきます。
・〇〇システムの機能改修を行う
・システム連携テストは支援（データ作成、エラー調査）のみを実施し、実施主体は貴社とする
・運用要件及びインフラ要件は対象外とし、インフラ改修を要する場合は貴社にてインフラを担当しているシステムベンダーに調整いただく
・非機能要件に関する決定は貴社にて実施いただく
・画面数15本、帳票数8本、バッチ処理5本を想定しており、各機能は大：20人日以上、中：10人日以上小：10人日未満で作業量を概算
・上記に記載の内容は原則作業範囲外とし、必要に応じて担当者間で協議を行う
このような前提条件の挙げ方は、あらゆるシーンで使える考え方です。
どういう前提で、どういう想定を置いて、作業計画を立てたか明らかにします。それによって、このラインまでは守るが、これ以上は守れないことを明示することで揉め事が起きる前にけん制することに繋がります。
ぜひ、前提条件の置き方の参考にしてみてください。
スコープコントロール
スコープコントロールは、特に要件定義工程と設計工程でその力を発揮します。
それぞれの工程におけるスコープコントロールについてみていきます。
〇要件定義工程
要件定義工程は、最も要件が増減し変動しやすい工程です。したがって、要件定義工程を通じてスコープを正確に捉えることがプロジェクト全体を成功させる鍵です。
要件定義では、下図のgood曲線のように前半でしっかりと要件を出し切り、後半で収束させていくような進行が重要です。逆にbad曲線のような場合、要件定義の終盤になってベンダーが「このままでは要件定義が終わりません」「納期に納まりません」との相談を顧客にすることになります。しかし、顧客側も急に言われても困ります。
ここはプロとして要件をコントロールする必要があります。スコープを広げながらうまく要件を引き出しつつ、締めるところは締めるというメリハリが求められます。
〇設計工程
要件定義工程でも同じことがいえますが、スコープというのは要件定義書や設計書に書かれていることという意味合いでも使うことができます。
究極を言えば、ドキュメントに謳っていないことは実施しなくて良いのです。（極論です。）
例えば、受注登録画面にて受注取消についての言及がなければ、受注取消に関する処理を実装する必要はありません。たとえ、間違えた入力があった場合は取消をできるにしてほしいという要求があったとしても、機能定義として取消処理を謳っていなければ実装は不要です。なぜなら、システムによっては一度登録した受注データは明らかな誤りであっても内部統制の観点からシステムに残しておくために削除はできないようにするという要望も実際にはあるからです。したがって、ベンダー側が気を使って実装してあげることは無駄かもしれませんし、余計なお世話になるかもしれないため、勝手な真似はしない方が良いです。（もちろん極端な例であるため、明らかに改善が見込めるような点は顧客と調整のうえ改善することが望ましいです）
そういう意味で、ベンダーはスコープに漏れがないかどうかを確認しながらMECEに詰めていく必要があることを肝に銘じておく必要があります。逆に、顧客もシステムの処理定義は分からずともやりたいことはすべて網羅的に議論されているか、こちらが当たり前だと思っていることも確認は取れているかという観点でレビューをする必要があります。
こうしたスコープ定義が後々、変更管理が発生した際の重要な役割を果たすこととなります。変更管理については次の記事も御覧ください。
WBS（Work Breakdown Structure）について
WBSは、プロジェクトに必要な作業を要素分解していくことです。
知り合いのエンジニアと話をしたとき、WBSは進捗管理ツールのことだと言っていました。
確かに、要素分解してできたWBSの最下層のレベルで進捗管理していくことになるため、言わんとしていることは正しいですが、本来の正しい意味合いではありません。正しい理解をしたうえで、WBSと言うようにした方が望ましいです。
WBSとしてどこまで要素分解していくか、要素分解のコツを挙げたいと思います。
①それらを実施することで成果物が出来上がる作業であること
②その成果は目で見て分かるもの、測れるもの、触れるものであること
③その成果は、最長でも２週間（10営業日）、理想は１週間後に明らかになるものであること
④WBSでどうしても表現できないことであっても箇条書きで一覧化しておくこと（口頭指示を避ける）
上記の観点をもとにWBSを作成し、抜け漏れのないスコープ定義をしていきましょう。
まとめ
今回は、スコープについて解説してきました。
スコープはベンダーを守る生命線であり、プロジェクトが炎上した際、ベンダーを守る最後の砦です。
ぜひ、今回の内容をもとに何をやらなければいけないのかを意識してプロジェクトを遂行していければと思います！
参考文献
・情報処理教科書 プロジェクトマネージャ （三好康之著）
私は2019年度版を参考にしています。
・プロジェクトマネジメント実践講座 伊藤大輔（著）
コメント