前回までは、ITILを規定の視点で考えてみました。 今回は、ITILの構成管理について、実際の構築の中で工夫したことを書いてみたいと思います。

目次

スタートは構成管理から

構成管理は何のため？

物作りに学ぶ構成管理

システムの構成管理

CIの単位は、どのようにするか？

スタートは構成管理から

ITILの導入は、インシデント管理、問題管理から始めることが多いそうですが、私は構成管理からスタートしました。理由は２つ。
システム名やサーバー名称が、担当レベルでまちまちで、あいまいのところが多い 変更管理とのつながりを明確にしたい
１．の名称の曖昧さは、以前は　システムとサーバーそして管理者はクローズしており　あまり混乱することは無かったのですが、最近はサーバー、ストレージ、バックアップ統合などが進むと共に　仮想化やブレードといった技術、製品が多くなり、この辺で整理しておく必要があると感じたわけです。 今後　インシデント管理や問題管理などをやるにしても　システムの構成の管理が明確でないと、対象のシステム、機器がはっきりわからなくなったり、せっかく蓄積したノウハウも　うまく検索できなくなると思います。 “言葉の定義” ⇒ “構成の明確化”　といったベースの部分がまず第一だと思った訳です。
２．の変更管理とのつながりについては、製造業的感覚で、製品の設計変更のやり方と同じ考え方が、自分達にはわかりやすいのでは？　と考えました。

構成管理は何のため？

構成管理を導入するとき、社内の人にこんな質問をします。 “構成管理は何のためにやると思いますか？” これは、非常に大切なことで、構成管理の目的はいろいろあると思います。 ITILでは、障害がおきたときに、その時点の状態（スナップショット）がわかるようにして問題解決をはかることを重視していますが、それ以外にもいくつか考えられ、それは会社ごとに異なると思います。

そこでは、こんな最終目的をあげました。
危機管理（早期障害対応）
資産管理
未来の改善のため
１．２．については一般的ですが、３．はちょっと違った視点に見えるかもしれません。
しかし、実際は構成管理を実践している会社では無意識のうちに未来のために構成管理を活用しているものです。 最近　”サーバー・ストレージ統合”といった切り口で、数社のベンダーさんのコンサルを受けたことがあります。 コンサルは必ず現状調査から始まり、その工数が半分くらい占めています。また、調査する項目も各ベンダーさんも似たり寄ったりでした。 今後、情報システム部門では、外部のコンサルは必要不可欠だと思っています。しかし、その都度調査していては社内の工数、コンサルの工数ともに大変です。最初の調査は確かに大変でしょう。しかしその情報を構成管理台帳に1回載せてしまえば、次回からはその情報を使えます。こういう積み上げによって、いつの間にか情報が溜まって行き、コンサル費用や次期の構想の期間が圧縮できるでしょう。 このような視点で構成管理の管理項目を決めるのも、未来のために役立つのではないでしょうか？

物作りに学ぶ構成管理

ITILの構成管理を構築されるにあたって、物作りの部品表は役立つ部分が非常に多いと思います。 システムもしくはサービスを１つの製品に見立てて考えていくのです。 家電製品など、物作りの会社では、製品を表すために、”部品表”があると思います。そして部品表は目的（工程）によって、属性をもとにいろいろな形をとります。技術部門では、ＣＡＤとの関係や技術者にわかり易いような機能別に、生産技術部門では、生産工程別に、購買部門では部品の発注リードタイム別や発注先別に、サービス部門ではサービスパーツの部品表・・・　などなど。 例では、技術部品表の大まかな形をあげていますが、これが、使う人の目的により、属性をもとに形を変えていきます。また、ポイントは、部品の概念は仕様書などの文書まで広げ、必ず番号管理されています。

システムの構成管理

 Microsoft 構成管理運用ガイドを参考にすると　システムの構成は下記のような図が考えられます。

081217_02.png 出典：Microsoft 構成管理運用ガイド http://www.microsoft.com/japan/technet/prodtechnol/windows2000serv/maintain/opsguide/cfgmgtog.mspx 現在、各社にある部品表のシステムの考え方を、そのまま構成管理に使えないかというアプローチも面白いと思います。これは、次回お話しする変更管理と密接に関係してきます。 もし、製造業の方で、部品表のシステムを扱っている方は、システムの構成要素を、自社の部品表の概念を入れて考えてみるのもいいのではないでしょうか？

CIの単位は、どのようにするか？

ここで、製品を構成する部品に相当するのが、ＣＩ（構成アイテム）ですが、ＣＩをどの単位でくくるかというのが問題になってきます。ここが十分考えなければならないポイントです。 システム（サービス）を提供するのはあくまでもアプリケーションなので、システムの直下にアプリケーション。そしてそのアプリケーションを入れているハードウェアをその下におくという考えもあるでしょう。 また、仮想化の浸透により、基本ソフト部分は、アプリケーションと一緒に考えたほうがいいものと、ハードウェアと一緒に考えたほうがいいものと両方あります。 また、一般的なサーバーは、わざわざ分ける必要も無く、システム直下にサーバーをおいてもいいものも多いでしょう。

悩みだし出すと　どんどん深み（？）にはまって行きます。こういう類の話は、ある意味興味深くて、とかく理想を追い求めてしまうため、いつまで経っても結論は出ません。 とにかく、大切なのは、“何のためにやるのか？”を常に忘れないことです。 最後に、構成管理はちゃんとやろうとすると非常にハードルが高く、面倒なものです。私の経験では、構成管理の第１歩は、ＣＩの内容はともかく、現在あるサーバーや機器をもれなく番号をつけて名称と設置場所を記載し、メンテナンスをしっかりするきまり（習慣）を作ることだと思っています。 実際、簡単なデータベースを作り、機器の簡単な登録だけを義務付けたところ、いつの間にか担当はそこに自分の必要な情報をどんどん入れるようになりました。 CIの簡単な登録/削除だけを漏れなく行い、“システム、サーバーなどの情報を入れる器をまず作ること”が、導入のポイントだと思っています。 “信頼できる情報の入れ物”　さえあれば　情報は自然と集まるものです。“集まる情報が必要な情報”というアプローチもあるかもしれません。