これはカーネギーメロン大学にあるＳＥＩ（Software Engineering Institute）の W. Humphrey 氏を中心としたグループが１９８９年に発表した、ソフトウェア開発組織（：プロセス）の“能力”を判定する尺度です。
尺度は５段階あって、それぞれ
・レベル１ ― 初期のレベル（Initial）
・レベル２ ― 反復可能なレベル（Repeatable）
・レベル３ ― 定義されたレベル（Defiened）
・レベル４ ― 管理されたレベル（Managed）
・レベル５ ― 最適化するレベル（Optimizing）
と定義されています。
簡単に言えば、レベル１は仕事が約束できないレベルで、レベル２以上は制限は付くかも知れませんが「約束」できるレベルということができます。このレベルの判定は「アセスメント」という手続きで行なわれるのですが、基本的には１００余りの質問に応える形で行なわれるため、判定がぶれることも考えられます。したがって、この考え方に批判的な見解も、殆どがその判定方法に対して向けられたものです。
しかしながら、そのような人たちも、この「プロセスの成熟度」という考え方そのものは、比較的受容しているようです。
また、国防総省（ＤｏＤ）がＳＥＩのこの研究資金を出していることもあって、現在では国防総省のソフトウェアの入札業者の条件として、「レベル３以上」であることが義務づけられています。したがって日本の業者でも国防総省の入札に参加するためには、ＳＥＩなどの評価機関の判定を受けなければなりません。
ハンフリー氏らはこのほかに、プロセスレベルを引き上げるためのプログラム（ＣＭＭ：Capabirity Maturity Model）も公表しており、そこではプロセスのレベルに応じて効果的な取り組みが提案されています。ＣＭＭの主張は、そのプロセスのレベルに相応しくないテーマに取り組んでも効果は上がらないと言う考え方です。実際、レベル１のプロセスの場合、体系だった分析・設計手法や標準の作業手順を導入しようとしても、目の前の仕事の約束が出来ないために、勉強する時間が確保できず、結局のところ途中で挫折してしまいます。
この問題は、私もコンサルティング活動の中で何度か苦い経験したところです。スキルアップの研修を実施しようとしても、作業に計画性が無いために、僅か２時間のセミナーにも拘らず当日になって欠席されてしまいます。その日にセミナーが企画されていることは１ヶ月以上も前に知らされていることですが、レベル１の組織には、そのようなことは問題ないのです。
そのため、ＣＭＭではレベル１のプロセスにおいては、そのような「分析・設計手法」の取り組みは提案されていません。５年間、この内容を知ったとき、私は少なからず衝撃を覚えました。と同時に一つの回答を得たのも確かです。それ以来、レベル１の組織の中でも、ある程度作業のスケジュールが立てられるようになるまで、「手法」を教えることは止めました。ちなみに、レベル１からレベル２に引き上げるための取り組みの項目を以下に列記します。（それ以上のケースは文献２を参考にして下さい）
１）要求管理
２）プロジェクト計画
３）プロジェクトの追跡と監視
４）外注管理
５）品質保証（に繋がる取り組み）
６）構成管理（変更制御も含む）
の６項目です。「分析・設計手法」や「ＣＲ手法」などの取り組みは、レベル２からレベル３に引き上げる際に提案されています。
私も、これまでの経験から、この考え方に賛成です。
また、最近になってハンフリー氏はこの考えを「組織」から「個人」に移しています。「プロセス」というとき、もともと組織だけでなく“個人”も含まれていたのですが、その点を明確にするために「ＰＳＰ（Personal Software Process）」という考え方を前面に打ち出して、個人に対する訓練を開始しています。（文献３）
組織のレベルを上げるには、そこにいる「個人」のスキルを上げなければなりません。しかも「約束」という問題は、単に講義を聞いただけでは実現しまぜん。どうしても“約束するための訓練”が必要になります。実際に、私もコンサルティング活動の中にこの考え方を取り入れていますが、業務を遂行しながらの取り組みになるため、通常、半年から１年の期間を必要とします。それでも訓練を通じて、「約束」するために必要な行動が適時考えられるようになります。そのことは言い換えれば“時間をコントロール出来る”ことを意味しており、その段階になって初めて業務を遂行しながら未来に投資する時間を確保出来るようになります。言い換えれば、この段階になれば「手法」や「技法」など、体系的な知識の修得に時間を割いても、業務の推進に支障を来さなくなるのです。
今日、日本のソフトウェア開発組織の抱えている問題は、殆どが「プロセスの問題」と言っても過言ではありません。つまりレベル１の状態のままでは、何をやっても上手く行かないのです。早くレベル２の状態に引き上げる取り組みに着手しなければ、事態は悪化するばかりです。そしてそこにいるソフトウェア・エンジニアは、まるでコンクリート・ミキサーの深みに引き込まれるばかりです。
【参考文献】
１）「ソフトウェアプロセス成熟度の改善」 日科技連 刊
Ｗ．ハンフリー著、 藤野喜一監訳
ISBN4-8171-6033-0 \8,000
２）「Capabiliry Maturity Model, Version 1.1」 Bill Curtis 他
IEEE Software July 1993 p.p.18-27
３）「A Discipline for Software Engineering」 Addison Wesle 刊
Ｗ．ハンフリー著
ISBN0-201-54610-8