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

組み込み分野でもCMM/CMMIに取り組む会社が増えている一方で、「組み込みに合わない」という声も聞かれる。その実態は？

[石田 己津人，＠IT MONOist]

勘所見極めが重要

　CMMIのごく大まかな概要を解説した。ここで注意したいのは、欧米のマネジメント関連のガイドラインに共通することだが、書かれているのは「何をすべきか（what）」であって、「どうやるべきか（how）」は書かれていないことだ。

　例えば、レベル2のプロセスエリアの1つであるプロジェクト計画策定には「見積もりの確立」「プロジェクト計画の策定」という2つの固有ゴールがある。前者に対しては、「プロジェクト範囲の見積もり」「成果物とタスク属性の見積もり」など4つのプラクティスが決まっているだけなのである。

　つまり、プラクティスの具体的な実行方法の選択は、実行者に委ねられている。プラクティスは、ソフトウェア開発の「要求」と似ている。要求は1つでも実装方法はいろいろある。また、CMMIに取り組む目的や達成スケジュールに応じて、実装の“深さ”にもメリハリを付けられる。例えば、工数と費用を精緻に見積もろうとすると、それなりの工学的な手法が必要になる。それまでカンで見積もっていた現場へそうした手法を押し付けても負担になるだけだ。レベル2〜3の段階なら、既存のやり方で間に合わせ、徐々に手法を変えていっても問題ないのだ。何しろ、CMMIは“何をどのようにしろ”とは規定していない。

　それどころか、いったん定義したプロセスであっても、「プロセスQA（品質監査）」により、現場に合わなかったり過剰な負担が掛かったりするのなら見直すように求めている。CMMIは意外に柔軟なガイドラインなのである。「CMMIの導入で失敗しやすいのが、担当者が本を読んで自分でプロセスを決め、頭ごなしに現場にやらせようとしているケース。CMMI教則本を額面どおり受け取り、メリハリを付けずにすべて適用したら、それは大変なことになる」（日立ソフトの臼井氏）。逆に、CMMIに取り組む目的を明確にし、目的に沿って最も効果が表れるポイント、勘所を押さえる必要があるのだ。

CMMIで実のあるプロセスへ

　勘所となるプロセス領域は、取り組む組織によって違ってくる。ここでは汎用的な例を紹介しよう。

　開発の上流段階から品質を作り込むこと、いわゆるフロントローディングは、どの組織にとっても重要だろう。コンピュータ周辺機器を開発するある機器メーカーは、レベル2からレベル3へプロセスを成熟させる中で、テスト段階で検出されるバグ件数を20％減らし、QCDを軒並み改善した。成果物レビューのやり方を抜本的に見直したからだ。

　CMMIレベル3には、11あるプロセスエリアの1つに「検証」がある。検証では、その固有ゴールとして仕様書や設計書、ソースコードなど成果物に対する「ピアレビュー」を求めている。この場合のピア（peer）とは、開発者と対等な立場の同僚を指す。つまり、マネージャがいない中で同僚同士が自由闊達にレビューを行い、レビュー効果を高めるのである。マネージャ監視下でのレビューは人事評価にもつながるので、開発者は自らミスを積極的に見つけ出そうとはせず、レビュアーも同僚のミスを指摘しにくい。機器メーカーは、このCMMIの考えに沿ってピアレビューを取り入れたのだ。「これまでのレビューは、上長の承認を得ることを目的とした形式的なレビューになっていた。とにかく急いで後の工程に移り、テストでカバーすればよいと思いがちだった。そのためテストでバグがたくさん見つかり、最後が大変になっていた」という。

　徹底したレビューが手戻りを防ぎ、QCDを向上させることは、開発経験者なら誰でも知っていることだ。バグ修正に掛かる工数は、設計書とテストの段階では2〜3倍違うと指摘されている。特に組み込みソフトウェア開発は、あいまいな要求を機能設計していく際にバグが混入しがちで、バグの半分以上は設計段階のものともいわれる。上流からのレビューがより重要であり、ピアレビューは1つの方法論となるだろう。

　CMMIのようなガイドラインは、開発の現場からすると“形式的なもの”ととらえられがちだが、実は意外に多い形式的な既存プロセスを“実用的なもの”に変える効能も秘めている。

　レベル2のプロセスエリアとなっている「要求管理」も組み込みソフトウェア開発に効くだろう。いったん確定したハードウェアの要求仕様は簡単に変更できず、仕様変更のしわ寄せはソフトウェアに来る。消費者向け機器は、市場の競合関係で要求仕様が大幅に変わることも多い。体系化された要求管理は不可欠である。ところが、「組み込み系の開発現場でしっかりと要求管理を実施しているのは少数」（機器メーカーのソフトウェア開発部門責任者）なのが現状である。

　CMMIの要求管理では、要求仕様と計画、開発、成果物の間でのトレーサビリティを重視している。ほとんど管理されていない初期段階からレベル2に達したある機器メーカーは、独自の方法で個々に要求仕様にIDを振ってExcelで管理。1つの仕様変更がどの要求仕様や成果物に影響するか、モレなく判別できるようにした。その結果、デグレードが起こりにくくなったという。

図3　CMMI適用効果のイメージ

　取り上げた成果物レビューにしても要求管理にしても、特別なプロセスではない。どの開発現場でも行われている。ただ、多くの場合、形骸化していたり、管理レベルが甘くて実効性が低いのが実情だろう（組み込み系の開発現場のほとんどが、レベル2未満と指摘する声は多い）。公式評定を受けるか受けないかは別にして、レベル2〜3程度のプロセス成熟度は、どの開発会社にとっても必要なものといえそうだ。