能力成熟度モデル(CMM)は、1986年に米国国防総省の資金提供を受けて、同省と契約を結んだ組織から収集したデータに基づいて作成された開発モデルです。「成熟度」という用語は、アドホックな慣行から、正式に定義された手順、管理された結果指標、そしてプロセスの積極的な最適化に至るまで、プロセスの形式化と最適化の度合いを指します。
このモデルの目的は既存のソフトウェア開発プロセスを改善することですが、他のプロセスにも適用可能です。
2006年、カーネギーメロン大学のソフトウェアエンジニアリング研究所は、能力成熟度モデル統合(Capability Maturity Model Integration)を開発しました。これはCMMに取って代わり、その欠点のいくつかに対処しています。[ 1 ]
能力成熟度モデルは、もともと政府請負業者のプロセスが契約ソフトウェアプロジェクトを実行する能力を客観的に評価するためのツールとして開発されました。このモデルは、 IEEE Software [ 2 ]で最初に説明され、その後、1989 年にWatts Humphrey著の書籍Managing the Software Processで紹介されたプロセス成熟度フレームワークに基づいています。その後、1993 年に記事として[ 3 ]、1994 年に同じ著者によって書籍として出版されました[ 4 ]。
このモデルはソフトウェア開発の分野から生まれたものですが、一般的なビジネスプロセスを支援するモデルとしても使用されており、政府機関、商業、産業において世界中で広く使用されています。[ 5 ] [ 6 ]
1980年代には、コンピュータの利用がより広範に、より柔軟に、そしてより安価に普及した。組織はコンピュータ化された情報システムを採用し始め、ソフトウェア開発の需要は著しく増加した。しかし、ソフトウェア開発の多くのプロセスはまだ黎明期にあり、標準的な手法や「ベストプラクティス」はほとんど確立されていなかった。
その結果、成長には成長痛が伴いました。プロジェクトの失敗はよくあることで、コンピュータサイエンスの分野はまだ黎明期にあり、プロジェクトの規模と複雑さに対する野心は、計画された予算内で適切な製品を提供する市場の能力を超えていました。エドワード・ヨードン[ 7 ] 、ラリー・コンスタンティン、ジェラルド・ワインバーグ[ 8 ] 、トム・デマルコ[ 9 ]、デビッド・パルナスなどの個人は、ソフトウェア開発プロセスを専門化しようと、研究結果をまとめた記事や書籍を出版し始めました。[ 5 ] [ 10 ]
1980年代、ソフトウェア下請け業者を巻き込んだ米軍のプロジェクトのいくつかは予算超過となり、予定より大幅に遅れて完了したか、あるいは全く完了しなかった。こうした事態の原因を究明するため、米国空軍はソフトウェア工学研究所(SEI)に研究資金を提供した。
ITに対する段階的成熟度モデルの最初の適用は、CMU/SEIによるものではなく、1973年にIT組織の成長段階モデルを発表したリチャード・L・ノーランによるものであった。 [ 11 ]
ワッツ・ハンフリーは、IBMでの27年間のキャリアの後半に、プロセス成熟度の概念の開発を始めた。[ 12 ]
米国国防総省ソフトウェアエンジニアリング研究所(SEI)によるこのモデルの本格的な開発は、ハンフリーがIBMを退職後、ペンシルベニア州ピッツバーグにあるカーネギーメロン大学のソフトウェアエンジニアリング研究所に加わった1986年に始まった。彼は米国空軍の要請を受け、契約締結の一環として米国国防総省がソフトウェア請負業者の能力を評価するのを支援するため、自身のプロセス成熟度フレームワークの体系化に着手した。
空軍の研究の結果、軍がソフトウェア下請け業者のプロセス能力成熟度を客観的に評価するためのモデルが作成された。ハンフリーはこのフレームワークを、フィリップ・B・クロスビーが著書「品質は無料」で開発した品質管理成熟度グリッドに基づいて構築した。 [ 13 ]ハンフリーのアプローチは、組織が特定の順序でプロセス上の問題を解決することによって段階的にプロセスを成熟させていくという独自の洞察に基づいていた点で異なっていた。ハンフリーは、個々の開発プロセスの成熟度を個別に測定するのではなく、組織内のソフトウェア開発プラクティスのシステムの段階的な進化に基づいてアプローチを構築した。そのため、CMMIはさまざまな組織で、一般的なビジネスプロセスのパフォーマンスを理解し、改善するための一般的で強力なツールとして使用されている。
ワッツ・ハンフリーの能力成熟度モデル(CMM)は1988年に発表され[ 14 ] 、1989年には『Managing the Software Process』という書籍として出版された[ 15 ]。
当初、組織は、ハンフリー氏とソフトウェアエンジニアリング研究所の同僚たちが考案したプロセス成熟度アンケートとソフトウェア能力評価手法を用いて評価されていた。
能力成熟度モデルを、5 つの成熟度レベルそれぞれにおける定義されたプロセス領域と実践のセットとして完全に表現する作業は 1991 年に開始され、バージョン 1.1 は 1993 年 7 月に公開されました。 [ 3 ] CMM は、同じ著者である Mark C. Paulk、Charles V. Weber、 Bill Curtis、および Mary Beth Chrissisによって 1994 年に書籍として出版されました。 [ 4 ]
ソフトウェア開発における CMMI モデルの適用は、時に問題となることがあります。組織内および組織間で統合されていない複数のモデルを適用すると、トレーニング、評価、および改善活動にコストがかかる可能性があります。能力成熟度モデル統合(CMMI) プロジェクトは、ソフトウェア開発プロセスに複数のモデルを使用する問題を解決するために設立され、CMMI モデルは CMM モデルに取って代わりましたが、CMM モデルは引き続きパブリック ドメインで使用される一般的な理論的プロセス能力モデルです。[ 16 ] [ 3 ] [ 17 ]
2016年、CMMIの管理責任は情報システム監査・統制協会(ISACA )に移管されました。ISACAはその後、2021年にCMMI v2.0をリリースし、2023年にはCMMI v3.0にアップグレードしました。CMMIはプロセスアーキテクチャを重視しており、これは通常プロセス図として表現されます。CMMIは購読者のみが入手可能です。
CMMIはもともと、政府請負業者が契約したソフトウェアプロジェクトを遂行する能力を評価するためのツールとして考案されました。ソフトウェア開発の分野から生まれたものですが、 IS/IT(およびその他の)組織におけるプロセス(例えば、ITサービス管理プロセス)の成熟度を示す一般的なモデルとして、広く応用されており、現在も応用され続けています。
成熟度モデルとは、組織の行動、慣行、プロセスが、必要な成果をどの程度確実かつ持続的に生み出すことができるかを記述する、構造化された一連のレベルと見なすことができる。
成熟度モデルは、比較のためのベンチマークとして、また理解を深めるための補助ツールとして活用できます。例えば、共通点があり、それを比較の基準とできるような、異なる組織間の比較評価に利用できます。CMMの場合、比較の基準となるのは、各組織のソフトウェア開発プロセスです。
このモデルは5つの側面から構成されています。

このモデルには連続体に沿って5つのレベルが定義されており、SEIによると、「組織のソフトウェアプロセスの予測可能性、有効性、および制御は、組織がこれら5つのレベルを上がるにつれて向上すると考えられています。厳密ではありませんが、これまでの実証的証拠はこの考えを裏付けています」[ 18 ] 。
これらの成熟度レベルそれぞれには、そのレベルを特徴づける主要プロセス領域があり、各領域には目標、コミットメント、能力、測定、検証という5つの要素があります。これらは必ずしもCMMI固有のものではなく、組織が成熟していく過程で経なければならない段階を表しています。
このモデルは、プロセスの成熟度を段階的に向上させていくための理論的な連続体を提供する。段階を飛び越えることは認められていない/不可能である。
このモデルは元々、政府請負業者がソフトウェアプロジェクトを実行する能力を評価することを目的としていました。実際にその目的で使用されており、その目的に適している可能性もありますが、批評家は、CMM に基づくプロセス成熟度が必ずしもソフトウェア開発の成功に必須ではないと指摘しています。[ 21 ]
本書で解説するソフトウェアプロセスフレームワークは、組織またはプロジェクトが主要プロセス領域に準拠しているかどうかを評価したい方を支援することを目的としています。各成熟度レベルごとに、5種類のチェックリストが用意されています。