CMMIの連続表現と段階表現は何が違うか
ソフトウエア開発の世界では、ときどきCMMI(Capability Maturity Model Integration)という言葉を耳にします。どこどこの会社がCMMIレベル5を取ったんだって、へーえ、それってすごいの? みたいな感じで。そもそもCMMIって何なのでしょうか。
CMMIとは、簡単に言ってしまうと、ソフトウエア開発はこういう風にやればうまく行きまっせというノウハウ集です。ソフトウエアの開発というと、プログラミング言語でガリガリプログラムを作っておしまい、という世界かと思いきや、実はそれは作業のほんの一部に過ぎません。ほとんどの人はほとんどの時間、プログラミング以外の作業をしています。というのも、本当に「使える」ソフトを作るには、いろいろやらなくてはいけないことが山積みなのです。まずそのソフトで何がやりたいのかをはっきりさせて(要件定義)、画面のレイアウトなんかをきちんと決めて(外部設計)、プログラムの構造とか処理の細かい内容を決めて(内部設計)、プログラムが出来上がったらちゃんと動くかすみずみまでテストして……、という段階を踏んで行かないと、途中でわけがわからなくなって失敗してしまいます。またそうやって考えた内容も、きちんと書いて残しておかないと他人には伝わりませんし(文書化)、内容が正しいかほかの人に見てもらわないと、ミスや勘違いでヘンなものができてしまったりもします(レビュー)。さらには、開発の予算はどのぐらいあって今いくら使っちゃってるのかとか、納期はいつでそれには間に合うのかとか、仕様の変更があったら受け入れていいのかとか、アプリのマニュアルはどうするんだとか、使っててバグが出たらどう対応するんだとか、旧バージョンと新バージョンはどうやって持っておくんだとか、それはもうありとあらゆることを考えなくちゃいけません。ですから、あまり経験のない人や組織が何をどうやればいいのか曖昧なまま開発を進めた場合、結果的にものすごくお金がかかったり、納期に遅れたり、ちゃんと動かなかったり、最悪の場合は途中で開発が頓挫してしまったりと、失敗してしまう可能性が高いのは、お分かりいただけると思います。そこで、こういう風にやればうまく行くよというノウハウをまとめたCMMIが役に立つ、というわけです。なお、このような、開発でやらなくちゃいけないいろいろな仕事のことを全部ひっくるめて、一般に開発プロセスと呼びます。
CMMIでは、開発でやらなくちゃいけない仕事を22の領域に分割し、それぞれの領域ごとに目標を掲げ、それぞれの目標を達成するためにはこういうことをやるのがいいよというノウハウをリストアップしています。例えば、上で例に挙げた要件定義は1つの領域になっていて、次の3つの目標が掲げれられています。
- 目標1: お客さんが何を望んでいるかがはっきりしていること
- 目標2: 自分たちが作らなきゃいけないモノがはっきりしていること
- 目標3: お客さんの望みが妥当かどうか分析して確認していること
で、たとえば目標1には次の2つのノウハウが書かれています。
- 目標1へのノウハウ1: 隠れたニーズを引き出せ
- 目標1へのノウハウ2: お客のやりたいことを整理して文書化しろ
……ただし、こういう内容をCMMIはすごーく分かりづらい表現で書いていて、私なんかは一読したぐらいでは何を言っているのかよく分かりません。まず、CMMIでは、22の領域のことをプロセス領域(Process Area、略してPA)と呼び、目標のことを固有ゴール(Specific Goal、略してSG)、それに対するノウハウのことを固有プラクティス(Specific Practice、略してSP)と呼んでいます。で、例えば要件定義に相当するPAは「要件開発」(Requirements Development、略してRD)で、RDの3つのSGは、
- SG1: 顧客要件を開発する
- SG2: 成果物要件を開発する
- SG3: 要件を分析し妥当性を確認する
です。SG1に対する2つのSPは、
- SP1.1: 成果物ライフサイクルのすべてのフェーズについて、利害関係者のニーズ、期待、制約、およびインタフェースを引き出す
- SP1.2: 利害関係者のニーズ、期待、制約、およびインタフェースを顧客要件に変換する
という具合です(ここで挙げた表現は、CMMI-DEV V1.2の日本語訳を引用)。もうムズカシイ言葉と略語のオンパレードでわけわからんという感じだと思いませんか?
さて、では話を戻して、そういうノウハウ集であるはずのCMMIのレベル5を取るとは一体どういうことでしょうか。実はCMMIというのは、ある組織がそのノウハウ集に照らしてどのぐらいちゃんとできてるかを測るモノサシでもあるのです。モノサシには1から5までのレベルがあって、
- レベル1: 何も決めてなくて行き当たりばったり、うまくいくかどうかは個人の技量と運まかせ
- レベル2: 開発はこういう風にやれというのがプロジェクトごとにはだいたい決まっているけど、他のプロジェクトに行くと流儀が変わる
- レベル3: 開発はこういう風にやれという組織全体の決まりがあって、プロジェクトごとにここは変えてもいいよという箇所が決まっている
- レベル4: 進捗とか品質とか予算とかいろんなことを数字で測って分析して、ヤバい兆候があれば対処してる
- レベル5: 今のやり方が経営目標と合ってないところを探してその原因を考え、やり方そのものを常に軌道修正している
という感じです。各レベルにはそれぞれ対応する領域が割り当てられていて、その領域の全ての目標を達成していないとダメ、ということになっています。このレベルは言ってみれば、その組織の総合評価です。CMMIのレベル5を取るということは、その組織の開発のやり方を総合評価してみたらレベル5の状態に達していた、ということです。ちなみにこの総合評価のことを、CMMIでは段階表現(Staged Representation)と呼び、1~5のレベルのことを成熟度レベル(Maturity Level、略してML)と呼んでいます。
これだけで終われば話は簡単なのですが、実はCMMIにはもうひとつ別のモノサシがあります。それは、22の領域ひとつひとつについて、どのぐらいちゃんとできているかを0から3のレベルで表すという方法です。言ってみれば、個々の科目の個別評価です。レベルの内容は次のような感じです。
- レベル0: その領域の目標のなかに、達成できていないものがある
- レベル1: その領域の目標は全部達成できてるけど、やり方がちゃんと決まってなくて、時間が経つとまた達成できなくなる
- レベル2: その領域の目標は全部達成できてて、やり方もプロジェクトごとにはだいたい決まっているけど、他のプロジェクトに行くと流儀が変わる
- レベル3: その領域の目標は全部達成できてて、やり方も組織全体の決まりがあって、プロジェクトごとにここは変えてもいいよという箇所が決まっている
ここで言うレベルは、総合評価のレベル1~5とは全くの別物です。CMMIでは、この個別評価のことを連続表現(Continuous Representation)と呼び、0~3のレベルのことを能力レベル(Capability Level、略してCL)と呼んでいます。(なお、CMMI-DEV V1.2までは能力レベルにもレベル4と5が存在していましたが、分かりにくいという理由でV1.3では廃止されています。ここがV1.2とV1.3の最大の違いです。)
そして、個別評価の結果は、総合評価に変換できることになっています。というのも、前述のとおり総合評価のレベルにはそれぞれ対応する領域が割り当てられているので、
- 総合評価のレベル2に割り当てられている領域がぜんぶ個別評価のレベル2だったら、総合評価はレベル2
- 総合評価のレベル2と3に割り当てられている領域がぜんぶ個別評価のレベル3だったら、総合評価はレベル3
- 総合評価のレベル2と3と4に割り当てられている領域がぜんぶ個別評価のレベル3だったら、総合評価はレベル4
- 総合評価のレベル2と3と4と5に割り当てられている領域がぜんぶ個別評価のレベル3だったら、総合評価はレベル5
という風に変換ができるというわけです。個別評価にはレベル3までしかないのに総合評価ではレベル4とか5に相当する場合がある、というのが分かりにくいところだと思いますが、これは総合評価のレベル4に割り当てられている2つの領域が「数字で状況を測る」ことに関する領域で、総合評価のレベル5に割り当てられている2つの領域が「常に軌道修正する」ことに関する領域だから、と言えば理解していただけるのではないでしょうか。
簡単にまとめると、CMMIの「連続表現」とは開発プロセスの各領域の「個別評価」のことで、「段階表現」とは組織全体の「総合評価」のこと、そして個別評価は総合評価に変換可能、ということになります。
……などと分かったようなことを書き連ねてきましたが、私もCMMIに関してはド素人で、ふと疑問に思ったことについてCMMI文書をナナメ読みしてみたらこんな感じ? というレベルですので、話が大雑把すぎたり(だいたいGGとGPについては何も触れてないし……)、認識違いをしていたりということがあるかと思います。あくまで、こういうイメージを押さえてCMMIを眺めると多少は分かりやすいかも、という程度にお考え下さい。
※「CMMIのGG、GPとは何か」に続きを書きました。
※バージョンメモ
- CMMI-DEV V1.3