CMM（Capability Maturity Model）とは、ソフトウェアプロセスの成熟度モデルのことでソフトウェア開発組織の実態を分析して、5つの成熟段階から構成されるモデルのことです。 最初に提唱したのは、米国カーネギーメロン大学のハンフリー教授です。このモデルの改定版であるCMM Ver1.1が、現在デファクトスタンダードとして世界的に使われています。
成熟度モデルをベースとしたプロセス評価を実施する目的には、次の2つがある。
（1）自組織のプロセス改善（SPA：Software Process Assessment）に利用する。
成熟度モデルに照らして現状のプロセスを分析し、その強み、改善課題を抽出するために利用する場合である。
改善の進捗状況を次のアセスメントでフォローして確認するような利用形態がとられる。
（2）開発ベンダの評価選定（SCE：Software Capability Evaluation）のため
能力の高い開発ベンダ、外注先を選定するために利用する場合である。例えば、発注先の候補として、一定レベル以上の成熟度の達成を条件に設定するような場合である。
CMMはもともと、米国の国防総省をはじめ、政府関係の開発物件に対するベンダの能力を評価する方法として利用されることを念頭に開発されたものであ る。当初は、主に防衛関連の開発などに使われていた。しかし、最近では一般企業での利用が急速に増え、公表されている評価実績数の約3分の2が、商用ソフ トあるいは内部利用ソフト開発への適用となっている。また、その適用目的としては自社組織の改善のための利用が多い。
CMMは世界中で普及しており、適用実績は43カ国（2001年8月現在）に上る。特に最近はインド、中国などのアジア諸国政府が、国の基盤産業として ソフトウェア産業の強化を進めるため、CMMの活用を国の政策として積極的に勧めている。特にインドのソフトウェア開発企業は、成熟度レベルの最高水準で あるレベル5を取得している企業が多い。
わが国でも、前述したように、経済産業省を中心としてプロセス評価手法の普及を促進するための施策が検討されている。また、以前から国内企業もCMMに 準拠したプロセス改善の活動は行われていた。ただし、言語の壁（英語でアセスメントを実施する必要があった）もあり、CMMの公式なアセスメント（認定資 格を有するアセッサーによる評価）を実施した企業の数はそれほど多くはないが、今後は急速に増えると予想される。
それでは現在、デファクトスタンダードとして世界的に広く採用されているCMM Ver.1.1 (Capability Maturity Model Version 1.1)について解説しよう。このモデルは、ソフトウェアプロセスの発展過程を指し示したモデルであり、その他のCMMファミリ（システムエンジニアリン グ用CMM、調達用CMMなど）と区別するために、SW-CMM（CMM for Software）と表記することがある。通常、単にCMMと表記されている場合は、このCMM Ver.1.1のモデルを指すことが多く、ここでもこの表記法に従う。
CMMの構造
CMMは、混沌とした未成熟なソフトウェア組織が、自律的な改善を継続的に行える成熟した組織に発展するためのロードマップを与えている。提示された ロードマップに沿って、ソフトウェア組織が体系立ててプロセスの改善に取り組めるように、CMMは図2に示すような構造を持っている。
図2 CMMの構造。数字は、それぞれに含まれる構成要素の数。The CMM structure: Capability Maturity Model for Software Version 1.1 (CMU/SEI-93-TR-24) by SEI
それでは、実際にCMMを構成する5つのコンポーネントである（1）成熟度レベル、（2）キープロセスエリア、 （3）ゴール、（4）コモンフィーチャ、（5）キープラクティスの概念と相互の関係を説明し、CMMの構造の意味を明らかにしよう。
（1）成熟度レベル
CMMの基本的な考え方の1つに、“優れたツールや技法もその組織の発展段階に応じて導入しなければ効果を生まない”というものがある。この考え方に基 づいて、CMMの最上位構造に5段階の成熟度レベルが定義されている（表1）。この5段階の成熟度レベルによって、アセスメントで対象とするプロセスの絞 り込みや優先すべき改善課題の特定が容易に行え、プロセスの評価改善が効果的かつ効率的に行える。
表1 5段階あるCMMの成熟度レベル 成熟度レベル 概要 特徴 1：初期レベル レベル2に到達していない組織のレベル ・作業の仕方が場当たり的で、ときには混沌的・ほとんどのプロセスは未定義 2：反復できるレベル 基本的なプロジェクト管理が実施できているレベル ・日程、費用、機能性の初歩的管理プロセスを確立・同じ領域の成功経験を反復できるプロセス規律の存在 3：定義されたレベル 組織的にプロセス管理を行っているレベル ・管理プロセスと開発プロセスの定義と統合化・全プロジェクトが文書化されたプロセスを遵守 4：管理されたレベル プロセスおよびプロダクトの定量的管理が実施できているレベル ・プロセスとプロダクトの詳細な品質データを収集・ データに基づいたプロセスとプロダクトの理解と制御 5：最適化するレベル プロセス改善に全員が参加し、改善活動が日常化しているレベル ・プロセスからフィードバックと革新的技術の志向による持続的な改善
一連の成熟度レベルは、ソフトウェア組織の発展の大きな方向性を指し示している。成熟度の各レベルは、ソフトウェア組織のプロセス能力を示している。プロセス能力とは、当該プロセスに沿ってソフトウェア開発を実施した場合に、達成が期待できる成果の範囲のことである。ここでいう成果には、品質、費用、納期などが含まれる。また、プロセス能力と対比して、実際に達成された結果をプロセス実績という。
プロセス評価改善への取り組みで重視すべきことは、狭義のプロセス能力の向上（レベルの達成）を第一義の目的とせず、プロセス実績の向上に主眼を置いた改善活動に取り組むことである。そのためには、QCD（品質、コスト、納期）などの視点から組織としてのプロセス実績の目標（尺度および目標水準）を明確にしたうえで、計測と分析を行い、常にプロセス改善に伴う効果に関心を払う必要がある。
図3に、各成熟度レベルのプロセスの特徴と期待される成果を示す。この図では、レベルの向上に伴って、平均実績値と目標値との乖離が少なくなり（予測能力の改善）、プロジェクト間の実績のばらつきが小さくなり（制御能力の改善）、より高い目標値が達成可能になる（効率の改善）ことが示されている。CMMで期待されるこれらの効果を論理的に証明することは困難であるが、効果を裏付ける多くの事例が報告されている。
2）キープロセスエリア
成熟度レベルには、そのレベルに到達するうえでの主要なプロセス群が含まれる。これらをキープロセスエリアと呼ぶ。ただし、成熟度レベル1はプロセス指向の考え方はほとんど根付いていない状態を表しており、成熟度レベル1にはキープロセスエリアは含まれない。図4にあるように、キープロセスエリアは成熟度レベル2～5に合計18個存在する。
キープロセスエリアは、それを含む成熟度レベルに到達するための主要な活動を特定するものである。ただし、このことは、それ以外のプロセスを実施する必要がないことを意味するものではない。上位の成熟度レベルのキープロセスエリアを効果的かつ効率的に実践するには、それより下位の成熟度レベルのキープロセスエリアが、組織に定着した形で実践されていることが求められる。つまり、明示的ではないが、CMMではレベルを横断したキープロセスエリア間の関係が意識され、下位の成熟度レベルに含まれるキープロセスエリアは、より上位の成熟度レベルのキープロセスエリアを効果的に実装するための前提条件として機能している。表2に成熟度レベル2のキープロセスエリアの目的と概要をまとめた。
なお、参考までに成熟度3のキープロセスエリア（目的と活動概要は省いている）を表3としてまとめた。
（3）ゴール
キープロセスエリアには、達成すべきゴールが定義されている。定義されているゴールの数は、キープロセスエリアごとに2つから4つであり、合計52のゴールが定義されている。ゴールは、後述するキープラクティスと図5のように関連付けられている。
ゴールは、それに関連付けられた一連の活動の趣旨を要約したものであり、組織あるいはプロジェクト内で実践されている活動が効果的に行われているかを判定するための視点を与える
アセスメントを実施する局面では、個々のキープラクティスに対応する作業がそれぞれに行われているかどうかより、ゴールに関連する複数のキープラクティスに対応する作業群を見渡して、一連の活動がゴールで示された趣旨を満たしているかが重視される。
（4）コモンフィーチャ
図5に示したように、CMMではゴールを達成するための作業がキープラクティスにより記述されているが、キープラクティスの切り出しは5つのコモンフィーチャの視点から体系的に行われている。この5つの視点は、すべてのキープラクティスで共通である。5つのコモンフィーチャのうち、「実施される活動」はキープロセスエリアで実施すべき作業が実装されているかを取り上げる属性である。そして「実施のコミットメント」「実施能力」「計測と分析」「履行検証」は、組織内でそれらの作業が制度化されているかを取り上げる属性である。つまりCMMでは、あるキープロセスエリアで実施されるべき活動がある時点、あるプロジェクトで実装されていることだけでなく、それが組織あるいはプロジェクト内の制度として定着した形で行われていることが求められる。
CMMを構成するコンポーネントのうち、5つのコモンフィーチャが定義されている意義を理解することは難しい。そこで、スポーツ選手の筋力強化を1つのキープロセスエリアにたとえ、5つのコモンフィーチャの意義を明確にしてみよう。
あるスポーツチームの監督が直近の大会での優勝に向けて、筋力強化専任のトレーナーを任命し、“毎日1時間以上の筋力トレーニングの実施”という指針を出した。これは「実施のコミットメント」に相当する活動である。この指針に沿って、筋力トレーニングする前に、必要な機器を取りそろえ、機器のメーカー担当者から説明を受けるなどして、その使用方法をトレーナーや各選手が習得する必要がある。これは、「実施能力」に相当する活動である。そのうえで、各選手はトレーナーと相談して日々の筋力トレーニングの計画を立て、それを遂行し、遂行実績を記録・報告する。これらは、「実施される活動」に相当する活動である。
監督とトレーナーから各選手に対して、遂行実績を記した日誌に機器ごとのトレーニング時間を記録し報告することを求め、各選手の筋力トレーニング実施率（筋トレ実施日数／経過日数）、平均筋力トレーニング時間（累積筋トレ実施時間／経過日数）を算出し、遂行状況をトレースする。これは、「計測と分析」に相当する活動である。さらに、トレーナーは各選手から報告される日誌と各選手との個別ミーティングにより、監督はトレーナーからの報告および毎週ごとに行われるチームの全体ミーティングにより、筋力トレーニングの遂行状況や遂行上の問題点の報告を受け、適切なアドバイスを与え、必要に応じて抜本的な対策を打つ。これは、「履行検証」に相当する活動である。
以上によって、筋力強化のプロセスを指針に沿って確実に実施するうえで、5つのコモンフィーチャに沿って実践すべき作業を切り出すことが有効であることが理解できるであろう。CMMでは、あらゆるプロセスに対して、これら5つのコモンフィーチャに則って活動を遂行することを求めている。
（5）キープラクティス
各キープロセスエリアには、そのゴールの達成に寄与するキープラクティスが記述されている。個々のキープラクティスがどのゴールに寄与するかは、上記の図5に示したような形で対応付けられている。この図からも明らかだが、キープラクティスには1つのゴールの達成に寄与するものもあれば、複数のゴールの達成に寄与するものもある。
アセスメントを行う局面では、キープラクティスが評価の視点として利用される。個々のキープラクティスに沿って、組織およびプロジェクト内で実践されている活動の状況が文書レビュー、インタビューなどにより洗い出され、収集された情報に基づいてゴールの達成が判定される。
判定の際の重要な考え方として、ゴール志向の判定というものがある。各キープラクティスで識別された活動の状況が、関連付けられたゴールの達成に寄与する形で実施されているか否かを重視することである。従って、あるキープラクティスに対応する活動がCMMで要求されているからという理由で形式的に実践され、ソフトウェア開発の現場から見ると負荷要因としてしか認識されていないといった事実が判明した場合には、改善事項として対処しなければならない。
また、キープラクティスには、ソフトウェア組織がプロセス活動を効果的かつ効率的に推進するうえで参考になる情報が記述されている。ただし、キープラクティスは実施すべき活動をWhatのレベルで記述しているのであり、Howを記述しているのではない。つまり、各キープラクティスの実践の仕方には、組織特性、製品特性、顧客要求、開発方針などに応じたバリエーションがある。多くのキープラクティスには、アセスメントとプロセス改善の局面で参考となる、実装時の推奨事項や実装例がサブプラクティスまたは補足事項として記述されているが、これらは絶対的な要件ではない。最も重要なことは、ソフトウェア組織内で実際にソフトウェア開発管理に携わっている要員にとって役に立つ活動が実践されることであり、CMMがプロセス評価改善活動においてそれを促進する形で活用されるようにすることである。
CMMに取り上げられた316のキープラクティスを理解することは、管理者、実務者を問わずソフトウェア開発に携わる方々にとって有意義なことと考えるが、限られた紙面でこれらを列挙し解説することは難しい。ここでは、表3でCMMに記述されている典型的なキープラクティスのパターンを、コモンフィーチャごとに表で示すにとどめておく。
当団体のＩＴコーディネータが御社の悩みの相談相手になります。
当団体のＩＴコーディネータを、下記の様なセミナーの講師として派遣します。
