ハリウッドVFX業界就職の手引き

ハリウッドVFX業界就職の手引き
鍋潤太郎氏による、海外のVFX業界で働くための手引き。お薦めです。

2016年5月12日木曜日

Shotgunを使って見る その2

Shotgunのお話の2回目になります。前回はShotgunのようなワークフロー、パイプラインを支えるソルーションがどういうものなのか、ということと、それがどういうプロダクションに向くのか、向かないのか、ということについて軽く触れました。今回は、具体的なプロダクション・スケールを例にあげながら、こうしたソルーションを使うべきか、また自前でパイプラインを構築する場合の利点や問題点についてお話ししていきたいと思います。


10人以下のプロダクション、フリーランサー

まず、最初は最も小規模なケースから例にあげましょう。この規模だと、おそらく日々の作業はエクセル表をメールでやりとりする程度で済んでしまうことが多いのではないでしょうか。パイプラインも、プロダクション全体としてはディレクトリ・ストラクチャが大まかに決まっている程度で、あとはアーティスト任せ、というケースが多いと思います。この規模でも本格的なプロダクション・パイプラインを導入することにメリットはありますが、おそらくコストと天秤にかけながらということになるでしょう。

10人以上、50人未満

50人未満、というのは実のところあまり根拠のない数字ですが、おそらくこの範囲に収まるプロダクションが日本では非常に多いでしょうから、例にあげました。この規模になると、エクセル表のやりとりだけではさすがに厳しくなります。データベースやウェブ・サーバーの導入などを検討するようになる規模ですが、とはいえこれらのシステムを維持するためだけに専属のエンジニアを雇う余裕もあまりないでしょう。ということは、この規模になるとShotgunのようなクラウドのプロダクション・パイプライン、ワークフロー管理システムを使うことは、かなり自然なことであると考えていいでしょう。ただし、前回も指摘しましたが、社内のすでにあるパイプラインとこうしたサービスをフィットさせるためには、ある程度の開発コストがかかります。そのため、逆に全てのワークフローをShotgunに合わせてしまう、というやり方も1つの手です。

50人以上

この規模になると、すでに専任のパイプラインTDがいて、自前のパイプライン、ワークフロー管理システムを立ち上げていてもおかしくない規模です。そうなると、逆にShotgunの導入には慎重になった方がいいでしょう。既存のパイプラインとShotgunを繋ぎあわせる手間や、アカウント数に応じてサブスクリプション・フィーを払わなければならないことを考えると、そのまま独自でやった方がいい可能性も出てきます。独自でやる最大のメリットは、プロダクションの要求に合わせて柔軟な体制を敷けることですが、そうはいってもデータベース・サーバーやウェブ・サーバーは既存のものを使ってシステムを組むことになるでしょうから、何がベスト・プラクティスになるかを判断するのは難しいところです。MySQLのようなリレーショナル・データベース管理システム(RDBMS)は、最初のデータ設計が非常に重要で、映像制作の現場の技術的要件のように増えたり減ったりする情報項目を管理するのが難しい、という考え方もあります。複雑な検索よりも素早い情報の引き出しが求められるため、MongoDBのようなNoSQLデータベースを支持する向きもあります。こう書くとハードコアなRDBMSの支持派からは「MongoDBのどこが高速なんだ、言ってみろ」と怒られそうですが、実際のところCGのレンダリング・ディスパッチャとして広く使われているDeadlineはスピードを理由にMySQLからMongoDBに乗り換えた、と聞いています。これはレンダリングのジョブ管理が、複雑な検索よりもログなどの素早い読み書きに重きを置いているためというのがあるのでしょう。

しかしながら、この規模でもShotgunのようなソルーションを使うメリットがないわけではありません。例えば、外注先や協業会社とスケジュールやタスクの管理を共有したい場合、自前でデータベースを立ち上げると、こうした外部の会社との情報の共有は難しくなりますが、Shotgunのようなネット上のサービスであれば、共有は比較的簡単です。ただし、これもそうした外注先や協業会社がShotgunのようなサービスを導入していることが当然ながら前提になります。

Shotgunを使うことにデメリットはないのか?

私の個人的な考えでは、Shotgunのようなサービスを使うことにデメリットというのはほとんどないと思います。強いて言えばコストということになりますが、Shotgunのサービスはサブスクリプション形態をとっており、不要と感じれば解約すれば済む話ですから、リスクはかなり低いとみていいでしょう。しかし、導入するに見合った価値が得られるか、というと、これは導入する側の利用形態によって異なってきます。

まず、Shotgunは階層化されたデータ構造の変更に強くありません。Shotgunは各プロジェクトをSequenceとShotの階層に分けており、多くの場合はこれで事足りますが、テレビシリーズなどを手がけているスタジオなどはEpisodeのような階層もあったほうがいいでしょう。TACTICはこの階層を初めから取り入れているようですし、ftrackは階層のカスタマイズ自体が出来るようですので、Shotgunでも無理ではないのかもしれませんが、やや手をかけなければならないでしょう。

基本的にShotgunのようなサービスはクラウド上で扱えるデータのみの管理を目的としており、実際のCGの実データを管理できるわけではありません。ストレージのサービスはありますが、これはあくまで資料用の画像やサムネイル、ムービー・ファイル、メッセージの添付ファイルなどを保存するための領域です。これはCGの実データのサイズを考えれば理にかなっていることですが、社内のファイル・サーバーにあるデータと、そのデータに紐づけられたタスクをトラッキングするはずのShotgunの情報が手入力で同期させる必要があるとしたら、これはあまりメリットを感じられないでしょう。そのため、Autodeskではアセットの情報を主要なCGのアプリケーションからShotgunに送受信できるようにするアドオンなどを提供していますが、もしそうしたアドオンでは対応しきれない場合は、APIなどを使って自前で開発することを勧めています。このAPIに関しては、次回に実例をあげながら説明していきたいと思います。

APIといえば、Shotgunはデータの連携、例えば、特定のタスクのステータスの変更に応じて、他のタスクのステータスが変更されたり、特定のイベントの発生に応じてメールを飛ばしたりといった、イベント・ドリブン型の機能が最低限度の形でしか提供されていません。これは、各ユーザーごとにどういった情報の関連づけがなされるか、ということは異なるわけですから当然と言えば当然で、そうしたカスタマイズもAPIを使って自分たちで定義してほしい、というのがShotgun側のスタンスです。Shotgunを初めて導入したユーザーも、初めはエクセルを回し書きしているレベルからShotgunのウェブ・アプリケーションに移ってその便利さを実感しますが、次第に複雑なことを行おうとすると、思いの外自前の開発が増えてくることに気付かされるようになります。Autodesk側でも恐らくそのことは気づいていて、何とかShotgunを、吊るしの状態のままでできることを増やせるように考えているようですが、基本万人向けに作らなければならないツールで全てのユーザーを満足させることは難しいですから、ユーザー側がAPIを使いこなすようになる方が現実的でしょう。

アセットを管理するアドオンについてちょっと触れましたが、これに関しては、弱いというよりちょっと扱いづらい印象を受けます。Shotgunでは主要な3DCGアプリケーションにそうしたツールが提供されていますが、ファイルの関連情報を拾い上げる仕組みがやや複雑で、これを理解できるくらいのプロダクションであれば、とうに自前のパブリッシュ・ツールやローダーを書き上げていてもおかしくないくらいです。既存のバージョン管理システムとの連携に関しても、今のところShotgunが直接サポートしているのはPerforceだけのようです。Perforceは良いバージョン管理システムですが、正直お安くはないですし、映像プロダクションで使っているところはそれほど多くないでしょう。

そして最後に、この手のサービスにありがちなことではありますが、日本語への対応がまだ未熟です。Shotgunでは各データ・タイプにカスタム・プロパティを追加することができますが、これが日本語だと、APIから検索するための名前がうまく引き出せない、といった問題がありました。もっとも、この点に関してはAutodesk Japanが今後対応を進めていくと思いますので、ftrackやTACTICよりは分があると言えるでしょう。

次回は、Shotgun APIの使い方を、実例を挙げて説明したいと思います。

0 件のコメント:

コメントを投稿

注: コメントを投稿できるのは、このブログのメンバーだけです。