Integration)とは、組織のプロジェクトマネジメント力を5段階評価で表したものです。1980年に発表されたソフトウェア開発を対象にしたCMM(能力成熟度モデル)がベースなのですが、その後エンジニアリングやソフトウェア調達、人材開発などさまざまな分野向けに派生版が生まれました。これらを1999年に統合したものがCMMIで、CMMにI(Integration)という文字が加わっています。CMMIの5段階の成熟度レベルCMMIは組織のプロジェクトマネジメントに関する成熟度(要はプロジェクトマネジメント力)をレベル1からレベル5まで定義しています。下表は、それぞれの成熟度レベルの内容と、そのレベルにあるために必要なプロセス(ツールや実践技法など)を表したものです。レベル1は、属人的なプロジェクトマネジメントに終始している水準であり、必要なプロセスがきちんときまっていません。一応、初歩的な管理プロセスが確立され、同じような仕事なら反復して成功させることができるようになるとレベル2になります。プロジェクトマネジメントにおける管理プロセスと開発プロセスの標準化がなされ、そのテーラリングも行われるようになるとレベル3。品質などのデータを数値化し、データに基づいたプロセスの管理が遂行できるようになればレベル4。改善活動が日常化していて継続的に改善が図られるような組織になっていればレベル5と認定されます。注意して欲しいのは、レベル3が“普通”ではないということです。レベル3は標準的な仕組みを持っており、それを改善しながら管理しているという高度な水準です。ほとんどの企業がレベル1ないしはレベル2の程度であり、プロセス改善によりレベルを上げてゆくことが望まれているのです。表:CMMI5段階の成熟度レベルテーラリングとはテーラリング(仕立て直し)とは、業務遂行やプロジェクトマネジメントの基本として定めた標準を手直しして実用的な標準を作成、実行すること。CMMIの認定(アプレイザル)PMBOKの資格(PMP)はPMIという組織が認定していましたが、CMMIレベルは誰が認定しているのでしょうか。CMMIはカーネギーメロン大学のソフトウェア工学研究所(SEI)が作成したもので、SEIは組織のCMMIレベルを認定できる人(SCAMPIアプレイザー)を教育・認定しています。組織がCMMIレベルの認定を受けるには、この認定アプレイザーとそのチームに依頼してプロジェクトマネジメント状況を評価(アプレイザル)してもらい、定められている水準に達しているかの認定を得る必要があります。CMMIの意義CMMIは、組織のプロジェクトマネジメント力をできるだけ客観的に評価しようという試みです。これまで「あの会社はプロジェクトマネジメント力がある」「あそこはプロジェクトマネジメントがなってない」などと言われていたことを、一定の評価方法と基準に基づいて、きちんと訓練された認定者が5段階のレベルに評価・認定する。このような仕組みを提供したことで、世界中の企業や組織がプロジェクトマネジメント力の強化に対する関心や認識を高めることになりました。企業や組織にとってみると、自分たちのレベルを客観的に認識し、それを改善してもっと高いレベルに持って行こうという意識向上につながります。CMMIレベル3や4、5などの認定を受けていれば、対外的に「プロジェクトマネジメントをしっかりやっている組織だ」ということを大きくアピールできるメリットもあります。以前、中国のソフトウェア会社にオフショア開発の依頼を打診した際、自分たちはCMMIレベル3だということを強くアピールされたことがあります。その内容自体はExcelを駆使した人海戦術的なものでしたが、それでもレベル3を取っているのであれば少なくともプロジェクトマネジメントに対する意識はしっかりしているのだろうと思った記憶があります。CMMIのレベル判定CMMIの基本的な考え方は、このレベルならこれくらいの管理はできていなければならないというモデルに基づいて、組織のマネジメント状況を診断(これをアプレイザルと言う)するものです。評価項目は、プロジェクトマネジメント、エンジニアリング、サポート、プロセスマネジメントという4つの領域に分けられ、レベルに応じて25のプロセスが定義されています。各プロセスにはゴール(目標)と呼ばれる評定基準が設けられています。診断対象のレベルに必要なゴールが満足な状態にあるかどうかをドキュメントの確認やインタビューなどによりアプレイザーチームが診断してレベル判定します。CMMIの対象は企業全体とは限りません。組織が評価・診断を受け、その組織だけが認定を受けるようなケースも一般的です。企業全体ではレベル3、ある部門だけがレベル5というような事例もあります。本稿ではCMMIを「組織のプロジェクトマネジメントの成熟度」の指標と解説していますが、厳密に言うとプロジェクトマネジメント以外にエンジニアリング、サポート、プロセスマネジメントという領域まで適用範囲は広がっています。組織がサポート(保守サービス)業務を行うのであれば、構成管理や成果物の品質保証、障害などの原因分析などを行える仕組み(プロセス)がきちんと用意されているかを診断されるわけです。CMMIで使われるプロセスと言う言葉は、「与えられた目的を達成するために実行される一連の手段」というものです。そのうちソフトウェアプロセスとは「ソフトウェアおよび関連成果物を開発し、保守するのに使用する活動、方法、プラクティスの集合」と定義されています。小難しくて分かりにくいので、筆者は「プロセス」=「仕組み」と理解しています。業務を遂行するのに必要な管理を行う仕組みを診断し、その仕組みをより良くしてゆく作業が「プロセス改善」なのです。CMMIに取り組む本来の目的は、自社の現状レベル(必要な仕組みがどれだけできているか)を知り、それをより良くしてゆくプロセス改善にあると言えます。自分たちの組織の成熟度(マネジメントできる仕組み)を客観的尺度で認識し、その仕組み(プロセス)を改善してゆくというCMMIのアプローチは素晴らしいと思います。CMMIにはいくつかの課題がありますので、それを踏まえた上でどう対処して行くかを考えてみるのが良いでしょう。筆者が一番の課題と感じているのは、レベル判定を受けるための費用が高いということです。日本では、レベル3程度の認定を受けるだけでも1500万円以上かかるとされており、かなり高額です。有効期限は3年なので、3年経ったら再認定を受けなければなりません。したコスト高がCMMIの普及を阻害していると思われます。診断が人による手作業だという点は、課題でもあり利点でもあるでしょう。CMMIが認定した正規のアプレイザ―が、明確に定められたアプレイザルの方法やレベル判定の基準に則って診断するので、いい加減な診断ではありません。それでも人に依ってばらつきが出たり、国によって大盤振る舞いしがちだったりします。した人による手作業であるからこそ、機械的な診断・判定よりも実態をきちんと捉えて、改善プランを明確に提示できると考えられます(それがコスト高の要因にはなっていますが)。診断を受ける側の課題としては、レベル達成を目的としてしまいがちということです。アプレイザーと一緒に調査・分析して見つかったギャップは、組織がプロセスを改善するための貴重な指摘事項です。ギャップを埋めるためのプロセス改善は、その組織に取って真にメリットのある改善でなければなりません。表面的にゴールを満足させるべき“改善にならない改善”で対処してしまうのです。したアプローチを取ってしまうと、レベル認定はされたがプロジェクトの成功率が高まらないという結果になってしまう恐れがあるのです。CMMIとどう向き合うか以前、経済産業省が日本版CMM構想を掲げて、政府調達のソフトウェア発注の応札条件にしようという話がありました。結局、この構想は実現せず、今のところ日本のソフトウェア会社のCMMIへの取り組みはあまり活性化していません。CMMIは組織に対しての認定なので、こうした構想を実現しても運用が難しかったかも知れません。一方で、こうした対外的に実力を示すという目的とは別に、CMMIを活用して自社のプロセス改善に役立てようという企業はじわじわと増えています。企業規模や価値観にもよるのですが、プロセス改善が進んでプロジェクトの失敗が減るならば投資コストも高くないとも考えられます。実はうな重やお寿司のように、アプレイザルにもA、B、C(松、竹、梅)というランクがあります。レベル認定が行われるのはクラスAだけなのですが、もっと手軽なクラスBやクラスCでも自社のプロセス改善というテーマに対しては十分効果は出ます。やればやるだけの成果は必ず出ますので、クラスC、もしくはネットに転がっている情報を元に自分たちでシャドウ―アプレイザルを行うなどして、プロセスの改善課題を洗い出して、改善プランを立てていったらどうでしょうか。CMMIとOBPM組織のプロジェクトマネジメント力を強化する。そのためのアプローチとして人間系で改善課題を洗い出してプロセスを改善するのがCMMIです。OBPMはシステム系で同じ目的を実現しようというアプローチです。本来、プロジェクトマネジメントを行う仕組みというものは普遍的なものであり、企業によって大きな差があるものではありません。あるならば、バーンと理想的な仕組みを組織に導入して、そのシステムの通りにプロジェクトをマネジメントすれば、いっきにCMMIのレベル4相当の成熟度が実現できるという発想です。これはERP的な発想とも言えます。業務改善プロジェクトなどを発足して、現状分析や改善課題の洗い出しを延々と繰り返すより、ERPを導入してできるだけERPに合わせるようにした方が手っ取り早く、効果も大きいと考えています。OBPMは、PMBOKに準拠したプロジェクトマネジメントシステムですが、組織のプロジェクト管理力強化というCMMI的側面を強く持っています。その1つがドメインと呼ばれる標準化です。リスクなどの標準を組織(ドメイン)ごとに用意して、それをテーラリングしてプロジェクト計画を立てます。OBPMでは、このような組織のプロジェクト管理力強化機能を数多く持っており、それらをメインメニューにまとめています(画面2)。右のタブはプロジェクトごとのプロジェクトメニューです。