■PM Tools A to Z_No.23
コンフィギュレーション・マネジメント(1)
今日から2回にわたってコンフィギュレーション・マネジメント（Configuration Management）について説明します。
PMBOKガイドでは、コンフィギュレーション・マネジメントは、統合変更管理プロセスのツールと技法の一つとして挙げられています。
その説明を要約すると次のようになります。
| ・ ・ |
変更管理システムの一構成要素であり、プロジェクトの成果物の記述が正しくかつ完全であることを確保するために用いられる。 技術面、事務管理面の指示と監視を行うための文書化された手順・・・[※] ・対象物やシステムの機能・物理特性を明確にして文書化する。 ・機能・物理特性に対する変更をコントロールし、変更実施状況を記録・報告する。 ・対象物やシステムを監視し、要求事項への適合を検証する。 |
◆PMBOKガイド第3版（2004年発行）での説明：
（コンフィギュレーション・マネジメント・システムの説明になっている。）
| ・ ・ |
変更管理システムを包含し、変更提案の提出、変更提案のレビューや承認を行う追跡システム、変更を認可する承認レベルの規定、承認済み変更を確定する方法の提供等のプロセスを含む。 上記2000年版[※]の記述とほぼ同様 |
このようにコンフィギュレーション・マネジメントは、PMBOK第3版ではコンフィギュレーション・マネジメント・システムに格上げされ、変更管理システムとの包含関係が逆転しています。
また、SEI（Software Engineering Institute）が定義するCMM（Software Capability Maturity Model）では、コンフィギュレーション・マネジメントを成熟度レベル2におけるキー・プロセス・エリアの一つに設定しています。その日本語版では、コンフィギュレーション・マネジメントを「構成管理」と訳しています。
◆CMMにおける説明（部分）：| ・ ・ |
ソフトウェア構成管理の目的は、プロジェクトのソフトウェア・ライフサイクルの全般にわたって、ソフトウェア・プロジェクトの成果物の一貫性を確立し維持すること。 前記目的達成のために以下の活動が実践されること。 ・所定の時間におけるソフトウェア構成（ソフトウェア作業成果物）を特定する。 ・ソフトウェア構成の変更を系統的に制御する。 ・ソフトウェア構成の一貫性と追跡可能性を維持する。 |
これらPMBOKやCMMにおけるコンフィギュレーション・マネジメントの説明では、中々そのイメージがつかめない方もいるのではないでしょうか。
ところで、特にIT系の企業でISO9001などの品質マネジメントシステムの構築や運用、及びその下でプロジェクト活動を行っている方は、コンフィギュレーション・マネジメントよりも「構成管理」の表記に馴染んでいると思います。
これは、ISO9000-3:1991「品質管理及び品質保証の規格−第3部：ISO9001のソフトウェアの開発、供給及び保守に適用するための指針」の日本語版で、Configuration Managementを構成管理としていることなどから来ているのでしょう。
しかし、業界によっては形態管理などの表記を使ったりしているので、統一された日本語訳がなく、PMBOKガイド日本語版ではカナ文字表記を採用したものと推測しています。
それではここで、ソフトウェア開発などIT系プロジェクトにおけるコンフィギュレーション・マネジメントを具体的にイメージするために、その表記を「構成管理」として、それについて説明します。
始めにISO9000-3における構成管理の説明を一部引用します。特にIT系の人には分かりやすい内容で、構成管理のイメージがはっきりしてきます。
◆ISO9000-3における構成管理の説明（部分）：| ・ ・ |
構成管理は各ソフトウェア・アイテムの正式のバージョンを識別し、管理し、追跡する機構を提供する。多くの場合、使用中の旧バージョンも維持し、管理する。 構成管理システムは、 a）各ソフトウェア・アイテムの正式バージョンを一意に識別する。 b）製品全体の特定のバージョンを構成する個々のソフトウェア・アイテムのバージョンを識別する。 c）開発中又は引渡され設置されたソフトウェア製品の内部の構成を識別する。 d）二人以上の人によってあるソフトウェア・アイテムが同時に更新される事を管理する。 e）要求に応じて、一つ以上の場所にある複数の製品の更新について調整を行う。 f）個々の変更要求について、その要請から終了までの識別と追跡を行う。 |
| ここでいうソフトウェア・アイテムとは、「ソフトウェア開発の中間段階、又は最終段階における、それだけでまとまった、ソフトウェア製品（使用者に納入されるコンピュータ・プログラム、手順、関連する文書及びデータの完全な一組）を構成する部分」のことです。 |
構成管理の基本的な考え方を図１により説明します。
図１は、ドキュメント、SWソース１、SWソース２の３つのソフトウェア・アイテムにより構成管理が行われる簡単な例を示しています。
プロジェクトの進行中、それぞれのソフトウェア・アイテムは改訂・改版が行われます。そして、プロジェクトの各フェーズの終了時やマイルストーンで、ベースレベル（＊）が設定されます。
| （＊） | ベースレベルとは、開発中のソフトウェア・アイテム相互の関連、またはソフトウェア製品の特定のバージョンを構成するソフトウェア・アイテム相互の関連の記録をいいます。ベースレベルは、プロジェクトのフェーズやマイルストーンに対応して、成果物の構成を管理するために設定されます。 |
このベースレベルを管理することが構成管理を行うということです。
図１では、３つのベースレベルについて、それぞれドキュメントとそれに対応するソフトウェア・ソースコード（２種類）の関連が分かります。
計画にしたがって構成管理を適切に行うこと、このことがソフトウェア・アイテムや完成製品の品質確保につながります。
ベースレベル１の構成要素：ドキュメント(Rev.1)，ソース1(Rev.2)，ソース2(Rev.1)
ベースレベル２の構成要素：ドキュメント(Rev.2)，ソース1(Rev.3)，ソース2(Rev.3)
ベースレベル３の構成要素：ドキュメント(Rev.2)，ソース1(Rev.4)，ソース2(Rev.5)
次回は、構成管理責任者の任命から始まる構成管理活動について概観します。
| 参考文献： |
|
※PMBOKはProject Management Instituteの米国及びその他の国における登録商標です。