CMMIの体系 - たこはちの「へのかっぱ」日記

CMMIの構成(constellation)は、CMMI-DEV、CMMI-ACQ、CMMI-SVCの3つだ。CMMI for Acquisition(CMMI-ACQ) Version 1.2が昨年2007/11にリリースされた。調達プロセスのためのガイドだ。発注側／調達側視点の22のプロセス領域で構成されている。また、CMMI for Services(CMMI-SVC) Version 1.2もまもなくリリースされるだろう。外部顧客や組織内にサービスを提供するためのガイドだ。Draftは2006/11のものが公開されているが正式版は2008/春のリリースと聞いている。もうとっくに春だ。

開発者は、主に2006/08にリリースされたCMMI for Development(CMMI-DEV) Version 1.2は利用しているだろう。日本語訳も2007/07に出ている。今回CMMI-SVCがリリースされると、CMMIの体系はひととおり揃うことになる。CMMI-SVCがどの程度ITILも包含するかにもよるが、これまでCMMI＋ITILでサービス提供を語らなければならなかったものが、CMMIの中で閉じた形で語れるようになるのだろう。CMMI-SVCの特徴として、ITILのベストプラクティスを特定の小さなプラクティスへと要約し、CMMIモデルの要素にマッピングしているとある。つまりITILの本質的な原理原則は網羅しているということだ。また、開発プロセスのトレーニング、プロセス改善、サービスベースのインフラに対する部分では既存のCMMIモデルの80％を再利用しているそうだ。

少しCMMIの体系を整理してみた。CMMIではプロセス領域カテゴリは以下のように6個で構成されている。各プロセス領域はどれかのカテゴリに分類される。

プロセス領域カテゴリ(6個)
 |
 +-- ■プロセス管理 (Process Management)
 +-- ■プロジェクト管理 (Project Management)
 +-- ■支援 (Support)
 +-- □エンジニアリング (Engineering)                (※CMMI-DEV固有カテゴリ)
 +-- □調達 (Acquisition)                            (※CMMI-ACQ固有カテゴリ)
 +-- □サービス (Service Establishment and Delivery) (※CMMI-SVC固有カテゴリ)

また、CMMI-DEV、CMMI-ACQ、CMMI-SVCは、16個の共通するコアプロセス領域にそれぞれ固有なプロセスを追加する形式で構成されている。CMMI-DEVは6個(合計22個)、CMMI-ACQは6個(合計22個)、CMMI-SVCは8個(合計24個)の固有プロセスを追加している。

16個のコアプロセス領域
 |
 +-- プロセス管理
 |  +-- ■組織改革と展開 (Organization Innovation and Deployment:OID)
 |  +-- ■組織プロセス定義 (Organization Process Definition:OPD)
 |  +-- ■組織プロセス重視 (Organization Process Focus:OPF)
 |  +-- ■組織プロセス実績 (Organization Process Performance:OPP)
 |  +-- ■組織トレーニング (Organizational Training:OT)
 +-- プロジェクト管理 
 |  +-- ■プロジェクト計画策定 (Project Planning:PP)
 |  +-- ■プロジェクトの監視と制御 (Project Monitoring and Control:PMC) 
 |  +-- ■統合プロジェクト管理 (Integrated Project Management:IPM)
 |  +-- ■リスク管理 (Risk Management:RSKM)
 |  +-- ■定量的プロジェクト管理 (Quantitative Project Management:QPM)
 +-- 支援
 |  +-- ■構成管理 (Configuration Management:CM)
 |  +-- ■プロセスと成果物の品質保証 (Process and Product Quality Assurance:PPQA)
 |  +-- ■測定と分析 (Measurement and Analysis:MA)
 |  +-- ■原因分析と解決 (Causal Analysis and Resolution:CAR)
 |  +-- ■決定分析と解決 (Decision Analysis and Resolution:DAR)
 +-- 各ガイドごと
    +-- ■要件管理 (Requirements Management:REQM)　(※固有要件がそれぞれ追加される)

REQMのみは各ガイドで固有な要件を追加する形式で構成される。REQMは、CMMI-DEVではエンジニアリング領域カテゴリに配置される。CMMI-ACQではプロジェクト管理領域カテゴリに、CMMI-SVCではサービス領域カテゴリに配置される。

CMMI-DEVの固有プロセス(6個+1)
 |
 +-- プロジェクト管理 
 |  +-- □供給者合意管理 (Supplier Agreement Management:SAM) (※CMMI-SVCに吸収？)
 +-- エンジニアリング
    +-- □要件開発 (Requirements Development:RD)
    +-- □技術解 (Technical Solution:TS)
    +-- □成果物統合 (Product Integration:PI)
    +-- □検証 (Verification:VER)
    +-- □妥当性確認 (Validation:VAL)
    +-- ■要件管理 (Requirements Management:REQM) (※REQMに固有要件を追加して特化)

追加の固有プロセスはSAM以外は、エンジニアリング領域に属する。管理(REQM)と開発が並行で、開発はRD→TS→PIと進み、各RD,TS,PIの後にはVERとVALを伴うという構成になる。成果物だけではなく、その構成要素についてもRD→TS→PIと繰り返すことになる。ソフトウェアに限ればSWEBOKで重点的に語られる部分である。

SAMは、CMMI-DEVから完全にCMMI-SVCに移動されるのか、部分的に共有しながら定義されるのかは情報不足で不明。SAMもREQMと同様に、各ガイドで固有要件を追加するという位置づけなのだろう。

CMMI-ACQの固有プロセス(6個+1)
 |
 +-- プロジェクト管理 
 |  +-- ■要件管理 (Requirements Management:REQM)　(※REQMに固有要件を追加)
 +-- 調達 
    +-- □引合いと供給者合意開発 (Solicitation and Supplier Agreement Development:SSAD)
    +-- □調達管理 (Acquisition Management:AM) 
    +-- □調達要件開発 (Acquisition Requirement Development:ARD)
    +-- □調達技術解 (Acquisition Technical Solution:ATS)
    +-- □調達妥当性確認 (Acquisition Validation:AVAL)
    +-- □調達検証 (Acquisition Verification:AVER)

調達(acquisition)とは「契約を通じて成果物(商品やサービス)を獲得するプロセス」と定義されている。

SSADは、CMMI-DEVのSAMのコンセプトをベースにしているが類似する部分は僅かであり、別物と考えた方がよいらしい。両者を対照するようなドキュメントは提供されていない。SSADは、引合い、供給者選定、供給者合意の確立と保守を受け持つ。プロジェクト遂行を成功させるための調達者が供給者との関係を明文化するためのプラクティスを提供する。供給者合意にもとづいて、成果物やサービスが供給者から調達者へデリバリされるのだ。

CMMI-ACQでの調達要件開発(ARD)プロセスのアウトプットは顧客要件と制約を汎化させたものになる。要件管理では、供給者の要件管理と同様に変更要求に対応する必要がある。供給者合意のもとで変更要求に対応する。顧客要件と、調達者が管理する契約上の要求は、双方向のトレーサビリティが維持される必要がある。REQMは、CMMI-ACQではプロジェクト管理カテゴリ、CMMI-DEVではエンジニアリングカテゴリに配置されるので注意が必要。

調達側のRD,TS,VAL,VERがどのように異なるのかは別途。

CMMI-SVCの固有プロセス(8個+2)
 |
 +-- プロセス管理
 |  +-- □組織サービス管理 (Organizational Service Management:OSM)
 +-- プロジェクト管理 
 |  +-- □キャパシティと可用性管理 (Capacity and availability management:CAM)
 |  +-- □サービス継続性管理 (Service Continuity Management:SCON)
 |  +-- ■供給者合意管理 (Supplier Agreement Management:SAM) (※CMMI-DEVから移動？)
 |  +-- ■要件管理 (Requirements Management:REQM)　(※REQMに固有要件を追加)　
 +-- 支援
 |  +-- □問題管理 (Problem management:PRM)
 +-- サービス
    +-- □インシデントと要求管理 (Incident and request management:IRM)
    +-- □サービス移行 (Service transition:ST)
    +-- □サービスデリバリ (Service Delivery:SD)
    +-- □サービスシステム開発 (Service System Development:SSD)

CMMIではサービスを非常に簡潔に「無形で蓄積できない成果物(an intangible, non-storable product)」と定義している。またサービスという成果物を意識して、以前ひとまとめに「成果物」と表現されていたものが、有形であることが明らかな場合には「製品(product)」と明示するようになっている。顧客や最終利用者への納入が意図された作業成果物である。CMMI-DEVからそのような定義に変更された。

SAMは、CMMI-DEVから完全に移動されるのか、部分的に共有しながら定義されるのかは情報不足で不明。SAMプロセスは例外的に扱われる。3つのガイドに現れるが、組織で必要としないならCMMI-SVCのアプレイザルからは除外してよい、とある。CMMI-DEVで考慮されていれば、CMMI-SVCでは取り上げなくてよいということか。(※2006/11のDraft情報)

問題管理(PRM)は、インシデントの根源的な原因を識別し、再現を抑止するためのプロセスである。

また、CMMI-DEVにもCMMI-ACQにもさらにCMMI-SVCにも登場するREQMであるが、CMMI-SVCではサービス提供者と顧客の間でサービス要件、サービスレベルの同意を確立し、明文化したものを保守するという位置づけになる。REQMは、要件の再利用とトレーサビリティの維持の観点で記述されているらしい。REQMはCMMI-ACQと同様にプロジェクト管理カテゴリに配置されるので注意が必要。