テクマトリックスの会田です。
私が所属するSE事業部では、過去に構成管理ツールの代理販売をしており、私がその製品の技術側の担当者でした。構成管理（バージョン管理）に携わってきた経験から、よく言われる「Gitを使うべき」についての考えや調べたことを記事にまとめておきます。
目次
1. 要約
- むやみにGitを選択せずに、開発プロジェクトの要件にあった構成管理（バージョン管理）ツールを選ぶべき。
- 開発プロジェクトによってはSubversionが向いているケースはある。
- GitHubやGitLabのGitホスティングにおけるプル/マージリクエストは本当に良い。使うことを一度は検討しても無駄ではない。
2. GitはSubversionよりも使われているのか
Gitが「流行っている」ことを確認してみます。
2.1. Googleの検索トレンド
SubversionとGitの検索トレンドを確認してみます。全世界と日本で時期に違いはあるものの、Gitの検索トレンドがSubversionを2010年までに追い越しており、2024年時点ではSubversionが「1」に対して、Gitの検索人気度は「約85」と大きな差が生まれています。Gitの情報が多く公開されており、検索されていることがわかります。
2.2. StackOverflowのサーベイ
StackOverflowでは、毎年エンジニア向けのアンケートを実施しています。
グラフ：Stack Overflowの2022年サーベイ、Version control systemsの結果を元に作成
構成管理（バージョン管理）システムについてのアンケートは2022年に実施されており、職業エンジニアの96.65%がGitを利用しているという結果が出ています。以降のアンケートではバージョン管理システムの集計は行われていません。Gitが主流という結果が出ており、アンケートから削除するほどGitを使うことが当たり前となっているようです。
Gitが流行っているのは、ネット上で公開されている情報を見る限りでは間違いないようです。
3. 開発ソフトウェアごとの特徴
まず、私が関わったことのあるソフトウェア開発について、業界やシステムごとに「私の個人的な感想」として特徴をまとめます。その後、Gitが向いている、Subversionが向いているケースについて私見を述べます。
| 業界・システム種別 | 求められる要件、特徴 |
|---|---|
| 製造業 | ・小規模～大規模で運用が大きく異なる。 ・小規模は標準化ルールがないケースもある。 ・派生開発や並行開発が多く、ブランチやマージに関する課題が発生しやすい。 ・開発ソフトウェアの寿命が長く、変更履歴管理が重視される。 ・安全規格へ適合する必要があり、アクセス制御などの厳格な管理が必要。 ・デプロイにハードウェアが関係するため、CI/CDは限定的。 |
| 車載・自動車 | ・分岐の多い派生開発や複数拠点での開発があり複雑。 - 国内や海外で仕様が異なる（仕向けがある）ため、分岐が多い。 - サプライヤーが開発を請け負うケースが多い。（常駐、受託など多種） - 地理的に分離した拠点で開発を行う。 ・モデルベース開発環境と親和性の高い構成管理（バージョン管理）を利用する。 ・工場など開発拠点外でコードを変更し、総合試験を行うケースがある。 |
| 業務システム | ※基幹業務や業務支援、情報共有など、用途や範囲が多岐に渡る。 ・基幹業務：大規模かつ信頼性が重視される。厳格な開発プロセスや成果物の 管理が求められる。システムの寿命が長く、開発と保守で担当が変わる。 ・業務支援、情報共有：複数のシステムとの連携する要件が多い。連携する システムによっては大規模のデータの取り扱いが必要。 ・業界特化：業界の法令や監査対応が必須なケースあり。 |
| 金融・銀行システム | ・システム自体に高い信頼性と可用性が求められる。 ・厳格なアクセス管理、変更履歴の完全性、コンプライアンス遵守が必要。 ・案件（新規開発や保守開発）が並行して進むため、案件ごとのマージや デプロイの計画立案に多大な労力が必要。 ・（経験上）ビジネスパートナーが開発した成果物は納品後に構成管理（バージョン管理）に 登録されるため、小さい変更の単位では履歴が残らない。 |
| Webサービス | ・頻繁に新機能をリリースすることで競合との差別化を図る。 ・利用者数の増加に対応するために高いスケーラビリティが必要。 ・アジャイル開発手法を採用し、CI/CDサイクルを回す活動が盛ん。 ・新しい手法やツールを取り入れる文化が根付いているケースが多い。 |
| ゲーム | ・ディレクターやデザイナー、テスターなど、多用なメンバーが共同で作業。 ・モバイルやオンラインゲームでは、頻繁なアップデートが必要。 ・メディア、ゲームアセットなど大容量のファイル管理が必要。 ・マルチプラットフォーム対応でコードが分岐、派生する。 ・頻繁にテストを行うため、テスト効率化のために自動化やCIの活動が盛ん。 |
4. Gitが向いているケース
先に記載した開発ソフトウェアの特徴を見てみると、明らかにGitが向いているケースがあります。
Webサービスは明らかにGitが向いています。
頻繁なリリース、アジャイル、CI/CDサイクルなどの特徴から、Gitホスティング（GitHubやGitLab、BitBucketなど）が向いています。プル/マージリクエストを契機としてインテグレーションを実施し、ステージング環境へのデプロイまでを自動化する恩恵が大きいです。
それ以外のソフトウェアはどうでしょうか。特徴からは明らかにGitを使うべきと言えるものはありません。開発プロジェクトでCI/CDサイクルを回したい、変更したコードのレビューや承認をシステムで実現したいなどの理由があれば、Gitを採用するでしょう。コードの変更履歴を管理し、アクセス制御ができれば良いという要件だけであれば、Subversionで十分です。
※ ゲーム業界は構成品目にバイナリファイルが多いという特徴があるため、メディアファイルの管理に長けた有償ツールが採用されるケースが多いです。
厳格なアクセス制御を必要とする開発においては、Gitを採用するとかえってプロセスを制御・管理する手間がかかるケースがあります。というのも、「堅い」開発プロジェクトにおいては、「情報資産へのアクセス（読み取り）」もログとして残したいケースがあるためです。
5. Subversionが採用されているケース
日本のシステム開発では、ビジネスパートナーが受託開発を請け負う場合、さまざまな理由でSubversionのほうが都合が良い（Gitにするメリットがない）ケースが存在します。
5.1. コンプライアンス遵守、中央集中型管理が求められるケース
官公庁システムや金融、医療などの規制が厳しい業界では、Gitの分散管理の仕様は相性が悪いです。開発者が成果物にアクセスしたことをログに残し、承認を得た上で変更を許可する仕組みが求められるためです。Gitを採用した場合、こうしたアクセス制御や監査の対応のために新しく開発ルールを策定する必要があります。また、開発者のGit利用のためのトレーニングが必要となり、開発フェーズと保守フェーズで担当する開発会社が変わるようなケースでは、教育のコストもかかります。
私が知っている、とある堅いシステム開発では、Subversionを採用していました。その開発では、開発者はSubversionに直接ci/coすることはできず、以下のようなフローで開発していました。
- 変更依頼システムでどのシステムのどのファイルを変更するかを申請フォームから申請
- 承認されるとファイルが提供される（Subversionから取り出したファイルを共有される）
- ファイルを変更した後、変更依頼システムで登録を申請
- 承認されるとファイルが登録される（Subversionにファイルが登録される）
コードや設計書の変更に申請と承認が必要でした。こうした運用は一見手間だと感じますが、コンプライアンス遵守を最優先とした結果として生まれた運用フローであると、今なら理解できます。こうした遵守のプロセスが確立されている場合、構成管理（バージョン管理）ツールが何であるかは優先度の高い問題ではありませんし、Gitに変えたところでGitのメリットは享受できません。もっと抜本的な開発プロセスの変更が必要です。
5.2. 開発ソフトウェアのライフサイクルが長いケース
さらに、5.1.に記載したシステムは開発から保守の期間が長いため、10～20年以上稼働しているものがあります。これらシステムは開発を開始した当時はトレンドであったSubversionを採用し、そのまま利用を続けているという実情があります。
また、Gitに移行したくとも移行コストが高く、膨大な履歴を変換する必要があるため、現行システムが稼働している間は移行できないこともGitが採用されない要因の1つだと感じます。
同じような考えを述べている記事がありますので、参考として記載します。
- Is Subversion Still Used Today?
- 記事を公開しているassemblaはSubversion, Git, Perforceのホスティングサービスを提供しており、営業的な観点（ポジショントーク）でSubversionを推しているわけではなさそうです。
5.3. バイナリファイルの管理が必要なケース
Subversionを採用する他の理由としてバイナリファイルの管理が挙げられることがあります。組み込みやゲーム開発など、バイナリファイルを扱う開発においては、GitよりもSubversionのほうがパフォーマンスが高いため、採用されるケースがあります。これも参考記事があります。
- Subversion beats Perforce in handling large files, and it’s not even close
- 記事では、PerforceとSubversionのバイナリファイルのパフォーマンス比較を行っています。Gitのバイナリファイル管理の問題についても触れており、Git LFSも信頼できないと記載しています。（本当かな…）
6. 経験から思ったこと
記事の序盤に紹介したように、Gitを使うことが当たり前のような風潮がありますが、実際の現場を見ていくとGitのメリットをあまり活かせないケースがあるのも事実です。特に、以下のような状況ではSubversionでも大きな不便がなく、むしろGitを導入した際の運用コストが増大する可能性があります。
- 物理的に開発拠点が分離され、頻繁にソースコードをやり取りしない場合
例：ビジネスパートナーからソースが納品され、社員が内容を確認して構成管理（バージョン管理）に登録するフロー。コミットを頻繁に行わない前提だと、Gitの分散管理のメリットが発揮されにくい。 - 競合（衝突）を極端に嫌う開発形態の場合
例：標準化された開発プロセスで申請を経て成果物を登録する。この場合、登録の頻度が少なく、承認のワークフローが構成管理（バージョン管理）の外で完結するため、SubversionでもGitでも運用形態は大きく変わらない。
こうしたケースで「Subversionでも問題なく運用できている」という現場に無理にGitを導入すると、トレーニングや監査要件への対応など新たなコストが増えるばかりで、かえってデメリットが大きくなることもあります。
7. じゃあGitを使わなくても良いのか？
結論からいうと、「それでもGitホスティングサービス（GitHubやGitLabなど）の導入は検討してみる価値がある」と考えています。とりわけ、日本のソフトウェア開発で以下のようなニーズがある場合、開発プロセスの改善の肝になります。
- 承認ゲートとして活用したい場合
たとえば、プル/マージリクエストを次工程へのゲートと見なし、リクエスト時に影響分析や静的解析を自動実行する。
承認の証跡をそのままツール上に残せるため、従来の「別システムで承認→成果物を登録」よりもスマートに運用できる。 - アジャイル開発やCI/CDサイクルを回したい場合
Gitが得意とするブランチ戦略（Gitflow、GitHub-flow）を採用すると、開発者それぞれが頻繁にコードをテスト・レビューしあえる環境が整う。
Subversionでもブランチは作れますが、Gitに比べてブランチの作成・管理コストが高いため、同じ運用をしようとすると運用ルールが複雑になりがちです。 - これから新規の開発プロジェクトをはじめる場合
これから新たに開発プロジェクトがはじまる場合は、明確な理由がない限りは現在のトレンドであるGitを採用することをおすすめます。
過去の開発プロジェクトの資産を引き継ぐ場合は、Gitへの移行が必要となります。移行時は対象をすべての履歴、リリースバージョンだけ、最新版だけとするのかを判断する必要があります。
もちろん、新しい運用プロセスを取り入れるには大きな労力や組織的な調整が必要で、教育コストもかかります。しかし、それだけの投資をしてもお釣りがくるほどの効果（効率化・品質向上・エンジニアのモチベーションアップなど）が得られる場合は、検討して損はありません。
8. まとめ
- Subversionが向いている開発は確かに存在する
コンプライアンス重視や厳格なアクセス管理が必要な開発、バイナリファイルを多く扱う開発、あるいはコミットの頻度が極端に少ない開発などでは、Subversionでも十分に事足りるケースがあります。すべてのプロジェクトがGitに移行する必要はありません。 - 一方で、Gitホスティングサービスの恩恵は大きい
製造業の派生開発、Webサービスや業務システムの継続的なリリースなど、アジャイルやCI/CDを取り入れる現場では、プル/マージリクエストを軸とした開発フローが非常に有効です。
ブランチの作成や管理コストが低く、多数の開発者が並行して作業できる環境が簡単に構築できます。 - 最終的には「自分たちの現場に合ったツール」を選ぶことが重要
構成管理（バージョン管理）ツール自体の選択よりも、開発現場の要件や制約、組織の文化、理想とするプロセスに目を向けることが大切です。ツールの移行には教育コストや履歴データの変換作業などが伴うため、「なぜ移行したいのか」「移行して何を実現したいのか」を明確にしたほうがうまくいきます。
もし、現場の要件に照らし合わせても「どちらが良いのかわからない」「そもそも運用プロセスから変えないとメリットが出ない」という場合には、構成管理ツールの導入や移行を経験している専門家に相談するのも手です。運用ルールの策定やチーム教育まで含めて検討すれば、ただツールを変えるだけでは得られなかった新しい開発体制の可能性も見えてくるでしょう。
開発基盤ソリューションではGitの移行の相談を受け付けています。
Gitや構成管理（バージョン管理）ツール、CI/CDのご相談はこちらから。
