ITIL4を深掘ってみる(5/5)-4.名前が変わっちゃったプラクティスの背景と理由

一旦一区切りにしたいと思います。さて、今回は、ITILv3とITIL4で名前が変わったプラクティスについて、その理由を考察します。

すみません、今回も5,000字を超えました。

今回も、これ以降、この記事について、「プロセス」(ボールド、及びイタリック)表記になっているものは、ITILv3のことを指しています。つまり、プロセスは、固有名詞として扱います。一般名詞としてのプロセスとは意味が違う点をご了承ください。

需要管理→「事業分析」(SMプラクティス)

そもそも、ITILv3における需要管理プロセスとは何を指しているでしょうか？SO（Service Operation）の段階で語られることの多かったITILv3において、あまり馴染みがない方もいらっしゃるかもしれません。需要管理プロセスとは、SS(Service Strategy)の段階*1で活用されるプロセスです。やることはその名の通り「そのサービスの需要」つまりニーズを把握し、後続であるSD段階のプロセス、キャパシティ管理や可用性管理、サービスレベル管理へ引き継ぐ。これがこのプロセスの役割です。*2ここで議論される需要のコントロールの方法として、例えば最近JRでも導入されたオフピーク定期券*3。実はこれ、英国ではかなり昔から導入されている需要コントロールの方法です。かなり昔ですが、英国出張時に電車の運賃説明で仰天しました。

このように需要を把握しコントロールすることを責務とするプロセスが需要管理です。では、なぜそれがITIL4では、「事業分析」に変わったのか。

それを理解するためには、下記の違いを理解する必要があります。

ITILv3の「需要管理プロセス」は、「管理対象となるサービスの需要を管理する」ことに焦点を当てていました。つまり、管理対象となるサービス提供組織の内側を管理するという考え方です。

例えるなら、内部(社内向け)サービスであれば、「SAPの運用保守サービス」とか、「PCキッティングサービス」とか、何某かのサービスとして完結する塊を定義することで管理対象が見えてくる。これが、外部(エンドユーザ向け)サービスであれば、旅先でとまる旅館・ホテルの食事もサービス*4です。

ITIL4の「事業分析プラクティス」は、「分析対象となる事業を分析する」になります。なので幅広です。ITILv3の様に個別のサービスに対する管理ではなく、そもそもの事業を分析することに主眼が置かれています。

先ほどと同じ事例を使って解説すると以下の通りです。

「SAPの運用保守サービス」を担当するチームのチーム分析。仮にSAP運用保守チームがいるのだとすると、そのチームの目的、当初決めていたKPI、KGIに対する達成状況、その差分の分析が含まれます。さらに、監査の結果（監査報告書）もそのインプットに使います。

これの意味するところ、簡単に言えば、そのチームの決算報告と翌年度の対応を検討するということです。信じられますか？それやれって書いてあるんです。サービスではなく、事業の分析を行うので、当然こうなります。要するに内部サービスも「事業」として捉え直すんです。

逆に社外サービスの例はわかりやすいですよね。先ほどの旅館に例えると、次の２パターンの考え方ができます。

• 料理長率いる食事を提供する「調理部の事業」の分析
• 1泊2食付きのパッケージ化された商品としての事業の分析

このどちらが正しいか。それは、この旅館という事業体の意思決定に基づきます。ただ、あくまで個人的な感覚ですが、どーせメッシュ的な分析をしたくなるに決まっているので、どちらでも使える様に指標が取れる様にすることを推奨しますけど。例えば、下記みたいな。

旅館における事業分析のイメージ

つまり、事業分析になったことにより、個別のサービスの分析のみならずサービスを提供または複数のサービスを組み合わせた事業そのものの分析を行い、ニーズを分析するというかなり範囲が拡大したということです。これが、名前を変えた理由です。

デザインコーディネーション→「サービスデザイン」(SMプラクティス)

続きましては、デザインコーディネーション。これは、ITILv3 2011 editionで追加されたものですので、馴染みのない人もいるかもしれません。しかし、大したこと書いてないんですよね、、、これ。「SD段階の全ての行動・プロセス・リソースを調整する」としか書かれていませんし。。それに対して、今回サービスデザインは、どちらかというとSSの段階の各プロセスの一部を包含したと考えています。例として、先ほどご説明した事業分析を思い出してください。

(前略)

• 料理長率いる食事を提供する「調理部の事業」の分析
• 1泊2食付きのパッケージ化された商品としての事業の分析

このどちらが正しいか。それは、この旅館という事業体の意思決定に基づきます。(後略)

この例のうち、下段、「商品としての事業の分析」。この商品(パッケージ)が生まれるためには、「背景・目的・目標*5」があり「どの程度のROIを狙い（たい）」という金銭的な目標があり、スケジュールがあり、関係者（ステークホルダー）があり・・・・と色々定義するべきことがあります。このような施策定義書*6を定めることを確実にする。ここ重要で、定めることを確実にするので、作ることに責任があるわけではないです。

要するに、ITIL4におけるサービスマネジメントプラクティスで起こりうる成果物管理を行うのがこのプラクティスです。なので、各プラクティスが定義し作るアウトプットをめちゃくちゃチェックします。文字数の都合で割愛しますが、興味のある方は、ぜひ、本記事を作成する上で参考にした下記書籍*7をぜひお買い求めください。(私執筆者じゃありませんけど。)

要するに、ITILv3でSSにあった実務的な活動をまるっと定義し、実務者に対してそれぞれのサービスをコーディネートする役割を担うのが、このサービスデザインの本質です。名前を変えたのは、サービスをコーディネートするだけではなく、サービスの企画から検討し、サービスをコーディネートするといういわば事業計画のガイドを提供することになった。それゆえに、「サービスデザイン」というもう少し含意のある定義に変えたのだと考えられます。

キャパシティ管理→「キャパシティおよびパフォーマンス管理」(SMプラクティス)

続きまして、「キャパシティ及びパフォーマンス管理」。私としては、この変更は「やっとか」という思いと「いまさら？」という思いがあります。というのも、そもそもITILv3のキャパシティ管理の中でも「パフォーマンスを管理してあるべき姿に持っていくようにしてね」と書いてあります。*8つまり、元々パフォーマンスについても管理することになっている。ではなぜ今回プラクティス名に引き上げられたか。

想像なのですが「管理するべきがコンポーネントレベルのパフォーマンスではないから」だと考えています。どういうことか。

想像してみてください。よくあるSLAの月次報告として、オールグリーンなんだけど、ユーザから不満の声が上がるという事例。これは、コンポーネント単位でSLAは満たしているものの、一気通貫、つまりユーザからシステムまでのE2Eで見た場合にユーザの期待値を満たしていないからおきます。この事例、スイカSLA（見た目は緑なんだけど、割ってみたら中身は真っ赤）として知られています。これは果たしてユーザの満足につながっているか。少なくとも内部サービスだとよく聞きます。しかし、外部サービスだとまずやっちゃダメなパターンですねよ。

コンポーネント、またはCI単位のパフォーマンスを管理するのではなく、「サービス」のまたは「事業」としてのパフォーマンスを管理することで本質的なユーザ体験、ユーザの満足度に寄り添う。それを意図して、パフォーマンスをプラクティスのタイトルに格上げした。そう考えています。要するにスイカSLAの撲滅のために格上げされた。そう認識しています。

変更管理→「変更実現」(SMプラクティス)

これ、おそらく日本語訳を考えた人はものすごく苦しんだと思うんですが、この名前の変更は、ITIL4最大の成果の一つだと明言できます。原文で見てみます。

ITILv3→Change Management（変更　管理）

ITIL4 →Change Enablement（変更　可能な状態になる）

です。つまり、この変更実現は、「変更(することを)実現(できる状態を作る)」プラクティスです。

ですので、やることは今までの変更管理プロセスと特には変わりませんが、考え方は大きく変わりました。変更を管理するのではなく、「変更することをいつでもできる状態を作ること」に注目したプラクティスへと変わったのです。

なぜこの変化を生んだのか。それは、AgileやDevOpsなどの頻繁かつボリュームの多い変更に備えた柔軟な変更管理基準の作るためです。事業という形を成す以上、法規制や内規に対応しガバナンスを満たす状況を作るのは当然です。では、どやってそれら規制とビジネスを両立させるのか？その方向性に舵を切った。これは大変重要なことです。

イベント管理→「モニタリングおよびイベント管理」(SMプラクティス)

この名称変更は、正直言って、順当な進化だと考えています。ITILv3のイベント管理は、「イベント(アラート)は定義されていて、それを適切に処理する」というインシデントな状態をいかに速やかに収束させるかという点に焦点を当てているプロセスでした。

それに対し、ITIL4の「モニタリング及びイベント管理」は、「イベントの定義」「イベント発生時の処理」「イベントの分析」を定義しています。これは、従前のWF型開発、重厚長大な運用であろうが、Agileのような不安定の安定を追求するような開発手法であろうが有効です。順当な名称変更であり内容の充実だと考えます。

要求実現→「サービス要求管理」(SMプラクティス)

これ、正直申し上げて、明確な理由がわかりませんでした。そもそもITILv3において、サービス要求(Service Request)って呼んでました。本音を言うと、差はない。と考えています。

でも、それでは芸がないので、ITILv3に対して、ITIL4ではこのサービス要求管理は何か変化はないかと見比べてみました。

大きい変化ではないのですが、SR化されたこれら超定型作業を更に改善するまたは自動化を検討するなど、より省人化、省力化するためのプロセスが定義されていることぐらいでしょうか……。対して面白くなくてすみません。

ITサービス継続性管理→「サービス継続性管理」(SMプラクティス)

これは、単純に考えると頭の「IT」が消えただけに見えます……。そうなんです。消えただけなんです。消えただけなのですが、この変化は実はITIL4が事業計画に踏み込んだ証左でもあります。どう言うことか。先ほどの旅館の例で考えます。

サービス継続計画として、いくつかの前提は置くものの、まずはお客様と従業員の安全の確保。そして宿泊業である以上、一定期間(72時間は自力でどうにかしてねってのが今の日本の前提だった認識)はサービス提供者として一定の安全を担保する必要があります。従って、下記のような基本方針を定めます。

旅館におけるサービス継続計画

サービス毎、何をいつから継続しなければいけないかを記載していますよね。これと一緒なのです。このサービス毎これらを継続させるために、「宿泊部」「調理部」「料飲部」（ITにおいては各チーム）など各旅館の組織が考えるのです。宿泊部は、卓球について考えた際、火災が発生したのなら、卓球はもう忘れていいのです。そして卓球に関係ないであろう「料飲部」「調理部」はそもそもサービスのことを考えない。そう言うガイドとしてこの計画を見る。

逆に調理部は、火災が発生したとしても食事を提供する（しかもサービスレベルは変えずに）ので、6時間以内に何をどのように整えるべきか、その時必要なファシリティは何かを検討し、サービスマネージャである私に要求しなければいけません。（言うなれば、BackupDCを作るとかそう言う投資計画になるわけです）

お気づきでしょうか？要するにITILv3のITサービス継続性管理は、この図で言う「宿泊部」「調理部」「料飲部」毎のものに過ぎないのです。しかし、ITIL4のサービス継続性管理は、それら各IT組織が作成する各ITサービス継続性管理計画の上位概念になった。ITとビジネスは一体化した。と言うことです。

よって、この変化もITILv3から見るととても大きい変更と言わざるを得ません。ITIL4は高度にデジタル化するビジネスの場において、ビジネスプロセスを定義したものなのだと考えられます。

まとめ

この長編の第3回で下記のように記載しました。

ITIL4はITを使ったビジネスマネジメントのフレームワークとして大きく姿を変えた。

この通りだと思います。名前が変わった理由は細かく確認してきました。しかし背景はこれに尽きるのだと思います。今やITを何も使わずにビジネスが進むなんてことはありません。よって持って、ITIL4は、ITを使ったビジネスマネジメントのフレームワークとして世界中のナレッジを再度定義し直した。そう考えます。

そう考えると、やはり、ITILv3を適用した方がいい組織はあると思う。具体的には、ITがビジネスに関与しない枠組みで管理されてきてしまった企業。

そして、実は中小企業こそ、ITIL4に取り組むべきなのではないかなと思うのです。なぜならビジネスプロセスに関与するアクターがすっごく少ない。少ない会社であればあるほど、適用は速やかだし、特にビジネスが多方面に渡っているわけではない。つまり、一つのビジネスまたは少数のビジネスなので、ITとビジネスを一体化させるときの投資はすごく少なく済む。100人以下の企業において、これらのプラクティスを適用させると劇的に働き方改革になるんじゃないかなと思います。まぁ想像ではあるのですが。。

*1:ITILv3は、SS、SD、ST、SOのそれぞれを段階と表現します。

*2:ITILv3 Foundation、及びSOA(Service Offerings and Agreements capability)のホルダーの方は、PBA(Pattern of Business Activity)という言葉に聞き覚えはないでしょうか？それを作るのが、このプロセスの役割だったりします。（実際に作った事例って聞いたことないですけどね）

*3:https://www.jreast.co.jp/offpeak_teiki/

*4:これが1泊2食付き、温泉入れます、部屋はこれ、というようなパッケージになると、SP（サービスパッケージ）になります。SD段階のサービスカタログ管理プロセスに出てくるアレです。

*5:定性的な目標です。このサービスによりどの様な価値を生み出したい。どの様な状況になっていたいかを定義しています。金銭的な目標は別です

*6:このような定義書はリーンキャンバスで有名です。この手のフレームワークは改訂版も含めたくさん出回っており、ググることをお勧めします

*7:

【ITIL4公認】ITIL 4の基本 図解と実践

*8:サービスキャパシティ管理サブプロセスで明言されている