構成管理、リリース管理、バージョン管理・・・
呼び名はいろいろあります。
そもそも構成管理はソフトウェア業界特有のワーヅではないので、学ぶべき先人の仕事が多数あります。
しかしここでは間抜けなソフトウェア開発現場に対する些細な指摘をしておきます。
今日は予告編なので、結論だけ書きます。
大部屋開発における構成管理の最大のメリットは
マッチポンプ連中の暗躍をオフィシャルにブロックできること
大部屋開発では、「自称ベテラン」あるいは「あの人はプロジェクト開始前から居るから何でもあり」というような「特権階級」の中にマッチポンプ担当が潜んでいます。
マッチポンプの目的は、
管理可能な範囲でプロジェクトを炎上させ
最大限の人員投入要求を発行させる
ことです。
むかしからごみためをお読みでない皆さんも、
人月で回る星の世界(業界)では
プロジェクト炎上の炎が
下請け以下の会社の富の源泉
(炎上する→増員→儲かる)
という神話をご存知かと思います。
元請け、というか発注元も同類であり、直接的なキックバックがなくても、下請け＝子会社への天下りルートがあれば、同じアナの貉です。
しかしそんな泥船も、国際競争のある市場では通用しません。
本当にプロジェクトの生産性をあげる必要がでたときに、
じゃぁ、今度のプロジェクトはホンキンで
と簡単に済ませたいなら、
構成管理専任担当者を置く
CVS/SVNならコミットは申請許可方式
git/hg/bzrなら、プル要求方式
これだけです。
コミット/プルの許諾は、各機能ドメインの発注元のプロパーが行えば間違いありません。
下請けに作れ・直せといった内容のコミットしか認めない。
マッチポンプ野郎がこっそりコミットするのを阻止できる。
それだけではありませんよ。構成管理専任担当者がいるということは、当然のことながら、
リリースされるソースツリーに取り込むのは、ビルドが通るものだけ
という運用が可能なのです。
あ～Ａ社の野郎がコミットしたせいでビルドが壊れてる！
・・・ＧＤＧＤＧＤ・・・
という開発者の時間を無駄にする無駄が削減できるのです。
さらに、構成管理専任者がいれば、
ＸＹＺ機能のコミットにより、
リリース前テスト(デグレード、リグレッションテスト)が失敗しました
ＸＹＺ機能およびそれに依存するコミットはロールバックされます。
という機械的な対応が、開発者無しで可能となるのです。
あなたの現場では、
ビルドが壊れるたびに、
開発者のイミフな説明(A.K.A.言い訳)に振り回されて
時間を無駄にしていませんか？
純粋な構成管理にはそれなりのスキルが必要ですが、製品に対する知識は最低限でよいです。
鍛え上げられた構成管理者は、複数プロジェクトを担当することも可能です。
リポジトリの管理と
リリース前ビルド作業だけのための人員？
なんだその金の無駄は？
などと言っているのは、マッチポンプ野郎だけです。
注意して観察すればすぐに分かります。
ビルドや、リポジトリの管理、マージ作業などが開発者にしかできないというのは幻想、あるいは神話なのです。
我々は「紙の時代」を記憶しています。プログラムを印刷したものや、マニュアルの原紙(←これが死語だなｗ)、機械図面や電気図面を棚に並べて管理していたのは、技術者でも開発者でもなく、事務の人でした。ただ彼らのスキルは会計事務でも、伝票処理でもなく、「文書管理」と呼ばれていました。
おわかりでしょうか。構成管理とは彼らの末裔なのです。
思い出してください。紙の時代に、上司の承認印を受けた図面を、勝手に書き換えることはご法度でしたね？
リポジトリを開発者が勝手に管理していて、ソフトウェ構成管理専任担当者がいない現場は、それと同じ危険な運用が常態化しているということです。
大部屋開発では本来あってはならない運用でしょう。
SOHO、零細は好きにやればよろしい。
