プロジェクトマネジメントにおける変更管理とは?

当ページには広告が含まれています。

こんにちは、DXCEL WAVEの運営者(@dxcelwave)です!

こんな方におすすめ!
  • プロジェクトマネジメントにおける「変更管理」の基礎について詳しく学びたい!
目次

変更管理とは?

変更管理とは、プロジェクトで定めたスコープに対して、そのスコープ外となる変更要求を受け付けた場合のマネジメントプロセスを指します。

変更はプロジェクトに関係するステークホルダーであれば誰でも要求することができます。

【参考】変更管理とコンフィギュレーションマネジメントの違い

変更管理と似た概念として「コンフィギュレーション・マネジメント」があります。この2つの概念については違いを理解が必要になります。

目的の違い

変更管理システムやプロジェクトにおける変更を計画的に管理し、変更がシステムに及ぼす影響を最小限に抑えること。変更要求が発生した際、それが適切に評価、承認、実施されるようにする。
コンフィギュレーション・マネジメントシステムのコンフィギュレーション(構成)を特定し、管理し、維持すること。これには、システムの各構成要素(ハードウェア、ソフトウェア、ドキュメントなど)のバージョン管理やトラッキングが含まれる。

領域の違い

プロジェクト領域の特徴は、「変更管理プロセス」を必要とする文書に限り取り扱うことです。

プロダクト領域の特徴の1つにバージョン管理があります。例えば、V1.0, V1.1のような表現の決まりや変更ルールを定義して管理します。

コンフィギュレーション・マネジメントは、通常、プロジェクト毎ではなく、組織の定常業務として実施されている活動であるため、プロジェクトとの棲み分けが必要になります。

上図の重複領域の役割は、変更管理とコンフィギュレーション・マネジメントどちらの責務とするか話し合いで決める必要があります。

プロジェクトの進め方別の変更管理プロセス

変更管理は、プロジェクトの進め方であるウォーターフォール型(予測型)とアジャイル型(適応型)によって大きくプロセスが変わってきます。それぞれのプロセスの違いについて確認していきましょう。

ウォーターフォール型での変更管理

ウォーターフォール型を採用した場合、変更管理プロセスは、変更およびその影響を最小限に抑えるよう堅実に進めていくのがポイントになります。

いわゆる「スコープ・クリープ」を防止するために取り組んでいくことが特徴的です。

変更への取り組み方やコントロール方法を事前に定義し、変更マネジメント計画書を作成します。その上で、変更マネジメント計画書に準拠する形式でプロジェクトを進めていくのです。

変更マネジメント計画書

変更マネジメント計画書には次のような内容が記述されています。

  • 変更管理のプロセス・フロー
  • 変更要求が提示された際の役割・責任・体制・連絡方法
    • 変更管理委員会
    • コーディネーター
    • プロジェクト・マネージャー
    • その他プロジェクト関係者
  • 変更ログ
    • 変更の追跡・コントロール方法
    • 承認のレベル

アジャイル型での変更管理

アジャイル型の場合、変更を積極的に受け入れて対処するという思想で変更管理プロセスが進んでいきます。

【参考】スクラム概要

例えばスクラムではまず、顧客とプロダクト・オーナーが「ユーザーストーリー」を描き、それらに優先順位を付与した上で積み上げ、プロダクトバックログを構成します。次に、開発チームがスプリント計画において、プロダクトバックログから優先順位の高いユーザーストーリーを複数選び出し、スプリントバックログを構成します。そして、スプリントバックログ内のユーザーストーリーを開発することを目的とし、スプリントが展開されます。スプリントの最後には、プロダクトオーナーや顧客に対して開発物のデモを行うとともにフィードバック・承認を受けるスプリントレビューを実施します。最終的にスプリント全体を通じて振り返りを行うレトロスペクティブを実施するという流れです。

変更管理のポイント

上記のようなスクラムの流れに対して、変更管理は次のように対応されます。

  1. 変更対象のユーザーストーリーが「プロダクトバックログ」内にある場合
    • 変更対象のユーザーストーリーを直接変更
    • プロダクトオーナーはプロダクトバックログ内の再優先順位付けを実施
  2. 変更対象のユーザーストーリーがスプリント期間内に開発中の場合
    • 変更対象を新規のユーザーストーリーとしてプロダクトバックログに追加
    • プロダクトオーナーはプロダクトバックログ内の再優先順位付けを実施
    • 開発中のユーザーストーリーが変更対象であっても現在のスプリント中には変更せず、原則一旦開発を完了させる。ただし、その変更が非常に重要と判断された場合、開発を止めて変更作業を実施。この判断はプロダクト・オーナーを中心にチーム全体で行う。
  3. 変更対象のユーザーストーリーがスプリント期間中に既に開発済みの場合
    • 変更対象を新規のユーザーストーリーとしてプロダクトバックログに追加
    • プロダクトオーナーはプロダクトバックログ内の再優先順位付けを実施
    • 開発チームはプロダクトバックログ内の優先順位に従い、次のスプリントを計画

最後に

この記事が気に入ったら
フォローしてね!

本記事をシェア!
目次