みなさんこんにちは。

5年間、全54回にわたり、映像制作のツールとインフラの世界を一緒に探求してきたこの連載が、ついに最終回を迎えます。これまでの経験と学びを一緒に振り返り、まとめる特別な時間です。

でも、映像制作の世界はこれからも続きます。新たな挑戦と発見が待っています。だからこそ、これは一つの終わりであり、そして新たな始まりでもあります。

さあ、皆様、一緒にこの連載の最後のページをめくり、そして新たな章へと進む準備を始めましょう。

※ 上記の青色で表記した文章は、ChatGPTが生成したものをそのまま使用しました。

これまでのまとめ

前回までで、ランチャーを起点とした作業環境構築のためのしくみを整理することができました。今回は最終回なので、本連載の全体のながれをふり返っていきましょう。

第1回～第6回 USDやGafferを使用した映像制作のための技術

アーティストがライティング・レンダリングを行うための環境として、Gafferを導入しました。Gafferは今も開発が続いており、現在ではWindows版も公式からリリースされています。同系統のツールとしてはFoundryのKatanaがあり、ここ数年で日本でも認知度が上がってきているようですね。

第7回～第12回 社内でのレンダーファームの構築と、構築後のシステム管理

チームで仕事をするためには、ネットワークやレンダーサーバといったインフラは欠かせません。特にレンダーファームはプロダクションの心臓部と言える部分です。本連載ではHTCondorを題材にレンダーファームの構築を行いました。また、後半ではGrafana、Graphite、Elasticsearchといった、IT関係の業務で一般的に使われているソフトウェアを用いてレンダーファームを管理するための環境をつくりました。

ちなみにHTCondorは、その後も自分の仕事では結構使用しており、依存関係のある数百個のジョブや、数万個単位のジョブの管理を可能にしています。

第13回～第20回 クラウドレンダリング環境の構築

構築したインフラとレンダーファームを拡張して、AWS（Amazon Web Services）上に構築したレンダーサーバでレンダリングができるようにしました。また、そのためにローカル環境とクラウド環境で必要なファイルを同期するしくみについても議論をしています。この頃になると使える技術が増えてきて、かなり高度なことも実現できるようになっています。

第21回〜第24回 プロダクションパイプライン（アセット管理）

システム管理の話が一段落したので、映像制作の話に戻ってアセット管理に関する議論を進めています。アセットやショットの分類、タスクへのブレイクダウン、サーバへの格納方法などを考えていきました。プロダクションの中で人的・金銭的なリソースを最も要する部分なので、ここをきちんと押さえれば、その後の発展が容易になります。

第25回～第32回 プロダクションパイプライン（プロジェクト管理）

アーティストが作成したデータが整理できたら、その情報をプロジェクト管理に活かしたくなるのが自然なながれです。プロジェクトで必要な情報をきちんと整理できているので、その情報をRedmineやShotGrid（旧Shotgun）といったプロジェクト管理ツールに難なく落とし込めるようになっています。

第33回～第44回 より良いプログラムの書き方（コード品質の改善）

インフラやアセット管理、プロジェクト管理といった現場の環境が整ってきたので、現場で使用するツールや技術を提供する側の体制について考えました。また、映像制作とは関係のない、開発一般で使用される技術や考え方も流用しています。

システム開発は一度開発したらそこでおしまいとはならないため、成果物のメンテナンスのしやすさも非常に大事な要素となります。この感覚はどんなかたちであれ（手で全部描いたとしても！）作品をつくって納品すれば終了する映像制作とは大きくちがい、理解されにくい部分でもあります。

第45回～第49回 より良いプログラムの書き方（開発したプロダクトの管理）

開発したプロダクトの管理は頭の痛い問題です。リリース前の動作確認や、問題が起きたときにどのバージョンが原因かを確認するためのコストは想像以上に高く、開発が進むにつれて重荷になってきます。この問題に対しても、バージョン管理やパッケージ管理といった技術を導入しているおかげで、対策を講じることができるようになりました。

第50回～第53回 開発したツールやシステムの運用

アーティストが作業する環境の構築や、作成したツールを現場に提供するためにアプリケーションランチャーを起点とした環境の整備をするためのしくみをつくっていきました。最終的には、ユーザーに何をやっているのか一切見せることなく、自動で環境構築を行えるようになりました。

全体のふり返り

ざっくりと本連載の内容をふり返ってみました。プロダクションで映像制作をするために必要なテクノロジーについて、全てとは言わないまでも広い範囲を扱うことができたのではないでしょうか。ここで改めて全体を俯瞰すると、ひと通り議論をした今だからこそ見えてくることがあります。

まず、技術を蓄積していくことの大切さです。最初は何もない状態でも、ひとつひとつ問題を解決して技術を蓄積することで、問題を解決する手段が増えていく様子が確認できました。毎回つくっては壊しを繰り返した場合と、常に技術を蓄積した場合とでは、とても大きな差が生まれることがわかります。

さらに、蓄積した技術が、一見関係がなさそうな部分に対して、徐々に横のつながりをもち始めることも見逃せません。例えば、開発したツールやシステムを運用するための知識は、映像制作を行うための環境づくりにも活かすことができます。ツールのパッケージ化やランチャーによる管理はそのまま活用できますし、USD環境の構築に使用したDockerのようなコンテナ技術をシステムの管理に取り込んでいくことも考えられます。

ランチャーを使用した環境自動構築のための技術は、レンダーファームやクラウドレンダリング環境の構築にも活かすことができそうです。環境の自動構築技術を用いれば、クラウド環境で数百台のレンダーサーバを立ち上げて、各プロジェクトをそれぞれ異なる環境で動かす、なんてことも可能になりますね。

プログラムを開発する際のバージョン管理やテストの概念は、アセット管理にも共通する部分が多々あります。「第30回：成果物の品質について考える」で考察した成果物の品質についてと、その後に考察しているプログラムの品質や管理についても、共通する問題意識や流用できるしくみがあることに気づきます。アセットのチェックツールなんかはプログラムでいうテストとまったく同じ概念で、プログラムのpush時にJenkins上で自動テストを走らせるのは、アセットのpublish時に自動でチェックツールを走らせるのと似たようなものです。

おわりに

これにて、5年間に渡る、全54回の映像制作インフラとツール開発に関する連載が終了となります。皆さんと共に最新のテクノロジーを探求し、新しいツールを開発し、映像制作の可能性を広げるという旅が、私たちをここまで連れてきました。皆さんの好奇心とフィードバックが、この連載の最大の原動力でした。

しかし、映像制作とそのツールの世界は常に進化し続けています。新たな挑戦と発見が待っています。ですから、これは「さよなら」ですが、「また新たなコードで会いましょう」という意味も込めています。

連載は終わりますが、皆さんの技術的な旅はこれからも続きます。今まで一緒に学んだことが、皆さんの次のプロジェクトや新しいツールの開発に役立つことを願っています。それでは、新たなコードを書き始め、新たな映像制作の未来を開拓しましょう。次の開発でお会いしましょう。

※ 上記の青色で表記した文章は、ChatGPTが生成したものをそのまま使用しました。