要件定義の曖昧さ排除とスコープクリープ防止の実務

システム開発プロジェクトが失敗する最大の要因として常にトップに挙げられるのが、「要件定義の曖昧さ」と、プロジェクト進行中に際限なく要求が膨張する「スコープクリープ（Scope Creep）」です。

高度試験の午後Ⅰ・科目Bでは、「業務部門の要望を安易に受け入れて炎上したシナリオ」や「変更管理プロセスの形骸化によってQCDが崩壊した事例」が頻繁に出題されます。PMとしてスコープのベースラインをどのように死守し、追加要求に対してどう優先順位付けと合意形成を行うべきか、その実務プロトコルを学びます。

1. スコープクリープの発生メカニズムと典型的な兆候

スコープクリープとは、正式な変更管理手続きを経ずに、プロジェクトのスコープ（作業範囲・機能範囲）がなし崩し的に拡大していく現象を指します。

2. スコープ管理を担保する4大マネジメントツール

1. 【WBS（Work Breakdown Structure）と辞書】：成果物ベースで最下層のワークパッケージまで細分化し、各作業の「受入基準（何をもって完了とするか）」を辞書として文書化する。

2. 【要件トレーサビリティマトリクス（RTM）】：ビジネス目標、業務要件、機能要件、設計書、テストケースを1対1で対応付け、不要な要件の混入や要件の抜け漏れを機械的に検知する。

3. 【変更管理委員会（CCB：Change Control Board）】：変更要求（Change Request）が発生した際、影響度（工数・スケジュール・コスト・品質）を定量試算し、採否を正式決定する最高機関。

4. 【フェーズ分割・段階的リリース】：納期固定（ハードマイルストーン）の場合、要件にMoSCoW分析（Must/Should/Could/Won't）を適用し、必須外要件を「フェーズ2（次期開発）」に切り離す。

3. 【実戦記述演習 問1】曖昧要件の受入判定におけるトラブル防止

【シナリオ背景】製造業C社では、取引先からの発注データを受信する「Web受発注ポータル」の再構築プロジェクトを推進している。要件定義工程において、C社の営業部門から「取引先が使いやすいよう、過去の注文履歴から類似商品をワンクリックで一括再発注できる機能がほしい」という強い要望が出された。プロジェクトチームは要件定義書に「注文履歴からの簡易再発注機能」と記載し、機能の概要のみを明記して基本設計工程へ進んだ。しかし、受入テスト工程において、営業部門から「過去注文時に適用された特別値引き率が自動再計算されず、現行価格で計算されてしまう。これでは取引先に使わせられないため不合格である」との指摘を受けた。開発チームは「過去の値引きルールの自動引き継ぎは要件定義書のスコープに含まれておらず、仕様変更である」と主張し、双方の意見が真っ向から対立した。

設問1：要件定義工程において、このような受入基準を巡る認識の齟齬を未然に防止するために、PMが要件定義書に明記させておくべきであった事項を、業務ロジックの観点から35字以内で述べよ。

【模範解答】

再発注時における値引き率等の価格計算ルールと適用条件の受入基準。（33字）

解説と採点基準（配点：10点）

• 出題意図：機能の存在だけでなく、「計算ロジック」「例外ケース」「合否判定基準」を要件定義段階で具体化することの重要性を問う。

• 加点キーワード：『価格計算（値引き・単価）ルール/ロジック』（4点）、『適用条件（例外処理）』（3点）、『受入基準（判定基準）の明記』（3点）。

• 減点対象：「営業部門との定期的な打ち合わせ」（具体性がなく、要件定義書に何を明記するかの答えになっていないため0点）。

4. 【実戦記述演習 問2】変更要求発生時のCCBにおけるPMの対応

【シナリオ追加背景】対立の結果、経営層の裁定により「特別値引きの自動再計算機能」を追加開発することになった。しかし、本機能の追加には詳細設計の修正と単体・結合テストの追加が必要であり、開発工数として1.5人月、期間として2週間の追加が見込まれる。現在の本番稼働日は、業界の法改正対応に合わせた「絶対厳守の必達納期」であり、全体のスケジュール延長は一切認められない。PMは変更管理委員会（CCB）を開催し、この変更要求を本番稼働に間に合わせるためのトレードオフ案を審議することにした。

設問2：必達納期を厳守しつつ本変更要求を取り込むために、PMがCCBにおいて業務部門および経営層に提案すべき現実的な対策を、スコープ調整の観点から40字以内で述べよ。

【模範解答】

必須機能でない優先度の低い既存要件を抽出し、次期フェーズへ延期する提案。（36字）

解説と採点基準（配点：10点）

• 出題意図：納期とコストの制約（トレードオフ）の中で、スコープのデスコープ（優先順位に基づくフェーズ分割）を提案・合意できるマネジメント能力を評価する。

• 加点キーワード：『優先度の低い機能（非必須機能）の抽出』（4点）、『次期フェーズ（次回リリース）への延期・切り戻し』（4点）、『スコープのトレードオフ（代替除外）』（2点）。

• 減点対象：「要員を追加投入して残業でカバーする」（クラッシングによる品質低下やブルックスの法則を無視した悪手とみなされ減点、最大3点止まり）。

5. まとめ：スコープ防御のための実務チェックリスト

• □ 要件定義書に「等」「別途協議」「柔軟に対応」などの曖昧ワードが残っていないか？

• □ 変更要求（CR）はすべて書面（チケット）化され、影響度分析（工数・納期・費用）が添付されているか？

• □ CCBの議事録に、承認された理由および「見送られた要件の次期扱い」が記録されているか？

• □ 顧客責任者とPMの双方が、スコープバウンダリ（何をやらないか：Out of Scope）に合意署名しているか？