能力成熟度モデル統合 (CMMI) の背景
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
開発のための能力成熟度モデル統合 (CMMI) に関する明確なガイド、『CMMI: Guidelines for Process Integration and Product Improvement』は、ソフトウェア エンジニアリング研究所によって出版されています。この書籍では、CMMI 成果物一式内のモデルの 1 つである、CMMI for Development (CMMI-DEV) バージョン 1.3 について詳しく説明されています。 また、『CMMI Distilled: A Practical Introduction to Integrated Process Improvement』も、CMMI に関する有用で理解しやすい書籍です。
注意
ここで説明するガイダンスは、CMMI のバージョン 1.3 に基づいており、Azure DevOps で使用できる CMMI プロセスに対応しています。 現在、このコンテンツを更新して新しいバージョンをサポートする計画はありません。
歴史に関するメモ
CMMI は、ソフトウェア エンジニアリング研究所 (SEI) のプロジェクトである能力成熟度モデル (CMM) として、1987 年に始まりました。 SEI はカーネギーメロン大学の研究センターであり、米国国防総省によって設立され、資金提供を受けています。 1991 年に初めて公開された CMM for Software は、重要な成功要因のチェックリストとして始まりました。 このモデルは、International Business Machines (IBM) Corporation および 20 世紀の品質保証リーダー (Philip Crosby 氏や W. Edwards Deming 氏など) の研究に基づいて構築されたものでもあります。 CMM (Capability Maturity Model) という名前と、段階表現の 5 つのレベルは、Crosby の Manufacturing Maturity Model から着想を得ています。 主に国防プログラムに適用された CMM は広く普及し、いくつかの改訂が行われました。 その成功の結果、ソフトウェア以外のさまざまなテーマの CMM が開発されました。 新しいモデルの普及は、混乱をもたらしました。 これを受けて政府は、システム エンジニアリング、ソフトウェア エンジニアリング、および製品開発を統合した、単一の拡張可能なフレームワークを作成するための、2 年間のプロジェクトに資金を提供しました。 この取り組みには、200 人以上の業界および学術専門家が関与しました。 その成果が CMMI です。
CMMI-DEV はモデルです。 プロセスでも、従うべき規定でもありません。 CMMI-DEV はソフトウェア開発やシステム エンジニアリングの分野において有用であることが証明された、組織の一連の行動モデルです。 ここでは、このようなモデルを使用する理由、 その目的、 最適な使用法について説明します。 これらの重要な問いは、おそらく CMMI に関して最も誤解されている点です。
モデルを使用する理由
改善の取り組みには、組織の機能や、それらの機能がどのように相互作用するかを示すモデルが必要です。 モデルを使用することで、組織の要素を理解し、改善すべき内容や方法についての議論を促進することができます。
モデルの利点を次に示します。
- コミュニケーションのための共通の枠組みと言語が提供される
- 長年の経験を活用できる
- 改善に焦点を当てながら、全体像を考慮するのに役立つ
- 多くの場合、トレーナーやコンサルタントによる支援を受けられる
- 合意済みの基準を提供することで、意見の食い違いを解決するのに役立つ
CMMI モデルの目的
CMMI モデルの目的は、製品の改良を目標として、組織のプロセスの成熟度を評価し、プロセス改善のためのガイダンスを提供することです。 また、CMMI はリスク管理のためのモデルでもあり、組織のリスク管理能力を測定する手段にもなります。 リスク管理能力は、組織が高品質な製品を提供する能力にも影響します。 リスク管理に関するもう 1 つの視点は、組織がストレス下でどれだけ優れたパフォーマンスを発揮できるかという点です。 成熟度が高く、能力の高い組織は、予期せぬストレスフルな出来事に対しても柔軟に対応できます。 一方、成熟度が低く、能力の低い組織は、困難にさらされるとパニックに陥ったり、時代遅れの手順に盲目的に従ったり、すべてのプロセスを捨てて無秩序な状態に逆戻りしたりする傾向があります。
ただし、CMMI は組織の経済的成果の指標として、その有効性を証明されたものではありません。 成熟度の高い組織は、リスク管理能力や予測可能性も高い一方で、リスクを嫌う傾向があることが証明されています。 この忌避感は、革新性の欠如や官僚体質の強化につながり、リード タイムの長期化や競争力の喪失の原因になる場合があります。 一方、成熟度の低い企業は、革新性や創造性に優れる反面、無秩序で予測不可能な傾向があります。 結果を達成できた場合も、個人の英雄的な奮闘の結果であることがよくあります。
CMMI モデルの最適な使用法
CMMI モデルは、プロセス改善の取り組みの基盤として使用されるように作られており、評価においては、改善を測定するためのサポート システムとしてのみ使用されます。 しかし、常に正しく使用されているわけではありません。 CMMI モデルを、既存のプロセスに欠けているものを見つけるための地図ではなく、プロセス定義と誤解して、それに従おうとする例が後を絶ちません。 CMMI の基本構成要素はプロセス領域です。プロセス領域では、ゴールと、それを達成するためによく使用されるいくつかの活動が定義されています。 たとえば、プロセスと成果物の品質保証、 構成管理などのプロセス領域があります。 プロセス領域はプロセスではないことを理解することが重要です。 1 つのプロセスが複数のプロセス領域にまたがることもあれば、1 つのプロセス領域に複数のプロセスが含まれることもあります。
CMMI-DEV は、実際には、同じ基本要素を共有する 2 つのモデルです。 1 つ目のモデルは、よく知られている段階表現です。このモデルでは、22 のプロセス領域が 5 段階の組織成熟度レベルに割り当てられます。 組織の評定では、組織が現在どのレベルにあるかが評価され、そのレベルが、組織のリスク管理能力、ひいては約束を守る能力の指標になります。
通常は、レベル 4 と 5 が高い成熟度レベルとされます。 定量的な管理や最適化行動を特徴とする成熟度の高い組織と、単純に管理しているか、定義されたプロセスにただ従っている成熟度の低い組織との間には、多くの場合、明確な違いがあります。 成熟度の高い組織では、プロセスの変動が少なく、統計的に正当化できる管理方法の一環として主要な指標がよく使用されています。 その結果、成熟度の高い組織は予測可能性が高く、新しい情報への対応も早い傾向があります (官僚体質が妨げにならない場合)。 その一方で、成熟度の低い組織では英雄的な奮闘がよく見られるのに対し、成熟度の高い組織は、困難な状況に陥るとプロセスに盲目的に従ったり、プロセスを変更する必要性に気付かなかったりすることがあります。
連続表現は、プロセス能力を 22 のプロセス領域でそれぞれ個別にモデリングして、組織の改善努力を最もビジネス価値の高いプロセスに合わせて調整できるようにします。 これは、Crosby の元のモデルにより近い表現です。 このモデルに対する評定の結果は、1 つの数字ではなく、能力のプロファイルになります。 組織成熟度レベルはほとんどの経営者や経営幹部が理解しているため、連続モデルの評価の結果を 5 段階の評価に割り当てることもできます。
段階モデルをプロセス改善プログラムの基盤とする際に、CMMI がプロセスやワークフロー モデルではないことを実施者が忘れると、危険を招く可能性があります。 CMMI はあくまでも、プロセスやワークフローによって達成すべき目標を提示するために設計されたものです。 それらの目標を達成することで、組織の成熟度が向上し、計画どおりに業務を展開できる可能性が高まります。 あるレベルを達成することを目標にして、単に評定に合格するためにプロセスやインフラストラクチャを作成するようなことは避ける必要があります。 すべてのプロセス改善活動の目標は、1つの数字ではなく、測定可能な改善にします。
連続モデルは、プロセス改善のガイドとして成功を収めています。 コンサルティング企業の中には、連続モデルに関するガイダンスのみを提供しているところもあります。 最も明白な違いは、連続モデルに基づくプロセス改善プログラムには、成熟度レベルによって決定される機械的な目標がないことです。 また、連続モデルは、組織に経済的利益をもたらす可能性が最も高い領域にプロセス改善を適用するのに適しています。 このため、連続モデルに従うと、CMMI モデルに基づく取り組みから建設的なフィードバックを受ける可能性が高くなります。 さらに、建設的なフィードバックによって、改善の好循環が生まれる可能性も高まります。
CMMI モデルの要素
次の表に、CMMI モデル (バージョン 1.3) を構成する 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 の文献では、大規模な宇宙プロジェクトや防衛システム プロジェクトからデータが引用されています。 自分の組織で実行される実際のプロジェクトとは合わない場合や、業界の最新の動向 (アジャイル ソフトウェア開発手法の出現など) が反映されていない場合があります。