Global Wind　（グローバル・ウインド）

東京都中小企業診断士協会中央支部・国際部
静永　誠

 

はじめに

CMMI(Capability Maturity Model Integration：能力成熟度モデル統合)は、プロジェクト管理やプロセス管理の能力を段階的にレベル表現できるモデルであり、主にシステム開発の分野で利用されている。

CMMIの概要、歴史を振り返り、新リリースの変更点を3回に分けて、簡単に紹介する。第1回ではCMMIの概要を紹介した。第2回である本記事では、CMMIの歴史を簡単に紹介する。

 

CMMIの開発の経緯

CMMIの前身にあたるSoftware CMM®（Capability Maturity Model）は、1990年代にCarnegie Mellon大学のソフトウェア工学研究所（Software Engineering Institute、以下SEISM）により公開された。CMMの開発の経緯をみると、ソフトウェア関連企業に関する能力評価法の開発という米国連邦政府から要請へ応えるための、SEIでの研究がその前身になっている。

ここでは、前回記事で説明した成熟度レベルの概念が確立される様子を中心に、CMMIの前身まで含めた、開発の歴史を紹介する。

 

ソフトウェアへのTQMの適応

SEIのソフトウェアプロセス成熟度に対する研究の底流にある基礎的な前提は、ソフトウェア製品の品質の大部分は、ソフトウェアの構築に使われる、開発および保守のプロセスの品質によって決まるというものであった。

そのような前提のもと、SEIではプロセス品質の改善に係る研究のなかで、Walter Shewhartの統計的品質管理や、Edwards DemingのDemingサイクルの概念を取り入れ、TQM（Total Quality Management）の原理をソフトウェア開発組織に適応させる研究が行われていた。

ソフトウェア開発のプロセスの品質をCMMIのような成熟度の段階構造で示すフレームワークは、Philip Crosbyが著書「Quality is Free」で説明している品質管理成熟度表（Quality Management Maturity Grid）を、Watts Humphreyがソフトウェアのプロセスに適応することで作成された。

品質管理成熟度表は、クロスビーが成熟度という概念を適用した実務経験から作成したものであり、管理者が専門的な品質管理の訓練を受けなくても、5段階に示された品質ポイントをなぞることで品質改善ができるように工夫されたものであった。

 

IBMでのHumphreyとRadiceの研究

1980年代にRon RadiceはHumphreyの指揮のもと、IBM社のソフトウェア開発プロセスを調査していた。1985年、Radiceは、ソフトウェアを開発していた8サイトを対象にしたソフトウェア開発プロセスの調査報告を発表し、そのなかでプロセス成熟度表（Process Maturity Grid）というモデルを提示した。

Radiceは調査にあたり、プロジェクト管理者とソフトウェア開発者と、両方にインタビューしてプロセスの情報を収集しており、インタビューでの確認内容が報告書で要約されている。報告書で示されている内容は、現在のCMMIのアプレイザルでの確認内容にも通じるものがあるため、参考までに、主な確認内容を以下に示す。

●インタビュー参加者に持参を依頼する資料

  • 自分の作業を説明するプレゼン資料
  • (会社／組織のもの以外で)作業中に使っているワークブック、手順書
  • 使っている、作成している文書のサンプル(仕様書、テスト計画など)
  • 作業資料のサンプル(問題報告など)
  • 自分のプロセスにとって、重要であると考えられるメモ

●インタビュー回答者にプレゼン資料に含めるよう依頼する項目

  • プロセスへの入力／出力
  • サブプロセス
  • 自分以外に関与する人
  • 先行するプロセス／後続するプロセス

●インタビュー回答者にプレゼンを依頼する項目

  • どんなドキュメントを使っているか／作っているか？
  • どんなツールを使っているか？
  • 決まった(定義された)手順は持っているか？
  • その(決まった)手順には従っているか？
  • 品質／正確性／完全性はどう検証してるか？
  • どんなチェック／レビュー／承認作業が関わっているか？
  • 進捗はどうやって追い掛けているか？
  • 必要なスケジュールと要員とは、どうやって見積もっているか？
  • 変更はどうやって扱っているか(制御／管理してるか)？

●インタビュー側で追加質問する代表的な項目

  • 部門の中で、必要なスキルはどうやって開発／維持してるか？
  • 部門に中で、顧客はどの程度意識されているか？
  • 部門として、作業の品質を上げるためにしていることはあるか？
  • 仕事をするうえで、プロセスに関連して(手順／手続き／ツール／情報伝達などで)問題は起きているか？
  • 自分のプロセスを最も改善できるものとして、考えられることは何か？
  • 自分の作業に関係するもの(ツール、手順、など)について、何をすれば最も改善できると考えられるか？
  • 今回のリリースで使ったプロセスは、以前のリリースで使ったものに対して、何か違うところはあるか？
  • 次回のリリースでは、プロセスについて、どんな変化を加えたいと考えているか？

Humphreyは、この研究の成果として作成されたプロセス成熟度の概念をSEIに持ち込み、1987年に発表したソフトウェアプロセス成熟度のフレームワークの定義に利用した。

 

ソフトウェアプロセス成熟度のフレームワークと質問票

1986年、ソフトウェア関連企業に関する能力評価法の開発を米国連邦政府から要請され、SEIはMITRE社の協力を得ながら、ソフトウェアプロセスの改善を目標とした、プロセスの成熟度に関するフレームワークの開発を開始した。翌1987年、SEIはその成果として、成熟度フレームワークの簡単な定義と、ソフトウェアプロセスの成熟度に関する質問票を発表した。

この成熟度フレームワークでは、継続的プロセス改善の一連の土台となる5段階が識別され、あわせて組織のソフトウェアプロセスの成熟度レベルを測定する順序尺度の定義がされた。この成熟度レベルのコンセプトは、以降のSoftware CMMおよびCMMIの進化のなかでも、常に存在し続ける重要なものとなった。

さらに、この時期の決定事項のなかで重要なものに、成熟度レベルの違いでは、プロジェクトのコミットメントの識別および管理に注力することと、計画の管理に注力することが重大であるとした決定がある。この決定が、成熟度モデルとCrosbyの品質管理成熟度表などとの大きな違いのひとつになった。以降、Software CMMやCMMIのV1.3までの各バージョンにおいても、成熟度レベルは、まずプロジェクト管理に関する要求をレベル2で定義し、技術的な手法はレベル3以降で標準化などを要求する内容になっている。

 

アプレイザル手法の開発と正式モデルのニーズ

成熟度フレームワークの発表とともに、その成熟度のコンセプトを使って組織のプロセス成熟度を診断することが試みられた。SEIでは、プロセス改善のための自組織の診断と、調達者による業社選定のための診断とを合わせてアプレイザルと呼び、アプレイザル手法の開発も進められた。その結果、プロセス成熟度の判定結果の信頼性をどのように担保するかという懸念が明らかになった。

当時は、成熟度の概念に関してHumphreyの知識や理解に依存する部分が大きかったため、今後の普及にあたり、成熟度フレームワークの正式なモデルへのニーズが明らかになった。

 

「Managing the Software Process」出版とSoftware CMMのリリース

1989年、Humphreyは研究成果として「Managing the Software Process」を出版した。この書籍は成熟度フレームワークの内容を詳細に示すとともに、ソフトウェアプロセスにプロセス管理の原理を適用するという動きに大きな影響を与え、以降のSoftware CMM開発を促進させるものとなった。

「Managing the Software Process」の内容をベースに、プロセス成熟度の正式なモデルとしてSoftware CMMの開発が進められた。コミュニティ向けのレビュー版のリリースを繰り返した後、1991年にSoftware CMM v1.0がリリースされた。

Software CMMでは、正式に、成熟度レベルがキープロセスエリア（key process area）という観点から説明されるようになった。キープロセスエリアは組織がプロセスを改善するために注力すべきところを指し示すものであり、各成熟度レベルでは、複数のキープロセスエリアが定義された。各キープロセスエリアでは複数のゴールが定義され、ゴールがSoftware CMMにおける要求事項とされた。

キープロセスエリアには、ゴールのほかにも参考情報という位置づけでコモンフィーチャ、キープラクティスなど、様々な詳細情報も含まれていた。

参考までにSoftware CMMの構成要素と構造を図1に示す。
図１SoftworeCMMの構成要素

図 1 Software CMMの構成要素

図の各要素について例を示すと、表1のようになる。

表 1 Software CMMの構成要素の例

Software CMM構成要素 概要 例
キープロセスエリア 関連するひとまとまりの活動を特定しており、それら全体が実施されれば、プロセス能力の確立に重要と考えられるゴールの集まりが達成される。 要件管理
ソフトウェア進捗管理
組織プロセス定義
コモンフィーチャ キープロセスエリアの実装と制度化が効果的で、反復でき、永続するかを示す属性。 実施のコミットメント
実施能力
実施される活動
キープラクティス キープロセスエリアの効果的な実装と制度化に大きく寄与する基盤と活動を記述している。 「ソフトウェアエンジニアリンググループは、割り当てられた要件がソフトウェアプロジェクトに組込まれる前の段階でレビューする。」
※「要件管理」キープロセスエリアのキープラクティスのひとつ

 

Software CMMの開発停止とCMMIの開発

1993年、小規模な改訂であるSoftware CMM v1.1がリリースされた。これは、主に語句や表現の明確化および一貫性の向上のための変更が加えられており、内容や意図自体の変更はされていない。

当時、新しいキープロセスエリアを追加するといった、より大規模な改訂への要求については、v2.0リリースで取り込むという計画になっていた。Software CMM v2.0の開発は3回の大きなレビュー実施をとおし、ほぼ完成するところまで進んでいた。しかしながら、1997年にスポンサーであった米国国防省の意向によって、CMMI作成に注力するために中止となった。

CMMIは当初、以下の成熟度モデルを統合するものとして開発された。

  • ハードウェア開発なども含めたシステム開発の成熟度モデル（EIA/IS-731）
  • 米国国防省で導入が図られていた統合成果物プロセス開発（integrated product and process development、例えば国防省プロジェクトでハードウェア、ソフトウェア、運用など様々な専門家グループが参加して開発するとき、グループ間連携を強調する考え方）の成熟度モデル（Integrated Product Development CMM v0.98）
  • Software CMM v2C

このように複数のモデルを統合した背景には、Software CMMにみられるような成熟度の枠組みがソフトウェア開発以外でも応用可能であったために、様々な領域で試みられていたCMMに類似した成熟度モデルの開発があった。Software CMM v1.0がリリースされた1991年以降では、システムエンジニアリング、ソフトウェアエンジニアリング、ソフトウェア調達、従事者の管理と育成、および統合成果物プロセス開発などについて、CMMと同様の成熟度モデルが開発されていた。

これらのモデルは、アーキテクチャ、内容、アプローチなどに差異があり、複数のモデルを使用するのは困難であった。複数のモデルを適用した場合、改善策を広げていくことが難しく、トレーニング、アプレイザル、改善活動などを実施するときコストが高くつくようになっていた。

この問題を解決するために、米国政府、産業界の代表、およびSEIによりCMMIプロジェクトが組織され、様々なCMMで扱っている内容を統合するフレームワークとしてCMMIの作成が進められた。

 

今回のまとめ

今回の記事はCMMI開発の経緯について、CMMIの前身であるSW-CMMなどを含めて紹介した。

CMMIの歴史は、統計的品質管理やTQMの原理のソフトウェア開発組織への適応を試みていた、SEIによるソフトウェアプロセス成熟度の研究までさかのぼることができる。そして、ソフトウェア関連企業に関する能力評価法の開発という、米国連邦政府からSEIへの要請に応えて成熟度のフレームワークが作成された後に、プロセス成熟度の正式なモデルとしてSW CMMがリリースされた。SW CMMは米国国防省の意向もあり、システム開発のプロセスなども含めた成熟度モデルであるCMMIへ引き継がれた。

次回の記事では、CMMIの新バージョンであるCMMI V2.0の変更点を紹介する。

 
参考資料

  • Mark C. Paulk, “A History of the Capability Maturity Model for Software,” ASQ Software Quality Professional, Vol. 12, No. 1, December, 2009
  • CMMI Product Team, “CMMI for Development, Version 1.3 CMMI-DEV, V1.3 CMU/SEI-2010-TR-033 ESC-TR-2010-033,” Software Engineering Institute, Carnegie Mellon University, 2010
  • CMMI 成果物チーム、「開発のためのCMMI® 1.3版 CMMI-DEV, V1.3 CMU/SEI-2010-TR-033 ESC-TR-2010-033 より良い製品とサービスを開発するためのプロセス改善」、カーネギー・メロン大学ソフトウェア工学研究所、2010年
  • CMMI Product Team, “CMMI for Service, Version 1.3 CMMI-SVC, V1.3 CMU/SEI-2010-TR-034 ESC-TR-2010-034,” Software Engineering Institute, Carnegie Mellon University, 2010
  • Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, Charles V. Weber, “Capability Maturity ModelSM for Software Version 1.2 Technical Report CMU/SEI-93-TR-024,” Software Engineering Institute, Carnegie Mellon University, 1993.
  • Mark C. Paulk他著、「能力成熟度モデルのキープラクティス 1.1版 技術報告書 1993年2月、CMU/SEI-93-TR-25、ESC-TR-93-178」、ソフトウェアエンジニアリング研究所、カーネギーメロン大学、1993年
  • Watts S. Humphrey著、藤野喜一監訳、日本電気ソフトウェアプロセス研究会訳、「ソフトウェアプロセス成熟度の改善」、日科技連、1991年
  • フィリップ・B．クロスビー著、小林宏治監訳、「クオリティ・マネジメント：よい品質をタダで手に入れる法」、日本能率協会、1980年
  • 渡辺昇、平松庸一、「経営品質メカニズムに関する理論モデルの研究－組織成熟度と組織変革の共進化プロセス－」、日本経営品質学会、2007年
  • 「CMMIの変遷」、https://www.daiwa-computer.co.jp/jp/consulting/cmmi-evolution、2018年6月29日アクセス
  • Ronald A. Radice, John T. Harding, Paul E. Munnis, Richard W. Phillips, “A Programming Process Study,” IBM Systems Journal 24(2): 91-101, 1985
  • “DoD Integrated Product and Process Development Handbook,” Office of the Under Secretary of Defense (OUSD), Washington, DC – 20301-3000, August 1998

────────────────────────────────────────
Capability Maturity Model、CMM、 CMMI は、Carnegie Mellon大学によって米国特許商標庁に登録されている。
SEIは、Carnegie Mellon大学の商標。

 
プロフィール：
静永　誠
大手メーカー系・独立系ソフトウェアハウスで開発工程全般の実務を経験した後、ソフトウェア開発プロセスのアセスメント資格と中小企業診断士を取得。航空宇宙業界や自動車業界で、プロセスアセスメントやソフトウェアプロセス改善のコンサルティングを担当した後、他業種のSIベンダーのプロセス改善支援にも活動を広げている。