ITCサンシャイン・ブレインズ

PPAとは─CMMと何が違うのか─

ISO/IEC TR 15504とは
ISO/IEC TR 15504（ソフトウェアプロセスアセスメント）は、アセスメントを実施するときの要求事項を定めたもの。1993年にISOで検討が開始され、5年後の1998年に発行された。日本では、標準情報 TR X 0021として翻訳され、1999年に発行されている。

検討当初は、世界で共通に使用できるCMMなどに相当するアセスメントモデルを開発することを狙った。しかし、すでにCMMが米国内では定着し始めてお り、移行が困難になったなどの事情によって、抽象度を高め、アセスメントモデルに対する要求事項と、アセスメント手順として守るべき事項を定義するにとど めることになった。もともとの狙いが、応札した複数企業のアセスメント結果を相互に比較できることであったため、アセスメントモデルが守るべきフレーム、 すなわち、プロセスそのものとプロセス能力の枠組みを定め、ISO準拠のアセスメントモデルは、プロセスそのものとプロセス能力の枠組みによるアセスメン ト結果を、ISO/IEC TR 15504が定めるプロセスと能力のフレームに変換できることを求めている。

ISO/IEC TR 15504に準拠したモデルとして現在知られているのは、PPA、SPICE、eSPAなどがあり、CMMIは準拠に向けた検討が進められている状況である（図4）。

ここでは、これらの中で最も実績があり、今後日本でも拡大するであろうPPAについて紹介する。

■PPAの起源とモデル構造
PPAは、ISO/IEC TR 15504に準拠したモデルの1つとして開発されたプロセスアセスメントモデルである。英国を中心とした欧州で主に利用されている。MOD（英国国防 省）、ブリティッシュエアロスペース、TRW、ブリティッシュテレコム、ノーテルなど、政府、通信、金融、一般IT分野などの主要企業や中小企業で、主と してプロセス改善用に使われている。欧州にあるIBMやシティバンクなどの米国系企業でも使われている。PPAの開発は、広い範囲でビジネスに実際的に使 用されることを意図して、UPAC（United Kingdom Process Assessment Consortium）により行われた。

PPAの前身はSTD（Software Technology Diagnostic）というモデルで、1992年に中小向きのプロセス改善モデルとして運用が始まっている。STDの開発者はISO/IEC TR 15504の検討に当初から中心的に参画しており、STDはCMMと並んでISO/IEC TR 15504の主要なインプットの1つとなった。並行してSTDをISO/IEC TR 15504準拠にするように強化を図ったものがPPAである。CMMに比べてビジネスプロセス志向である。

ISO/IEC TR 15504に準拠したPPAは、次のようなモデル構造を有する。

（1）プロセスとプロセス能力レベルの二次元構造
PPAはプロセス座標（process dimension）を横軸に、プロセス能力レベル座標（capability dimension）を縦軸に持つマトリックス型の構造を有している。横軸には6つのカテゴリと約60のプロセスを有し、縦軸には0－5の6段階の能力レベルがある（図5）。

（2）プロセスの種類
PPAのプロセス座標（横軸）には、組織の役割との関係で必要とされる購入、供給、エンジニアリング、支援、管理、組織の6つのカテゴリが存在する。こ のカテゴリは階層構造を有し、各カテゴリの基本プロセスとその要素プロセスからなる約60のプロセスを有する（図6）。

（3）プロセス属性
縦軸のプロセス能力レベルには、0～5までの6段階がある。レベル0を除く各段階には、プロセス属性と呼ばれる、プロセス能力の評価可能な特性が定めら れている。主に、レベル1ではプロセスの実施、レベル2ではパフォーマンス強化、レベル3～5ではプロセスマネジメントのプロセス属性など、能力水準に対 応したプロセス属性が定められている（図7）。

（4）プロセス能力の4段階評定
プロセス座標（横軸）にある各プロセスについて、プロセス能力座標（縦軸）に定められた各プロセス属性の達成度を、F、L、P、Nの4段階の評価尺度で評定している（図8）。

（5）プロセス能力レベルの判定
一連のプロセス属性評定結果に基づき、アセスメント対象に選択したプロセス能力を6段階で判定するようになっている。能力判定は下位レベルからの積み重ねであり、上位レベルだけでの能力判定は行われない（図9）。

（6）アセスメントモデルと手法
PPAを用いたプロセスアセスメントは、アセスメントモデルとアセスメント手法を用いて実施される。その構造を図10として示す。

■PPAの狙いとメリット
PPAの主な特徴を整理すると次のようになる。
（1）マトリックス構造を用いたアセスメント適用範囲の自由な設定
PPAは、プロセス座標（横軸）とプロセス能力レベル座標（縦軸）のマトリックス型の構造を有しているため、現場で必要とされるプロセスに集中した改善 を実施することができる。CMMのステージ型モデルでのプロセス改善は、最初の段階から6つのKPAを対象とするため、やや大掛かりであるのに対して、 PPAではアセスメントの適用範囲を自由に設定して、融通性があり小回りの利くアセスメントを提供することができる。

ソフトウェアの開発は、多数の企業が共同して作ることもあり、その場合、プロセスも分担されることがある。下請けも含めて、全体の能力を把握し調整する うえで、CMMはその方法を提供していない。PPAはプロファイルを合成することにより、それができる（図11）。

（2）情報技術やビジネス分野に適用できる豊富なプロセス
PPAでは、ISO/IEC TR 15504のプロセスを修正して、さらに情報技術やビジネス分野における多くの主要なプロセスをエンハンスして、ビジネスプロセスを含む約60のプロセス から構成されている。CMMではソフトウェア調達向けに作成された経緯があり、ソフトウェア分野の18のプロセスしか提供していない。

（3）プロセスごとの能力レベル評価
PPAのマトリックス型モデルでは、プロセス属性を用いて、すべてのプロセスに対してプロセスの能力レベルを評価することができる。CMMは組織を評価対象としているため、プロセスごとの能力評定方法は提供していない。

（4）4段階のきめ細かなプロセス能力評価
PPAのプロセス能力評価では、評定尺度に4段階（F、L、P、N）評価を採用し、より木目細かな洞察を得ることを支援している。CMMや ISO9001のような、○×評価（Satisfied、Unsatisfied）よりも、弱い部分をビジブルに特定しやすく、組織に必要なプロセスを効 果的に改善するために有効な評定方法である。CMMなどは満足か不満足かを判断するが、どの程度の改善余地があるか提示していない。

「＠ＩＴ」より掲載

---

PPAの適用事例

■PPAによるプロセスアセスメント事例
それでは、PPAによるプロセスアセスメントの事例を使って、PPAに期待できる効果を確認しよう。PPAアセスメントには5ステージある。開始、準 備、評価、分析と報告、完了である。第2ステージの準備の部分でアセスメント適用範囲を選定し、第3ステージの評価を実施して、第4ステージの分析と報告 で本プロジェクトのプロセス改善領域の識別を実施した（図12）。

（1）アセスメント適用範囲の選定
この事例では、開発プロジェクトの推進に当たり、自社組織のニーズおよびビジネスゴールを考慮に入れ、プロジェクト推進のリスク分析などを狙いとしてア セスメントを行った。選択したプロセスは、リスク管理、プロジェクト管理、要求事項管理、戦略管理の4つ。プロセス能力は、本プロジェクトで必要十分と想 定されるレベル3までを選定した。

（2）アセスメントの実施
アセスメントは、PPAリードアセッサが、主にインタビューと文書レビューによって実施された。PPAでは少なくとも2名以上のアセッサでアセスメント を実施し、プロジェクトに提示されるアセスメント結果は、アセッサチーム内で合意したものである。アセスメントを実施して得られた結果（プロファイル）を 図13に示す。

（3）プロファイル分析による改善プロセスの識別
PPAアセスメントのプロファイルは、図のように可能な限りビジュアルに提示することにより、プロセスの弱みを識別しやすいように工夫する。
本アセスメントでは、図示したプロファイルからレベル2のQC（品質制御）に共通した弱みがあることに気付く。また、要求事項管理プロセスのPM（プロ セス管理）が弱いことが分かるだろう。これがプロセス共通にQCが弱いことの原因になっていると考えることができる。また、レベル2に弱みが多いにもかか わらず、レベル3の結果が良い。それから、対象プロジェクトはしっかりした組織標準があるにもかかわらず、それをテーラリングして十分に使いこなせていな いことがうかがえる。
これは簡単な事例であるが、PPAではアセスメント対象となったプロジェクトの強み・弱み、それに組織的なプロセスの強み弱みを客観的に分析することができる。

■ソフトウェアプロセスからビジネスプロセスへ
ソフトウェアプロセスを改善する際に重要なことは、ソフトウェアの開発という枠の中だけではなく、より広範囲なビジネス環境の中で改善活動が行われると いう認識である。今後の方向としてはソフトウェアプロセスからシステムプロセスへ、さらにビジネスプロセスへと視野を広げることである。現在その位置付け にあるのがPPAである。

例えば、現在のような競争環境下での戦略では、何よりも時間（スピード）が重要な要素となる。特に持続力のある競争優位を作ることが大切となるが、その ために企業活動の役割を明確に浮かび上がらせるコンセプトとしては、バリュー・チェーンが考えられる。これはソフトウェア組織においても例外ではない。バ リュー・チェーンは、一般に5つの主活動と4つの支援活動に分類されるが、このプロセスはソフトウェア開発組織の枠を超えた経営層（ビジネスマネジメン ト）の領域である。これまでに、CMMのような成熟度モデルでは、この領域のプロセス管理能力を扱うことはできなかった。PPAであれば、バリュー・ チェーンの大部分のプロセスをその対象にできる。ソフトウェアプロセスを超えてビジネスプロセスの管理にも役立てることができる。

またISO/IEC TR 15504系のモデルでは、必要なプロセスが不足する場合にはほかのプロセスモデルを使用することも可能である。例えば、経営品質の分野であればマルコ ム・ボルドリッジ国家品質賞や経営品質賞をプロセスとして使用することもできる。

PPAのコンセプトは会社経営上の管理支援ツールとして、今後大いに発展する素地を有している。

参考文献
・Barry Boehm,Software Validation,The Price of Procrastination, IEEE Trans on Computer, 1976・Software Hell, Business Week, Dec. 6, 1999・Carnegie Mellon University, Software Engineering Institute, The Capability Maturity Model, – Guidelines for Improving the Software Process -, Addison Wesley Longman, Inc, 1998・Watts S. Humphrey, “Managing the Software Process”, Addison-Wesley Publishing Company, 1990・Kim Caputo, CMM Implementation Guide, Choreographing Software Process Improvement, Addison Wesley Longman, Inc, 1998