CEDEC 2008の海外招待セッション「Haloの開発: テクニカルアートの役割」で紹介されたのを皮切りに、日本のゲーム業界でも徐々に認知度が高まり、近年のCEDECでは複数の関連セッションが当たり前のように実施されているテクニカルアーティスト（以降、TA）。それでも「TAが足りない」「志望する学生がいない（または少ない）」という声は頻繁に聞こえてくる。そこで、カプコン・セガゲームス・バンダイナムコスタジオの3社でTA業務に従事する塩尻英樹氏、麓 一博氏、沼上広志氏に集まっていただき、その具体的な仕事内容や、新人TA育成時の課題などについて語り合ってもらった。座談会では約2時間にわたり活発な意見交換が行われたため、本記事は前後編に分けてお届けする。

・後編はこちらで公開しています。

TEXT＿尾形美幸 / Miyuki Ogata（CGWORLD）
PHOTO＿弘田 充 / Mitsuru Hirota

全プロジェクトを俯瞰し、会社全体での円滑化や効率化を図る

CGWORLD（以下、C）：「TAは、テクニカルとアートの両方に精通しており、勉強家で、交渉力も説得力もあり、人間的にも『できた人』であることが求められるので、新卒学生がいきなり目指すのはものすごくハードルが高い」という意見を、かつてはよく聞きました。「まずはプログラマーなり、エンジニアなり、アーティストなりの職種で専門性を高め、段階的に視野を広げ、TAとしての力も身に付けていくのが現実的だろう」というわけですね。実際、今日集まっていただいたお三方はそうやってTA業務に従事するようになったと思います。

ところが最近では、新卒入社の若手が、最初からTAとして育成されるケースも出てきました。入社2年目にしてCEDECでTAのラウンドテーブルを共同開催したセガゲームスの清水宣寿さんはその代表例でしょう。彼のような若手TAに刺激され、TAの仕事に興味をもつ学生も出てきていると私は実感しています。これらの背景を踏まえ、実際のところ、TAの「今」の仕事はどうなっていて、「これから」のTA人口を増やすには何が必要か、じっくり伺っていきたいと考えています。

塩尻英樹氏（以下、塩尻）：正確に言うとカプコンにはTAというポジションが存在しません。実際にはTAの役割を果たしている人も、「プログラマー」あるいは「アーティスト」と呼ばれており、私の場合は「チームリーダー兼マネージャー」を名乗っています。

  • 塩尻英樹
    カプコン
     技術開発室 DCCサポートチーム長。1998年カプコンに入社。『バイオハザード3 LAST ESCAPE』（1999）、『デビルメイクライ』（2001）、『P.N.03』（2003）では背景を担当し、『バイオハザード（GC）』（2002）、『ディノクライシス3』（2003）、『大神』（2006）ではVFXなどを担当。その後『戦国BASARA』（2005）、『戦国BASARA2』（2006）、『戦国BASARA2 英雄外伝』（2007）ではキャラクターセクションおよびインゲームデモリーダーを担当。現在はDCCツール関連のツールプログラマーチームのリーダー兼マネージャーを務めながら、様々なプロジェクトのサポートにも携わる。


沼上広志氏（以下、沼上）：それを言い出すと、私も正確にはTAではありません（笑）。当社ではエンジニア寄りのTAのことを「テック」と呼びます。だから私も社内では「テック」と名乗っていますが、対外的には「TA」と言った方が通じやすいことは大半の社員が理解しています。


麓 一博氏（以下、麓）：セガゲームスのTAは、社内でも社外でも最近では「TA」と呼ばれ始めています。

  • 麓 一博
    セガゲームス
     
オンラインコンテンツ事業部　開発サポート部 テクニカルアーティスト。1998年セガ（現、セガゲームス）に入社。ドリームキャストの起動時の映像、いくつかのゲームタイトルのアート業務を経て、現在の描画ライブラリ開発、サポート部門へ。複数のゲームタイトルにおいて、DCCツール、表現技術、ワークフローなどに関する開発とサポートを担う。


C：三者（社）三様で、ややこしいですね（苦笑）。おそらく仕事内容に大きなちがいはないと思うので、この座談会の中では「TA」と呼ばせてください。その上で、皆さんが所属しているチームの、社内での役割を教えていただけますか？

塩尻：私は「技術開発室 DCCサポートチーム」のリーダー兼マネージャーを務めています。メンバーは12人で、ツールプログラマーとアーティストで構成されており、社内の全ゲーム開発プロジェクトを対象にMayaやHoudini、Substance系ツール、ZBrushなどのDCC（Digital Content Creation）ツールのサポートをしています。「MayaDev」「シーンデータマネージャ」といった内製汎用ツールの開発・運用に加え、DCCツール関連の問題解決や相談にも応じています。

▲【左】Mayaの画面上からMayaDev（カプコンの内製ツール）を操作している／【右】MayaDevの機能を説明するためのマニュアルページ。「MayaDevは、簡潔に言うとMayaに関連するツールの統合開発環境です。ゲーム制作の効率化につながる様々な内製ツールがまとめられており、Mayaの画面上から操作できます。MayaDevの開発以前は、各プロジェクトで制作されたツールの情報共有が不十分だったので、同じような機能のツールが複数のプロジェクトで制作されており、微妙に使い方がちがったりもしていました。こういった課題を解決するために、社内の全プロジェクトで使用できる汎用的な統合開発環境としてMayaDevという仕組みが開発されました」（塩尻氏）


▲シーンデータマネージャ（通称、SDM／カプコンの内製ツール）の画面。「SDMは、Mayaの画面上で各種アセットを管理するためのブラウザツールです。2014年より開発が始まり、『バイオハザード7』（2017）開発での導入を皮切りに、現在ではMayaで開発するほとんどのカプコンのプロジェクトで導入しています」（塩尻氏）


C：たった12人で、カプコンという巨大組織の全プロジェクトをサポートしているのでしょうか？ ゲーム開発者だけでも数千人規模になるでしょうし、プロジェクトの数も何十とありますよね......。

塩尻：各プロジェクトの中にも「テクニカルに強いアーティスト」「アートに理解のあるプログラマーやエンジニア」がいるので、そういう人たちと連携しつつ、会社全体でのゲーム開発の円滑化や効率化を図っています。DCCサポートチームは全プロジェクトを俯瞰（ふかん）する立場にあるので、個々のプロジェクトの状況把握までは手が回りません。代わりにプロジェクト内のTAの素養のある人たちが、プロジェクト固有の問題やニーズを把握し、DCCサポートチームと連携しながら問題解決に当たってくれています。個人的には、そういう人たちの方がよりTAと呼ばれるに相応しい仕事をしているように思います。

プロジェクトの歴史を踏まえ、解決策や落とし所を提案

沼上：カプコンさんと同様、バンダイナムコスタジオでも何十という数のプロジェクトが常時進行しているので、プロジェクト専属のTAとは別に全体を俯瞰する役割のTAがいなければ、同じような問題に対し複数プロジェクトのTAが個別対応するといった無駄が頻発します。

C：となると、バンダイナムコスタジオにも全体を俯瞰する役割をもったチームがあるのでしょうか？

沼上：そうです。私の所属するチームは通称「テック」と呼ばれており、7人ほどのエンジニア寄りのTAで構成されています。それとは別に、5～6人ほどのアーティスト寄りのTAで構成されたチームもあり、その2チームで会社の全プロジェクトを俯瞰しています。会社全体での効率化を推進するためには、複数プロジェクトで共通して使える汎用ツールを開発した方が良いのですが、必ずしも共通化が正解というわけではありません。特にナンバリングを重ねてきたタイトルの場合は、長年かけて培ったやり方があるので、無理矢理ちがう方向にもっていこうとすると、かえって良い結果を生まないこともあります。

▲あるゲーム開発プロジェクトのために、バンダイナムコスタジオのTAが開発・運用しているツール類の一部。ほかのプロジェクトと共用している部分がある一方で、プロジェクトに合わせてカスタマイズしたり、プロジェクトに特化した専用ツールをつくったりもしている。「プロジェクトに所属するアーティストと密に連携し、作業の効率化に直結する様々なツールを提供しています。まずは後々の資産になりそうな汎用性の高いツールから開発し、その後、プロジェクトに合わせたカスタマイズを施すことで、汎用性と利便性の両立を図っています」（沼上氏）


C：塩尻さんと麓さんはちょうど20年、沼上さんは20年以上同じ会社に勤めていますから、そのナンバリングの過程をずっと見てきたわけですね。

麓：そうですね。プロジェクトの歴史を踏まえた上での解決策や落とし所を提案できるのは、長くいる者の強みだと思います。いろんなことを考慮して、プロジェクトにとってベストの解決策を提示して、受け入れてもらい、ちゃんと実践してもらうことが重要です。新人TAにそこまでやってもらうのは難しいので、徐々に勘所を伝えていく必要があります。

塩尻：TAには交渉したり、説得したりといったテクニックが不可欠です。相手が怒って交渉決裂で済むんだったら楽ですが、そうもいきません（笑）。仕事で必要とされる「コミュニケーション能力」というのは、単に相手と仲良くなれる力ではなくて、解決へと導ける力なんですよ。

沼上：仮に私がカプコンさんやセガゲームスさんに行き、今と同じような仕事をしようとしても、多分できないでしょう。3人とも、これまで蓄積してきた経験やノウハウがあるから今の仕事ができていると思いますし、それが持ち味にもなっていると思います。例えばカプコンさんの社員にしてみれば、塩尻さんが言うのと、知らない人が言うのとでは説得力がちがうと思います。若い人には、自分のキャリアを長い目で見て、少しずつ実績を積み上げていってほしいと思います。

次ページ：
TA人口は徐々に増えているが
中小規模タイトルでは手薄

[[SplitPage]]

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の具体的な仕事内容をご紹介します。ぜひお付き合いください。

・後編はこちらで公開しています。