新人技術者のためのロジカル・シンキング入門（4） ―― 直したバグがゾンビのごとく復活する

【2】管理ツールの採用は避けられない（2/2）

1） 入り口のミス

　まず，ソース・コードを取ってくる入り口のミスから考えてみます．図2と図6を比べてみてください．管理ツールが導入されていれば，ソース・サーバに最新版があるのでまちがいようがないように思われます．しかし，ソース修正に夢中になり，ローカル・マシンにあるソースの組み合わせを「最新版のつもり」で改造してしまう人が現れたらどうなるでしょう？ ソースを修正して提出したときに問題が発生しうることになりますね．なぜなら，改造する対象のソースが，ソース・サーバで管理されていたソースの最新版と異なるかもしれないからです．

図 6　管理ツールを導入しただけでは救えないミスの例
入り口と出口に着目すると，それぞれ「ソース・サーバから正しく取ってこない」，「サーバに上げ損ねた」場合は，管理ツールの外で起こるミスなのでルールが必要

　したがって，まずソースを取ってくる入り口の部分では，「改造前にかならずソース・サーバからソースを取ってくること」というルールを徹底しなければならないことがわかります．管理ツールにも，変更が開始されると，ソース・サーバ上にそのことが記録されます．これがないと，管理ツールの外で改造が始まることになってしまいます．

2） 出口のミス

　次に，出口の部分を考えてみましょう．正しく自分のソースをソース・サーバに上げれば改造は無事完了します．しかし，管理ツールがなかったときに起こりえた「上げ損ね」，すなわち必要なファイルを過不足なく正しく上げる作業そのものは管理ツールがやってくれるわけではありません．ソースを過不足なく提出するのは，管理ツールを使う人間の役目です．
　したがって，出口の部分でも一定のルールが必要となります．すなわち，「サーバに上がったソースが手元のファイルと一致することを確認する」というルールです．一致を確認する方法としては，管理ツールに付属の差分比較ツールを用いてもよいし，何かのテキスト・エディタの機能を使ってもよいでしょう．

3） コンフリクト

　次に，コンフリクトのミスを管理ツールでどのように防げるかを図7で考えてみることにします．図7（a）に示すように，正しく管理ツールを使いこなせばコンフリクトによる変更の上書きは起きません．しかし，図7（b）で示すような入り口のミス，すなわち正しくサーバからソースを取ってこずに改造を始めてしまうミスを犯すと，やはり変更の上書きは起こってしまいます．ソース・サーバが出どころではないソース・コードが途中から混じり込んでしまえば，やはり正しく変更が反映されなくなってしまうからです．
図 7　コンフリクトへの対応
（b）のように，サーバからソースを取得しないで改造を始めてしまい，更新するときに初めて取得して改造ソースで上書きして上げた人がいたとする．このケースは，管理ツールだけでは救えない

　まとめると，管理ツール導入後は，入り口と出口に表1のようなルールを設けなければならないことになります．これらのルールは重要です．きわめて簡単なものであるため，遵守を徹底することは容易なはずです．