ITIL サービストランジションの原則

Vol.017 - 2009年09月08日

前回から、新しい分野である「サービストランジション」に入りました。前回は、「サービストランジション」の目的や目標、評価の測定方法などについて触れました。念のために書いておきましょう。「サービストランジション」の目的は、一言で言えば、次のとおりでした。

「サービスストラテジ」の戦略に沿って「サービスデザイン」で計画が作成されたサービスを、その計画にしたがって確実に本番環境に移行し、確実に稼働すること

「サービストランジション」には、ITIL v2 でいうところの「変更管理」、「リリース管理」、「構成管理」がこの中に含まれるんでしたね。具体的には、次のプロセスが含まれています。

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

さて今回は、「サービストランジション」をより深く理解するために、「サービストランジション」の原則について取り上げます。ただこれは、ITIL Foundation 試験の内容からは少々離れる（と筆者は思っています）ので、基本事項の確認程度にしたいと考えています。

サービストランジションを支える基本原則を理解するためには、

サービスとは何か　いかにサービスが事業に価値を提供するのか

ということを最初に理解しなければなりません。

ITIL v2 の頃から「ITサービスマネジメント」という言葉が使われていますが、ITIL v3 では、ITIL v2 の頃に比べてさらに「サービス」に重点を置くようになりました。実際には、ITIL v2 の頃は 7冊の書籍のうち、「サービスサポート」と「サービスデリバリ」だけが注目されていたので、それだけサービスに重点が置かれないままに読み進められていたのだと思います。ITIL v3 では、ITが事業をサポートする、という側面がより強く重視されています。事業と IT との結びつきを強めれば強めるほど、IT が事業に対してどのようなサービスを提供するのか、ということに重点をおく必要が出てくるのです。

さて、「サービス」とは何でしょうか。詳しくは、本コラムの後半（かなり後のほう）でお話する予定の「サービスストラテジ」で述べる予定でいます。ここではそのエッセンスだけをお話ししましょう。

図１をご覧ください。

図１：事業にサービスを提供するために必要なサービス資産

図の右端にあるように、会社の中には数多くの資産が存在しています。これらの資産は、建物、デスク、電話、パソコン、お金、社員といった有形の資産と、その会社が持っている、あるいは築き上げてきたオリジナルのノウハウ、ナレッジあるはプロセスとそれらの情報といった無形の資産とに分けることができます。企業は、これらの資産を利用して顧客に対し商品やサービスを提供します。

ITの世界でも同じことが言えます。ITにとって有形資産とは、インフララストラクチャ（ハードウェア）、アプリケーション（ソフトウェア）、情報（データ、ファイルなど）、そして金融資本（お金）です。ITIL v3 では、これらの資産のことを「リソース」といいます。一方無形資産とは、プロセス（仕組みや手順）、組織（組織体系や部署、チームなど）、管理（管理手法そのものや何をどの程度管理するかなど）、そしてナレッジ（ノウハウや意思決定）です。これらの資産のことを「能力」といいます。人材は、リソースにも能力にも含まれます。能力は、リソースを適切にコントロールしたり、限りあるリソースを効果的に利用するための調整を行ったりします。そうやって、価値のあるITサービスを提供していくのです。

次に図2です。

図2：サービスは顧客資産のパフォーマンス向上とリスク排除によって価値を提供する

この図はほぼ、ITIL 書籍に載っている図そのままなのですが、少々わかりにくいかもしれません。ITIL 書籍では、３つの柱のようなものは、それぞれ「顧客資産のパフォーマンス」、「提供されるサービスレベル」、「サービス資産のパフォーマンス」と紹介されています。このままではわかりにくいので、筆者は赤い字のように、それぞれを「顧客が持つ資産」、「サービス」、そして「サービス資産」と置き換えて読んでいます。

すると少しわかりやすくなります。「サービス資産」とは、サービスを創出するために必要な資産のことです。サービス資産を消費してサービスを生み出し、顧客に提供します。顧客は対価を払ってそのサービスを受けます。そのサービスは、顧客が持っている資産に対して価値を提供します。価値の内容はまちまちですが、今まで手作業でやっていたことが自動化されるとか、時間が短縮されるとか、間違いが減るとか、同じ時間内に処理できる数が増えるとか、とにかく顧客が対価を払ってまで受けたいと思うようなものでなければなりません。その対価はサービス・プロバイダの収入となって、新たなサービス資産を生み出します。そう、サービスは「顧客に価値を提供するための手段」なのです。

ということは、「何が顧客にとっての価値なのか」ということを根本的に理解しておかないと、顧客に対して真の価値を提供することは難しくなります。ここが、今までの IT業界の不幸だったのです。現場の人たちは目の前に広がっている仕事を片付けるのにせいいっぱいで、何が顧客にとっての価値かということを真剣に考える余裕も時間も、そのチャンスさえありませんでした。そこに光をあてるのが「サービスストラテジ」なのです。

が、その「何が顧客にとっての価値なのか」ということについては、「サービスストラテジ」の解説の時に明らかにしましょう。

さて、上記のように「サービスとは何か」ということを踏まえた上で、「サービストランジション」の基本原則を確認しておきましょう。「サービストランジション」の原則を構成する側面はひとつではありません。ITIL 書籍には、次のようなものが挙げられています。

• サービストランジションの正式な方針の定義と実施
• サービストランジションを通じたすべてのサービス変更の実施
• 共通のフレームワークと標準の採用
• 定評あるプロセスと仕組みの再利用の最大化
• サービストランジション計画とビジネス・ニーズとの整合
• 利害関係者との関係の確立と維持
• 効果的なコントロールと規律の確立
• ナレッジ継承と意思決定支援の仕組みの提供
• リリース・パッケージと展開パッケージの計画
• 軌道修正の予測と管理
• サービストランジション全体でのリソースのプロアクティブな管理
• サービス・ライフサイクルの初期から関与の徹底
• 新規または変更されたサービスの品質の保証
• サービストランジションにおけるプロアクティブな品質改善

ITIL 書籍には、これらの側面のそれぞれ方針、原則、ベストプラクティスがまとめられています。各原則が明確に記述され、適切な原則とベストプラクティスごとに分けられた上で、組織がその原則を実行する手助けとなる適用方法とアプローチが記載されているのです。本当はそれらをひとつひとつ扱いたいのですが、Foundation 試験対策としては少々深すぎます。そこで今回は、「サービストランジションの正式な方針の定義と実施」の方針、原則、ベストプラクティスを簡単にご紹介することにしましょう。

つまりは、「サービストランジション」の各プロセスを導入するにあたって、「サービストランジションの正式な方針」を決めるべきだ、というわけです。また、決めたからにはちゃんとそれを実施しましょう、とも言っています。さらには、「これらの定義や方針は、マネジメント・チームにおいて定義し文書化し、承認されるべき」だとも記載されています。ここで承認された正式な方針をマネジメント・チームによって組織全体、および関係するすべてのサプライヤとパートナーに伝達されるようにする必要がある、とも記載されているのです。組織全体とはつまり、経営にかかわっている人たちも「サービストランジション」の導入に参加し、支援することを薦めているのです。

たとえば。
レストラン経営において、古くからあるPOSレジがたびたび動かなくなるといったインシデントがあるとしましょう。POSレジの電源を入れなおせば何事も無かったかのように動くというワークアラウンドがあるものの、いつ業務に支障が出るのかわからないため、新しいPOSレジに移行することが決まりました。

すると、古いPOSレジから新しいPOSレジに移行するために、考えなければならないこと、決めておかなければならないことがたくさんあります。具体的には、以下のようなことを導入前や導入時に考え、調べておかなければなりません。

• 新しいPOSレジにはどのような機能を持たせるか
• 新しいPOSレジをどのようにして調達するのか
• 新しいPOSレジの物理的な大きさは、現在のものより大きくてもいいか
• 新しいPOSレジはいつ導入するのか
• 新しいPOSレジの導入にかけられる予算はどの程度か
• 新しいPOSレジの使い方を従業員にどのように教育するのか
• 新しいPOSレジのマニュアルはあるのか、なければ誰が作るのか
• 新しいPOSレジが故障した時はどうしたらよいのか
• そもそも、新しいPOSレジを導入することでインシデントは根本的に解決するのか

これらのことを考えるための専門チームを発足するにしても、誰かが業務の合間に考えるにしても、通常業務には少なからず影響が出ます。経営者層はこれらのことを理解し、正式にプロジェクトチームを発足したり、そのための人員をアサインしたり、その人員を通常業務からはずしたり、人員になんらかの権限を与えたりしなければなりません。

このように、新しいIT機器を導入し本番環境で上手く稼動させるためには、ITに詳しい現場の人間の力だけでは不十分です。あらゆる面から支援することができる経営陣の参加が不可欠となるのです。支援するべきあらゆる面の中には、上記のような人的リソースの確保だけでなく経済的な側面、そのIT機器の導入に対して反対している人たちへの配慮といった側面なども含まれます。また、現場で高機能高価格な機種を勝手に導入しないように、費用対効果が最も高く自分たちの業務に対して妥当な機能が付いているものを導入するようチェックすることも必要です。

さらに、ITIL書籍では次のようなことも考えるべきだ、と書かれています。

• 方針では達成目標を明確に示すべきであり、方針の不遵守は是正するものとする
• 方針を全体的なガバナンス・フレームワーク、組織、およびサービスマネジメントの方針と整合させる
• 方針の策定に関与する後援者と意思決定者は、方針の採用と実施に対するコミットメントを実証しなければならない。これにはサービスのあらゆる変更から予測される成果を提供するコミットメントを含む
• チームを統合するプロセスを使用する。説明責任と実行責任の明確な線引きを維持しながら力量を融合させる
• リリースにおいて変更を提供する
• リリース設計段階とリリース計画立案段階の初期に展開を検討する

原則ひとつとっても大変です。ITIL v3 は、そう簡単に右から左に導入できるものではないと思います。ただ、大変だからこそ「Small Start Quick Win」を提唱しているわけだし、正しく理解して正しく導入しないと大怪我をするのです。その一方で、正しく理解して正しく導入すれば、かならずや一定の成果を上げることができるのです。

さて次回は、「サービストランジション」をもう少し深く掘り下げて、もうちょっと具体的な内容に入ってまいります。お楽しみに。