SGのWBS・スコープ対策｜成果物の分解と追加要望の判断を図解

現行SGシラバスVer.4.1には、プロジェクト憲章、ベースライン、ステークホルダ、スコープ、WBS、活動の定義などが挙がっています。アジャイルかウォーターフォールかを選べても、何をどこまで完成させる計画かが曖昧なら、担当や見積りの前提をそろえられません。

WBSを読むときは、上位の仕事に対して下位に何が含まれるかを確かめます。PMIの公開解説は、成果物に着目した階層的な分解として説明しています。単に思い付いた作業を並べたリストでは、同じ仕事の重複や、必要な仕事の抜けを見つけにくくなります。

本記事はSGの範囲にある基礎概念を、当サイトのケースで学ぶものです。PMBOKの特定版の全工程をSGの必須知識としたり、資格の出題頻度を断定したりするものではありません。開発手法とスクラムとは目的を分けて読んでください。

外部の提案や見積りで仕事の範囲を具体化する場面はSGのRFI・RFP・RFQと調達の判断で、要求と回答の前提をそろえて考えます。 日程の計算はSGのPERT・クリティカルパスと余裕時間で、並行作業の合流と短縮後の経路を独自の数値例で確認できます。

架空の会社Vが、利用中の40人分のメールボックスを新環境へ移すプロジェクトを始めたとします。今回は現行のメールと利用設定の移行、動作確認、利用案内、運用担当への引継ぎを対象にし、保管済みの過去アーカイブ200件の再整理と端末の買替えは対象外と合意しました。対象数も境界も説明用の設定です。

「移行が終わった」という言葉だけでは、担当者によって完成像が変わります。データを転送した時点なのか、利用者が送受信できることを確認した時点なのか、引継ぎまで終わった状態なのかを具体化します。会社Vでは、合意した範囲ごとに確認方法と受入れを判断する担当を定めることにします。

対象外にした過去アーカイブも、不要だから自由に削除してよいわけではありません。別の管理責任や保存の要求があるかを確認し、今回扱わない範囲の担当を明確にします。スコープの境界を決めることは、法令・契約・社内規程の義務をなくすことではありません。

会社Vの計画を「設定する・コピーする・説明する」とだけ書くと、何を完成させる作業かが見えません。たとえば移行対象一覧、移行結果と確認記録、利用案内、引継ぎ資料のように、確認できる成果物との対応を置きます。成果物にはシステムだけでなく、必要な計画や管理の記録も含めて考えます。

次の図は、会社Vの仕事の一部を三つのまとまりにした説明図です。実務用の完全なWBSではなく、下位の細分化も省略しています。実際には管理・見積り・責任を明確にできる単位まで具体化し、何を含むかの説明を添えます。箱を細かく増やすこと自体が目的ではありません。

移行結果の確認を「移行準備」にも「受入れ」にも同じ内容で数えると、担当や見積りが重複します。一方、利用案内を誰も担当していなければ、転送処理だけが終わっても、今回の合意した完成には届きません。上位と下位の対応をたどり、漏れと二重計上を確かめます。

WBSの上から下、左から右という配置を、そのまま着手順序と読み替えないでください。会社Vで利用案内を作るために何の設定が確定している必要があるか、確認作業にどの担当者が必要かなどを検討して、活動の順序、所要期間、資源を計画します。

「引継ぎ資料」というまとまりを置いただけでは、作成・レビュー・修正・受入れにいつ誰が関わるかは決まりません。また、担当が同じ二つの作業を、依存関係がないからと無条件に同時実施できるとも限りません。範囲の分解、順序、担当の空き、日程は関係していても別の情報です。

見積りや日程を出すときは、対象と前提を明示します。40人分の現行メールを前提にした見積りを、アーカイブ200件の整理まで含む数字として使わないようにします。数量だけで作業時間が比例すると決めず、調査や確認の方法が変わるかも確かめます。

会社Vで動作確認の担当が未定だったと分かった場合、動作確認は元から合意した範囲です。必要な仕事が計画から漏れていた問題として、担当・工数・日程への影響を確認します。WBSに書いていなかったことだけを理由に、依頼者の追加要望だと決めつけないでください。

一方で、対象外とした過去アーカイブ200件も今回再整理してほしい、という要望なら、合意した境界の変更を検討する話になります。「ついでに便利になるから」と担当者だけで始めると、期限や他の仕事への影響が共有されないまま進みます。

どちらも影響を放置してよいわけではありません。元の合意と照らして理由を記録し、組織で決めた権限・手順に沿って判断を求めます。依頼者が急いでいることと、変更を承認する権限があることも分けます。案件ごとの承認範囲を無視して、全て同じ役職や会議が承認すると決め付けません。

会社Vのアーカイブ追加案を記録するなら、次の表のように、要望された内容、影響、決定を分けます。検討中の案がチャットに書かれている状態と、必要な承認を得た状態は同じではありません。変更しないときにも、理由と今後の扱いを記録すると認識の食い違いを減らせます。

承認されたら、対象範囲、見積り、日程、受入条件など関係する計画を整合させ、関係者へ伝えます。比較の基準となるベースラインも、所定の変更管理で扱います。古い版を無言で上書きし、最初から追加案まで含まれていたことにはしません。実績を評価するときも、どの版との比較かを確かめます。

設定を実際に反映する際の検証・切戻しはセキュリティの変更管理、運用後の合意と実績はSLA・サービスレベル管理へ分けています。

復習では「利用案内を作る」という活動に対し、出来上がる案内の対象読者、必要な内容、誰がどう確認するかを書いてみます。仕事の名前を説明できても、何が完成すればよいか分からない場合は、元の目的や受入条件へ戻ります。これは問題の正解を変えるのではなく、適用条件を理解するための独習です。

ケースの条件整理は科目Bの読み方、学習範囲はSGの目次へ。無料6問で解説や操作を試せますが、プロジェクト管理分野の全理解度を診断するものではありません。収録範囲と購入条件はSGの教材・料金で確認できます。