第112号：CMMI-SVCを知る

「サービスのためのCMMI(CMMI-SVC)」をご存知でしょうか？

私は先日、CMMI-SVCのトレーニングを受講する機会がありまして、CMMI-SVCの概要やどのように利用するかを学んできました。
国内でSVCのセミナーを受講出来る機会はなかなか無いので、貴重な経験となりました。

CMMI-SVCは、CMMIモデルの3つの関連要素群(DEV、SVC、ACQ)のうちの１つで、「サービス」という無形で蓄積できない成果物を対象とするモデルです。

国内のソフトウェア業界においてCMMI-DEVはよく広まっていますが、残念ながらCMMI-SVCはそれほどではありません。
しかし、業務の内容が開発ではなく、保守や運用、ITサービス、トレーニングやコンサルティングといったサービスを提供することが多い企業であれば、CMMI-SVCはプロセス改善の有効な選択肢の1つですので、導入を検討してもいいのかなと思います。

そこで今回は、CMMI-SVCについて簡単に概要をご紹介したいと思います。
※主にCMMI-DEVとの違いを中心に説明してきます。

CMMI-DEVは、ソフトウェア開発やシステムエンジニアリングにおいて何かを「構築」することに主眼がありますが、CMMI-SVCはサービスを「実施」することに主眼があります。

CMMI-SVCで扱うサービスの種類は非常に幅広いです。上記で挙げた運用、保守、ITサービス、トレーニング、コンサルティングの他、コールセンター業務、消防署運営、タクシー業務等、など、ソフトウェア業界に限らず、あらゆるサービスに関する業務に適用可能とされています。

次にモデルの中身の話をしましょう。

プロセス領域の数は、DEVよりも2個多い24個です。プロセス領域、成熟度レベル、カテゴリの関連は以下のようになっています。

縦軸が成熟度レベル(ML)、横軸がカテゴリです。

┌─┬──────┬─────┬────┬────┐
│ML│プロジェクト│サービス　│支援　　│プロセス│
│　│と作業管理　│確立と提供│　　　　│管理　　│
├─┼──────┼─────┼────┼────┤
│５│　　　　　　│　　　　　│CAR 　　│OPM 　　│
├─┼──────┼─────┼────┼────┤
│４│QWM 　　　│　　　　　│　　　　│OPP 　　│
├─┼──────┼─────┼────┼────┤
│３│IWM、RSKM、 │IRP、SSD、│DAR 　　│OPF、　 │
│　│CAM、SCON 　│SST、STSM │　　　　│OPD、OT │
├─┼──────┼─────┼────┼────┤
│２│REQM、WP、　│SD　　　　│CM、MA、│　　　　│
│　│WMC、SAM　　│　　　　　│PPQA　　│　　　　│
└─┴──────┴─────┴────┴────┘
　※ML=Maturity Level

DEVにあった「エンジニアリング」のカテゴリがなくなり、「サービス確立と提供」というカテゴリが新たに追加されています。

DEVでの「プロジェクト管理」カテゴリは、「プロジェクトと作業管理」カテゴリに名称変更されています。

SVCにおけるサービス業務は、「プロジェクト」という有限の活動単位ではなく、合意の元に継続的に提供が行われる「作業(Work)」単位で行われるため、プロセス領域名の「プロジェクト」の部分が軒並み「作業」に変更されています。

　プロジェクト計画策定(PP)　　　→　作業計画策定(WP)
　プロジェクトの監視と制御(PMC) →　作業の監視と制御(WMC)
　統合プロジェクト管理(IPM)　　 →　統合作業管理(IWM)
　定量的プロジェクト管理(QPM)　 →　定量的作業管理(QWM)

DEVのエンジニアリングカテゴリに属する5つのプロセス領域(RD、TS、PI、VER、VAL)はSVCには存在しません。
その代わり、サービス確立と提供カテゴリとプロジェクトと作業管理カテゴリに、SVC独自のプロセス領域が合計7つ追加されています。

プラクティスレベルでのDEVとの大きな違いとしては、「作業計画策定(WP)」プロセス領域のSP1.1に「サービス戦略を確立する」という固有プラクティスが追加されています。
　WP SP1.1 Establish and maintain the service strategy.

では、SVC独自の7つのプロセス領域について、概要、目的、固有ゴール等について少しだけご紹介しましょう。
※公式訳ではありません。

実施するサービスの合意を確立して、要望を処理して、サービスシステムを運営していくプロセス領域です。
SVC独自のプロセス領域のうち、唯一の成熟度レベル2に属するプロセス領域です。
　　
目的：サービスの合意に従ってサービスを提供すること
SG1 ：サービスの合意を確立する
SG2 ：サービス提供の準備をする
SG3 ：サービスを提供する

どんなサービスを提供するかを分析および計画し、標準的なサービスを確立して利用していくためのプロセス領域です。
　　
目的：戦略的ニーズや計画に合わせて標準サービスを確立し保守すること
SG1 ：標準サービスに対する戦略的ニーズと計画を確立する
SG2 ：標準サービスを確立する

サービスシステムの開発に関するプロセス領域です。追加分(Addition)のプロセス領域なので、必要に応じて適用することになります。
各プラクティスは、CMMI-DEVのエンジニアリングのプロセス領域(RD、TS、PI、VER、VAL)の各固有ゴールに対応しています。
　　
目的：既存、または予想されるサービスシステム合意を満足するために、サービスシステム構成要素も含めたサービスシステムを分析し、設計し、開発し、統合し、検証し、そして妥当性を確認すること
SG1 ：利害関係者の要件を確立し分析する
SG2 ：サービスシステムを開発する
SG3 ：サービスシステムを検証し妥当性を確認する

新規開発または変更したサービスシステムを移行することに関するプロセス領域です。
　　
目的：運用中のサービス提供への影響を管理しながら、新規または大規模変更されたサービスシステム構成要素を展開すること
SG1 ：サービスシステム移行の準備をする
SG2 ：サービスシステムを展開する

サービスに関してうまくいっていないことに対処したり、将来発生しないように予防したりするプロセス領域です。
　　
目的：適宜、サービスインシデントをタイムリかつ効果的に解決し、予防するようにすること
SG1 ：インシデントの解決と予防の準備をする
SG2 ：個別のインシデントを特定し、制御し、対処する
SG3 ：選択されたインシデントの原因と影響を分析し、対処する
　　
うまくいっていないことに対応する
また、出来る限り最優先でうまくいかなくならないように予防する。

サービスシステムが必要な時に必要なだけ利用可能になるように、監視し、分析することのプロセス領域です。

目的：効果的なサービスシステム実績を確保し、サービス要件を支援するために、資源が効果的に提供され使用されるようにすること
SG1 ：キャパシティと可用性管理の準備をする
SG2 ：キャパシティと可用性を監視し分析する

大地震やテロといった災害・惨事が起こった時に、速やかにサービスを回復して継続できるようにするための計画を備えるプロセス領域です。
　　
目的：正常運用中の重大な障害の最中またはその後に、サービスが継続できるような計画を確立し保守すること
災害・惨事からの回復手順を準備しておき、サービス提供を通常に戻す
SG1 ：不可欠なサービス依存関係を特定する
SG2 ：サービス継続のための準備をする
SG3 ：サービス継続計画を検証し妥当性を確認する

以上、簡単にCMMI-SVCについて概要をご紹介させて頂きました。

CMMI-SVCモデルは、DEVと違って公式日本語訳がないため、オリジナルの英語版を読んでいく必要がありますが、DEVをご存知の方なら、違いを意識しながら読むことで理解しやすくなるでしょう。