ITIL V3 vs CMMI-SVC #3 プロセスの比較

CMMI ITIL

これまでシステム開発者の拠り所としてSWEBOK、PMBOK、CMMI-DEV、SLCP共通フレームをベースにしてきたが、最近では、SOA開発といっていいのか単にサービス開発といっていいのかははっきりしないが、人系の運用を含めたサービス価値や投資対効果を特に重要視しなければならなくなった。ITILやCMMI-SVCの存在が無視できないのだ。私を含めて開発者は明らかに運用や保守といったプロセスを軽視してきたように思う。関心事は上流へ上流へと進み、ビジネス価値やビジネスゴールへの興味からBABOKのようなビジネス分析や要求開発の方へと傾倒してきたのだ。
それではいけないだろう。では、ITILとCMMI-SVCはどちらを適用・学習すればいいのだ。どこが違うのだ。
両者のモデルというか、そこで提示される構造化されたフレームワークは、非常によく似ているのだ。以前はハードウェアを考慮していなかったがITILもCMMIも包含するようになったし、ライフサイクルを考慮していなかったITILもV3で見直された。両者は徐々に接近してきたのだ。体系的な枠組みに大差はなく、相互に大して欠落はないように見える。だから余計に厄介なのだ。
では、何が異なるのか。視点とフォーカスしている部分が異なるとしか言えない。CMMIは、プロセスの成熟度を規定しようとするが、ITILは遠慮しているのか、そこにはあまり関心を示していない。キャパシティ、サービスレベル管理、リリース管理など本番環境へサービスをリリースする部分のプロセスにフォーカスしてマネージメント視点でベストプラクティスを掲げるだけなのだ。

少し詳細にプロセス領域を比較してみた。とはいえ、概要の字面程度の比較ではある。CMMI-SVCの固有プロセス領域が、ITIL V3でどのように扱われているかを見てみる。

(1)キャパシティと可用性の管理 (CAM:Capacity and Availability Management)

キャパシティと可用性の管理(CAM)は、サービス要求をサポートするために、サービスシステムのパフォーマンスを効果的なものにし、またリソースが効果的に供給され利用されるようにすることが目的だ。

(1)キャパシティと可用性管理の準備キャパシティと可用性管理のための戦略を策定し、サービスシステムに対する測定方法と分析技法を選定し、サービスシステムの可視化を行う。
(2)キャパシティと可用性の監視と分析閾値に対するキャパシティを監視／分析し、ターゲットに対する可用性を監視／分析し、それらのデータを利害関係者に報告する。
ITILでは、当然「キャパシティ管理」と「可用性管理」に相当する。なぜ１つにまとめられているか。キャパシティと可用性は密接であり、監視・分析・報告の観点では実際的に区別がないからだろうか。ITILの中でも密接であることは強調されているがあえて分離している。組織やロールが異なるという見解からだろう。

(2)サービス継続性 (SCON:Service Continuity)

サービス継続性(SCON)は、通常運用での重大な障害に対して、その間またその後もサービスを継続できるように計画を確立することが目的だ。

(1)主要サービス要素の識別サービス継続性を確保するために実施しなければならない主要な機能と主要なリソースを識別し、優先度を付与する。
(2)サービス継続性の準備主要な機能の実施を再開するために組織が可能なサービス継続性計画を策定し、サービス継続性のためのトレーニングを確立して供給・評価する。
(3)サービス継続性計画の検証と妥当性確認サービス継続性計画の検証と妥当性確認のための準備をし、実施し、検証と妥当性確認作業の結果を分析する。
ITILでは、当然「ITサービス継続性管理」に相当する。

(3)サービスデリバリ (SD:Service Delivery)

サービスデリバリ(SD)は、サービス合意に従ってサービスを供給することが目的だ。

(1)サービス合意の確立期待する新しいサービス合意の準備のために既存のサービス合意とサービスデータを分析し、サービス合意を確立／維持する。
(2)サービスデリバリの準備サービスのデリバリ方法とサービスシステム運用の方法を確立し、サービスシステムの準備を開始し、要求を処理／追跡するための要求管理システム(RMS)を準備する。
(3)サービスデリバリの実施サービス合意に従ってサービス要求を受けて処理し、サービスデリバリが継続できるようにサービスシステムを運用／維持する。
ITILでの「サービスレベル管理」と「要求実現」と「IT運用管理」が対応する。需要管理やサービスカタログ管理も含んでいる。イベント管理、アクセス管理もここに含まれることになるだろう。

(4)インシデントの解決と予防 (IRP:Incident Resolution and Prevention)

インシデントの解決と予防(IRP)は、サービスインシデントの適切な解決と予防をタイムリーで効果的なものにすることが目的だ。

(1)インシデントの解決と予防の準備インシデントの解決手順と予防方法を確立し、インシデントを処理・追跡するためのインシデント管理システム(IMS)を準備する。
(2)インシデントの識別・コントロール・調査インシデントを識別し、記録し、分析し、ワークアラウンド(回避策)を適用し、原因を調査し、適宜エスカレーションし、インシデントのステータスを管理する。
(3)選ばれたインシデントの調査方法の定義インシデントの根源的原因を分析し、それら原因に宛がうアクションを計画し、ワークアラウンドを確立／維持する。
ITILでの「インシデント管理」と「問題管理」が相当する。ちなみにCMMI-SVCではインシデントと問題を区別していないようで、「選ばれたインシデント(Selected Incident)」と呼んでいるものがITILでの「問題」に相当するようだ。

もともとITILのいう「根本原因」の定義には違和感がある。「問題はインシデントを引き起こす未知の根本原因」だそうだ。問題はどうみても原因というより、まだ原因もはっきりしていないような事象だと思える。ITILでは、問題となっている事象とその原因を包含して「問題」という概念で捉えていることになる。問題の特化したものが「エラー」であり、原因に対する回避策が備わっている。エラーは、問題となっている事象、その原因、原因に対する回避策の3つで構成されるといえるのだ。ここで注意すべきは、回避策であって「根本的な対策」というべきものではない。回避できればいいのだ。開発側のプロセス改善の観点だと、問題を分析して表層的な原因を識別して解決するだけでなく、さらに根源的な原因を分析し、その根源的原因（プロセスや組織、そこで適用される技術などに行き当たる）に対して根本的／恒久的な対策を施したいはずだ。しかし、ITILではそんなことまで言及していなくて、問題を切り抜けられる回避策が明らかであればいいといったスタンスなのだ。

また、インシデントや問題に対して優先度付けする必要がある。開発側ではよく、重要度＋緊急度＝優先度と表現するのだが、ITILではインパクト＋緊急度＝優先度としている。確かに「重要度」というのは抽象的で定量化しにくく、判断が属人的になりやすい。インパクトは、インシデントや問題がユーザとの間で合意のとれたサービスレベルからどのくらい逸脱しているかによって決まる影響範囲で表現している。SLAをベースに判断するので客観的／定量的に評価しやすいのだろうと思われる。

(5)サービス移行 (SST:Service System Transition)

サービス移行(SST)は、進行中のサービスデリバリでの影響を管理しながら、サービスシステムコンポーネントを新規または重大な変更時に配置(デプロイ)することが目的である。

(1)サービスシステム移行の準備サービスデリバリへの影響度が最小になるように現行と将来のサービスシステムの機能性と互換性を分析して、サービスシステムへの移行計画を策定し、利害関係者に対する準備を行う。
(2)サービスシステムの配置移行計画に基づいたデリバリ環境にサービスシステムコンポーネントを配置し、利害関係者とサービスデリバリに対する移行の影響度を評価し、適切な是正アクションを施す。
ITILでのサービストランジションが該当し、変更管理やリリース管理が相当する。構成管理はCMMI-SVCでは独立したプロセス領域になる。

(6)サービスシステム開発 (SSD:Service System Development)

サービスシステム開発(SSD)は、CMMI-SVCでは追加オプションとなっている。サービスシステムやコンポーネントを分析、設計、構築、統合、検証、妥当性確認することが目的であり、新規サービス開発にも、既存サービスの変更にも適用される。オプションになっている理由は、CMMI-DEVそのものと重複するからだ。シンプルなサービスであればSSDに沿って開発すればよい。規模が大きい場合はCMMI-DEVを適用することになる。その場合でも、人とプロセスをサービス開発に特化させて記述されたSSDをガイドとして参照すべきである、と記述されている。

(1)利害関係者要求の開発と分析利害関係者のニーズ、期待、制約、インタフェースを収集し、利害関係者要求へと変換する。サービスシステム要求を開発できるように利害関係者要求を洗練し、精緻化する。要求を分析し、妥当性確認し、要求されるサービスシステムの機能性を定義する。
(2)サービスシステムの開発選択可能なソリューション候補からサービスシステムソリューションを選定する。サービスシステム、サービスシステムコンポーネントの設計を開発する。内部／外部のインタフェース定義、設計、サービスシステムへの変更を管理する。サービスシステム設計を実装する。実装されたサービスシステムコンポーネントを、検証可能なサービスシステムへと組み立て、統合する。
(3)サービスシステムの検証と妥当性確認検証と妥当性確認の方法と環境を確立する。選択されたサービスシステムコンポーネントについて、ピアレビューを実施する。選択されたサービスシステムコンポーネントを、特定の要求に照らして検証する。サービスシステムの妥当性を確認する。意図通りのデリバリ環境での利用に適合しているか、利害関係者の期待に合致しているかを確認する。
サービス開発での要件定義、設計、構築、テストまでの一連のプロセスを説明している。ITILでは、視点は異なるが「アプリケーション管理」で扱われる内容に相当する。ちなみにITILのアプリケーション管理は、アプリケーション開発プロセスとサービスマネジメントプロセスに分けられ、前者が要件定義、設計、構築(テストを含む)まで、後者が展開(移行)、運用、最適化(改善)を表現している。CMMIはV&Vを強調しているし、ITILは移行、運用、改善といった導入後のマネジメントを包含して強調している。

(7)戦略的サービス管理 (STSM:Strategic Service Management)

戦略的サービス管理(STSM)は、戦略的ニーズと計画に沿って標準サービスを確立することが目的だ。

(1)標準サービスのための戦略的ニーズと計画の確立戦略的ニーズと組織の能力についてのデータを収集し、分析し、標準サービスの計画を策定する。
(2)標準サービスの確立組織の標準サービス資産とサービスレベルを確立し、標準サービスを定義・記述する。
ITILでは、サービスストラテジの中のサービス戦略策定とサービスポートフォリオ管理が相当する。財務管理や需要管理まで包含しているかはまだ読み取れていない。

その他

ITILのサプライヤ管理は、CMMI-SVCではサプライヤ合意管理(SAM)が対応する。SAMはCMMI-SVCとCMMI-DEVで共通である、同じものであるということが分かった。、ITILの構成管理は、当然、CMMI-SVCの構成管理(CM)が対応する。

また、重複した説明になるが、ITILでのサービスレベル管理、要求実現、IT運用管理、需要管理、やサービスカタログ管理、イベント管理、アクセス管理、情報セキュリティ管理は、CMMI-SVCのサービスデリバリ(SD)に含めるしかないだろう。盛り沢山だ。一部は、サービスシステム開発(SSD)や戦略的サービス管理(STSM)に含まれてもよいはずだが、キーワードを眺める限り、明示はされていないようだ。このあたりは、ITILの方がより精緻に体系化できていると言える。