【CIO】【経営企画部】【情報システム部】【ITアーキテクト】【プロジェクトマネージャ】

連載

今日からできる“CMMI流”開発効率改善術（3）

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

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

2012/7/6

前のページ｜1　2　｜

スプリントのプロセスにもスクラム＋アルファの要素が

■CMMIではプロジェクト全体とスプリントを区別しない

- PR -

　次に、スプリントの部分です。スクラムでは、まずプロダクトバックログから切り出されたユーザーストーリーをスプリントの期間中にプログラミングし、スプリント完了時にリリースします。スプリントの開始時には、スプリント計画を行い、各ユーザーストーリーにかける作業時間を見積もります。

　一方、CMMIでは、「プロジェクト全体の計画」と「スプリントの計画」を区別しておらず、この部分も「プロジェクト計画策定」で説明しています。また、スクラムの場合、スプリントに取り組んでいる間、「作業時間」「タスクのステータス」などでユーザーストーリーの開発進捗を監視しますが、CMMIでは「プロジェクト全体の計画」と「スプリントの計画」を区別していないため、進捗管理については「プロジェクトの監視と制御」のパートでまとめています。

■要件分析には要件開発（RD)が該当

　スプリントで実際にプログラムを作成する際には、ユーザーストーリーの要件を分析しますが、この要件分析についてはCMMIの「要件開発（RD)」が該当します。スクラムでは「ユーザーの参加を促し、ユーザーの要望をどう引き出すか」に重点をおいて要件開発を行うため、実際に使いそうな人物像を想定するペルソナや、画面イメージを早い段階でユーザーに見せるプロトタイプといった技法をよく使いますが、CMMIではそれに加えて、「ユーザーの要望を引き出す観点をあらかじめ整理しておく」など、常に先を見越したプロセスを定義するよう勧めています。

　また、作成したプログラムについては、スクラムの場合、ソースコードレビューやユニットテスト、ファンクショナルテストなどを実施しますが、CMMIでは「検証（VER)」がこうした取り組みをカバーしています。さらに、CMMI V1.3ではアジャイル開発技法の例として、「検証」プロセス領域で「ペアプログラミング」と「リファクタリング」を勧めています。

■CMMIでは各プログラムに共通する課題の洗い出しも推奨

　スクラムの場合、スプリントの終了時に、完成したプログラムをユーザーにスプリントレビューで確認してもらい、ユーザー企業の商用環境などにリリースします。CMMIでは、作成したプログラムの確認は「検証」「妥当性確認」が該当します。前者は「検証が指定された要件通りにできているか」、後者は「妥当性確認がリリース後に本当に使い物になるか」という観点でレビューするものです。スクラムでも、スプリントごとのデモを見せるような場合にはそうした観点でレビューするので、この点も「重なっている」と言えるかと思います。ただ、CMMIではこれに加えて、「レビューやテストの結果データを分析して全体の傾向を捉え、各プログラムに共通して見られるようなエラーがあったら対処する」ことも勧めています。

CMMIは自動化も推奨

■「リリース作業」には、CMMIの「構成管理」「成果物統合」が該当

　スクラムの最後のプロセス「リリース作業」には、CMMIの「構成管理」「成果物統合」が該当します。特に、CMMI V1.3では、「アジャイル環境では継続的インテグレーションのような技法が使われることがあるため、構成管理の自動化が大事だ」と書かれています。

　ちなみに、この自動化という言葉ですが、CMMIが目指しているのは「開発の業務フローも含んだ自動化」です。例えば「Redmine」のようなタスク／チケット管理システムと「Subversion」のような構成管理システムを連携させ、「チケット番号をコミットログに書くと、チケット管理システムからファイルの変更状況が確認できるようなる」など、プロジェクトの管理作業全体を効率化することを改善ポイントとして推奨しています。

　また、「どの機能を、どういう順番でリリースしていくか」は、ビジネス上も極めて重要ですが、CMMIでは「成果物統合プロセス領域で、統合の戦略を立てる」よう勧めている点も特徴でしょう。現在、スクラム開発を行っている場合も、全社戦略を意識的に考慮に入れることで、より効果的なリリースができるようになるかもしれません。

■テーマを細分化して振り返るCMMI

　スプリント終了時には、レトロスペクティブ（振り返り）を行い、次のスプリントに向けた教訓とします。このレトロスペクティブは、「スプリント活動の事実を客観的に見つめ、今後のプロジェクト運営をより良くしていこう」という趣旨で行われる点で、CMMIでは「プロセスと成果物の品質保証（PPQA）」に該当すると言えます。ただし、CMMIでは振り返りについて、ただ何となく話し合うのではなく、プロセス単位で区切って整理して話し合うことになるため、「具体的にどのプロセスを、どう変えれば良いのか」という議論がしやすくなるメリットがあります。

　最後にスクラムのデイリーの部分を対比してみましょう。ここで行われる状況報告と共有、すなわちデイリースタンドアップには、CMMIの「プロジェクト計画策定（PP)」と「プロジェクトの監視と制御（PMC)」が該当します。現時点の進捗報告だけではなく、日々の振り返りを含む場合には「プロセスと成果物の品質保証（PPQA）」も該当します。

抽象度の高いプロセスを示し、各組織に最適な改善を促す

　さて、開発の流れに沿って、スクラムとCMMIの内容を対比してきましたが、スクラムの各作業がCMMIのどこかに入っていることが理解できたのではないでしょうか。まとめると以下の図3のようになります。

図3 赤い枠で示したのがCMMIのプロセス領域。スクラムの各プロセスに対応している

　CMMIはもともとソフトウェア開発を“幅広く”カバーしたプロセスモデルのため、スクラムのような新しい開発プロセスが登場しても、必ず当てはまる箇所が見つかります。筆者は長い間CMMIを使ってきましたが、アジャイルの書籍を読みながら、「ああ、ストーリーポイントはプロジェクト計画策定だな」「プロダクトバックログは要件管理だな」などとつぶやいていました。

　スクラムとCMMIの違いがあるとすれば、「記述の詳細度」ではないかと思います。例えば作業量の見積もりについて、スクラムではストーリーポイントなどを推奨していますが、CMMIでは「きちんと定量的な根拠で見積もることが大事だ」としながら、見積もるための尺度を具体的には指定していません。尺度については、行数、ファンクションポイント、機能数、ストーリーポイントなど、多くの例が紹介されていますが、見積もる方法についての詳細な解説は見られません。

　言ってみれば、やや抽象度の高いプロセスを中心に書き、多くの実装例を紹介することで、実装方法については柔軟な対応ができるようになっているわけです。これは一見、CMMIの弱みのように思えますが、CMMIは継続的改善を重視しているので、「より良い実装方法があったら、そちらに変えても良い。だから、あえてCMMIからは実装方法を指定しない」という作りになっているのです。プロセスを「実装」ではなく「本質」で捉えることにより、実装に関する技術トレンドが変化しても追随できる実力をつけることがCMMIの狙いです。

◇

　とはいえ、ここまでの説明では「ものは言いよう」とネガティブに捉える向きもあるかもしれません。次回からは、いよいよCMMIのメリットを具体的に紹介していきます。まずはCMMIの特徴の1つである「プロセスの測定」と、それによる開発作業の改善パターンを解説します。

参考リンク

CMMI V1.3 日本語版（Amazon.co.jp）
CMMI V1.3 英語版

筆者プロフィール

矢部智（やべさとし）
SEI認定CMMI(SCAMPI)高成熟度リードアプレイザー、SEI認定CMMIインストラクター。日本人資格者としてCMMI V1.2以降で初のレベル4以上のCMMI評定を実施。ソフトウェアプロセス改善全般に取り組み、CMMI評定を中心としたプロセスアセスメント（30回以上）、ソフトウェア開発における定量データの分析、プロセス改善教育、標準プロセスの作成支援などを行っている。
岡本隆史（おかもとたかし）
認定スクラムマスター。OSSのプロジェクト管理ツールのスクラム対応の強化や、分散バージョン管理の勉強会、執筆を通し、オープンソースで企業が気軽に導入できるプロジェクト管理ツールの開発を進める。業務ではクラウド基盤の研究開発に従事。

■要約■
前回、CMMIとは「開発から管理、組織運営、定量分析まで全てをカバーした“全部入りモデル”」と解説した。しかし、CMMIは「ウォーターフォール型の重厚長大な開発向け」といったイメージで捉えられ、アジャイルとCMMIは対立するスタイルとして語られることもあった。だが、アジャイルとCMMIは決して対立的な関係ではない。今回は、アジャイルとCMMIの重なっている部分を、アジャイル開発手法の1つであるスクラムの流れに沿って紹介する。

例えば、スクラムでは、まずエンドユーザーの声を聞きながら「どんな機能を作るのか」を考え、ユーザーストーリーをまとめる。その上で、必要な機能に優先順位を付け、開発すべきものを絞り込んでプロダクトバックログとし、スプリントに回して開発に着手する。CMMIでこの部分に該当するのが「要件開発（RD)」と「要件管理（REQM)」だ。前者は「エンドユーザーの要望を聞きながらユーザーストーリーを作成すること」、後者は「プロダクトバックログを管理すること」を指し、具体的な方法をまとめている。また、スクラムでは、プログラムを作成する際、ユーザーストーリーを分析するが、この要件分析もCMMIの「要件開発（RD)」が該当する。スクラムでは「ユーザーの参加を促し、ユーザーの要望をどう引き出すか」に重点をおいて要件開発を行うため、実際に使いそうな人物像を想定するペルソナなどの技法を使うが、CMMIではそれらに加えて、「ユーザーの要望を引き出す観点をあらかじめ整理しておく」など、常に先を見越したプロセスを定義するよう勧めている。

このように見ていくと、「CMMIは他の標準と重なっている」ことが理解できる。注目すべきは、重なっているだけではなく、改善に向けて視野を広げてくれる点だ。言ってみれば、やや抽象度の高いプロセスを中心に書き、多くの実装例を紹介することで、実装方法については柔軟な対応ができるようになっている。CMMIは継続的改善を重視しているため、「より良い実装方法があったら、そちらに変えても良い。だから、あえてCMMIからは実装方法を指定しない」という考え方だ。プロセスを「実装」ではなく「本質」で捉えることにより、実装に関する技術トレンドが変化しても追随できる実力をつけることがCMMIの狙いなのだ。