TAチームの起動と軌跡

2022.02.22

こんにちは、アプリボットでチーフテクニカルアーティストをやっている堀井です。

今回はプロジェクトに拘らない記事の執筆機会をいただきましたので、
アプリボットのテクニカルアーティスト（以降TA）チームについて書かせていただきます。

TAとは？

TAとは、3DCG業界で一般的に理解されている範囲だと

プログラマとアーティストの思考の違いを理解して橋渡しをする人または職業
テクニカルディレクターと呼ぶ会社もあり、プロジェクトの利用技術向上に導く人、
或いは新技術研究を行い反映する人または職業
（※１）DCC(Digital Content Creation)ツールやゲームエンジンがあればそのアプリケーション等の作業効率化、最適化、ときにワークフローの提案を行う人また職業

※１）DCCツールとはアーティストがアセット制作に利用するツールのこと

このように認知されているかと思います。

その業務範囲は幅広く、３Dアーティストがモデラー、アニメーター、エフェクトアーティストとわかれているように、TAもリガー、VFXアーティスト、アニメーションプログラマ、パイプラインツールエンジニアやグラフィクスエンジニアと専門分野の中で存在するほどです。

TAとして初めから会社に属する人も昨今は増えているようですが、エンジニア出身からなるルートや、アーティストがプログラミング技術やエンジンやツールを用いてテクニカルな知識を身に着けたあとからなるルートなど様々なキャリアがあるかと思います。

ただ、いまのところ確立されたキャリアはないように思います。
この職種の重要性や難易度を理解した上で、あるいは気が付けばTAになっている人も多いのではないでしょうか。

私自身も元は３Dアニメーター出身で社内の業務効率化の必要性を感じMayaとMotionBuilderのツール開発をしたことや、開発初期のルックデブのおり、シェーダー等を開発したことをきっかけにテクニカルアーティストへ転向しました。

社内におけるTAの課題

私が入社したころのアプリボットにはTAがプロジェクトごとに１名～数名、
またはいないこともありました。

そして組織的に動くような体制ではなく主だった業務と兼任しているため、
TA業務を主業務としてこなすということが難しい状況でした。

そんな中、業界的にもアセットのクオリティに対する要求水準の上昇は目まぐるしく、
TAの担う仕事は増加の一途をたどっています。
当然弊社にもTAの需要が増していました。

とはいえTAを育てる環境もなく、外に目も向けてもなかなか居ません。
TAのいないプロジェクトをどう補うのか？
業務を兼任している状況で他のプロジェクトへはどうアプローチしたらいいのか？
このことは大きな課題でした。

TAチームの結成

このような課題を解決するにはプロジェクトをまたいで業務を行えないといけない。
そう考えた私はプロジェクトの外にチームを作るという発想に至りました。

半年をかけてこつこつロードマップを上長に共有したり、
同じ思想やこの業務に興味のある人に地道に声をかけたり。
自らの担当職業名をテクニカルアーティストとして表示してもらい、存在をアピールもしました。

そして出来上がったのがTAチームです。
一応名前もあり「YojiGen」というチーム名を全員意見一致の上でつけています。

チーム名をつけたりするのは弊社の文化でもありますが、
ツールやモジュール名等につけておくことで「このツール名ならあそこがつくったのか」と
ブランディング効果も期待できます。

構成員は現在は数名ですが、全員がデザイナー出身のチームです。

（アニメーション、エフェクト、背景分野の出身者で構成されています）

TAの価値と評価

TAには前段でご紹介した通りテクニカルディレクションとワークフロー等最適化の2側面あると思われますが、今回の内容はそのうちワークフロー等最適化に関しての成果定量化について記載します。

チームと一概にいっても組織であることに変わりはありません。
チームメンバーのスキル把握やタスク管理、また成長促進のための技術研究の開催など、
マネジメントを含めたチームビルディングを発足前から計画していました。

ただひとつ、組織としておそらくですが業界他社とあり方が異なるのは、
TAメンバーの上長がTAリーダー（チーフ）ではないということでしょう。

実際に私を含めたメンバーは特定のプロジェクトに属しており、
主業務をこなしつつTA業務をこなすスタイルのため上長は主業務のプロジェクト内に存在しています。

なのでTAチームの成果に対する評価が自分からメンバー各自の上長とすり合わせを行わないと
可視化しにくい状態になります。

とはいえすり合わせを行うにしても、各分野の専門的な内容になるため
成果の価値などを上長側が判断しにくい状況がありました。

具体的には

デザイナーまたはマネージャー（上長）がコードをみてもスキルを判断できない。
ツールなどを利用するのは別のプロジェクトのデザイナーであったりするので、
効果がどの程度であったのかなどを上長が把握することが難しい。

そこで毎半期の目標設定を数値化できるものにし、この目標に対する達成度と成果を
社内のクリエイターが参加する場で可視化して発表して評価をもらう形にしています。

例を提示します。

ある年度の削減工数目標：100人日　に対して、
実際は500.90人日削減に成功。達成率は500％を超えました。

この数値は実際に依頼・相談者側へ削減工数などをヒアリングして提供してもらうことで、
事実との乖離を防いでいます。

「あのチーム一部では人気だけど、実際なにしてどんなことで活躍してるの？」
と関りがない人にTAの必要性を問われる場面があるのを前職で経験していたので、
まるで社内の決算発表のようですが我々の活動が会社の利益になることが明示できるために、
この形を採用しています。

自分たちに出来ることをやる

スマートフォンゲームアプリにおいても膨大なアセット数になりつつある昨今では、
アセット管理が非常に大きな問題になってきました。

兼ねてよりこの問題に直面していた大規模開発においては、DCCツールなどと連携してプレビュー機能やタスク管理機能がついたクラウドベースのソリューションの導入を行うこともあるかと思います。

弊社ではいまのところDCCツールの中だけで見た目が完成しないことが多く、
下流工程のUnity上での組み込み、編集作業の後ようやく完成します。

とくにエフェクトにおいてはほとんど最後までUnity内部のパーティクルシステム(Shuriken)を利用してアセット制作を行っており、アセット管理はUnity上で行う必要がでてきます。

数が多くなると下記のような問題が発生しました。

エフェクトアーティストがチームで作成するときに他人のものまで見きれず、
同じような素材をいくつも作ってしまった。
企画が同じような見た目のエフェクトをアーティストへいくつも依頼してしまった。
作成したエフェクトがどんな見た目のものなのかスプレッドシートなどでリスト管理しても、
文字や静止画が限界で動きがわからず他職の人とのやりとりで時間を取られることが増えた。

弊社ではこの問題に対してYojiGenチームの一人がこの問題に直面したとき、
Webデザイナー/クライアント出身だった彼はAWSを使ってクラウドベースのアセット動画管理やWebサイト上でその動画のプレビュー機能が利用できるシステムを構築しアーティストとそれ以外の人とのやり取り上の問題を解決しました。

※AWS = アマゾンウェブサービス
https://aws.amazon.com/jp/what-is-aws/?nc1=f_cc