CMM/CMMI導入・成功と失敗の分かれ目：始めよう、組み込み開発プロセス改善（3/3 ページ）

[石田 己津人，＠IT MONOist]

CMMIに対する誤解

　それでも最近、組み込み業界から「CMMIは使えない」という声が強まっているのも事実である。

　例えば、「日本の組み込み分野は品質レベルが世界最高。米国流のプロセス改善で品質が高まるはずがない」という指摘がある。これに対して日立ソフトの臼井氏は、「確かに、組み込み系はエンタープライズ系に比べて高い水準で品質を作り込んでいる。ただ、それも生産性を犠牲にしている面がある。プロセスを改善すれば、品質を維持しながら生産性も高められる」と話す。

　臼井氏によれば、ある機器メーカーでは、システムテスト段階で許容されるKstep当たりバグ件数は0.5件であるという。一般的な業務アプリケーションは、それが5件ほどなので品質基準は10倍である。一方、開発生産性は500step／人月に達していない。800step／人月はいくエンタープライズ系の6割程度しかなかった。「単体テスト、結合テストの段階になって力業でバグを徹底的につぶしているので、生産性が悪くなっている。プロセス改善で品質を前倒しで作り込んでゆけば、生産性がすぐ10〜20％はアップするだろう」（臼井氏）。

　組み込み分野でCMMIが必要とされてきた原因として、開発規模がエンタープライズ級に肥大化していることがよく挙げられる。逆にいうと、数人ほどの小規模開発にCMMIは合わないという見方がある。少人数ならプロセスを臨機応変に変える方が効率的という考え方である。

　だが、豆蔵の濱野氏は次のように指摘する。「当社の顧客では、開発者2〜3人のプロジェクト単位でCMMIに取り組んでいるところが多い。そうした職人的な小規模開発だと、管理者からはプロセスが見えず、状況を管理できないからだ。そうした現場にCMMIを教科書どおりに適用する必要はないが、属人性の弱い部分を補うのに使える」。

　現場の開発者は、CMMIによるプロセス標準化と聞くと、決まり事や提出文書が増えると考え、嫌がるものだ。その半面、プロジェクトの立ち上がりは確実に速くなる。必要な資料やテンプレートがリポジトリ化され、WBS（作業分割構成）も定義される。開発者の負担を減らす面もあるのだ。

　「CMMIに取り組んだ開発者の多くは、『もう前のスタイルに戻りたくない』と話している。逆に、管理者は前に戻りたがっている。いままでなら下に任せっ切りでよかったからだ。CMMIは管理者にきちんと働いてもらう仕組みともいえる」（濱野氏）。

CMMIは万能ではない

　ここまでCMMIの効能面を説明してきたが、もちろんCMMIは万能ではない。汎用的な開発プロセスを対象としているため、組み込み分野から見ると過不足がある（過不足の度合いは、組み込み機器のジャンルによっても大きく違う）。

　例えば、レベル2で求められる「構成管理」などは、プラクティス（要求）が大枠過ぎて、同時に3バージョンぐらいを平気で並行開発する組み込み系で求められる複雑な構成管理には向かないといわれる。また、組み込み系では最近、テストプロセスの高度化が叫ばれているが、この部分でもCMMIは有益なガイドを示していない。

　組み込みソフトウェア開発の特徴として、既存資産の成果物をベースとした差分開発が多いことが挙げられる。そのため既存資産の管理をプロセスに盛り込む必要があるが、CMMIはその部分も特に手当てしていない。あるOA機器メーカーは、組み込みOSの変更に伴って、すべての既存資産を書き直し、ライブラリ化しようとしているが、そこまでできる開発会社は少数だろう。「オリジナルプログラムを一元管理して、コピーのコピーはさせない」（ある自動車メーカー・ソフトウェア開発部門）など、独自に管理プロセス打ち立てる必要がある。

　前述したとおり、CMMIはプロセスごとの要求だけを示したフレームワークであり、具体的にどう実装するかは個々の開発会社が決める。実装ノウハウとなるエンジニアリングやプロジェクト管理、人材管理などの能力がなければ、CMMIは使いこなせない。

　豆蔵が手掛ける組み込みソリューションは、CMMIとオブジェクト指向開発の導入を支援するものだ。「CMMIはエンジニアリングをプロセスという側面から体系付けるのに役立つが、それだけではレベルアップしない。プロセスと同時にエンジニアリングそのものも改善していかないと効果は上がらない」（濱野氏）。要求管理で仕様変更に備えていても、肝心のソフトウェアが変更に強くなければ、意味が半減する。変更に強いエンジニアリング手法（代表としてオブジェクト指向開発）が必要というわけだ。

　そして忘れてはならないのは、プロセスを運用するのは人だということである。プロセスを定義しても、それが守られなければ意味がない。前述したピアレビューなども、レビュアーのモチベーションが低ければ、レビューにマネージャが介在しようとしまいと、レビュー効果は変わらない。

図4　CMMIだけで問題は解決しない。ソフトウェア開発のQCDレベルを高めるうえで、CMMIとエンジニアリング技術は両輪の関係となる。例えば、オブジェクト指向開発系のeXtreme Programmingを実行すると、CMMI2〜3レベルで要求しているエンジニアリング関連のプロセスエリアを満たすとも指摘される。もちろん両輪の中心は人材であることはいうまでもない

　「われわれのコンサルティングでも、プロセスを定義したら、管理者や開発者を集めて何回も教育し、プロセスを守り、育てていくことの意義を伝える。そのうえで、プロセスQAで絶えず見直しを掛け、プロセスを開発現場になじませていく地道な努力が必要になる」（臼井氏）。

　要するに、CMMIそのものが組み込みソフトウェア開発に向くか向かないかという議論は、あまり意味がない。もちろん足りない部分もあるが、それも考慮して、個々の組織が主体的（明確な目的を持って）にCMMIを使いこなせるかどうかであろう。