製造業のA社はITシステムの開発・運用をIT子会社B社にアウトソースしている。しかし、A社の管理者であるM氏は、子会社B社の対応に普段から不満を持っている。たとえば、最近はウイルス騒ぎのたびにルータや基幹サーバの設定を変えたりソフトのバージョンアップを行なったり、パッチを当てているのだが、その度にアプリケーションが動かなくなるのだ。原因はパッチ自体ではなくて、パッチの導入後に関連するサーバを、連絡もなく再起動しているのが問題らしい。同じ会社にもう運用を任せて何年にもなるのに、何でいつも問題が起きるのだろう？ Mさんはそのたびに担当には強くクレームを入れているのだが「以降気を付けます」というだけで一向に改善されない。 Mさんの不満は募る一方だ。
単純なユーザーの追加や削除のような日常のメンテナンスから、システム更新のような大掛かりなものまで、ITのシステムに変更を加えることはよくあります。しかしシステムに変更を加えることがトラブルの原因となることは、システム管理をされている方ならよくご存知なはずです。
何かトラブルが起きた時、「○○○が今朝から動かなくなっちゃったよ」「何か変えた？」といった会話をよく耳にします。機器やソフトウェアに故障や不具合はつきものですが、正常に動いているシステムが、何の理由もなく突然動かなくなるということはめったにありません。やはり何か設定なり、環境が変わったことが引き金となっていることが多いのです。したがって、システムに加えた変更を管理するということは、トラブルを速やかに解決し（リアクティブ）、及びトラブルを未然に防止する（プロアクティブ）という両面でとても重要になります。
この中で特に重要なのが、変更を加える前に、その変更が他の機器やシステム全体、あるいは業務にどのような影響を及ぼすかを評価することです。事例ではそのインパクト評価がうまくできていないようですね。
ITILでは、変更を行なう前にその影響度を評価し、その結果承認されたものだけを実施するというインパクト評価の方法が推奨されています。今回はそのインパクト評価を中心に、ITILの手法を用いて変更管理をどのように行なっていくかを見てみましょう。
前回のキャパシティ管理と同様、いつ、どこに、どのような変更を加えたかを記録にとっておきましょう。面倒なようですが、記録を残しておかないと、以前にどんな変更を加えていたのかわからなくなってしまいます。
キャパシティ管理と同様にノートに書き留めておくのでもよいですが、今回は次のステップで変更のインパクトを関係者の間で評価する必要がありますので、専用のフォームを用意しましょう。ITILではこの変更内容を記述するフォームを「RFC（Request for Change：変更要求）」と呼んでいます。
この変更を行なう場合には、このRFCに必要な内容を記入し、それを決められたルートで承認することを守ることで、変更を正しく管理することができます。変更管理者はすべての変更をコントロールする役割を持つ管理者で、RFCの内容を見て優先度を決めたり、あるいは同じシステムに同時に別々の変更を行なわないようスケジュールを調整します。
しかし、変更管理者の最も重要な役割は、変更のリスクを評価することにあります。事例では、まずMさんはB社にRFC発行のプロセスがあるかどうか、またきちんと変更管理者が任命されているかを確認すべきです。サーバ担当者が自分の判断で勝手にパッチを当てているようでは、いつか取り返しのつかないミスを犯すかもしれません。その時になって責任の在処を追及しても遅いのです。
 |  |
|---|
 |
||||
 |
 |
 |
|
 |
 |
||||
「ITILでシステムの効率化を目指そう」トップへ
【アスキービジネス 新刊ムック】
【ASCII.jp SaaS・ASP】