徹底検証！ CMMIはアジャイルの改善にも役立つか？

矢部 智／岡本 隆史（NTTデータ）

2012/7/6

｜1　2　｜次のページ

スクラムとCMMIは対立する概念ではない

　前回、CMMIとは「開発から管理、組織運営、定量分析まで全てをカバーした“全部入りモデル”」であり、単一のプロジェクトだけではなく、複数のプロジェクトの成功を狙う「組織としてのビジネスの成功」を目指したものである点に、他の標準モデルとの違いがあると解説しました。

　しかし、そうした特性ゆえか、CMMIは「ウォーターフォール型の重厚長大な開発向け」といったイメージで捉えられ、アジャイルとCMMIは対立する開発スタイルとして語られることもありました。しかし、「より良いソフトウェア開発を目指す」という意味では、アジャイルとCMMIは決して対立的な関係ではありません。むしろ似ている点が数多くあり、実際、V1.3からアジャイル対応についても盛り込まれているのです。

　ただ、以上のように、「CMMIと一連の業界標準はお互いに排他的ではない」「CMMIとアジャイルは対立的ではない」と説明したところで、「では具体的に、他の開発手法と、どの作業が、どう重なるのか」「本当に排他的ではないのか」といった点は気になるところかと思います。

　そこで今回は、アジャイルとCMMIの重なっている部分を、アジャイル開発手法の1 つであるスクラムの流れに沿って紹介します。スクラムの各作業はCMMIのどの部分に該当するのか――つまり、CMMIのどの部分を見れば、スクラムの作業改善のヒントが得られるのかが分かれば、CMMIに対する印象もだいぶ変わるのではないでしょうか。

　この5月にはCMMI V1.3 公式日本語版もリリースされました。本記事と併せて読んでみてはいかがでしょうか。

スクラムとCMMIの基礎知識

　では、スクラムとCMMIの対比に入る前に、まずはそれぞれの基礎を簡単に振り返っておきましょう。以下の図1をご覧ください。これはスクラム開発の流れを簡単にまとめたものです。

図1 スクラム開発の流れ。1番下の矢印はシステム開発の時間軸を示す

　スクラムでは、まず「プロダクトバックログ」を管理します。システムが備えるべき機能をエンドユーザー視点でまとめたものを「ユーザーストーリー」と言いますが、プロダクトバックログとは、それを機能単位に分割し、一覧にしたものです。例えば、オンラインショップのシステムなら「新規ユーザーを登録する」 「商品を検索する」などです。プロダクトバックログは、真ん中の大きな輪で示した「スプリント」に回され、開発作業に入ります。

　「スプリント」とは、2〜4週間のサイクルで繰り返し行う「作業時間の単位」です。ここでは、開発するプロダクトバックログを管理可能な単位に分割した「スプリントバックログ」という概念が存在します。例えば、「新規ユーザーを登録する」という機能の場合、「仕様検討」「実装」「テスト」「ドキュメント作成」といった具合に分割し、確実に管理を行うのです。こうして開発したプロダクトバックログは、スプリントが1つ終わるたびにユーザーにリリースします。なお、右上の小さな輪は、スプリント期間中のデイリー（日々）単位の管理を表しています。

　一方、CMMIでは、開発に関連するプロセス全体を、22個の「プロセス領域」という単位で分けています。具体的には、以下の図2のように、「要件管理」「プロジェクト計画策定」「プロジェクトの監視と制御」「検証」「構成管理」などがあります。つまり、開発プロセスを22個の「プロセス領域」に細分化することで、課題となるポイントを絞り込み、着実に改善効果を挙げられるよう配慮しているのです。図2は22個のプロセス領域のうち、今回の説明に使う9個の領域名を示したものです。

図2 CMMIが定義している開発のプロセス領域の一部（クリックで拡大）

　ちなみに、以上のような各プロセス領域は「ゴール」や「プラクティス」といった、さらに細かい単位に分かれるのですが、「改善への意識付け」という点では、この22個のプロセス領域の方が適切であるため、ここではこのプロセス領域を基に、CMMIとスクラムを対比してみます。

スクラム＋アルファの視点を提供してくれるCMMI

■プロダクトバックログは要件開発・要件管理

　まずはスクラムの流れを見てみましょう。スクラムでは、まずプロダクトバックログの部分で、プロダクトオーナーが中心となり、エンドユーザーの声を聞きながら「どんな機能を作るのか」を考えてユーザーストーリーをまとめます。その上で必要な機能に優先順位を付け、開発すべきものを絞り込んでプロダクトバックログとし、スプリントに回して開発に着手します。

　CMMIでこの部分に該当するのが「要件開発（RD)」と「要件管理（REQM)」です。前者は「エンドユーザーの要望を聞きながらユーザーストーリーを作成すること」、後者は「ユーザーストーリーの一覧をプロダクトバックログとして管理すること」を指し、その具体的な方法をまとめています。

■ストーリーポイントの見積もりはプロジェクト計画策定

　次に、ユーザーストーリー単位で作業量の大まかな見積もりをする場合、 スクラムでは「ストーリーポイント」という概念を使います。これは各ユーザーストーリーを開発するために「相対的に、どのくらいの作業量が必要か」を見積もるための手法です。例えば、「ストーリーAに必要な作業量が1ポイントだとしたら、ストーリーBは5ポイント」といった具合に、各ストーリーの作業量を大まかに見積もります。

　ポイントという概念を使う理由は、具体的な「時間」や「人数」で工数を見積もると、「チームメンバーのスキル」という属人的かつ影響度の大きい見積もり要素を見落とすことになるためです。その点、大まかに「ストーリーBの作業量はAの5倍」といった具合に“相対的に”見積もれば、さほど人のスキルの影響を受けない見積もりを割り出すことができます。見積もりの妥当性を確保する手法としては、複数のチームメンバーが見積もりを出し合う「プランニングポーカー」を行うこともあります。

　一方、CMMIでは、成果物の規模見積もりについては「プロジェクト計画策定（PP)」にまとめています。特徴的なのは、CMMIでも「定量的な根拠をもって見積もること」としているのですが、「具体的にどの尺度を使うのか」までは指定していない点です。つまり、ストーリーポイント以外にも、ファンクションポイント、ソースコード行数など、何を使用してもかまわないことになっているのです。

　また、「開発作業量の見積もり」以外の項目についても計画するよう推奨しています。例えば「プロジェクトリスク」「作業環境」「利害関係者との会議」「要員のスキル」「関連する他のプロジェクトやグループへの影響」などを考慮するよう説いています。この辺りは、「単一のプロジェクトだけではなく、複数のプロジェクトの成功を狙う『組織としてのビジネスの成功』を狙う」CMMIの大きな特徴と言えます。

■プロジェクト進捗の可視化方法も重なっている

　次にプロジェクト開始後を見てみましょう。スクラムの場合、各スプリントが終わると、「そのスプリントによって、どれくらいのユーザーストーリーを実現し、どれほどのストーリーポイントを記録したか」を測る「バーンダウンチャート」を使って、開発プロジェクトの進捗を可視化します。さらに、「チームがタスクを実行する能力」である「ベロシティ」を算出します。その開発チームが過去のスプリントで消化できたストーリーポイントの実績を基に、「スプリントで処理可能なストーリーポイント」を測っておけば、次のスプリントの計画をより正確に立てやすくなるためです。

　CMMIでは、以上のプロセスは「プロジェクトの監視と制御（PMC)」が該当し、「プロジェクトがどれくらい進んでいるのか、あるいは遅れているのかを定量的に監視する」ことを勧めています。しかし、先ほどの「作業量の見積もり＝プロジェクト計画策定」と同様、「どの尺度で監視するか」までは指定していません。従って、CMMIでも、監視手段としてはベロシティやバーンダウンチャートを使うことになります。

　このように見ていくと、「CMMIは他の標準と重なっている」ことが理解できるかと思います。また、注目すべきは、重なっているだけではなく、「開発作業量の見積もり」以外の項目についても計画するよう推奨するなど、視野を広げてくれる点です。「単一のプロジェクトではなく、複数のプロジェクトの成功を狙う、組織としてのビジネスの成功を目指したもの」という特徴も理解しやすいのではないでしょうか。

｜1　2　｜次のページ

	Page1 スクラムとCMMIは対立する概念ではない スクラムとCMMIの基礎知識 スクラム＋アルファの視点を提供してくれるCMMI
	Page2 スプリントのプロセスにも、＋アルファの要素が CMMIは自動化も推奨 抽象度の高いプロセスを示し、各組織に最適な改善を促す