反省(3)構成管理に成功事例なし

先日、現事務局の方から衝撃のコメントがありました。
「審査員の先生にちらっと聞いたんですけど、
　構成管理で成功している企業ってないみたいですよ」

そう聞いて、なんだか残念なような、ほっとしたような...

というのもかつて、ISO20000を導入するときに力を入れたのが、、
インシデント管理と構成管理でした。
構成管理は、機器の「親子関係」までを管理するデータベース、
CMDBが要件に入っています。

CMDBの概念の肝は、親子関係の紐付け。頭のよい仕組みだととても関心しました。
例えば、一つのサーバーの情報には、親になるデータセンターや、IPアドレス、
顧客名、子になるOSや、アプリケーションの情報などが、
網羅的に紐付けいているのです。
もちろん顧客名から引くこともできますし、IPアドレスからも引くことができる。

これはホスティング屋さんからしたら、夢のシステムです。
「データセンターの障害だ！」と言えば、
データセンタに紐づく顧客のリストが一覧で示され、一次連絡が迅速にできます。
「ハードウェアの障害だ！」と言えば、
同じ機種のリストが一覧で出て、そこから過去の障害対応の履歴などを参照できます。
「○○というアプリケーションに脆弱性がでたよ」と言えば、
○○をインストールしているサーバーと、顧客一覧が示され、
パッチあて作業の時間を見積り、作業スケジュールが迅速に作成できます。

...とこのように、ISO20000の構築チームでは夢が広がり、
CMDBの開発にあたり、ありとあらゆる要件が盛り込まれました。
要件確定後も、みんなが思いついたアイデアを、次から次に開発担当者に伝え、
カスタマイズは膨らみに膨らみました。

気がつくと。カスタマイズ部分のドキュメンテーションが追いつかず、
（中小企業にはよくあることですね...）
CMDBが故障した際の復旧方法を、十分にCMDBの運用担当者に引き継げず、
カスタマイズ部分はリスクが大きいから、と部分的な運用にとどまることになりました。
夢の実現は、感覚値で10～20%程度でしょうか。
高機能なCMDBを入れることで、審査の際、有利に進みましたが、
現状の使い方であればAccessで低予算で身の丈に合ったDBを作ることでも、
実務では十分だったかもしれません。

それでも世の中には高機能なCMDBツールが各種存在し、
ITILを導入しているデータセンターもずいぶん増えました。
きっと成功事例があるんだろうな、と夢見ていた矢先の、現事務局さんからのヒトコト。
もちろん、CMDBツールが全く機能しないわけではなく、
構成管理というのは、どのサービスプロバイダにも存在しますが、
ITILのベストプラクティスは、やはりあるべき姿。
ユーザ側の期待が大きすぎるのかもしれません。
夢のシステムなんて、やはりないんだなぁ、と感じられた一件でした。

身の丈にあった仕組みからスタートし、
PDCAで夢に近づけていくのが、現実解なのだと思います。