ソフトウェア構成管理に至るまでの道のり

「何故、設計書をバージョン管理するのか？」という疑問から、ソフトウェア構成管理について考え直してみる。
＃あくまでもメモ書き。

【元ネタ】
■[development][trac]構成管理ツールをいかにして導入するか

■[システム開発][構成管理]構成管理ツールはどのようなタイミングで導入し、どのように活用すべきなのだろうか？

■[構成管理]Subversion + TortoiseSVN + xdocdiffでドキュメント管理

ソフトウェア構成管理

【1】バージョン管理が無かった頃

今でも多いが、WordやExcelの設計書をバージョン管理していないプロジェクトは多い。

その時の最大の問題点は、■[構成管理]Subversion + TortoiseSVN + xdocdiffでドキュメント管理　にその理由が書かれている。

ほっておくと自然増殖してくるのが、下記のような形式のドキュメント。

**設計書.xls
**設計書20080601.xls
**設計書20080713.xls
**設計書20080828.xls

かなりうっとおしい。
もっと酷いのが、次のようなケース。

**設計書.xls
**設計書（最新）.xls
**設計書（最新２）.xls

どれを見たらいいんだよ！！

設計書というバイナリファイルをバージョン管理していないと、上記のようにすぐにカオスになる。
今では、TortoiseSVNでExcelもWordも差分表示も可能なのだから、ソースだけでなく設計書もSVNでどんどん管理すべきだ。

【2】バージョン管理しても構成管理が無かった頃

ソースをCVSやVSSでバージョン管理しているが、BTSを使っていないプロジェクトは今も多い。

そんなプロジェクトのソース修正では、あるルールがある。
ソースのヘッダに、修正履歴を書くことだ。
つまり、「2008/5/1 ホゲ会社の何某　バグ修正した」という履歴をソースのヘッダ部に残す。
JavaDocにも、@historyというタグが残っている。

更に、ソース修正にも手順がある。
以前のバージョンのソースのロジックをコメントアウトして、修正日付と修正仕様のコメントを書いてからロジックを実装することだ。

このやり方の問題点は、ソースに修正が入るたびにガラクタのロジックが増えること。
たとえ不要なコメントであろうとも、本番稼働中のソースに、現在の問題のバグ修正に関係ないコメントを削除するのは怖い。

同様に、設計書に更新履歴のシートを作り、履歴を書き残すことは多い。
更に、設計書へ更新前の文章に取消線を入れて、追加した文章を赤字にして変更箇所を強調するやり方も多い。

これらの問題点は、無駄な変更履歴が混じって、本来の仕様が分かりにくくなることだ。

今なら、SVNとRedmineを連携させて、ソースや設計書を修正してSVNコミット時に、コミットログに修正理由とチケットNoを必ず書く。
そうすれば、チケットに変更履歴の詳細、変更理由が残り、設計書やソースに無駄なコメントを書く必要は無い。

RedmineのようなBTSは、チケットだけでなくSVNコミットログの検索も簡単。
更に、Redmineのチケットには、下記の区別があるから、色んな観点で変更履歴を観察することができる。

・問題トラッキング(バグ、機能、サポート)
・時間トラッキング(開発作業、デザイン作業、テスト作業)
・カテゴリ(システムの機能単位)
・期間(開始日、終了日)
・優先度
・予定、実績工数
・作業状態

つまり、チケット集計結果からソフトウェア・リポジトリ・マイニングを使って、チケットの変更内容のある種の傾向を探り出すことができる。
例えば、顧客の要求は、実はこういう系統の内容が多い、などのように。

【3】ソフトウェア構成管理(SCM)とは何なのか？

僕のイメージでは、ソフトウェア構成管理とは、成果物をバージョン管理できて、変更履歴を一貫して追跡できることだ。
これによって、成果物の作業状態を一貫して管理できる。

ソフトウェア構成管理をWikipediaでは下記のように定義している。

ソフトウェア開発プロジェクトをその成果物を通して制御・管理する方法論である。ソースコードや文書などの成果物の変更履歴を管理し、製品のバージョンやリビジョンに個々の成果物のどのバージョンが対応しているかを識別し、任意のバージョンの製品を再現可能とする。
(中略)
一般にソフトウェア構成管理はバージョン管理とは等価ではなく、バージョン管理を制御するマネジメント的要素が含まれる。

つまり、変更管理、リリース管理、プロセス管理、そしてプロセス改善までも管理できる機能まで含んでいる。
そして、ソフトウェア構成管理の利用対象は、開発者だけでなくプロジェクトリーダやマネージャ、リリース担当者、品質管理担当者になる。

分かりやすいイメージは下記にある。

図1 構成・変更管理ツールの仕組み

SCMの一般的な目的はWikipediaで次のように書かれている。

・構成の識別 - 修正を施すべきコードはどれか？
・構成の制御 - 製品のリリースとその修正を制御する
・状態の記録 - コンポーネントの状態を記録し報告する
・レビュー - コンポーネント間の一貫性と完全性を保証する
・ビルド管理 - ビルドのためのプロセスとツールを管理する
・プロセス管理 - 組織としての開発手法を厳守する
・環境管理 - システムの基盤となっているハードウェアおよびソフトウェアを管理する
・チームワーク - 開発に関するチーム内のやりとりを促進する
・バグトラッキング - 全ての障害について対処状況を追跡可能とし、かつコード修正と対応付ける

つまり、SCMは構成アイテム(CI)の管理だけでなく、マネジメント要素も含んでいるのが特徴。
まだ模索中だが、RedmineとSubversionで上記の機能や目的は全て実現できるはずと直感している。

【4】構成アイテム(CI)の対象とは？

構成管理DB(CMDB)に入れる物、つまり構成アイテム(CI)の対象とは一体何だろう？

最初は、バージョン付けする成果物と思っていた。
つまり、Ver1.0とタグ打ちする時、タグをつけるべき対象の成果物一式だ。
ソースコードだけでなく、納品ドキュメントも当然含まれる。

そして、「Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック」の本から、ソフトウェア開発に必要な物全てをバージョン管理対象に入ると知った。
つまり、ビルドスクリプト、開発環境、設定ファイルなどだ。

更に、■[システム開発][構成管理]構成管理ツールはどのようなタイミングで導入し、どのように活用すべきなのだろうか？　を読むと、テストデータまで含むべきだと主張している。
実際、初期のマスタデータにプログラムやシステムが依存していることはすごく多い。
つまり、ソフトウェア開発に支障があると思われる成果物は全て構成管理の対象に入るのだろう。

但し、このようにどんどん構成管理の対象を増やすと、不要になったゴミデータが増えないだろうか？という疑問はある。
おそらくその場合は、ライフサイクルの単位で管理するのだろうと思う。

【5】BTS(バグ追跡システム)＋SCM(バージョン管理)の導入は構成管理の基盤を与える

以上を考えると、BTS＋SCMの導入は構成管理の基盤を与えるのだと思う。

つまり、チケットはRFC(変更要求)を含む。
そのチケットに要件管理ID(変更要求)がアサインされているはず。
これによって、チケットが構成アイテムの変更のトレーサビリティ(一貫性)を保持する。

そして、それらのチケットをグループ化したものがバージョン。
バージョンとは、リリース時点の成果物のスナップショットと言える。

従って、導かれる究極のルールは「チケット無しでは構成アイテム(CI)の変更は不可」。
構成管理に置かれた成果物を変更する場合、必ずチケットに起票して、変更理由と変更履歴を必ず残す。
これによって、変更された成果物の作業の状態を一貫して追跡できる。

このおかげで、たくさんのフォルダに散在したExcelの仕様書を探す必要は無くなる。
構成管理DB(CMDB)から、要件管理IDや変更理由などから検索すればいい。

RedmineとSubversionによるチケット駆動開発をきちんと論理的に構成できれば、チケット駆動開発は構成管理の基盤を与えてくれるはずだ。