「先週お願いした修正、やっぱり前の状態に戻してもらえますか」。担当者からそう連絡した瞬間、電話の向こうの声が一瞬止まった。「確認します」と言われてから戻ってきた答えは、こうだった。「バックアップは取っていましたが、変更履歴の管理まではしていませんでした。前の状態に戻すには、もう一度作り直すしかありません」。
画面はすでに動いていない。注文が入らない。問い合わせフォームも送信できない。今日一日の売上と信用が、目の前で削られていく。原因を尋ねても「ちょっと調べてみないと」としか返ってこない。何が変わって、何が壊れたのか、開発会社自身が把握できていないのだ。
これは特別な話ではない。中小企業が自社の業務システムやECサイト、予約管理システムを外部に発注したとき、実際に起きている光景だ。そしてその根っこには、たいてい同じ言葉がある。バージョン管理。エンジニアにとっては当たり前すぎて説明されることのないこの仕組みが、実は発注者の運命を大きく左右している。
バージョン管理とは何か。専門用語を使わずに説明する
バージョン管理を一言でいえば、システムの設計図や中身のプログラムに加えた変更を、すべて記録しておく仕組みのことだ。誰が、いつ、どこを、どう変えたのかという履歴を一つ残らず保存しておく。まるで原稿を書くときに、下書きのすべての版を捨てずに取っておくようなものだと考えるとわかりやすい。
普段、私たちはWordやExcelのファイルを保存するとき「上書き保存」をする。前の状態は消えて、新しい状態だけが残る。もし途中で間違いに気づいても、よほど「変更履歴」機能を使っていない限り、前の版には戻れない。
業務システムの開発現場では、この「上書きされて戻れない」状態を避けるために、変更のたびに版を記録していく専用の仕組みを使う。これがバージョン管理であり、そのための代表的なツールが「Git(ギット)」と呼ばれるものだ。開発会社との打ち合わせで「Gitで管理しています」と言われたら、それは「変更のたびに版を記録して、いつでも過去の状態に戻せるようにしています」という意味だと理解しておけばいい。
大事なのは、これは単なる技術の細部ではないということだ。発注者の事業がシステム障害でどれだけ止まるか、担当者が変わったときにどれだけ混乱するか、追加開発のたびにどれだけ余計な費用がかかるか。バージョン管理の有無は、そのすべてに直結している。
バージョン管理をしていないとき、現場で何が起きるか
バージョン管理がされていないシステム開発の現場では、目に見えにくいところでリスクが積み上がっていく。三つの典型的な場面を挙げる。
変更を元に戻せない
冒頭の例がまさにこれだ。追加した機能に不具合が見つかった、あるいは新しいデザインが評判が悪かった。「じゃあ前の状態に戻そう」というのは、事業をやっていれば当然出てくる判断だ。ところがバージョン管理がなければ、開発会社の手元には「今の状態」しか残っていない。戻すためには記憶とバックアップファイルを頼りに、手作業で再現するしかない。しかも、その再現が完全である保証はどこにもない。
複数人での同時編集による上書き事故
システムの規模が大きくなれば、一人の担当者だけでなく複数のエンジニアが同時に手を入れることになる。バージョン管理がなければ、Aさんが直した部分をBさんが知らずに上書きしてしまう、といった事故が起きる。誰かが半日かけて直した内容が、翌朝には跡形もなく消えている。これは決して大げさな話ではなく、履歴を残す仕組みがないチームでは実際に繰り返し起きている。
担当者交代時に何が変わったのか誰もわからない
開発会社の担当エンジニアが退職や異動でいなくなることは、珍しくない。バージョン管理がされていれば、後任者は履歴を追うことで「いつ、何のために、どこを変えたのか」を把握できる。しかしそれがなければ、後任者は真っ白なコードを前にして、まず何が起きているのか調べることから始めなければならない。この調査だけで数十万円の見積もりが発生することもある。発注者からすれば、担当者が変わっただけで、過去に払った開発費の一部が無駄になったに等しい。
バージョン管理があることで、発注者は何を得るのか
バージョン管理は、エンジニアのための便利機能ではない。発注者にとっての安心材料でもある。
- 何かトラブルが起きても、問題が発生する前の状態に戻せる。事業を止める時間を最小限にできる。
- いつ、誰が、なぜその変更をしたのかという記録が残るため、後から「言った言わない」の水掛け論にならない。
- 開発会社を乗り換えるときも、履歴ごと引き継げるため、新しい担当者がゼロから調査し直す必要がない。
- 担当者が退職・異動しても、システムの変更履歴という「会社の資産」は残り続ける。
特に最後の二つは見落とされがちだが、実は経営判断として重要だ。システムは一度作って終わりではなく、事業とともに何年も育てていくものだ。その過程で開発会社を変えたい、あるいは社内に詳しい人材を採用して内製化したいと考える場面は必ず来る。そのときに履歴が残っているかどうかで、引き継ぎにかかる時間とコストは何倍も変わってくる。バージョン管理は、将来の自分たちの選択肢を守るための仕組みでもあるのだ。
発注前に確認すべき質問
専門用語がわからなくても、次の質問を発注前の打ち合わせでそのまま投げかければいい。回答の中身よりも、即答できるかどうか、答えを濁さないかどうかに注目してほしい。
- 「Gitなどのバージョン管理ツールを使っていますか」。使っていて当然の質問であり、ここで言葉に詰まる会社は要注意だ。
- 「変更履歴を、発注者側でも確認できますか」。GitHubやGitLabといった管理画面を見せてもらえるか、あるいは変更内容を定期的に報告してもらえるかを聞く。履歴を見せることを渋る会社は、そもそも履歴を整理して残していない可能性がある。
- 「システムを元の状態に戻す作業には、どのくらいの時間と費用がかかりますか」。具体的な数字や手順がすぐに出てくるかどうかで、日頃からその準備ができているかが見える。
- 「担当者が交代した場合、引き継ぎはどのように行われますか」。履歴と設計資料が揃っていれば、引き継ぎの説明にも具体性が出る。
- 「このシステムのソースコードとその履歴は、契約終了後も当社が保有できますか」。所有権と履歴へのアクセス権をセットで確認しておく。
難しい専門知識を持って質問する必要はない。むしろ、非エンジニアだからこそ「なぜそれをしているのか」という素朴な問いを投げられる。壁の向こう側の言葉を無理に覚えなくても、壁を越えて確かめるべきことは確かめられる。
よくある失敗パターン
実際の発注現場でよく見られる失敗を三つ紹介する。
一つ目は、見積書の安さだけで発注先を決めてしまうケースだ。バージョン管理を整備し、履歴をきちんと記録する体制には、それなりの工数がかかる。見積もりが極端に安い会社の中には、こうした地味だが重要な工程を省略しているところがある。安さの裏側に何が省かれているのかを、必ず確認する必要がある。
二つ目は、開発会社に丸投げしてソースコードの所在を確認しないケースだ。契約書に「納品物としてソースコード一式を引き渡す」と明記されていなければ、システムの中身も、その変更履歴も、開発会社のパソコンの中にしか存在しないという事態が起こり得る。契約を切ったとたん、自社のシステムなのに中身に触れられなくなる。
三つ目は、担当者が個人的な感覚で管理してしまっているケースだ。小規模な開発会社やフリーランスに多いが、「自分は変更内容を覚えているから大丈夫」という属人的な管理は、その人が体調を崩したり連絡が取れなくなったりした瞬間に破綻する。バージョン管理は、人の記憶に頼らないための仕組みでもある。属人化は一見コストが低く見えて、実は最も高くつくリスクだ。
まとめ
バージョン管理とは、システムに加えたすべての変更を記録し、いつでも過去の状態に戻れるようにしておく仕組みのことだ。専門用語としては難しく聞こえるかもしれないが、意味することはシンプルで、事業を守るための安全網そのものだと考えていい。
これが整備されていない開発会社に発注すると、トラブルが起きたときに元に戻せない、複数人での作業で上書き事故が起きる、担当者が変わったときに何もわからなくなるという三重のリスクを背負うことになる。逆にこれが整備されていれば、何かあっても戻せる安心感と、引き継ぎのしやすさという二つの資産を手にできる。
非エンジニアであっても、「Gitを使っていますか」「変更履歴は見せてもらえますか」という質問さえ投げかければ、発注先の力量と誠実さを見極める入り口に立てる。専門用語の壁を完全に理解する必要はない。壁の向こうにいる相手が、自分たちの事業をきちんと守ってくれる相手かどうかを見抜くことこそが、発注担当者に求められている仕事だ。わからないことを正直に問い直せる担当者こそが、結果として会社を守っている。そのことを、忘れないでほしい。