能力成熟度モデル統合

出典: フリー百科事典『ウィキペディア（Wikipedia）』

これはこのページの過去の版です。210.128.115.149 (会話) による 2012年3月5日 (月) 07:55 （個人設定で未設定ならUTC）時点の版 (→‎外部リンク)であり、現在の版とは大きく異なる場合があります。

能力成熟度モデル統合 (のうりょくせいじゅくどモデルとうごう、英: Capability Maturity Model Integration, CMMI) は、組織がプロセスをより適切に管理できるようになることを目的として遵守するべき指針を体系化したものである[1] 。 CMMIは、もともとは能力成熟度モデル (CMM; Capability Maturity Model) として開発された。

概要

CMMIは、組織に5段階のプロセス成熟度レベルに照らして等級をつけて評価するために使うことができる。 CMMIで規定されている各レベルは、評価の対象となる領域のプロセスにおける標準化の程度に応じて、等級づけられている。

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

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

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

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

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

成熟度モデル

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

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

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

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

歴史

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

背景

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

CMMIのモデルは、ソフトウェア開発を行う組織のプロセス成熟度について、5つのレベルを規定している。

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

これらの各レベルには、それぞれの成熟度レベルを特徴づけるキープロセスエリア (KPA) が規定されている。 各キープロセスエリアには4つの要素 (共通特徴、コモンフィーチャ) が定義されている。

  1. 実施のコミットメント
  2. 実施能力
  3. 履行監督
  4. 履行検証

これらキープロセスエリアは必ずしもCMMI特有の要素ではない。 キープロセスエリアという文字通り、組織が成熟して任務を遂行できるようになるために行わなければならない諸段階を、表している。

CMMIによりプロセス改善に取り組む組織は、権威ある検証機関により成熟度レベルの検証を受けることとされている。 このように先ず組織が成熟度レベルの検証を受けることにより、次のレベルの達成に向けた計画を立てることができる。 成熟度レベルの飛び越しは許可されない。

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

商用のパッケージソフトウェアを開発する企業 (クラリス、アップルコンピュータ、シマンテック、マイクロソフト、ロータスなど) の多くは、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 公表。

現状

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

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

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

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

今後の動向

CMMIバージョン1.2が公表されると、SEI は既存の CMMI を CMMI for Development (CMMI-DEV) と改称した[2]。 SEI の援助のもとでノースロップ・グラマン社が主導するチームが CMMI for Services という CMMI のバージョンを開発中である。 この開発には以下の各企業・団体も参加している[3]。

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を参照。

CMMIのレベル

詳細はSEIのCMMIv1.1 (2002年3月の版) 第2章 11ページを参照

CMMI (能力成熟度モデル統合) には5つの成熟度レベルがある。 SEIによると、

組織のソフトウェアプロセスの予測可能性、効率性、および管理は、これらの5つの段階を経て上ることを通じて改善されると確信している。厳格な基準ではないが、経験的な証拠がこの確信を裏づけている。

レベル1 初期

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

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

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

レベル2 管理された

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

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

プロジェクトの情況や納品物の引渡しなどは、事前に定めておいた時点 (メジャーマイルストーンやメジャータスクの完了など) での管理を通して明確になる。

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

レベル3 定義された

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

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

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

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

成熟度レベル4の組織では、正確な測定を行うことで、管理側はソフトウェア開発などの有効性を効果的に制御することができる。 特に、管理側は個別のプロジェクトに対してプロセスを調整し適合する道筋を同定することができる。 このとき測定可能な品質の低減や仕様からの逸脱は無い。 成熟度レベル4の組織は、ソフトウェア開発プロセスやソフトウェア保守などのための定量的な品質の目標を設定する。

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

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

レベル5 最適化している

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

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

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

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

CMMIの拡張

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

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

プロセス領域

CMMI (能力成熟度モデル統合) には成果物開発の観点を示す複数のプロセス領域があり、組織のプロセスを網羅するべく定められている。

能力成熟度モデル統合 (CMMI) のプロセス領域
プロセス領域 区分 成熟度レベル
要件管理 (REQM: Requirements Management) エンジニアリング 2
プロジェクト計画策定 (PP: Project Planning) プロジェクト管理 2
プロジェクトの監視と制御 (PMC: Project Monitoring and Control) プロジェクト管理 2
供給者合意管理 (SAM: Supplier Agreement Management) プロジェクト管理 2
測定と分析 (MA: Measurement and Analysis) 支援 2
プロセスと成果物の品質保証 (PPQA: Process and Product Quality Assurance) 支援 2
構成管理 (CM: Configuration Management) 支援 2
要件開発 (RD: Requirements Development) エンジニアリング 3
技術解 (TS: Technical Solution) エンジニアリング 3
成果物統合 (PI: Product Integration) エンジニアリング 3
検証 (VER: Verification) エンジニアリング 3
妥当性確認 (VAL: Validation) エンジニアリング 3
組織プロセス重視 (OPF: Organizational Process Focus) プロセス管理 3
組織プロセス定義 (OPD: Organizational Process Definition) プロセス管理 3
組織トレーニング (OT: Organizational Training) プロセス管理 3
(IPPDのための) 統合プロジェクト管理 (IPM: Integrated Project Management) プロジェクト管理 3
リスク管理 (RSKM: Risk Management) プロジェクト管理 3
統合チーム編成 (IT: Integrated Teaming) プロジェクト管理 3
統合供給者管理 (ISM: Integrated Supplier Management) プロジェクト管理 3
決定分析と解決 (DAR: Decision Analysis and Resolution) 支援 3
統合のための組織環境 (OEI: Organizational Environment for Integration) 支援 3
組織プロセス実績 (OPP: Organizational Process Performance) プロセス管理 4
定量的プロジェクト管理 (QPM: Quantitative Project Management) プロジェクト管理 4
組織改革と展開 (OID: Organizational Innovation and Deployment) プロセス管理 5
原因分析と解決 (CAR: Causal Analysis and Resolution) 支援 5

論争

ソフトウェア業界内は多様でありまた気まぐれである。 あらゆるソフトウェア開発方法論には支持者と批判者が存在する。 CMMI (能力成熟度モデル統合) も例外ではない。

肯定的見解

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

批判的見解

  • CMMIは、世界的に広く影響を与えるには至っていない。SEIが公表している企業の名称と達成した成熟度レベルだけからは、実際の普及の度合いを正確に知ることは難しい。企業の名称と達成した成熟度レベルは、SEIが企業の要望を受けて一覧にして公表される[4]。CMMIの最近の成熟度の分析はウェブで公表されている[5]。
  • レベル達成は、認定されたリードアプレイザーとそのアプレーザルチームが確認したということであって、SEIそのものが認証しているのではないことに注意が必要である。
  • CMMは官僚的な組織に適している。官僚的な組織とは、例えば政府省庁、大企業、規律正しい専売会社などである。もしCMMを適用する組織が十分に大規模であれば、CMM監査チームを設置して監査結果を経営陣に報告させることができるかもしれない (この監査チーム設置と経営陣への報告は、SEIにより推奨されている)。監査チームと経営陣への報告は、情報技術を担う組織全体に影響を及ぼし、一方でCMMの流儀を完全に達成することを重視するようになるが、他方でアプリケーションソフトウェアの開発や顧客の要求、市場については軽視する結果になるかもしれない。プロジェクトが納期に基づいて遂行される場合、CMMのプロセスと流儀に対する徹底した依存は、納期に間に合わせるためにはじゃまになるかもしれない。これは、とにかく何らかの製品を実際に出荷することが、製品の品質の高さや機能の豊富さよりも重要な場合に、あてはまる。
  • メトリクスによるソフトウェアプロセスの科学的な管理は、CMMIではレベル4以上で言及されている。ビジネスでプロセスの費用低減を検証することはほとんど無く、経験に基づいた根拠を参考にする程度である。望ましいのは、根拠の大部分が、CMMで要するビジネス上の全てのオーバーヘッドにより、情報技術の頭数と、ビジネス上の費用、および顧客を犠牲にすること無く市場に出荷するまでの期間を、低減することに、なっていることである。
  • ソフトウェア開発を担う組織に対してCMMIに準拠していると認定する第3者機関は存在しない。組織自らが正直に検証することが提唱されている ([6]および[7])。
  • CMMは有効なソフトウェア開発組織をどのようにして作るかを記述していない。CMMは成功した組織が行ったベストプラクティスを記述している。CMMに準拠することにより、プロジェクトが成功する保証が得られるわけではない。しかしCMMに準拠することにより、プロジェクトを成功する方向へと改善することは可能である。
  • CMMは、本質的なことの推進よりもCMMに記述されたプロセスを推進しているというように、過度に官僚的な内容だと解釈されることがある。例えば、エンドユーザへのサービスの提供よりも、予測可能性を強調しているというように。商業的に成功している方法論 (例えばラショナル統一プロセス) では、組織が他の組織を満足させるような能力や、仕様全体を満たすソフトウェアを開発する能力には、焦点を当てていない。そうではなく商業的に成功している方法論では、組織が OMG (Object Management Group) の 統一モデリング言語 (UML) の手法に従って、特定のエンドユーザの「ユースケース」を満たす能力に焦点を当てている。
  • CMMIは、「・・・遵守するべき指針を体系化したものである」とする冒頭の説明は誤っている。CMMIは、ベストプラクティスの体系であると言えても、法律や規則ではなく、遵守しさえすれば品質や生産性が向上するというものではない。また、単純に成熟度レベルで組織を比べることはできない。遵守するものであれば、リードアプレイザーはさしずめ裁判官であろう。リードアプレイザーの役割はレベルを判定することではなく、改善をファシリテートすることである。このように間違った理解や言葉使いの誤りが世の中をミスリードする。
  • CMMIは、必ずしも経営状態の改善には寄与しない。事実として、CMMIレベル5を取得してから業績が急降下しているシステム会社も少なくない。（日本では、ジャステック、三菱電機インフォメーションシステムズ等が好例であろう）

CMMIレベル2、レベル3を達成することによる主な利点

  • 開発する対象を記したソフトウェアの仕様を作成すると、発注側の経営者により公に承認される。この仕様は活きた文書ではない。しかし別途、後にソフトウェア開発の次のサイクルに編入される。
  • 技術仕様を使う。この文書はソフトウェア仕様で規定された対象をどのようにして正確に開発するかを記した文書である。この文書は活きた文書である。
  • ソフトウェアコードのメトリクスを使うピアレビューを行う。開発者たちが実装のウォークスルーを行い、実装の改善を促す。
    • 注意: ピアレビューには課題がある。レビューを行うのは既にコードが実装された時点であり、その際にまずい設計を「微調整」で直すことはできない。
    • 参考: リファクタリング
  • バージョン管理を行う。組織の大多数はバージョン管理とリリースの管理を実施していない。
  • ソフトウェアを開発の正しい方法があり、その正しい方法は工学的設計を含む科学的なプロセスであるという思想。

高いCMMIレベルで評価された企業

世界中の非常に多くの情報技術企業が CMMI (能力成熟度モデル統合) とそのレベルに関心をもっている。 1999年6月にインドの Wipro Technologies 社が、SEI CMM レベル5を達成した世界で最初の情報技術サービス企業となった。 レベル5はCMMの最高の水準である。 毎年、世界中の多くの情報技術企業が CMMI の制度を導入し、自社の CMMI レベルを向上させている。 2006年現在、CMMI レベル5を達成した企業の約75%がインドに存在する企業である。 これらの企業の多くはバンガロール市に存在する[要出典]。

完全なリストは List of Published SCAMPI Appraisal Results を参照。 リストは、SEIだけでなく、英国の次のサイトhttp://www.pparegister.com/でも公開されている。

脚注

  1. ^ “Capability Maturity Model®Integration (CMMI®) Version 1.2 Overview” (PDF). SEI (2006年). 2006年10月28日閲覧。
  2. ^ “What is CMMI? - Worldwide Adoption”. SEI (2006年). 2006年10月28日閲覧。
  3. ^ Crosby, Philip (1979). Quality is Free. Mc Graw Hill. ASIN B000K2M9MU. http://www.wppl.org/wphistory/PhilipCrosby/index.html 
  4. ^ Crosby, Philip (1980). Quality is Free (paperback). Mc Graw Hill. ISBN 0-451-62585-4. http://www.wppl.org/wphistory/PhilipCrosby/index.html 
  5. ^ “August 2002 edition of CMMI” (PDF). CMU/SEI-2002-TR-011. SEI (2002年). 2006年10月28日閲覧。
  6. ^ Finkelstein, Anthony (2000年4月28日). “A Software Process Immaturity Model” (PDF). University College London. 2006年10月28日閲覧。
  7. ^ Schorsch, Tom (1996年). “The Capability Im-Maturity Model”. The Air Force Institute of Technology. 2006年10月28日閲覧。

関連項目

  • パーソナルソフトウェアプロセス (PSP) と チームソフトウェアプロセス (TSP) - この2つのプロセスモデルは、ソフトウェア工学研究所 (SEI) により個人とチームにそれぞれ適用するモデルとして開発された。
  • Information Technology Infrastructure Library (ITIL) - 高品質な情報技術 (IT) サービスの提供の促進をめざすベストプラクティスの手法の枠組み。
  • People Capability Maturity Model
  • The SPICE project ⇒ ISO 15504

ある企業が何らかの「エンタープライズレベル」の成熟度レベルを達成したと主張している場合、私たちは懐疑的になる必要がある。 達成したと主張するレベルが高ければ高いほど、より懐疑的になる必要がある。 多くの場合こうした主張はあるときに何らかのプロジェクトを自社で行うことを意図したマーケティング技術である。 その企業が実際に主張する水準のレベルを達成していることはほとんど無い。

参考資料

書籍

ウェブ

外部リンク

「https://ja.wikipedia.org/w/index.php?title=能力成熟度モデル統合&oldid=41506567」から取得