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

【1】ミスを確実に防ぐしくみを作る（2/2）

2）「改造する」工程の管理ミス

　次にミスが起こりえる場所は，改造の過程そのものです．しかしここで起こるミスは，管理ミスというより，改造作業そのもののミスです．ソース管理の問題とは別次元の問題として，とりあえず切り離してよいでしょう．

3）「提出する」工程の管理ミス

　ミスは最後の提出の段階でも起こりえます．例えば，デバッグ環境というものは，ディレクトリ構成が個人によってけっこう異なるものです．だからもし，一定の管理方針がないと，追加・修正したソース・コードを一部上げ損ねることにもなりかねません．

　以上で，ソース・コードを取ってきてから提出するまでの一連の流れを追ってみました．すると，ソース管理でミスが生じうる場所は，どうやら「入り口」と「出口」に集中するようです（図3）．すなわち，正しく取ってきて，正しく提出することができれば，ソース管理にミスは生じえないことがわかります．

図 3　ソース修正の流れ
ソース修正を流れでとらえて整理してみると，要するに「入り口」と「出口」に着目すればよさそう，ということがわかる．正しく取ってきて正しく更新すればミスは起こりえない．管理ツールも，結局はこれらを補助する道具にすぎないことに注意

● チーム作業の場合の管理ミスの原因を探る

　次に，ひとりで修正が完結する場合ではなく，複数の人が介在する場合を考えてみることにします．この場合，複数の人間が同じソース・ファイルを参照・更新するため，各人はそれぞれ正しく「取得」して「提出」しても起こりえる問題があります．それは，一部のソース管理ツール（例えば版数管理や構成管理などを行うツール）で「コンフリクト（競合）」と呼ばれる事象です．

　例を図4に示しました．時間を追ったソース・コードの履歴を矢印で記してあります．まず，Qさんが取ってきて改造に入ります．その間にPさんが取ってきて別の改造を済ませてしまいます．そこにQさんが自分の改造を反映するのです．こうなると，Pさんが施した改造がQさんによって上書きされてしまう恐れがあります．これは，PさんとQさんが同じソース・ファイルを共通して改造対象としていた場合に起こりえます．

図 4　ミスの発生例（チーム作業の場合）
複数の人が改造にかかわった場合のミスの発生要因を考えてみる．複数人が同じソース・ファイルを参照・更新している，という点がポイントとなって，チーム開発特有のミスが生じうる．これは「コンフリクト」と呼ばれる

　これを防ぐには，Pさんが扱うソース・ファイルとQさんが扱うファイルを完全に別にするという手がありそうです（極端な話，1関数1ファイルに限定するソース・コード規約を作ってしまうなど）．

　しかしそうしたところで，ファイルにはどうしても共有しなければチーム開発できない部分もあります．例えば，共通ヘッダ・ファイルのようなものがそれにあたります．したがって，ファイルを複数人で共有していても混乱が生じないしくみを作らない限り，解決策にはなりません．

　以上で，ひとりで改造する場合と複数人で改造する場合について，順を追ってソース管理ミスが発生しうる場面を検証してきました．ひとりで改造する場合はソース・コードを取ってくる「入り口」と提出する「出口」に問題が生じがちであること，複数人で改造する場合は「コンフリクト」という事象が生じることを述べてきました．

　したがってソース管理とは，今まであげたようなミスをすべて防ぐためのしくみ作りであることが理解していただけると思います．