CMMIなら、どんなチームも開発効率を改善できる：今日からできる“CMMI流”開発効率改善術（1）（2/2 ページ）

[矢部智, 岡本隆史，NTTデータ]

CMMIを使えば組織の現状と目標がすっきり分かる

　では、前のページと少し重複しますが、まず「CMMIとは何か」から簡単にご紹介しましょう

　CMMIは米国のカーネギーメロン大学ソフトウェアエンジニアリング研究所 （以下SEI）が開発・公開している、ソフトウェア開発のノウハウを詰め込んだ知識体系です。専門用語では「プロセスモデル」とも言われます。正式名称は 「CMMI for Development （開発のためのCMMI）」と言い、V1.3では開発以外のビジネスについても「CMMI for Services（サービスのためのCMMI）」「CMMI for Acquisition（調達のためのCMMI）」があり、全部で3つのプロセスモデルがリリースされています。

　本連載で取り上げるCMMI for Developmentは、「継続的にソフトウェア開発をしている組織では、開発プロセスが成熟していく」という仮定に基づき、5段階のレベルを定めている点が特徴です。

図1 CMMI 5段階のレベル

　レベル5は「変化し続ける事業環境に応じて、適切なビジネス目標を設定し、データ分析を基に（開発の）改善策を実施し、目標達成に貢献している」状態を指します。例えば、「現在の品質を維持しながら、開発コストを10％削減するには？」といった難しい課題に取り組めることを指しています。

　レベル4は「蓄積された定量データを分析し、数値で意志決定ができるようになること」を指します。 これは数値データを利用することで、“プロジェクトの途中で将来の予測ができるようになる”という点がポイントです。例えば、プロジェクトが中盤まで進んだ時点で「最終的なコストはどれくらいで収まりそうなのか」といった不確実性を含んだ課題に対処できるようになることを意味しています。

　レベル3は「複数のプロジェクトからなる、組織としてのプロセスの標準化・情報共有と、 レベル4に向けて定量データの蓄積を行うこと」を指します。「標準化」というと重いテーマのように感じられるかもしれませんが、周りの人が開発したノウハウの流用により、お互いの作業が楽になるというメリットがあります。

　レベル2は 「単一のプロジェクトで、見積もりや進ちょく管理などの基本的なプロジェクト管理ができるようになること」。レベル1はそれ以前の状態を指し、「プロジェクトの状況が把握できていない」状態です。

　つまりCMMIとは、開発のやりかた（＝プロセス）のレベルを5段階に分けて定義付けすることで、経験や技量が異なるさまざまな組織の“現在のレベル”を共通のものさしで測り、次に目指すべき目標を明確化できるものなのです。

　この図1に当てはめてみると、皆さんの組織はどのレベルに当てはまりますか？ もし「日々の進ちょく管理で戸惑っているような状態」ならレベル2から、「日々の作業はスムーズに遂行できているが、関連部門との連携や情報共有が課題だ」と感じるならレベル3から、「情報共有はできているが、その活用をもっと進めて、組織全体としての収益の改善につなげたい」ならレベル4と考え、次のレベルを目指してCMMIの該当箇所を読むと、必ずや有効なヒントが得られると思います。

各標準モデルの“いいとこ取り”をした全部入りモデル

　ただ、とても便利なCMMIですが、ある種の先入観から、CMMIに対するさまざまな誤解があることも事実です。中でも典型的な誤解は、「各標準モデルはお互いに排他的で、ある標準（例えばスクラム開発）を使っていると、他の標準（例えばCMMI）は適用できない」というものです。

　確かに、各標準モデルのドキュメントには、それぞれ異なる点がたくさんあります。 しかし標準モデルとは、どれも「開発の進め方をより良くする」ことを狙って策定されたものです。その点で、「お互いに矛盾することを主張する」とは考えにくいのではないでしょうか。そこで誤解を解消できるよう、「同じ目標なのに違いがあるとしたら、その違いは何なのか」を簡単に説明しておきましょう。

　以下の図2をご覧ください。

図2 IT業界で使用されている主要な業界標準と、そのカバー範囲。ピンク色のカコミのように、「より大規模な組織でアジャイル開発を」と考えると、おのずと組織運営のノウハウが必要になるが、CMMIは組織運営、定量分析まで全てをカバーしている

　これはIT業界で使用されている主な標準モデルと、そのカバー範囲を示したものです（厳密に見れば不正確な部分もありますが、ここでは各標準モデルの違いを大まかに理解することが目的なので、正確性についてはあえて無視しています）。

　まずは図2の最上段を見てください。ここでは開発にまつわる各種作業を大きく4つの領域に分けています。設計や試験など成果物を作る「開発」、開発作業の状況を管理する「管理」、企業単位、事業部単位での標準化や情報共有活動などを指す「組織運営」、組織のパフォーマンス改善に向けて、数値データから現状を分析し、対策を立案・実行する「定量分析」の4つです。

　図はこうした各種作業に対して、PMBOKなどの各標準モデルがどのように対応しているかを視覚化したものです。例えば、PMBOKはプロジェクト「管理」に特化したもので、プログラミングやテストなど、システム「開発」そのものについては言及していません。一方、チーム運営、設計、コーディング、テストなども対象としているスクラム開発は、「開発」と「管理」の両方をカバーしていることが分かると思います。

　この図にCMMIを当てはめると、開発から管理、組織運営、定量分析まで全てをカバーした“全部入りモデル”となります。CMMIを他の標準モデルと比べたときの特徴は、単一のプロジェクトだけではなく、複数のプロジェクトの成功を狙う「組織としてのビジネスの成功」を目指しているところにあると言えるでしょう。

　また、もう1つ、この図から分かる重要なポイントは、「IT業界向けの標準モデルは、必ずしもお互いに排他的というわけではなく、適用領域が異なっているだけで、領域が重な っている場合、表現上の違いはあっても、本質的にはほぼ同じ内容だ」ということです。

　例えば、「管理」領域は、PMBOK、スクラム、ISO9001、CMMIの全てがカバーしていますが、「お客様からの要望を受け付ける方法」「プロジェクトの進ちょくを測る方法」といったノウハウを、細かな技法は異なりますが、どの標準も含んでいます。

CMMIはスクラムと同時に使える

　では、カバーする領域が異なる場合はどう考えればよいのでしょうか。例えばPMBOKは「管理」しかカバーしていません。よって、「開発」については、SLCPやスクラムなど、別の標準モデルを選ぶ必要があると考えれば良いのです。（もちろん、標準モデルに頼らないという選択肢もありますが）。つまり、これらの標準モデルはお互いに補完的な存在と言えるのです。

　例えばスクラムを使って、小規模なアジャイルプロジェクトを成功させられるようになった組織が、大規模な開発でアジャイルを成功させるノウハウがほしい場合は、CMMIの「組織運営」の部分を参考にする、アジャイル開発の生産性を向上させるためにベロシティを改善したい場合は、CMMIの定量分析を利用する、といった使い方をすると、必要なノウハウを効率的に入手できます。ちなみに米国では、複数の標準モデルを組み合わせて戦略的に使うことを「マルチモデル」と呼び、ここ1〜2年、企業の注目を集めています。

---

　さて、今回はCMMIの特徴とメリットを簡単にご紹介しましたが、いかがだったでしょうか。前述のようにドキュメント全体の量は非常に多いのですが、そこに記されている1つ1つの要素はシンプルかつ分かりやすい内容となっています。CMMIは開発全体をカバーする”全部入りモデル”ですが、フルセットでの適用以外に、必要な部分だけを選択して使うことも可能です。開発効率を高める上で、これを使わないのはあまりにももったいないのではないでしょうか。

　次回はCMMIのメリットについて、事例を使って解説します。本連載を通じて、開発現場で働く皆さんにとって、CMMIが身近なものになればと願っています。

参考リンク
CMMI V1.2 日本語版（Amazon.co.jp）
CMMI V1.3 英語版

筆者プロフィール

矢部 智（やべ さとし）

SEI認定CMMI(SCAMPI)高成熟度リードアプレイザー、SEI認定CMMIインストラクター。日本人資格者としてCMMI V1.2以降で初のレベル4以上のCMMI評定を実施。ソフトウェアプロセス改善全般に取り組み、CMMI評定を中心としたプロセスアセスメント（30回以上）、ソフトウェア開発における定量データの分析、プロセス改善教育、標準プロセスの作成支援などを行っている。

岡本 隆史（おかもと たかし）

認定スクラムマスター。OSSのプロジェクト管理ツールのスクラム対応の強化や、分散バージョン管理の勉強会、執筆を通し、オープンソースで企業が気軽に導入できるプロジェクト管理ツールの開発を進める。業務ではクラウド基盤の研究開発に従事。