能力成熟度モデル統合

能力成熟度モデル統合  は、組織がプロセスをより適切に管理できるようになることを目的として遵守するべき指針を体系化したものである 。 平易な言い方をすると、ソフトウェア開発組織及びプロジェクトのプロセスを改善するために、その組織の成熟度レベルを段階的に定義したものである。 CMMIは、もともとは能力成熟度モデル  として開発された。

1. 概要
-----

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

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

ソフトウェア開発
システム開発
プロジェクト管理
リスク管理
システム調達、情報技術  サービス
パーソナルマネジメントCMMIでは5つの成熟度レベルを厳密に定義している。

レベル1は、非常に未熟で混沌とした開発プロセスである。
レベル5は、非常に成熟した高品質を実現する開発プロセスである。1998年の時点では、ソフトウェア開発を行う組織の75%がレベル1であると推定されている 。

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

2. 成熟度モデル
---------

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

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

何から着手すべきか
ソフトウェア開発コミュニティが以前に経験したことから得られた成果
共通の言語と、ビジョンの共有
実行の優先順位づけの枠組み
自分たちの組織にとって改善が意味することを明確にする方法成熟度モデルは、同等の能力をもつと思われる複数の組織を評価するベンチマークとして使うことができる。

3. 歴史
-----

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

3.1. 背景
-------

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

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

ワッツ・ハンフリーによる能力成熟度モデルは、1989年に //Managing the Software Process// という書籍に記述され出版された。 ワッツ・ハンフリーが考案したCMMは、10年前のフィル・クロスビーの業績に基づいている。 クロスビーの業績は、彼の1979年の著書 //Quality is Free// の "Quality Management Maturity Grid" で公表された。 1986年から SEIにより本格的に CMM のモデル構築が始まった。

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

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

初期状態。成熟したプロセスを導入する際の、出発点のレベル。
管理された状態、反復してプロセスを実行できるレベル
定義された状態、プロセスが標準ビジネスプロセスとして明示的に定義され関係者の承認を受けているレベル。
定量的に管理された状態、プロセス管理が実施され、さまざまなタスク領域を定量的に制御しているレベル。
最適化している状態、継続的に自らのプロセスを最適化し改善しているレベル。CMMIは複数のプロセス領域から構成されている。段階表現の場合にはプロセス領域は成熟度レベルに応じて分類されている。連続表現ではプロセスの適用対象の区分に応じて分類されている。各プロセス領域はさらに複数のゴールから構成されている。ゴールには固有ゴールと共通ゴールの2種類がある。固有ゴールは、例えば、プロジェクト計画策定プロセス領域であれば、「プロジェクト計画を策定する」のように、そのプロセス領域で実施されるべき固有の内容を表わしている。共通ゴールは、プロセスの制度化の程度を表わしており、レベルと対応している。

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

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

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

商用のパッケージソフトウェアを開発する企業の多くは、CMMIが規定する水準の文書を滅多に管理していないdate=2013年2月}}。 この文書管理はCMMIのレベル2を達成するために必要である。 こうした企業のほとんどはレベル1に等級づけられるであろう。

3.2. 起源
-------

アメリカ合衆国空軍が SEIに資金を提供して、SEIは軍がソフトウェア開発請負業者の客観的な評価基準として使うモデルを作成する研究を行った。 1989年に、CMMは //Managing the software process// の書名で出版された。

3.2.1. 年表
---------

1987年: SEI-87-TR-24公表。
1989年: 書籍 //Managing the Software Process// が出版される。
1990年: SW-CMM v0.2 公表。
1991年: SW-CMM v1.0 公表。
1993年: SW-CMM v1.1 公表。
1997年: SW-CMM の開発を終了する。
2000年: CMMI v1.02 公表。
2002年: CMMI v1.1 公表。
2006年: CMMI v1.2 公表。
2010年: CMMI v1.3 公表。
2018年: CMMI v2.0 公表。

3.3. 現状
-------

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

ソフトウェア能力成熟度モデルv2.0 ドラフト C
システムエンジニアリング成熟度モデル
統合成果物開発成熟度モデルv0.98
供給者ソーシングCMMI は3つのソースモデルの後継版として位置づけられている。 SEI は SW-CMM、SECM、IPD-CMM および古いバージョンの CMMI を終了する方針を公表した[2]。 これらのモデルは新しいバージョンの CMMI が後継している。

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

3.4. CMMIの発展
------------

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

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

ボーイング
ロッキード・マーティン
レイセオン
SRA
SAIC
SSCISEIは、CMMI for Acquisitionという CMMI の関連要素群も開発した。

SEIは、CMMIを改善する提案を歓迎している。 SEIにCMMIのフィードバックを渡す方法については、[5]を参照。

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

4. 成熟度レベル
---------

//詳細は[7] 第3章 26ページを参照//

CMMI  には5つの成熟度レベルがある。 SEIによると、

4.1. レベル1 初期
------------

成熟度レベル1では多くの場合、プロセスは場当たり的であり、組織は安定した環境を提供しない。 こうした組織では、プロジェクトの成功は、組織に属する個々人の能力と英雄的行動に依存しており、有用性が証明されたプロセスを採用していない。 場当たり的で混沌とした環境であるにもかかわらず、成熟度レベル1の組織は実際に動く成果物とサービスを提供することが少なくない。 しかしそれらは多くの場合プロジェクトの予算および予定期限を超過する。

成熟度レベル1の組織は、超過労働、危機に対処するプロセスの欠如、過去の成功を繰り返す能力の欠如、によって特徴づけられる。

レベル1の組織が遂行するプロジェクトの成功は、高い能力をもつ個人に依存している。

4.2. レベル2 管理された
---------------

成熟度レベル2の組織はソフトウェア開発などの成功を反復して実行することができる。 このレベルの組織では、組織の全てのプロジェクトにおいて反復が実現できているとは限らない。 このレベルの組織では、何らかの基本的なプロジェクト管理を行い、費用と予定  を管理している。

レベル2のプロセスの規律を実行することにより、これまで行ってきた実践は今後も意識して行われ続けられる。 これまで行ってきた実践は今後も首尾良く行われる場合、プロジェクトは文書化された計画に従って実行され管理される。

プロジェクトの情況や納品物の引渡しなどは、事前に定めておいた時点  での管理を通して明確になる。

基本的なプロジェクト管理プロセスが確立し、費用、予定、開発対象の機能を管理する。 レベル2のプロセスの最低限の規律は、過去の類似した分野と範囲をもつプロジェクトの成功を、反復することである。 このレベルでは、費用もしくは納品予定日を超過するという大きなリスクは依然として存在する。

4.3. レベル3 定義された
---------------

成熟度レベル3の組織では、組織の標準プロセスが確立しており、時が経つにつれ標準プロセスは改善される。 こうした標準プロセスは、組織全体に浸透させ組織における一貫性を確立すべく使用される。 組織のプロジェクトは、組織の標準プロセスによりテーラリング指針に沿って、定義されたプロセスを確立する。

組織の管理部門は、組織の標準プロセスに基づいてプロセスの目的を確立し、こうした目的が確実に適切に取り組まれるようにする。

成熟度レベル2とレベル3の重要な違いは、標準群とプロセス記述と手続きである。 成熟度レベル2の組織では、標準群とプロセス記述と手続きは、プロセスのおのおのの具体的な内容において組織内でかなり異なっているかもしれない。 成熟度レベル3の組織では、あるプロジェクトや部門の標準群とプロセス記述と手続きは、組織の標準プロセスに適合している。

4.4. レベル4 定量的に管理された
-------------------

成熟度レベル4の組織では、実施プロセスを安定化し、さらに実績を予測するモデルを持つことで、ソフトウェア開発などの有効性を効果的に制御することができる。 特に、個別のプロジェクトに対してプロセスを調整し適合する道筋を同定することができる。 このとき測定可能な品質の低減や仕様からの逸脱が無いようにプロセスが制御され、安定化される。 成熟度レベル4の組織は、ソフトウェア開発プロセスやソフトウェア保守などのための定量的な品質の目標を設定する。注意すべきことは、この目標がプロセスの実績データを基にした実現可能なものであり、管理層からの一方的押しつけや実現不可能な努力目標ではないということである。

プロセス全体の遂行に非常に大きく貢献するサブプロセスが選択される。 この選択されたサブプロセスは、統計的な技法と他の定量的な技法により制御される。

成熟度レベル3とレベル4の重要な違いはプロセス遂行の予測可能性である。 成熟度レベル4では、プロセスの遂行は統計的な技法と他の定量的な技法により制御され、定量的に予測可能である。 成熟度レベル3では、プロセスは単に定性的に予測可能なだけである。

4.5. レベル5 最適化している
-----------------

成熟度レベル5は、段階的および革新的な技術的進歩を通じた継続的なプロセスの有効性の改善を重視する。 組織にとっての定量的なプロセス改善の複数の目標が定められる。 これらの目標は、ビジネス上の目標の変更を反映して継続的に改訂される。 またこれらの目標は、プロセス改善の管理における基準として使われる。 適用されたプロセス改善の有効性は計測され、定量的なプロセス改善目標に照らして評価される。 定義されたプロセスと組織の標準プロセスのセットの双方が、改善活動の計測の対象となる。

プロセス改善は、プロセスにおける変動の共通の原因に取り組み組織のプロセスを計測可能な形で改善するために、同定され評価され適用される。

敏捷で適応力のある進取的なプロセスの最適化は、能力の高い労働者がビジネス価値と組織の目標に同調して参加するかどうかにかかっている。 組織における変化と機会にすばやく対応する能力は、学習を加速し共有する道筋をみつけることで高まる。

成熟度レベル4とレベル5の重要な違いは、取り組む対象である、プロセスにおける変動の種類である。 成熟度レベル4では、プロセスはプロセスにおける変動の特定の原因に取り組むことと結果の統計的予測と関連している。 プロセスは予測可能な結果を出すかもしれないが、その結果はあらかじめ定めた目標の達成には不十分であるかもしれない。 成熟度レベル5では、プロセスはプロセスにおける変動に共通する原因に取り組むこととプロセスを変更し  その遂行能力を向上させ  あらかじめ定めた定量的なプロセス改善目標を達成できるようにすることと関連している。

4.6. レベルに関する表現
--------------

成熟度レベル5は「最適化しているレベル」であって「最適化されたレベル」ではない。 これは、プロセス改善に終わりはなく、常に改善し続けていくものだという 考えに基づいている。

同様の考え方から、レベルに関しては「認証」「認定」「取得」といった表現は使わず、 「達成」という表現を使うべきものとされている。レベル「認定」を「取得」する ことだけが目的の改善ならば、「認定」された時点で活動が終わってしまうからである。 仕組みとしても、CMMIでは 何らかの認証機関が成熟度レベルを認証したり、認定することはない。 資格を持ったリードアプレイザが アプレイザルチームを構成して、評定結果を出す仕組みがあるのみである。

5. 能力度レベル
---------

CMMIの連続表現ではプロセスごとにレベルをつけることができ、能力度レベルという名で呼ばれる。段階表現でも連続表現でもレベルの概念は同じであるとされているが、能力度レベルには、成熟度レベルにはない、レベル0が存在する。また、v1.3以降、能力度レベル4, 5は廃止された。

レベル0は、「不完全な」プロセスレベルとして特徴づけられる。 CMMIに関心をもつ多くの人々は、このレベルを冗長であるもしくは重要ではないとして、無視しているdate=2013年2月}}。 ただしプレスマンなどの人々はこのレベルに注目している。 SEI CMMI 2002年8月のバージョンの18頁を参照。

アントニー・フィンケルシュタイン は、負  のレベルが何段階か必要だと考えている。 負のレベルは、平凡であるに加えてはっきり非生産的な環境を表す。 この負のレベルは、トム・ショルシュ により「能力非成熟度モデル」 として改良された。

6. プロセス領域
---------

CMMI  は複数のプロセス領域から構成されている。 以下は「開発のためのCMMI」のプロセス領域の一覧である。



7. 論争
-----

section=1ソフトウェア業界内は多様でありまた気まぐれである。 あらゆるソフトウェア開発方法論には支持者と批判者が存在する。 CMMI  も例外ではない。

7.1. 肯定的見解
----------

CMMは、国防組織に対して、ソフトウェアの請負業者が、期日どおりに、予算の範囲内で、受け入れ可能な基準に沿って、納品する能力を検証し記述する基準を、提供した。CMM/CMMIは、まず間違いなくこの役割を果たすことに成功している。それだけでなくソフトウェアの営業を行う一定の人々が自社の経営者やソフトウェア開発者に「CMM/CMMIによるプロセス改善を実施してください」と要求するよう促している。
CMMIは、組織のソフトウェア開発の成熟度を検証できるようにすることを意図している。CMMIは、アウトソーシングもしくはソフトウェア開発を外注する際に重要なツールとなっている。インド、アイルランド、エジプト、シリアなど多くの国々の経済開発を担う省庁は、CMMIをアメリカ合衆国のアウトソーシング契約を一定の基盤のもとで行えるとして、称賛している。
CMMIは、組織としての改善の良い枠組みを提供している。CMMIにより企業は自社のプロセス改善計画において優先順位をつけることができる。
改善の比較的初期