ITIL V3 vs CMMI-SVC #2 比較してみた

ITIL V3を学習し、ITIL V3 Foundation試験を受けた。もともと、サービス開発においてもサービス運用/管理を考慮しなければならないが、ITIL V3が適切なのか、CMMI-SVCが適切なのかという疑問がスタート地点だったのだ。これまでの記事を参照のこと。


ITIL V3 Foundation #1 試験申込んだ
ITIL V3 Foundation #2 受験した

ITIL V3 vs CMMI-SVC #1 どちらを学習すべきか?
ITIL V3 vs CMMI-SVC #2 比較してみた

ITIL V3 Foundationについては、もうすぐ『ITサービスマネジメント教科書 ITIL V3 ファンデーション』が発売されるという情報がある。かなり有力な本になりそうだ。受験を急がないのであれば、7/16の発売を待ってからの方がいいだろう。

さて、本題だ。CMMI-SVC V1.2とITIL V3の対応関係を少し調査してみた。CMMI-SVCITIL V3のどちらを適用すればいいのか、どちらを学習すればいいのかが悩まれるところだ。包含関係や網羅性はどうなっているのか。細かい部分まではまだ比較できていないが、それぞれどんな体系なのかをざっくり探ってみた。

CMMI-SVCの体系

CMMI-SVCは、サービスプロバイダのアクティビティにフォーカスして、16の共通プロセス領域(CMF:CMMI Model Foundationという)、7つのサービス固有プロセス領域(※SAMを含めて8つ)、合計24のプロセス領域で構成されている。7つのサービス固有プロセス領域は、(1)キャパシティと可用性の管理、(2)サービス継続性、(3)サービスデリバリ、(4)インシデントの解決と予防、(5)サービス移行、(6)サービスシステム開発、(7)戦略的サービス管理だ。かなり、ITILのプロセスと似通っていることは分かる。

CMMI-SVCの記述の中では、ITILについては「CMMI-SVCは、他のCMMI(CMMI-DEVとCMMI-ACQ)、他のサービス指向の標準やモデル(ITIL、ISO/IEC 20000、CobiT、ITSCMM)のコンセプトとプラクティスに基づいていて、ITIL V3については、Service Improvement、Service Design、Service Operation、Service Strategy、Service Transitionを参照している」という部分があるのみだ。また、解説文によれば、CMMI-SVCには「ITILのベストプラクティスを小さな集合に要約していて、ITILのベストプラクティスをCMMIのモデル要素にマップでき、ITILのコンサルにおいては追加的な実装情報として利用できる」というような謙虚な姿勢もあるようだ。

CMMI-SVC V1.2で24のプロセス領域を見る前に、CMMIは共通ゴールとプラクティス、固有ゴールとプラクティスに分けられていること、またプロセス領域はいくつかのカテゴリに分類されていることを確認しておく。共通ゴールとプラクティスは、CMMI-DEV、CMMI-ACQとも共通する部分だ。取り上げたいのはサービス固有のゴールとプラクティスの方なので、共通ゴールの方には深くは触れない。プロセス領域は以下のカテゴリに分類されている。


■プロセス管理 (Process Management)
■プロジェクト管理 (ProjectManagement)
■支援 (Support)
■サービス確立とデリバリ (Service Establishment and Delivery)
■エンジニアリング (Engineering)
■調達 (Acquisition)
「サービス確立とデリバリ」がCMMI-SVC固有のカテゴリだ。ちなみに「エンジニアリング」はCMMI-DEV固有、「調達」はCMMI-ACQ固有のカテゴリになる。プロセス管理、プロジェクト管理、支援は、CMMI-DEV、CMMI-ACQ、CMMI-SVCの3つに共通している。

CMMI-SVC V1.2で24のプロセス領域は、以下のような構成になる。


CMMI-SVC
|
+-- 共通ゴールとプラクティス
| |
| +-- ■GG1: 固有ゴールの達成
| +-- ■GG2: 管理されたプロセスの制度化
| +-- ■GG3: 定義されたプロセスの制度化
| +-- ■GG4: 定量的に管理されたプロセスの制度化
| +-- ■GG5: 最適化されたプロセスの制度化
|
+-- 固有ゴールとプラクティス(24のプロセス領域)
|
+-- 16の共通プロセス領域
| |
| +-- プロセス管理
| | +-- ■Organizational Process Definition (OPD)[3]
| | +-- ■Organizational Process Focus(OPF)[3]
| | +-- ■Organizational Training (OT)[3]
| | +-- ■Organizational Process Performance (OPP)[4]
| | +-- ■Organizational Innovation and Deployment (OID)[5]
| |
| +-- プロジェクト管理
| | +-- ■Project Monitoring and Control(PMC)[2]
| | +-- ■Project Planning (PP)[2]
| | +-- ■Requirements Management (REQM)[2]
| | +-- ■Integrated Project Management (IPM)[3]
| | +-- ■Risk Management (RSKM)[3]
| | +-- ■Quantitative Project Management (QPM)[4]
| |
| +-- 支援
| +-- ■Process and Product Quality Assurance (PPQA)[2]
| +-- ■Configuration Management (CM)[2]
| +-- ■Measurement and Analysis (MA)[2]
| +-- ■Decision Analysis and Resolution (DAR)[3]
| +-- ■Causal Analysis and Resolution (CAR)[5]
|
+-- 7つのサービス固有プロセス領域 + SAM
|
+-- プロジェクト管理
| +-- ■(1)Capacity and Availability Management (CAM)[3]
| +-- ■(2)Service Continuity (SCON)[3]
| +-- ■Supplier Agreement Management (SAM)[2] (※CMMI-DEVと共通)
|
+-- サービス確立とデリバリ
+-- ■(3)Service Delivery (SD)[2]
+-- ■(4)Incident Resolution and Prevention (IRP)[3]
+-- ■(5)Service System Transition (SST)[3]
+-- ■(6)Service System Development (SSD)[3] (※追加オプション)
+-- ■(7)Strategic Service Management (STSM)[3]
サービスシステム開発(SSD)は、CMMI-SVCでは追加オプションとなっている。サービスシステムやコンポーネントを分析、設計、構築、統合、検証、妥当性確認することが目的であり、新規サービス開発にも、既存サービスの変更にも適用される。オプションになっている理由は、CMMI-DEVそのものと重複するからだ。シンプルなサービスであればSSDに沿って開発すればよい。規模が大きい場合はCMMI-DEVを適用することになるが、その場合でも、人とプロセスをサービス開発に特化させて記述されたSSDをガイドとして参照すべきである、と記述されている。

共通プロセスの中の構成管理(CM)や原因分析(CAR)は、ITILの構成管理と問題管理などに直接的に結びつく。

サプライヤ合意管理(SAM)は、サプライヤからの製品やサービスの調達を管理することが目的だ。CMMI-ACQの中心テーマだが、CMMI-SVCでもCMMI-DEVでも語られている。SAMについては16の共通プロセス領域に含めないようなので、一応個々の体系で固有のものとして挙げておく。SAMは扱いが正確に理解できていない。CMMI-SVCCMMI-DEVで共通であるということのようだ。リリースされた時期が異なるので、2つがそれぞれ別物として存在しているように見える。アプレイザルにおいてもオプション扱いのようである。ITIL V3では「サプライヤ管理」(V2では請負契約)で取り上げられている。

ITIL V3の体系

ITILで語られるプロセスや機能は、以下のような体系になる。ちなみにITILでは「機能」とは能力や働きそのものではなく、それらの機能を果たす組織を含めて「機能」と表現しているようだ。サービスデスクも機能であり、アプリケーション管理も機能と言っている。機能組織(Function Team)と言っていいだろう。


ITIL V3
|
+--【1】サービス戦略(Service Strategy)
| |
| +-- ■サービス戦略策定
| +-- ■財務管理 (※V2でのITサービス財務管理)
| +-- ■需要管理
| +-- ■サービスポートフォリオ管理
|
+--【2】サービス設計(Service Design)
| |
| +-- ■サービスレベル管理(V2)
| +-- ■サービスカタログ管理
| +-- ■キャパシティ管理(V2)
| +-- ■可用性管理(V2)
| +-- ■ITサービス継続性管理(V2)
| +-- ■情報セキュリティ管理
| +-- ■サプライヤ管理 (※V2でのUCの扱い)
|
+--【3】サービス移行(Service Transition)
| |
| +-- ■変更管理(V2)
| +-- ■サービス資産/構成管理(V2)
| +-- ■リリース/展開管理(V2)
|
+--【4】サービス運用(Service Operation)
| |
| +-- ■イベント管理
| +-- ■要求実現 (※V2でのサービス要求の扱い)
| +-- ■インシデント管理(V2)
| +-- ■問題管理(V2)
| +-- ■アクセス管理
|
+--【5】継続的サービス改善(Continual Service Improvement)
| |
| +-- 7つのステップ
| +-- (1)測定するべきものの定義
| +-- (2)測定できるものの定義
| +-- (3)データの収集
| +-- (4)データの処理
| +-- (5)データの分析
| +-- (6)情報の提示と利用
| +-- (7)是正処置の実施
|
+-- 組織と技術
|
+-- ■機能(Function)
| +-- ■サービスデスク(V2)
| +-- ■技術管理
| +-- ■アプリケーション管理
| +-- ■IT運用管理
| +-- ■運用コントロール
| +-- ■施設管理
|
+-- ■役割(Role)
+-- ■技術
個々の対照は後日としたい。大体、字面だけ眺めても対応関係は推測できるだろう。