前回は、構成管理の話をしましたが、今回は、変更管理の話をしてみたいと思います。 ITILの導入は、インシデント管理→問題管理、から始める会社が多い中で、構成管理→変更管理の順に考えるのは　逆の流れです。一概には言えないとは思いますが、物作りの世界では、ISO9000の影響もあり、ドキュメントの流れで業務を考えているように思います。今までのＩＴの世界ではドキュメントの重要性が軽視されてきた傾向があります。ですから、その人がいないとわからないとか、資料がないとかいう言葉がよく聞かれるのです。 ITILの変更管理は、ＩＴ業界でISO9000のような変更プロセスをやればいいと当初から考えていたので、”物作りに学ぶ”という言葉をタイトルに入れているのです。

目次

物作りの変更パターン

最後に

物作りの変更パターン

変更という行為は、その対象になるものがなければなりません。前回お話した”部品表”は、製品の構成要素（部品、文書）の集まりです。そして製品の変更は、”部品表”に対して行われます。　 たとえば、部品を変更するとき（例えば１００Ωの抵抗を５０Ωに変更）とか、文書を変更するとき（例えば回路図の中の１００Ωという部分を５０Ωに修正）を、部品表に書かれている部品番号や文書番号を修正するという形で変更を表現します。つまり、”結果として何が変わるのか？”を先に文書として、番号をキーにして多くの関係者に知らしめるのです。

製造業では、設計の変更により多くの部署が影響を受けます。そのため、部品表を“神様”として、変更に伴う最終的な形をまず部品表に表し、全部署が変更に対する認識を共有するようにしています。 ではITILの変更管理も同様に考えて見ましょう。 部品表の部品、文書に相当するものが、構成管理のＣＩと考えられます。 下記に、ハードウェア（サーバー）を入れ替えた簡単な例を書いてみました。

構成管理はITILの中でも最後のステップとして位置づけられています。　リリースが完了して　構成管理にて最新の構成に変更することになっています。 ここでは　変更管理時点で　構成管理に”変更待ち”として登録し、リリースが完了した時点で　ステータスを変更して変更前の構成を履歴という形で残しています。 結局同じことのように見えますが、私は構成管理の情報は、システム全体の”マスター”という視点で捉えています。現在の構成、過去の構成、そして予定されている直近の構成、を表すと共に、インシデント管理、問題管理等で使用されるサーバー、文書などの、”言葉”のマスターであるとも考えています。 変更管理はそのマスターに対して変更をかけるということになります。

最後に

構成管理は、やり始めたらどんどん深みに入っていくことは前にもお話しました。ITILでもスコープを明確にするように書かれています。 変更管理も同様で、何の変更を管理するか？承認はどのレベルでやるか？ということを決めることが重要です。一言で言えば、本番環境に影響するものはすべて変更の承認が必要です。かと言ってすべての変更を網羅するのはなかなか大変です。やはり変更管理の承認に関しては、簡単な変更に対する承認レベルや承認ステップをルールで決めることを同時に考えながら、構成管理、変更管理のシステムを考えることは重要でしょう。 今回４回のシリーズで、ITIL活用のアイデアというタイトルで書いてきましたが（お役に立ったかどうかはわかりませんが。。。）、

私の基本的な考えは、
とにかく文書化すること
文書の関連付けを明確にすること
です。

業務はすべて、必ず文書によって承認が行われ、次のステップへ進むという大前提のもと、業務は、文書で回っていることを、意識してもらいたいと思います。 そして、
文書を作る場合は 誰のためにやっているか？
を常に意識することが一番大切だと思っています。