本連載では、CG映像制作におけるテクニカル系スタッフの仕事の現状と課題を、パイプライン開発の専門家である痴山紘史氏(日本CGサービス(JCGS)代表)が探っていく。第7回では、白組の制作チーム間の橋渡しを担う、パイプラインプロジェクトと呼ばれている活動を前後編にわたって深掘りする。

白組は1974年に設立された、日本を代表する総合映像制作プロダクションだ。同社は、CG、VFX、2Dアニメーション、ストップモーションといった多彩な表現手法を駆使し、幅広いコンテンツの企画・制作を行なっている。手がける分野は、CM、映画、ゲーム映像、TV番組、ネット配信コンテンツ、イベント映像など多岐にわたり、映画『ゴジラ-1.0』(2023)、映画『STAND BY ME ドラえもん』(2014)などは同社の代表的な大ヒット作品として広く知られている。

以降では、白組の入田尭光氏(システム部長)、小森啓裕氏(制作第4部 部長)、鈴木健之氏(制作第3部 部長)へのインタビューを通して、長い歴史をもつ同社が、どのようにして技術を蓄積し続けているのかを紐解いていく。

記事の目次

    8つの制作チームが特色をもちつつ、さらに視野を広げていく

    入田尭光氏(以下、入田):白組では、有志メンバーが集まり、社長承認の下でパイプラインプロジェクトとして、社内の各種パイプラインの整備に取り組んでいます。本日はその主要メンバー3名が集まっています。

    ▲入田尭光氏。システム部長。映像制作を支えるインフラの構築や保守・管理を担当

    小森啓裕氏(以下、小森):パイプラインプロジェクトには、全部で6~7名のメンバーが参加しています。その中にはツール開発を担っているプログラマーや、コンポジットのスーパーバイザーなども含まれています。私たちの活動を理解していただくために、まずは白組という会社の特色や、仕事への関わり方からお話できればと思います。

    ▲小森啓裕氏。制作第4部 部長。映画、アニメーション作品、ゲーム映像、CMなどの多岐にわたる分野で、監督、アニメーション監督、VFX・CGスーパーバイザーを務めている

    鈴木健之氏(以下、鈴木):私たちが白組に入社した当時は、島村(達雄)が代表取締役社長を務めていた時代で、スタッフの個人的な活動を積極的に支援する会社の風土をすごく感じていました。個々人が「こうしたい」と提案すれば、それを会社が後押しする文化が根付いていました。

    そうした風土の中で、山崎(貴)、八木(竜一)といったクリエイターが映画制作を志し、会社からも応援されてきました。このような経緯が現在のチーム編成にも影響を与えています。

    白組の3DCGに関わる制作チームは、調布スタジオ、制作第1部~第4部、企画制作本部として2チーム、新規コンテンツ事業部の8つに分かれており、各チーム内で常に5〜10程度のプロジェクトが同時並行で進んでいます。ただし、ひとつの長期プロジェクトだけに携わる場合や、10を超えるCMなどの短期プロジェクトに同時に携わる場合もあります。

    ▲鈴木健之氏。制作第3部 部長。映画、アニメーション作品、ゲーム映像、CMなどを手がけ、『friends もののけ島のナキ』(2011)よりCGスーパーバイザーを務めている

    小森:白組では「アニメーション×VFX」という言葉を掲げ、アニメーションとVFXに関わることであれば、どんな依頼でも挑戦するという姿勢で業務に取り組んでいるため、様々な分野のプロジェクトに携わる必要があります。制作期間も様々で、1週間で完了する短期プロジェクトもあれば、5年がかりで技術開発をしながら取り組む長期プロジェクトもあります。全てのプロジェクトに単一の制作方法で対応することは難しく、ひとつの制作チームで担うことが難しいケースも多々あります。

    例えば、ひとつの制作チームがフルCGの長期プロジェクトだけに専念できるのであれば、それに完全に特化したパイプラインや制作体制を構築することが可能ですが、次のプロジェクトに移ると、分野や制作期間が変わることはもちろん、ルックや関わるスタッフの編成も大きく変わってしまうため、その状況に対応し続ける必要があります。その結果、多様な課題に向き合い、解決策を模索する日々が続いています。

    2010年代までは、制作チームごとの得意分野に依存するスタイルが主流でした。例えば、実写のVFXが得意なチーム、セル調のアニメーションに特化したチームという具合です。しかし会社が成長するにつれ、そういうスタイルだけでは対応しきれなくなりました。近年は、「得意分野ではないけれど、セル調に挑戦してみよう」、「ほかのチームの協力を得ながら、実写のVFXをやってみよう」というような、チームの枠を超えた新たな挑戦が増えています。こうした取り組みによって、各チームが特色をもちつつ、さらに視野を広げていくことで、会社全体の柔軟性を高めることができるようになってきました。

    様々な分野に共通する、最低限の基盤を厳選して整備

    小森:プロジェクトが始まる際は、まず母体となる制作チームを決定し、仕事内容やスタッフの得意分野、空き状況を考慮して制作メンバーも決定します。不足分は社内全体から適任者を集め、最適なプロジェクトチームが編成されます。母体となる制作チームで不足しているスキルや経験は、ほかの制作チームのメンバーによって補うかたちがとられます。

    この場合、母体となる制作チームの存在が非常に重要になります。最初から社内全体に対して適任者を募るという方法も考えられますが、そうではなく、母体となる制作チームが教育面やメンタル面でのサポートを通じてスタッフの成長を支える役割を果たし、プロジェクト全体の最終的な責任も担うことで、責任の所在を明確にしています。

    鈴木:白組では、目の前にある多種多様なプロジェクトが仕事のベースになっているため、テクニカルスタッフは各プロジェクトに紐付くかたちで活動することが多いです。

    小森:例えば、セル調のルック開発や、実写合成、フォトグラメトリーの活用などが必要なプロジェクトであれば、それに応じたしくみを構築します。また、「長期プロジェクトだから、Flow Production Tracking(以下、Flow PT)の活用が適している」と判断すれば、それが使える環境を整えます。

    しかし、その環境をほかのプロジェクトや制作チームでも継続して利用するとは限りません。例えばCMのような短期間で完了するプロジェクトの場合は、Flow PTのようなツールを導入する必要はなく、コストの面でも現実的ではありません。そのため、必要なプロジェクトが終了すれば、そのツールやしくみの使用も終わります。

    鈴木:白組では当初から各制作チームの得意分野に最適化したワークフローやルールが確立されており、文化のちがいに驚くことがありました。例えば、セル調のアニメーションと実写映像では制作方法やノウハウが大きく異なります。このような状況でも、各分野のやり方や文化を尊重し、理解する姿勢が求められました。結果、多種多様なプロジェクトを進めるうちに、分野に固執することなく、それぞれのテクニック、ノウハウがほかのプロジェクトで活かされる場面も増えてきたと感じます。

    小森:先に説明した通り、白組ではプロジェクトごとに常に最適化された制作体制を構築し、映像制作に取り組んでいますが、その反面、どのプロジェクトにも共通する作業や課題に対応する必要性もありました。例えば、Houdiniを起動する際の環境変数や、Flow PTを使用する際の設定などは、「全員が簡単に利用できる環境を整備した方が効率的だ」という声が上がっていました。

    また、データの格納場所や、管理方法、アセットの呼び出し方など、共通化できる部分は統一した方が良いという意識も自然と生まれてきました。私自身も、フルCGの長編映画を制作した際に、単純な努力で乗り越えられるものではないと痛感しましたし、同様に、鈴木やほかのスタッフも、プロジェクトを進める中で共通の課題意識をもつようになりました。

    一度使ってみて良かった経験や、その際に開発されたツールを、次の長期プロジェクトなどにスムーズに引き継ぐしくみも必要になります。特に優れたアイデアを基に開発された革新的なツールについては、積極的にほかのプロジェクトや制作チームでも活用できるように整備し、社内で共有する必要もあります。

    さらに、様々なチームに参加しているスタッフからも、「プロジェクトに参加した後、スムーズに作業を始められる環境を整備したい」という意見が寄せられるようになりました。これを受けて、仕事を進めるための各種仕様や、基本ツールのしくみを統一しようとした取り組みが、パイプラインプロジェクトの出発点となりました。

    鈴木:パイプラインプロジェクトが整備しているパイプラインは、特定の理想形を目指すのではなく、多様なプロジェクトや制作チームごとの文化に適応することを目指しています。例えば、映画や、CM、アニメーション、VFXなど、様々な分野・工程に共通する要素を厳選し、最低限の基盤づくりを念頭に整備を進めることで、どのプロジェクトにも柔軟に対応できるしくみづくりを意識しています。

    ファイルサーバの構造や、共通ツールの整備から始めた

    小森:パイプラインプロジェクトでは、各チームへのヒアリングと、アイデアをもつスタッフの参加を通じて、基盤となるサーバの構造やそれに関係する共通ツールの整備を行うところからスタートしました。最初は業務の合間を縫っての活動でしたが、現在ではきちんと時間を確保し、月に2回、仕様の策定と技術(ツール)開発に関する話し合いを中心にミーティングを実施しています。このミーティングを通じて、どのチームにも共通する重要な部分を絞り込み、整備を進めています。

    現在パイプラインプロジェクトには、システム部を含め、5チームからメンバーが参加しています。直接の技術開発のリソースをもたない制作チームもあるため、全チームから誰かが参加することを必須にするのではなく、有志による参加を主体としています。メンバーは、パイプラインの全体像を把握できるスキルをもち、興味や、具体的なアイデア、開発力もあるスタッフで構成されています。

    パイプラインプロジェクトでは、ファイルサーバの構造を整備する際に、まずサーバを以下の3つのカテゴリに分け、それぞれに適した構造を構築していきました。

    1. 白組全体に関わる部分
    2. 制作チーム単位に関わる部分
    3. プロジェクト単位に関わる部分

    この構造は、多様なプロジェクトに対応しつつ、ツール開発を容易にする汎用的なしくみを目指して設計しました。私たちはこの構造をSSS(Shirogumi Server Structure)と呼んでおり、一度運用を始めたら終わりにするのではなく、日々の新たな要求を取り入れながら継続的なアップデートを続けています。

    ▲パイプラインプロジェクトのポータルページ。掲載している主な情報は以下の通り
    ・各種仕様、SSS(Shirogumi Server Structure)に関する解説
    ・各種ツールマニュアル、ツール使用回数集計(費用対効果の検証用)
    ・命名規則やツール開発のガイドライン
    ・パイプラインプロジェクトの概要、活動記録
    ・リリースノート
    ▲活動記録ページ。2011年から現在までのパイプラインプロジェクトの活動記録が、ドキュメントとして残されている

    7割程度の標準化を目標に、パイプラインを整備

    小森:最初は、整備したルールやツールを導入するか否かの判断は制作チームに任せており、各チームが独自に運用していたディレクトリ構造の方が慣れていて使いやすいといったことも相まって、なかなか普及が進みませんでした。しかし3~4年も経つと、「共通ルールがある方が便利だ」という認識が広がり、チーム間のスタッフの交流も手伝って、徐々に浸透していきました。

    現在では、サーバのディレクトリ構造はかなり統一化されるようになりました。しかし全社で全てのプロジェクトの統一化を図っているわけではなく、何年も秘伝のたれのように引き継がれ続けている長期プロジェクトや、Linuxを使用している環境においては、今でも独自の最適化が進められています。

    私たちは、全プロジェクトの7割程度が標準化された仕様に基づいて運用されることを目標に掲げていました。残りの3割に関しては、例えば長期プロジェクトで映画を制作する際には、それに特化したパイプラインツールの拡張や、工程間をつなぐ細かなツールの開発を行なっていくという具合です。その思考が、社内の柔軟性を担保する上ですごく重要になります。

    鈴木:各制作チームには、ツールを開発できるアーティストも所属しているので、私たちが考え方の基準を整備し、各チーム内で様々なプロジェクトに合わせたカスタマイズをするという運用にしています。現場がやりたいことを否定せず、柔軟に対応することを心がけています。

    小森:全てをルールで縛ってしまうと、そのルールに当てはまらないプロジェクトの場合に不具合や摩擦が起こります。そのため、例えばどのプロジェクトにもほぼ共通する「アセット制作」全般に関する部分は標準化を進める一方で、プロジェクトごとに処理が変わる「アセットのパブリッシュ」のような部分については、カスタマイズが容易なしくみを用意しています。

    ツール開発は、日々の話し合いの中で必要なツールを計画することから始まります。ある程度内容がまとまったらサンプルツールを開発し、需要のある制作チームで試験運用を行います。その後、ほかのチームでも同様の需要があれば紹介し、様々なプロジェクトを通しての意見を聞きながら改良を加えていきます。そのため、ひとつのツールが完成するまでには、かなりの時間を要します。

    例えばパブリッシャーの開発時には、最初は単純にデータをサーバにアップロードするだけの、どのプロジェクトでも簡単に導入できる状態からスタートしました。それから3~4年が経過した現在も、全プロジェクトの7割の需要をカバーできる範囲に限定して、細かな機能のアップデートを続けています。単にデータをアップロードするだけなら短期間で開発が完了しますが、実際に運用してみるとプロジェクトごとの突飛な対応が必要になったりします。近年は「Blenderを使うことになったから、対応できるようにしてほしい」といった要望も取り入れつつ、課題をひとつずつ解決していくことで、徐々に最適解に近づけています。

    ▲AssetPublisher。承認されたアセットデータをパブリッシュするツール
    ▲ShotPublisher。同じく、ショットデータをパブリッシュするツール
    ▲SeqPublisher。シークエンスの連番ファイルや、それに付随するNukeScriptなどをパブリッシュするツール

    一方的にツールを押し付けず、少しずつ浸透させる

    小森:現場スタッフとしての状況を踏まえながらツールを開発しているので、今のところ現場のニーズとの大きな乖離は起きずに使用できるようになってきました。ただし、制作チームごとの事情や運用方法のちがいによる解釈のズレ、末端のスタッフへの情報伝達の不備といった課題はあります。そのため、プロジェクトを通して少しずつ浸透させ、「時間がかかっても良いから、共通のやり方で進められる部分は揃えていこう」というスタンスで取り組んでいます。

    鈴木:こうしたツールを広める過程では、一方的に「こうしてほしい」と押し付けるのではなく、現場の要望を聞き、ツール開発の意図や、仕事の進め方、アイデアなどを話し合うことが重要です。こうした対話を通じて、新しいスタッフがチームに合流しやすくなる風土も醸成されます。

    小森:「こうやると便利だよ」という口コミを広めていくことも重要で、便利なツールによって現場の仕事が楽になると理解できれば、多くのスタッフが使用するようになります。一方で、使い方がわからない、マニュアルだけだと理解が難しいといった理由で、現場での採用が進まない場合もあります。そのため、ときには説明会を設けるなどして現場に浸透するよう努めています。

    パイプラインとワークフローは切り離して考える

    鈴木:パイプラインプロジェクトを開始する際には、パイプラインとワークフローを切り離して考えることも重視しました。ワークフローはプロジェクトごとに異なりますが、パイプラインは共通の基盤として構築するべきだという考え方です。

    ワークフローはプロジェクト開始時に設計しますが、その設計通りに最後まで進まないこともあります。この場合は、現場の仕事の進め方や、必要な考え方を吸い上げることが重要です。このフィードバックに際しては、実際にプロジェクト内で手を動かしているスタッフが生きた意見をもっていることが多いので、よく意見を聞き、パイプラインプロジェクトとの間で一方通行になってしまわないように心がけています。

    パイプラインに関しては、プライオリティがあります。大別すると、「ここは厳守してほしい」という部分と、「ここはプロジェクトの裁量で運用方法を決めて良い」という部分に分かれます。プライオリティは「リソースや成果物を管理する」、「ストレージの過剰な使用を避ける」といった目標を基に決定します。その目標が達成できていれば、プロジェクトごとの事情に合わせて運用方法を柔軟に変更しても構いません。

    小森:例えば、パブリッシャーを使用する場合に最低限押さえておくべきポイントは、「成果物を決められた場所にアップロードし、バックアップを取ること」と、「プロジェクト終了時に不要なデータを削除すること」です。まず最低限これさえ守られていれば、それ以前の工程でいつパブリッシュするかはプロジェクトリーダーの判断に任されます。あるプロジェクトでは、「長期で関わる人数が多いので、工程が次に引き継がれていく度に、パブリッシュを行う」と決めて運用し、別のあるプロジェクトでは「短期で納品されるので、全ての作業が終了してから、一括でパブリッシュする」と決めて運用するといった具合です。効率的にプロジェクトが進行され、大きな目標が達成されていれば、どの運用方法でも問題ありません。

    後編は2月公開予定です

    痴山紘史

    日本CGサービス(JCGS) 代表


    大学卒業後、株式会社IMAGICA入社。放送局向けリアルタイムCGシステムの構築・運用に携わる。その後、株式会社リンクス・デジワークスにて映画・ゲームなどの映像制作に携わる。2010年独立、現職。映像制作プロダクション向けのパイプラインの開発と提供を行なっている。

    TEXT_痴山紘史/Hiroshi Chiyama(日本CGサービス)

    EDIT_尾形美幸/Miyuki Ogata(CGWORLD)
    PHOTO_弘田 充/Mitsuru Hirota