メールやチャットは却下――IT変更管理はオフラインで：ITIL Managerの視点から（2/2 ページ）

[谷誠之，ITmedia]

　CABの中でRFCが評価されたら、今度はそのRFCを分類していく。分類の方法はいくつかある。例えば、次のようなものだ。

例1　優先度での分類

• 即時：変更しないと、多くのユーザに対して申告なサービス停止や使用上の問題を引き起こす。リソースをただちに割り当て、迅速に実装する必要がある。
• 高：変更しないと、何人かのユーザに深刻に影響する、または深刻な問題が時々発生する。変更の構築やリソース割り当てが積極的に行われる。
• 中：深刻なインパクトはないが、次の大幅なITサービスの変更のタイミングまで待てないもの。
• 低：変更の必要性を無視できないが、次の大幅なITサービスの変更のタイミングまで待てるもの。

例2　規模による分類

• 大規模：事業全体、あるいは組織全体に影響する変更であり、変更しないと事業に深刻なインパクトを与える可能性があるもの。また、変更そのものに多大なリソースを必要とするもの。
• 中規模：一部のITサービスに影響する変更であり、変更しないと一部のITサービスに深刻なインパクトを与える可能性があるもの。変更に中程度のリソースを必要とするもの。
• 小規模：ごくわずかなITサービスに影響する変更であり、変更にかかるリソースもわずかであるもの。

例3　履歴による分類

• 新規：初めて起案された変更。
• 類似：似たような変更が以前起案されたことがあり、評価中、または承認待ちである。
• 却下済：同じ、または似たような変更が起案されたことがあり、却下されている

---

　これらの分類は大変重要である。分類することで、「どの変更から先に着手するか」「いくつかの変更をまとめることができるか」といったことを評価できるからである。

　さて、CABについて筆者の経験上、重要だと考えていることを加えておこう。それは、CABは必ず「顔を突き合わせて行う」ことが望ましい、ということである。最悪、テレビ会議でもかまわない。しかし、相手の顔や息づかいが分からないもの、例えばメールや電子掲示板、電話会議などでCABを開催してしまうと、思わぬコミュニケーションミスを発生させてしまう可能性がある。いくらITインフラの変更にともなうものだとはいえ、CABの開催に限ってはアナログな手段で行うほうが良い。

谷 誠之（たに ともゆき）

IT技術教育、対人能力育成教育のスペシャリストとして約20年に渡り活動中。テクニカルエンジニア（システム管理）、MCSE、ITIL Manager、COBIT Foundation、話しことば協会認定講師、交流分析士1級などの資格や認定を持つ。なおITIL Manager有資格者は国内に約200名のみ。「ITと人材はビジネスの両輪である」が持論。ブログ→谷誠之の「カラスは白いかもしれない」