「構成管理の重要性」

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

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

図. １：システム構成図

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

■課題1

■課題2

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

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

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

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

(1)

所定の時間におけるソフトウェア構成を特定すること（ソフトウェア構成とは選択されたソフトウェア作業成果物とそれらの記述）

(2)

ソフトウェア構成の変更を系統的に制御すること

(3)

構成の一貫性と追跡可能性を維持すること

※文献名：

ソフトウェアエンジニアリング研究所カーネギーメロン大学, SEA CMM 研究会訳“能力成熟度モデルのキープラクティス1.1 版”,1993

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

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

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

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

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

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

■課題1の対策

■課題2の対策

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

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

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

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