CMMIとは
CMMI（Capability Maturity Model Integration）とは、組織のプロジェクトマネジメント力を5段階評価で表したものです。もともとは1980年に発表されたソフトウェア開発を対象にしたCMM（能力成熟度モデル）がベースなのですが、その後エンジニアリングやソフトウェア調達、人材開発などさまざまな分野向けに派生版が生まれました。これらを1999年に統合したものがCMMIで、CMMにI（Integration）という文字が加わっています。
CMMIの２つの表現
CMMIには２つの表現方法があり、組織のプロセス改善の目的に応じて選びます。
１：プロセスの領域が機械的に決まる「段階表現」
段階表現は、プロセス領域が機械的に決まる表現方法です。以下の５段階で組織のレベルが表現されます。
- レベル１
- 初期
- レベル２
- 管理された
- レベル３
- 定義された
- レベル４
- 定量的に管理された
- レベル５
- 最適化している
この5つのレベルでそれぞれにやるべきこと（改善すべきプロセス領域）が決まっており、それを達成することで上のレベルに上がります。やるべきことがはっきりしているため、何から始めてよいのか分からない場合は段階表現が適しています。
２：プロセス領域を自由に選択できる「連続表現」
連続表現は、プロセス領域を自由に選択できる方式です。たとえば、プロセスのうち要件管理だけを改善するという選択も可能です。それぞれのプロセスの成熟度は、以下の6段階のレベルで表現されます。
- レベル０
- 不完全な
- レベル１
- 実施された
- レベル２
- 管理された
- レベル３
- 定義された
- レベル４
- 定量的に管理された
- レべル５
- 最適化している
各プロセスごとにこれらのレベルが設定されます。下位レベルで求められる能力を満たすことで、上位のレベルに上がります。どのプロセスを改善したいのかがはっきりしている場合は、連続表現が適しているでしょう。
CMMIの5段階の成熟度レベル（5つの指標）
CMMIは組織のプロジェクトマネジメントに関する成熟度（要はプロジェクトマネジメント力）をレベル１からレベル５まで定義しています。下表は、それぞれの成熟度レベルの内容と、そのレベルにあるために必要なプロセス（ツールや実践技法など）を表したものです。
レベル1は、属人的なプロジェクトマネジメントに終始している水準であり、必要なプロセスがきちんときまっていません。一応、初歩的な管理プロセスが確立され、同じような仕事なら反復して成功させることができるようになるとレベル2になります。
プロジェクトマネジメントにおける管理プロセスと開発プロセスの標準化がなされ、そのテーラリングも行われるようになるとレベル３。品質などのデータを数値化し、データに基づいたプロセスの管理が遂行できるようになればレベル４。そして改善活動が日常化していて継続的に改善が図られるような組織になっていればレベル５と認定されます。
注意して欲しいのは、レベル3が“普通”ではないということです。レベル3は標準的な仕組みを持っており、それを改善しながら管理しているという高度な水準です。ほとんどの企業がレベル1ないしはレベル2の程度であり、プロセス改善によりレベルを上げてゆくことが望まれているのです。
表：CMMI5段階の成熟度レベル
|
テーラリングとは |
レベル1 - 初期レベル
レベル１はプロセスが定義されておらず、場当たり的である状態です。そのため、そのプロセスの成否は担当者の努力に依存します。
まったくプロセスが定まっていないため、担当者は手探りで方法を模索するしかありません。そのためプロセスは常に変動し、一定の安定性が確保できません。スケジュールの予想が立てづらい、成果物の品質にばらつきが生じるなどの問題が発生します。
レベル2 - 反復できるレベル
レベル２は、プロセスの基本が確立されている状態です。基本的な手順が決まり、再現が可能な状態といえます。新規のプロジェクトを始める際も、過去のプロジェクトのプロセスを参考にできるため、１から考える必要がありません。スケジュールの見通しも立てやすく、成果物の品質も安定するでしょう。
レベル3 - 定義されたレベル
レベル３は各プロセスが標準化されている状態です。方法の文書化やスタッフの熟練が進み、効果的にプロセスを進められます。プロセスにおける技術的な側面も標準化が進み、レベル２よりもスムーズに進行できる状態です。
レベル２よりも高い精度でプロセスを管理できるため、スケジュールやリスクの管理もさらに緻密になります。発生したトラブルに対処できるだけでなく、未然に防止できる状態です。また、標準化するためには異なるプロジェクト間での情報共有なども欠かせません。レベル３は組織内での風通しが良く、組織としての一貫性が保たれている状態といえるでしょう。
レベル4 - 管理されたレベル
レベル４はプロセスが定量的に管理されている状態です。
作業の手順や進捗状況、成果物の品質を数値化することで、より客観的な管理を実現します。この定量化データの収集・分析は単一のプロジェクトではなく、組織内で横断的に行われる必要があります。企業として一貫した判断基準を持つ必要があるためです。
定量的な管理が実現すれば、品質の予測が容易になります。許容可能な品質を設定し、その範囲内に収めることで、安定したプロダクトを提供し続けられるでしょう。
レベル5 - 最適化するレベル
レベル５はプロセスが最適化されている段階です。具体的には、以下のようなことが実現した状態を指します。
- 継続的なプロセス改善
- トラブルの予測と対策
- 新しい提案や技術の費用対効果分析
- 組織全体での情報共有
レベル１～４で達成すべきことを満たし、そのうえで継続的な改善を続けている状態といえます。
CMMIの認定（アプレイザル）
PMBOKの資格（PMP）はPMIという組織が認定していましたが、CMMIレベルは誰が認定しているのでしょうか。もともとCMMIはカーネギーメロン大学のソフトウェア工学研究所（SEI）が作成したもので、SEIは組織のCMMIレベルを認定できる人（SCAMPIアプレイザー）を教育・認定していました。カーネギーメロン大学は2012年にCMMI研究所(Institute)を設立し、同研究所がSEIの役目を引き継いでいます。
組織がCMMIレベルの認定を受けるには、この認定アプレイザーとそのチームに依頼してプロジェクトマネジメント状況を評価（アプレイザル）してもらい、定められている水準に達しているかの認定を得る必要があります。
CMMIはCMMI研究所によりバージョンアップされており、2010年にVer1.3が発表されアジャイルソフトウェア開発をサポートしました。そして2018年にVer2.0が公開され、「開発」「サービス」「買収」という3つの領域が統合されています。Ver2.0はCMMI研究所により日本語に翻訳され、ホームページで公開・ダウンロード提供されています。なお、CMMI研究所は2016年にISACA（情報システム監査および管理協会）に買収されています。
CMMIの意義
CMMIは、組織のプロジェクトマネジメント力をできるだけ客観的に評価しようという試みです。これまで「あの会社はプロジェクトマネジメント力がある」「あそこはプロジェクトマネジメントがなってない」などと言われていたことを、一定の評価方法と基準に基づいて、きちんと訓練された認定者が5段階のレベルに評価・認定する。このような仕組みを提供したことで、世界中の企業や組織がプロジェクトマネジメント力の強化に対する関心や認識を高めることになりました。
企業や組織にとってみると、自分たちのレベルを客観的に認識し、それを改善してもっと高いレベルに持って行こうという意識向上につながります。また、CMMIレベル3や４、5などの認定を受けていれば、対外的に「プロジェクトマネジメントをしっかりやっている組織だ」ということを大きくアピールできるメリットもあります。以前、中国のソフトウェア会社にオフショア開発の依頼を打診した際、自分たちはCMMIレベル3だということを強くアピールされたことがあります。その内容自体はExcelを駆使した人海戦術的なものでしたが、それでもレベル3を取っているのであれば少なくともプロジェクトマネジメントに対する意識はしっかりしているのだろうと思った記憶があります。
CMMIのレベル判定
CMMIの基本的な考え方は、このレベルならこれくらいの管理はできていなければならないというモデルに基づいて、組織のマネジメント状況を診断（これをアプレイザルと言う）するものです。評価項目は、プロジェクトマネジメント、エンジニアリング、サポート、プロセスマネジメントという4つの領域に分けられ、レベルに応じて25のプロセスが定義されています。
各プロセスにはゴール（目標）と呼ばれる評定基準が設けられています。診断対象のレベルに必要なゴールが満足な状態にあるかどうかをドキュメントの確認やインタビューなどによりアプレイザーチームが診断してレベル判定します。
なお、CMMIの対象は企業全体とは限りません。組織が評価・診断を受け、その組織だけが認定を受けるようなケースも一般的です。企業全体ではレベル3、ある部門だけがレベル５というような事例もあります。
表：CMMIの5レベルに対応したチェック対象プロセス
プロセス改善
本稿ではCMMIを「組織のプロジェクトマネジメントの成熟度」の指標と解説していますが、厳密に言うとプロジェクトマネジメント以外にエンジニアリング、サポート、プロセスマネジメントという領域まで適用範囲は広がっています。たとえば組織がサポート（保守サービス）業務を行うのであれば、構成管理や成果物の品質保証、障害などの原因分析などを行える仕組み（プロセス）がきちんと用意されているかを診断されるわけです。
CMMIで使われるプロセスと言う言葉は、「与えられた目的を達成するために実行される一連の手段」というものです。そのうちソフトウェアプロセスとは「ソフトウェアおよび関連成果物を開発し、保守するのに使用する活動、方法、プラクティスの集合」と定義されています。ちょっと小難しくて分かりにくいので、筆者は「プロセス」＝「仕組み」と理解しています。
つまり、業務を遂行するのに必要な管理を行う仕組みを診断し、その仕組みをより良くしてゆく作業が「プロセス改善」なのです。CMMIに取り組む本来の目的は、自社の現状レベル（必要な仕組みがどれだけできているか）を知り、それをより良くしてゆくプロセス改善にあると言えます。
CMMIの課題
自分たちの組織の成熟度（マネジメントできる仕組み）を客観的尺度で認識し、その仕組み（プロセス）を改善してゆくというCMMIのアプローチは素晴らしいと思います。しかし、CMMIにはいくつかの課題がありますので、それを踏まえた上でどう対処して行くかを考えてみるのが良いでしょう。
筆者が一番の課題と感じているのは、レベル判定を受けるための費用が高いということです。日本では、レベル3程度の認定を受けるだけでも1500万円以上かかるとされており、かなり高額です。また、有効期限は3年なので、3年経ったら再認定を受けなければなりません。こうしたコスト高がCMMIの普及を阻害していると思われます。
診断が人による手作業だという点は、課題でもあり利点でもあるでしょう。CMMIが認定した正規のアプレイザ―が、明確に定められたアプレイザルの方法やレベル判定の基準に則って診断するので、いい加減な診断ではありません。それでも人に依ってばらつきが出たり、国によって大盤振る舞いしがちだったりします。ただし、こうした人による手作業であるからこそ、機械的な診断・判定よりも実態をきちんと捉えて、改善プランを明確に提示できると考えられます（それがコスト高の要因にはなっていますが）。
診断を受ける側の課題としては、レベル達成を目的としてしまいがちということです。アプレイザーと一緒に調査・分析して見つかったギャップは、組織がプロセスを改善するための貴重な指摘事項です。ギャップを埋めるためのプロセス改善は、その組織に取って真にメリットのある改善でなければなりません。しかし、得てして表面的にゴールを満足させるべき“改善にならない改善”で対処してしまうのです。こうしたアプローチを取ってしまうと、レベル認定はされたがプロジェクトの成功率が高まらないという結果になってしまう恐れがあるのです。
CMMIとどう向き合うか
以前、経済産業省が日本版CMM構想を掲げて、政府調達のソフトウェア発注の応札条件にしようという話がありました。結局、この構想は実現せず、今のところ日本のソフトウェア会社のCMMIへの取り組みはあまり活性化していません。また、CMMIは組織に対しての認定なので、こうした構想を実現しても運用が難しかったかも知れません。
一方で、こうした対外的に実力を示すという目的とは別に、CMMIを活用して自社のプロセス改善に役立てようという企業はじわじわと増えています。企業規模や価値観にもよるのですが、プロセス改善が進んでプロジェクトの失敗が減るならば投資コストも高くないとも考えられます。
実はうな重やお寿司のように、アプレイザルにもA、B、C（松、竹、梅）というランクがあります。レベル認定が行われるのはクラスAだけなのですが、もっと手軽なクラスBやクラスCでも自社のプロセス改善というテーマに対しては十分効果は出ます。やればやるだけの成果は必ず出ますので、クラスC、もしくはネットに転がっている情報を元に自分たちでシャドウ―アプレイザルを行うなどして、プロセスの改善課題を洗い出して、改善プランを立てていったらどうでしょうか。
CMMI Ver2.0で変更されたポイント
(1) 3つの領域をV2.0でまとめた
CMMIは対象分野により「開発のためのCMMI」「サービスのためのCMMI」「買収のためのCMMI」という3つのモデルがありました。バージョン2.0ではこれらの3つの領域が1つのモデルにマージされています。
(2) V2.0のアーキテクチャー
V2.0では組織の成熟度を高めるためのプラクティス（実践）を「実行」「管理」「支援」「改善」という4つの大分類、9つの中分類（能力領域）、20の小分類（プラクティス領域）で整理しています。なお、V1.3のプロセス領域は、V2.0ではプラクティス領域と呼ばれています。
20のプラクティス分類の中には、レベル1からレベル5までのプラクティスが定義されています。表1は各プラクティス分類の中にいくつプラクティスが定義されているかを表したものです。例えば、DMS（サービスの提供と管理）のSTSM（戦略的サービス管理）の中には、表2のようにレベル1が1つ、レベル2が3つ、レベル3が1つのプラクティスがあります。
表1：CMMI2.0のプラクティス分布
表2：（サンプル）戦略的サービス管理で定義されているプラクティス
表1は視点を変えてレベルごとに見ます。例えばCMMIレベル2を達成するためには、レベル1に含まれるプラクティスとレベル2に含まれるプラクティスをすべてカバーする必要があります。
CMMIとOBPM
|
組織のプロジェクトマネジメント力を強化する。そのためのアプローチとして人間系で改善課題を洗い出してプロセスを改善するのがCMMIです。一方、OBPMはシステム系で同じ目的を実現しようというアプローチです。 画面２：組織のプロジェクトマネジメントを行うためのメインメニュー |
この記事の著者
株式会社システムインテグレータ 代表取締役会長
梅田 弘之
1995年に株式会社システムインテグレータを設立。2006年東証マザーズ、2014年東証第1部、2021年東証スタンダード上場。ECパッケージ「SI Web Shopping」や開発支援ツール「SI Object Browser」、統合型プロジェクト管理システム「OBPM Neo」など独創的なアイデアの製品を次々とリリース。また、ERP「GRANDIT」をコンソーシアム方式で開発。2019年に著書「AIのキホン」を出版し、現在はThinkITで「エンジニアならしっておきたいGPTのキホン」を連載中。
