「SVNでチェックアウトしておいて」
——SVN？何それ？
IT未経験からSESエンジニアに転職して、最初の現場に入った日の私です。転職前の学習では、学習サイトもYouTubeもUdemyも「Git、Git」一色。SVNという単語は、現場に入るまで一度も目にしたことがありませんでした。存在すら知らなかったものが、配属初日にいきなり「チームの標準ツール」として目の前に現れたのです。
その後、私は2つの現場を経験しました。1現場目（金融系）はSVNが完全に現役。2現場目はGitLabがメインで、必要に応じてSVNも併用。つまり、学習コンテンツには登場しないSVNが、現場では普通に使われています。
これからITエンジニアを目指すあなたが、初日の私のように固まらないために。
この記事では、両方を実際に業務で使った経験をもとに、GitとSVNの違いと、未経験者がどちらから学ぶべきかを解説します。
目次
Open 目次
まず結論：学ぶのはGitから。ただしSVNの存在は知っておく
最初に結論をまとめます。
- これから学ぶならGit一択。新規開発の現場・求人の大半はGitで、学習教材も豊富
- ただしSVNは「過去の遺物」ではなく、金融系・官公庁系のレガシー案件ではいまも現役
- Gitでバージョン管理の概念を理解していれば、SVNの現場に入っても数日で慣れます（私がそうでした）
「Gitだけ覚えれば大丈夫」とも「SVNも勉強しなきゃ」とも言い切らないのが、現場を経験した上での正直な答えです。学ぶのはGit、でもSVNがどういうものかは知っておく——この記事1本でその「知っておく」を済ませてください。
そもそもバージョン管理とは：「最終版_修正2_本当に最終.xlsx」をなくす仕組み
バージョン管理システムを一言でいうと、**「ファイルの変更履歴を全部記録して、いつでも過去の状態に戻せるようにする仕組み」**です。
こんなファイル名を見たことはありませんか。
設計書_最終版.xlsx
設計書_最終版_修正.xlsx
設計書_最終版_修正2_本当に最終.xlsxこれは人力のバージョン管理です。コピーを作って履歴を残しているわけですが、どれが本物の最新かわからなくなり、誰かが古いファイルを編集して大事故になる。
ソフトウェア開発では何十人が同じソースコードを同時に編集するので、この方式では一瞬で破綻します。そこで「誰が・いつ・何を・なぜ変えたか」をシステムで記録し、複数人の変更を安全に合流させる仕組みが必要になりました。それがバージョン管理システムで、その二大勢力がSVN（Subversion）とGitです。
GitとSVNの違い：分散型と集中型
両者の最大の違いは、リポジトリ（変更履歴の保管庫）の持ち方です。
SVNは「集中型」：中央サーバーがすべて
SVNでは、変更履歴を持つリポジトリは中央サーバーに1つだけ存在します。開発者は中央サーバーから最新のファイルを取得（チェックアウト）し、変更したらサーバーに反映（コミット）します。
- コミット＝即・中央サーバーに反映。チーム全員に影響する
- 履歴の確認やコミットにはサーバーへの接続が必要
- 構造がシンプルで、「サーバーのものが正」という考え方がわかりやすい
Gitは「分散型」：自分のPCにもリポジトリがある
Gitでは、開発者全員が自分のPCにリポジトリの完全なコピーを持ちます。
- コミット＝自分のPC内のリポジトリへの記録。何度コミットしても誰にも影響しない
- 共有サーバー（GitHub・GitLabなど）に反映するのはプッシュという別の操作
- オフラインでもコミット・履歴確認・ブランチ作成ができる
- ブランチ（並行作業用の分岐）が軽量で、気軽に作って捨てられる
比較表
| 項目 | SVN（集中型） | Git（分散型） |
|---|---|---|
| リポジトリ | 中央サーバーに1つ | 全員のPC＋共有サーバー |
| コミット | 即サーバー反映 | まずローカルに記録（pushで共有） |
| オフライン作業 | ほぼ不可 | コミット・履歴・ブランチ全部可能 |
| ブランチ | 重い（運用されない現場も多い） | 軽量で日常的に使う |
| 代表的なツール | TortoiseSVN | GitHub・GitLab・SourceTree |
| 学習教材 | 少ない | 非常に豊富 |
| 採用される現場 | レガシー・金融・官公庁系 | 新規開発のほぼすべて |
未経験者が最初に混乱するのは、Gitの「コミットとプッシュが別」という点です。SVN感覚だと「コミットしたのにチームに反映されてない！」となりますが、Gitではコミット（ローカル保存）→プッシュ（共有）の2段階。逆にここさえ押さえれば、Gitの理解は一気に進みます。
現場のリアル：金融系の1現場目はSVNが完全に現役だった
ここからは私の実体験です。
1現場目（金融系）：TortoiseSVNでの開発が「普通」だった
未経験からSESエンジニアになって最初に配属されたのは金融系の案件でした。そこで使われていたのは、GitではなくSVN。それも「移行が遅れている」という空気ではなく、SVNでの開発が完全に標準として回っている現場でした。
使っていたのはTortoiseSVN（トータスSVN）というツールです。亀のアイコンが目印で、エクスプローラーに統合されるのが特徴。フォルダを右クリックすると「SVN Update」「SVN Commit」といったメニューが出てきて、コマンドを打たずにマウス操作でバージョン管理が完結します。
冒頭に書いたとおり、私はこの現場に入るまでSVNという単語自体を知りませんでした。初心者向けの学習コンテンツには登場しないので、知る機会がなかったのです。初日に亀のアイコンを見て固まった私を救ってくれたのは、事前にGitでバージョン管理の概念を学んでいたことでした。
「リポジトリから最新を取ってくる」「変更をコミットする」「他人の変更と衝突したら解消する」——この流れ自体はSVNもGitも同じです。違うのは「コミットが即サーバーに反映される」ことくらいで、概念を理解していたおかげで数日で普通に作業できるようになりました。
2現場目：GitLabがメイン、ただしSVNも併用
2つ目の現場はGitLabがメインでした。ブランチを切って開発し、マージリクエスト（GitHubでいうプルリクエスト）でレビューを受けてからマージする、いわゆるモダンな開発フローです。
ただ、この現場でも一部の資材はTortoiseSVNで管理されていて、必要に応じて両方を使い分けていました。古くからあるドキュメントや設計資材はSVN、ソースコードはGitLab——という住み分けです。
2つの現場を経験してわかったのは、初心者向けの学習コンテンツとSESの現場には情報の断絶があるということです。学習の世界ではSVNはそもそも登場すらしない。でも現場では、特に金融・官公庁系の歴史が長いシステムで、安定して動いているSVN運用をわざわざリスクを取って移行しない判断は普通にあります。SES・SIerでこの領域の案件に入る可能性があるなら、SVNに遭遇する前提でいたほうがいい。
未経験者がGitから学ぶべき3つの理由
現場ではSVNも現役——それでも、これから学ぶのはGitからで間違いありません。理由は3つです。
理由1：新規開発と求人の大半はGit
新しく始まるプロジェクトでSVNが採用されることはまずありません。求人票のスキル欄に書かれるのも、ほぼ「Git／GitHub／GitLab」です。SVNは「現場で出会ったら慣れる」で十分で、先に学ぶ対象ではありません。
理由2：Gitを理解していればSVNはすぐ使える
私の実体験のとおりです。バージョン管理の概念——リポジトリ・コミット・更新・競合の解消——はGitで学んだものがそのまま通用します。むしろSVNのほうが構造はシンプルなので、Git→SVNの順なら戸惑いは最小です。逆にSVNだけ知っている状態でGit現場に入ると、ローカルリポジトリやブランチ運用の概念を現場で学ぶことになり、負荷が大きくなります。
理由3：GitHubがそのままポートフォリオになる
未経験からの転職活動では、GitHubアカウントに学習の成果物を公開しておくと「実際に手を動かしている」証明になります。Gitを学ぶこと自体が、転職活動の武器づくりを兼ねるのです。SVNにはこの使い道がありません。
私がやったGit学習法：ハンズオン形式の講座で「手を動かす」
最後に、私が転職前にやって現場で困らなかった学習方法を紹介します。
使ったのはUdemyの講座です。
Git: もう怖くないGit！チーム開発で必要なGitを完全マスター
Udemyで講座を見る
この講座を選んでよかったと思うのは、ハンズオン形式であることです。スライドを眺めて概念を覚えるのではなく、実際に自分のPCでリポジトリを作り、コミットして、ブランチを切って、わざとコンフリクト（変更の衝突）を起こして解消する——全部自分の手を動かして体験します。
バージョン管理は、文章で読むと抽象的でピンとこないのに、手を動かすと「なんだ、そういうことか」と一瞬で腑に落ちる典型的な分野です。私はこの講座で概念と操作を体に入れてから現場に入ったので、SVNの現場でもGitLabの現場でも、バージョン管理で困った記憶がほぼありません。
転職前に受講したUdemy講座の全体像は未経験からIT転職する前に受けてよかったUdemy講座まとめに書いています。あわせてどうぞ。
まとめ：Gitを学び、SVNを知っておく
この記事の要点です。
- バージョン管理＝変更履歴を記録し、複数人の変更を安全に合流させる仕組み。二大勢力がSVNとGit
- SVNは集中型（中央サーバーに即反映）、Gitは分散型（ローカルにコミット→プッシュで共有）
- 金融系・官公庁系の現場ではSVN（TortoiseSVN）がいまも現役。私の1現場目も完全にSVNだった
- それでも学ぶのはGitから。新規開発・求人はGit、概念はSVNにも通用、GitHubがポートフォリオになる
- 学習はハンズオン形式で手を動かすのが最短。私はUdemyの講座で学んでから現場に入り、困らなかった
「Gitを学んでおけば、SVNの現場に放り込まれても大丈夫」——これが2つの現場で両方を使った私の結論です。安心してGitの学習から始めてください。
よくある質問（FAQ）
Q1. SVNはもう学ぶ価値がないのでしょうか？
「先回りして学ぶ」価値は低いですが、「出会ったら触れる」心構えは持っておくべきです。金融系・官公庁系・製造業系の歴史あるシステムでは現役で使われており、SES・SIerで働くなら遭遇する可能性は十分あります。Gitの概念があれば現場で数日あれば慣れるので、事前学習は不要というのが私の実感です。
Q2. GitHubとGitLabは何が違うのですか？
どちらも「Gitのリポジトリをチームで共有するためのWebサービス」で、役割はほぼ同じです。GitHubは世界最大で個人のポートフォリオ公開にも定番、GitLabは自社サーバーに設置（セルフホスト）できるため企業の社内開発でよく使われます。私の2現場目もGitLabでした。操作の概念は共通なので、片方を覚えればもう片方もすぐ使えます。
Q3. コマンド（黒い画面）が苦手です。GUIツールでもいいですか？
現場ではTortoiseSVNやSourceTreeのようなGUIツールも普通に使われているので、GUIで仕事は成立します。ただし学習の最初だけは、コマンドでgit add・commit・push・mergeを一通り体験することをおすすめします。裏で何が起きているかを理解してからGUIを使うのと、GUIのボタンを丸暗記するのとでは、トラブル時の対応力がまるで違うからです。
Q4. コンフリクト（競合）が怖いです。やらかしたら大事故になりませんか？
コンフリクトは「事故」ではなく、複数人開発では日常的に起こる正常なイベントです。Gitは履歴をすべて保持しているので、操作を間違えてもほぼ確実に元に戻せます。怖さの正体は「対処法を知らないこと」なので、学習段階でわざとコンフリクトを起こして解消する練習をしておくと、現場での恐怖心が消えます。ハンズオン形式の講座にはこの練習が組み込まれています。
Q5. 未経験の転職活動で、Gitスキルはアピールになりますか？
なります。ただし「Gitを勉強しました」と言葉で言うより、GitHubアカウントに学習成果物をコミット履歴ごと公開するほうが何倍も効きます。継続的なコミット履歴は「学習を続けられる人」の客観的な証明になるからです。面接で聞かれたときに「ブランチを切ってプルリクエストを出す流れを一人で練習しました」と言えれば、チーム開発への準備として十分アピールできます。
Q6. SVNしか使っていない現場に配属されたら、Gitスキルは無駄になりますか？
無駄になりません。私自身が金融系のSVN現場に配属されましたが、Gitで学んだバージョン管理の概念（リポジトリ・コミット・競合解消）はそのまま通用し、数日で慣れました。また、自分の学習やポートフォリオ管理でGitを使い続けることはできるので、スキルが錆びることもありません。むしろ「両方使える人」になれるチャンスです。
免責事項：本記事は筆者個人の体験談を共有するものです。記事内のリンクにはアフィリエイトリンクが含まれます。