SW構成管理とはそもそも何なのか？

チケット駆動開発をRedmineで運用し始めて、SW構成管理(Software Configuration Management：SCM)を強く意識するようになった。
しかし、SW構成管理をきちんと定義している書籍もHPも、日本には殆ど存在しない事実を知って、愕然とした。

CMMIでも構成管理プロセスを定義しているけれども、僕の中ではフィットしない。
抽象的すぎて、現場で運用できるレベルではない。
ITILの構成管理が、僕の中では最もフィットするが、何が核心なのか分かり辛い。

ソフトウェア構成管理を定義しているHPの文章を記載しておく。
＃以下は、考えてみた書きかけのメモ。

【元ネタ】
◆ソフトウェア構成管理 - Wikipedia

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

◆サービスサポート(ITILの構成管理) - Wikipedia

サービスを提供する為の情報システムは、ライフサイクルの中で大なり小なり様々な変更が発生する。サービス開始時からその構成情報が一切変わる事無く、サービスの提供終了まで、あるいは情報システムの更改まで保たれるという事はまずありえない事である。

構成管理では実在する全ての構成アイテムを明確にしたITインフラストラクチャとサービスの論理モデルを提供する事で効率的なサービスを提供する為の情報の維持管理を行う事を目的として以下の目標を掲げている。

1.すべてのIT資産の明確化
2.構成管理で管理する情報を他のプロセスへ提供する
3.ITインフラストラクチャと構成記録の整合性検証を行う

◆【福井信二が語る：第3回】構成管理・プロジェクト管理の原理原則 - 組み込み開発 - Tech-On!

構成管理の狙いは，成果物が徐々に細分化されていく変化と，同じ成果物の状態の変化を管理することである。

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

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

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

(4)ステータス＆アカウンティング
構成管理の活動を通じて得た情報を，ソフトウエア開発の進捗の把握に使おうという考え方である。
構成管理の仕組みをうまく構築すれば，機械的にデータを集めるだけで進捗が分かるようになる。

◆Software Engineering Platform Blog > バージョン管理とソフトウェア構成管理の関係 : ITmedia オルタナティブ・ブログ

ソースコードなどのプロジェクトの成果物を管理する手段として、バージョン管理とかソフトウェア構成管理と言うものがありますが、この２つの違いというのは意外と知られていないものです。

というか、厳密な定義がないに等しく（各書（各所）によって同じ言葉を異なった意味合いで用いていることがあるため）非常に紛らわしかったりします。

広義のソフトウェア構成管理
　　＝ 変更管理（Change Management）
　　＝ 狭義のソフトウェア構成管理 ＋ 変更依頼管理（Change Request Management）

といった式のイメージになるでしょうか。

1.バージョン管理（Version Control）：
ソースコードなどのファイルを「いつ、誰が、なんのために、なにを、どのように」改訂したのかを版（リビジョンやバージョン）として記録し、構成の把握などに役立てること。

2.ソフトウェア構成管理（Software Configuration Management）：
プロジェクトの成果物の構成を正確に記録し、必要に応じて過去の構成であっても正確に再現することができるように管理すること。
基本要素としては、バージョン管理（Version Control）、作業領域管理（Workspace Control）、ビルド/リリース管理（Build/Release Control）、プロセス制御（Process Control）が求められる

【考えたこと】
上記から、SCMを自分なりにまとめてみる。
SCMの目的は、成果物の細分化や状態の変化を管理して、構成アイテム(Configration Item)の任意のバージョンを再現できるようにすること。

1.バージョン管理
1-1.構成アイテムが段階的に詳細化される過程を管理する
1-2.構成アイテムの修正履歴を管理する

2.変更管理
2-1.構成アイテムの状態を記録し、一貫性と完全性を保証する
2-2.全ての障害の状態と対処を残し、ソース修正と紐づける

3.ビルド管理
3-1.いつでも最新バージョンの製品をビルドできる
3-2.リリースした製品の任意のバージョンを再現できる

4.マネジメント
4-1.構成管理の集計情報(メトリクス)をSW開発に活用する
　→ソフトウェア・リポジトリ・マイニングによって、プロジェクト管理に役立つメトリクスを出力して、SW開発の意思決定の判断材料にできる。

SCMで重要な概念は「バージョン」。
バージョンは2つの意味を持つ。

1.ある時点のシステムをいつでも再現できるポイント(タグ、バージョン)
2.ある時点でステークホルダー(顧客、開発者など)が要件や仕様などで合意した状態

バージョンがあるから、切り戻しポイントにいつでもロールバックが可能になる。
バージョンが発生するタイミングは、構成アイテムの変更をコミットするタイミング。
あるいは、別のアクターへ成果物を納品する時にバージョンが発生する。

例：お客から開発チームへ、要件を仕様として確定する。
←これはまさに、仕様というベースライン。
　ベースラインがSLA(品質保持契約)にも関連してくる。

例：開発チームからサーバーセンターへモジュールを送付する。
←ビルド番号を付けたモジュールを渡すから、ビルド番号にChangeLogが書かれているはず。

つまり、構成管理はSW開発プロセスをトランザクションに喩えた時、トランザクションマネージャに相当するだろう。
各工程の担当者の作業を一つのトランザクションと見なして、システムの整合性や一貫性を保障する仕組みなのだ。

SW構成管理のインフラがあるからこそ、プログラマや設計者は自分のアイデアを簡単に実装できる。
SW構成管理のインフラは、水道や電気のように、当たり前で安価である方が良い。