本日のテーマは「構成管理」です。この言葉を聞いてみなさんは何を想像するだろうか？
「あぁ、CMDBだろ？」とか、「サーバのOS情報とかパッチ情報でしょ？」とか、「Excelで管理してる奴でしょ？」とか色々だと思います。
「敢えて言おう、すべて外れであると。」（ギレン風）
「諸君、構成管理はプロセスなのだよ！！」
単にこれが書きたかっただけなんだけど、あまりにもこういった用語に関する意識の違いというのが、そこかしこで聞かれる。
簡単にいえば構成管理データベース（CMDB）を管理するプロセスと言ってもいいであろう。これはITILにも記載されているから、よく読んでおいたほうが良い。個人的にはv3より、v2の方が分かりやすいと思う。
構成管理プロセスには、
- 識別
- 更新
- 監査
- 報告
などの仕事があり、他の管理プロセスを支援する役割を持つ。
この支援というのが曲者で、よく運用管理部門で構成管理を導入したいという話がでるのだが、大抵は導入効果や構成管理自体に価値が見いだせずになかなか導入が進まない。
これは構成管理自体をやっても、構成データを管理する仕組みだけが出来上がって、誰が、どんなタイミングで、どんなデータを使うのかが全く定義、設計されずにCMDBだけ導入されてしまうケースによく見られる。
CMDBだけ構築してもこれを最新の情報に維持したり、実際の環境とデータの齟齬を監査したりするプロセスがないといずれはデータは陳腐化し、使いものにならないものとなる。
これならExcelでシコシコと個人で台帳管理しているのとなんら変わらない。
「利用目的のない（構成）データをお金を掛けて管理しても意味が無い。」
ってことだ。
構成管理データベースは大抵の運用のケースでは、「あったほうが良い」とか「なくてもなんとかなる」という声が多い。これは構成データを活用して運用品質の改善に貢献しようというアイデアが
浮かんでいないのであろうと考えてしまう。
しかしながら、通常運用、異常時の運用を含めて運用員や管理者は必ず構成情報を参照する。しないと運用できないはずだ。
だって、運用ってのは、「IT資産の運用」なのだから。
システムも、サービスもネットワークも、インシデントチケットも、IT資産も構成から出来ている。だから参照しなければITの運用はできない。
構成管理を理解するには、まずは運用のどのシーン（プロセス）で構成情報を参照しているかを知ることから初めて見てはいかがだろうか？そこから各プロセスの改善の糸口が見つかるかもしれない。
