プロジェクト計画と変更管理｜スコープ・WBS・関係者の合意をつなぐ

現場から便利な追加機能を頼まれ、担当者がそのまま実装した。機能は増えても、試験や教育の時間が足りず、予定日に使えないことがあります。プロジェクトの計画は作業の羅列ではなく、何を完成させるか、誰が承認するか、変更で何が動くかを合意する仕組みです。

この記事で理解すること

• 製品の機能範囲とプロジェクトの作業範囲を区別し、成果物と受入条件を定める。

• WBSで必要な作業を分解し、担当・見積り・完了条件を対応付ける。

• 変更要求の影響を評価し、権限に従う判断と計画更新を進める。

架空の会社が、倉庫の在庫照会と出庫登録を導入する例です。今回の対象は照会・出庫・履歴・現場教育で、自動発注は対象外と合意しています。依頼者、現場、購買部、開発担当、プロジェクト管理者が関わります。工数の値は教材用で、特定手法を全案件へ強制する例ではありません。

スコープと受入条件：何を完成と呼ぶか

製品スコープは、システムが提供する機能や特性の範囲です。プロジェクトスコープは、それを完成させるために行う作業の範囲です。画面を作るだけでなく、移行、試験、運用手順、教育なども必要なら作業の範囲へ含めます。

対象外も文章で明示すると、期待のずれを減らせます。今回の自動発注を「いつか必要」とすることと、今回の予算・期日で完成させる約束は別です。あいまいな希望を、承認済みの要件として扱わないようにします。

受入条件は、成果物を認めるための判断基準です。「使いやすい」という表現だけでは担当者ごとに結論が変わります。対象業務・入力条件・期待結果・承認者を具体化します。テストケースの網羅率や品質分析の詳細は別の主担当記事へ分けます。

WBS：成果物に必要な作業を階層化する

WBSはWork Breakdown Structureで、プロジェクトの範囲にある作業を階層的に分解する構造です。管理可能な単位のワークパッケージへ分け、範囲、担当、必要な資源、見積り、完了条件を記述します。作業の抜けと重複を見つけるために使います。

WBSの上下関係は、いつ実行するかを表す工程の矢印とは違います。同じ成果物を作る設計と試験でも、日程や依存関係は別に設定します。クリティカルパスやバッファの計算は日程の記事を参照します。

下位の作業を合わせると上位の範囲を全て含み、同じ作業を複数の枝へ二重計上しないようにします。管理、調整、資料、受入支援も必要なら含めます。コードを書く工数だけを足すと、見積りの対象が計画の範囲と合いません。

工数と期間：人数だけで機械的に割らない

工数は作業量で、期間は開始から完了までの時間です。8人日の作業は、一人が8日分働く量を表しますが、二人を追加すれば必ず4日で終わるという意味ではありません。順序依存、技術、担当者の可用時間、レビュー待ちがあるためです。

見積りには前提と根拠を残します。既存機能を再利用できるのか、外部サービスの試験環境があるのか、現場が受入を行う時間を確保できるのかで値は変わります。日程・費用・品質を別々の表で管理しても、共通の成果物へ対応付けて判断します。

ステークホルダー：影響を受ける人と決定権を分ける

ステークホルダーはプロジェクトに影響する、または影響を受ける関係者です。依頼者だけでなく、利用部門、運用、購買、外部連携先も対象になります。誰が要求を出し、誰が影響を確認し、誰が費用・期日・受入を承認するかを整理します。

要求を出せる人が、そのまま予算の増額や日程変更を決められるとは限りません。承認者と判断基準を計画で定め、影響を受ける部門へ必要な情報を届けます。関係者を全員集めるだけでなく、判断が必要な内容を明らかにします。

ベースライン：比較に使う合意済みの基準

ベースラインは、合意して管理対象とした計画や要件等の基準です。現在の実績や見込みをその基準と比べ、差異と変更を説明します。差異が出るたびに元の基準をこっそり書き換えると、何が変わったかを判断できなくなります。

ベースラインは変更できない永久固定の計画ではありません。承認した変更を反映し、版と日付、理由、承認記録を管理します。予測を更新することと、合意済みの基準を変更することは別の操作です。ソースコードのブランチやリバートの仕組みも別テーマです。

変更要求：実装前に影響と代替案を評価する

現場から「在庫が少ないとき自動発注してほしい」と依頼が来ました。この追加は画面だけでなく、購買の承認、外部発注先、失敗時の再処理、権限、試験、教育に影響します。便利さを評価するだけではなく、現在の対象と制約のどこが変わるかを調べます。

承認前の実装が積み重なり、合意した対象が無管理に広がることをスコープクリープと呼びます。小さい変更も、組合せで試験や教育に影響する場合があります。標準的な小変更を簡略手順で判断する方式でも、対象・権限・記録の条件を定めます。

アジャイル開発でも対象と価値を見直し、優先順位と関係者の合意を管理します。全ての案件が同じ変更委員会を使う必要はありませんが、「変更を歓迎するので影響評価も合意も不要」という理解は適切ではありません。

代替案：追加だけでなく範囲と期日を組み合わせる

追加機能の見積りは設計2人日、実装3人日、試験2人日、教育1人日で合計8人日です。予定日までに既存作業を除いて使える余力は6人日とします。余力だけでは2人日足りず、しかも工数が収まっても依存関係や担当が合わなければ間に合いません。

次回へ延期する、期日を変更する、別の機能を後回しにするなどの案を比較します。既存の履歴出力機能4人日を次回へ移すなら、差引き追加4人日で工数上の余力へ収まります。ただし履歴出力を外してよいか、業務への影響と受入条件の変更も承認が必要です。

承認後は要件だけでなくWBS、見積り、日程、試験、運用資料、教育内容、契約上の対象を更新します。開発担当だけに伝えても、現場が古い手順で操作すれば合意と実態がずれます。最後に変更の完了と受入結果を記録します。

演習1：作業の範囲

条件：機能は完成したが、計画で約束した現場教育が未実施。

問い：プロジェクトの範囲を完了したといえるか。

解答例：いえない。約束した教育も必要な作業と成果物に含まれるため。

根拠と誤答の確認：製品の画面完成と、導入プロジェクトの完了を区別します。

演習2：WBSと順序

条件：WBSに実装と試験を同じ成果物の下へ置いた。

問い：上下関係だけで実行順序が決まるか。

解答例：決まらない。WBSは範囲の分解で、依存関係と日程は別に定める。

根拠と誤答の確認：階層図を工程の順序図として読みません。

演習3：小さい追加

条件：現場担当が承認前に小さい機能を何度も追加させている。

問い：どのような問題が起きるか。

解答例：対象が無管理に広がり、工数・試験・期日・合意にずれが生じる。

根拠と誤答の確認：一件の小ささだけで累積影響を無視しません。

演習4：余力の計算

条件：追加は8人日、余力6人日。既存機能4人日を次回へ移す案がある。

問い：差引き追加工数と、残る判断を答える。

解答例：差引き4人日。既存機能の延期の業務影響・日程・受入条件を確認し承認する。

根拠と誤答の確認：工数が収まることだけで対象の削除を勝手に決めません。

演習5：基準の更新

条件：進捗が遅れたので、元の日程を記録なく延ばして差異を消した。

問い：なぜ問題か。

解答例：合意済み基準との差異と変更理由が追えず、判断の根拠を失うため。

根拠と誤答の確認：予測の更新とベースラインの承認変更を分けます。

演習6：変更の通知

条件：自動発注追加は承認済みだが、購買担当と現場には伝わっていない。

問い：何をすべきか。

解答例：影響する手順・試験・教育・計画を更新し、関係者へ変更内容と実施条件を伝える。

根拠と誤答の確認：承認を取った事実だけでは、運用の整合は完成しません。

参照資料とこの記事の範囲

事例・図・演習は教材用に独自に作成しました。公式・教育機関の資料で仕組みを確認し、特定年度の問題本文を前提にせず学べる構成にしています。

NASA WBSガイダンス

NASA 要求変更の管理

NASA システムエンジニアリングと関係者

IPA APシラバス

関連テーマを続けて学ぶ

サービスデスク｜受付・分類・優先度・エスカレーションから復旧まで

記述式の設問と本文根拠の読み方