LASSIC Media らしくメディア

「このサーバーを止めると、どの業務に影響が出るのか」——障害対応や変更作業の場面で、この問いに即答できず手が止まった経験はないでしょうか。システムが増え、担当者が入れ替わっていくと、何がどこにつながっているのかは、しだいに誰の頭の中にも収まらなくなります。その全体像を台帳として持ち、対応の土台にしようという考え方が、CMDB（構成管理データベース）です。

CMDBは、ITILなどのフレームワークで語られる構成管理の中心にある仕組みです。ただ、言葉だけが先行し、「IT資産管理と何が違うのか」「作ったものの使われずに終わった」という声も少なくありません。本記事では、システムを運用する情報システム部門の担当者に向けて、CMDBとは何か、近い取り組みとの違い、つまずきやすい点、そして無理なく続けるための運用と外注の勘所を整理します。

CMDBとは——IT資産管理との違い

CMDB（Configuration Management Database／構成管理データベース）とは、システムを構成するさまざまな要素と、それらのつながりを一元的に記録・管理する台帳を指します。ここで管理される一つひとつの要素を、構成アイテム（CI：Configuration Item）と呼びます。サーバーやネットワーク機器といったハードウェアだけでなく、その上で動くソフトウェアやサービス、保守契約や担当者まで、対象は幅広く及ぶのが特徴です。CMDBの核心は、これらを個別に並べるだけでなく、「どのCIが、どのCIとつながっているか」という依存関係まで持つ点にあります。

よく似た取り組みにIT資産管理があります。両者は重なる部分もありますが、狙いが異なります。IT資産管理は、「何を、いくつ持っているか」を把握することに重きを置き、調達やコスト、ライセンス、機器の寿命といった管理が中心です。いわば、保有物の台帳です。これに対してCMDBは、「何が何につながっているか」という関係を重視します。ある機器を止めたときに、どのサービスへ影響が及ぶかを辿るための、いわば地図にあたります。

モノを数える台帳なのか、つながりを辿る地図なのか——この違いを押さえておくと、CMDBに何を期待すべきかがはっきりします。関係を持たせるぶん、CMDBは資産管理より作り込みや維持の手間がかかるものです。だからこそ、何のために作るのかを見失わないことが大切になります。

なぜ必要とされるのか

CMDBが求められる背景には、日々の運用でつきまとう「影響範囲がわからない」という悩みがあります。システムが小規模なうちは、担当者の記憶や表計算ソフトのメモでも間に合うでしょう。しかし、機器やサービスが増え、相互に連携し合うようになると、全体のつながりを一人で把握するのは難しくなっていきます。

ここでCMDBが土台として力を発揮します。たとえば障害が起きたとき、影響を受けているCIから関係を辿れば、原因の候補や波及先を早く絞り込めます。変更作業の前には、その対象がどのサービスにつながっているかを確認し、影響を見積もったうえで計画を立てられるのです。担当が替わっても、つながりが台帳に残っていれば、引き継ぎの負担を抑えられます。つまりCMDBは、それ単体で価値を生むというより、変更管理や障害・問題管理といった日々のプロセスを下から支える基盤といえる仕組みです。逆にいえば、支える相手となるプロセスが定まっていないままCMDBだけを作っても、宝の持ち腐れになりがちです。

CMDBの中身と成り立ち

CMDBは、いくつかの要素が組み合わさって成り立っています。全体像をつかんでおくと、自社で何をどこまで管理すべきかを考えやすくなります。中心にあるのは、前述の構成アイテム（CI）です。サーバー、ネットワーク機器、ソフトウェア、サービス、契約、担当者といったものが、それぞれCIとして登録されます。

そして各CIには、種類ごとに属性（名称・型番・設置場所・状態など）が記録され、CI同士は「Aサービスは、Bサーバーの上で動く」といった関係で結ばれます。この関係の網こそが、影響範囲を辿る手がかりになります。情報の集め方には、機器やクラウドから自動で集める形と、契約や担当者のように人が登録する形があり、実際には両者を組み合わせるのが一般的です。全体の関係を図にすると、次のとおりです。

つまずきやすい難所

CMDBの構築には、あらかじめ想定しておきたい難所があります。踏まえておくと、「作ったのに使われない」という結末を避けやすくなります。

とりわけ大きいのが、情報の陳腐化です。CMDBは、作った瞬間から古くなり始めます。機器の入れ替えや構成の変更が反映されないままだと、台帳と現実がずれ、やがて誰も信じなくなります。更新し続ける運用がなければ、CMDBは形だけのものになりがちです。二つ目は、範囲と粒度の欲張りです。あらゆるものを細かく管理しようとすると、初期構築も維持も破綻します。何を、どこまで細かく持つかは、目的に照らして絞り込むのが現実的です。三つ目は、目的の欠落です。変更管理や障害対応など、CMDBを使う場面を先に定めないまま作ると、活用されずに終わります。四つ目は、手作業への依存です。更新を人手だけに頼ると、負担が重く、抜け漏れも生じます。可能な範囲で自動収集を取り入れ、人の手を要所に絞る工夫が求められます。いずれも、「作ること」ではなく「使い続けること」を見据えると避けやすくなる落とし穴です。

鮮度を保つ運用の回し方

CMDBは、一度作って終わりではなく、現実とのずれを直し続ける運用があってはじめて役に立ちます。仕組みとして定着させる進め方を整理しました。

鍵になるのは、変更作業とCMDBの更新を切り離さないことです。構成を変えたら、その場で台帳も直す——この流れが定着すると、ずれの発生そのものを抑えられます。そのうえで、自動収集で拾えない契約や担当者などは、定期的な棚卸しで実物と突き合わせ、鮮度を保つのが要点です。完璧を目指すより、「使う場面で信じられる状態」を維持することを優先すると、運用が長続きします。

外注時に確認しておきたい点

CMDBの構築や運用を外部に委託する場合は、次の点を事前にすり合わせておくと、認識のずれを防ぎやすくなります。まず、目的と使う場面です。変更管理を支えたいのか、障害時の影響把握を速めたいのかで、必要な範囲や粒度が変わります。ここが曖昧なまま構築だけを頼むと、使われないCMDBになりかねません。次に、管理する範囲と粒度です。どのCIを、どこまで細かく持つかを、目的に照らして一緒に決めておきたいところです。

さらに、情報の集め方と鮮度を保つ運用も、あらかじめ分担を決めておきたい点です。自動収集の仕組みをどこまで組むのか、棚卸しは誰がいつ行うのか、変更管理とどう連動させるのか——ここを詰めておかないと、構築後に形骸化しやすくなります。初期構築だけを頼むのか、更新を続ける運用まで含めて依頼するのかを明確にしておくと、任せたあとのつまずきを抑えやすくなります。

まとめ：CMDBで押さえる3つの視点

CMDBは、構成アイテムとその依存関係を管理し、変更や障害対応を下から支える台帳です。検討するうえで押さえたい視点は3つに整理できます。第一に、「モノを数える」IT資産管理と、「つながりを辿る」CMDBの違いを理解し、自社が求めているのがどちらなのかを見極めること。第二に、CMDBは単体で価値を生むのではなく、変更管理や障害・問題対応といったプロセスを支える基盤だと捉え、使う場面を先に定めること。第三に、大きな壁となる情報の陳腐化に備え、変更作業と連動した更新と定期的な棚卸しで、鮮度を保つ運用を組み込むことです。この3点を踏まえておけば、「作ったのに誰も使わないCMDB」という失敗を避けやすくなります。範囲の見極めや運用の設計に不安があれば、外部の手を借りるのも一つの選択肢です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　参考：itSMF Japan「ITIL（ITサービスマネジメントのフレームワーク）」に関する一般情報（https://www.itsmf-japan.org/）。用語や定義は各版・出典により異なる場合があります。

Tweet