Integration:能力成熟度モデル統合)は、プロジェクト管理やプロセス管理の能力を段階的にレベル表現できるモデルであり、主にシステム開発の分野で利用されている。CMMIの概要、歴史を振り返り、新リリースの変更点を3回に分けて、簡単に紹介する。第1回ではCMMIの概要を紹介した。第2回である本記事では、CMMIの歴史を簡単に紹介する。Institute、以下SEISM)により公開された。CMMの開発の経緯をみると、ソフトウェア関連企業に関する能力評価法の開発という米国連邦政府から要請へ応えるための、SEIでの研究がその前身になっている。ここでは、前回記事で説明した成熟度レベルの概念が確立される様子を中心に、CMMIの前身まで含めた、開発の歴史を紹介する。ソフトウェアへのTQMの適応SEIのソフトウェアプロセス成熟度に対する研究の底流にある基礎的な前提は、ソフトウェア製品の品質の大部分は、ソフトウェアの構築に使われる、開発および保守のプロセスの品質によって決まるというものであった。Management)の原理をソフトウェア開発組織に適応させる研究が行われていた。クロスビーが成熟度という概念を適用した実務経験から作成したものであり、管理者が専門的な品質管理の訓練を受けなくても、5段階に示された品質ポイントをなぞることで品質改善ができるように工夫されたものであった。RadiceはHumphreyの指揮のもと、IBM社のソフトウェア開発プロセスを調査していた。Grid)というモデルを提示した。Radiceは調査にあたり、プロジェクト管理者とソフトウェア開発者と、両方にインタビューしてプロセスの情報を収集しており、インタビューでの確認内容が報告書で要約されている。報告書で示されている内容は、現在のCMMIのアプレイザルでの確認内容にも通じるものがあるため、参考までに、主な確認内容を以下に示す。部門の中で、必要なスキルはどうやって開発/維持してるか?部門に中で、顧客はどの程度意識されているか?部門として、作業の品質を上げるためにしていることはあるか?仕事をするうえで、プロセスに関連して(手順/手続き/ツール/情報伝達などで)問題は起きているか?自分のプロセスを最も改善できるものとして、考えられることは何か?自分の作業に関係するもの(ツール、手順、など)について、何をすれば最も改善できると考えられるか?今回のリリースで使ったプロセスは、以前のリリースで使ったものに対して、何か違うところはあるか?次回のリリースでは、プロセスについて、どんな変化を加えたいと考えているか?Humphreyは、この研究の成果として作成されたプロセス成熟度の概念をSEIに持ち込み、1987年に発表したソフトウェアプロセス成熟度のフレームワークの定義に利用した。ソフトウェアプロセス成熟度のフレームワークと質問票1986年、ソフトウェア関連企業に関する能力評価法の開発を米国連邦政府から要請され、SEIはMITRE社の協力を得ながら、ソフトウェアプロセスの改善を目標とした、プロセスの成熟度に関するフレームワークの開発を開始した。翌1987年、SEIはその成果として、成熟度フレームワークの簡単な定義と、ソフトウェアプロセスの成熟度に関する質問票を発表した。この成熟度フレームワークでは、継続的プロセス改善の一連の土台となる5段階が識別され、あわせて組織のソフトウェアプロセスの成熟度レベルを測定する順序尺度の定義がされた。CMMおよびCMMIの進化のなかでも、常に存在し続ける重要なものとなった。この時期の決定事項のなかで重要なものに、成熟度レベルの違いでは、プロジェクトのコミットメントの識別および管理に注力することと、計画の管理に注力することが重大であるとした決定がある。この決定が、成熟度モデルとCrosbyの品質管理成熟度表などとの大きな違いのひとつになった。CMMやCMMIのV1.3までの各バージョンにおいても、成熟度レベルは、まずプロジェクト管理に関する要求をレベル2で定義し、技術的な手法はレベル3以降で標準化などを要求する内容になっている。アプレイザル手法の開発と正式モデルのニーズ成熟度フレームワークの発表とともに、その成熟度のコンセプトを使って組織のプロセス成熟度を診断することが試みられた。SEIでは、プロセス改善のための自組織の診断と、調達者による業社選定のための診断とを合わせてアプレイザルと呼び、アプレイザル手法の開発も進められた。その結果、プロセス成熟度の判定結果の信頼性をどのように担保するかという懸念が明らかになった。当時は、成熟度の概念に関してHumphreyの知識や理解に依存する部分が大きかったため、今後の普及にあたり、成熟度フレームワークの正式なモデルへのニーズが明らかになった。Process」を出版した。CMM開発を促進させるものとなった。CMMの開発が進められた。v1.0がリリースされた。area)という観点から説明されるようになった。キープロセスエリアは組織がプロセスを改善するために注力すべきところを指し示すものであり、各成熟度レベルでは、複数のキープロセスエリアが定義された。CMMにおける要求事項とされた。キープロセスエリアには、ゴールのほかにも参考情報という位置づけでコモンフィーチャ、キープラクティスなど、様々な詳細情報も含まれていた。CMMの構成要素と構造を図1に示す。図の各要素について例を示すと、表1のようになる。関連するひとまとまりの活動を特定しており、それら全体が実施されれば、プロセス能力の確立に重要と考えられるゴールの集まりが達成される。キープロセスエリアの実装と制度化が効果的で、反復でき、永続するかを示す属性。キープロセスエリアの効果的な実装と制度化に大きく寄与する基盤と活動を記述している。v1.1がリリースされた。これは、主に語句や表現の明確化および一貫性の向上のための変更が加えられており、内容や意図自体の変更はされていない。当時、新しいキープロセスエリアを追加するといった、より大規模な改訂への要求については、v2.0リリースで取り込むという計画になっていた。v2.0の開発は3回の大きなレビュー実施をとおし、ほぼ完成するところまで進んでいた。1997年にスポンサーであった米国国防省の意向によって、CMMI作成に注力するために中止となった。CMMIは当初、以下の成熟度モデルを統合するものとして開発された。CMMにみられるような成熟度の枠組みがソフトウェア開発以外でも応用可能であったために、様々な領域で試みられていたCMMに類似した成熟度モデルの開発があった。v1.0がリリースされた1991年以降では、システムエンジニアリング、ソフトウェアエンジニアリング、ソフトウェア調達、従事者の管理と育成、および統合成果物プロセス開発などについて、CMMと同様の成熟度モデルが開発されていた。これらのモデルは、アーキテクチャ、内容、アプローチなどに差異があり、複数のモデルを使用するのは困難であった。複数のモデルを適用した場合、改善策を広げていくことが難しく、トレーニング、アプレイザル、改善活動などを実施するときコストが高くつくようになっていた。代表、およびSEIによりCMMIプロジェクトが組織され、様々なCMMで扱っている内容を統合するフレームワークとしてCMMIの作成が進められた。今回のまとめ今回の記事はCMMI開発の経緯について、CMMIの前身であるSW-CMMなどを含めて紹介した。CMMIの歴史は、統計的品質管理やTQMの原理のソフトウェア開発組織への適応を試みていた、SEIによるソフトウェアプロセス成熟度の研究までさかのぼることができる。CMMがリリースされた。CMMは米国国防省の意向もあり、システム開発のプロセスなども含めた成熟度モデルであるCMMIへ引き継がれた。V2.0の変更点を紹介する。Mellon大学によって米国特許商標庁に登録されている。Mellon大学の商標。自動車業界で、プロセスアセスメントやソフトウェアプロセス改善のコンサルティングを担当した後、他業種のSIベンダーのプロセス改善支援にも活動を広げている。中央支部からの最新情報をお届けします。有する約1,500名の会員で構成されています。支部員に対するサービス提供に加え、一般のクライアント満足も目指し、診断士の地位向上に向けて活動をしています。経営力UPのお手伝い!ご利用は無料です!支部員の方はこちら中央支部員限定コンテンツのため、閲覧にはID/パスワードが必要となります。ID/パスワードは、毎月第3火曜日に発行している「中央支部eニュース」の中でお知らせしています。