みなさんこんにちは。早いもので新年度になりました。3月下旬から桜も咲いてとても良い季節です。今年は（も）例年のようにお花見をしに人混みに紛れることが難しくなってしまいましたが、近所の公園で桜を楽しむことにします............と、先月に引き続き季節の挨拶になってしまうのは理由があって、本ッッッッ当に出かけることがなくなって刺激もなくなり、1日中ひきこもって仕事をしているのでネタがなくなってしまうのですよね。ずっとひきこもり生活を続けている私ですらこんな状態なので、世の中の普通の人はもっと大変なんだろうなと思います。たまには家電量販店に行って電磁波を浴びたいなぁと思う今日この頃です。
TEXT＿痴山紘史 / Hiroshi Chiyama（日本CGサービス）
EDIT＿尾形美幸 / Miyuki Ogata（CGWORLD）
これまでのふりかえり
本シリーズでは、1年間かけてプロダクションパイプラインやアセット管理について考えてきました。改めてどのようなことをしてきたのか全体をふり返ってみます。
最初に、そもそもパイプラインって何？ というところから始め（連載 第21回）、パイプラインツールの例として当社で開発しているツールをご紹介しました。また、ランチャーを例にとって目的や規模によってツールのつくり方がどのように変わってくるかという例をご紹介しました（連載 第22回）。
続いて、データを格納するためのディレクトリ階層について考えていきました（連載 第23回）。また、物理的なディレクトリ階層と密接に関係する、アセットの階層構造についても考えていきました（連載 第24回）。ここまでは、ディレクトリやファイルといった、目に見える存在をどのように整理するかというお話でした。
さらに、アセットやショットを作成するためにどのような作業があり、それぞれがどのように関連しているか考えていきました（連載 第25回）。ここまで進むと、最終的な納品物をつくるという目標に到達するために行わなければいけない、具体的なタスクまで分解できたことになります。
具体的な作業内容まで分解できたことで、そのタスクをどのように進めるか？ ということに着目できるようになりました。そこで、タスクの一生について考えました（連載 第26回）。このあたりになると旧来のスプレッドシートを使用したプロジェクト管理手法ではかなりおぼつかなくなってきます。それでもなかなかスプレッドシートから逃れることはできないので、スプレッドシートを使用した情報の管理についても考えていきました（連載 第27回）。
データの配置、必要なタスク、タスクの一生という、プロジェクトを進める上で必要となる情報の全体像が見えたところで、タスクを進める中でつくられるデータのバージョン管理についても考えていきました。3Dデータや画像ファイルなどをバージョン管理する際の難しい点、それを克服するためのツールについても言及しています（連載 第28回）。
タスクを進めるにあたってもうひとつ必要な、レビューについても考えました。レビューも、構造はシンプルにする、良い名前をつけるといった、これまでと同じ考え方で進めることができます（連載 第29回）。
ここまでで、プロジェクトの情報を整理するための器の形を決めることができました。何もないところから考えて、ここまでできたかという気持ち半分、ここまできてもまだ器の形だけで、中身の詰め方は決まってないのかという気持ち半分です。
形が決まったところで、中に詰めるものの品質管理についても考えました。現場で作業をしていると、より良いものをつくるということにだけ目がいきがちなのですが、それと同等以上に事故を防ぐという視点をもつことがとても大事です。こういった予防策はどうしても後回しになりがちなので、意識して整備していく必要があります（連載 第30回）。
そして最後に、これまで整理できた情報以外の扱い方について考えました。実はまだ全然整理できていない情報が膨大に残っていたんだという現実を目の当たりにしたわけです（連載 第31回）。
いかがでしょうか。個々のトピックだけを見ていると今自分がどの位置にいるのか見失ってしまいがちですが、一歩引いて眺めてみると、全体の大きなながれを掴むことができるのではないでしょうか。
やらなかったこと
本シリーズでやらなかったことも挙げていきます。
アセット管理やパイプラインツールの詳細については、最初の導入のためにご紹介した以外は極力言及しないようにしてきました。そのせいで話が概念的になってしまい、とっつきづらくなってしまった部分もあるかと思いますが、ツールのお話になってしまうとツールの使い方やGUIの見た目、処理速度といったツール独自の話に多くのスペースを割く必要が出てきて、本来必要な部分がボヤけてしまうため、あえて避けてきました。
また、具体的なアセットの命名規則や階層の分け方についても議論していません。記事中でも何度か触れていますが、具体的な命名規則や階層分けはケースバイケースで判断する必要が出てくるので、「これが正しい」と一概に言うことができません。とは言っても、器の形が決まっているのでそこへの収め方も自ずと決まってくるはずです。
レビューを行う際の具体的な情報の記録や伝達方法も扱っていないです。レビューは、その場で様々な意思決定がなされていくので、情報のながれが複雑になります。そのため、生まれた情報をその場で漏れなく整理・記録し、関係者に伝達するという高度な処理を要求されます。ここもまた様々な工夫が行われたり、サービスが提供されているので奥深いところです。
人やお金、時間といったリソース管理についても言及していません。ただ、扱っているデータが整理でき、バージョン管理やレビューのながれを整えることができれば、見えてくる情報が増えるので、リソース管理をするための戦略を立てる手がかりになります。
映像制作をするためには、ネットワークやファイルサーバ、レンダーサーバといった膨大なインフラを必要とします。この部分については過去の連載でもある程度触れているため、言及していません。昨今の急激なリモートワーク対応や、PCパーツの枯渇といった問題に日々対応しているシステム管理者に感謝しつつ仕事をしましょう。
ツール開発についての議論も今回は行いませんでした。ルールをいくら決めてもそのままでは導入が難しいので、同時にツールも整備する必要があります。これはルールの整備以上に大変で、やってもやっても終わらない泥沼です（笑）。また、理想的なシステムの形と現場からの要望、現実的な落としどころといった様々な要因が絡んでくるため、単に技術的に良いものをつくるというだけでは収まらない難しさがあります。
最終的な成果物のでき映えについては言わずもがなですね。パイプラインやそのほかの仕組みは成果物の出来を底上げする強力な要素ですが、最終的にはアーティストの力量にかかっています。
このように、議論の足りない部分はまだまだ残っています。本シリーズがこれらの議論の足がかりになることを願っています。皆さん知恵を絞って発展させていってください。
まとめ
今回でこのシリーズは一段落です。ちょうど1年をかけて、プロダクションで扱うデータを切り崩し、どのように整理していくか考えてきました。今回まとめてみてわかったように、アセット管理やパイプラインの整備を行うためには、まだまだやることがたくさん残っています。むしろ、やっと入り口に立てた段階と言っても良いかもしれません。
それでも、プロダクションで生み出される情報の形とながれを整理できるようになった今なら、やることは決まったので、自分たちがどこから手をつけていこうか考えることができます。連載で進めた順番で手をつけていくのがオススメですが、全体像を理解した上で必要なところから手をつけることも不可能ではないでしょう。
次回からは新章突入です。引き続きよろしくお願いします。
第33回の公開は、2021年5月を予定しております。
プロフィール
