CEDEC 2008の海外招待セッション「Haloの開発: テクニカルアートの役割」で紹介されたのを皮切りに、日本のゲーム業界でも徐々に認知度が高まり、近年のCEDECでは複数の関連セッションが当たり前のように実施されているテクニカルアーティスト（以降、TA）。それでも「TAが足りない」「志望する学生がいない（または少ない）」という声は頻繁に聞こえてくる。そこで、カプコン・セガゲームス・バンダイナムコスタジオの3社でTA業務に従事する塩尻英樹氏、麓 一博氏、沼上広志氏に集まっていただき、その具体的な仕事内容や、新人TA育成時の課題などについて語り合ってもらった。座談会では約2時間にわたり活発な意見交換が行われたため、本記事は前後編に分けてお届けする。
・前編はこちらで公開しています。
TEXT＿尾形美幸 / Miyuki Ogata（CGWORLD）
PHOTO＿弘田 充 / Mitsuru Hirota
カプコンの、とあるTAのよくある1日
CGWORLD（以下、C）：3社におけるTAの仕事を「とあるTAのよくある1日」と題して具体的に紹介していただけますか？
塩尻英樹氏（以下、塩尻）：私の場合は、こんな感じ（下記）です。
・パターンA
9:00〜
・出社
・各プロジェクトからの要望などに見落としがないかチェック
・今日の最低限しなければならないことの確認
・ライセンスサーバチェック
9:30〜
・メンバー勤怠管理
・DCCツールが正常終了しないとの社内アーティストからの報告。環境変数で対応したところ改善
10:00〜
・プロジェクトAから、社外にMayaDevを提供したいとの依頼。内容と、開発委託契約上問題がないかを確認後、メンバーにパッケージzipの制作と提供を依頼
11:00〜
・メンバースケジュールチェック作業
・プロジェクトBのプロデューサーより、過去作のバックアップデータの、現行VerのMayaへのコンバートテストとフロー制作の依頼。バックアップデータの収集開始
13:00〜
・ゲームエンジン関連社内ミーティングに参加
14:00〜
・プロジェクトBのバックアップデータの確認作業。20年前のデータ（Softimage|3Dのデータ）なので、過去OSが起動できるPCでのデータ復旧作業、およびFBXとdotxsiでのデータ出力検証
15:00〜
・プロジェクトCよりHoudiniの検証を行いたいとの依頼。SideFXにメールにてテンポラリライセンスの発行を依頼。ライセンスサーバ（VM）側の準備
・プロジェクトBのバックアップデータコンバートフローで使用する、簡単なスクリプトを制作
16:00〜
・オートデスクへのMayaとMotionBuilderに関する質問メール制作（Maya2018Update4での問題、FBXフォーマット質問、API関連など）
17:00〜
・Shotgun関連でのプロジェクトDとのミーティング。運用手法やクラウド（AWS）の説明。試用版の必要性などについて協議
18:00〜
・質問返答（HoudiniEngineのライセンスに関するアーティストからの質問）
・質問返答（MayaDevの提供内容とその手法について）
・パターンB
9:00〜
・出社
・各プロジェクトからの要望などに見落としがないかチェック
・今日の最低限しなければならないことの確認
・ライセンスサーバチェック
9:30〜
・メンバー勤怠管理
・近郊の外部協力会社より、DCCツールが起動できないとのトラブル報告。メールや電話で確認するも不明な点が多々あり、10:00より緊急訪問することに
11:00〜
・DCCツールが起動できない問題対処終了。Displayportをグラフィックボード側に刺さずに、マザーボード側に刺してしまったことに起因する問題。Intelグラフィックスのドライバアップデートで改善。その後、MayaDev内ツールやミドルウェアワークフローなどについて質問を受け対応
13:00〜
・プロジェクトEとのツール発注仕様確認ミーティング。シーンデータマネージャ（SDM）への依頼が主となるので、開発者に同席依頼
14:00〜
・外部協力企業とのDCC関連技術ミーティングの事前準備として、資料制作
15:00〜
・社内機材担当部門より、新規グラフィックボードとIntelチップセットの評価依頼。機材のセットアップと空き時間での検証を開始
17:00〜
・プロジェクトFの上長より、Softimage2010からMayaへの作業移行、およびUnityから社内開発ゲームエンジンへの移行について相談依頼。既存データコンバートツールの改良点や移行時のアーティストの諸問題について相談。内容を持ち帰りプロジェクト側で相談するとのこと
・プロジェクトBより、プレイヤー1体、エネミー1体、背景1区画の高解像度化。サンプルデータの制作依頼。内容を確認しスケジュールを調整
バンダイナムコスタジオの、とあるTAのよくある1日
沼上広志氏（以下、沼上）：バンダイナムコスタジオのTAの場合は、こんな感じ（下記）です。
・パターンA
10:00〜
・メールチェック
・毎晩回しているJenkinsの自動処理の結果が問題ないことをログで確認
13:00〜
・メインで担当しているゲームプロジェクトAで、プログラマーからパラメーターを追加したいと言われた。中間ファイルフォーマットを確認して仕様追加、サンプルデータをMayaでつくって検証、リリース
15:30〜
・プロジェクトBから、モデリング作業を他社に委託するため、内製ツールを貸与したいとの相談あり。すぐに打ち合わせを行い、内容の検討、事務手続きの説明
17:00〜
・委託先とボイスチャットで遠隔ミーティング
18:00〜
・プロジェクト向けに制作したツールを汎用化し、社内共用ツール環境へ移行する作業を実施
・パターンB
10:00〜
・海外子会社からMayaのライセンスの仕様について相談あり。チャットでカタコトの英語で説明
11:00〜
・「DCCツールで、とある操作をすると期待した挙動にならない」と社内メーリングリストで相談あり。過去案件を調査、課のメンバーに相談。似たケースがあったと聞いたので、相談者の席まで行き、実際に手順を見せてもらう。データをもらい手元で試したら問題が再現したので、ひとつずつ条件を削って調査。その結果、あるコマンドに不具合が見つかったので代理店に連絡。とりあえず代替手順をつくって回避してもらう
14:00〜
・プロジェクトAのアーティストから、エクスポートがなぜかエラーになるとの相談。ログを送ってもらい確認したところ、足りないデータがあったため、説明して試してもらい、無事通るようになったとのこと
15:00〜
・プロジェクトAのアーティストから、ある作業を簡略化するツールをつくってほしいとの相談。詳しく聞いてみたところ、以前別のTAが似た用途のツールを制作していたのを思い出したので確認。少し機能を追加すれば流用できそうだったので、前述のTAに相談。機能追加までやってくれたので、それを渡して試してもらう
17:00〜
・Perforceが重いと相談あり。プロジェクトでのPerforceアクセスフローを調べて、社内の管理チームに状況を説明しに行く。ログを見てもらったところ、プロジェクト側の自動処理に無駄な部分があったことが判明。修正対応
セガゲームスの、とあるTAのよくある1日
麓 一博氏（以下、麓）：セガゲームスのTAの場合は、こんな感じ（下記）です。
・パターンA
9:40〜
・メールチェック、Redmineチェックをし、前日のタスクと今日やることを反芻し、軽くまとめる
10:00〜
・前日実装したツールの機能や修正に問題がないか動作チェック
10:30〜
・朝会
・チームメンバーの前日の作業と今日やる作業、問題点などを全員で確認
11:00〜
・Teams（チャットツール）よりプロジェクトで使用しているツールの問題点が新たに報告され、次の要望よりも先行して修正する必要があるとのこと。修正方針をそのままTeams上ですり合わせ、逐一確認しながら実装。複数のクラス、関数にわたる修正のため少し時間がかかることを伝える
12:00〜
・お昼休み
13:00〜
・チームメンバーから制作中のツールに関して仕様確認。関係者で少し打合せた後、仕様を策定
14:00〜
・プロジェクトのミーティングに出席、作業の内容と進捗などを相互に確認
15:00〜
・自席にて午前中報告があった問題を引き続き修正。PySideで上手く動かない部分についてWebで調べる。ついでに知らなかった機能を発見し、別のスクリプトに密かに組み込みを試す
17:00〜
・修正完了。チェックをし、コミット
17:30〜
・チーム内で開発中のアプリケーションの確認
18:00〜
・チーム内で開発中のアプリケーションで使うアイコンをデザイン
18:30〜
・Redmineを見ながら、チームタスクを確認。調整を行う
・日報を制作し、諸々社内外含めメールを書いたり、返信したり。チャットの相談ごとにも返信をする
・パターンB
9:40〜
・メールチェック、Redmineチェックをし、前日のタスクと今日やることを反芻し、軽くまとめる
10:00〜
・前日実装したツールの機能や修正に問題がないか動作チェック
10:30〜
・朝会
・チームメンバーの前日の作業と今日やる作業、問題点などを全員で確認
11:00〜
・プロジェクトから新規ツールの相談があり、調整、仕様の聞き取りなど
12:00〜
・昼休み、何を食べようかな
13:00〜
・依頼されていたツールプログラム作業を少し進めるが、Mayaの仕様に悩まされ、検証に時間を取られる
14:00〜
・プロジェクトの近くに用意された作業席へ移動。プロジェクトTAと話をしたりツールの確認をしたり、相談された調査を行うなど、実装から調整まで色々対応。基本的にはパイプライン構築作業
15:00〜
・プロジェクトのTA技術共有ミーティングに参加
16:00〜
・引き続き常駐プロジェクトの実装作業
17:00〜
・部門間TA情報共有ミーティングに参加
18:00〜
・上記2つのミーティングで出てきた相談の調査や、ツールの修正など、チームのほかのメンバーと仕様をすり合わせる
・業務のログと、作業時間の記録。チームの報告書などを制作し、明日対応するための課題を書き出して退勤
次ページ：
若い世代のTAが
われわれと同じ道を歩む必要はない
若い世代のTAが、われわれと同じ道を歩む必要はない
C：四六時中、いろんなプロジェクトのいろんな人から問題が持ち込まれ、片っ端から同時並行で解決していくという点では、3社とも共通していますね。一方で、文面に書いた方の個性がにじみ出ている点が面白いです（笑）。この中だと、セガゲームスの事例が一番プロジェクト専属TAに近く、カプコンの事例が一番全プロジェクトを俯瞰（ふかん）する立場のTAに近いと言えるでしょうか。カプコンの事例の場合は、外部協力会社まで足を運び、しかもハードウェアに起因する問題解決までやっている点に驚きます。語弊があるかもしれませんが「何でも屋さん」と言っても過言ではないほど守備範囲が広いですね。
塩尻：実際、私はひとつの分野に秀でるのではなく、広い分野をカバーするゼネラリスト型だと思います。昔からカテゴライズが難しい働き方をしていたので、TAという役割が浸透する以前は、社内のある人から「塩尻マン」と呼ばれていました。
C：そのまんまですね。どういう経緯で、そういうネーミングになったのでしょうか？
塩尻：昔のカプコンでは、例えばキャラクターモデルをつくる人は「モデルマン」、モーションを付ける人は「モーションマン」、背景をつくる人は2Dゲーム時代の名残で「スクロールマン」と呼ばれていました。そんな中で「塩尻はカテゴリがわからないから『塩尻マン』だ」となったわけです（笑）。
C：カテゴライズ不可能な特殊スキルをもっていたわけですね。
▲左から、「塩尻マン」こと塩尻英樹氏（カプコン）、麓 一博氏（セガゲームス）、沼上広志氏（バンダイナムコスタジオ）
塩尻：「なんとかしてゲーム業界で生き残っていかなきゃならない」という危機感から、周囲の相談に片っ端から応じていたら、いつのまにかそういうカテゴライズをされる人間になっていました。例えば「DCCツールが起動しない」という相談を受けたとき、その問題がライセンス認証に起因している場合もあれば、CPUのドライバのバージョンや、グラフィックボードに起因している場合もあります。問題をいち早く解決するためには、機材のことも勉強する必要があったのです。さらに各ツールのサーバを立ち上げるときには、サーバ関連の知識も必要になります。物理的なサーバを新設するのか、仮想的なサーバにするのかの検討から始まって、アセットを共用するにはどうしたらいいのかなど、必要な知識は多岐にわたります。
沼上：私も「わかりません」と言ったら仕事がなくなるんじゃないかという危機感から、一所懸命いろんなことを調べてきましたね。その結果、塩尻さんと同じように、機材やネットワーク関係の相談にも応じられるようになりました。そこに詳しい人はプロジェクト内にあまりいないので、すごく重宝がられ、やりがいを感じ、さらに詳しくなって今にいたります。最近は「とりあえず、相談すれば何とかしてくれる」という認識が浸透し過ぎて、全然関係ない事務手続きまで聞かれることがあります（苦笑）。
塩尻：われわれ世代のTAは、そういうゼネラリスト型が多いですよね。昔はプロジェクトの人数が今より少なかったので、1人で何でもやらざるをえなかったし、業務に対する上長の理解が浅く、評価軸が定まっていないケースが多かったように思います。そんな極限状況だったから、鍛えられたとも言えますね。一方で、若い世代のTAがわれわれと同じ道を歩む必要はないだろうと思っています。最近は求められる技術や知識のレベルがどの職種でも高度化しており、それに伴うスペシャリスト化がTAにおいても進行しています。例えばカプコンにはアニメーションに特化したTAもいます。そのTAの場合は、すごくアニメーションやリギングに精通している一方で、それ以外はあまり詳しくないですが、しっかりプロジェクトに貢献し、評価もされています。
2年ほど前に私のチームに新人が入ってきたとき、最初は「何からやってもらおうか......」と悩んだのですが、「まずは武器をもってもらおう」と決めました。「Mayaに精通し、Mayaのツールをつくれるようになる」とか、「シェーダを極める」とか、先のアニメーション特化型TAのように、まずは1つの分野のスペシャリストになることから始めてもらうのが良いだろうと思ったのです。
C：大きいゲーム会社の場合は、人数が多く使える機材も豊富ですから、スペシャリストが活躍する余地もふんだんにありそうですね。新人TAの場合は、まずは武器となる専門分野でもってプロジェクトに貢献し、その後「塩尻マン」的なゼネラリスト型を目指すのか、何らかのスペシャリスト型を目指すのか、自分に合う方を選択すれば良いということでしょうか？
麓：それが自然なながれだと思います。これ（下図）は、とある大学で特別講義をした際に、TAの仕事のながれを解説するためにつくったスライドです。どんな分野から始めたとしても、TAを続けることは学習を続けることとイコールなので、着実に成長していきます。一足飛びに守備範囲が広がらないことはシニアTAたちだって理解しているので、焦ることはありません。われわれ自身、時代に乗り遅れるのは悔しいので、今も学習しながら仕事をしています（笑）。
▲麓氏が、とある大学で特別講義をした際に、TAの仕事のながれを解説するためにつくったスライド。「仕事の合間に学習を挟んでいかないと、時代に乗り遅れるといった話をする際に使いました」（麓氏）
C：わかりやすいスライドですね。TAの仕事を続けていれば、自ずと知識が増え、守備範囲が広がり、一人前になっていくわけですね。
塩尻：うーん。一人前の定義がよくわからないので何とも言えないですね。私自身、自分が一人前だと思ったことはありません。ほかの方を見て「すごいなあ」と感じることばかりなので、生涯一人前とは思えない気がします。ただ、ある業務を任せられるのが一人前だとするならば、プログラムやアート技能など、もともとの技能・素養の有無によって差はありますが、MayaやHoudiniを知らなくても、速ければ半年、遅くとも1年くらいで簡単な業務を任せられるようになると思います。
[[SplitPage]]TAとして「何がやりたいか？」を考えてみる
麓：「TAになりたいな」と思ったら、次は「TAとして、何がやりたいか？」を具体的に考えてほしいと思います。TAの守備範囲はすごく広いので、単に「TAになりたいです。何を勉強すればいいですか？」と学生さんに聞かれても、答えに困ってしまうんです。自分がやりたいことを軸にして、勉強なり、質問なりをすれば、自分の将来がより具体的になっていくと思います。TAという言葉や役割が世の中に認知されてきた結果、具体性のないままTAが語られるケースが出てきており、最近はそこに危機感をもっています。
沼上：TAに加え、ツールプログラマー、エンジンプログラマー、パイプラインエンジニアなど、ゲームプログラマー以外のテクニカル職を募集しているゲーム会社は多いです。大きな会社の場合は、それぞれの職種で「この人はアニメーションが得意」「あの人はレンダリングが専門」というように細分化もされています。だから「自分はTA志望だと思ったけど、実はちがった」という学生さんもいると思います。応募するときには「どんなことに興味があって、どんなことをやってみたいか」さえしっかり伝えてくれれば、どの職種が適しているかは採用する側が判断します。
例えば私の場合は自分で絵は描けませんが、プログラムすれば綺麗な絵を生成できることが楽しくて、CGを始めました。それを仕事にできる業界はあるだろうかと調べた結果、ゲーム業界にたどり着いたんです。その頃はゲーム業界以外に、CGで飯が食えるところはなかったんですよ。そんな動機でこの業界に入ったから、今でもゲームが下手で、例えば格闘ゲームに新しいデータを組み込んだとき、動作確認をしたくても技が出せなくて周りの人に助けを求める......ということもたまにあります。
塩尻：TAやツールプログラマーには、結構そういう人がいますね。必ずしもゲームをつくること自体にモチベーションを感じる必要はないと思います。われわれのユーザーは目の前のゲーム開発者なので、彼らの相談に応じ、プロジェクトにとってベストの解決策を提示できれば役割は果たせます。ただ、その先にはゲームをプレイしてくださるユーザーがいるので、「ゲームが嫌いです」という人だとさすがに無理が出てくるとは思います。
C：確かに、3社の採用ページを見るとゲームプログラマー以外のテクニカル職もいろいろ募集していますね。
・カプコンの採用ページ
・セガゲームスの新卒採用ページ
・バンダイナムコスタジオの新卒採用ページ
C：実際のところ、応募の際に何を送れば「TAとしての将来性」をアピールできると思いますか？
沼上：エンジニア寄りのTAなら、プログラマーやエンジニアと同様の採用経路になることが多いので、大学生なら研究成果、専門学校生ならつくったゲームやツール、作品などをアピールすると良いでしょう。アーティスト寄りのTAなら、通常のアーティストと同じ採用経路になることが多いので、ポートフォリオや作品の提出が必要になります。その上で、TAの仕事のどこに魅力を感じるか、何をやりたいかを伝えてほしいですが、正直に言うと「TAとしての将来性」まで明示するのは難しいだろうなと思います。
塩尻：私自身、自分の履歴書を書けと言われたら、どう書くか悩みますね（笑）。ただ、どんな経験も無駄になることはないので、自分のやってきたことをアピールすれば良いと思います。とはいえツール制作などの技能があった方が、目に止まりやすいとは思います。制作したツールの説明や、サンプルデータなどがあればなお良しです。最終的には「この人になら、業務を任せてみたい」と面接の相手に思わせられるかどうかだと思います。
沼上：就職してから基礎を学びなおすのは大変なので、大学でも専門学校でも、理系であれば数学・物理・英語を、美術系であればアートの基礎をちゃんと勉強しておくことが大事だと思います。CGの幅広い知識に加えて、Pythonなどの各種言語のスクリプティング、理系であればC++のプログラミング、Webの関連技術、PCなどのハードウェア関連知識なども学習しておくと、後で役立つと思います。既存のゲームエンジン、DCCツールなども身近にあるならぜひ触ってほしいですが、高価なソフトを勉強のためだけにわざわざ買う必要はありません。
CEDECのスライドで学び、学会や作品展示会の発表に応用する
塩尻：それからTAの場合は「人に伝える能力」が特に重要なので、学生のうちから意識して鍛えておくことをおすすめします。数年前の話になりますが「ゲームエンジンって何なの？」という上長からの質問に答えるために、こういうスライド（下図）をつくりました。
▲塩尻氏が、ゲームエンジンを用いたグラフィックス制作フローをわかりやすく解説したスライド
塩尻：で、さらにわかりやすく伝えるため、こういうスライド（下図）もつくりました。
▲塩尻氏が、前述のフローを「さらに」わかりやすく伝えるため、カレーづくりに例えて解説したスライド
C：おお！ わかりやすい上におもしろい！！
沼上：すごくわかります。ほかのものに例えたり、言い換えたりというテクニックは私もよく使います。
塩尻：学生でも、学会や作品展示会の場で、自分の研究成果や作品について発表する機会があると思います。そういうとき、どんな資料やスライドをつくり、どう説明すれば伝わりやすいか、よく考えて実践してみることも、後の仕事に役立つと思います。
麓：CEDECは、ゲーム業界の開発者たちの「人に伝える能力」の向上に役立っているなと感じます。CEDECの発表スライドを閲覧できるCEDiLには2通りの活用方法があって、ひとつは技術情報を手に入れることで、もうひとつはスライドのつくり方を勉強することなんです。CEDiLのスライドを見たり、CEDECで実際の発表を聞いたりすると、人に伝えるときの勘所が養えると思います。
塩尻：そうですね。CEDECのスライドは本当によくできているものが多いです。カプコンの社員の場合は、CEDECで発表する前に3〜4回は社内でリハーサルをします。「CEDECで発表するより、社内でリハーサルをするときの方が怖い」と皆が言うくらい容赦ないダメ出しが入るので、どんどん上手くなります。
C：確かに、CEDECのスライドや発表は、どの会社も年々レベルが上がっていると思います。
麓：1ページ単位で情報を切り出して整理して、それを並べて起承転結を付けて、聴衆を飽きさせないテンポで説明して、ちゃんと理解してもらうのはかなりハードルが高いです。そういう点にも注目すると、新たな発見があると思います。
C：CEDiLやCEDECを通してインプットしたことを、学会や作品展示会の発表でアウトプットしていけば、考える力が培われ、人に伝える力も磨かれて一石二鳥ですね。お話を伺ったことで、TAの仕事の「今」と「これから」が、より具体的にイメージできるようになりました。
沼上：この座談会を通して、TAの仕事に対する理解がさらに深まれば嬉しいです。
塩尻：TAやツールプログラマー人口がさらに増えることを期待しています。
麓：ゲーム会社の社員は、基本的に「自分がやりたいこと」がモチベーションになっていて、それはTAの場合も同様です。TAの仕事の何にモチベーションを感じるのか、ぜひ聞かせてほしいと思います。
C：お話いただき、ありがとうございました。
