スコープ管理

変更要求へんこうようきゅう

チェンジリクエストスコープ変更変更管理プロジェクト管理仕様変更CCB

変更要求について教えて

簡単に言うとこんな感じ！

プロジェクトの途中で「やっぱりここ変えたい！」って思ったとき、口頭でなく正式な書類で申請する仕組みだよ。「言った・言わない」を防いで、コスト・スケジュールへの影響をみんなで確認してから変更するルールなんだ！

変更要求とは

変更要求（チェンジリクエスト、Change Request / CR） とは、プロジェクトの進行中に発生した仕様・スコープ・スケジュール・コストなどの変更を、正式な手続きを通じて申請・承認・追跡するための仕組みです。単なる「お願い」ではなく、影響範囲・費用・工期への影響を明確にしたうえで承認を得る、プロジェクト管理の重要プロセスです。

システム開発の現場では、要件定義後に「画面のデザインをもう少し変えたい」「機能を追加したい」という要望が頻繁に発生します。これらをすべて口頭や口約束で受け入れると、スコープクリープ（scope creep） と呼ばれる際限ない仕様拡大が起こり、納期遅延・予算超過の原因になります。変更要求はそれを防ぐ「安全弁」です。

発注者側（ビジネスパーソン）にとっても、変更要求は「追加でいくらかかるか・いつ完成するかを事前に把握できる」便利な仕組みです。変更を申し込んだら必ず影響試算が戻ってくるため、判断する材料が整った状態で意思決定できます。

変更要求の構成と流れ

変更要求は「申請 → 審査 → 承認/却下 → 実施 → 確認」という一連のフローで管理されます。

ステップ	担当	内容
① 変更要求の起票	発注者 / ユーザー	変更内容・理由・優先度を記載したCR票を作成
② 影響分析	ベンダー（開発側）	コスト・工期・品質への影響を試算して提示
③ 審査・承認	CCB（変更管理委員会）	変更の可否・優先度を決定
④ 実施・記録	開発チーム	承認された変更を計画に組み込み作業
⑤ 完了確認	発注者 / PM	変更が意図どおり反映されたかを確認

CCBって何？

CCB（Change Control Board、変更管理委員会） は、変更要求の可否を審査・承認する会議体です。プロジェクトマネージャー・発注者代表・技術責任者などで構成され、コスト・スケジュール・品質のバランスを見て判断します。小規模プロジェクトでは「PM単独」や「発注者との二者協議」が代わりになることもあります。

変更要求票に書くべき項目

【変更要求票（CR票）の基本フォーマット】

CR番号    : CR-2025-0042
申請日    : 2025-06-01
申請者    : ○○部 山田太郎
優先度    : 高 / 中 / 低

■ 変更内容
  （何をどう変えたいか、具体的に記載）

■ 変更理由・背景
  （なぜ変更が必要か）

■ 影響範囲（ベンダー記入）
  コスト影響  : +50万円
  工期影響    : +2週間
  品質リスク  : 低

■ 承認欄
  発注者責任者: ____________  承認日: ______
  PM         : ____________  承認日: ______

歴史と背景

1960〜70年代: 大規模な政府・防衛プロジェクトで「口頭変更による混乱」が多発。仕様書の変更を正式管理する必要性が認識される
1980年代: NASA・米国防総省などが 構成管理（Configuration Management） の一部として変更管理プロセスを体系化
1996年: PMI（米国プロジェクトマネジメント協会）が PMBOK第1版 を発行。変更管理を統合変更管理プロセスとして正式に定義
2000年代: アジャイル開発の普及により「変更を歓迎する」文化が台頭。ただしアジャイルでも バックログ管理・スプリントレビュー という形で変更の優先度付けと合意形成は維持されている
現在: クラウド・SaaSの普及により「継続的デリバリー」が一般化。変更要求も迅速化・軽量化が進むが、コスト・リスク管理の本質は変わらない

変更要求と関連する管理プロセス

変更要求は単独で機能するのではなく、プロジェクト管理のいくつかのプロセスと密接に連携しています。

変更要求 vs 口頭変更（やってはいけない例）

比較項目	変更要求（正式）	口頭・メール一言（NG）
記録	CR票として残る	残らない・紛失リスク
コスト影響	事前に試算・合意	後から請求トラブルに
工期影響	明確に合意	「聞いてない」が発生
承認者	明確（CCBなど）	誰が決めたか不明
追跡	番号管理で追える	埋もれてしまう

アジャイルにおける変更要求

アジャイル開発では「計画より変化への対応」を重視しますが、無秩序な変更を許容するわけではありません。プロダクトバックログ に変更要求を積み上げ、スプリントプランニング で優先度と工数を確認してから着手するという形で、実質的な変更管理が行われます。

規格・番号	内容
PMBOK（PMI）	プロジェクトマネジメント知識体系。「統合変更管理」プロセスとして変更要求を体系的に定義
ISO 21500	プロジェクトマネジメントの国際規格。変更管理を含む10の主題グループを規定
ITIL v4	ITサービス管理のベストプラクティス。「変更管理（Change Management）」プラクティスを定義