構成管理とは何？わかりやすく解説 Weblio辞書

ウィキペディア

索引トップ用語の索引ランキングカテゴリー

構成管理

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2020/01/01 01:14 UTC 版)

ナビゲーションに移動検索に移動

トップレベルの構成管理の活動モデル

はじめに

システムのライフサイクルに構成管理を適用するとき、その範囲・性能・機能・構成要素・物理的な属性の視認性と制御を提供する。構成管理はシステムが意図通りに機能することを確認し、計画したライフサイクルに対応すべく十分詳細に識別され文書化することがある。構成要素の変更、機能の改訂、性能・信頼性・保守性の改善、システムの寿命を延ばす、コスト削減、危険性や問題の低減、欠陥の修正など、役に立つシステムの変更やシステム情報の整然とした管理を容易にする。構成管理は相対的に低いコストで実施でき、多くのコスト削減を実現できる。人命に影響を与えるシステムでは、構成管理の欠如や実施がまずい場合、結果として人命が失われたり大きな事故を引き起こすなどの壊滅的結果を引き起こす可能性がある^[2]。

構成管理ではシステムの変更を効率的に制御するため、部品間、サブシステム間、システム間の機能的関係を強調する。それにより、変更案が逆効果を最小化するよう考慮しているかを体系的に検証可能となる。システムの変更は、一貫性を保証するよう標準化した体系的手法を使って提案し、評価し、実装する。変更案は予想されるシステム全体への影響について評価する。構成管理は変更を規定通りに行ったかを検証し、部品やシステムの文書が実際の構成を反映していることを確認する。完全性の高い構成管理では、部品毎、サブシステム毎、システム毎についての全システム情報が実体を反映するよう対策をとる^[6]。

構造化した構成管理では、文書（要求仕様、設計書、試験仕様、受納書など）が実際の設計を正確に表しかつ一貫していることを保証する。構成管理を実施しない場合、文書が存在しても実体と一貫していないことが多い^[要出典]。そのため、後に設計に変更を施す際、関係者が実体を反映させるべく何度も開発文書を改訂する必要が生じる。構成管理を行えば、そのようなリバースエンジニアリング的な無駄な作業を減らすことができる。

歴史

形式的管理手法としての構成管理は、アメリカ空軍 (USAF) がアメリカ国防総省 (DoD) のために1950年代に開発したもので、当初は物質的な材料についての技術的管理技法だった。その後様々な産業に広まっていった。DoDが1970年代に発行した「480シリーズ」と呼ばれるMIL規格（MIL-STD-480、MIL-STD-481）を策定していた1960年代末、構成管理が独立した技術的規範となっていった。1991年、480シリーズは MIL–STD–973 という1つの規格としてまとめ、さらに標準化団体が策定した一般の工業規格を取り入れて軍独自の規格の数を減らすため、 MIL–HDBK–61 へと改訂した^[7]。これが構成管理の国際標準 ANSI–EIA–649–1998 へと発展^[8]。2013年現在、広く採用されている構成管理のコンセプトとしては、システム工学 (SE)、Integrated Logistics Support (ILS)、能力成熟度モデル統合 (CMMI)、ISO 9000、PRINCE2プロジェクト管理方法論、COBIT、Information Technology Infrastructure Library (ITIL)、アプリケーション・ライフサイクル・マネジメントなどがある。構成管理を図書館の司書のような活動と捉え、変更を制御する側面を変革管理として独立して捉えることもある。ソフトウェアの構成管理では、ISO/IEC TR 15846:1998 Information technology -- Software life cycle processes -- Configuration Managementが標準技術文書(technical report)として1998年に発行している。しかし試用のち、2007年に廃止している。軍関連のソフトウェア開発部門での利用はあったが、他の分野では詳細すぎて仕立て(tailoring)の出発点としては重すぎるとの背景があった。

概要

構成管理は変更を体系的に扱うことで、システムの完全性を長期に渡って保つ。管理・変更案の評価・変更状態の追跡に必要な方針・手順・技法・ツールを与え、システムの変更に際してシステムの構成と対応文書を維持する。構成管理計画は開発と実装における技術的・管理的方向性を与え、複雑なシステムをうまく開発・保守するために必要とされる手順・機能・サービス・ツール・プロセス・資源を提供する。システム開発においては、検収・運用・保守を通して管理者が要件を追跡することを可能にする。要求仕様や設計に対して変更を加えることは必然的に発生し、その場合はシステムの状態の正確な記録を作成し、それを承認した上で文書化しなければならない。安全に関する理想的な構成管理プロセスはシステムのライフサイクル全体にわたって適用すものである。

ハードウェアとソフトウェアの構成要素についての構成管理プロセスは、MIL–HDBK–61A や ANSI/EIA-649 で確立された5つの規則で構成されている。これらの規則は、方針手順を励行することでベースラインを確立し、変更を管理するプロセスを標準化して実行するためのものである。

構成管理の計画と管理: 構成管理プログラムのガイドとなる正式な文書としては、人事関係、責任分担とリソース、訓練要件、（手順の定義やツールを含む）管理会議のガイドライン、ベースラインとなるプロセス、構成制御と構成現況記録、命名規則、監査とレビュー、下請け業者・供給業者への要件などがある。
構成識別 (Configuration Identification, CI): ベースラインの設定と保守からなり、システムやサブシステムのアーキテクチャ、部品群、任意の時点でどういう開発が必要かなどを定義する。これをベースラインとしてシステムへのいかなる変更も識別し、文書化し、設計から配備までを監視する。そうすることで構成現況記録 (CSA) のベースとなる現況の文書を徐々に確立していく。
構成制御: あらゆる変更要求・提案を評価し、採用・不採用を決定するプロセス。システムの設計・ハードウェア・ソフトウェア・文書の変更を制御する。
構成現況記録 (Configuration Status Accounting, CSA): 構成要素（ハードウェア、ソフトウェア、ファームウェアなど）について記録・報告し、設計・製造段階でベースラインから乖離した部分を全て記録・報告するプロセス。問題が発生したとき、ベースラインとなる構成と採用された変更のうちどれが関係するかを素早く特定できるようにする。
構成検証と監査: 個々のハードウェアやソフトウェアについて、要求仕様を満足しているか、標準規格に適合しているか、ベースラインに適合しているかといった観点でレビューを行う。構成監査では、システムおよびサブシステムをアーキテクチャ上の基準線に受け入れる前にそれらの構成文書が実際の機能や物理的特性と正しく対応しているかを検証する。