CMMI の背景

開発のための能力成熟度モデル統合 (CMMI) の最も信頼のおけるガイドは、ソフトウェア エンジニアリング研究所によって発行された『CMMI: Guidelines for Process Integration and Product Improvement (CMMI 標準教本 プロセス統合と成果物改善の指針)』です。 この本は、現時点で最新の CMMI 成果物一式に含まれるモデルの 1 つである、開発のための CMMI (CMMI-DEV) 1.2 版を対象としています。 このモデルは非常に安定しているため、2010 年以降も使用され続けます。 このテーマの本として、これ以外では『CMMI Distilled: A Practical Introduction to Integrated Process Improvement (CMMI モデルガイド)』も有益で読みやすいものになっています。 これらの本の詳細については、このトピックの「その他のリソース」を参照してください。

CMMI は、1987 年に、カーネギーメロン大学ソフトウェア エンジニアリング研究所の能力成熟度モデル (CMM) というプロジェクトとして始まりました。 この研究所は、米国防総省によって設立され、その出資を受けています。 1991 年には、最初のソフトウェア能力成熟度モデルが発行されました。このモデルは、70 年代後半から 80 年代前半のソフトウェア開発プロジェクトの重要成功要因のチェックリストに基づいています。 また、International Business Machines (IBM) Corporation や、20 世紀の品質保証のリーダーである Philip Crosby 氏および W. Edwards Deming 氏のアイディアも取り入れられています。 CMM (Capability Maturity Model) という名前と、段階表現 (後ほど説明します) の 5 つのレベルは、Crosby の Manufacturing Maturity Model から着想を得ています。 主に国防プログラムに適用された CMM は広く普及し、いくつかの改訂とイテレーションが行われました。 その成功の結果、ソフトウェア以外のさまざまなテーマの CMM が開発されました。 新しいモデルの急増によって混乱が生じたため、システム エンジニアリング、ソフトウェア エンジニアリング、および製品開発を統合した単一の拡張可能なフレームワークを作成するために、政府の出資の下、200 人以上の産学の有識者を集めた 2 年間のプロジェクトが行われました。 その成果が CMMI です。

CMMI-DEV についてまず理解しておかなければならないことは、それがモデルであるということです。 CMMI-DEV は、プロセスでも、従うべき処方箋でもありません。 ソフトウェア開発とシステム エンジニアリングの分野で有効であることが証明された、組織の一連の行動です。 ここでは、このようなモデルを使用する理由、 その目的、 およびその最適な使用法 について説明します。これらは、重要な問題である一方で、おそらくは、CMMI について最も誤解されている点でもあります。

このトピックの内容

• モデルを使用する理由

• CMMI モデルの目的

• CMMI モデルの最適な使用法

• CMMI モデルの要素

• その他のリソース

モデルを使用する理由

組織がどのように働き、どのような機能を必要としているのかや、それらの機能がどのようにやり取りするのかを示すモデルがなければ、改善の取り組みを導くことは困難です。 モデルを使用すると、組織内のばらばらの要素を把握できるようになるほか、何を改善する必要があり、どうすればそれを実現できるのかについて議論したり、議論するための言葉を整理したりすることもできます。 モデルの利点を次に示します。

• コミュニケーションのための共通の枠組みと言語が提供される

• 長年の経験を活用できる

• 全体像を念頭に置きつつ改善に集中できる

• トレーナーやコンサルタントによってサポートされている場合が多い

• 意見の相違を解決するための基準になる場合もある

CMMI モデルの目的

先ほど紹介した本には、CMMI モデルの目的は、組織のプロセスの成熟度を評価して、製品の改良につながるようなプロセスの改善についてのアドバイスを提供することであると書かれています。 ソフトウェア エンジニアリング研究所の人々からは、CMMI はリスク管理のためのモデルであり、組織のリスク管理能力の目安になるものであるという答えが返ってくるかもしれません。 この目安は、組織が約束を守ったり、市場の注目を集めるような高品質の製品を提供したりすることの可能性を示す証拠となります。 別のとらえ方をすると、このモデルは、困難な状況に対応する組織の能力を評価するための良い指標になると言えます。 高度に成熟した、能力の高い組織は、予期せぬ困難な状況に遭遇しても冷静に対処し、変化し、前進することができます。 成熟度が低く、能力の低い組織は、困難にさらされるとパニックに陥り、役に立たなくなった手順に盲目的に従ったり、すべてのプロセスを捨てて無秩序な状態になったりします。

CMMI は、組織の経済的成果の指標としては有効ではありません。 成熟度の高い組織は、リスク管理能力や予測可能性が高い一方で、リスクを嫌う傾向があることが証明されています。 これは、革新性の欠如や官僚体質の強化につながり、リード タイムの長期化や競争力の喪失の原因になります。 一方、成熟度の低い企業は、革新性や創造性に優れる反面、無秩序で予測不可能な傾向があります。 結果を出すことができた場合も、個人の英雄的な奮闘の結果であることがよくあります。

CMMI モデルの最適な使用法

CMMI モデルは、プロセス改善の取り組みの基盤として使用されるように作られており、評価においては、改善を測定するためのサポート システムとしてのみ使用されます。 しかし、常に正しく使用されているとは言えず、 CMMI モデルを、既存のプロセスに欠けているものを見つけるための地図ではなくプロセス定義と誤解して、それに従おうとする例が後を絶ちません。 CMMI の基本構成要素はプロセス領域です。プロセス領域では、ゴールと、それを達成するためによく使用されるいくつかの活動が定義されています。 たとえば、プロセスと製品の品質保証、 構成管理などのプロセス領域があります。 プロセス領域はプロセスではないということを理解することが重要です。 1 つのプロセスが複数のプロセス領域にまたがることもあれば、1 つのプロセス領域に複数のプロセスが含まれることもあります。

CMMI-DEV は、実際には、同じ基本要素を共有する 2 つのモデルです。 1 つ目のモデルは、よく知られている段階表現です。このモデルでは、22 のプロセス領域が 5 段階の組織成熟度レベルに割り当てられます。 組織の評定では、組織が現在どのレベルにいるかが評価され、そのレベルが、組織のリスク管理能力、ひいては約束を守る能力の指標になります。

通常は、レベル 4 と 5 が高い成熟度レベルとされます。 定量的な管理や最適化行動を特徴とする成熟度の高い組織と、漠然と経営されているか、定義されたプロセスに従っているだけの成熟度の低い組織との間には、多くの場合、明確な違いがあります。 成熟度の高い組織では、プロセスの変動が少なく、統計的に正当化できる管理方法の一環として主要な指標がよく使用されています。 その結果、成熟度の高い組織は予測可能性が高く、新しい情報への対応も早い傾向があります (官僚体質が妨げにならない場合)。 その一方で、成熟度の低い組織では英雄的な奮闘がよく見られるのに対し、成熟度の高い組織は、困難な状況に陥るとプロセスに盲目的に従ったり、プロセスを変更する必要性に気付かなかったりすることがあります。

もう 1 つのモデルである連続表現は、プロセス能力を 22 のプロセス領域でそれぞれ個別にモデリングして、組織の改善努力を最もビジネス価値の高いプロセスに合わせて調整できるようにします。 これは、Crosby の元のモデルにより近い表現です。 このモデルに対する評定の結果は、1 つの数字ではなく、能力のプロファイルになります。 もちろん、組織の成熟度レベルはほとんどの経営者や経営幹部が理解しているため、連続モデルの評価の結果を 5 段階の評価に割り当てることもできます。

段階モデルをプロセス改善プログラムの基盤として使用する場合、実装者が重要な事実を忘れる危険があります。その事実とは、CMMI はプロセス モデルやワークフロー モデルではなく、プロセスやワークフローの到達すべき目標を提供するものであるということです。 それらの目標を達成することで、組織の成熟度が向上し、計画どおりにことが進む可能性が高まります。 おそらく最大の落とし穴は、成熟度レベルの向上を目標にして、ただ評定に合格するためにプロセスやインフラストラクチャを作成してしまう可能性があることです。 すべてのプロセス改善活動の目標は、数字ではなく、目に見える改善であるべきです。

プロセス改善の手引きとしては連続モデルの方が成功を収めているようで、連続モデルに基づくアドバイスのみを提供しているコンサルティング会社もあります。 最も明白な違いは、連続モデルに基づくプロセス改善プログラムには、成熟度レベルによって決定される機械的な目標がないことです。 また、連続モデルの方が、組織に経済的利益をもたらす可能性が最も高い領域にプロセス改善を適用しやすくなっています。 そのため、連続モデルに従った方が、CMMI モデルに基づく取り組みから肯定的な反応が得られる可能性が高くなります。 さらに、肯定的な反応が得られれば、改善の好循環が生まれる可能性も高くなります。

CMMI モデルの要素

CMMI モデルは、次の表に示す 22 のプロセス領域に分割されています。

段階表現では、次の図のように、プロセス領域が各段階に割り当てられます。

連続表現では、次の図のように、プロセス領域が機能グループに割り当てられます。

各プロセス領域は、必要とされる構成要素、期待される構成要素、および参考の構成要素で構成されています。 モデルに対する評定を達成するために必要なのは、必要とされる構成要素だけです。 必要とされる構成要素は、各プロセス領域の固有ゴールと共通ゴールです。 期待される構成要素は、各固有ゴールまたは共通ゴールの固有プラクティスと共通プラクティスです。 期待される構成要素は期待されているだけで必要とされてはいないため、固有プラクティスや共通プラクティスは同等のプラクティスに置き換えることができます。 期待されるプラクティスは、実装者や評定者のための手引きとして用意されています。 代替プラクティスを使用する場合は、実装者が評定者に報告して、その代替プラクティスが適切とされる理由を示す必要があります。 参考の構成要素には、CMMI モデルに沿ったプロセス改善の取り組みをこれから始めようとする実装者のための詳細情報が用意されています。 参考の構成要素には、共通プラクティスおよび固有プラクティスのサブプラクティスと、典型的な作業生産物が含まれます。

必要とされているのは共通ゴールと固有ゴールだけであるということを理解しておくことは非常に重要です。 その他のものはすべて手引きとして提供されているだけです。 CMMI の文献に示されている期待される構成要素や参考の構成要素の例は、ほとんどの場合、大規模な宇宙システムや防衛システムの統合プロジェクトから取られています。 それらは、カーネギーメロン大学のソフトウェア エンジニアリング研究所の出資者および後援者である企業のプロジェクトであるため、 組織の実際のプロジェクトとは合わなかったり、業界の最新の動向 (アジャイル ソフトウェア開発手法の登場など) が反映されていなかったりする場合があります。

その他のリソース

詳細については、次の Web リソースを参照してください。

• CMMI: Guidelines for Process Integration and Product Improvement (第 2 版) (Mary Beth Chrissis、Mike Konrad、Sandy Shrum 共著、Addison-Wesley Professional、2006 年)

• CMMI Distilled: A Practical Introduction to Integrated Process Improvement (第 3 版) (Dennis M. 著) Ahren、Aaron Clause、Richard Turner 共著、Addison-Wesley Professional、2008 年)

参照

その他の技術情報

MSF for CMMI Process Improvement v5.0