根性論では改善しない組み込みソフトの品質：基礎解説 ソフトウェア構成管理（2/2 ページ）

[崎田 喜一 キャッツ，＠IT MONOist]

前回と今回のリリースとの差分を把握しよう

　複数の不具合対応を行った後のテストや、リリース向けテストを実施しているときに、デグレと呼ばれる「以前は発生しなかった不具合」が発生した場合、対策を施した多くの不具合から、どの対策（修正）によってデグレが発生したかを調査するため、対策した不具合を1つ1つ外していくことがあります。この場合、不具合対策それぞれにおいて、どのファイルのどのバージョンで対策されたかが分からないと、対策した不具合を外すことができません。

　また、複数の不具合対策を行った後、1つの不具合だけを直す場合、1つのファイルの異なるバージョンで対応している場合、どのファイルのどのバージョンを取得すればいいかが分かりません。さらに、製品をリリースする場合には、前回リリースした後に判明した不具合リストと今回のリリースで回収された不具合リスト（リリースノート）を把握する必要があります。

図3　作業状況／作業内容の管理

　こういった問題を解決するのにも、ソフトウェア構成管理ツールが活躍します。ソフトウェア構成管理ツールでは、不具合帳票とそれに関して修正したファイルリストを関連付けできるので、不具合帳票それぞれにおいて、ファイルを外していけます。また、前回リリースした際と今回のリリースにおける不具合リストを生成することによって、「リリースノート」を自動生成することもできます。小規模開発では効果が分かりにくいかもしれませんが、大規模開発になればなるほど、ソフトウェア構成管理ツールの効果が身に染みて分かってきます。

図4　ソフトウェア構成管理ツールによる作業管理書

より高度なソフトウェア構成管理

　これまで説明してきたファイルのバージョン管理やビルド／リリース管理といった基本的な管理機能のほかにも、より高度なソフトウェア構成管理を求められることもあります。その中でも主要な管理項目について簡単に紹介します。

要件／変更管理

　ソフトウェア開発における、要件そのものや、不具合修正に関する変更管理を行います。例えば要件管理では、要件の作業状態や担当者、納期などを管理していきます。これによって、要件の作業が終了しているのか、していないのかが分かるようになります。また、納期を設定することによって、納期が近い要件リストを抽出し、手の空いているエンジニアに対応させるといったこともできます。

図5　ソフトウェア構成管理ツールによるプロジェクト管理

開発プロセス管理

　「要求定義」「設計」「コーディング」「テスト」「リリース」というように開発プロセスを定義しても、開発者が開発プロセスをきちんと守っているとは限りません。納期を守るために「テスト」工程を飛ばして「リリース」してしまい、リリース後に客先からクレームが来るという話は開発現場ではよく聞かれます。これを防ぐために管理者が利用するのが、開発プロセス管理です。

　ここでは、案件（要件）や不具合帳票ごとに、開発プロセスに従った開発工程を維持させるため、管理者などの「承認」がないと、次の開発工程に移ることができないようにします。

図6　開発プロセスに従った開発工程の管理イメージ

定量的データ測定／解析

　開発プロジェクトにおいて、作業工数や不具合の発生率や収束状況（バグ曲線）を把握することで、プロジェクトの進ちょく状況やプロジェクトの質を推測することができます。この推測を行うために、進ちょく報告書の作成や不具合帳票の発行を行い管理している企業も多いと思います。

　しかし進ちょく報告書は、開発者の数が増えるとリーダーやマネージャなどの中間管理職が増え、レポートの回収と提出に時間がかかってしまいます。その結果、進ちょくの情報が数日前だったり、ひどいときには1週間前の情報だったりして、緊急事態への対応に遅延が発生してしまうことがあります。ソフトウェア構成管理ツールを利用することで、定量的データ（作業進ちょく情報、バグ曲線、作業工数状況）を把握することができます。

図7　作業進ちょく情報、バグ曲線、作業工数状況などの定量化

まとめ

　本稿で説明したように、ソフトウェア構成管理では、ファイル管理だけではなく、開発プロセスの管理や開発プロセスの効率化までを管理できます。これらの機能をうまく応用することで、CMM／CMMI、ISO、IECなどの国際的な規格に対応した開発体制を構築することも可能になるでしょう。