【目次】
・CCBとは何か
・CCBを設置する目的とメリット
・CCBメンバーと役割
・CCB運用プロセスの全体像
・CCB会議運営のポイント
・CCB運用で使うドキュメントとツール
・よくある失敗パターンと対策
・まとめ
CCBとは何か
まずは「CCBってそもそも何？」というところから整理します。
CCB（Change Control Board）とは、プロジェクトに対する「変更」を審議し、
- 実施するか／しないか
- いつ、どのように実施するか
を決定するための公式な意思決定の場・組織です。
ここでいう「変更」とは、例えば次のようなものです。
- 要件の追加・削除・変更
- 画面仕様・帳票仕様の変更
- 開発スコープの増減
- 品質基準やテスト項目の見直し
- 納期や予算に影響する調整 など
ポイントは、
「なんとなく、口頭で合意したから変更する」
ではなく、
「CCBで影響を評価し、合意のうえで変更する」
という管理の仕組みを作ることです。
これにより、
- 後から「そんな話は聞いてない」「誰が決めたの？」というトラブルを防ぐ
- スコープや工数・納期の影響をきちんと把握できる
- 顧客・自社双方が納得感のある意思決定をしやすくなる
といった効果が期待できます。
CCBを設置する目的とメリット
CCBを設置する主な目的は、次の3つです。
変更管理を「見える化」する
- 誰が、どんな変更を提案したか
- どのような影響があるか（スコープ・工数・コスト・納期・品質など）
- その結果、どう決定されたか
を記録・共有することで、プロジェクト全体が同じ前提で動ける状態を作ります。
感情ではなく「事実ベース」で判断する
現場では、「お客様が困っているから」「現場の人が大変そうだから」という気持ちだけで変更を受けてしまうケースがよくあります。しかし、その結果として
- スケジュールが破綻して炎上
- メンバーの残業が常態化
- 他の重要な作業が犠牲になる
といった問題が起きがちです。
CCBでは、感情ではなく影響分析の結果をもとに、
「この変更を受けるなら、納期＋2週間と追加費用XX万円が必要」
といった形で条件付きの判断ができるようになります。
責任と決定権を明確にする
CCBで正式に決定していれば、
- 「誰が決めたのか」
- 「そのときの前提は何だったのか」
が明確になり、後から責任のなすり付け合いになりにくくなります。
特に、
- 顧客側の意思決定者（プロジェクトオーナーなど）
- 自社側の責任者（PM・部門長など）
が参加しているCCBで決定されたことは、組織としての合意として扱いやすくなります。
CCBメンバーと役割
CCBを機能させるには、「誰が参加するか」「どんな役割を担うか」が重要です。
典型的なメンバー構成
例として、システム開発プロジェクトのCCBメンバーは次のようなイメージです。
- CCB議長（チェア）
- 多くの場合、プロジェクトマネージャ（PM）
- 会議の進行、議題の整理、決定内容の確認を行う
- 顧客側責任者（プロジェクトオーナー、業務責任者など）
- 変更の必要性、業務への影響、優先度を説明
- 予算・スケジュールに関する意思決定に関与
- 開発側リーダー（システム側リーダー、設計リーダーなど）
- 変更の技術的な影響を評価
- 既存設計やテストへの影響を説明
- 品質担当／PMO
- プロセス遵守・記録・エビデンスの管理
- 変更が品質に与える影響の観点を補う
- 必要に応じて
- インフラ担当、セキュリティ担当、運用担当 など
各メンバーの基本的な役割
- PM（議長）
- 議題の優先度をつける
- 必要な事前資料が揃っているか確認する
- 会議中に結論が出ない場合は、宿題事項や次回方針を明確にする
- 顧客側責任者
- 「なぜその変更が必要か」「優先度はどの程度か」を説明
- 代替案への柔軟な検討（全部を一度にやるのか、段階的にやるのかなど）
- 技術リーダー
- 影響範囲（機能、データ、インターフェース、性能、保守性など）を説明
- 実現可能な案（最小限の改修で実現できる方法など）を提案
- 品質／PMO
- 変更管理ルールの適用確認
- 記録の漏れ・抜けがないようにチェック
CCB運用プロセスの全体像
ここからは、CCB運用の典型的な流れをステップで説明します。
- 変更要求の受付
- 事前整理・影響分析
- CCBでの審議・決定
- 決定内容の通知・計画反映
- 実施・検証
- クローズ・記録保存
変更要求の受付
まずは「変更要求」を受け付ける仕組みを決めます。
- 変更要求票（テンプレート）を用意する
- 変更の概要
- 背景・目的
- 希望時期
- 想定されるメリット／リスク
- 依頼者情報（所属・氏名・連絡先）
- 受付窓口を一本化する
- 「PMまたはPMO宛てのメールのみ」
- 「チケット管理ツール（JIRA、Redmineなど）」
- 「グループウェアの申請フォーム」 など
ここがバラバラだと、
「あの口頭依頼はどこへ行った？」
「メールで聞いてたけど、変更要求票が出ていない」
といった混乱が発生しやすくなります。
事前整理・影響分析
受け付けた変更要求を、そのままCCBに持ち込むのではなく、PMや技術リーダーが事前に整理し、影響分析のたたき台を作ります。
- 対象機能・対象システム
- 既存設計への影響（画面・バッチ・インターフェースなど）
- 開発工数の概算
- テストへの影響（追加テスト・再テストの有無）
- 納期への影響（遅延、追加リリースの必要性）
- コスト・契約影響（追加費用の有無、契約変更の必要性）
この段階で「実現が極めて難しい」「明らかに別プロジェクトレベル」と判断できる場合は、
- CCBではなく別途「案件として切り出す」
- プロジェクト範囲外として整理する
といった選択肢も検討します。
CCBでの審議・決定
CCBミーティングでは、次の流れを意識するとスムーズです。
- 議題ごとに
- 変更要求内容の説明（依頼元 or PM）
- 影響分析結果の説明（技術リーダー）
- 質疑応答
- 実施方針・条件の検討
- いつ対応するか（今リリース／次リリース／後回し）
- どこまで対応するか（要望の100％か、簡易版か）
- 結論の整理
- 承認／保留／却下
- 承認の場合の条件（納期変更、費用、優先度）
重要なのは、「承認」だけでなく「保留」「却下」も正式な決定として扱うことです。
保留の場合は、
- 追加で調査・検討が必要な内容
- 調査の担当者と期限
を明確にし、次回CCBの議題とします。
決定内容の通知・計画反映
CCBで決まった内容は、必ず以下に反映します。
- WBS／スケジュール
- 要件定義書・設計書
- 見積・予算管理表
- テスト計画書 など
また、関係者への通知も重要です。
- プロジェクトメンバー向け：
- 「どのタスクが増えたか」「優先度がどう変わったか」
- 顧客側メンバー向け：
- 「いつ反映されるか」「何が変わるか」「費用や納期の影響」
通知は、メール・議事録・チケットなど、後から追跡できる形で残すことがポイントです。
実施・検証〜クローズ
決定された変更は、通常の開発プロセス（設計・実装・テスト）に乗せて実施します。
実施後は、
- 想定通りの結果になっているか
- 副作用が出ていないか
を確認し、問題がなければ変更要求を「クローズ」します。
ツール上でステータス管理すると、
- 受付中 → 影響分析中 → CCB審議中 → 実施中 → クローズ
といった形で進捗を追えるようになります。
CCB会議運営のポイント
CCBを「形だけの会議」にしないために、運営面のコツを整理します。
事前アジェンダの共有
- 議題リスト（変更要求ID・概要）
- 関連資料（影響分析の結果など）
を前日までに共有しておくと、当日の審議がスムーズになります。
「その場で初めて内容を見る」状態だと、議論が深まらず、保留ばかりが増えてしまいます。
決定基準をあらかじめ決めておく
例えば、次のような基準をプロジェクト内で共有しておきます。
- 安全性・法令遵守に関わる変更は優先度を最優先で高くする
- 必須業務（コア業務）への影響が大きいものは優先度を上げる
- 利便性向上のみの変更は、原則として次フェーズでまとめて検討する など
このような基準があると、
「なんとなく押しの強い人の要望が通る」
といった不公平感を減らせます。
CCB運用で使うドキュメントとツール
CCBを実務で回すために、最低限そろえておきたいドキュメント・ツールを整理します。
変更要求票（申請書）
必須項目の例：
- 変更要求ID
- 依頼日・依頼者
- 変更概要
- 背景・目的（なぜ必要か）
- 希望時期・優先度（依頼者視点）
- 期待される効果
- 想定されるリスク／懸念点（あれば）
影響分析シート
技術側が入力することを想定した項目です。
- 対象機能・モジュール
- 開発への影響（工数、担当者、期間）
- テストへの影響
- リリース計画への影響
- コスト・契約への影響
- リスク・制約事項
変更要求票とセットで扱うことで、CCBメンバーが判断しやすくなります。
変更管理台帳
すべての変更要求を一元管理する一覧です。
- ID、概要、依頼者
- ステータス（受付中／審議中／承認／却下／クローズなど）
- 重要度／優先度
- CCB審議日と決定内容
- 実施結果・備考
Excelでも、チケットツールでも構いません。
ポイントは「プロジェクト内の誰もが、変更の状況を一目で把握できる状態」にすることです。
仕様変更管理表のサンプルはこちらからダウンロードできます。
よくある失敗パターンと対策
最後に、現場でよく見かける失敗例と、その対策を整理します。
口頭の依頼がそのまま作業になってしまう
失敗例
- 上司や顧客からの「ついでにこれもやって」が、変更要求票なしで作業化
- 後から「そんなに大変だとは思っていなかった」と言われてしまう
対策
- 「口頭依頼禁止」ではなく、
- 「まずは変更要求票に起こす」
- 「急ぎであれば、簡易版の記入でも良い」
という運用ルールを徹底する。
- PMが率先して「では変更要求票に起こしてCCBにかけましょう」と口に出して運用する。
CCBが単なる「報告会」になっている
失敗例
- すでに決まった内容の報告だけをする場になっている
- 誰も反対しない「追認会議」と化している
対策
- 「CCBで合意してから実施する」流れに変える
- 少なくとも、納期・コストに影響する変更は事前にCCBで審議するルールを定める
記録が残っておらず、後から揉める
失敗例
- メールや口頭だけで決めてしまい、後から「言った・言わない」の争いに
- 過去にどのような判断をしたか参照できない
対策
- CCBごとに議事録を作成し、決定内容を必ず残す
- 変更管理台帳と紐付けて管理（議事録番号やURLを記載）
影響分析が甘く、想定外の手戻りが多発
失敗例
- 画面だけのつもりが、バッチや帳票にも影響していた
- テストケースの更新漏れで不具合が多発
対策
- 影響分析の観点チェックリストを用意する
- 画面／バッチ／インターフェース／DB／性能／セキュリティ／運用・監視 など
- 重要な変更は、レビュー（技術リーダー同士のクロスチェック）を実施する
まとめ
CCB（Change Control Board）は、単なる「会議」や「書類仕事」ではなく、
プロジェクトを守るための変更管理の仕組みです。
- 変更要求を一元的に受け付け
- 影響分析を行い
- 関係者で議論し、合意のうえで決定し
- 計画・ドキュメントに反映し
- 記録として残す
という一連の流れを整えることで、
- スコープの膨張による炎上を防ぐ
- 「誰が何を決めたのか」を明確にする
- 顧客と開発側の納得感のある関係を作る
ことができます。
