４年ほど前、約３０億円規模のソフトウェア開発プロジェクトをカットオーバーした直後、ソフトウェア開発プロセスの能力成熟度モデルのアセスメントを受審しました。
プロジェクトそのものは、納期面・品質面・収益面とも申し分なく、また、プロジェクトの開始に先立って、各種標準（工程標準、成果物標準、設計標準、ツール標準）・共通部品等を整備し、プロジェクト実行計画書・品質保証計画書を策定し、それに基づいたＰＤＣＡを回していたこともあり、プロジェクトのメンバーともども余裕を持って審査を受けることになりました。
そもそもの能力成熟度モデルについてですが、ソフトウェア開発を行う組織がプロセス改善を行うためのガイドラインであり、カーネギー・メロン大学の下部組織であるソフトウェア工学研究所（ＳＥＩ）が考案したＣＭＭＩ（Capability Maturity Model Integration：能力成熟度モデル統合)等いくつかの種類があります。私たちが受審したのは、ＣＭＭＩの作成者も参画して策定された「ISO/IEC 15504」・・通称、ＳＰＩＣＥ（Software Process Improvement and Capability dEtermination）というモデルに基づくものでした。
ＳＰＩＣＥモデルにおいては、ソフトウェア開発を行う組織のプロセスの成熟度を、６段階のレベルで評定します。
レベル０ 不完全なプロセス（Incomplete process）
レベル１ 実施されたプロセス（Performed process）
レベル２ 管理されたプロセス（Managed process）
レベル３ 確立されたプロセス（Established process）
レベル４ 予測可能なプロセス（Predictable process）
レベル５ 最適化しているプロセス（Optimizing process）
レベル２以上の状態になって、ようやくプロセスの状況が管理者にとってプロジェクトが「見える化」になることがわかります。
そこで、レベル２相当と認定されるために必要な主要プロセス・・「プロジェクト管理」「品質保証」「構成管理」等の「マネジメント系プロセス」とともに、実開発メンバーにとって、現場の日々の作業に直結する要求分析・設計・構築・ソフトウェアテスト・・といった「エンジニアリング系プロセス」を審査の対象としました。
ところで、アセスメントの結果は、どうだったでしょうか？
実はちょっと残念なもの・・・いえ、プロマネにとっては極めて手厳しいものでした。
要求分析・設計・構築・ソフトウェアテスト・・といった「エンジニアリング系プロセス」は高く、ルールに則って開発されており、結果として、高品質・納期遵守を達成している、ということで概ねレベル２の評定でした。
一方、プロマネの本業であるはずの「マネジメント系プロセス」については低く、プロジェクトが円滑に推進しているのはプロセスによるものではなく、プロセス以外の方法（人的スキルや能力）で行われている可能性が高い、との指摘でした。当時、プロマネとしては、マネジメントがエンジニアリングの足を引っ張っている、という事実を突きつけられたようで、衝撃であるとともに、プロジェクトメンバーに対して、とても申し訳なく思ったことを覚えています。
その後、「プロセス以外の方法（人的スキルや能力）」で押さえられているという暗黙知を、プロセス標準のかたち等に明文化し、極力、形式知とする努力を続けるとともに、新規メンバーへのプロジェクトの導入教育の実施、また、プロセス標準改訂毎の再教育の実施を続けています。また、１年に一度のペースで、アセスメントの再審査を受けて、改善指摘を受けつつ、改善活動を続けています。
アセスメントを受けてわかったこととして、
１．改善活動は、漸進的にしか進まない
２．いきなりレベル３以上の組織を作ることはできない
３．途中のレベルを抜かすことはできない
４．レベルが低い段階は、新技術の導入より先にすべきことがある
「レベル１からレベル２への移行が一番困難である」といったのは、成熟度モデルの提唱者であるワッツ・ハンフリー氏ですが、それは、混沌とした組織文化から、近代的なマネジメントの文化へという価値観の転換が必要であるためだと思います。
レベル１からレベル５を目指す取り組みは、１０年のスパンでプランすることを覚悟する必要があるため、経営のコミットが必須となります。
ところで、現場のプロマネがほしいのは、ＣＭＭＩやＩＳＯのソフトウェア開発プロセスの成熟度のレベルの高い評定ではなくて、「予測可能性」・・あとどれだけの工期と工数で、どの程度の品質のソフトウェアができあがるのか？ということだ、と思います。
工期・工数・品質の指標は、開発プロセスの品質・生産性とリンクすることを踏まえると、「最下層のあえぎ」と評される、成熟度レベルが１未満のプロジェクトチームを救う重要な方策は、開発プロセスの改善です。
プロジェクトメンバーの幸福のためには、プロジェクトの現場が３Ｋから３Ｔ（楽しい、給料高い、定時に帰れる）へ変身する必要がありますが、そのための１つの有効な弾丸が、全員参画型のプロセス改善活動であると思います。
そのため、現場任せで、プロジェクトが円滑に回るまではプロセス改善に手をつけないという事態を避けるためにも、プロセスが不十分なうちは、組織側からのコミットと少し手厚いフォロー、人のアサインが必要になります。その上で、プロセスの成熟度にあわせて、冗長なプロセスや人のアサインをスリム化するという順序を間違えないことが大切です。
そして、高度化を目指す対象プロセスも、自組織やプロジェクトの課題を踏まえて選ぶ必要があります。たとえば、見積り精度を高度化したいのであれば「見積り」プロセスを選び、また、レビューやインスペクションの方法を改善したければ「ピア・レビュー」プロセスに取り組むということから始めることも、プロジェクト現場のモチベーションと業務への効果の観点から有効です。
最後に、プロマネ及びプロジェクトメンバーは、アセッシー・・・アセスメントを受ける立場なのですが、組織としてのプロセス改善のためには、アセスメントを実施するアセッサーの協力・参画も必須であり、いかに一体となったプロセス改善活動とすることができるかが成功の鍵であると思います。