|
ITIL サービストランジションのプロセス Vol.018 - 2009年09月28日 お待たせしました。ちょっと日が開いてしまいましたが、今回からいよいよ「サービストランジション」の各プロセスについてご紹介してまいりましょう。 「サービストランジション」の範囲や目的については、第16回目、第17回目のコラムでお話しましたね。その中で「サービストランジション」の目的は、「サービスストラテジ」の戦略に沿って「サービスデザイン」で計画されたサービスを、その計画にしたがって本番環境に移行し、確実に稼働することである、と書きました。ITサービスライフサイクルの中心部分にあたるわけです。このライフサイクルの中心部分を支えるために、「サービストランジション」には次に挙げる７つプロセスが存在しています。 1. 移行の計画立案およびサポート この7つのプロセスは大きく二つに分けることができます。
前者に含まれるものは次の3つです。
残りの4つが後者、つまり「サービストランジション」だけで利用されるプロセスです。 この、ITサービス・ライフサイクルを横断したプロセスが存在している、という概念は重要です。各ライフサイクル（あるいは各 ITIL 書籍）はそれぞれが独立して存在しているのではなく、密接な関わり合いを持っている、ということを意味しています。「私は構築屋だから、戦略や設計などには関係ない」とは言えないほど、ITの世界は複雑になってきているのです。また同時に、ITに寄せられる期待もそれだけ大きい、ということでもあります。 さて、7つのプロセスのうち、今回は「移行の計画立案およびサポート」と「変更管理」の2つを取り上げます。 移行の計画立案およびサポート サービス・プロバイダは、顧客に対してITサービスを提供します。そのITサービスは（何度も書いていますが）顧客の事業目標を達成しやすくするためのものでなければなりません。時代とともに進化を続けるIT業界ですから、常に新しい技術の導入や市場動向の変化に対応していかなければなりません。同様に、顧客の事業戦略やビジネス目標なども、市場の変化に伴って柔軟に変化する可能性があります。 こうしたIT技術の変化や事業戦略の変更などに伴って、顧客に提供するITサービスが新規に構築されたり変更されたりした場合には、えてしてさまざまな問題点が生じます。その問題点を事前に推測して対応したり、問題の影響を最小限に抑えたりするための活動が、この「移行の計画立案およびサポート」なのです。 主な問題点としては、次の3つです。
非協力的なスタッフとは、使い慣れた技術ややり方を捨てて新しい技術ややり方を導入することに抵抗感があったり、新しい技術ややり方のをわざわざ覚えなおさなければならないことに不満を持ったりするスタッフのことを指します。Windows XP から Windows Vista への移行、Office 2003 から Office 2007 への移行などは、まさにそうだと言えるでしょう。そういった負の感情が起きないように事前に認知活動や変更の必要性を理解してもらうような教育を行ったり、不幸にして負の感情が起きたとしてもすぐに考え直してもらえるような啓蒙活動や操作のトレーニングを行ったりする必要があります。「変更は決まったことだ」と上から押さえつけるような指導では、ユーザの不信感はぬぐえません。特に、なぜその変更が必要なのか、変更することによって効果や効率はどう変わるのか、ということを納得してもらうための活動は重要です。 新規サービスの導入、ITインフラの変更には、トラブルがつきものです。むしろ、トラブルのない変更のほうが珍しいのではないか、とさえ思ってしまいます。変更時にどのようなトラブルが発生するか、ということをできる限り事前に予測し、対策を立てておく必要があります。また、十分な計画を立てて導入したシステムであっても、移行後に予想外のインシデントに見舞われる可能性もゼロではありません。予想外のインシデントですから、それを予想しろというのも無理な話ですが、ただ「予期せぬインシデントが起こる可能性がある」ということは認識しておいて、そのための役割分担や連絡網、責任範囲はあらかじめはっきりさせておいたほうがいいでしょう。 もし、日常業務を止めてまでサービスを移行するような必要性に迫られている場合は、事前にスタッフへの説明と協力要請も必要となってきます。さらに、移行、変更されるサービスの構築、開発、テストに必要となるリソースを割り当てるなどの活動も行います。なお、計画立案の際には、できる限り過去に行った実績ある計画をモデルとして参考にします。もちろん、計画に支障が出たり状況が変わったりした場合は、新しい状況に適合するように常に計画を変更します。 ところで「移行計画立案およびサポート」プロセスには、「サポート」という言葉がついていますね。これは、「サービストランジション」を実施するスタッフやあるいはチームをツールや仕組みで支援することを意味しています。「サービストランジション」によって導入されるITサービスに関係するすべての利害関係者に対して、移行内容や導入されるITサービスの内容を理解させたり、それに従うことが出来るようにしたりといったサポートが必要だ、というわけです。 変更管理 致命的なインシデントを防止したり、さまざまな問題を解決したりすることを目的としたITインフラの変更は必須要件といえるでしょう。ITサービスが、それを提供するインフラの故障で使えなくなったり、時代とともにITサービス（またはITインフラ）が陳腐化したりすることがあります。一方前述のとおり、そうしたITインフラの変更には様々な「新たな問題」がつきまといます。新しいサービスのための導入したITインフラが古いインフラと整合しないとか、新しいサービスを導入したために古いサービスが使えなくなった、というようなことはよく耳にします。特に、最近の企業内にあるIT機器は複雑に絡み合い、ちょっとした機器の入れ替えだけでも業務全体を止めてしまうようなインシデントを引き起こす可能性があります。変更が新たなインシデントを引き起こすという可能性を最小限にとどめ、既存のITインフラやITサービスを守るために、変更管理というプロセスが存在します。 基本的に変更管理プロセスは、ITIL v2 の時とほとんど変わりません。 図１をごらんください。これは、変更のタイプを3つに分けたものです。実際の現場では通常変更をさらに細かく分類して、関連部署に決裁権限を付与し管理します。 図１変更のタイプ
通常変更は図２のようなプロセスで管理を行います。 図２通常変更の管理プロセス これに対して、標準変更のプロセスは図３のように簡略化されています。 図３標準変更の管理プロセス この違いは、標準的で成功率の高い変更手順を標準変更として整備し、その都度変更管理プロセスを通さずに運用することを目的としているためです。「ありとあらゆる変更は、必ず変更管理プロセスを通さなければならない」としていた ITIL v2 に比べて現実的になったといえるでしょう。 RFC（変更要求） ITIL v2の時にもRFC（変更要求)がありました。ITIL v3でも、変更管理プロセスの始まるきっかけはRFCです。RFCはすべての変更を一元的に管理、記録するための共通フォーマットを用います。その記入内容の例を以下に記します。承認前に記入する内容と承認後に記入する内容があります。 承認前に記入する内容は、次の通りです。
これに対して、承認後に記入する内容は、次の通りです。
変更承認者および変更諮問委員会 変更承認者とは、変更管理において変更の実施可否を判断する役割を持つ人（または人たち）のことです。通常、変更承認者は、その組織の決済権限者のことです。この変更承認者の意思決定をサポートするのがCAB（変更諮問委員会）です。承認者をサポートするCABのメンバーは、アプリケーション開発部門、インフラ部門、サービスデスク、運用部門、顧客代表といった立場が異なる人たちで構成されます。 ちなみに ITIL v2 で CAB/EC（CAB/Emergency Committee：変更諮問委員会／緊急会議）は、ECAB（Emergency CAB：緊急変更諮問委員会）と名前を改めました。意味や位置づけは変わっていません。 さて、次回も「サービストランジション」のプロセスに関して説明を加えていきます。どうぞお楽しみに。 |
