2. 組織成熟度

CMM^®やCMMI^®では、組織のプロセスの発展段階を５段階の成熟度レベルでモデル化しています。成熟度レベルは、最初にプロジェクトレベルでプロジェクト管理の基礎を達成することからはじまり、定性的データ、定量的データの両方を使用して意思決定を行い、最終的には組織全体にわたる継続的な改善へと進む段階的な改善経路を提供しています。

ここでは改めて、その原点ともいえるCMU/SEI-93-TR-24「ソフトウェア能力成熟度モデル 1.1版」から成熟度レベルの特徴を振り返ってみましょう。 この文書は、https://www.sea.jp/CMM/publish/CMM-J99.htmlからダウンロードできますので、是非参考にしてください。以下の網掛け部分はその一部抜粋です。

『成熟度レベル』は、成熟したソフトウェアプロセスを達成する途上の整った形で定義された進化の段階である。各成熟度レベルはそれぞれ、継続的なプロセス改善の基盤における層を規定している。それぞれのレベルは、プロセスゴールの集合で構成される。これらのゴールが達成されれば、ソフトウェアプロセスの重要なコンポーネントが安定する。成熟度の枠組みの各レベルを達成することで、ソフトウェアプロセスの各コンポーネントを確立し、結果として組織のプロセス能力が増大する。

CMMやCMMＩではプロセスゴールは「必要とされる要素」に分類され、重要視されています。ここで、ゴールとは、活動の結果を表し、活動の実施はこのゴールを満たすように行われ、ひいては組織の事業目標に貢献するように位置づけられます。 組織は、開発活動をビジネスプロセスとして捉えて設計し、成熟度レベルに応じてゴールを満たすようにコンポーネント（すなわちプロセスの構成要素）を構築することが推奨されます。組織やプロジェクトの活動を一連のプロセスの集合として捉え、各プロセスの付加価値を検討します。

レベル1　-　初期レベル

初期レベルでは、組織がソフトウェアの開発と保守のために安定した環境を提供しないのが典型的である。組織が健全な管理を欠いている場合、役に立たない計画活動とリアクション型の責任体制によって、良いソフトウェアエンジニアリングプラクティスの利点が損なわれてしまう。危機に直面すると、典型的なプロジェクトは計画された手順を放棄し、コーディングとテストに戻る。プロジェクトの成功は、卓越したマネージャと熟練し効果的なソフトウェアチームがいるかどうかにかかっている。・・・
レベル1の組織のソフトウェアプロセス能力は予測不能である。なぜならソフトウェアプロセスが、作業の進捗につれて、たえまなく変更され、修正され続けるからである（プロセスは場当たり的である）。この場合、スケジュール、予算、機能充足性および成果物の品質は一般的に予測できない。

レベル2　-　反復できるレベル

反復できるレベルでは、ソフトウェアプロジェクト管理の方針とその方針を履行するための手順が確立されている。新しいプロジェクトの計画とその管理は、類似プロジェクトの経験に基づいている。レベル2を達成することの目的は、ソフトウェアプロジェクトの効果的な管理プロセスを制度化することである。具体的なプロセス実装はプロジェクト毎に相違があるとしても、効果的な管理プロセスは、以前のプロジェクトで成功した実践を組織が反復できるようにする。効果的なプロセスは、実践され、文書化され、徹底され、トレーニングされ、計測され、改善可能なものと特徴付けられる。
レベル2組織のプロジェクトでは、基本的なソフトウェア管理を導入している。・・・
ソフトウェア要件およびその要件を満足させる作業成果物にはベースラインがあり、その一貫性は制御されている。ソフトウェアプロジェクト標準が定義され、組織はこれらに忠実に従うことを確実なものにする。・・・
レベル2組織のソフトウェアプロセス能力は、規律ある状態と要約できる。

レベル２の特徴は、基本的なソフトウェア管理が実現されているレベルと要約されます。ここでソフトウェア管理という言葉が使われていますが、これはソフトウェアプロジェクト管理と読み替えてもよいと思いますが、プロジェクトの成果物を対象にした構成管理や客観的な品質保証も含めていますので、多少広めの用語を使用していると考えられます。基本的なソフトウェア管理という言葉は、レベル３以上のプロジェクト管理に対する言葉使いであり、基本的なプロジェクト管理とは、コスト、スケジュール、機能充足性を中心に、発生する問題が生じたときに是正を図るということを意味します。レベル３では起こるかもしれない問題を発生する前に予見するという意味で能動的なプロジェクト管理ということができますが、それに対して、レベル2のプロジェクト管理は受動的なプロジェクト管理ということができます。

また、上記の文章では、プロジェクトと組織の関係で誤解を生じることが懸念されますが、レベル２における主体はプロジェクトであり、組織はプロジェクトに対して、プロジェクトが実装するプロセスに対する方針を示すことが期待されています。ここで、プロジェクトの活動は一連のプロセスで構成されているという考え方が必要です。方針とは、それらのプロセスの活動に対する組織の期待を意味します。それは活動の具体的な方法ということではなく、活動の結果として期待すること、すなわち活動のゴールなり、期待する活動のパフォーマンス、成果物に対する期待などです。ソフトウェアプロジェクト標準とは、方針を満たすための具体的な手段を記述した文書を意味しますが、これは組織が決めることを意図しているのではなく、プロジェクトが自ら確立することを意図していることに注意が必要です。

レベル3　-　定義されたレベル

定義されたレベルでは、組織全体でのソフトウェアの開発と保守の標準プロセスが文書化されている。これにはソフトウェアのエンジニアリングと管理の両方のプロセスが含まれ、これらのプロセスは首尾一貫したものとして統合化される。この標準プロセスは、CMMでは「組織の標準ソフトウェアプロセス」と表されている。ソフトウェアマネージャと技術要員は、より効果的に動けるよう、レベル3で確立されたプロセスを利用する（そして適宜変更する）。組織はそのソフトウェアプロセスを標準化する際には、ソフトウェアエンジニアリングの効果的なプラクティスを活用する。組織のソフトウェアプロセス活動の責任を負っているグループ（ソフトウェアエンジニアリングプロセスグループ（SEPG）などと呼ばれる）が存在する[Fowler90]。要員およびマネージャが要求される知識や技能を習得し割当てられた役割を遂行できるように、全組織的なトレーニングプログラムが履行されている。
プロジェクトは、「組織の標準ソフトウェアプロセス」をテーラリングし、プロジェクトの特徴に合せて、独自の定義されたソフトウェアプロセスを作成する。CMMでは、このテーラリングされたプロセスを「プロジェクトの定義されたソフトウェアプロセス」と呼んでいる。定義されたソフトウェアプロセスは、整った形で定義されたソフトウェアのエンジニアリングと管理のプロセスが一体となって統合された集合から成っている。整った形で定義されたプロセスは、開始基準、インプット、作業を実施するための標準と手順、（ピアレビューのような）検証メカニズム、アウトプット、および完了基準を含んでいる。ソフトウェアプロセスが整った形で定義されているので、管理層はすべてのプロジェクトの技術的進捗をよく見通せる。
レベル3組織のソフトウェアプロセス能力は、標準と首尾一貫性と要約できる。

レベル３では、組織の標準プロセスの確立とそれをもとにプロジェクトがテーラリングした「プロジェクトの定義されたプロセス」に基づいて活動が進められることを意図しています。「プロジェクトの定義されたプロセス」は、レベル2のソフトウェアプロジェクト標準の発展系と位置づけられますが、さらにエンジニアリングの活動が統合化されることが意図されます。ここでいうエンジニアリングとは、純粋に要件仕様から要件を満たす製品を実現する技術的な活動、すなわち、要件分析、設計、レビュー、統合、テストなどの活動を意味し、管理のプロセス、すなわちプロジェクト管理などソフトウェア管理の活動とは分けて議論されています。レベル3ではエンジニアリングの活動と管理の活動が整合され一体化されて定義されることが期待されています。レベル3は、活動等の統合化という言葉で代表されますが、あくまで統合であって、統一化ではないことに注意しましょう。

レベル3では標準プロセスが強調されていますが、何故かということに注意してください。標準化されることは事業目標を達成する上ではあくまで手段であり、目的や目標ではないはずです。すなわち、レベル3の意図は、組織的な活動における一貫性の確立とプロジェクト間における知識やノウハウの共有に意味があります。標準プロセスは最終ゴールではなく、これから組織的な改善を進めて行くための一時的なベースラインと捉える必要があります。さもなければ、標準化により組織は硬直化し、発展はなくなります。

また上記では、エンジニアリングとの統合、標準プロセスとそのテーラリングが強調されていますが、レベル2で述べたように、レベル3のプロジェクト管理では、リスク管理や利害関係者との協調関係、エンジニアリングのより細かい活動粒度（すなわちタスクレベル）での管理の強化など、能動的なプロジェクト管理が期待されています。また、エンジニアリングプロセスの統合により、コスト、スケジュール、機能充足性に加えて、品質側面の管理の洗練化も期待されます。

レベル4　-　管理されたレベル

管理されたレベルでは、組織は、ソフトウェアの成果物とプロセスの両方に対して定量的品質目標を設定している。生産性および品質は、組織的計測プログラムの一部として、重要なソフトウェアプロセス活動について全プロジェクト横断的に計測される。「組織のソフトウェアプロセスデータベース」は、「プロジェクトの定義されたソフトウェアプロセス」から入手可能なデータを収集し、分析するために使われる。レベル4では、ソフトウェアプロセスは、整った形で定義され首尾一貫した計測を備えるようになる。これらの計測は、プロジェクトのソフトウェアプロセスと成果物を評価するための定量的基盤になる。
プロジェクトは、その成果物とプロセスに対する制御を達成し、許容可能な定量的境界内に収めるためにプロセス実績の変動幅を小さくする。プロセス実績の意味ある変動を、（特に確立した製品ラインでは）ランダムな変動（ノイズ）と区別することが可能になる。新しいアプリケーション領域に対する学習過程に伴うリスクは既知のものになり、注意深く管理される。
レベル4組織のソフトウェアプロセス能力は、予測可能と要約できる。プロセスが計測され、計測可能な限界内で遂行される。このレベルのプロセス能力では、このような限界の定量的範囲内で、プロセスと成果物の品質がどんな傾向かを組織が予測できるようになる。これらの限界を越えたとき、この状況を正すための処置がとられる。ソフトウェア成果物は予測可能な高品質なものである。

レベル４の特徴は、組織的な定量的目標管理とプロセスや製品品質の安定化に焦点があります。プロセスが定量的に安定化することにより、はじめて予測可能になります。プロジェクトは、一連の連なったプロセスとして考えることができますので、プロセスを安定化させることは、プロジェクトの成果を安定化させることになり、プロジェクトの成果を早い段階で予測可能にすることを意味します。

測定というと、何故か組織が行うもののように思われがちですが、組織も行うし、プロジェクトも行うものです。組織は、組織の事業目標を達成するために、プロジェクトはプロジェクトの目標を達成するために測定と分析を行います。また、レベル４で初めて定量的管理を始めるわけではありません。レベル１でも測定と分析は行われているでしょうし、レベル２、３でも勿論使われます。

レベル３までの測定は主に計画対実績に焦点があり、できるだけ計画から乖離しないように、プロジェクトで発生する、あるいは、発生しそうな問題に着目した管理が行われます。レベル４は、プロセスの組織的な定量的目標の設定とプロセスを安定化させるために測定と分析を行います。

定量的な安定化を議論するために、レベル4では、シューハートの統計的品質管理を考察しています。しかしながら、ソフトウェアは量産問題が対象となるハードウェアとは問題の質が異なるため、分析は難しい側面を有します。

レベル5　-　最適化するレベル

最適化するレベルでは、組織全体が継続的なプロセス改善を重視している。組織には、欠陥の発生を予防することを目標として、プロセスの弱みと強みを先を見越して特定する手段が備わっている。ソフトウェアプロセスの有効性を示すデータは、組織のソフトウェアプロセスに対する変更提案や新しい技術の費用対効果分析に使われる。最高のソフトウェアエンジニアリングプラクティスによる革新的な改善が特定され、組織全体に移転される。レベル5の組織のソフトウェアプロジェクトチームは、欠陥原因を決定するために欠陥の分析を行う。ソフトウェアプロセスは、既知の欠陥の再発を防止するために評価され、その教訓は他のプロジェクトにも広められる。
レベル5組織のソフトウェアプロセス能力は、継続的な改善と特徴付けられる。レベル5の組織では、プロセス能力の範囲を改善する努力を怠らず、これによってプロジェクトの実績を向上させる。既存プロセスの漸進的進歩と、新しい技術および手法による革新の両方によって改善が行われる。

レベル2～4を通じて、組織やプロジェクトは問題に対処し、プロセスを安定化し、問題の発生を予測したり、結果を予測する術を身につけていることになります。残る課題は、プロセスそのものに根ざす生来の問題をいかに除去するかであり、これがレベル5のテーマです。

成熟度は、プロセス改善の道筋を示すものとして、組織として重要なプロセスを如何に確立、維持していくかということを述べていますが、レベル5における改善プロセスの確立をもって、一応の完成をみることになります。しかしながら、形ができたということであって、最適なパフォーマンスが必ずしも発揮されているとは限りませんので、プロセスは継続的に見直していくことが必要になります。レベル5では、「継続的なプロセス改善」と言っていますが、プロセスだけを見ているのではなく、新しい技術や手法（勿論ツールも含まれます）の導入も含めていますので、むしろ「継続的改善」といった方がよいと思います。

成熟度レベルの理解

CMMは、個々の成熟度レベルにおける組織を特徴付ける重要な（もしくはキーとなる）属性について記述しており、その意味で記述的モデルである。政府との大規模契約プロジェクトを遂行する組織に期待される規範的な行動について、詳細なプラクティスが特徴付けているという意味で、規範的モデルである。CMMは適度なレベルの抽象概念で書かれており、ある組織がソフトウェアプロセスをどのように実装するかについて過度に制約することを意図するものではない。すなわち、ソフトウェアプロセスに本質的な特徴は通常どうあると期待されているかを記述しているに過ぎない。
CMMを適用するいかなる状況においても、キープラクティスは合理的に解釈されるべきである。もしもビジネス環境が、大規模組織のものと比べて大幅に相違がある場合、知識のある専門家の判定のもとで、CMMは適切に解釈されなければならない。
CMMは処方箋ではないので、組織に対して改善の方法を教えたりはしない。CMMはそれぞれの成熟度レベルに達する特定の手法を処方するのではなく、各々の成熟度レベルにおける組織について記述している。レベル1からレベル2までいくのに、数年を要することがあり、他のレベルに移行するには通常、2年ほどかかる。
ソフトウェアプロセス改善は、組織の戦略的計画および事業目標、その組織的構造、その使用技術、その社会的文化、およびその管理体制などの周辺状況のなかで発生する。CMMはTQM運動のプロセス面に焦点を置いている。優れたプロセス改善は、ソフトウェアプロセスの範囲外の観点への対応も伴う（例えば、プロセス改善が実装され制度化されることを可能にするための組織文化の改変に伴う人的問題など）。

制度化とは、よい活動を日常的に繰り返して行えるように、組織の基盤、文化を確立することを意味します。

以上、CMU/SEI-93-TR-24「ソフトウェア能力成熟度モデル 1.1版」の記述を引用して成熟度の各レベルの特徴をみてきました。CMMIでは、各成熟度レベルの名称は以下のように若干変わっていますが、考え方は変わりません。