CMMI (1/5)歴史

CMM® | CMMI®とは (1/5)

  1. CMM | CMMIの歴史
  2. 組織成熟度
  3. CMMIで規定されるプロセス領域
  4. 段階表現と連続表現
  5. CMMIとアプレイザル(アセスメント)

1. CMM® | CMMI®の歴史

品質、生産性の向上、工期短縮などのニーズを満たすためにソフトウェアプロジェクトの活動をより高度なレベルに高めるため、米国国防総省(DoD)の出資のもとに、カーネギーメロン大学のソフトウェアエンジニアリング研究所(SEI)が能力成熟度モデル(CMM: Capability Maturity Model)を開発しました。

SEIは、DoDが出資している研究機関で、軍事費の多くを占め、益々増大するソフトウェアコストを圧縮するための方策を検討することが、CMMを開発するそもそものきっかけでした。研究の成果は、1987年に成熟度フレームワークとしてまとめられ[1]、DoDは成熟度フレームワークによるソフトウェアプロセスアセスメント(SPA)のしくみをその調達の枠組みに導入しました[2]。 ソフトウェア開発およびそのマネジメントプロセスが一定の成熟度レベルに達していることが調達時の条件にされ、契約業者はプロセス改善に取り組む必要性に迫られました。DoDは提案依頼書(RFP)に受注のために必要な成熟度レベルを指定します。応札企業は、レベルを満たすことを示す要件リストにチェックを入れ、提案書に添付して応札することが求められます。DoDが供給者に対して行うプロセスチェックをエバリュエーションと呼び、供給者がプロセス改善の一環として行うプロセスチェックをアセスメントと呼びます[3]

SEIでCMMを主導したハンフリー(W.Humphrey)は、その思想を「ソフトウェアプロセス成熟度の改善」にまとめました[4]。成熟度フレームワークは、その後、集大成され、いくつかの改訂を経て、1993年にソフトウェア能力成熟度モデル(CMM: Capability Maturity Model) V1.1が発行されました [5,6]。 CMMには、シューハート(W.Shewhart)、デミング(W.Deming)、ジュラン(J.Juran)らによるSQC、TQM、トリロジーなどの理論とともに、クロスビー(P. Crosby)による組織の成長過程モデルの考え方が反映されています[7]。また、ソフトウェア開発において実践されているベストプラクティス(注)が体系化されています[8,9]。CMMはソフトウェアプロセスのあり方を示すモデルとして、世界的に注目されました。

(注)プラクティスとは、日々の業務で必要とされる概念や原則、必要な技術、手法、ツール、管理ノウハウなどの集合を指します。

CMMは当初ソフトウェアの開発を対象に開発され、これをソフトウェア CMMと呼んでいます。CMMにはこれ以外に、システムエンジニアリグCMM、システム調達CMMなど、いろいろなモデルが開発されました。これらのモデルはそれぞれ似て非なるところがあって、使いづらいことからこれらを統合したモデルの開発が求められ、それがCMM統合モデル、すなわちCMMI®(CMM IntegrationSM)です[10]。CMMIには、他の分野の要素とともにSW-CMMの主要な要素が取り入れられ、さらに発展した内容になりました(「CMMIとCMMの違いは?」を参照)。その後さらに改良が加えられ、2012年現在、CMMI V1.3が運用されています。CMMI V1.3には、システムやソフトウェアの「開発のためのCMMI」 (CMMI-DEV)[11]、「調達のためのCMMI」 (CMMI-ACQ)、「サービスのためのCMMI」 (CMMI-SVC)の3種類があります。勿論、 統合モデルですから、それらは共通部分と個別部分からなります。なお、CMMI-DEVはCMMI V1.1の後継です。



SW-CMMからCMMIへの流れ

CMMやCMMIは、ベストプラクティスを体系化したモデル記述であり、プロセス改善のためのツールです。調達に適用される場合は、要求事項化することもありえますが、ISO9001のような要求事項ではありません。最近、「CMMIのレベルを取得する」といった言い方が前にも増して一般化してきた印象を受けます。 また、ウィキペディアの「能力成熟度モデル統合」の項に、「組織がプロセスをより適切に管理できるようになることを目的として遵守するべき指針を体系化したものである」という説明がありますが、「レベルを取得する」や「遵守する」といった言葉は必ずしも適切な表現、説明とは思えません。 CMMやCMMIに仕えるのではなく、それを使いこなすことによってQCD(品質、コスト、納期)を改善し、顧客の満足を得、事業の目標を達成することにこそ意味があり、レベルの達成は最終目的ではありません。



(参考文献)
  1. 「Characterizing the Software Process A Mturity Framework」
    W. Humphrey、CMU/SEI-87-TR-11
  2. 「A Method for Assessing the Software Engineering Capability of Contractors」
    W. Humphrey他、CMU/SEI-87-TR-23
  3. 「The Role of Assessment in Software Process Improvement」
    D.Kitson,W. Humphrey、CMU/SEI-89-TR-3
  4. 「ソフトウェアプロセス成熟度の改善」
    W.S.Humphrey著、藤野喜一他翻訳、日科技連出版
  5. 「Capability Maturity Model for Software, Version 1.1」
    Mark C. Paulk, Bill Curtis, et al, CMU/SEI-93-TR-24
  6. 「ソフトウェア能力成熟度モデル 1.1版公式日本語版」
    SEA-SPIN/CMM グループ訳,ソフトウェア技術者協会(SEA)
  7. 「Quality is Free」、P.Crosby著、PENGUIN USA
  8. 「Key Practices of the Capability Maturity Model」, Version 1.1
    M.Paulk, C.Weber, S.Garcia, M.Chrissis,M.Bush, CMU/SEI-93-TR-25
  9. 「能力成熟度モデルのキープラクティス 1.1版公式日本語版」
    SEA-SPIN/CMM グループ訳, ソフトウェア技術者協会(SEA)
  10. 「能力成熟度モデル統合(CMMI),1.1版」
    JASPIC訳、情報処理推進機構(IPA)発刊
  11. 「開発のためのCMMI(CMMI-DEV)1.3版」 CMU/SEI-2010-TR-033

2. 組織成熟度へ