新人技術者のためのロジカル・シンキング入門（4） ―― 直したバグがゾンビのごとく復活する
ここではソース・コード管理のポイントについて述べる．複数のエンジニアが共同でソース（ソフトウェア・プログラムやHDLコードなど）を開発していると，誤って正しいファイルが上書きされてしまったり，適切に修正が反映されていないファイルがリリースされる場合がある．そのため，チームによる開発ではソース管理ツールの導入が不可欠である．ただし，ソース管理ツールを導入しても改善されない問題もある．本稿ではツールで対応する問題と運用ルールで対応する問題について考える． （編集部）
技術解説・連載「新人技術者のためのロジカル・シンキング入門」 記事一覧
第1回 いかにしてバグの原因を突き止めるか
第2回 プログラミングにおける良いデータ構造
第3回 「必要とされる設計書」の作り方
第4回 直したバグがゾンビのごとく復活する
第5回 ソース・コード規約の作り方
第6回 ハードウェア基礎の基礎
第7回 「ひたすら流すだけのテスト」にさよなら
第8回 CPUの演算量をひたすら削る
第9回 メモリ転送速度の最適化設計
第10回 「工学の知」を実務に生かす
●お知らせ
本連載記事を元に加筆・再編集した書籍『組み込みエンジニアのためのロジカル・シンキング入門』が好評発売中！
Fさんのプロジェクトはいまたいへん忙しい時期，いわゆる「火事場」となっています．結合テスト工程でバグが次々に発覚し，そのたびに修正に追われているからです．昨晩もあるやっかいなバグの修正にようやくけりを付け，新たにソース・コードをリリースしたばかりでした．
今日はもう一つ残った別のバグをやっつけるために，ほかのメンバとともに休日出勤したFさんでしたが，バグの切り分けに集中しようとしていたFさんのところにリリース先に出張している部下のYさんから妙な連絡が入りました．昨日リリースしたソース・コードを組み込むと，修正されたはずのバグが消えないばかりか，1週間前に修正したバグと似たような現象が再現したというのです．
「あっ，いかん．あまりテストせずにソース・コードを出したから，デグレったのか？注 でも，早く修正版を出してくれないと自分の立場がない，とかいっていたのはYじゃないか...」．
注；修正版で既存機能が損なわれる事象を「デグレード（degrade）」と呼ぶ．
早急につぶさなければならないバグが目の前にあって気が気ではないFさんは，念のため，修正前にはNGだったテスト項目を実行してみました．すると，何の問題もなくパスします．不審に思ったFさんは，とりあえず現状のエラーをメールにまとめて送ってくれないかとYさんに連絡しました．
30分後，Yさんから送られてきたエラーのリストを見ていたFさんの脳裏にあるでき事がよぎりました．「ちょっと待て．この間，新人のX君のソース・コード・レビューをやったばかりだな．X君のミスで何件かバグがカウントされてしまったから，注意しなかったっけ？ あの後もX君が原因を作ったバグが何件か修正されているはずだ．まさか...」．
いやな予感がしたFさんは，リリース先のYさんに頼んでソース・コードのタイム・スタンプをファイルに記録して送ってほしいと頼みました．すぐに送られてきたリストのタイム・スタンプは，一部のファイルが明らかにFさんの事務所のタイム・スタンプと一致しません．その後，リリース先と事務所のソース・ファイルを差分比較ツールで比較して判明したことは，次のような事実でした．「X君が修正した7月5日，7月10日，7月15日の修正のうち，リリース先のソース・コードに反映されているのは7月15日分のみ．7月5日，7月10日の分は修正前の記述になっている」．
読者のみなさんの中に，連日の休日出勤で疲れたFさんの代わりにこのプロジェクトのソース管理を立て直してくれる人はいるでしょうか？
