能力成熟度モデル統合

ウィキペディア

索引トップ用語の索引ランキングカテゴリー

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/12/24 07:07 UTC 版)

概要

成熟度レベルの特性

CMMIは、プロセスの評価や改善をすすめるための枠組みであり、段階表現と連続表現の2つの表現方法がある。段階表現では、組織の実施プロセスを評価し、レベル1からレベル5までの5段階の成熟度レベルを（組織に対して）出すことができる。連続表現では、各プロセスを評価し、レベル0からレベル3までの4段階の能力度レベルを（プロセスごとに）出すことができる。（以前はレベル0から5までの6段階であったが、v1.3から4段階に改訂された。）これらのレベルは、評価の対象となるプロセスの制度化の程度に応じて、等級づけられている。

評価の対象となる領域はさまざまであり次のようなものがある。

ソフトウェア開発
システム開発
プロジェクト管理
リスク管理
システム調達、情報技術 (IT) サービス
パーソナルマネジメント

CMMIでは5つの成熟度レベルを厳密に定義している。

レベル1は、非常に未熟で混沌とした開発プロセスである。
レベル5は、非常に成熟した高品質を実現する開発プロセスである。

1998年の時点では、ソフトウェア開発を行う組織の75%がレベル1であると推定されている (参考)。

CMMIの前身にあたるCMMは、1980年代半ばにアメリカ合衆国のピッツバーグにあるカーネギーメロン大学 (CMU) のソフトウェア工学研究所 (SEI; Software Engineering Institute) で開発された。 CMMIは、航空電子工学ソフトウェアの開発や北アメリカ、欧州、アジア、オーストラリア、南アメリカ、アフリカなどの国々の政府主体で行うプロジェクトなどで、広く採用されてきており、こうした国々でCMMIに対する官民の関心は高い^[2] 。現在、いくつかの国々の省庁は、ソフトウェア開発契約に際して業者にレベル3の基準を達成しかつ運用できていることを必須としている。また日本においても、ソフトウェアを発注する官公庁や民間組織がCMMIを採用し、一方でソフトウェア開発を担う組織がCMMIの指針に即して自らのソフトウェア開発プロセスを改善する動きが、徐々に広がりつつある。

成熟度モデル

CMMI (能力成熟度モデル統合) は、組織がプロセスを定め洗練するための手段である。最初のCMMはソフトウェア開発プロセスを確立し洗練することを目標としていた。成熟度モデルは、効果的なプロセスのさまざまな特性を構造化して記述した体系である。カーネギーメロン大学 (CMU) のCMMI研究所はCMMIの公式文書を公開しており、この中には日本語の公式訳もある。この日本語訳は、ソフトウェアプロセス改善に関する企業コンソーシアムであるJASPIC (日本SPIコンソーシアム)が翻訳作業を実施したものである。いずれも無償でダウンロード/閲覧することができる。

成熟度モデルが提供するものは次のとおりである。

何から着手すべきか
ソフトウェア開発コミュニティが以前に経験したことから得られた成果
共通の言語と、ビジョンの共有
実行の優先順位づけの枠組み
自分たちの組織にとって改善が意味することを明確にする方法

成熟度モデルは、同等の能力をもつと思われる複数の組織を評価するベンチマークとして使うことができる。

歴史

CMMI（能力成熟度モデル統合）の前身である CMM（能力成熟度モデル）は、もともとは軍事研究の一環として資金を与えられて始まった。アメリカ合衆国空軍がカーネギーメロン大学（CMU）のソフトウェア工学研究所（SEI）に資金を渡して、軍事部門がソフトウェアの下請業者を客観的に評価するものとして使えるモデルを作る研究を依頼した。研究成果は1989年に Managing the software process の書名で出版された（日本語訳『ソフトウェアプロセス成熟度の改善』1991年）。 CMMはその後も改訂・更新を経ている。 SEIはもはや CMM に対するサポートを止め、改訂版である CMMI（能力成熟度モデル統合、Capability Maturity Model Integration）が開発・サポートの対象となっている。 2012年、カーネギーメロン大学は、CMMI研究所（CMMI Institute）という新しい研究所を設立し、CMMIに関係する成果物と活動をSEIから移行した。 2013年現在、CMMI バージョン 1.3 が公表されており、CMMI Instituteのウェブサイトで全文を閲覧することができる。

背景

1970年代に、技術の発達によりコンピュータが広く普及しよりさまざまな用途に使われるようになり、従来より少ない費用で導入できるようになっていた。多くの組織は、コンピュータ化による情報システムを推進する方針を採り、それに伴い組織におけるソフトウェア開発の領域の比重も非常に大きくなった。こうした情況から、開発者および開発管理者に対する要求は日増しに大きくなっていた。このような要求には、経験をあまり積んでいない専門職の人々が対応していた。

不幸なことに、開発者に対する要求が非常に大きくなったことは、組織にとって苦痛を伴った。ソフトウェア開発プロジェクトが失敗に終わることは、ごく普通のありふれたことになってしまった。その原因は、コンピュータ科学が当時は未成熟であったことだけでなく、開発プロジェクトがその規模と複雑さにおいて野心的で多くの労力を伴う傾向が有ったためでもある。この問題に対して、エドワード・ヨードン、ラリー・コンスタンティン、ジェラルド・ワインバーグ、トム・デマルコ、デイビッド・パーナスなどの人々は、ソフトウェア開発プロセスをより熟練した工程とするための研究を行い、その研究成果を論文および書籍として発表した。

ワッツ・ハンフリーによる能力成熟度モデル（CMM; Capability Maturity Model）は、1989年に Managing the Software Process という書籍に記述され出版された（日本語訳は『ソフトウェアプロセス成熟度の改善』1991年）。ワッツ・ハンフリーが考案したCMMは、10年前のフィル・クロスビーの業績に基づいている。クロスビーの業績は、彼の1979年の著書 Quality is Free の "Quality Management Maturity Grid" で公表された^[3]^[4]。 1986年から SEI（ソフトウェア工学研究所）により本格的に CMM のモデル構築が始まった。

CMMはもともとは政府のソフトウェア開発請負業者を評価するためのツールと位置づけられており、ソフトウェア開発契約に基づくプロジェクトを遂行する際に活用することが想定されていた。 CMMはソフトウェア開発の分野で活用されていたが、システム工学分野でも適用できるCMMIに発展し、さらに、さまざまなプロセスの成熟度の一般的なモデルとして、広く適用されるようになっている（ITサービス管理プロセスなど）。システムインテグレータや情報技術関連組織などがCMMIを活用するようになっている。

CMMIのモデルは、ソフトウェアやシステムの開発、調達、サービス提供を行う組織のプロセス成熟度について、5つのレベルを規定している。

初期状態（混沌とした、いきあたりばったりで、一部の英雄的なメンバー依存の状態）。成熟したプロセスを導入する際の、出発点のレベル。
管理された状態（反復できる状態、プロジェクト管理・プロセスの規則の存在）、反復してプロセスを実行できるレベル
定義された状態（制度化された状態）、プロセスが標準ビジネスプロセスとして明示的に定義され関係者の承認を受けているレベル。
定量的に管理された状態（制御できる状態）、プロセス管理が実施され、さまざまなタスク領域を定量的に制御しているレベル。
最適化している状態（プロセスを定量的に改善する状態）、継続的に自らのプロセスを最適化し改善しているレベル。

CMMIは複数のプロセス領域（プロセスエリア）から構成されている。段階表現の場合にはプロセス領域は成熟度レベルに応じて分類されている。連続表現ではプロセスの適用対象の区分（プロジェクト管理、プロセス管理、エンジニアリングなど）に応じて分類されている。各プロセス領域はさらに複数のゴールから構成されている。ゴールには固有ゴールと共通ゴールの2種類がある。固有ゴールは、例えば、プロジェクト計画策定プロセス領域であれば、「プロジェクト計画を策定する」のように、そのプロセス領域で実施されるべき固有の内容を表わしている。共通ゴールは、プロセスの制度化の程度を表わしており、（成熟度および能力度）レベルと対応している。

CMMIによりプロセス改善に取り組む組織は、資格を認定された評定者（リードアプレイザまたはB,Cチームリーダ）によりプロセスの評定（アプレイザル）を受けることができる。評定には厳格さに応じてA,B,Cの三段階のクラスがあり、もっとも厳格なクラスAの評定では成熟度レベルの判定を出すことができる。改善の初期にまずプロセスの評定（アプレイザル）を受けることにより、組織は改善点を客観的・網羅的に把握することができ、次の改善のための計画を立てることができる。改善活動実施後、その改善結果の確認のために、再度、評定を受ける。この際には成熟度レベルの判定ができるクラスＡの評定を実施することが多い。

レベルはその定義から累積的な概念であり、高いレベルの達成は低いレベルの内容も同時に達成していることを意味する。成熟度レベルは段階的で自然なプロセス改善の順序と考えられており、レベルを飛び越す形の改善は推奨されない。

注意: CMMはもともとは政府の請負業者が請け負ったソフトウェアを開発する能力を評価する手段を想定して作成された。 CMM/CMMIがソフトウェア開発プロセス成熟度のモデルとして一般的になると、CMM/CMMIに対する批判も多くなされるようになった。

商用のパッケージソフトウェアを開発する企業（Apple、シマンテック、マイクロソフトなど）の多くは、CMMIが規定する水準の文書を滅多に管理していない^[要出典]。この文書管理はCMMIのレベル2を達成するために必要である。こうした企業のほとんどはレベル1に等級づけられるであろう。

起源

アメリカ合衆国空軍が SEI（ソフトウェア工学研究所）に資金を提供して、SEIは軍がソフトウェア開発請負業者の客観的な評価基準として使うモデルを作成する研究を行った。 1989年に、CMM（能力成熟度モデル）は Managing the software process の書名で出版された（日本語訳『ソフトウェアプロセス成熟度の改善』1991年）。

年表

1987年: SEI-87-TR-24（SW-CMM 質問書）公表。
1989年: 書籍 Managing the Software Process が出版される。
1990年: SW-CMM v0.2 公表。（最初の外部向け公表、資料を参照）
1991年: SW-CMM v1.0 公表。
1993年: SW-CMM v1.1 公表。
1997年: SW-CMM の開発を終了する（CMMIを開発するため）。
2000年: CMMI v1.02 公表。
2002年: CMMI v1.1 公表。
2006年: CMMI v1.2 公表。
2010年: CMMI v1.3 公表。
2018年: CMMI v2.0 公表。

現状

CMMに基づいた各モデルは多くの組織にとって有用であったが、複数のモデルを使いこなすことが難しい課題となっていた。さらに、複数のモデルの適用を一つの組織内もしくは組織横断的に統合して実行することは、訓練、評価、プロセス改善において費用が高くついた。複数のCMMモデルを適用するに伴う課題を克服する、CMM統合（CMMI; CMM Integration）プロジェクトが立ち上げられた。 CMMI開発チームの目的は、3つのソースモデルを統合することであった。

ソフトウェア能力成熟度モデル（SW-CMM）v2.0 ドラフト C
システムエンジニアリング成熟度モデル（SECM）
統合成果物開発成熟度モデル（IPD-CMM）v0.98
供給者ソーシング

CMMI は3つのソースモデルの後継版として位置づけられている。 SEI は SW-CMM、SECM、IPD-CMM および古いバージョンの CMMI を終了する方針を公表した[1]。これらのモデルは新しいバージョンの CMMI が後継している。

またCMMIは、ISO/IEC 15504にも適合できるように、これまでの段階表現（Staged Representation）に加え、連続表現（Continuous Representation）も用意された。

CMMIの発展

CMMIバージョン1.2が公表されると、SEI は既存の CMMI を「開発のためのCMMI」（CMMI for Development, CMMI-DEV）と改称した[2]。現在では、CMMIは発展して、「開発」以外の目的にも使用できるような複数のモデルが作られている。それぞれのモデルは関連要素群と呼ばれている。

SEI の援助のもとでノースロップ・グラマン社が主導するチームが CMMI for Services という CMMI の関連要素群を開発した。この開発には以下の各企業・団体も参加していた[3]。

ボーイング
ロッキード・マーティン
レイセオン
SRA（日本のSRAとは別の会社）
SAIC（Science Applications International Corporation）
SSCI（Systems and Software Consortium）

SEIは、CMMI for Acquisition（CMMI-ACQ）という CMMI の関連要素群も開発した。

SEIは、CMMIを改善する提案を歓迎している。 SEIにCMMIのフィードバックを渡す方法については、CMMIのウェブサイトを参照。

場合によっては、CMMIは他の方法論と組み合わせることができる。 CMMI と ISO 9001 を同時に施行することは、よく行われている。 JPモルガン・チェースは、CMMをコンピュータプログラミング方法論エクストリーム・プログラミング（XP）およびシックス・シグマと統合することを試みた。この統合を行った人々は、統合した3つの体系が互いを補強し、相互に矛盾することは無い、との所感をもった。 Extreme Programming (XP) Six Sigma CMMIを参照。

脚注