[第2回]監督コラム: Unity Version Control System（UVCS）ってぶっちゃけどう？ [技術記事]
ごあいさつ
こんにちは！ 監督（兼エンジニア）の太田一行です。前回の「キービジュアルができあがるまでの記事をたくさんの方に閲覧いただき、嬉しいです！ ありがとうございました。引き続きよろしくお願いします。
今回は、『アイリス・オデッセイ』の開発（ゲームプログラミング）について書いていこうと思います。なので、今回はゲーム開発に関わるマネージャの方あるいはエンジニアの方向けの内容となります。なのでエンジニアの皆さん、『アイリス・オデッセイ』はさておきゲーム開発一般の話と思って拡散していただけると助かります！！
テーマは、『Unity Version Control System（UVCS）ってぶっちゃけどう？』です（特にGitと比べて）。小規模なインディ―ゲームの開発において、バージョン管理システムをどうするか？ は結構悩みどころだと思います。Git／GitHubを使うのか、それともUnityがプッシュしている謹製UVCSのレールに乗るのか、技術選択の大きな分かれ目という感じがしますが、日本語で取り扱っている最近の記事をみなかったので、僕も決めるときには随分悩みました。
開発をスタートさせて半年以上、幣チームではUnity Version Control System（以下UVCS）を運用してきたので、採用に至る経緯や運用フロー、現状の評
価雑感を書いていければと思います。
最後に、『アイリス・オデッセイ』開発チームでは、Unityを一緒に書いてくれる人を募集しています！！
TL;DR
書いている人はWeb系／Webアプリが主戦場のソフトウェアエンジニアで、その目線での評価になります。
UVCS、ぶっちゃけどう？
機能する（婉曲表現）。
UVCSを採用するメリット
中央集権型で、ゲーム開発に適性がある
アセットファイルの管理がより簡潔 (vs Git LFS)
謹製という安心感。
非エンジニア（プランナー、デザイナー）のメンバーにとって敷居が低いように、クライアントが工夫されている。ありがたい。
UVCSを採用するデメリット
GitHub likeな管理クラウド、Unity Cloudにロックインされる
残念ながら使い勝手は良くない
Unity DevOps（CI／CD機能）も、CircleCIやGitHub Actionsに比べて自由度が低かったりデバッグが難しかったりという辛さが目立つ。
ぶっちゃけた話、技術的な筋の良さは置いておいて、Unity CloudというウワモノがGitHubエコシステムと比較してイケていないため、開発者目線では不満。
持って帰ってほしいTIPS
わからないことはGitHub CoplilotかChatGPTに聞くとよい。PlasticSCM時代のコミュニティノートの蓄積がかなりあり、それらは学習コーパスに含まれている。
結論
開発者がある程度我慢すれば使える状況なら、それが一番ではないか。インディ―ゲーム開発者の皆さんは、結局UVCS使うのがいいと思っています。
前提
PCゲームをUnityで開発する。
予算には制約条件がある。
開発フローに参加するチームメンバーは3人～最大5人程度まで増加する。
一定以上のリソースをかけて開発できるのはリーダーのエンジニア（僕）のみ
直接Unity C# コードを読み書きする人は僕入れても現状2人
他の方はプランナー、デザイナーなど
純技術的な検討 Git vs UVCS
インディーゲーム開発全体を取りまとめるバージョンコントロールシステムはGitかUVCSのどちらかになると考えてよいでしょう。
Git
Gitを採用するメリットは、利用者数が非常に多いため、コミュニティやサポート、周辺技術が大変優れていることが挙げられます。例えば、GitHubの存在がアプリ開発の大前提と感じるエンジニアの方もいらっしゃるのではないでしょうか。
実際、Git/GitHubはUnityに対しても十分にサポートを提供しています。以下のような動画を参考に、GitHubエコシステムにUnityを簡単に取り込めます。
gitを採用するデメリットは、2点あります。
一点目が、Gitは画像、動画などのアセットファイルを格納するのに向いた仕組みではないということです。これは、ゲーム開発においては見逃せないビハインドです。
Gitは本来的にソースコードのようなテキストファイルを管理するのに特化したシステムです。ファイルごとの差分を記録し、保存する仕組みはテキストに対してはうまく動作しますが、画像などのファイルに対しては、1bitの違いでもファイル全体を新たに保存してしまいます。このため、リポジトリサイズが開発に伴い急速に増大してしまうという欠点があります。
このような問題を解決する外部ツールとして、Git LFSがあります。LFSでは、画像の代わりにファイルのポインタだけを持つようにします。外部にアセットファイルを保管する専用サーバを立て、そこからポインタを辿ってファイルを出し入れするという仕組みです。
二点目が、ユーザはCLIの知識を求められるということです。プランナーやデザイナーと協同する上での課題となります。Git/GitHubのGUIクライアントを使うこともできますが、その場合でもGit LFSとの連携が必要です（公式で連携がサポートされています）。
結論としては、LFSとCLIのハードルを超えられるのであれば、Gitによる管理はおすすめです。実際、僕の周辺でも、ソーシャルゲーム系のプロジェクトだとGitHubでの管理が多い印象があります。そういった会社は、ソーシャルゲームだけでなく他のWebアプリ系事業を持っていることも多く、メンバーにとって慣れた開発文化でやれる、というのも理由の一つになっているかと思います。
UVCS
UVCSは中央集権型のバージョン管理システムなので、ゲーム開発に適した要件をいくつも備えています。
UVCSは、画像などのアセットを管理することを前提に、リモートサーバに最初からファイル管理システムがついています。GitLFSのような外付けシステムを必要としません。
クライアントは必要なデータをリモートサーバに問い合わせるだけでよく、ローカルに差分を持つ必要がありません。
ファイルの編集を中央でロックすることができます。特に、Unityが自動生成するファイル群は壊れやすくコンフリクトが発生したときに手動マージが難しいため、このロック機能は役立ちます。
技術的には、ゲーム開発の要件に対しよりマッチしているのは、UVCSといって問題ないかと思います。
番外：perforce(Helix Core)
商用の、大規模ゲーム開発に向けられたバージョンコントロールシステムです。UVCSと同じ中央集権型のサーバとなっていて、アセットファイルを管理するのに優れています。
ただし、公式に値段も書いていないという敷居の高さから、インディ―ゲームプロジェクトで採用するのは困難です。
ぶっちゃけどう？ UVCS
さて、ここまでの内容だと、このGitユーザ向けに出しているUVCSの宣伝文を読めばOK以上の情報量がありません。
ゲーム開発をやるなら中央集権型のVCSのほうがいいよね、というのはエンジニアがちょっと調べればわかる程度の自明事項であって、皆さんが聞きたいのはよりぶっちゃけた話ですよね？ 本当に決めてになったのはどこか。実際に使ってみてどうだったか。あるいは実際使ってみて全然いけてないのはどういう点なのか。
ぶっちゃけた採用理由①謹製の安心感
第一に、Unity謹製という安心感があります。Unityが自分で面倒を見ているので、UVCSのレールに乗っている限りは動作が保証されており、作業手順も最適化されています。Gitの場合には、Unityはあくまでサポートされている、という程度のことであって、機能の追従や動作はあくまでコミュニティベースです。動作の保証はありません。また、管理する対象のUnityも、実際巨大なブラックボックスであって時折予想もつかない出力を返します。課題は常に発生しえ、それに対してそれがGitツールチェインで解決可能であるとしても特殊なナレッジがいつでも必要になります。
大きい会社内で開発するぶんには、何かVCSでトラブルがあっても社内の専任スタッフに聞いたり同僚・先輩に相談したりすれば何とかなる、最悪自分が解決しなくても専門知識を持った人がサードパーティのコードを読んで解決してくれるという安心感があります。一方、少人数で開発するインディ―ゲームでは、チーム内にそれほどの技術リソースがないケースが圧倒的に多いと思います。
Unityのブラックボックス的挙動を分析し、それをGit側でどう吸収するかを一つ一つ検討解決していくのは、時間とメンタルの無駄遣いだと考えました。というわけで、僕は”レールに乗る”選択をしました。これが、正直に言ってUVCSを採用した一番大きな理由です。
ぶっちゃけた採用理由②非エンジニアに本当に優しい
中央集権型である、という仕組みは、非エンジニア向けの開発フローを整えるという点で非常に有利に働いていると感じます。なぜなら、リモート／ローカルという概念を考える必要がないので、登場人物が一人減っているからです。
この登場人物が一人減った効果が、GUIツールのわかりやすさにつながっていると感じられます。UVCSのGUIツールDevOps Version Controlはブランチを切る、コミットを積む、マージするという基本機能によく絞って作られており、あらゆる用途に対応しているためゴテゴテしたGitHub Desktopよりずっと快適です。
おかげで、非エンジニアにこのツールを紹介するときも、違和感なく展開が可能でした。メンバーのリテラシーの高さということもあると思いますが、本当に助かったことでした。
ぶっちゃけたマイナス点：Unity Cloudが枯れてない
UVCSを使用すると、同時にUnity CloudというGitHub likeなサイトにつないでリポジトリ管理することになりますが、本家GitHubと比較して、非常に使いにくいです。どんなふうに使いにくいかというと、まだ始まったばかりのプロジェクトなのであまり洗練されておらず、かゆいところに手が届かない状態になってしまっています。
PRを効率的に作成するための各機能が乏しい。（開発不足に起因する問題）
画像をアップロードできない。（PRやコメントにスクリーンショットを添付したいのにできない）
コメントが勝手に折りたたまれる。
何ならＰＲ本文も勝手に折りたたまれる。
CI/CD機能が貧弱。GitHub Actionsのように周辺ツールチェインが揃っていない。
画面構成が悪い。(フロントエンドのデザイナーやＰＭの問題）
GitHubが常に１カラムなシンプルな構成なのに対し、平気でデフォルト3カラムで表示してくる。しかもただ文字が並ぶだけ、みたいなことが平気である。
情報構造の並べ方がGitHubと全く異なる。Organization、Repositoryごとの設定の管理やDevOpsとの接続が整理されていない印象を受ける。
Unityはアセット権利の問題があるため、このように複雑な仕組みをサーバサイド実装せざるをえないと考えられる。権限管理は圧倒的にGitHubのほうが楽。
CI/CD機能であるUnity DevOpsもとても使いにくいです。
コミット時のテスト、ビルド、リリースなどをymlに書いて管理できない。すべてぽちぽち。
CircleCIのようにドキュメントが充実しておらず、エコシステムが貧弱。特に、Dockerエコシステムの恩恵を受けられないのが非常に痛い。
単純に、遅くて貧弱。（特にMacビルドは価格も高く、使い物にならないと思います）
sshしてデバッグできない。
中央集権的システムかどうか、非エンジニア目線で使いやすいか、perforceに比べて安く提供できるかというところプロダクトの焦点があり、開発者の体験向上はUnity社のプライオリティとして高くないのだろう、と察せます。GitHub + GitHubActionsなどに慣れていたエンジニアにとっては、ややフラストレーションの溜まる環境であることは間違いないです。
結論：インディー開発者の明日はどっちだ
結論としては、僕のように少数のプログラマとそれ以外のメンバーで構成されるチームでインディ―ゲームを制作するには、UVCSを選択するのがベターだと思います。
開発者経験（DX）で、UVCSが劣ることは間違いないです。エンジニアの心情として、使い慣れたGitを手放したくもないでしょう。しかし、Unity純正であり動作が保証されているという安心感と、チームメンバーに対する展開が楽であるという2点のメリットは、DXを引き換えにして余りあると考えます。
しかしそんなエンジニアにも頼れる相談相手がいます。それはAIです。GitHub Copilot、およびChatGPTはUVCSおよびその前身Plastic SCMのコミュニティノート（英語）を大量に学習しており、かなり正確なヒントを提供してくれます。日本語ではPlasticSCM/UVCSの情報を手に入れることは難しく、また海外フォーラムを見に行くにしても限界があるので、言語の壁をいとも簡単に超えられるChatGPTの存在は神のようにありがたいと思いました。
開発メンバー募集のお知らせ
現在、『アイリス・オデッセイ』を一緒に作っていただけるUnityエンジニアの方を募集しております。
当面は、作成したAdobeXDのモックアップを元に、UnityエディターでUIを作成する作業をお願いできればと思います！（要Unityチーム開発歴1年程度）
副業大歓迎で、時給2000円から（経験により応相談）、時間などの都合は最大限配慮させていただきます！
小規模なインディ―ゲーム開発プロジェクトということもあり、全然気軽な感じで声かけていただいて構いませんので、ご興味ある方は上記サイトから連絡いただけますと幸いです！！
次回予告
来月の更新は、開発体制の話をしようと思います。インディ―ゲーム開発には、どのようなアプリがよさそう？ 何のＳａａＳを契約する必要があったか、あるいはなかったか、今度は開発マネージャ・エンジニア以外の方にも楽しめる記事にする予定です！
twitterフォローもお願いします！
それでは、次回をお楽しみに！