品質保証と品質管理

 プロセスの改善、あるいはプロジェクト管理に取り組むとき、必ず出てくるのが、この 「品質保証」 と 「品質管理」 です。 中には、これらは言い方を変えただけで、同じものと思っている人も居るようですが、この2つは全く異なるものです。 簡単に言ってしまえば、 「品質保証」 は、品質を保証できる( あるいは保証しようとする )仕組みを持っていることで、 「品質管理」 とは、品質上の目標を定めて、それに達するための取り組みを考え、作業( 結果 )を計測し、目標に近づけるためのマネージメントです。 この2つの違いを誤解したままでは、プロセスの改善は進みません。 このあと、それぞれについてもう少し詳しく説明します。

 CMM の各レベルでの取り組みを見てください。 品質保証はレベル2のKPA( Key Procrss Area )にあるのに対して、品質管理は、レベル4のKPAにあります。 これは、品質管理は計測が前提であり、かつそのためには、品質保証の体制が整っていなければならないということを表しているのです。 私たちは、簡単に 「もっと品質管理しなければ ……」 といいますが、実は、品質管理は、容易には実現しないものでもあります。


品質保証

 品質保証は、レベル2の取り組みのテーマです。 もちろん、レベル2で完成するものではありません。 現実問題として、品質保証はプロセスの定義が前提となりますので、通常は、レベル3にまで引きずっていくことになります。 それでも、レベル2の取り組みのところで、何とかプロセスの定義に取り組み、その流れの中で、品質保証の仕組みを手に入れようというのです。

 品質保証とは、要求仕様を漏らさないプロセスを持っているとか、漏れるかもしれない状況でそれをカバーするプロセス( レビューなど )を実行しているとか、テスト仕様にそれが確実に反映される仕掛けや、それが事前にチェックされる仕掛けを持っている。 また、仕様を実現するための適切な設計を行うことができ、それが独りよがりではないことを確認するプロセスを持っていて、仕様が確実に設計されている事を確認するプロセスも用意されている。 そしてソースに成ったときは、そこでも設計書との食い違いがないことを確認するプロセスかあり、テストが省かれないように、またバグが勝手に修正されないようなプロセスを持っていて、厳しく監視する仕組みが整っている。 さらに、このようなプロセスが機能するような成果物の構成や内容が事前に検討されており、表記ルールなども予め決められていて、そこに合意ができている。 こういう取り組み方をしていますよ、個人が勝手なことは出来ないようになっていますよ、という 「保証書」 でもあるわけです。

 もちろん、レベル2での完成度としては、それほど高いものは期待できないでしょう。 それでも、限定された状況ではあっても少しでも約束できるために、プロセスの定義に取り組み、自分たちにとって何とかうまくいく作業の流れを掴もうとすることが大事です。 レベル2では、ちょっと気を許すと、直ぐに戻ってしまいますので、立ち止まらずに前進することの強い意志、あるいは強いリーダーシップが必要です。

 プロセスの流れができ、それぞれのプロセスがそれなりに( レベル2なりに )定義されるようになって、品質保証の形が出来てきたとしても、これだけで、バグが無くなるわけではありません。 もちろん、品質保証が出来ているとして認められる程の状態になれば、仕様の誤解や不用意な仕様漏れ、また設計漏れといったバグは、相当数は姿を消すはずです。 それは、バグの原因はプロセスの欠陥にあるからです。 でも、レベル2ということは、まだまだプロセスの精度が低く、実際の作業との間で食い違っていたり、成果物の内容が予定通りに行かなかったり、仕様の誤解などによってスケジュールが逼迫したことで、プロセスの“ショートカット”をやってしまうことがあります。 このような状態が残っているかぎり、バグは残ってしまいます。

 ある程度プロセスが定義されていることで、大崩れは免れ、なんとか許される範囲で収めることが出来るのがレベル2でもあります。 これがレベル3に進むことで、プロセスの定義がより厳密になり、プロセスの時間を測ったり、レビューの測定や評価が出来たり、成果物の欠陥の測定や分析が出来るようになります。 このような状態が、品質管理の下地となるわけです。


品質管理

 プロセスの定義もある程度の精度で実現し、品質保証が安定してくると、本格的に品質管理に取り組む環境が整います。 品質管理は、計測することが前提になります。 プロセスを安定させるのはそのためです。 一般に、品質管理の取り組みでは、まず、適当な品質特性について目標を設定します。 例えば、第1回目のテストでは、プログラムの 「機能性」 に関する欠陥を50件以内とするとか、設計書に対する欠陥の指摘を20件以内とする、というように、目標を定めます。 もちろん、これらの目標は、その組織において現実離れしたものでは意味がありません。 第一、所定の期間内に、その目標に達するための取り組みが考えられません。 時間内になんとか到達するようなステップが描けないような目標には、意味がありません。 はやる気持ちはわかりますが、具体的に道筋が見えないような目標は時間の無駄というだけでなく、組織のモチベーションにも悪い影響を与えます。

 残念ながら、多くの組織においては目標は立てるものの、その目標に至るためのステップ、すなわちプロセスが定義されることは殆どありません。 目標とする山は設定しても、どうすればその山に登ることができるのかを、誰も示さないのです。 実際に、そのような山に登った人がいないことが、最大の原因と思われますが、そのような場合は、目標を低くして、始めてでもそこに登るための方法を考えることができることが大事です。 そして、実際に取り組んでみて結果が出たときに、そこで考えた取り組みの“お陰”でうまく行ったことを実感できることが大事です。 そのためにも、目標は、背伸び、あるいは、ちょっとジャンプして届く程度にしておくことです。

 目標に到達するための取り組みは、必ず、現状の( それまでの )プロセスの変更を伴います。 新しいプロセスが追加されたり、プロセスの定義が変更されたり、成果物の内容や構成が変わったりします。 これを伴わない取り組みはありません。 ここで、レベル3であることが意味を持つわけです。 レベル2では、プロセスの定義が甘く、目標が設定されても、それに対して的確にプロセスの変更が対応しません。 目標に対してプロセスの変更( 変化 )が対応して、はじめて効果( 結果 )との因果関係が確認できるのです。

 そうして、結果は向こうからやって来ます。 その結果を目標と比べて、達成したのかどうかを判断します。 目標に達していなければ、プロセスを調整して再び取り組むことになります。 目標に達していれば、そこで定義されたプロセスが有効であったことになり、そのプロセスを、しばらくは安定的に使用することになります。 もちろん、そのプロセスも、状況の変化や新たな目標の設定によって、変更されることは言うまでもありません。

 このような品質の管理は、いろんなところで実施することができます。 プログラムのバグだけでなく、レビュー( ウォークスルー )に於ける成果物の欠陥の指摘でも取り入れることができます。 見積りとの誤差を縮めるところにも使うことが出来ます。 品質的な目標が設定できて、それが計測によって検証できるものであり、それを実現するためのプロセスが考えられれば、そこに品質管理を取り入れることができます。 要するに、品質保証が出来るほどにプロセスが定義されている状況であれば、品質管理は可能だということです。




CMM(capability maturity model)
シーエムエム / 能力成熟度モデル / ソフトウェア能力成熟度モデル


 企業や団体、プロジェクトチームなどの組織的能力を成熟度という概念で示して、その能力水準を判定したり、能力向上を図ったりするために作られた各種リファレンスモデルの総称。基になったソフトウェア能力成熟度モデルであるSW-CMM( CMM for Software )のことを指していることも多い。

 もともとは、ワッツ・S・ハンフリー( Watts S. Humphrey )教授が著した 「Managing the Software Process」 を下敷きに、カーネギーメロン大学のマーク・C・ポーク( Mark C. Paulk )やビル・カーティス( Bill Curtis )らが改良を加えて作られた、ソフトウェア開発能力の成熟度を測る 「ソフトウェア能力成熟度モデル:SW-CMM」 が元祖である( 1991年発行 )。
 ここから派生して、システムエンジニアリングに関する 「SE-CMM:System Engineering CMM」 やソフトウェア調達の能力を測る 「SA-CMM:Software Acquisition CMM」、人材開発能力の成熟度モデル 「P-CMM:People CMM」、製品開発に焦点を当てた統合プロダクト開発成熟度モデル 「IPD-CMM:Integrated Product Development CMM」 など、特定分野別にさまざまな成熟度モデルが生まれた。これらを 「CMMs」 と総称する。

 ただしCMMといった場合、通常は基になったSW-CMMを指すことが多い。 ソフトウェア開発の調達先認定およびプロセス改善( SPI:software process improvement )のための指標として、広く全世界で採用されたため、知名度も高かったためである。

 SW-CMMにおけるレベルの概要は以下の通り。
・レベル1:プロセスが確立されていない初期段階
・レベル2:特定のプロジェクトリーダーや技術者に依存している状態
・レベル3:首尾一貫したプロセスを標準として持っている段階
・レベル4:標準化されたプロセスを定量的に測定し、洗練化していく状態
・レベル5は技術・要件環境の違いによって、標準プロセスを最適化して用いられる段階
 SW-CMMについては、その作成・運営団体であるカーネギーメロン大学 ソフトウェアエンジニアリング研究所( CMU/SEI )が作成中だったV2.0が公表されることなく、CMMIに統合され、これが後継モデルとなっている。


CMMI( capability maturity model integration )
能力成熟度モデル統合 / CMM統合 / SEI CMMI


 専門分野・改善作業内容別に複数存在していたCMMを整理・統合し、分野横断的な改善活動で利用可能な手引きとして定義・策定されたプロセス改善モデル。 世界中の組織・企業でCMMを利用した結果をフィードバックして、より効果的なモデルとして作られた。

 1980年代半ばにカーネギーメロン大学 ソフトウェアエンジニアリング研究所( CMU/SEI )で開発が始まったCMM( SW-CMM )は、ソフトウェア開発のプロセス改善において大きな成果を示した。 この成功は、さまざまな分野で類似の改善モデルを多数生み出すことになった。

 これらのモデルは各分野の特定プロセスに適用するには有用だったが、大規模な組織が複数の異なるプロセス同士を横断的に連携して改善活動を行おうとする場合、訓練や評価、プロセス資産の重複など、コスト・手間・一貫性といった点で問題があり、改善活動の目的や焦点がぼやけるという弊害が指摘されるようになった。

 そこで1997年、米国国防総省( 科学・技術国防副長官 )がCMU/SEIとNDIA(米国国防産業協会)の協力を得て、複数の改善モデルを統合するCMMIプロジェクトをスタートした。 短期的には 「ソフトウェア能力成熟度モデル」( SW-CMM )、 「システムエンジニアリング成熟度モデル」( EIA/IS 731 )、 「統合成果物開発成熟度モデル」( IPD-CMM )の3モデルの統合が目標とされ、2年余りを経た2000年に最初のCMMIモデル( V1.02 )と関連アセスメント、トレーニング成果物がリリースされた。さらに2002年にはV1.1( システムエンジニアリングおよびソフトウェアエンジニアリングのためのCMMI:CMMI-SE/SW )が、2006年にはV1.2( 開発のためのCMMI:CMMI-DEV )がリリースされている。これらはCMU/SEIのサイトからダウンロードでき、無料で使用することができる。

 CMMIモデルの基本は、プロセス領域( process area )である。 これはプロセス改善における活動を分類したもので、従来のSW-CMMでいう 「キープロセスエリア」、EIA/IS 731でいう 「フォーカスエリア」、IPD-CMMでいう 「プロセスエリア」 に該当する。 CMMIではこれらを整理・統合し、CMMI-DEV V1.2では22のプロセス領域が定義されている。 各プロセス領域には固有ゴールと共通ゴールがあり、固有ゴールには固有プラクティスが、共通ゴールには共通プラクティスが設定されている。 これらのプラクティスを実施し、ゴールを満たすことが成熟度・能力の達成につながる。

「開発のためのCMMI V1.2」 のプロセス領域
連続表現の
グループ
プロセス領域 段階表現のグループ
(成熟度レベル)
プロセス管理 OPF:組織プロセス重視   3    
OPD:組織プロセス定義+IPPD   3    
OT:組織トレーニング   3    
OPP:組織プロセス実績     4  
OID:組織改革と展開       5
プロジェクト管理      PP:プロジェクト計画策定 2      
PMC:プロジェクトの監視と制御 2      
SAM:供給者合意管理 2      
IPM:統合プロジェクト管理+IPPD   3    
RSKM:リスク管理   3    
QPM:定量的プロジェクト管理     4  
エンジニアリング RD:要件開発   3    
REQM:要件管理 2      
TS:技術解   3    
PI:成果物統合   3    
VER:検証   3    
VAL:妥当性確認   3    
支援 CM:構成管理 2      
PPQA:プロセスと成果物の品質保証 2      
MA:測定と分析 2      
DAR:決定分析と解決   3    
CAR:原因分析と解決       5
 CMMIは異なるモデルを統合した結果として、 「段階表現」 と 「連続表現」 という2つの表現形式を持つ。 これは全プロセス領域のグルーピングにおける考え方の違いを示すものだが、ユーザーにとっては改善活動に対するアプローチが異ってくる。

 段階表現は 「成熟度」 ( maturity )の概念を用いて、組織( 企業全体・部署・プロジェクト )を5段階の成熟度レベルで診断し、そのレベルに応じて改善活動( プロセス領域 )を順序に従って実施していく。 ある成熟度レベルを達成するには定められたプロセス領域の活動を省略することなく行うことが求められる。 また、高い成熟度レベルの組織になるためには、下位レベルを必ず確立してからでなければならない。 改善活動をどこから手を付けてよいか分からない組織にとって適したアプローチである。

 これに対して連続表現は 「能力」 ( capability )という概念を中核に据え、選択したプロセス領域ごとにベースラインを設定して改善活動の結果を測定、達成された能力に評点を与えて可視化して、改善サイクルを回していく。 このとき、能力値は組織にではなく、プロセス領域に対して付与される。 どのプロセス領域に焦点を当てるかは、その組織の必要・目的に応じて柔軟に選ぶことが許されている。 各プロセス領域には依存関係があるので選択に一定の制限はあるが、自由度はかなり高い。

 ユーザーは原則としてどちらかの表現形式を選択して使用することになるが、この2つはプロセス改善においても評定( appraisal )においても本質的には等価な結果が得られるように設計されており、双方を必要に応じて並行的に使い分けることも想定されている。