こんにちは、
クラスター株式会社でテクニカルアーティストをしているacchiです。
この記事では入社して半年が経過した元ゲーム企業勤めのテクニカルアーティスト(以下、TA)の目線から、メタバース企業でのTAのお仕事とは何か、また、cluster上で絶賛稼働中のプロダクト「AvatarMaker」の運用に関わっていくなかで何をやったかについて、実例をもとにお話させて頂きます。
そもそも: TAとは
デザイナーやエンジニアという職業を知っているようなIT界隈の人でもTAのことは知らない事が多く、なんならクラスター社内の人にも「TAって何ですか？」と聞かれ、説明が必要になることも少なくありません。
そんなTAを表現するための常套句として
「デザイナーとエンジニアの橋渡し」というものがあります。
自分なりの言葉に直すと「デザイナーとエンジニアのコミュニケーションを円滑にするための通訳係」といった具合でしょうか。
TAは主にゲーム業界やCG制作の現場で活動していることが多い職種です。
デザイナーとエンジニアの両方のスキルを持ち合わせたハイブリット、というとまるでスーパーマンのような印象を受けますが、実態はDCCツールやゲームエンジンの仕組みに詳しいデザイナーや、シェーダーを書いてアートな部分を強化できるエンジニアなど、アートとエンジニアリングの両方の”ごく一部”の領域に跨って仕事をしている器用な人のことをそう呼ぶことが多いようです。
※稀にアートもエンジニアリングも秀でた真のスーパーマンも存在します。そんな方は是非クラスターへ！
今でこそワード検索で沢山の記事がヒットするようになりましたが、一昔前（2015年頃？）まではネット上でもあまり見かけず、転職支援サービスでも殆ど取り扱いが無かったような、つい最近になって認知されるようになってきた新しい職業でもあります。
クラスターでのTAのおしごと
TAはゲーム会社やCG業界に多いという話をしましたが、業界は違えどCGを扱うことの多いクラスターにも高い親和性があると感じています。
クラスターではこの半年間でTAとして大きく分けて2つのことをやってきました。
- ルール整備
- パイプラインの構築
1. ルール整備
具体的には「プロジェクト(フォルダ)の構成」と「命名規則」です。
クラスターでなぜ整備できていなかったかについては純粋にリソース不足で手が回っていなかったというよくある(?)話なので割愛するとして、例えリソースに問題が無かったとしてもこのあたりのルールを上手く決められないケースはしばしばあるのではないでしょうか？
そうなっている場合いくつかの理由が考えられますが、その中の一つに
「デザイナー・エンジニア間でコミュニケーションが取れていない」ということが挙げられます。
ルールを決める際、
データのカテゴリはどの程度あるか？将来そのデータはどの程度増えるのか？バリエーションは存在するのか？
など、フォルダ構成・命名規則いずれにしても様々な条件から複合的に検討する必要があります。
大抵の場合、デザイナーはこういった作業が苦手でエンジニアは得意な傾向があるのですが、エンジニアに任せすぎるとデザイナー視点の使い心地まで考慮されていなかったり、逆にデザイナーが独断で決定してしまった場合には本来想定しておかなければならなかった条件が抜けていて満足に実装できないというケースもあります。
そうした悲劇を防ぐためにもデザイナーとエンジニアの双方でコミュニケーションを取ることが重要ですが、お互いに普段扱っている技術や言葉に違いがあるため、円滑に事を運ぶためにはお互いにそれなりの経験値が求められます。
そこで、TAが間に入ることで
お互いの技術や言葉を上手く翻訳する「通訳係」として機能したり、
次に紹介する「パイプラインの構築」に関連付けてルールを提案することもできます。
私の場合もパイプラインを意識してアセットを管理するプロジェクトの構成から、これから作るものとclusterに既にアップロードされているもの全てを対象に命名規則を整備し、マイグレーション的な作業と新規のアセット実装を同時進行で行いました。（大変でした）
2. パイプラインの構築
ここでいうパイプラインとは、
①DCCツールで制作したアセットを
②ゲームエンジンに実装し
③最終的なプロダクトにアップロードする
までの一連の流れを指します。
TAがパイプラインを構築する意味合いとしては感覚的な話になってしまいますが「デザイナーの使い心地を考慮できる」点と、
「そのままアウトプットできる」点にあると思っています。
（要は都合が良いという話です）
ここではAvatarMakerでの実例を元に、パイプラインを整備する前後で
ワークフローがどのように変わったかを簡単に紹介します。
早速ですがbefore/afterのイメージをご覧ください。
before
ワークフロー
- デザイナーが制作したアセットデータをエンジニアにチャットツール(slack)で直接受け渡す
- エンジニアがslackでアセットデータを拾う
- エンジニアが受け取ったデータをDCCツールで書き出す
- エンジニアがゲームエンジン(Unity)にインポート & セットアップ & バージョン管理(Git)
- エンジニアがclusterにアップロード
課題点
- デザイナーがバージョン管理システム･ゲームエンジンを使えていないため、結果としてエンジニアの負担が大きい
after
ワークフロー
- デザイナーが制作したアセットデータをエクスポートツールを介して自動でUnityに直接インポート※バリデーションツールも用意し、データチェックも自動化
- デザイナーがUnityにインポートしたアセットデータをツールで自動セットアップ
- デザイナーがGitでTAにPRを提出
※デザイナーがGitを扱いやすいようにGitHubDesktopを導入&マニュアル作成した - TAがUnity上でデータ確認し、問題なければmasterにマージ
- TAがclusterにアップロード
beforeからの改善点
- デザイナーがデータ出力・セットアップ・バージョン管理まで一貫して行えるようになった
- TAは簡単なデータチェックを行い、アップロードするだけでよくなった
パイプライン構築のまとめ
旧パイプラインではデザイナー(複数名)の責務がデータ制作のみでそれ以降の工程が全てエンジニアが担うことになっており、エンジニアの負担割合が非常に大きくなっていました。
一方新パイプラインでは、デザイナーがツールのサポートによって負担が少ない形で自身で制作したデータを出力→実装→バージョン管理まで一貫して行えるようになりました。
その結果としてTA(旧エンジニアポジション)は簡単なデータ確認とアップロードするだけのような体制になりました。
また、時間のかかる工程をルール整備していたおかげで自動化が可能になったため、ヒューマンエラーの防止や工数削減のような効果も得られました。
今後の展望としてはこのパイプラインを更に発展させ、デザイナーがTAの手を介さなくても単独で開発環境へのアップロードまで行えるようにブラッシュアップしていく予定です。
おわりに
この記事で紹介した事例はクラスター社におけるTAの仕事のほんの一部に過ぎませんが、なんとなくTAがどのような職業なのかイメージが付きましたでしょうか。
私個人としてTAの本質は「課題解決」だと思っています。
例えば「プログラムを組める」はTAにとって強力な武器ですがそれはあくまで「手段」でしかなくて、その先にある「目的(課題解決)」をどうクリアしていくかというのを考えるのが最も重要な責務だと思っています。
また、メタバース業界と聞くとまだまだ得体のしれない業界のように感じる人も多いかもしれませんが、少なくともCGの分野であればゲーム会社やCG業界と扱う技術や抱えている課題にほとんど差はないので、親近感を覚えていただけたなら幸いです。
積極採用中！
ということでクラスター株式会社ではCGデザイナーとして一緒に戦ってくれる仲間や、それ以外にも様々な業種の方を積極採用中です！
興味が沸いた方は是非エントリーをお願いします！
