「提案書_最終_v2_修正版FIX」が増え続ける会社へ──ファイル名でバージョン管理するのを、そろそろやめる

提案書_最終.docx 提案書_最終_修正.docx 提案書_最終_修正_v2.docx 提案書_最終FIX.docx 提案書_最終FIX_田中修正.docx

心当たり、ありませんか。そして半年後、どれが本物か誰も分からなくなる。

これは整理整頓が下手だから起きるのではありません。ファイル名でバージョンを管理するというやり方が、そもそも人数と時間に耐えられないからです。1 人で 1 週間なら回ります。3 人で 3 ヶ月やれば、必ず崩れます。

この記事では、その代わりになる仕組みの話をします。結論から言えば Git（ギット） ですが、いきなりそこには行きません。多くの中小企業は、もっと手前で足りるからです。順番に見ていきます。

---

なぜファイル名管理は必ず崩れるのか

理由は 3 つあります。

1. 命名ルールは、忙しい日に破られる 「_v2 を付ける」と決めても、締切前日に「とりあえず」で保存する人が出ます。ルールを守らせる仕組みがないルールは、運用ではなく願望です。

2. 何を変えたのかが、ファイル名に書けない _v2 からは「2 番目である」ことしか分かりません。金額を直したのか、日付を直したのか、まるごと書き直したのか。変更の中身は、ファイル名には入らない。だから後から追えない。

3. 上書きは、取り返しがつかない 別名保存を忘れて上書きした瞬間、前の状態は消えます。共有フォルダなら、他人の作業ごと消えることもあります。

つまり問題は「名前の付け方」ではなく、変更の履歴を残す場所がどこにもないことです。

---

まず:クラウドドライブの版履歴で足りる場合

正直に書きます。多くの会社は、ここで解決します。

Google ドライブや OneDrive、SharePoint には**版履歴（バージョン履歴）**の機能があります。同じファイルを上書き保存しても、過去の状態が自動で保存されていて、いつでも戻せる。誰がいつ編集したかも記録されます。

• 扱っているのが Word・Excel・PowerPoint 中心
• 編集する人が同時に何人もいるわけではない
• 変更の履歴を厳密に追う必要まではない

この 3 つに当てはまるなら、Git を覚える必要はありません。いま使っているドライブの版履歴を使いこなす方が、確実に早くて確実に定着します。ファイル名に _v2 を付けるのをやめて、同じファイルを上書きしていく——それだけで、冒頭の問題はほぼ消えます。

ここを飛ばして Git を勧めるのは、不誠実だと思っています。

---

それでも足りなくなる場面がある

一方で、ドライブの版履歴では苦しくなる場面が確実にあります。

1. ファイルが「ローカルのツール」の中にある

これがいちばん大きい。Obsidian のようなノートアプリ、自社ツールの設定ファイル、開発中のアプリのソース——こうしたものは、手元のフォルダにファイルが並んでいる状態で動きます。

これをクラウドドライブで同期しようとすると、うまくいきません。ファイル数が多いと同期が遅れ、2 人が同時に触ると**「競合コピー」が量産され**、どれが本物か分からなくなる。ファイル名管理と同じ地獄が、別の形で戻ってきます。

2. アップロードという手間が挟まる

そして地味に効くのがこれです。作業のたびにブラウザを開いて、フォルダを選んで、アップロードして——この数十秒の手間が、続かない理由になります。VS Code の記事でも書いた通り、人の注意力と手間に依存する運用は、忙しい日から順に崩れていきます。

3. 容量を圧迫する

版履歴は過去の状態を保持するぶん、容量を消費します。大きなファイルを頻繁に更新していると、気づけばプランの上限が近づいている、ということが起きます。

4. 「何を変えたか」を説明として残せない

版履歴は「いつ・誰が」は分かりますが、「なぜその変更をしたのか」は残りません。判断の経緯が消えるのは、会議データの記事で書いた「決定の理由が残らない」問題とまったく同じ構図です。

---

実例:Obsidian のノートを、チームで同時に触れるようにした

私たちの話をします。

Obsidian というノートアプリを使っています。ローカルのフォルダ（vault）に md ファイルが大量に並ぶ形式で、手元で動くからこそ速くて快適な反面、そのままでは自分ひとりのものです。

これをチームで共有したい。でもクラウドドライブでは、ファイル数が多すぎて同期が追いつかず、2 人が同時に書けば競合します。

そこで Git で管理するようにしました。結果どうなったか。

• 最新の状態を確認してから書ける——書き始める前にワンタッチで最新を取り込む
• 自分の変更をワンタッチで反映できる——アップロードの操作は要らない
• 誰がいつ何を書いたかが全部残る——追える
• 同じファイルを別の人が触っていても、基本は自動でまとまる——行単位で管理されるため

要するに、ローカルの快適さを捨てずに、チームで共有できるようになりました。これは版履歴付きのクラウドドライブでは実現できなかったことです。

自社でツールを作っている会社、テキストで資料を管理している会社なら、同じ形が使えます。

---

Git とは何か（非エンジニア向けの説明）

ここまで来て、ようやく Git の説明です。

Git は「エンジニアの道具」というイメージが強いですが、やっていることは驚くほど単純です。

いつ・誰が・何を・なぜ変えたかを記録し、いつでも前の状態に戻せる。

それだけです。プログラムのためのものではなく、テキストで書かれたファイルなら何にでも使えます。仕様書、議事録、設定ファイル、原稿。

そして重要なのが、記録するときに「なぜ変えたか」を一言添える点です。「見積もりの金額を修正」「顧客名の表記を統一」——この一行が残るから、半年後に追えます。ファイル名の _v2 には、絶対に書けなかった情報です。

なお、VS Code にはこの Git が最初から組み込まれています。黒い画面でコマンドを打つ必要はなく、ボタンで操作できます。

---

いちばん大きい変化は、「触り方」が変わること

最後に、機能の説明では伝わらない話をさせてください。

Git を使い始めて本当に変わったのは、大胆に触れるようになったことです。

ファイル名で管理していた頃は、大きく手を入れるのが怖かった。「壊したら戻せない」と思うと、無難な直し方しか選べません。ためらって、コピーを作って、そのコピーがまた _v2 になる。

いつでも戻せると分かっていると、判断が変わります。 思い切って構成を変えてみる、一度まるごと書き直してみる、実験してダメなら捨てる——試すコストが劇的に下がる。

これはツールの機能の話ではなく、仕事の進め方の話です。個人的には、ここがいちばん大きい。

---

今日できる、最小の一歩

いきなり全部を覚える必要はありません。最初はこれだけです。

1. VS Code を入れて、管理したいフォルダを 1 つ開く
2. サイドバーの「ソース管理」から、リポジトリを初期化する（ボタンを押すだけ）
3. 区切りのいいところで、変更内容を一言書いて記録する

これだけで、そのフォルダはいつでも過去に戻せる状態になります。

push も branch も merge も、まだ出てきません。それらは複数人で共有するときに必要になるもので、一人で履歴を残すだけなら不要です。まず「戻せる」体験を一度してみてください。その先が必要になったら、そのとき覚えれば間に合います。

---

向いていない場合

• Word・Excel 中心の職場——Git は中身が見えるテキストに強く、Word や Excel のファイルは「変わったこと」しか分かりません。ドライブの版履歴の方が向いています
• 編集するのが基本ひとり——ドライブの版履歴で足ります
• 社内に一人も分かる人がいない——最初の設定でつまずくと定着しません。誰か一人が触れる状態を作ってから広げてください

---

まとめ

• ファイル名でのバージョン管理は、人数と時間に耐えられない。名前の付け方の問題ではなく、履歴を残す場所がないことが問題
• まずはクラウドドライブの版履歴。Word・Excel 中心で、編集者が少ないなら、これで解決する
• 足りなくなるのは、ファイルがローカルのツールの中にある / アップロードの手間が続かない / 容量を圧迫する / 「なぜ変えたか」が残らない場合
• Git は「いつ・誰が・何を・なぜ変えたかを記録し、戻せる」仕組み。テキストなら何にでも使える
• 最大の効用は機能ではなく、壊しても戻せると分かることで、大胆に試せるようになること
• 最初の一歩は、VS Code でフォルダを 1 つ、履歴を残し始めるだけ

「あのフォルダ、どれが本物か分からない」——その状態は、仕組みで消せます。

Acetyl:Tech は、こうした「現場の道具の使いこなし」から、業務の仕組み化までを支援しています。 資料やデータの管理が属人化しているなら、お気軽にご相談ください。