　最初に、CMM（Capability Maturity Model、能力成熟度モデル）のレベル取得に取り組んだ例を紹介します。CMMやCMMI（Capability Maturity Model Integration、能力成熟度モデル統合）は、昨今組み込みソフトウェアの開発でも注目され、大手企業を中心に、レベルを取得しているプロジェクトも増えてきました。

　初めにおさらいの意味も含めて、CMMについて簡単に触れておきます。CMMは、米国カーネギーメロン大学（Carnegie Mellon University）のソフトウェア工学研究所（Software Engineering Institute、SEI）が開発した組織のソフトウェア開発の能力を評価するためのモデルで、ソフトウェアのプロセス改善の指標ともなっています。

　CMMには、1～5までのレベルがあり、レベル1が初期段階で「Chaos（混沌）」ともいわれ、要するにルールがほとんどない、ただ一生懸命開発しているというレベルです。管理は個人に依存していて、組織的には行われていない状態です。レベル2は反復できる段階、レベル3は定義された段階と成熟度が上がっていきます。

　CMMの誕生は、1980年代にさかのぼります。米国国防総省が当時、品質、コスト、納期ともによろしくなかったソフトウェアの開発案件入札の条件として、CMMレベル3以上を要求しました。その後、開発プロセス改善の指標としても使われるようになったのです。

　前置きが少々長くなりましたが、エピソードをご紹介しましょう。

プロジェクトマネージャー　「CMMのレベル3を取得することが決まったという通達がありました。私たちの新規プロジェクトもその対象でした」

その後、説明会が何度か開かれ、記入すべき文書や、ルール、承認の手続きなどが説明され、手順を明記した書類も配布されたそうです。

プロジェクトマネージャー　「それが……合わないんですよ。粒度とか、手順とか、とにかく現実と合わない。別のプロジェクトの中には、合っているところもあるのかもしれないのですが、私たちのプロジェクトにはどうも無理があるのです」

結局、二度手間になっている部分も少なくないとのこと。レベルのお約束で作成するよう指示されているものと、本当に現場で使えるものと、2種類作っている文書もあるというのです。

プロジェクトマネージャー　「CMMのレベルによって能力を判断するというのは、1つのやり方ではあると思います。それを否定するつもりはありませんが、本当にこれでいいんでしょうか。まずCMMありきで、開発の現場を改善するかどうかではなく、ただレベルを取得するためにルールを守り、文書を作っているのが現状です。QCD（Quality、Cost、Delivery）を確保するため、独自のやり方をもう少し生かせる手段はないのでしょうか。私自身は、CMMについてそれほど詳しいとはいえません。でも、これではレベル取得のための作業になってしまっていて、単に作業が増えているだけのような気がします」

　実は、こういう話は珍しくはありません。CMM誕生のきっかけは米国国防総省です。見習う部分はあるとしても、日本の組み込み開発の現場に「丸ごと」持ち込んだところで、現実に合うのかどうか大いに疑問です。

　しかし、CMMはダメというわけでもありません。開発のやり方を工夫して、品質、コスト、納期の改善を目的とするならば、「CMMは使いよう」ともいえるかもしれません。改善の具体的なやり方が分からず、やみくもに走り回るよりは、完成された指標を「参考にする」のは1つのやり方といえるでしょう。

　一方、企業にとってCMMは自分たちの開発体制の成熟度を裏付ける一種の「お免状」でもあり、レベルの取得自体を目的として取り組むケースもあります。ただ、レベルは取得したが、それが実際の開発には生かされておらず、取得後の開発プロセスは改善されていないという現場の話も耳にします。どうやら、CMMのレベルという「看板」を掲げている企業なら、品質、コスト、納期ともに安心といえるほど、単純なものではないようです。

　　　　　　 1|2|3 次のページへ