技術とか戦略とか

証券レガシーシステムを8年いじってから転職した普通の文系SEによるブログ。技術のみではなく趣味の戦略考察についても。

ソース管理ルールが信頼されないことによるデグレード例と対策

新人にソース管理ルールを教えている時にふと書きたくなったので。
 
ソース管理は、Git等のバージョン管理ツールを使用し、運用ルールを整備することで行います。
ソース管理の概要は下記のページがわかりやすいと思います。
 
【社内勉強会】バージョン管理の重要性とGitの運用について

https://techracho.bpsinc.jp/hachi8833/2017_03_14/36735

 
しかし、運用ルールを頑張って整備して運用しようとしても、その運用ルールが開発者に信頼されない場合、開発者はその運用ルールを無視し始めます。
そして、運用ルール無視の結果、不具合の修正や機能追加を行った後の最新のソースではなく以前のソースを修正元としてしまい、デグレード(修正したソフトウェアの品質が修正前よりも悪くなること)が発生してしまいます。
 
私が知る限りでは以下のような事例があります。
共に管理者から貸し出されたソースを修正元とするルールであるのにも関わらず、開発者自身でソースを取得していたという事例です。
・開発者が最新ソース置き場から勝手にソースを取得していた
 管理者から貸し出されたソースが古かったことがあったため
・開発者が直近の案件から勝手にソースを取得していた
 Windows環境のソースをLinux環境で管理しているのが不安であったため
 
このようなルール違反によるデグレードを防ぐためには、管理者の方で以下のような対策を行うのが有効になります。
・管理ルールを明文化し、開発者へ説明会を行う
・開発者に修正元ソースと修正後ソースと修正前後コンペアを提出してもらい、正しい修正元ソースを元に修正されていることを確認する