この記事は自分の経験をもとに記述しています。普遍的なものではなく、各現場独自ルールがあると思いますので、その辺りはご了承ください。

#構成管理とは
wikiを見ると[構成管理]
(https://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E6%A7%8B%E6%88%90%E7%AE%A1%E7%90%86)とはこんな表現になっています。

ソフトウェア構成管理（ソフトウェアこうせいかんり、英: software configuration management、SCM）とはソフトウェア開発プロジェクトをその成果物を通して制御・管理する方法論である。
ソースコードや文書などの成果物の変更履歴を管理し、
製品のバージョンやリビジョンに個々の成果物のどのバージョンが対応しているかを識別し、
任意のバージョンの製品を再現可能とする。

大層なことを書いていますが、実際にはバージョン管理ツール、開発機へのリリース調整、環境管理などを作業していきます。

#バージョン管理
バージョン管理と言っても、手作業でできるわけもなく何かツールを使います。

######バージョン管理ツール
富士通系では懐かしのPowerGEM、SC-managerを使ってきました。
Subversion、Gitには手を出さずに構成管理作業からは手を引いたので、
その辺りは今どきの開発者に任せます。

######ブランチ
大規模ウォーターフォール開発の場合だと、ブランチを切るなんてことはあまり発生することはありません。
ブランチを切る場合は次期プロジェクトが始まるという場合が多いです。
つまり数年単位ですね。

######過去バージョンの参照
開発チームから過去ソースを参照したいというのはたまにあります。でもたまにです。

######チェックイン・チェックアウト
バージョン管理ツールで、チェックイン・チェックアウト機能を使っていることもありました。
今はどこでも使っていないと思います。（昭和の遺産ですね。）
昔は実施していたりしましたが、結局機能別に開発チームが分けられてあって、
チーム内で担当が決まっているので、同時貸出なんて置きません。
なのである時期から止めました。

#開発機へのリリース調整
ソフトウェア資産を管理していることもあり、リリース作業も担うことが多いです。本番稼働後は本番リリースも担当しますが、本番リリースが頻繁にあるわけでもないので、作業の大半は開発機へのリリース調整となります。

######リリース調整作業（準備段階）
リリース調整作業、まずは日常のサイクルを決めます。
リリース曜日：週２なのか週３なのか
ソースの締め切り時間：何時に締め切って、何時からテストが再開できるか
その辺りを開発リーダーと調整して、決めていきます。
後は構成管理チームの作業時間と開発チームの言い分でリリース時間を決めていきます。
構成管理チームの作業時間にはコンパイル・リリース準備作業・サーバの再起動時間を含めて検討していきます。

######リリース調整作業（テスト期間中）
テスト期間中のリリース調整は名の通り地道な調整です。
"修正が遅れているから"、"チーム内テストでバグがあったから"、"重大バクがあったが、これから直します"
みたいな連絡が構成管理チームにやってきて、ソースの締め切り時間とリリース時間を調整します。
ここで詰められるのが、構成管理作業なので、構成管理チームメンバーはだんだんと不満が募りだします。
開発チームは夜遅くまで修正して単体テストで終了ですが、構成管理チームはそこからが仕事です。
夜遅くなっても、待ってないといけません。

#####リリース戻し
トラブルが発生してリリースを戻すこともありますが、実は稀です。
大体はさらに修正を加えてリリースをすることが多いです。リリースツールでは大抵バックアップ後に
上書きコピーとなることがありますが、ほぼ使いません。

#環境管理
構成管理とは少し離れますが、大体これもやらされます。
大規模開発だと開発環境も複数あります。そこに対して〇〇環境はver〇〇などと管理していかなければなりません。
ただ単純にリリースタイミングがずれるから記録していけばいいわけではないです。
テストしたいから、〇〇の時点の状態にしてくれとか、結構面倒な作業が振ってきます。
また、稼働が近くなると移行リハーサルや稼働後確認などで、くるくるとリリースバージョンを切り替えて
行かなければなりません。
テストとしてのリリースが落ち着いてくると、こちらが忙しくなってきます。

#大変なところ
######準備期間
構成管理は開発工程で言うところのPG,PTのあたりで準備を行います。そのときにはソース数やビルド方法などを開発チームに聞いて回ります。
その時開発チームは作り・コンパイルを通すのに精一杯で、こちらの話なんて聞いてくれません。
開発からみたら間接部門の構成管理に時間を割けるわけありません。それでも聞いて回らなければ自分の仕事が進みません。

######開発中期間
一応PG,PTが終わりITに入っていく頃に構成管理としてソフトウェア資産を集めます。
この資産を集めた初っ端はビルドが通らない、リリースしても動かないが多くここも大変です。
ですが、これ以降もテスト機へのリリースを続けるのですが、その際に障害修正が終わらないということで待たされます。
開発機へのリリース予定は変わらないので、圧縮されるのは構成管理側の作業です。
それでも遅れれば、文句がでるし、だれからも感謝されません。

######テスト後半
テスト後半にもなってくると、プロジェクトの通例から人が減ってきます。
人が減ってきてもリリースタイミングは変えられないので、ツール化をします。
（この時点でツール化を考えても遅いので、もっと当初から検討していきます。）
もし稀に人が入ってきても、低スキル者なのでなかなか教えるにも大変です。
ツールがピーキーで使いにくい場合はここで大変になります。

######運用に向けて
移行→稼働が済んだら保守運用フェーズです。
そうなった場合は当初からいたメンバーはほぼ確実にいなくなります。
それでは運用費用が賄えないからです。
構成管理メンバーに配属された場合には、保守運用に残れないと知って作業すべきです。
なので、当初から引継ぎを意識しましょう。

#なんであんなに時間かかるの？
確かに実際に結構な作業時間かかります。
ツール化を進めますが、どの現場でも特有のやり方がありボタン一つというわけにはいきません。
また、テスト工程が進むにつれて環境が変わったり、他ベンダーとやり取りがスタートしたり
常に同じ状況ではないので、ツール化があったとしても結構時間を取ります。
ただし、正直なところワザとチェック項目を増やしていることろは有ります。
あまりにも手軽だと、開発側も真剣にならないところがあると思います。
意図して遅くすることはありませんが、あえて作業を増やすことはあります。
もちろんその場合はミスを防ぐためです。構成管理は正しくリリースしたところでだれからも褒められませんから。

#最後に
開発チームにとっては、「とっととリリースしてよ」しか思われない構成管理チームですが、
作業ミスをしないように、色々な手段・手順を踏んでいます。
あまり鑑みられないですが、なかなか大変です。
そんな構成管理チームですが、どうにかテストをストップさせないために日々働いています。
そんな人たちも居るということを、心の隅に気にしておいてください。

以上、ありがとうございました。