ソフト開発監査の方法（３）プロセス監査の確認項目はCMMIの重要なアクティビティを主体に
ソフト開発監査の確認綱目は CMMI を参考にした重要なプロセス活動が主体
開発委託先のソフト開発能力の良し悪しを判定するソフト開発監査では、監査で確認するソフト開発プロセスの項目は、CMMI でも重要ポイントとされている要件管理、開発計画、進捗管理、品質保証、構成管理、外注管理の６種類です。監査の手順は ISO9001 と似ていますが、ISO9001 は工場での製造品質の確認が主体ですので、確認する項目は CMMI を参考にしてあります。
ISO9001 は改善を目的として監査をし CMMI は能力を測るために認証をする
ISO9001 とよく似た手法でソフトウエアのプロセス改善に使われるのが CMMI です。 ISO9001 も CMMI もプロセスを定めたルールがあるあどかの確認とそのルールが着実に実施されている事の確認を主体にしていますので、実施する方法はよく似ています。でも、ISO9001 と CMMI とでは、その目的に違いがあるのでこの違いは注意してよく認識しておく必要があります。前の記事では ISO9001 を工場での製造品質を改善するためのツールですと紹介しましたが、それに対して CMMI は組織の持つソフトウエア開発の能力の良し悪しを判定するために考案された方ツールです。こおの目的の違いが、ISO9001 は監査を行うのに対して CMMI は認証を与えるというアクションの違いに現れてきます。
ＣＭＭＩ認証とはソフトの開発管理能力のレベルを示す
それでは CMMI の認証とはどんな物でしょうか。CMMI の認証とは、調査をした時点においてその組織のソフトウエア開発のプロセスの完熟度が何段階目にあるのかを認証するものです。もう少し平たく言えば、CMMIレベル３の組織よりもCMMIレベル４の組織のほうがソフト開発プロセスが優れていますよ、というお墨付きを与えるものです。
ちなみに、CMMI は CMM の改善版ですが、今世の中で実施されているのは CMMI です。CMMI は、Capability Maturity Model Integration の頭文字をとった略称で、日本語では能力成熟度モデル統合版と訳されています。（CMM は最後の Integration が無い版です）
能力成熟度モデル統合版、と言われてもなんかさっぱりイメージが湧かないですね。ざっくり言うと、ある組織のソフトウエアの開発管理の能力がどれだけ良いものかを評価するための方法、です。完熟とは実が充分大きくなって内容も充実する事なので、ソフトの開発管理能力が充分に充実しているかどうかを評価する方法、と言い換えると少しは判り易くなるでしょうか。
なぜ CMMI は ISO9001 と目的が違うのか？
CMMI の元になった CMMは、もともと米国国防省（ペンタゴン）が良い品質のソフトを納入できる開発委託先を選定するために、開発委託先のソフト開発管理の能力を判断する方法を、CMU（Carnegie Mellon University）のSEI （Software Engineering Institute）に依頼して考えてもらったものです。
米国は膨大な予算を投じて軍事用のソフト開発を様々な会社に委託しているので、委託先に良い会社を選ぶ事はとても重要になってきます。ところが、ソフトというのは目に見えなくてまた工場での量産製品ではなく一つ一つが一品生産物です。そのためどの会社に開発委託すれば良いソフトが安く出来上がるのか見極めるのがとても難しいです。この、良いソフトを開発してくれる会社を見極めるための手法を、CMU の SEI に考えてもらったのが CMM です。 そしてこの CMM をソフト開発以外の業務（サービス提供等）にも展開できるように拡張したのが CMMI です。
このような生い立ちなので、CMMI は「ある時点における組織のソフト開発管理の完熟度を測る」事を目的としています。 ISO9001 が製造管理の改善という相対的な能力の改善を目的としているのに対して、CMMI は開発管理能力の現時点での状況という絶対的な評価の提示を目的としている、とう違いは意識しておくと理解をし易くなります。
CMMI の認定レベルは１から５の５段階
結局のところ、CMMI が評価するソフト開発能力の完熟度とは、少しブレークダウンして言うとソフト開発管理プロセスの完熟度という事になります。つまり、ソフトの開発管理プロセスが充分に充実しているかどうか、その充実の度合を評価するのが CMMI です。ザックリ言うと、その組織のソフト開発管理プロセスについての通信簿ですね。
通信簿ですので評価の段階があります、CMMI ではソフトプロセスの完熟度を以下の５段階のレベルで表現します。
レベル１：初期段階（開発プロセスは場当たり的でソフト開発の成功は個人の力量に依存する）
レベル２：反復できる（基本的な開発管理のプロセスができていて、経験のある開発なら成功するプロセスがある）
レベル３：定義された（管理と技術のプロセスが標準化されていて、個々の開発は標準プロセスを取捨選択して作れる）
レベル４：管理された（プロセスとプロダクトの品質を管理する指標があり定量的な管理がされている）
レベル５：最適化する（革新的な技術の試行やプロセスの定量的なフィードバックでプロセスの改善が継続される）
こうやって書きだした概要を読むと、開発を委託する時にはレベル１の組織よりもレベル３や４の組織に委託したほうが、納期までにちゃんとソフトを仕上げてくれそうに思いますよね。という事で、CMMI によるプロセス管理能力の完熟度の評価は、どの会社にソフト開発を発注するかを判断する時の有効な情報の１つになり得ます。
CMMI をソフト開発監査に使う場合のメリットとデメリット
まあ、CMMIも単なるツールなのでうまく使いこなせないと成果（良いソフトの開発）には結びつかないのですが、、、そこはまた別の機会に譲るとして、ソフト開発監査に CMMI を用いるメリットとデメリットを整理してみましょう。
【メリット】
- どんな開発管理プロセスが必要かソフト開発に固有の物を中心に具体的に書いてあるので監査がし易い
- レベル２～５の各々のレベルに到達するにはどんな開発管理プロセスが必要なのかが判り易い
【デメリット】
- ある時点での管理プロセスの完熟度の評価が目的なので、組織の改善に使うには別の工夫が必要
- 開発管理プロセスの評価が目的なので、開発技術は測れない
という事で、CMMI の認証はチェックの中味はソフト開発に特化しているので具体的で使い易いのですが、ソフトの開発管理能力を改善する場面で使うには別途工夫が必要になってくる、という物です。