次の方法で共有

CMMI の背景

  • [アーティクル]

開発のための能力成熟度モデル統合 (CMMI) の最も信頼のおけるガイドは、ソフトウェア エンジニアリング研究所から発行された『CMMI 標準教本 プロセス統合と成果物改善の指針』です。この書籍では、執筆時点で最新の CMMI 成果物一式に含まれるモデルの 1 つである、開発のための CMMI (CMMI-DEV) 1.3 版について説明しています。 このモデルは非常に安定しているため、2010 年以降も使用されると予想されます。 このトピックに関する書籍として、『CMMI モデルガイド』も理解しやすく有益です。 これらの書籍の詳細については、このトピックの「その他のリソース」を参照してください。

CMMI は、1987 年に、カーネギーメロン大学の研究所の 1 つであるソフトウェア エンジニアリング研究所において、能力成熟度モデル (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 の基本構成要素はプロセス領域です。プロセス領域では、ゴールと、それを達成するためによく使用されるいくつかの活動が定義されています。 たとえば、プロセスと成果物の品質保証、 構成管理などのプロセス領域があります。 プロセス領域はプロセスではないことを理解することが重要です。 1 つのプロセスが複数のプロセス領域にまたがることもあれば、1 つのプロセス領域に複数のプロセスが含まれることもあります。

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

CMMI 段階表現

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

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

CMMI 連続表現

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

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

CMMI モデルの要素

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

頭字語

プロセス領域

CAR

原因分析と解決

CM

構成管理

DAR

決定分析と解決

IPM

統合プロジェクト管理

MA

測定と分析

OID

組織改革と展開

OPD

組織プロセス定義

OPF

組織プロセス重視

OPP

組織プロセス実績

OT

組織トレーニング

PI

成果物統合

PMC

プロジェクトの監視と制御

PP

プロジェクト計画策定

PPQA

プロセスと成果物の品質保証

QPM

定量的プロジェクト管理

RD

要件定義

REQM

要件管理

RSKM

リスク管理

SAM

サプライヤー契約管理

TS

技術解

VER

検証

VAL

検証

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

プロセス領域を示す段階表現

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

プロセス領域を示す連続表現

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

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

その他の技術情報

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

参照

概念

Visual Studio ALM 用 MSF for CMMI Process Improvement