CMMIのプラクティス
今回はCMMIに関する3回目のブログです。以前のブログで私は次のように述べました。
「CMMIは、世界中の成功している組織やプロジェクトが何を実施しているか(What)、なぜそれを実施しているか(その価値は何か)(Why)を分析し、体系化したものです。そのWhatをプラクティスと呼んでいます。」
プラクティスは内容に応じて“プラクティス領域(PA)”にまとめられています。今回のブログではCMMIのPAとプラクティスについて、具体例を示しながらご説明いたします。今回はかなり長くなってしまいましたが、これを読んでいただければ「プラクティス」の雰囲気が大体分かると思います。
1.CMMIがカバーする業務領域
2023年6月現在、CMMIがカバーしている業務領域と、リリースされたタイミングは以下の通りです。
上記のうち、「開発」の業務領域のCMMIは最も広く活用されており、CMMIと言えばソフトウェア開発のプロセス改善モデルと思っている方も多いと思います。今では８つもの業務領域をカバーしているのですが、ご存じの方はあまりいらっしゃらないですよね。
日本ではあまり話題にあがりませんでしたが、2023年4月にV3.0という新しいバージョンのCMMIがリリースされました。V3.0の主な変更点は上記にある３つの新しい業務領域（データ管理、人材管理、バーチャル環境での作業）の追加で、V2.0以前から存在する業務領域（開発、サービス、供給者、セーフティ、セキュリティ）については若干のマイナーチェンジや統廃合があったものの、個々のプラクティスの内容に大きな変更はありません。今回のブログはV2.0の情報や経験を基に説明しておりますが、ここでの説明はV3.0でもそのまま当てはまりますのでご安心ください。
V2.0とV3.0の差について興味のある方は、株式会社大和コンピューター様のメルマガ記事「CMMI V3.0で変更されたプラクティス文（抜粋）」に分かりやすい解説がありますので、参照してみてください。
2.プラクティス領域(PA)と具体例
CMMIプラクティスは内容に応じて“プラクティス領域(PA: Practice Area)”にまとめられています。ここでは「見積もり」のPAを例に、PAとプラクティスとは具体的にどのようなものなのかをご紹介いたします。
各PAには「意図」と「価値」が定義されています。「見積もり」のPAについては以下のように定義されています。
各PAには複数のプラクティスが含まれており、各プラクティスには「プラクティス文」と「価値」が定義されています。「見積もり」のプラクティスについて以下のように定義されています。
（注意）CMMI V2.0以降の情報公開は制限されており、プラクティスに関しては「プラクティス文」は一般公開されていますが、「価値」は一般公開されていません。しかしながら見積もりのPAのみは例外で、「価値」を含め全ての内容が公開されています。
3.プラクティスの進化レベル
プラクティスには進化レベルが定義されています。レベル1のプラクティスは 1.X、レベル2のプラクティスは2.Xというように番号で分かるようになっています。それぞれの進化レベルを私の言葉で大まかに説明すると以下のような感じです。
つまり、いきなり全てのプラクティスを実施する必要は無いのです。自分の組織の現状を踏まえて、レベル1のプラクティスから少しずつ、無理なく改善できるようにCMMIが導いてくれます。なお上記の見積もりのPAもそうですが、多くのPAでは進化レベル3まで定義されており、レベル4や5まで定義されているのでは一部のPAでのみです。
4.プラクティスの「価値」の記述
プラクティスの「価値」の記述はCMMI V2.0から追加されました。これにより「何のためにこのプラクティスを実施しているのか」つまりプラクティスの目的がとても分かりやすくなりました。
また「価値」の記述の追加により議論の焦点に変化が起きました。従来はプラクティスを実施しているかに焦点を当てがちでしたが、V2.0から、プラクティスを実施した結果、目的がどこまで達成できているかにより焦点が当たるようになったのです。以前はアウトプットを見たりインタビューをしたりして「ああ、この成果物があるし、インタビューで言っていることと矛盾が無いから確かに実施してますね。」というように「実施しているか否か」の判断に留まっていることがありました。しかしV2.0では「実施した結果、“成果”が出ているか。」についても確認するようになりました。実施はしたけれど成果が出ていない場合には、何らかの改善機会があるということです。このように、「価値」の記述の追加により、アプレイザルやギャップ分析の際に、“アウトプット”から“アウトカム”へ焦点が移ったのがV2.0の大きな特徴と言ってよいかと思います。
5.プラクティスから得られる気づきの例
プラクティスを読むと色々と気づきが得られますが、ここでは「見積もり」に関連した例を紹介します。
私の所属する（株）SI&Cでは根拠のある見積もりを作成することを重視しています。根拠のある見積もりを行うには何が必要でしょうか。第一のヒントは前述プラクティスの例で挙げたEST 2.1にあります。
【EST 2.1】 見積もり対象のスコープを作成し、最新に保ち、使用する。
このプラクティスにより、見積もりを行う上で、まずはスコープを明確にする必要があることに気がつきます。具体的には成果物やWBSなど等を定義して、プロジェクトで作成するものと作業を明確にします。
第二のヒントはEST 2.2にあります。
【EST 2.2】 ソリューションの規模見積もりを作成し、最新に保つ。
このプラクティスにより、見積もりを行う上で、成果物やサービスの大きさを数字で把握する必要があることに気がつきます。ソフトウェア開発であれば、ソースコード行数、ファンクションポイント、機能数、データ項目数、ストーリーポイント（アジャイル開発の場合）などが当てはまります。サービス提供であれば、ユーザー数、拠点数、サーバー数、サービス要求の数、トランザクション数などが挙げられます。当社ではこのEST 2.2を特に重視しています。その理由は、成果物の大きさを数値化して見積もることにより、スコープの変化に早く気づくことができるからです。皆様のプロジェクトでは、開発やサービス提供を進めて行くうちにいつの間にかスコープが拡大していて、予定コストを超過したり、納期に間に合わなかったりといったことが起きていませんか。EST2.2と合わせてEST2.3、そして計画（PLAN）と監視と制御(MC)のPAにある以下のプラクティスをしっかり実施することで、スコープの拡大に早期に気がつき、早期に対応できるようになります。
【EST 2.3】 規模見積もりに基づいて、ソリューションに対する工数、期間、および費用の見積もりと、それらの論理的根拠を作成し記録する。
【PLAN 2.3】 記録された見積もりに基づいて,予算とスケジュールを作成し、最新に保つ。
【MC 2.1】 実際の結果を、規模、工数、スケジュール、資源、知識とスキル、および予算の見積もりに照らして追跡する。
【MC 2.4】 実際の結果が計画された結果より著しく逸脱する場合は、是正処置をとり終結に至るまで管理する。
EST 2.3により、規模見積もりがあるからこそ根拠を持って工数、期間、費用が見積もれることに気づき、それらをしっかり文書に残しておくようになります。文書に残していないと当初の想定と何が変化したのか分かりません。
PLAN 2.3により、見積もり結果を基に計画を立てることと、立てっぱなしではなくて計画を随時見直す必要があることに気がつきます。
プロジェクトが進捗するにつれて、一部の成果物の規模の実績が得られ、他の成果物の規模もより正確に予測できるようになります。
MC 2.1により、規模の見積もりと実績の比較や、再見積もりを定期的に行うことの重要性に気がつきます。そしてMC 2.4は、当初の規模見積もりから逸脱している場合、その原因を特定し、必要な対応を行うように促します。
このようにCMMIのプラクティス同士は、PAの枠を超えて様々な関連を持っています。この関連をたくさん理解することで、より多くの気づきを得られるようになります。
また、ある組織ではあまり重視していなかったプラクティスも、別の組織ではとても重要な意味を持っていることがあります。あるいは、同じ組織であっても時の経過により、今まで見過ごされていたプラクティスに急に光が当たることもあります。
このようにCMMIは使用すれば使用するほど、プラクティス間の様々な関連を理解し、それぞれのプラクティスの奥深さを知ることができます。
今回のブログはいかがでしたでしょうか。CMMIのプラクティス領域(PA)やプラクティスの雰囲気をご理解いただけましたか。ぜひ皆様からのご意見やご感想を頂けると嬉しいです。
この記事が気に入ったらサポートをしてみませんか？