本連載では、CG映像制作におけるテクニカル系スタッフの仕事の現状と課題を、パイプライン開発の専門家である痴山紘史氏(日本CGサービス(JCGS)代表)が探っていく。第7回 前編に続き、後編でも、白組の制作チーム間の橋渡しを担う、パイプラインプロジェクトと呼ばれている活動を、入田尭光氏(システム部長)、小森啓裕氏(制作第4部 部長)、鈴木健之氏(制作第3部 部長)へのインタビューを通して深掘りする。

記事の目次

    プロジェクトの開始時や、パブリッシュ時の仕様

    小森啓裕氏(以下、小森):パイプラインプロジェクトの各種仕様や、SSS(Shirogumi Server Structure)に関する解説、各種ツールマニュアルなどはポータルページに掲載しており、社内の全員が閲覧できるようになっています。各制作チームのスタッフは、このページを見ることで、パイプラインプロジェクトに関するあらゆる情報を知ることができるよう、ミーティングの実施状況を含め、細かく情報を開示するよう努めています。

    前編でも紹介した、パイプラインプロジェクトのポータルページ

    小森:プロジェクトを開始するときには、最初にプロジェクトごとの仕様、OCIOの設定、ツールのバージョンといった情報を記述した.prjファイルを使用することで、プロジェクト開始時の準備にかける時間を短縮できるようになります。これには雛形となるファイルがあり、専用エディタで編集できるようにしています。

    ▲プロジェクトごとの環境変数や、DCCツールごとのプロパティ、関連するパスやキーなどの各種プロパティを一元管理・編集するために、SHIROGUMI Meta File(sMeta)と呼ばれる様々なファイルがある。上の画像は.prjファイルを編集するための専用エディタ(prjEditor)

    小森:ランチャーを使用してアプリケーションを起動するときには、.prjファイルを基に実行環境を容易に作成できる状態を目指して、しくみ化を行なってきました。


    ▲.prjファイルと連動し、プロジェクトごとの仕様に沿って環境変数などの設定を行い、DCCツールを起動するためのランチャー

    ▲アーティストでも.prjファイルに則ってDCCツールの起動ファイルを容易に作成できるように、UIなどを刷新し、機能を強化したProjectCenter2を現在開発中だ
    ▲パイプラインプロジェクトで開発している、RenderTool2(for 3ds Max)と、CameraTool(for 3ds Max)。RenderTool2は、Render Submitterや、AOVの管理、独自のSceneStateなどの機能を実装している。CameraToolは、カメラの画角、レンジ、オーバースキャンなどの管理と、プレビューの出力・管理ができる。RenderTool2とも連携する

    小森:サーバのディレクトリ構造はツールとの連動を考えて3階層目くらいまでを基本構造として定めていますが、それ以外はプロジェクトごとに変えても支障がないしくみを取り入れています。パブリッシャーのようなツールも、細かいところは運用中に変わっても問題ないように厳密な管理ルールは設けず基本フォルダ内にある必要なものだけを一式アップロードするしくみにしています。

    ツールを通してレンダーファームにサブミットした情報は、メタデータ(.subデータ)として蓄積されるようにしています。これにより、同じジョブをもう一度実行したり、ほかの人が見たりしたときに、そのデータができあがった経緯を知ることができます。

    その後、試行錯誤を重ねた結果、完成したアセットをパブリッシュする際には、サブミット時のメタデータを引き継ぐだけでなく、そのアセットの作成経緯(申し送り)、テクスチャなどのサブファイル、制作に使用したツールといった情報が、別のメタデータ(.pubデータ)として一緒に保管されるしくみを構築しました。これにより、作業工程をまたぐ際や、アセットのバージョンが更新されたとき、あるいは担当者が変更になった場合でも、必要な情報を手間なくほかのスタッフに共有できるようになりました。

    メタデータの活用はこれだけに留まらず、パイプラインプロジェクトで管理している全てのツールにはカウンターが付与されており、使用回数を集計できるしくみになっています。この情報を1年に1回確認し、「年間の使用回数が数回程度のツールはメンテナンスを停止する」「数万回以上使用されているツールはメンテナンスを強化する」といった意思決定に役立てています。

    ▲ポータルページにも、ツールの使用回数の集計情報が載っている

    小森:初めは「パイプラインと言われても、難しくてよくわからないし、導入する意味があるのだろうか?」と疑問をもつスタッフもいました。しかし、収集した統計情報を基に費用対効果を数値化し、具体的な成果として提示することで、多くのスタッフにその有用性を実感してもらうことができ、かなり理解を得やすくなりました。

    この取り組みを本格化してから、紆余曲折を経て7〜8年の歳月がかかりましたが、活動を続けることで、徐々に基盤が整ってきたという手応えを感じています。一方で、パイプラインの導入を強制することはせず、常に「使えるようであれば、使ってください」というスタンスで、状況に合わせて使用者に判断を委ねることを大切にしています。

    プロジェクト終了後のデータ整理

    小森:もうひとつの重要な取り組みが、プロジェクト終了後のデータ整理です。プロジェクト終了時には、不要なデータを削除し、アーカイブが必要なデータは事前にパブリッシュした上でバックアップを実施します。これにより、次のプロジェクトのためのサーバ領域を確保することができます。

    プロジェクトのデータには、中間データや試行錯誤の過程で生じた履歴など、保管する必要がないものが多く含まれています。そのため、プロジェクト終了時にデータの整理が完了するしくみを構築しました。具体的には、以下のような手順を採用しています。

    1. ユーザーデータの整理とチェックアウト処理の実施
    プロジェクト終了時に、各ユーザーの作業データを最終確認し、パブリッシュ漏れがないかをチェックした上で、チェックアウト処理を行なってもらいます。この処理を通じて、各ユーザーが使用したデータ容量を集計します。

    2. 不要データの削除
    全員のチェックアウト処理が完了すると、不要なデータを削除する処理が実行できるようになります。アーカイブが必要なデータは事前にパブリッシュが済んでいるため、バックアップデータを必要最低限に抑えることができます。

    ▲ProjectCheckOut:プロジェクト終了時にユーザーごとのチェックアウト処理や、データ使用量などの集計を行うツール

    ▲ProjectCheckOutEditor:各ユーザーの情報や、チェックアウト状況をプロジェクト単位で編集・確認するツール
    ▲SSSTempCleaner:不要な中間データを削除するツール。アセットやショットに関する、一定期間のバックアップが必要なデータは、パイプラインプロジェクトで開発している各種パブリッシャーによって事前にパブリッシュされ、必要に応じてアーカイブされる。それ以外のデータは本ツールを用いて削除され、空いた領域はほかのプロジェクトに転用される

    小森:この取り組みを始めたきっかけは、プロジェクトの大型化によるデータの肥大化と、円安によるサーバ費用の高騰でした。プロジェクトごとにサーバ領域の確保が必要で、その度にサーバを増強するコストが問題となっていたのです。

    しかし、データ整理の必要性を認識しても、どのデータを削除すべきかシステム部だけでは判断できず、スタッフに聞いても「リーダーに確認してほしい」と言われ、リーダーに聞くと「スタッフに聞かないとわからない」と言われる状況が続き、結局削除が進まないという課題がありました。

    トップダウンで不要と判断したデータを一律に削除する方法も考えられますが、実際に何を残し、何を削除すべきかは現場の状況に応じて判断するのが最も適切です。そのため、データ整理のプロセスをしくみ化し、以下の運用が定着するよう取り組んでいます。

    1. 必要なデータを決められた場所にアップロードする、パブリッシュの推進
    2. プロジェクト終了時にデータの確認とチェックアウト処理を行うしくみの導入

    この2つの運用をセットで行うことで、パブリッシュは、工程間のやり取りに留まらず、データ整理や、バックアップ、サーバ領域の確保といった広い視点からも重要であるという意識がスタッフに浸透していくよう努めています。

    サーバのディレクトリ構造が共通認識として社内に広まった頃から、この取り組みが一気に加速しました。パイプラインは全てディレクトリ構造に依存しているので、それが決まらないと、どのツールも全ての構造に対応する必要が生じ、開発工数が肥大化します。

    サーバ内のディレクトリ構造が統一されたことで、ランチャーを活用した環境設定や、メタデータの有効活用といった新たな段階に進むことが可能になりました。

    一方で、パイプラインプロジェクトでは、今のところシーンアッセンブル系のツールは開発していません。というのも、ショット作業においてはプロジェクトごとに求められる表現が大きく異なるからです。例えば、セル調のアニメーションと、実写のVFXとでは、シーン構築の方法が変わります。Pencil+を挟むだけでも、シーン構成が大幅に異なることがあります。

    このように、プロジェクトごとに必要とされる内容が大きく変わるため、その部分については従来どおり、プロジェクト内で必要に応じて開発するスタンスになっています私たちは、作業領域を明確にしたり、メタデータを格納するルールを定めたり、ランチャーを介してツールを簡単に起動できるしくみを構築したりといった、インフラ面の整備を優先しています。

    鈴木健之氏(以下、鈴木):とはいえ、ショット作業に対して完全にノータッチというわけではありません。大規模プロジェクトの際にはよく相談を受けており、その中で「このしくみは便利だから、次のバージョンでは仕様として組み込もう」といった情報交換は日々続けています。

    新しい技術を導入する際の姿勢

    CGWORLD(以下、CGW):白組では、パイプライン整備に留まらず、『Fate/Grand Order -終局特異点 冠位時間神殿ソロモン-』でのKATANA導入や、『STAND BY ME ドラえもん 2』でのACES・OCIOの採用『SILENT HILL f』でのアジャイル型フローの採用など、各プロジェクトで挑戦的な取り組みを進めている印象があります。こうしたチャレンジを推進するモチベーションの源泉はどこにあるのでしょうか?

    小森:当社には、新しい技術が業務効率の向上や画づくりに貢献するのであれば、積極的に導入を試みる風土があります。

    例えば最近は、「Blenderを使用したい」というスタッフが増えています。しかし、チームやプロジェクトで利用するとなると、様々な課題をクリアする必要があります。レンダリングのサポートが可能か、納品スケジュールに対応できるか、リグやアニメーションを含む全工程を移行できるか、ほかのソフトウェアとの連携手法を確立できるかなど、多岐にわたる検討が求められます。それでも現場のモチベーションが高まっている場合は、まず個人レベルでの導入を試みつつ、良い部分を可能な範囲で取り入れ、チーム単位での本格的な運用にもチャレンジしています。

    加えて、機材を含む様々なコスト上昇への中長期的な対応策、当社が得意とするフルCG作品や長尺作品をつくり続けるための体制維持などを見据えて、日々のプロジェクトの中で技術基盤を少しずつ改善していくことを意識しています。

    新技術の導入は、準備期間なしにいきなり大規模に進めても成功しません。例えばUSDを導入する場合、データのつくり方に対する理解が必要ですし、HoudiniのSolarisを使うのであれば、それを扱えるスキルを備えたスタッフが不可欠です。そのため、過去のアセットを流用しやすい続編プロジェクトや、シンプルなアセットのみで制作が完結するプロジェクトで試験的にUSDを使ってみるなどして、制作チーム単位で小規模な導入から始めています。その上で、導入結果をほかのチームに共有したり、段階的に導入の規模を拡大したりできるように、日々情報交換を行なっています。

    実際、制作第4部において、MayaとSolarisを使っている現在進行中のプロジェクトがあるのですが、その前段階では、BlenderとSolarisで制作するショートアニメーションのシリーズ作品のプロジェクトに挑戦していました。

    Blender、Solaris、Arnoldを併用するプロジェクト用に開発したツールの一部

    ▲Blenderのアセットデータ、およびショットデータのUSD出力用に開発したツール。USD出力機能に加え、カメラ対応や、出力時の追加処理、バッチ処理などの機能も実装している
    ▲Houdini上のUSDアセットデータと、USDショットデータのローダー

    ▲Solaris上で構築したツリーの一例

    小森:現在進行中のUSDを活用しているプロジェクトは、それ以前のプロジェクトで得た知見やツールを基に、経験者を中心にライティング担当者を増員し、USDとSolarisに関する知見をパイプラインプロジェクトのツールにも組み込んでいけるよう、検証を行いながら進めています。

    Maya、Solaris、V-Rayを併用する最新プロジェクト用に開発したツールの一部

    ▲Mayaのアセットデータ、およびショットデータのUSD出力用に開発したツール

    ▲Houdini上のUSDアセットデータと、USDショットデータのローダー。本プロジェクトでは、HDA(Houdini Digital Asset)からツール形式に移行した
    ▲Solaris USD Deadline Submitter for V-Ray:以前のプロジェクトで前身となるArnoldに対応したツールを開発しており、本プロジェクトにてV-Rayにも対応し、機能を強化した

    小森:新しい技術の導入は、リーダーが選択する場合もあれば、スタッフの提案から始まることもあります。Blenderの導入は、スタッフの提案がきっかけでした。「使いたい」という声が多かったため、条件が整ったプロジェクトにおいて「次は試験的に、Blenderのみで1本制作してみよう」と応じたところ、「本当にやるんですか!?」と驚かれましたけどね(笑)

    リーダーとスタッフの双方から自由に意見が出てくる環境でないと、こういう試みはなかなか上手くいかないように思います。新しいやり方を試すことは、慣れ親しんだ環境から離れることを意味します。最後の力技ができなかったり、日常的に使っているツールを使えなかったりといった制約は、とても怖く、および腰になりがちです。一方で、新しい技術が本当に自分たちに合っているのか、使いものになるのかは、導入してみなければわかりません。だからこそ、少しずつ新しいことに取り組みながら、スタッフ間で知識や経験を共有・蓄積していくプロセスが当社では重視されています。

    とはいえ、試験的に触ってみるだけでは、その技術の本当の使い勝手や有効性はわかりません。実際のプロジェクトでしっかり画が出るまで使い切ることで、初めてその技術の価値を正しく評価できると思っています。

    プロジェクトで得られた知見は、スタッフ間でカジュアルに共有されています。例えば、経験が浅い中で、セル調のアニメーションのプロジェクトを始めるチームがあれば、経験のあるチームに相談します。

    鈴木:プロジェクトの初期段階で経験者に混ざってもらうこともあります。当社の制作チーム間にはあまり壁がないので、気軽に情報交換をしていますね。

    小森:ソフトウェアの使い方などのスキルは、時代がどんどん移り変わる中で、いずれは不要になります。そんな中でも、変わることなく必要とされる技術は残り続け、自然と共有され、多くのスタッフが使うようになります。一方で、試してみたけれど残らなかった技術については、必要ないものと割り切り、執着しないようにしています。

    テクニカルスタッフの採用・育成

    CGW:テクニカルスタッフを育成する上で心がけていることや、課題として感じていることも教えてください。

    小森:当社のWebサイトの採用ページでは、現在はテクニカルスタッフを公には募集していませんが、興味のある方からの応募はいつでも大歓迎です。専門的な知見を活かして、開発やしくみづくりに参加なさりたい方がいらっしゃれば、ぜひご応募いただければと思います。最近はアーティストとして採用したスタッフで、テクニカルにも興味のある人が、スキルを伸ばしていくかたちも多く、興味をもった技術を伸ばしてもらえるようサポートしています。

    入田尭光氏:具体的には、プロジェクトを通じてその人の得意分野を見極め、テクニカルに強いと感じた場合はその方向性でサポートします。例えば、次のプロジェクトで挑戦する機会をつくったり、関係する打ち合わせに参加してもらったり、その分野に詳しいスタッフと一緒に仕事をしてもらったりして、成長を促していきます。

    小森:その結果、日常や面談のときなどに、「自分はこれが得意です」とアピールできるようになれば、さらに踏み込んだ役割を任せていきます。実際に、コンポジターでありながらパイプラインプロジェクトのメンバーでもあるスタッフが、積極的にコンポジット系ツールの開発に取り組み、活躍している例もあります。

    白組には様々なチャレンジを推奨する風土があるので、「自分の専門分野以外にも挑戦したい」といった好奇心がある人には非常に向いている環境だと思います。

    鈴木:技術的な内容であっても、わかる人だけで固まるのではなく、チーム全体で情報を共有するので、多くのスタッフの興味を喚起できるという側面もあると思います。例えば「試しにアニメーションもやってみる?」、「スクリプトを書いてみたらどう?」というように、気軽に促すこともあります。役割を固定せず、「いろいろ試してみたら?」と背中を押す白組の文化は、昔から変わりません。

    小森:私たちは、「作業を頼む側」と「作業を頼まれる側」という関係性ではないように思います。目の前の課題をどう解決するかを一緒に考え、真剣に取り組む中で、スキルは自然と身についていくと思います。そして、いつの間にか以前は難しかった課題をクリアできるようになり、それが結果的に成長につながっているのだと思います。

    筆者まとめ

    白組のパイプラインプロジェクトは、10年以上にわたる現場主導の取り組みを通じて、新しい挑戦と豊富な知見の蓄積を続けています。この文化は、白組を単なる制作会社ではなく、一種のクリエイティブなコミュニティとして機能させているように感じました。ほかの組織が一朝一夕に真似することは難しい、この独自の強みこそが、白組が長年にわたり優れた作品を生み出し続ける力の源なのではないでしょうか。

    痴山紘史

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

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

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

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