この連載記事の目次へ

成果物の変化を正しくつかむ

 難しいのは,計画を懸命に立てても,なかなかその通りには進まないことだ。これは,ソフトウエアの特殊性に起因する。PMBOKが示す「段階的な詳細化」が,ソフトウエアでは特に顕著なのである。

この記事は,「日経エレクトロニクス」と「日経バイト」が刊行した別冊『組み込みソフトウエア2006---品質管理と開発技法の実践的改革A to Z』の掲載記事を抜粋したものです。別冊の詳細はこちらをご覧下さい

 ソフトウエアを工程と部品に分解しようとしても,最初から完全に分解できるわけではない。システム設計,機能設計,構造設計と作業を進めていくうちに徐々に細かくなり,成果物が変わっていく(図3)。プログラミングと単体テストの両工程の成果物は同じソース・コードだが,その状態は変わっている。成果物の種類が変わったり,成果物の状態が変わったりすることをうまく管理する技術が欠かせない。これを実現しようとするのが構成管理である。

成果物の段階的な詳細化と状態の変化を追いかける
図3 成果物の段階的な詳細化と状態の変化を追いかける
構成管理の狙いは,成果物が徐々に細分化されていく変化と,同じ成果物の状態の変化を管理することである。

 ソフトウエア構成管理の標準として「IEEE Standard for Software Configuration Management Plans(IEEE Std 828-1998)」および「IEEE Guide to Software Configuration Management(IEEE Std 1042-1987)」がある。これらは変化という「関係」を管理するものであり,「物」を管理するハードウエアの構成管理とは異なる。

 構成管理で重要なのは,(1)構成識別,(2)ベースライン&プロモーション,(3)変更管理,(4)ステータス&アカウンティング,という4つの考え方である。それぞれについて解説していく。

 (1)の構成識別は,ソフトウエアが段階的に詳細化されていく様子を管理する技術である。最初にすべての成果物を定義しようとするのは現実的ではないという考えに基づく。その代わりに,誰が,いつ,何を定義するのかを,ソフトウエア構成管理計画書と呼ばれる表などを使って計画しておく(図4)。これにより,適切なタイミングで物事を定義できるようになる。

判断のタイミングを決めておく
図4 判断のタイミングを決めておく
ソフトウエア構成管理計画書の例を示した。プロジェクトの計画を立案する段階では,どの構成物を,誰が,どのタイミングで判断するかを示すために使う。全体を考える「モジュール一覧」と,一部を深く掘り下げる「モジュール」とを別のタイミングで決定することもポイントの1つ。

 ソフトウエアのモジュールと,モジュール一覧とを分けておくことも重要なポイントである。人は,物事を深く掘り下げると全体が見えなくなるし,逆に全体を見ると物事を深く掘り下げられなくなる。そこで,関係と物とを別のタイミングで分けて定義するようにしておく。また,品質基準の変更を管理対象とすることは必須となる。品質基準を明確に定義して文書として残し,工程の進行に伴う変更を管理していく。

 (2)のベースライン(基準線)&プロモーション(成長)は,成果物の状態の変化を管理する技術である。これは,ソフトウエアは成長するという原則に立つものだ。基準線を設け,その基準線を越えたかどうかを判定することによって成長を管理する。

 例えば1つのソフトウエア・モジュールの場合,プログラマがプログラミングの終了を宣言した段階で,プログラミングの基準線を越えたと考える。ここで成果物にバージョンを与える。同様に単体テストの完了,結合テストの完了といった時点で,基準線ごとにバージョンを与え,現在どのような状態にあるのかを管理する。この成果物が結合されることで別の構成物になったら,それをまた基準線ごとに新しいバージョンを与えながら管理していく。

 この基準線は,品質の基準でもある。越えたかどうかの判断は,1人ではなく,複数が参加するレビューで判断すべきだ。これが徹底され,ソース・コードのヘッダにバージョンを明記しておけば,他の技術者がソース・コードを見た場合に,正確な状態をすぐに把握できるようになる。さらに,基準線を定義する以上は,基準線自体も構成管理の対象として,変更をきちんと管理していかなければならない。

 (3)の変更管理は,構成管理の発端となったものである。一度リリースしたものに対する変更は,その変更の主体者だけのものではなく,利害関係者すべてに影響する。そのため,きちんとした組織を作って徹底的に管理しようというのが変更管理の考え方だ。構成管理委員会(configuration control board)を組織して管理しようという動きが米国から発生した。

 構成管理委員会というと大きな話のように聞こえるが,変更の影響範囲の大きさに応じて複数階層に置くことを基本としている(図5)。この委員会が,変更の可否や,変更の内容を議論することになる。どのような変更を,どの委員会で議論するかを決めておくことが望ましい。ただし,こうした委員会を置いたからといって,すぐに変更に関する判断を適切にできるようになるわけではない。まずは,こうした委員会の設置を通じ,リリース後の変更は影響が大きいという意識を技術者全員に持たせることを目的とすべきだ。

安易な変更は思わぬ影響を生む
図5 安易な変更は思わぬ影響を生む
成果物をリリースした後に加える変更の可否を判断する「構成管理委員会」と呼ぶ組織の例を示した。変更を加えると,思わぬ部分に影響を与えることがある。どの階層の委員会に諮るべきかは,変更内容に応じて判断する。

 (4)のステータス&アカウンティングは,構成管理の活動を通じて得た情報を,ソフトウエア開発の進捗の把握に使おうという考え方である。構成管理の仕組みをうまく構築すれば,機械的にデータを集めるだけで進捗が分かるようになる。例えば,全モジュールの中で,プログラミングが完了したもの,単体テストが完了したもの,結合テストが完了したものがそれぞれ幾つあるかがすぐに把握できるのである。

(第4回につづく)

(福井 信二=オムロン インダストリアルオートメーションビジネスカンパニー コントロール機器統轄事業部 技術部 技術開発グループ 技術専門職)