ITIL サービストランジションについて

Vol.016 - 2009年07月21日

本コラムも、今回で16回目を迎えます。10ヶ月目に突入です。ここでやっと「サービスデザイン」のお話が終わりました。今回からは、次の書籍である「サービストランジション」のお話へとコマを進めます。

ちょっと、復習しておきましょう。2回目のコラム(ITIL v2 のサービスサポートはどうなったの？)で書いたように、「サービストランジション」には ITIL v2 の構成管理、変更管理、リリース管理の3つが含まれています。さらに、2回目のコラムの中では、各コアを乱暴にも一言でまとめました。その中で、サービストランジションは「設計済みのITサービスを確実に導入する」のが目的である、とまとめています。

「サービストランジション」の位置づけを再確認しておきましょう（図１）。この図は何度も登場していますね。

図１：ITIL V3 コア

「サービストランジション」は、「サービスデザイン」と「サービスオペレーション」の間におかれています。4回目のコラム(【サービスデザイン】－ サービスデザイン概要 1)でも触れたとおり、ITIL v3 では

• 「サービスストラテジ」で提供するサービスを定義し、
• 「サービスデザイン」でサービスの内容を具体的に決め、
• 「サービストランジション」でそのサービスを実際に提供（導入）し、
• 「サービスオペレーション」で日々のサービス提供をサポートする

という流れと関係を重視しています。これはサービスのライフサイクルに注目していますから、単純に時系列に並んでいると考えればわかりやすいでしょう。ぜひ、コラムの4回目にもう一度目を通しておいてください。

ITIL v2 との明確な違いをもうひとつ、示しておきましょう。
ITIL v2 のサービスサポートでは、次のような理解をしていた人も多いと思います。

インシデント管理で、インシデントの管理と復旧を行い、
　　問題管理で、そのインシデントの根本原因を追究して解決策を図った上で、

それらインシデント管理や問題管理の活動の結果として作られるのが RFC で、その RFC の提出先が変更管理である、と。さらに、その変更内容を本番環境に確実に投入する責任を持つのがリリース管理であり、さらにさらに、その変更内容を確実に CMDB に記録する責任を持つのが構成管理である、と理解しておられたかと思います。つまり変更管理やリリース管理は、インシデントを解決するための手段として存在している、と考えるとわかりやすかったのです。

一方 ITIL v3 では、ITサービスのライフサイクルに重点を置いています。つまり、変更管理やリリースおよび展開管理は、事業が必要とし、「サービストランジション」が計画し、「サービスデザイン」が設計した ITサービスを本番環境に確実に導入する責任を持っていると考えるのです。

そのような考え方の違いには、十分注意する必要があります。

では、「サービストランジション」の目的や目標はなんでしょうか。

ITIL書籍には、「サービストランジション」の目的として次のようなものが挙げられています。

• リリースをパッケージ化、構築、テスト、本番展開し、顧客と利害関係者の要件に指定されたサービスを定着させるために、必要なキャパシティとリソースを計画、管理する
• 新規または変更されたサービスをリリースまたは展開する前に、サービス能力とリスク・プロファイルを評価するための一貫性のある厳密なフレームワークを提供する
• 識別されたサービス資産と構成がサービストランジションの段階を通じて発展していく中で、それら全ての完全性を確立、維持する
• 変更管理、リリース管理および展開管理が、リリースをテスト環境から本番へと昇格させるための効果的な決定を迅速に下せるよう、良質のナレッジと情報を提供する
• サービスデザインで規定された要件と制約に沿って、サービスを管理、運用、サポートできるようにする

つまり、「サービスストラテジ」の戦略に沿って「サービスデザイン」で計画が作成されたサービスを、その計画にしたがって確実に本番環境に移行し、確実に稼働することこそが、「サービストランジション」の目的なのです。新しくサービスを導入したり変更したりする時には、事業に影響が出ないよう注意深く計画を練り、テストと展開を行うことが大切であり、そのために適切なコントロールが必要なのです。そのフレームワークがサービストランジションでまとめられているのです。

一方、「サービストランジション」の目標は、次のようなものが挙げられています。

• 新規または変更されたサービスのパフォーマンスと利用を、事業の変更を可能にするためにどのように役立てることができるかについて、顧客の期待を設定する
• 事業変更プロジェクトまたは顧客が、それぞれのビジネス・プロセスとサービスにリリースを統合できるようにする
• 移行されたサービスのパフォーマンスの予測と実際との差を縮める
• 既知のエラーを減らし、新規または変更されたサービスの、本番への移行に起因するリスクを最小化する

これも一言にまとめると、新規導入されたり変更されたりするITサービスによって、顧客やユーザの満足度を高めることと、「サービスデザイン」によって設計されたITサービスが実際の運用を無事に開始できるよう、的確に効率的に移行作業を行うことが目標である、といえます。

サービストランジションでは、これらの目的や目標を達成するための方法がフレームワークとしてまとめられております。内容としては、次のようなものを含みます。

• リリースのパッケージ化
• リリースの構築、テスト、本番環境への展開
• 顧客要件と利害関係者に指定されたサービスを定着させるためのプロセス、仕組み、
• 機能の管理と調整

これは、「サービストランジション」プロセスの

• 変更管理
• リリース管理および展開管理
• サービス資産管理および構成管理
• ナレッジ管理

のすべての段階を支援します。ただし、非常に軽微な修正や継続的なサービスの改善については含みません。たとえば、故障したプリンタやPCを予備機と交換したり、標準的なソフトウェアをインストールしたり、新規ユーザのアカウントを登録したり、ソフトウェアのアップデート作業などは含まれません。

このような「サービストランジション」を導入することは、事業に対して付加価値をつけることになります。付加価値とは、新しい要件や市場の発展に素早く対応する能力や競争力、あるいは合併、会社分割、買収、サービスの移転に伴う移行の管理といったものが含まれています。さらに、新規あるいは変更されたサービスのサービスレベルが予測できたり保証できたりすることも大切な付加価値となります。これ以外にも、変更期間中であって事業要件とガバナンス要件が法令に違反していないかチェックできたり、新しいサービスの導入をしたり、あるいは、変更に伴うコストが予算に対して大幅な差が生まれにくくなるといったものも含まれます。

さて、「サービストランジション」においては、実際の事業計画とIT計画との間での整合性を図らなければなりません。その変更や、変更の実装が事業と照らし合わせて妥当かどうか、ということを管理する必要があるのです。

そのための一般的な指標にはいくつかあります。代表的なものを挙げてみましょう。

• 事業、IT、サービスマネジメントの戦略および計画と整合している「サービストランジションの増加率」
• 「サービストランジション」のプラクティスとその能力を明確に理解している、顧客および利害関係者である組織、または部門の割合
• 「サービストランジション」に割り当てられているサービス・ライフサイクルの予算の割合

では、サービストランジションの測定はどのように行うのでしょうか。

ライフサイクルにおけるサービストランジションの段階でのパフォーマンスの測定は、「サービスデザイン」で取り決めたサービスレベルやサービス品質が、新規または変更されたサービスによって提供されているかどうかということに注目します。また、「サービスデザイン」で計画した「サービスの展開やインストールのために必要となるリソース」の範囲内でちゃんとリリースできたかどうか、ということにも焦点を当てます。

また、「サービストランジション」の価値は、次のような項目を測定することで明らかになります。

• テストのコストおよび評価コストと比較した、実際のインシデントのコスト
• 「サービストランジション」を実施するにあたってのリソース不足など、「サービストランジション」が原因となって生じる遅延
• 「サービストランジション」のプロセスによって識別できたであろう運用上の問題
• 「サービストランジション」の各段階に対する利害関係者の満足度
• 「サービスデザイン」への変更を対象としたテストによるコストの節減
• スタッフの生産性向上

ITサービスの運用を確実に、しかも事業ニーズ、事業戦略に沿って行うためには、「サービストランジション」の段階で的確に本番環境への導入を行わなければなりません。逆に「サービストランジション」を的確なものにするためには、事業ニーズ、事業戦略、つまり「サービスストラテジ」からのインプットや、ITサービスのきちんとした設計、つまり「サービスデザイン」からのインプットが的確に行われなければなりません。具体的には、図２に示すような項目が「サービストランジション」へのインプットになります。

サービストランジションへのインプット一覧

これに対して、サービストランジションの結果（アウトプット）は、「サービスオペレーション」に対するものと、サービストランジションが成功した後にサービスが提供される顧客とユーザに対するものとがあります。たとえば、更新された契約ポートフォリオや更新されたサービスポートフォリオおよびサービスカタログといったものは、顧客やユーザに提供される代表的なアウトプットです。

以上がサービストランジションの全体像です。これを分かりやすく図にすると図３のようになります。実際には、「サービストランジション」の各プロセスは「サービストランジション」の中で閉じているのではなく、ライフサイクルの他の段階とも密接に関係しているのですが、そのことはまた別の機会にお話しましょう。

図３：サービストランジションの全体像

さて、次回は、「サービストランジション」の原則についてのお話になります。お楽しみに。