CCBとは「Change Control Board」の略称であり、日本語では「変更管理委員会」を意味します。CCBの運用は効率的な開発プロジェクトに重要です。この記事では、これからCCBを設置しようと考えている方向けに、CCBの概要や役割、設置するメリットを紹介します。また、CCBによる変更管理のプロセスや運用する際の注意点なども詳しく解説します。
CCB（変更管理委員会）とは
CCB（変更管理委員会）とは、プロジェクトの計画変更が発生した際に、その変更内容を精査し、承認または棄却を決定する組織です。
プロジェクトは通常、あらかじめ定めた進行計画に沿って進められます。どれほど事前に検討されたものでも、進行途中で計画とズレが生じてトラブルが発生するといったリスクをゼロにするのは困難です。プロジェクトの計画変更が想定される事象には、以下のような例が挙げられます。
- システム開発にかかるコスト（予算）削減
- 競合他社による新規のテクノロジの導入
- 開発初期段階のため、クライアント自身が求めているシステム要件を理解していない
プロジェクトが計画通りに進まない可能性がある場合、すぐに当初の計画から内容を見直し、変更を検討する必要があります。
このとき迅速な対応が必要であれば、個々のプロジェクトメンバーが判断して計画を変更してしまうかもしれません。しかし、現場レベルの担当者であってもメンバー自らで変更を行っては本来の目的から逸脱したり、目的の達成が困難になったりする恐れがあります。本来必要とされることよりも、クライアントからの要望を優先させてしまうこともあるでしょう。また、不都合な事実をもみ消してしまうことがあればプロジェクト全体の進行に深刻な影響を与えるリスクもあります。
そのため、変更がたとえ小さなものでも、何らかの変更が生じた際はCCBによる客観的な分析が必要となるのです。
ただし、CCBの性質上、迅速な機能変更には対応が難しいこともあります。CCBは近年主流になりつつあるアジャイル開発よりも、従来のウォーターフォール開発の欠点を補えます。
ウォーターフォール開発とは、プロジェクト開発の現場で長年用いられてきた手法です。手順を一つひとつ確認しながら工程を進めていくため、開発スケジュールの見通しを立てやすく、汎用性の高さから日本国内でも多くの開発現場で導入されています。開発を各工程に分けてクオリティ高く開発を進めていきますが、次のフェーズに進むと後戻りができないという特徴があります。そのため、仕様変更が必要になった場合に柔軟に対応できないというのが欠点です。
なお、アジャイル・ウォーターフォール開発、PMやPMOについては、以下の記事で詳しく解説しております。併せてご覧ください。
アジャイル開発とウォーターフォール開発の違いとは？失敗しない開発手法を決定するために、それぞれの特徴やメリットについて理解しよう
PMOとは？その意味と具体的な業務・役割、PMとの違いについて解説
ちなみに、CCBに近い言葉に「CAB（Change Advisory Board）」というものがあり、日本語で「変更諮問委員会」と呼ばれます。主にITサービスマネジメントの分野で組織されており、「何らかの変更を経て稼働しているサービス（運用）がどのような影響を受けるか」という視点から管理が行われます。
CCBの役割
前述したように、プロジェクトは計画通りに進むとは限りません。プロジェクトの進行中に変更が必要となるケースは多々あります。例えば、ソフトウェアのオプション購入や新規導入、ハードウェアの修理や追加購入といったシステム面での変更は日常的な事象です。また、プロジェクトメンバーや各役割の変更、業務プロセスの変更など、人事的な面についての変更もあるでしょう。
一口に変更といってもさまざまなケースがあります。細かい変更箇所全てをプロジェクトメンバーのみで議論するのは難しく、効率も良くありません。加えて、プロジェクトメンバーが客観的に判断できず、クライアントからの「変更してほしい」という意見を鵜吞みにしてしまう恐れもあります。
CCBの設置は、このような変更に対する業務を最小限にし、なおかつ客観的な目線で判断するためにとても重要なのです。CCBが存在することでエラーや失敗報告に関しても回収しやすい体制が構築され、プロジェクトをより成功に導きやすくなるでしょう。
CCBを設置するメリット
続いて、CCBを設置することによるメリットを見ていきましょう。CCBが設置されることで、プロジェクトの変更に必要な対応を効率化できます。また、第三者視点での審査が可能となるため、変更内容の正当性を客観的に判断でき、結果的にプロジェクトの成功率が高まります。
プロジェクトの変更に必要な対応を効率化できる
プロジェクトの計画に変更の必要が生じた際、CCBの客観的な視点による対応が可能となります。CCBは変更の妥当性はもちろん、類似する変更事例や変更に伴うプロジェクトへの影響などを検討します。客観的な視点を挟むため、変更した際の失敗防止に役立ちます。あらかじめ第三者機関にCCBを設置しておく場合、内容が複雑なことはCCBへ判断を任せられ、メンバーは本来のプロジェクト進行に注力できるのがメリットです。
変更内容の正当性を客観的に判断できる
クライアントやメンバー間の関係性によっては、プロジェクト変更の妥当性を客観的に判断することが難しい場合があります。CCBが設置されていると、スムーズにクライアントやプロジェクトメンバーから寄せられた提案をCCBへ伝達でき、客観的な判断を仰げます。CCBによる分析・承認の過程を挟むため、誤った判断のままプロジェクトが進行するのを防くことも可能です。
プロジェクトの成功率を高められる
プロジェクト計画の変更の際、クライアントからの複雑な要望が関係するケースは少なくありません。そのため、現場の限られたプロジェクトメンバーだけで変更の妥当性を判断するのは困難です。CCBが設置されていない場合、以下のようなリスクが想定されます。
- 企業が組織としてのマネジメント力や組織力を維持できない
- 柔軟な計画変更が行えず、変更に伴う対応への裁量も委譲されていない
- 対応に伴い、メンバーに過大な負担や周囲からの批判が寄せられる恐れがある
- プロジェクトが失敗するまで、報告が行われない
CCBの設置によって、変更に関する客観的な判断を任せられます。結果、業務効率性が保たれ、プロジェクトの成功率が高まるのです。
CCBによる変更管理のプロセス
CCBによって行われる変更管理は、通常以下のプロセスに沿って進めます。ここでは、変更管理における2つの流れを解説します。
変更提案を受理する
CCBがはじめに行うのは、変更提案の受理と内容の確認です。組織内にCCBがある場合、変更提案書が作成されていることが前提となります。記載される変更箇所には、次のようなものが挙げられます。
- 機能や技術面の変更
- プロジェクトスコープ（プロジェクトの明確な範囲、個々の作業、期日など）
- 新規ツールの導入
- 取引先やサプライヤーの変更
プロジェクトの変更といっても内容はさまざまです。取引先やサプライヤーが変更になる場合、別途見積書作成などが必要になります。
具体的には、変更の概要と必要性をまとめ、変更点を「変更提案書」として文書化していきます。完成した変更提案書をCCBに提出、これをCCBが受理して分析を進めていくという流れが通例です。
変更提案の内容を分析し可否を判断する
CCBは、提出された変更提案書を基に内容を分析・評価し、最終的な審議を経て速やかに提案者に回答します。
プロジェクトの変更が行われる場合、変更箇所は多岐にわたります。変更箇所ごとに担当者を割り振り、CCB内で分担して変更内容の範囲や計画、コストを分析します。この結果をCCB全体に伝え、担当者はプレゼンを行い変更の決議を行うのです。
変更が承認されたら変更箇所を文書化し、プロジェクトマネージャー主導のもとで変更を実装します。承認された変更要求に沿って文書化された内容通りにプロジェクトの変更を行いましょう。
そして、変更完了後にプロジェクトマネージャーはステータスをCCBへ報告し、報告を受けたCCBはレビュアー（査読者）を中心に処理に問題がないか確認していきます。変更が問題なく完了したことをレビュアーが確認次第、一連の変更管理プロセスが完了します。
ここまで解説した変更管理において、準備段階から完了までに必要とされる主な要件をまとめると以下の通りです。
|
変更管理プロセス |
必要とされる要件 |
|
準備段階 |
・変更管理方針と要求変更計画の策定 |
|
変更体制構築段階 |
・CCBの介入 |
|
実施段階 |
・CCBへの要求変更依頼 |
|
完了段階 |
・一連の要求変更の完了判断 |
CCBを運用する際の注意点
前述の通り、CCBの運用には客観的な視点が求められます。そのため、以下のような点に注意して運用していく必要があります。
プロジェクトマネージャーはCCBに参加しない
プロジェクトの評価や変更に関連した取り決めを検討するとなれば、プロジェクトマネージャー（PM）の意見も必要と考えるのは自然です。しかし、プロジェクトマネージャーはCCBの招集こそ行いますが、参加することは好ましくありません。
CCBに求められるのはあくまでも「客観的」であることです。そのため、顧客との接点もあるプロジェクトマネージャーがCCBにいると、判断が公平に行われなくなるリスクがあります。
CCBがプロジェクトチーム内に設けられるケースもありますが、できる限りプロジェクトに参加していないメンバーで構成しましょう。プロジェクトマネージャーに関しても、ビジネスと技術面どちらへも造詣のある人が適任です。
変更の申請は文書化するルールを設ける
変更申請と文書化は、セットであることが必須です。わざわざ文書化するのは手間だという意見もありますが、文書化には「変更履歴を残す」「複数人で共有しやすい」という目的があります。文書化する際は内容変更に要する時間やコスト、期待される効果や影響などを明記します。
完成した文章はCCBへ提出し、分析や評価が行われた後に組織内で共有されます。また、納期の変更や契約書の見直しなど、変更に外部の取引先も関係する場合もあります。対外的なトラブルを防止するためにも、CCBによるチェックは重要です。
まとめ
何らかのプロジェクトを進める際、当初の計画通りに進まないことやトラブルは少なからず発生するものです。なにか不都合が生じてから変更への対応を検討した場合、最終的にうまくいかないリスクが高くなるでしょう。
通常、トラブル対応には的確な状況把握やスピード感が求められます。プロジェクト変更を行う場合も、すぐに招集できるメンバー内のみで実効的な議論を行うのは非効率かつ建設的ではありません。
そこで、あらかじめCCBを導入しておくことで、トラブル発生時などの変更に関連する業務を最小限に抑えられます。CCB主導のもと、客観的な解決方法を速やかに打ち出すことで、プロジェクトの軌道修正が行えるためです。
なお、ソフトウェア開発におけるプロジェクト管理の強化ノウハウをまとめた資料もご用意しております。ぜひこちらもご覧ください。
