どうも、こんにちは。
さて、長文に渡るITIL4の深掘り、第4回。今回は、ITILv3から見て統合、または分解されたプラクティス群について、その内容を詳細に確認したいなと思います。
なお、今回は推敲に推敲を重ねても5,000字を超える自信があるので、以下、それぞれに目次だてしてご案内します。
これ以降、この記事について、「プロセス」(ボールド、及びイタリック)表記になっているものは、ITILv3のことを指しています。つまり、プロセスは、固有名詞として扱います。一般名詞としてのプロセスとは意味が違う点をご了承ください。
- 分割し統合されたプロセス①リリース管理及び展開管理プロセス
- 分割された（？）プロセス②サービス資産管理及び構成管理プロセス
- 分割し統合された機能③技術管理機能・アプリケーション管理機能・IT運用管理機能
- 分割し統合されたプロセス④サービスレベル管理プロセス
- 終わりに
分割し統合されたプロセス①リリース管理及び展開管理プロセス
分割先は次の通りです。
- サービスマネジメントプラクティス*1の「リリース管理」(また、移行の計画立案及び支援プロセスの一部も吸収しています。)
- 技術的マネジメントプラクティス*2の「展開管理」
リリース管理及び展開管理プロセスは「許可された変更をサービスの意図しない中断なく（つまり意図、または計画された中断は含まない）、ユーザの混乱も（なるべく）なく作業を遂行し、想定していた変更の目的を実現するためのプロセス」ということです。
その前提となっているのは、リリースや展開が教科書的に次の理解になっているためです。
リリース＝「一緒に構築され、テストされ、展開されるITサービスに対する一つまたは複数の変更」*3。つまり、「変更」そのものを指すものです。
展開＝「新規または変更されたハードウェア、ソフトウェア、文書、プロセスなどを稼働環境へ移行することを責務とする活動」*4。つまり、「作業」です。
それに対して、ITIL4ではリリースは、「使えるようになりました」になります。つまり、「状況」を指しています。エンドユーザに対して価値を提供し始める（利用できる）という意味合いに変わったということです。サービスの生産と価値提供が開始できる状態と考えてください。
展開は、あんまり変わってないです。「新規または変更されたサービスコンポーネントを稼働環境へ移行することを責務とする活動」です。このサービスコンポーネントが今までのCIの拡張なので、対象が増えた*5、ということはあるのですが、「活動」に焦点を当てているという点では、実はあまり差はない。この言葉の定義の変化により、分割されたのです。
正確には、分割できるようになった、が正しいと思います。
今までの変更とはどのようなものでしたでしょうか？新しい製品やサービスをX月X日に開始します！と銘打ったプレスリリースを出し、サービス開始の前日は、その準備のために徹夜。失敗したらプレスリリースが嘘になる、株主から責められると戦々恐々とするCEOやCIOの圧を感じながら、変更・リリース作業を実施するIT部員。無事に新サービス稼働を見届け、朝日を見つめ、感動のフィナーレ。
いや、馬鹿かと。徹夜で作業がそもそも人間性の無視です。そして、適切なプレッシャーは大切ですが、CEOが気にするべきは、そのサービスがどの程度の価値をユーザに届けられるかがポイントであり、そのサービスが使えるようになるかどうかでプレッシャーを感じるのはCEOとして不適切なプレッシャーです。
考えてみてください。新製品を発売するのは、この世に新しい価値を届けるために発売するのであり、その新製品の製造ラインが稼働しているかどうかは関係ありません。つまり、「新製品を作ることができること」（展開管理）と「新製品がユーザに対して価値を生むことが準備できている状況」（リリース管理）は別物なのです。
今までのWF型の開発では、これらのが一発展開だったために合体していました。
しかし、技術が進み*6、ユーザが使える状況（リリース管理）と、変更を実施する作業（展開管理）を分けて管理できるようになった。ゆえに、分割できるようになったのです。
分割された（？）プロセス②サービス資産管理及び構成管理プロセス
分割先は、以下の通りです。
- サービスマネジメントプラクティスの「サービス構成管理」
- サービスマネジメントプラクティスの「IT資産管理」
サービス資産管理及び構成管理プロセスは、「ITサービスを構成する要素（CI）を識別し、つながりを把握し、最新化する」ことを管理するプロセスです。一連の作業も管理プロセスも扱います。一般的には、構成管理プロセスと呼ばれることが多いように思います。それが、ITIL4では分割されました。
なぜか。これを理解するために、この２つよくみてみましょう。何を管理するのでしょうか？「サービスの構成」と「IT資産」ですね。
では、サービスの構成とは何か？簡単に言えば、ITILv3で行っていた「構成管理」です。CMDBを作ることとそのCIの最新化、及びCI同士の繋がりを管理するプロセスのことを指しています。なので、「サービス構成管理」は、ITILv3でよく言われていた「構成管理」のことを指しています。
じゃあ、次。IT資産の何を管理するんだよって話です。すごく乱暴にいうと、全部です。でもこれだけじゃ本当に乱暴で訳分かりませんよね。
なので、ちょっと一般的な製造業で例えましょう。
通常、何か製品を作成するとき、その製品の製造工場があり、その工場に生産ラインがあり、原材料があり、そこで働く人がいますよね。実際に製造ラインで働く人もいれば、いわゆる事務所で働く管理部門の人もいます。
サービス構成管理は、これらのうち、製造ラインそのものやその製造ラインで働く人、さらにその製造ラインの保守点検作業、原材料の管理が含まれます。
今まではこういったことに焦点を当て、CIの管理をしてきました。これこそが構成管理です。
では、問います。製造ラインの更改計画、保守点検のライフサイクル・機器メーカーとの保守契約更新、工場そのものの保守点検。管理部門の人件費。これって誰がどうやって管理するんでしょうね？はい、そうです。これらを管理するのが、「IT資産管理」です。ITILv3では、サービスライフサイクルの管理という文脈においてどこと明言されていなかったこれら間隙に落ちた業務が、「ITサービスライフサイクル」という概念がなくなったおかげで明文化された。これがIT資産管理なのです。計画を立て予算化をするところから、最後利用を停止し廃棄するところまでを管理するプラクティス。それこそがIT資産管理。
さて、具体例でご理解いただいたところで、そう捉えるとIT資産管理は何を行うものか改めて確認してみましょう。例えば保守契約の継続、更改。使っていないライセンスを棚卸し、解約した直後に使うことになった。そんなことはありませんか？そういったものに対して組織として方針を示し、適切に管理する。そういったことを行うプラクティスがIT資産管理なのです。サービスを生産することに直接的に関与するものではありませんが、これなしではサービスの生産に多大な影響を及ぼしますよね。というか、手が止まる。そういった緊急ではないが重要なことをちゃんと管理するために独立させた、それがIT資産管理プラクティスなのです。
分割し統合された機能③技術管理機能・アプリケーション管理機能・IT運用管理機能
ここにきて突然機能という言葉を使いましたが、ITILv3は機能とプロセスの集合体なので、お許しください。ITILv3のOSAを勉強された方には釈迦に説法ですが、4つ機能（原文:function）がありますよね。「サービスデスク」「IT運用管理」「技術管理」「アプリケーション管理」。これら実態としてはプロセスではなく組織を指す言葉です。実はITIL4では、サービスデスクを除いた3機能が全てここでミックスされました。考えてみればそれはそうです。4Dの一つとしてPeople&Organizationが定義されたため、各機能はそれぞれのプラクティスの中に散らばることは自然です。
- 技術管理は、「アーキテクチャ管理」（一般的マネジメントプラクティス）と「インフラストラクチャ及びプラットフォーム管理」（技術的マネジメントプラクティス）へ
- アプリケーション管理は、「ソフトウェア開発及び管理」（技術的マネジメントプラクティス）と「インフラストラクチャ及びプラットフォーム管理」（技術的マネジメントプラクティス）へ
- IT運用管理は、「インフラストラクチャ及びプラットフォーム管理」（技術的マネジメントプラクティス）へ
大きくは分割・統合されました。
理由はある意味で語ってしまいましたが、要するに、4Dの文脈で考えた際、組織の単位でまとめて表現する必要がなくなったんですね。People&Organization(人材と組織)として定義されたので。
とはいえ、それで終わってはなんのためにこのブログを書いているのかわからなくなるのでもう少し解説します。
技術管理組織の役割を主に引き継いだ「インフラストラクチャ及びプラットフォーム管理」はどんな技術を使ってEA*7を設計するかを決める「技術企画」、実際のEAの構築やインフラストラクチャの構築となる「製品開発」、インフラ運用を行う「技術運用」（ここは、IT運用管理の領分ですが）の3つが主な実施事項です。今までのいわゆるインフラ企画業務・構築運用管理業務・実運用業務の3つ。
なお、先々の、つまり将来的なEAロードマップの策定は、実は「アーキテクチャ管理」に移動しています。つまり、「インフラストラクチャ及びプラットフォーム管理」は、今とちょっと先のEAにフォーカスした実際の設計ということになります。ブループリント・ロードマップの策定とそのコントロールは、「アークテクチャ管理」です。
アプリケーション管理組織の役割を主に引き継いだのが「ソフトウェア開発及び管理」。
ここで注目するべきは、このプラクティス実はものすんごく概要しか書いてません。ここをものにするためには、アプリケーション開発の様々な手法をリファレンスしたほうが早いということだと思います。要するに、決められない（笑）。スクラム、XP、TDDなど開発方法は星の数ほどあり、一つ一つ良い面悪い面がある。どれがその現場にフィットするか、もっというとその現場を作り上げた企業文化によっても変わる。そのためだと思われます。
ただ、あるべきアーキテクチャの基本方針はあると思いますので、それはぜひ実務者の方から教えて欲しいです。いわゆるDevOpsや（狭義の）SREのフレームワークがこちらで学べると思います。
分割し統合されたプロセス④サービスレベル管理プロセス
分割先は以下の通りです。
- サービスマネジメントプラクティスの「サービスレベル管理」
- 一般的マネジメントプラクティスの「測定及び報告」
これは語らねばなりません。実は、このサービスレベル管理プロセスが「サービスレベル管理」と「測定及び報告」に別れたのは、これは管理上の問題だけではないのです。
サービスレベル管理プラクティスは、プラクティスに焦点を当てています。とんちみたいですね。（笑）つまり、SLAを定義する方法とそのSLAを計測する方法に関して焦点を当てています。
では、SLAはSLA単体で決められますか？答えを先に書けばそんなことはありません。CSFやKGIが決まって初めてSLAが決まりますね。ITILv3ではそこもまとめてサービスレベル管理プロセスに収めていましたが、ITIL4では、この「測定及び報告」に含められました。運用の現場では、どうしてもSLAにフォーカスしてしまう。それを否定せず、上位概念として切り出し、「測定及び報告」に全体的な俯瞰図として定義するように変えたのです。
そして、それらを報告・検討する会議体の定義などは、サービスレベル管理に含めた。WHYとWHATは「測定及び報告」にHOWは「サービスレベル管理」そう分割させたのです。これは、かなり理にかなっています。
そして、「測定及び報告」が一般的マネジメントプラクティス、つまりサービスの定義、およびサービスの生産性を計り．サービスの方向性を決定するプラクティスとして定義されていることとも関係してきます。そもそもCSFやKGIなどは、何を持って成功と成すかの定義なのでITに限らずビジネスの場一般で通用する指標ですからね。
終わりに
さて、やはり5,000文字を超えてしまいましたが、ITILv3からITIL4に変わったことによってプラクティスの統合と分割がなぜ起きたのか、ご理解頂けましたでしょうか？
これにより、ITILv3で進むべき現場と、ITIL4に取り組みたいとおもうビジネスの現場、それぞれに何かヒントとなれば幸いです。
次回最終回。「名前が変わったプラクティスとその理由」に関する考察をお待ちいただければ幸いです。（まだ一行も書いてない）
