“開発のよくある問題”を解決するCMMIの3大メリット
2012/5/23
開発効率を1ランク上に引き上げてくれるCMMI
- - PR -
前回、CMMIとは「開発から管理、組織運営、定量分析まで全てをカバーした“全部入りモデル”」であり、単一のプロジェクトだけではなく、複数のプロジェクトの成功を狙う「組織としてのビジネスの成功を目指したものである」と解説しました。
また、以下の図1はIT業界で使用されている開発の主な標準モデルと、そのカバー範囲をおおまかに示したものですが、このように、アジャイルとCMMIなど「一連の業界標準はお互いに排他的ではなく、重なる部分が多い」ことも紹介しました。すなわち、今現在スクラムを使って開発作業を行っている場合でも、作業を改善するためにCMMIを有効に使うことができるのです。
 |
| 図1 IT業界で使用されている主要な業界標準と、そのカバー範囲。ピンク色のカコミのように、「より大規模な組織でアジャイル開発を」と考えると、おのずと組織運営のノウハウが必要になるが、CMMIは組織運営、定量分析まで全てをカバーしている |
例えば、スクラムを使って、小規模なアジャイルプロジェクトを成功させられるようになった組織が、大規模な開発でアジャイルを成功させるノウハウがほしい場合は、CMMIの「組織運営」の部分を参考にする、アジャイル開発の生産性を向上させるためにベロシティを改善したい場合は、CMMIの定量分析を利用する、といった使い方をすると、必要なノウハウを効率的に入手することができます。
では、このように開発作業の改善に役立つCMMIには、具体的にどのようなメリットがあるのでしょうか。結論から言えば、そのメリットは大きく分けて3つあります。
- 情報共有
- 定量分析による合理的な意志決定
- グローバル対応
それぞれ詳しく見ていきましょう。
メリット1――情報共有
ソフトウェア開発の仕事をしていて、「自分たちのチームと同じような問題を周りのチームも抱えており、他のチームは解決できたが、自分たちは解決法を知らなかった」「隣のチームは有名なバグを知らず、自分たちが過去に作ったのと同じバグを作り込んでしまった」といったことはありませんか？ 「情報共有」と言われても「今さら」と思われるかもしれませんが、なかなか解決できない問題の1つであることは確かです。
実際にCMMIに取り組んだ組織でアンケートを採ってみると、開発メンバーから以下のような声が寄せられます。
|
これらをまとめると「過去の類似プロジェクトの手順を再利用できるようになった」「組織の全員が同じ方向を向いており、組織の風通しが良くなった」「みんなが改善に前向きになり、助け合うようになった」といったところでしょう。ではなぜ、このような声が出てくるのでしょうか？
まず紹介したいのは、「CMMIにおける『改善』と、皆さんが考えている『改善』は、同じ意味を持つ言葉ではないかもしれない」ということです。「改善」の一般的なイメージは、「作業者が自ら作業を振り返り（改善情報の収集）、次のサイクルにその教訓を生かしていく」というものだと思います。こうした「改善」の在り方はアジャイルでもウォーターフォールでも、サイクルの時間の長さは違いますが、基本的には同じです。しかしCMMI、特にレベル3以上では「改善」を以下の図2のように定義しています。
 |
図2 組織の情報共有のイメージ。図の中央にある「SEPG」は「Software Engineering Process Group」の略で、「情報共有の音頭を取る人やチーム」のこと（詳しくは後述）。このように他チームの振り返りや改善事例を相互に共有して活用することで、要員の流動性の担保、組織としての一体感向上など、組織としてのスケールメリットが得られる |
つまり、「情報共有を推進するチーム」が中心となり、そのリードに合わせて、自分たちの作業振り返りだけではなく、他のチームの振り返りもインプットし、互いにその教訓を生かすのです。連携するチーム数が増えれば、その分だけ改善情報も増えます。しかし、本当の効果は、改善の手掛かりが増えるだけではなく、「同じ問題について、各チームが個別に悩む必要がなくなる」「誰かが解決策を考えたら、みんながすぐ使える」という点にあります。
一般的な「改善」を行う場合、チームの数だけ似通った解決策が作られることになります。各チームの自助努力は評価すべきですが、組織としてのスケールメリットはそれほどありません。言ってみれば、各チームがまるで別々の会社であるかのような状態です。
しかし、CMMIにおける「改善」なら、チームの数だけ改善情報が速く、多く集まるほか、タイミングと内容が良ければ解決策は1つ作れば済み、改善のための重複コスト・時間も生じません。CMMIの「改善」は、お互いに解決策を出し合うことで、組織のスケールメリットを得ることができ、問題解決のトータルコストを削減できるものなのです。浮いたお金は利益にもなりますし、次の課題解決に使うこともできます。これなら「同じ会社で働いている一体感」も強くなるのではないでしょうか。
もちろん、全てのチームで同じ課題が生じることはないので、単純に「作業効率が何倍になる」と言うことはできません。しかし、共通する課題は意外に数多く潜んでいるものです。先日、「参加者を3チームに分け、どのチームにも同じ課題を与えて処理時間を競う」というアジャイルの勉強会に参加したのですが、その際も他チームのアイデアをすぐに真似できると、とても楽でした。
CMMIにおける情報共有の仕組み
しかし、普段は隣のチームのやっていることをリアルタイムでずっと見ていることはできません。そこで、時間と場所を隔てた他のチームと情報を共有する手段が必要になります。CMMIではその手段として「開発プロセスの標準化」と「プロジェクト横断的な情報共有」という仕組みを定義しています。
前者は「開発作業のやり方を、各チームが個別に決めるのではなく、チーム横断的にあらかじめ決めておく」ということです。情報共有における標準化の目的は、「普段、各チームが行っている作業について、互いに理解を深め合うこと」にあります。例えば、あるチームの人が「設計書のレビューで良くあるアレだよ」と言ったら、他のチームの人も「ああ、アレね」と分かるような状態です。「お互いが今何をやっているのか」という前提を知らなければ、問題の解決策があっても、その解決策が必要となった経緯をゼロから説明しなければならず、他の人に伝えるのに苦労します。
標準化というと「上から押しつけられた分厚い文書」「とにかく守らないと怒られるもの」というイメージを持っている方もいらっしゃるかもしれませんが、あまり堅苦しくとらえる必要はありません。基本的には「開発者が自ら必要な活動を標準プロセスとして定義し、それを使ったら振り返りをしつつ標準プロセスを書き換えていく行動」だと理解して下さい。
また、各人が情報共有をしたいと思っていても、現実には誰かが音頭を取ってくれないと、なかなかそのきっかけを作りにくいものです。情報やノウハウをもらう立場のときはいいのですが、与える立場になると「他のチームのために自分のチームのリソースを費やす」ことになるため、ついつい後回しにしてしまう、ということもあり得るためです。
従って、誰かがチーム単独の利害を超えた「組織としての活動」を考えなくてはなりません。その点、CMMIでは情報共有を推進する役割を明示的に割り当てるよう推奨しています。それが2つ目の仕組み「プロジェクト横断的な情報共有」です。CMMIでは情報共有の音頭を取る人やチームのことを「SEPG(Software Engineering Process Group)」と呼んでいます（図2参照）。SEPGは、組織内のポータルサイトにプロジェクト事例を掲載したり、ツール導入実績の勉強会を定期的に開いたりして、なるべくチーム横断的にノウハウが行き渡るような活動を行うよう定められているのです。
冒頭で「今現在スクラムを使って開発作業を行っている場合も、作業を改善するためにCMMIを有効に使うことができる」と述べましたが、今スクラム開発を行っているのであれば、そこにSEPGの役割を取り入れて“改善”し、「スクラム・オブ・スクラム」といったチーム間連携の仕組みを用意するのも良いでしょう。このような仕組みにより、CMMIは現場の課題に即した情報をより速くチーム間で共有・解決できるよう組織を導いてくれるのです。
 |
Page1 開発効率を1ランク上に引き上げてくれるCMMI メリット1――情報共有 CMMIにおける情報共有の仕組み |
| Page2 メリット2――定量分析による合理的な意志決定 測ったデータがあれば、予測もできる メリット3――グローバル対応 |
キャリアアップ
スポンサーからのお知らせ
転職／派遣情報を探す
「ITmedia マーケティング」新着記事
「ECプラットフォーム」売れ筋TOP10（2024年4月）
今週は、ECプラットフォーム製品（ECサイト構築ツール）の国内売れ筋TOP10を紹介します。
「ダークパターン」の認知は2割にとどまる――クロス・マーケティング調査
調査会社のクロス・マーケティングが実施したダークパターンに関する調査（2024年）の結...
ウェルビーイング調査 今後最も力を入れたい分野は「身体」、優先度が低いのは？
ASAKO サステナラボは、独自の「60のウェルビーイング指標」により生活者の充足度を数値...
