2.4構成管理

「この変更を加えたら、どのサービスに影響が及ぶのか」——サービスマネージャがこの問いに正確に答えられるかどうかは、サービスを構成する要素とその関係が正しく記録されているかにかかっています。構成管理は、サービスを構成するCI（構成品目）とその相互関係をCMDB（構成管理データベース）で管理し、変更管理やリリース管理を下支えするプロセスです。この節では、CIとCMDBの役割、他プロセスとの連携、そして混同されやすいIT資産管理との違いを、実務判断の観点から学びます。

2.4.1CIとCMDB

• CI（構成品目／Configuration Item）＝サービスを構成し、管理の対象となる要素。ハードウェア・ソフトウェア・ネットワーク機器だけでなく、文書・SLA・手順といった論理的な要素もCIになり得る。各CIは属性（バージョン・状態・所有者など）と、他のCIとの関係（依存・構成）を持つ。
• CMDB（構成管理データベース）＝CIとその相互関係を記録・維持するデータベース。CMDBが正確であれば、「あるサーバを変更するとどのサービス・業務に影響するか」という影響分析が可能になる。CMDBの価値は正確性にあり、実態と乖離した（更新されていない）CMDBはむしろ誤った影響分析を招く。

2.4.2変更管理・リリース管理との連携とIT資産管理との違い

• 変更管理・リリース管理との連携＝変更を評価する際、CMDBの関係情報でCIへの影響範囲を分析し（影響分析）、変更やリリースが実施されたらCMDBのCI情報（バージョン・状態など）を更新して実態に合わせる。構成管理は変更管理・リリース管理と双方向に連携し、CMDBの正確性はこの連携によって保たれる。
• IT資産管理との違い＝IT資産管理は主に資産の保有・数量・ライセンス・コスト・ライフサイクル（調達〜廃棄）の把握が目的。構成管理はサービス提供に必要なCIと、その相互関係の管理が目的で、関係性（依存構成）と影響分析を重視する点が異なる。同じ機器を扱っても「いくつ持っているか（資産）」と「何にどう依存しているか（構成）」で関心が異なる。

あるサービスマネージャが、共有データベースサーバのOSに重要なセキュリティパッチを適用する変更を評価しています。このサーバは複数の業務サービスから利用されている可能性があり、パッチ適用に伴う再起動がどのサービスに影響するかを正確に把握しなければ、SLAで約束した可用性を意図せず損なう恐れがあります。ここで頼るのがCMDBです。CMDBに各CI（このDBサーバ、そこで動くDBインスタンス、そのDBに依存する業務アプリケーション、それらが提供する業務サービス）と相互の依存関係が正確に記録されていれば、「このサーバの再起動が、どの業務サービスの停止につながるか」という影響分析を確実に行え、影響を受けるサービスの利用部門への事前連絡や、影響の小さい時間帯への実施計画、必要な立会い体制の判断が可能になります。逆に、過去の変更がCMDBに反映されておらず実態と乖離していると、依存関係の見落としから「影響しないはずのサービスが止まる」という事故につながります。だからこそ、この変更を実施したらCMDBのCI情報（OSのパッチレベル・バージョン・状態）を確実に更新し、構成管理を変更管理・リリース管理と連携させてCMDBの正確性を維持することが不可欠です。なお、このとき「そのサーバを資産として何台保有し、ライセンスをいくつ持っているか」を答えるのはIT資産管理の関心であり、今回必要な「そのサーバが何に依存され、変更が何に波及するか」という関係性・影響分析は構成管理の関心です。両者は対象機器が重なっても目的が異なるため、影響分析の局面で資産台帳だけを見ても必要な依存関係は得られません。このように、構成管理の価値は「CMDBに正確なCIと関係を保ち、変更の影響分析を可能にする」ことにあり、その正確性は変更・リリースのたびの更新という連携によって支えられます。

2.4.3この節のまとめ

• CI（構成品目）はサービスを構成する管理対象要素で、CMDBにCIと相互関係を記録し影響分析を支える
• 構成管理は変更管理・リリース管理と連携し、変更・リリースのたびに更新してCMDBの正確性を保つ
• 構成管理（関係性・影響分析が主眼）は、保有・ライセンス・コスト把握が主眼のIT資産管理とは目的が異なる