HOME会社概況業務内容開発分野開発事例CANモジュールソフテックだよりお問い合わせ
HOME > ソフテックだより > 第33号(2007年1月10日発行) 技術レポート「構成管理の重要性」

「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。

ソフテックだより(発行日順)のページへ
ソフテックだより(技術分野別)のページへ
ソフテックだより(シーン別)のページへ


ソフテックだより 第33号(2007年1月10日発行)

技術レポート

「構成管理の重要性」

1.はじめに

今回はソフトウェア構成管理(SCM;Software Configuration Management)の重要性と題してお送りします。
私がソフトウェア構成管理の調査と検討をしたのは2005年6月頃のことです。
きっかけは、私が携わるシステムに潜む課題を解決するための検討でした。
短い期間でしたがそのときの調査・検討から得たこと、感じたこと、をお伝えしたいと思います。

2.システムに潜む課題

まず、私が関わるシステムを簡単に紹介します。
私が関わるシステムは、ある設備の監視と制御を行うシステムです。
構成するソフトは10種類以上にあり、構成するCPUは最大で1000個を超える大規模な点が特徴です。また運用する期間が10年以上と長いことも特徴です。

図. 1:システム構成図
図. 1:システム構成図

ソフトは、基本ソフトとデータベースで構成されており、物件固有の仕様に対応できるようになっていますが、ほとんどすべての物件でソフト変更をおこなっていたため、物件毎に別々のソフトになっています。
物件が徐々に増えてきていたため、以下の課題が浮かび上がってきました。

■課題1

社内の出荷管理と現場で動いているソフトが一致していると言えるための管理はどのようにしたらできるか。

■課題2

障害が起こったときに、その障害が波及する物件を特定するためにどのように管理したらよいか。

これらを放置しておくとどうなるか?
システムを構成する要素(ソフトウェア、データベース、資料など)が多く、ソフト変更をした物件が長期間に渡り多数出荷されるため、物件が増えると構成要素の組合せが膨大になっていきます。よって放置しておくと確実な組合せの特定ができなくなってしまいます。
構成を特定できないことにより、例えばハードが故障したときに正しいソフトをインストールできなくなることや、ソフト変更があるときにベースにするソースやデータベースを誤ってしまう可能性があります。

これらの課題を解決するため、ソフトウェア構成管理を調べました。
まず「ソフトウェア構成管理とは」を調べました。

3.ソフトウェア構成管理とは

もともと「構成管理」とは航空機の部品を管理するためにはじまったものだそうです。航空機は大量の部品で構成されて長期間の間に部品が少しずつ変わっていく特徴があるそうです。
さて、「ソフトウェア構成管理とは」ですが、定義をWebで検索しましたなかで、あるサイトのCMM(Capability Maturity Model。能力成熟度モデル)から抜粋した定義(※)が簡潔にまとまっていますので以下に記載します。

「プロジェクトのソフトウェアライフサイクルの全般にわたって、ソフトウェアプロジェクトの成果物の一貫性を確立し維持することである」
また、上記の目的を達成するために、次のような活動が必然的に実践されることとしている。

(1)
所定の時間におけるソフトウェア構成を特定すること(ソフトウェア構成とは選択されたソフトウェア作業成果物とそれらの記述)
(2)
ソフトウェア構成の変更を系統的に制御すること
(3)
構成の一貫性と追跡可能性を維持すること
※文献名:
ソフトウェアエンジニアリング研究所カーネギーメロン大学, SEA CMM 研究会訳“能力成熟度モデルのキープラクティス1.1 版”,1993

具体的では無いため分りづらいかもしれませんが、私はソースやドキュメントなどのファイルを管理して後からでも過去のファイルを取得できることという意味だろうなと思いながら、評価用の構成管理ツールをダウンロードして実際に試してみました。

4.構成管理ツールの評価版を使ってみました

ソフトウェア構成管理のための市販ソフトが数社から出ています。
Webと書籍で調べた結果、評価版があり導入しやすそうな某社製のツールをダウンロード(サイズは百メガバイト以上!)して使ってみることにしました。
そのとき感じたツールの特徴を以下に記します。

  1. VSS(Microsoft Visual Source Safe)などのソース管理ツールのようにファイルを管理する機能がある。
  2. Lotus Notes(※1)のようにディスカッションを行う機能がある。
  3. 変更を管理(不適合管理、仕様変更)する機能がある。
  4. 工程・進捗を管理する機能がある。
  5. 承認依頼・承認などをおこなうワークフロー機能がある。
  6. 以上の構成するものすべてにバージョンを付け、バージョン単位で出荷構成を管理する。

試した結果は、自分が思ったことを実現するためだけではなく予想以上に広範囲のモノを管理できるものでした。

※1 : Lotus Notesとは当社内で使っているグループウェアソフトの名称です。

5.課題への対策

構成管理ツールは非常に強力で正確な管理が出来ます。その一方で一度管理をすると後で管理方法を変更することや他の管理ツールへ移行するのがとても難しいと思います。
上記に加え、既にNotesへ蓄積してきている情報があること、構成管理ツールのディスカッション機能よりもNotesのディスカッション機能の方が高い表現力を持つこと、などがあり構成管理ツールは使わず以下で対策しました。

■課題1の対策

Notesで出荷バージョン管理DBを作り対応しました。
そのNotes DBは、誰が・いつ・なぜ・何を出荷したかを明確にする承認フローをつけています。また現場へ出荷する過程で関係する会社(ハードウェア製作会社と顧客)も作業状況を記録するようにしています。
上記に加え、現場でソフト変更やデータベース設定変更をした場合に社内管理と不一致となるための対策として、現場で変更した場合には必ずNotes DBへ反映することを運用ルールとしました。
以上で出荷しているソフトが現場と同一なことを保証することにしました。

なお、仕様変更や不適合などによる変更のやり取り(ディスカッション)はこれまで使ってきたNotes DBがあるためそのまま使っていますが、出荷バージョン管理DBにそれらのNotes DBの文書へのリンクを貼ることで、リンクを追うと変更経緯や関係する出荷構成を把握できるようにしています。

図2. 出荷バージョン管理のNotes DB
図2. 出荷バージョン管理のNotes DB

■課題2の対策

上記の管理に加え、ソース管理ツール(VSS)の運用を決めることで対応しました。
詳細は省略しますが、基本ソフトと物件対応したソフトとのソースにリンク関係を設定することにしました。これにより物件間で共通に使っているソースを追うことができるようにしました。
障害が発生したときには原因となるソースを使っている物件が影響範囲となります。
また、出荷時点の各物件のソースにラベルという記号をつけるようにしました。ラベルはNotesの出荷バージョン管理DBのバージョン番号を同じにします。
これにより、Notes DBで管理している情報とソースとをラベル単位でリンクさせることができるようになるため、ラベルやバージョン番号をキーにしてNotes DBで関係する文書を探すことや変更のやり取りを把握することが出来ます。

6.調査・検討を行って感じたこと

ソフトウェア構成管理とは、私が最初に感じた「ソースやドキュメントなどのファイルを管理して後からでも過去のファイルを取得できること」は構成する1つ要素の管理にしか過ぎませんでした。

通常、製作・出荷したものは何らかの方法で管理していると思います。しかしどのようなシステムでも同じように管理をするのではなく、システムの規模や運用期間などの特徴や目的に応じて管理の目的も方法も異なると思います。
そのため、システムごとに「ソフトウェア構成管理をしないで放置するとどういう問題が起こるのか」を考えてみて、その問題が起こらないようにするにはどのような管理が必要か?の検討をすることが重要だと思います。
私の場合は開発を完了して物件が出た後に検討を行いましたが、ソフトウェア構成管理の検討はシステム開発の設計時点など早い段階で検討することが必要だと思います。設計時点でソフトウェア構成管理を検討することで、ソフト開発だけではなく運用フェーズにおいての変更対応・障害対応など様々なケースにおける対応を事前に検討出来るためソフトウェアライフサイクル全般の検討にも繋がると思います。

7.最後に

最後に各課題が今どのようになっているかと新たな課題を書きたいと思います。
まず、課題1ですが対策どおりに運用が行われており現在までに現場と社内管理に不一致は起こっていません。今後もこの状況を維持することで問題は発生しないものと考えています。
次に、課題2ですが、VSSのラベル付けに抜けがあるという問題が出ています。今はラベル付けが抜けていても課題1で対策したNotes DBでソースも管理しているため出荷時点のソースを特定でき問題にはなりませんが、将来的にはこのような二重管理はしないで済むようにしたいため対策を検討しています。
また、新たな課題も見えています。それは「増加するNotes DBの管理」です。
仕様変更があるたびにNotes DBを作成してきているため既に数十のNotes DBが存在しています。またこれからも増えていきます。放置しておくと次第に存在を忘れられてしまい有効に活用されなくなる恐れがあります。今後はこれらの新たな課題に対して対策をして行きたいと考えています。

最後まで読んでいただきありがとうございました。
ソフトウェア構成管理の概略およびその重要性が伝わり、何らかのご参考になれば幸いです。

(N.K.)


関連ページへのリンク

関連するソフテックだより