ソフト開発プロセスの改革指針であるCMM（能力成熟度モデル）と，その後継版であるCMMI（CMM統合）について，悩んでいる知人がいた。名前を仮にH氏としておこう。彼は，大手電機メーカーのソフトウエア開発組織の品質管理担当者としてCMMに取り組んでいた。H氏の悩みは，職場で「表面上の問題だけをみて，規則を守らせようとする口うるさい人」として煙たがれてしまうことだった。
いったん嫌われ者になってしまうと，何をやってもうまくいかない。例えば，こんなことがあった。バグの削減を目標にすると，プログラマも管理者もバグを隠したがる。そこでH氏らは，社内プロジェクトの平均的なバグ発生率までバグを検出しないとOKを出さない，と規定した。すると，開発者はあからじめバグを作り込んで，規定をクリアするバグ発生率を申告するようになった。
これでは何のための品質管理活動だか分からない。全く本末転倒である。H氏には悪いが，さすがにこれほどひどい例はあまりないと思う。だが，筆者自身もかつて，現場の開発者から，H氏のような品質管理担当者への不満の声をときどき聞いていた。例えば「レビューをちゃんとやっているか」いうアンケート調査をするだけだったり，ISOの取得やCMM/CMMIのレベル達成が，手段ではなく目的にすりかわっている，といった内容である。
「バグがこんなにあるじゃないか！」だけではうまく行かない
もちろん，ISOやCMM/CMMIに問題があるのではない。それを利用する側に問題がある。H氏の場合も，残念ながら実践方法が表面的な活動になり，現場に無視されていたのである。
しかし，最近の取材では，そういうことはあまり聞かれなくなってきた。
「最近考え方を変えました」――。こう語る品質管理担当の方は，たいてい，「プロダクト管理」よりも「プロセス管理」を重視するようになったのだという。簡単に言ってしまうと，プロダクト管理が成果物のみを問題にするのに対し，プロセス管理は，成果物の不具合がどこで起こるのか，それがなぜ起こるのかを追及し，開発者に伝えることを重視する考え方である。
もともとCMM/CMMIでは，プロダクト管理もプロセス管理も実施すべき，と示されている。しかし，ともするとH氏のようにプロダクト管理に終始しがちだった。「バグがこんなにあるじゃないか。ちゃんと仕事しろ！」というのももちろん大事だが，それだけでは開発現場は動かせない。
それよりも，「うまくいかないのは，ここが原因じゃないかな。ここを改善すればきっとうまくいくよ」と言った方がずっと建設的だし，開発者にも受け入れられやすい。実際，CMM/CMMIを理解していくうちに，プロセス管理によって開発プロセスの“真の問題”の追及に目覚めた，という人がかなり多い。
現場から頼りにされるには？
しかし，プロセス管理というのは簡単なものではない。原因の特定というのは，骨の折れる仕事だ。「限界値管理」という手法で品質や生産性などの問題や異常を突きとめる場合が多いのだが，組織的にデータを取らねばならず，現場の理解を得るのが大変だったりする。
限界値管理とは，品質や生産性などの変動が問題ないものなのか，何かの原因によるものかを調べるための統計的な手法である。パラメータが上限と下限の限界値の間にあり，パラメータの並び方にクセがないときを“問題がない状態（管理状態）”，限界値を超えたりクセがあるときを“問題がある状態（管理されていない状態）”と判断する。この“問題がある状態（管理されていない状態）”の原因を調べるやり方も，組織によって変わり，決まった方法はない。
あるCMM/CMMIのセミナーで，会場から「どんなメトリクス（評価尺度）を利用すれば良いのか。具体的に教えてほしい」という質問がでた。3人いた講師の先生は，口をそろえて「そういう態度が一番いけない。自社に合ったメトリクスを自分で考えなければならない」とだけ答えていた。随分厳しい先生方だなぁ，とそのときは思ったのだが，改めて考えると，確かにそういうものなのだろう。
CMM/CMMIを極めるのは難しい。しかし，ひとたび自家薬籠中のものにすれば，品質管理担当者が“口うるさい嫌われ者”から強力な“助っ人”になり，現場から頼りにされることも少なくない。そのポイントは，開発現場の問題解決を支援するプロセス管理手法の考え方にあるのだと筆者は思っている。
さて，その後のH氏はというと，元気をなくして会社を退職し，現在はソフト開発に全く関係ない仕事に従事している。彼も彼なりに一生懸命，品質管理に取り組んでいたのだが・・・。そんな彼のことを思うと，新世代の品質管理担当者やソフト開発プロセス改革の担当者が，開発現場に頼りにされる助っ人として，生き生きと活躍することを願わずにはいられないのである。
（安保 秀雄＝日経コンピュータ副編集長）
