TA人口は徐々に増えているが、中小規模タイトルでは手薄
C：少し脱線しますが「エンジニア寄りのTA」と「アーティスト寄りのTA」のちがいを説明していただけますか？
沼上：エンジニア寄りのTAはプログラマーやエンジニア出身者が多く、各種技術に精通しており、プログラム制作やツール開発、パイプライン構築を得意としています。一方でアーティスト寄りのTAはアーティスト出身者が多く、アートの基本的な技能をもち、アーティストのワークフローを熟知しているので、アーティストにとって使いやすいツールや、無理のないデータの制作方法を提案できます。実際にはかなりオーバーラップしているので、明確に区別できない場合も多いです。
C：テクニカルを起点にアートの理解も深めていった人か、アートを起点にテクニカルの理解も深めていった人かのちがいだけで、目指す役割は同じといったところでしょうか。
麓：そんな感じだと思います。エンジニア寄りのTAでもアーティストのワークフローに精通している人はいますし、アーティスト寄りのTAでもスクリプトはもちろんC++まで書ける人はいます。例えば、私の所属する「開発サポート部」は7人のツールプログラマーと、3人のアーティスト寄りのTAで構成されています。社内の多くの家庭用ゲームのプロジェクトで使われているHNDという中間ファイルフォーマットを開発・運用しており、このフォーマットを中心としたパイプラインを、各プロジェクトの状況に合わせてカスタマイズしたりもしています。
▲HNDViewer（セガの内製ツール）の画面。「HNDは、3D関連のDCCツールからエクスポートしたデータを格納するための中間ファイルフォーマットです。HNDViewerは、HNDファイル内の3Dデータを表示するビューアで、ポリゴンやノードのパラメーターの一覧、モーション再生などが可能です。このHNDViewerにコマンドライン実行機能を追加して、モーションデータからGIF画像を自動生成するツールを、若手TA（入社3年目）の清水に開発してもらいました」（麓氏）。この開発の詳細は、SEGA TECH BLOGの「新卒からのTAが内製ツールに動画撮影機能をつけてみた話」で紹介している
C：セガゲームスの場合も、開発技術部のTAとは別に、プロジェクト専属のTAがいるのでしょうか？
麓：いますね。カプコンさんの場合と同様、各プロジェクト内の「テクニカルに強いアーティスト」「アートに理解のあるプログラマーやエンジニア」が、プロジェクト専属のTAとして活躍しています。さらにプロジェクト内のTAチームとして組織化されたり、チーム間で情報交換したりといった動きも起こっているので、TA人口は徐々に増えていると思います。
塩尻：特にAAAタイトルのプロジェクトだとそういう人が数多くいるのですが、中小規模タイトルだと手薄になってしまい、中には専属TA不在のタイトルもあります。そこで発生した問題の多くはDCCサポートチームに持ち込まれるので、どう対処するかが課題になっています。
TAを長くやっていると、状況が先の先まで想像できる
沼上：バンダイナムコスタジオの場合も、全プロジェクトにTAを配属するような余裕はないので、似たような課題を抱えています。塩尻さんが言うように問題が持ち込まれるだけマシで、後になって「根性で解決しました！」という話を聞かされ、「相談してくれればどうにかしたのに......」と頭を抱えるケースも結構あります。
塩尻：ありますね（苦笑）。
麓：よくあります（笑）。例えば、Photoshopのひとつのファイルに大量のレイヤーが格納されていて、レイヤーの表示・非表示の切り替えでUIを表現したい。ところがゲームの実機に実装するためには、1枚1枚のレイヤーを個別の画像ファイルとして保存しなければいけない。さらに各レイヤー画像の実装方法を伝える指示書をExcelでつくらないといけない。ちなみに必要な画像ファイルの数は80枚。
C：それはやばい。
麓：アーティストが「根性で解決」したら、かなりの時間を要しますが、こういうケースは本当によくあります。そして、この作業は全部スクリプトを書けば自動化できますから、大幅な時間短縮とコスト削減が可能です。プログラマーにお願いすれば書いてもらえるような職場なら幸せですが、プログラマーの本来の仕事はゲームの実装ですから、プログラマーとして評価されない仕事にはできるだけ時間を割きたくありません。運よく書いてもらえたとしても、GUIが用意されておらず、プロンプトにコマンドや引数を入力して実行するツールだったりするとアーティストにとっては使いづらいし、別のプロジェクトで使おうと思っても、久々に起動したときには使い方を忘れています。
C：それはつらい。
麓：アーティスト寄りのTAの場合、このような状況が先の先まで想像できるので、最初に相談を受けた時点で「この作業をスクリプトで自動化するツールをつくろう。さらにツールの使い方のドキュメントを書く方が面倒だから、ちゃんとGUIを用意して、ツールを見れば使い方が直感的にわかるようにしておこう」と考えるわけです。時間に余裕があれば、ほかのプロジェクトでも使えるように、そのツールを汎用化するかもしれません。さらに条件が揃えば、なにがしかの統合開発環境の中に組み込むレベルまで昇華できるかもしれません。
C：それはすごい！！
麓：どこまでできるかは、TAとしての知識、技量、経験などで変わってきますね。今後は新卒入社の若手TAが増えてくると思うので、彼らの足りない部分を補うためにも、シニアTAが口を酸っぱくして先のようなことを言語化して伝えていく必要があると思います。例えば、最近流行っている海外ブログのセオリーを真似て「新人TAのための、ツール制作に必要な5つのこと」（下記）というような形で、端的にまとめてみるのも有効だと思います。
新人TAのための、ツール制作に必要な5つのこと
1. 絶えず自動化に目を光らせよう
2. どんなに簡単なスクリプトでも、GUIは絶対に必要
（GUIのながれは上から下へがセオリー。機能はできるだけシンプルに、ブロックごとにまとめる）
3. ユーザーの気持ちになってつくる
（自分が使いづらいと思ったツールは、ユーザーには絶対に使いづらいツール）
4. まずは目先のユーザー、余裕があれば将来のユーザーも視野に入れよう
5. 制作時間に余裕をもつ
（どんなツールでも自分の知っている範囲だけでつくらずに、もっと良い方法はないか調べながらつくる。そこで得た知識は必ず自分の糧になる）
沼上：すごく共感できます。TAを長くやっていると「状況が先の先まで想像できる」ようになり、問題解決のスピードが速くなっていきます。同じような問題をあちこちから何度も相談されるので、最後まで話を聞く前に答えを言ってしまうこともあるくらいです。とはいえ新人TAがそうなるまでには時間がかかるので、シニアTAがていねいに説明していくことが必要なんだろうと思います。
塩尻：そうですね。相談されるたびに、考えて、調べて、いろんな人に相談して、試して、解決して......を繰り返すので、どんどん思い浮かぶ選択肢が増えていくんです。1個の問題を相談されたとき、少なくとも2～3個の解決方法が浮かぶようになります。「Aが駄目だったらB、Bも駄目だったらCと言いたいところだけど、われわれの手間も結構かかるから、やっぱりDにしよう」という感じです。例えば「ツールが動かない」といった問題が発生した場合には、まず社内チャットなどで連絡が来て、チャットのやり取りだけでは解決できなければ相手の席まで出向きます。階段を降りたり、エレベーターに乗っている最中に頭の中で選択肢を思い浮かべ「多分これだろうな」と見当を付け、席に到着して指摘したら「当たり」ということもありますね。
沼上：ありますね。逆に何回も往復しなきゃいけないこともあります（苦笑）。
麓：勝手に想像しすぎて、全然ちがったりという空振りもありますね。でも、そうやって引き出しに入れておいた知識を、実際に出して試してみることがすごく重要なんです。それを繰り返すうちに、最短距離で正解を導き出す力が身に付いてきます。
C：知識を入れて、出して、試してのサイクルを回すことで、考える力が磨かれていくわけですね。
沼上：はい。知識をインプットすることも大事ですが、それをアウトプットしてみることもすごく大事だと思います。
塩尻：TAに向いている人の特徴のひとつに「知識欲が強い」というのがあるように思います。「新しいグラフィックボードが出たから触ってみたい」「あのミドルウェアは評判が良いから試してみたい」というような欲求が自然と沸き起こってくる人は、新しい情報や知識にキャッチアップしていくので、調べるスピードが速くなります。さらに、そうやってインプットした知識を、実際のゲーム開発の中でアウトプットして使ってみたいと思う人であれば、TAの仕事にやりがいを感じると思います。
沼上：さらに補足すると、先ほどのような単純作業を根性でやってしまえる人はTAに向いておらず、「めんどくさいから、何とかして効率化したい」と思う人はTAに向いています。アーティスト寄りのTAは、入社したときにはスクリプトすら書いたことがなかったのに、「めんどくさいことはやりたくない」という一心で、ツールを自作できるようになった人が多いです（笑）。
C：では続いて、そんなTAの仕事を「とあるTAのよくある1日」と題して具体的に紹介していただけますか？
前編は以上です。後編では3社における「とあるTAのよくある1日」を通して、TAの具体的な仕事内容をご紹介します。ぜひお付き合いください。
・後編はこちらで公開しています。
