＜デザイナも参加できる「Unity・Project/Git（Sourcetree）」の運用方法を考える＞
【はじめに】
こんにちは。
Unityでプロジェクトを運用する際に、デザイナがどんな風に参加してるでしょうか？
正直、Unityへのデザインデータ（アセット）インポートやgit関連の操作って、デザイナさんは苦手なところなのでは無いでしょうか？
僕も苦手です
でも、操作できた方が良いところもありますよね
なぜデザイナもUnityやgitの操作ができた方が良いのか？
これ、根本的な議論の出発点があります
Unityへのインポートや、gitの操作を覚えても、デザインの能力は、何一つ向上しません！
ここは言い切れます。Unityやgitの操作ができても、デザイン関連の個人スキルは何一つ上達しません！（残念ですがw）
じゃぁ、なぜやるのか？
Unityを使って「ゲームを作ることが上手く（効率よく）なる」からです
デザイナから見た場合、この一言に尽きると思います
なので、ここからはゲーム作りに興味がない方は読まなくても大丈夫です
ここから先は「デザイナでもゲーム作りが上手になる」一つの方法になります
【Unityの準備】
＜Unityにはルールがある＞
デザイナがUnityを、不勉強なままプロジェクトを操作すると、まぁ大体、事故りますw
そしてプログラマに怒られます！
なので、まずは、デザイナがUnityのプロジェクトを操作する場合、UnityにはProjectを操作するための一定の「ルールがある」という事を知ってください。
「Unityにはルールがある」…コレだけ知っていれば良いです！
その上で、安全で効率的なProjectの運用方法を以下で説明したいと思います
＜Unity・project内のフォルダ構成＞
①Projectの初期条件
UnityはProjectを作ると、必ず［Asset］フォルダが用意されます
そして、デザインデータの保存先として
［Assets/DataAssets］もしくは、［Assets/AssetBundle］
と言うフォルダ構成が必要になります
（※今回は［Asset/DataAssets］として解説します）
ここまでは、Unityのルールです
②Designフォルダを作る
［Assets/DataAsset］の下に［Design］フォルダを作ります
［Assets/DataAsset/Design］とします
（※なせ［Design］とするのか？以下で説明します！）
③Designフォルダの運用ルール
ココ重要です！
そして【デザイナは、この【［Design］フォルダ以下しか操作しない！】と言うルールにします。
このルールで「デザイナが作ったデータは、この［Design］フォルダ以下に全部入っている」と言う状態を作ります。
そして、この［Design］フォルダ外にデータを置いた場合「無断で消されて文句を言えない」と言うルールも追加してください
多分、コレだけでプログラマの心配事は、かなり解消されるハズです！
もう、今日はコレだけ覚えてもらうだけでも良いくらいですw
（※［Design］とフォルダ名にするのか？＝デザイナが「そこだけ見れば良い」と言うルールをわかりやすく提示できると思うんです）
＜Designフォルダ以下のフォルダ構成＞
では［Design］フォルダ以下をどうするのか？
少しずつ解説して行きます。
それほどフォルダ階層の説明はいらないなぁと思われた方は、
目次から＜まとめ＞あたりへ飛んでいただけると、良いかと思います
では、まずは、1階層下です。
＜1階層目＞
■Assets
∟■DataAssts
∟■Design
∟■BG
∟■Characters
∟■Effects
∟■UI
∟■Scenes
∟■TestDesign
（※■はフォルダを表します）
ざっくりと、こんか感じでしょうか？
■BG
背景（2D/3D）データを入れます
■Characters
キャラクター（2D/3D）データを入れます
（※アイテム（Item）や小道具（Prop）なども、キャラ扱いする場合は、このフォルダの下に用意するようにします）
■Effects
キャラ、背景、UI、など全てのエフェクトを、この下に用意します
■UI
UIデータを入れます
■Scenes
ココは特殊です
このSceneフォルダは、デザイナが使用する、キャラのルックスチェク用シーンや、エフェクトの確認用のシーンを入れておくフォルダです
このフォルダ内のシーンは、実際にゲームで使われるシーンではありません
■TestDesign
ココも特殊です
実装前にデザイナがテスト用に作ったデータなどを入れておくフォルダです
実際にゲームでは使用しないデータを入れておくことが前提となります
このフォルダの運用は「いつ削除されても文句を言わない」ルールが適用することを推奨します
最終的にはゴミデータとなってしまうからです
＜1階層目［■BG］フォルダ以下＞
BGフォルダ以下では、背景関連のデータをまとめておくようにしています
一旦、以下のようにまとめてみました
■Assets
∟■DataAssts
∟■Design
∟■BG（背景関連のデータを管理するフォルダ）
∟■3D（ここ以下は３Dモデル）
∟■Common（ゲーム全般で共通で使用する背景モデル）
∟■Terrain（ここ以下は地形関連のモデル）
∟■Ground（地面）
∟■Plants（植物）
∟■Building（人工建造物）
∟■Prop（小道具など）
∟■2D（ここ以下は２D画像）
∟■Common（オプションやシステム周りで使う背景画像）
∟■Title（タイトル画面の背景画像）
∟■Talk（2Dアドベンチャーパート背景画像）
３Dデータの場合、ファイルの種類が複数あると思うので、それぞれに、定型の形でデータ管理した方が、わかりやすくなります。
例として「Ground」を以下に書いてみます
∟■Ground（地面）
∟■BgG［（ID番号xxx）］
∟■Aniamtions
∟■Materials
∟■Mesies
∟■Textures
∟■Prefabs
■BgG［（ID番号xxx）］ですが、これは、地面の種類によってID番号で管理される事を想定しています
ID番号ごとに（Animations/Materials/Meshies/Textures/Prefabs）のフォルダを用意しておく事をルールとしておくと、時間が経ってから修正する場合でも、ある程度わかりやすくなっているのではないかと思います
＜1階層目［■Character］フォルダ以下＞
以下のような感じになるでしょうか？
ここでも3D/2Dのデータを分けて管理しています
■Assets
∟■DataAssts
∟■Design
∟■Character
∟■3D
∟■Player
∟■Enemies
∟■NPC
∟■2D
∟■Player
∟■Enemies
∟■NPC
3Dデータの場合、それぞれID番号で管理すると思うので、それ以下のフォルダ構成は以下のようにして、BGのフォルダ構成と合わせていくのが良いと思います
∟■3D
∟■Player
∟■P［（ID番号xxx）］
∟■Aniamtions
∟■Materials
∟■Mesies
∟■Textures
∟■Prefabs
２Dの場合は、表情差分やLive2Dのような動くデータを用意するのかで、若干変わりますが、１キャラ１枚程度で用意する場合は、Players/Enemies…の下にキャラID番号ごとのフォルダを作る必要はないでしょう
∟■2D
∟■Player
∟■P［（ID番号xxx）］（Live2D/Spineなどのデータがある場合）
＜1階層目［■Effects］フォルダ以下＞
エフェクトは、３D空間・3Dモデルに合わせて表示する事を想定しています
［Eff］の後ろに［C/P/E/UI］と喪jを追加することで、種類別の名称としています
・EffC＝Common
・EffP=PLayerCharacter
・EffE＝Eenemy
・EffUI＝UI系（主に2Dエフェクト）
とかにしておくと、分かり易いかと思います
∟■Effect
∟■Common
∟■EffC［EffectID番号xxx］
…
∟■Players
∟■EffP［CharactoerID番号xxx］［EffectID番号xxx］
例）EffP001003
…
∟■Enemies
∟■EffE［CharactoerID番号xxx］［EffectID番号xxx］
例）EffE001003
…
∟■UI
∟■EffUI［EffectID番号xxx］
…
＜1階層目［■UI］フォルダ以下＞
UIに関しては、
①：Commonで共通アセットを管理して…
②：その他は各シーンごとに、そのシーンでしか使わないデザイン素材を管理する
ような形にすると、わかりやすいのでは無いか？と思います
■Assets
∟■DataAssts
∟■Design
∟■UI
∟■Common
∟■System（補足①）
∟■Icons
∟■Sys（補足②）
∟■IItems
∟■Thumbnails
∟■Players
∟■Enemies
∟■NPC
∟■Title（タイトル）
∟■PlayerRegistration（プレイヤー登録）
∟■CharaCreate（キャラクリエイト）
…
（①）UI/Common/System
（※ボタン類/スライドバー/ダイアログウインドウ/テキストウインドウ…など）を入れておきます
（補足②）UI/Icons/Sys
（※メニュー周りのアイコン類）を入れます
＜まとめ＞
ここまでの内容をまとめると、以下のような６項目になるかと思います
チームやプロジェクトごとに細かい違いはあると思いますが、デザイナが触れる領域を決めておくことが、事故らないプロジェクト運営につながると思います
①デザイナは「Unityにはルールがある」って覚えておく
②デザイナは［Design］フォルダ以下のみ操作できる
③デザイナは［Design］以下のフォルダ階層をプログラマと相談して管理する
④デザイナは［Design］意外にデータを用意した場合、削除されても文句を言わない
⑤デザイナは［Design/TestDesign］フォルダを削除されても文句を言わない
⑥デザイナはデザインアセット（データ）のID管理を意識する！
【デザイナが（git/SourceTree）を使う】
さて、ここまでで、デザイナがUnityのProjectを扱うためのルールとProject内の環境（フォルダ構成）を用意してきました
これで、Project内で事故が起きても、ある程度、デザインデータを絞り込めるようになっています
その上で、作ったデータをデザイナ自身がgitに上げられるようになると、かなり効率化が計れます
また、逐一プログラマに頼まずに済むので、チームへのタイムラグが生じにくくなります
しかし、デザイナがgitのコマンドラインを使いこなすのは、流石にハードルが高いですよね？
そうした中、僕の所属しているチームでは「SourcetTree」を使っています
多分「SouceTree」の方が、コマンドラインより、まだわかりやすいと思います
（まぁ、それでもデザイナの拒否反応や苦手意識は出ると思いますが…w）
僕自身、実際に面倒だと感じますw
とはいえ、少人数でゲーム開発を行う上で、デザイナがココの作業ができれば、本当に良いことだとも感じています
最初は全然わからないでしょうから「SouceTree」の環境設定など、この辺りはプログラマにお願いした方が無難でしょうw
その上で…
①デザイナごとのブランチを管理者に用意してもらう
②各デザイナが、Mainのブランチと自分のブランチの切り替え方法を覚える
③各デザイナが、MainのブランチのPullを覚える
④各デザイナが、自分のブランチにMainのブランチをMergeすること覚える
⑤自分のブランチのCommit/Pushを覚える
⑥トラブった時（主に衝突など）の相談窓口をプログラマチーム（管理者）に用意してもらう
以上の６項目を各デザイナとチームが出来るようになれば、チームの効率化は、徐々に測れるハズです。
実際にデザイナが日常的に行うのは②③④⑤の４項目だけです！
（※慣れるまでは、トラブルが続くと思いますが、半年後、１年後、ぐらいのスパンで考えていただけると、デザイナは安心しますw）
SourceTreeを導入することで、デザイナは「gitを使う」と言うよりは、「SourcetTreeでプロジェクトを管理している」と言う感覚が強くになると思います
結構、この差がデザイナには大きいと思います
＜余談ですが…＞
この②③④⑤が一通りできるようになったらテレワークをOKにするなどの基準にしても良いかもしれません
また、僕のチームでは、gitHubを利用していますが、今回は、gitとgithubの説明は端折ります
僕の理解度でうまく説明できないと思うので…
m(_ _)m
＜余談ですが…その２＞
gitやSourceTreeの機能で、実は、他にも色々機能があると思います。
ファイルを無視したり、衝突時の回避方法だったり…
作業によってブランチを増やしたり…
でも、これをデザイナ全員に操作させるのは危険だと思ってしまいますw
なぜなら、その先でトラブった時に、デザイナ自身が正しい説明をできない場合が多いと思うからです。
トラブル解消のために、色々な人が余計に時間が取られかねない…
git/SourceTreeの操作については、まずはデザイナが必要最低限な操作のみ、覚えるところから出来たら良いのでは無いかなぁ？と思う次第です
＜余談ですが…その３＞
プログラマからしたら、デザイナがgitやSourceTreeを覚えられないのが、理解できないかもしれません。
想像してください、デザイナがPhotoshopとDccツールを使いこなしているのを…
それをプログラマが、数日で理解しろって言われているとしたら？
まぁ、素人同然ですよね？
メニューの位置や、意味がわからないですよね？
何年経っても、プロにはならないですよね？
gitやSourceTreeってデザイナから見たら、そんな感じなんですw
大きな心で、対応していただけると、とても嬉しいのであります
m(_ _)m
【そのほかのルール】
＜PSDはgitに上げるのはNGにする＞
PSDってファイルサイズが大きくなりがちですよね？
FullHD（1920x1080px）だと１レイヤー増えるごとに、約1Mずつファイルサイズが大きくなります
これをUnityProjectに入れてしまうと、他の人のローカル環境も圧迫します
まぁ、落とさないように設定すれば良いと思うのですが…
まぁ、言うて、同じPSDを開く人って、担当デザイナと監督者の二人ってパターンが多いのでは無いでしょうか？
もしくは、キャラ・背景・エフェクト・UI、それぞれのチームごとに、テクスチャの一部を修正して、バリエーションを増やすとか？
さして、頻繁に起こることでは無いと思うんです
ですから、PSDデータは、UnityのProjectに含めるのではなく、GoogleDriveやNUSを利用する事を考えても良いと思います
＜Prefabの管理ルール＞
Prefabの管理ルールについては、僕のチーム環境では、以下の2種類あります
①デザイナ間でのやり取り
②デザイナ/プログラマでのやり取り
①Prefabの管理ルール：デザイナ間でのやり取り
ここでは、作業担当者と管理者のやり取りを想定しています
この場合、もうDCCツールでのやり取りはしていません
担当者は、Unityに全てのデータをインポートして、出来る限りPrefab化した状態で監督者へ提出することにしています
これは、外の協力会社さんにも同じようにやてもらいます
Prefab状態で監修することによって、最終的なmaterialとShaderが適用された状態で、ルックスの確認ができるのが、最大の利点です
UnityPackageにして、Prefabごとに、まとめてデータを外に出しやすいのも扱いやすくなります
納品時には、UnityPackageにできたりもしますしね
また、チームに相談して、チェック用のシーンやスクリプトを用意してもらいやすいと言う事もあります
とにかく、脱DCCツールとしています
gitを使う上でも、UnityのProjectに入っているデータが最終のものと言うことで、DCCツールを介さないデータ管理がしやすくなると思います
②Prefabの管理ルール：デザイナ/プログラマでのやり取り
・データの引き継ぎ
ある程度、デザイナ側での監修が終わったところで、Prefabをプログラマに引き継ぐタイミングがあると思います
僕の所属しているチームは、プログラマに引き継ぐ時は…
①管理シートやレッドマインで、引き継ぎの状態にする
②チャット（記録用）で伝える
③口頭で伝える
この３つで、引き継ぎもれを起こさないようにしています
それでも、担当のプログラマが忙しいと、忘れられがちですが…w
・データを引き継いだ後に、デザイナがPrefabの作業をする場合
そしてプログラマに引き継いだ後は…
①基本的には、デザイナはPrefabデータを変更しない
②デザイナがPrefabデータを変更する場合は担当プログラマに確認する
③Mesh・Texture・AnimationClipの上書き・更新は、担当プログラマに確認しなくて良い（報告は必要）
（※多分、この辺りのデータはプログラマが直接扱わないと思われるので、上書きはOKとしています）
④データの名称を変えるときは、担当プログラマに絶対相談する！
⑤作業が終了してgitに上げたら連絡する
以上のように、確認と報告のルールを決めています
これは、gitでデータの衝突を起こさないようにするための作業になります
【最後に】
最後まで読んでいただきありがとうございます
ここまで書いた内容は、あくまでも僕のローカルな環境のルールです
デザイナ専属のプログラマを必要としないチームとして決めてきたルールではあるので、単独のデザイナでも運用できる最低限なところを詰め込んでいるように思います
（もしかしたら、がっつりTAさんがいるような環境だと、もっとやれてるのかもしれませんが…）
やはり、Prefabの管理、gitの運用は、デザイナが興味を持てない、難しい部分です
ですが、やはりデザイナがUnityを扱えて、gitでデータ管理ができるチームは、より高度なゲームエンジンの使い方が出来るようになるのではないか？と思っています
もしかしたら、今時はAIエージェントの導入で、もっと楽になるのかもしれませんが、自分達の扱うデータや環境を、ひとつずつ理解しながら作ると言う事は、決して無駄にならないと思います
より、上流レイヤーでのお仕事を目指す方は、一度トライしてみてはどうでしょうか？
