Film Production Pipelines and Artist Techniques

映像制作パイプラインの実践と課題

Practice and issues of film production pipeline

（株式会社ポリゴン・ピクチュアズ / スタジオフォンズ）

(Polygon Pictures Inc. / Studio Phones)

本資料は会合後にディスカッションされた内容を踏まえ記載しています。今後の会合の状況を見つつ加筆修正を含めブラッシュアップを進めていく予定です。

■概要

■Overview

資料の前半では、会合中のポリゴン・ピクチュアズとスタジオフォンズからの講演「現在の映像制作パイプラインの実践と課題」で紹介した映像制作パイプラインの実践をもとにここでは説明を行いますが、比較的映像制作パイプラインに慣れていない方を念頭に、慣れている方には他の関連資料や事後資料を読み進めるための導入的役割として記載しています。後半部分では、現在の映像制作パイプラインとそのインフラにおける課題について多少のとりまとめを行い、アーティスト側、インフラ設計者側、クライアントやパートナーの目線で、これらの課題を解説して行きたいと思います。

この資料は今後も継続しブラッシュアップを進めていきますので、他資料へのガイドとしてもお役立て頂ければ幸いです。

under construction...

■映像制作パイプラインの実践

■Practice of film production pipeline

映像制作におけるパイプラインシステムの変遷は、多くのアーティストが制作に関わるなかで、アーティストの専門分野ごとに工程を細分化し分業制というワークフローのなかで発展してきたと考えると理解がスムーズに進みます。
一般的には大規模な制作ラインのなかで、工程間のデータの受け渡しのためのデータフローやインフォメーションフローを構築し、パブリッシュという行為で必要なデータを次の工程に渡します。またそれらを自動化することによってヒューマンエラーを無くしたり、アーティストがクリエイティブな作業により多くの時間を割けるように設計されていく、そのような流れも強かったとも思われます。勿論、それらは主だったケースを指しているという段階であって、実際には、ワークフローは各スタジオの規模やビジネス形態よって多様な発展を遂げています。それに伴い、パイプラインシステムも各スタジオごとに特徴があるユニークなものとして発展してきていますし、その事が有効に働いているからこそ、スタジオの多様な文化が育って来たと思われます。
そこで本資料では、なるべく各スタジオで共通して設計のなかに組み込まている事柄についてを取り上げつつ、パイプラインの実践上の課題に関して一定の解説を試みながら、今後の各スタジオの個別の発展に役立てばと記載して行きます。

映像制作の場合、制作のフローは大きく「Assets」と「Shots」の2つに分けられます。
Asset工程ではモデリング、リギング、ルックデブ（サーフェシング）といった工程でShot工程で必要となるデータが作成されます。
各工程の作業はなるべく並行して作業が行えるようにパイプラインシステムを組むことが一般的で、各工程で作業されたデータを「ビルド」という処理でShot工程に渡すためのデータとしてパッケージングされパブリッシュされます。
またShotの各工程の作業特性にあわせたかたちのAseetデータを提供する必要があるため、ポリゴン数がリダクションされたデータやアニメーション用のデータ、レンダリング用のデータなど複数のバリエーションのアセットを用意します。それらはパイプラインシステムとしてデータベースなどに全ての処理が記録され、後述のトラッキングを行っていくことになります。

Shot工程ではレイアウト、アニメーション、エフェクト、ライティング、レンダリング、コンポジティングといった工程で、作成されたアセットを使用しながら作業が進められていきます。
Aseet工程で作成されたバリエーションのなかから必要なものを選択して作業を開始し、作業が終わったデータを次の工程へとデータをパブリッシュしていきます。
ライティング工程の直前で各工程からのデータを集約し、ここでも「ビルド」（またはシーンアッセンブルと呼ばれる）とい処理で、各工程のデータからシーンを構築しライティングおよびレンダリングの作業を行なっていくのがよく用いられるフローとなります。

これらのワークフロー上でデータが正しく流れて受け渡されていくためにパイプラインシステムが存在します。各スタジオではDCCツールを拡張したり、専用のツールを作成することで自社のワークフローにあわせたパイプラインツールを開発していくことになります。
パブリッシュを行うためのツールはもちろんのこと、アーティストが作業をする際に、自身の作業に必要なデータを自動的に収集したり、複数のアーティストが同時並行で作業を行う上で、データの整合性がとれるようなリビジョン管理といったことは、パイプラインシステムのなかで担保されるべき機能となります。
パブリッシュされたデータはスタジオの各端末からアクセスできることが前提となるため、社内のネットワーク上のファイルサーバーなどに格納されることが一般的で、各アーティストはネットワーク越しにそれらのデータにアクセスします。

パイプラインの機能を一歩前へ進めると、これらパイプラインで扱われるリビジョンの情報やメタ情報、レビューを行なった際のコメントやステータスをデータベースシステムの中に格納し、より高度なアセット管理やショット管理を行なっていくことになります。
映像制作は多くのアーティストが関わって作業し、複雑なワークフローの上で映像が完成していきますが、各工程ごとにアーティストが作成したデータに対してレビューを行い、そのデータがチェックされていきます。クオリティ面のチェックは、一般的にはスーパーバイザーと呼ばれる各工程のアーティストを束ねるスタッフやディレクターなどが行います。またパイプラインシステムでは、そのデータがパイプラインのデータ仕様に則したものかをチェックし、これらのチェックをクリアしたパブリッシュデータのみが次の工程へと引き継がれていきます。
同時にパブリッシュされたデータのステータスやメタ情報、ログなどはすべてトラッキングされており、それらのデータもデータベースへと格納されていきます。
データベースシステムを利用することにより、パイプライン上の情報を一元的に管理することが可能となり、検索の高速化やデータの依存関係など、より複雑な情報を扱うことが可能になります。たとえば誰が、いつ、どこで、どのデータを、どのリビジョンでパブリッシュしたかなど、そのような情報も簡単にトラッキングすることができます。
また一元化されたデータを可視化するためのWebシステムを構築するこにより、プロジェクトに関わるすべての人が簡単にパイプライン上のデータや情報を把握し、必要なフォーマットで取得することができるようになり、レポート機能としても活用されます。制作体制の規模が大きくなればなるほど、これらのシステムは効果的に機能します。

レンダリング処理では、スタジオ内にレンダーファームと呼ばれる計算クラスター環境を構築し、処理負荷の重たいタスクをジョブ化して、分散処理する仕組みが必要となり、こちらもパイプラインシステムのひとつの機能となります。
計算クラスターの台数はスタジオの規模にもよりますが、数百台から数千台といった台数になることもあり、それらのジョブの実行スケジュールや優先順位を管理したり、計算リソースの割り当てと言った処理を自動的に行う仕組みをディスパッチャーと呼びます。
ジョブが割り当てられたマシンは、ネットワーク上のファイルサーバーからデータを読み込み、計算処理を実行した後に、計算結果をファイルサーバーに書き出すと言った動作をします。計算クラスターではレンダリングの処理以外にもシミュレーションやパイプライン上のバッチ処理など、ローカルの端末で実行するには負荷が高すぎて時間がかかってしまうような処理も計算クラスター側で分散処理し、処理時間を短縮する役割もあります。
またそのジョブにかかったシステムリソースや計算時間、実行ソフトウェアからのログなどもトラッキングされており、プロジェクトで必要となる計算クラスターリソースの予測や不具合やエラーが発生した際の原因調査のための情報として活用されます。
計算リソースの有効活用として、アーティストのマシンについても使用していない時間帯は計算リソースとして利用するスタジオも多く、たとえばアーティストが帰宅時にマシンをログオフするとそのマシンが自動的に計算クラスターなかに参加する、といった仕組みをパイプライン上で構築することも可能です。
スタジオ内では複数のプロジェクトが並行して稼働していることも多々あり、それらのプロジェクト間でのリソース配分やプロジェクトや工程をまたがったジョブの優先順位付けなどは、スタジオ運営では欠かせない仕組みとなります。

パイプラインシステムはスタジオの規模やワークフローに応じて様々ではありますが、共通して言えることは、スタジオの発展やビジネス形態の変化、利用するツールの変更などにより、その都度機能をバージョンアップしたり場合によっては設計そのものを見直して作り変える必要も発生します。
それらはある種スタジオの歴史や文化を色濃く反映するかたちとなり、ユニークな発展を遂げていくことにつながります。
下記はご参考までに、ポリゴン・ピクチュアズでのパイプラインの変遷についての資料へのリンクとなります。

「ポリゴン・ピクチュアズのパイプラインの変遷」
https://a-film-production-technique-seminar.com/fppat/materials/ppi_pipelinehistory/index.html

また、プリプロダクションやコンセプトアートなどのワークフローやパイプラインなどのご紹介については、会合3の資料
「コンセプトワークのパイプラインの設計の難しさ」
に記載しておりますので、よろしければそちらをご参照ください。

under construction...

■パイプラインから見たインフラの要件

■Infrastructure requirements seen from film production pipeline

前述のパイプラインを構築していくうえで、各インフラへの要件を下記にまとめました。
ここではインフラの要件をキーワードとして挙げて行きますが、これらは解説に専用のページを割り当てて、後日、会合6の「工程別インフラ要求の目安」で今後詳細な解説を行っていく予定です。

●ストレージシステム
・パイプライン上の共有データおよび作業データの格納
・高い信頼性と可用性（基本的にメンテナンス時以外は無停止/無障害が望ましい）
・NFS / CIFS / iSCSIなど、制作作業マシンに応じたプロトコルに対応
・細かなアクセスコントロール
・制作規模とワークフローに応じたI/O性能（例 : 実効スループット40Gbps）
・拡張性が高く、かつ柔軟なファイルシステム（制約が少ない）
・スタジオやプロジェクトの拡張ニーズに対応できるスケールアウト型
・キャッシュ機能またはそれに相当する機能や設計
・スループット、トラフィック、IOPSといった性能面のトラッキングとレポート機能
・ロギング機能

●データベースシステム
・一般的なRDBシステム（MySQL / PostgreSQL / MSSQL）
・ドキュメント型やグラフ型といったNoSQLシステム（MongoDB / HBase）
・分散ファイルシステムと分散データベース（Hadoop / Apache Cassandra）
・レプリケーション、バックアップ機能
・性能評価のためのレポート機能
・パフォーマンスチューニング可能な設計（主にメモリキャッシュとディスクI/O）
・高負荷時にも対応できる高いスケーラビリティ

●WEBアプリケーションサーバー
・軽量かつ高速なレスポンス（Nginx / Node.jsなど）
・高機能な処理に対応（Apacheの併用）
・Pythonフレームワーク（CG系ではPythonインターフェースをそなえているものが多いため相性がよい）
・コンテナでの実行が可能
・RESTfulに対応したモジュールやフレームワーク
・データベースとの接続
・モジュールによる拡張性

●計算クラスターと分散処理
・レンダリングのための分散処理インフラ
・シミュレーションのための分散処理インフラ
・実行スケジュールやリソース割り当てなど、ジョブ管理のためのマネジメントシステム（Dispatcher）
・パイプライン上のバッチ処理やマイクロジョブ実行のコンテナ環境
・実行プログラムに応じた、効率的かつ柔軟なリソース割り当て（CPU / GPU / メモリ等）
・スタジオやプロジェクトでの需要に応じた柔軟なスケール

●システム構成管理
・頻繁なソフトウェアバージョンアップに対応できるユーザー環境
・インストールやデプロイ処理などの自動化
・仮想化環境の活用とそのシステム構成の管理
・イメージ管理による実行環境
・柔軟なバージョンダウン
・セキュリティ脅威に対する迅速な対応

オンプレミスの社内インフラの例については、別の関連資料

「ポリゴン・ピクチュアズの社内インフラ」
https://a-film-production-technique-seminar.com/fppat/materials/ppi_infrastructure/index.html

で紹介していますので、そちらをご参考にしてみてください。

under construction...

■現在のパイプラインとインフラでの課題

■Issues in current pipeline and infrastructure

これまで映像制作のパイプラインはオンプレミスのインフラ環境で構築するのが一般的で、ストレージシステムやレンダーファームなどの計算クラスターサーバー、データベースシステムなどを社内のサーバールームなどに物理的なマシンとして稼働させ、その環境の上でパイプラインシステムを運用してきました。
スタジオの規模によっては数百台のサーバーや数百TBまたは数PBのストレージを配置し、それらを高速な10Gネットワークで繋ぐといった比較的大きいインフラを構築しています。
ゲーム業界ではゲームアセットデータの特性から比較的小規模なインフラ構成で十分となるケースが多く、ゲーム業界からみて映像業界のインフラの大きさに驚きの反応が会合中に見られました。

導入するシステムは4〜5年単位で償却を行うシステム投資となり、数年先の需要を見込みながら機種の選定やサイジングを行なっていきますが、CG技術周辺の進展や変化のスピードは早く、データフォーマットの変更や計算性能が向上することによるデータ容量の増加、利用するソフトウェアの変更による必要な計算リソースの増加など、導入時点で数年先の状況を正確に予測することは非常に難しいという課題があります。
誤った予測は過剰なシステム投資へとつながり無駄にコストを発生させてしまう原因にもなります。またそれとは逆に予測への見積りが足りず、インフラリソースが不足した場合、パイプラインのパフォーマンスを引き出すことができず、それらが制作上のボトルネックなり、アーティストにも多大なフラストレーションを与えてしまうことになります。インフラの設計はそのコスト構造故に経営陣と常に議論し設計を行っていく難しさを生じており、スタッフのスキルや仕事の速度なども加味し、それらの板挟みの中で設計を練る難しさが存在します。

予測に対しては、過去のプロジェクトを参考にしていくことが最も簡易的かつ現実的な対応策となります。過去のプロジェクトで使用されたストレージ容量の推移やレンダリングのためのサーバー使用状況、ネットワークトラフィックなどから、将来のプロジェクトでの需要を予測していくということです。
同様な形態で、同じ手法やワークフローを採用する場合はだいたい同じぐらいのインフラリソースが必要となりますが、すでに過去プロジェクトと異なるツールやワークフローを採用することが決まっている場合は、それらを加味して予測を立てていくことになります。
ツール内部で用いるアルゴリズムの進化もそこには加わりますので、実地の計算時間なども随時計測し、見込みとしての性能をより鋭く見積もりを行っていくことになります。その際、当然のとも言えますが、クライアントへの説明用にシステムとしての計測値なども文書に残して行き、設計内容を客観的に精査可能な体制を築きつつ、設計を事業計画などにフィットさせていくことになります。
減価償却などの会計的側面もそこで考えていくのですが、国内では馴染みのまだ少ない国際会計基準（IFRS）など、会計基準の違いも今後は視野に入れ考えていく必要のある領域です。
またアーティストの人数の増加やプロジェクト数の増加など、スタジオの規模が拡大していくことが予想されている場合は、それらも予測のなかに含めていくことが必要となります。
ここで重要となるのは、それらの予測を立てるうえで過去のプロジェクトでのインフラリソースの使用状況をトラッキングしてデータとして記録されていることが前提となっている点です。インフラ運用の観点からその瞬間や短期的なリソース状況をトラッキングする仕組みを導入しているスタジオは多いかと思いますが、プロジェクトのプロダクション期間は長いもので数年にまたがるものもあり、それらの情報を長期的に保持しておくような仕組みが必要となります。そこでの注意事項は多々ありますが、人間の感覚でしかない計算速度などは客観性を欠く以上記録には成り得ず、全ての情報はその取得の際のアルゴリズムの説明と組にして文書化していくことで、クライアントへの説明や、社内での引き継ぎ事項などに役立てていけることとなります。
ここで出した説明はあくまでも一例に過ぎませんし、いくら徹底しても100%完璧な予測にはなり得ません。しかしながら、予測の精度をあげていく上ではある程度効果が見込め、各社様々な工夫を行っていっているのが現状かと思います。

またインフラ設計において、予測しきれなかった変化に対応すべく可能な限りスケールのし易い拡張性の高いソリューションを選択することによって、それらのリスク回避してく方法も検討できます。ストレージシステムなどではスケールアウト型と呼ばれるシステムがあり、拡張性と性能向上を両立したソリューションとなるため、予想外の想定でもインフラを拡張することによってインフラのパフォーマンス不足を回避できるようになります。しかしながらそれらのソリューションは比較的高価なエンタープライズシステムとなるため、コスト面が最適化されている状況とは言い難い側面もあり、結果的にシステム投資のサイクルを長引かせてしまうこともあるので、そのバランスの見極めも重要となります。

一方で、スタジオでのプロジェクトからの需要はその特性上、時期によって波があり、それらのシステムの稼働率が年間を通して常に100%ということはありません。ところが可用性・信頼性の高いパイプラインシステムを運用していくには、それらプロジェクトのピーク時でも性能が落ちないインフラを構築・運用していくことが求められ、需要のピークにあわせたインフラ設計を行うため、必然的に無駄が発生してしまいます。
そのため、ある一定量のインフラリソースは社内のオンプレミスの環境に構築しながら、ピーク時にそれらのリソースでは足りなくなった分をクラウドサービスなど外部のインフラリソースを利用することができれば、システムの稼働率を高く維持することが可能となります。

また制作体制の複雑化からくるインフラでの課題も存在します。
これまでスタジオのイントラ内に大きなインフラを構築し、スタジオ内のみで映像制作を行うことが主流でしたが、近年では制作体制のグローバル化やアウトソーシング、ロケーションフリーなワークスタイルの増加などもあり、既存のインフラ環境ではそれらのニーズに対応しきれない状況も出てきています。
外部との情報やデータ共有のためのインフラや遠隔とのコミュニケーションのためのインフラ、小規模なブランチスタジオでも同じようなワークフローを実践できるインフラなど、より高度で多機能なインフラを求められてきています。
これらは単にイントラ内のインフラだけを意識しておけばよかったこれまでと大きく異なり、インフラやパイプラインシステムをスタジオの外部にまで拡張していけるような設計が求められいることを意味しています。映像制作のインフラの現場では、社内のインフラ構築には長けていても、Webシステムや外部ネットワークアクセスといったインフラを扱ったことがあるエンジニアが少なく、会合内でもそういったエンジニアの育成や獲得が課題となってしました。
これらの要求にうまく対応するために、クラウドインフラの活用やパイプラインシステムそのものをクラウドインフラ上に構築することで、これまでの制作フローを拡張していける可能性があり、近年そのような動きが海外のスタジオを含め活発になってきています。
Webシステムや仮想化技術などについては、他業界で進んだ部分もあり、それらのベストプラクティスを学びつつスキルアップをしていく必要を強く感じるとともに、インフラエンジニアに求められる要求もより高度なものになっていく時代に突入したと思います。

少し視点を変えて、これらのインフラの課題を使用するソフトウェアの側面からも検討する必要があるようにも思います。映像制作のパイプラインには多くのDCCツールを利用しており、それらのツールがインフラに求める要件はユーザーサイドではコントロールできるものではないため、基本的にはそれらのソフトウェアの要件にあわせるかたちでインフラを設計していく必要があるのが実情かと思います。
しかしながら、ソフトウェア側のインフラ要件をコントロールできることは、インフラ設計の自由度をあげることを可能にし、自社のニーズにあわせたかたちでインフラを最適化していける可能性を含んでいます。
もちろん便利な商用のDCCツールを手放すことの難しさはありますが、部分的にでもインハウス開発によるソフトウェア開発を進めることによって、インフラ面で享受できるメリットも生まれてくるのではないと考えられます。

under construction...

■クライアントへのパイプラインやインフラに関する説明

■Explanation about pipeline and infrastructure to clients

ある一定規模のアーティストが在籍する会社組織でインフラやパイプラインを構築する、海外の大型案件などを制作するためにインフラやパイプラインを構築する、アウトソーシングなど他社との連携の上でのパイプラインやインフラを構築する、広くパートナーへのサービスとしてインフラを構築する、など映像制作パイプラインではインフラの構築、パイプラインのデザインと言っても、あまりに多様な形態が存在します。
その際、クライアントやパートナー（アウトソース先全般を含む関係者全て）と自社の開発チームで、インフラやパイプラインを含め、CG全般に渡っての知識、ノウハウ、スキルやDCCツール内で用いるアルゴリズムへの理解などは、多くの場合まちまちな状況になっている事が多々あります。

しかしながら、ビジネスとして展開する以上、自然と説明しなければならない範囲が増えて行きます。それらは記録やマニュアルとしてドキュメントに残して行かない限り、社内での引き継ぎはもちろんのこと、開発時に参照した情報や技術文書も残らないことになり、外部と連携するなかでトラブルなどが発生した際に、その問題の特定さえ出来ないような状況を発生させてしまうことになります。

多くの場合、インフラ設計やパイプライン構築の担当者や責任者などがそれらの議論のなかには必ずといっていい程度に存在しているわけですが、インフラ設計時やパイプラインのデザインしていくなかで、これらをその責任者を中心としてまとめていく事が必要になって来ます。逆に言えば、そのような過程を踏まえていなければ、クライアントのアセスメントの通過はおろか、審査の土台に上がる事さえ難しい状況を生じさせるとも言えるかもしれません。その際の引き継ぎ事項としては、システムの構成そのものは勿論ながらも、そのシステム構成を選んだ際の資料や決定した理由、特殊なアルゴリズムを採用した際は、そのアルゴリズムを理解し説明出来る社内責任者（ほとんどの場合、研究者レベルの知識保有者でしか務まらない）などを記載し、トラブルが生じた際の対応計画やそこでの試算としての復旧コストとプランBとしての同様の計画、などなど、関係している国や企業が増えていくほどに、それら引き継ぎ事項のほとんどは非常に高度なレベルを要求していきます。

しかしここには大きな問題が存在します。前述の通り、クライアントやパートナー（アウトソース先全般を含む関係者全て）と自社の開発チームで、インフラやパイプラインを含め、CG全般に渡っての知識、ノウハウ、スキルやDCCツール内で用いるアルゴリズムへの理解などは、その関係者同士の知識や立場などの違いを適切に反映してドキュメント化していくことの難しさが存在します。関係者内の相手がその領域への知識が無いからと言って、インフラの設計やパイプラインのデザインを単独で進めることは基本的に出来ない事が多いのが通例です。顧客や取引先がこれらの難度高い知識がわからないからと言って、説明を放棄することは企業である以上許容されるものではありません。その対応が妥当かどうかを説明し、そのコストが幾つかの選択肢と比較しどのような理由で採用されたかを顧客や取引先に説明することになるでしょうし、それを行っていない場合はそもそもビジネスとして成立しません。
しかしながら、これらのことを顧客や取引先に行っていくのは非常に難度が高いものになります。それゆえに、パイプライン構築はインハウスでの開発で行うことが自然と多くなり、インハウスであっても担当者や責任者を立て、経営層への細やかな意思確認を行いつつでしか進められないと考えられています。逆に言えば、パイプラインの設計を独断で出来る場合は、経営レベルへ意見を言える立場でインフラ設計やパイプラインのデザインが出来る場合などの、限られたケースであると言えるでしょう。スタジオの会社組織に根ざした設計が、パイプラインの設計には必要にはなっていくということです。

企業としての説明責任など様々な視点で考えると、ビジネスとしてアウトソース先やクライアントなどと連携を構築する以上、必要な説明は可能な限りドキュメントとして残していく必要があるわけで、実質的に、知識差のギャップを埋めていく必要があると考えられています。またその逆の立場として、クライアントからのアセスメント時には、これらの知識差を埋めて行くためのコストも込みで選定されて行っているとも言え、知識レベルの差を埋める事を避けた状態で連携が進むことはなかなか考えにくい状況であると思います。言い換えると、グローバル化を推し進めていく意思のあるスタジオであるほど、海外展開のためにその会社組織の最適化を行う際に、同時にインフラやパイプラインの設計構築を行うことがあるとも言えます。ビジネスの企画段階から関わる重要なパートであるこれらインフラ、パイプラインのデザインは、今後さらに会社の経営と密接に関わりながらでにしか展開出来ないと予測されています。

この事実は昨今、クラウドインフラの業界内への広がりなどにより、加速化する形で問題になって来たように思います。パテントやライツなどの知識をスタッフやアウトソース先、クライアントなどと共通認識を持って進めていくことの難しさがそこにあります。
インフラの管理上のチェック範囲の広がりのページで詳細にこの問題は説明していますが、今回の会合からも、技術文書の在り方への共通認識を今後は考えて行かないといけないかもしれない、そのように思われました。

下記ページで更に入念な説明を記載していますので、ご参考にして頂ければと思います。

インフラの管理上のチェック範囲の広がり
https://a-film-production-technique-seminar.com/fppat/materials/ppi_phones_infra_check_scope/index.html

クラウドインフラとマイクロパイプラインの詳細
https://a-film-production-technique-seminar.com/fppat/materials/ppi_phones_micro_pipeline/index.html

求められていく研究開発のスタンスの変化
https://a-film-production-technique-seminar.com/fppat/materials/ppi_phones_rnd_stance/index.html

人材獲得の難しさと研究開発の難しさ
https://a-film-production-technique-seminar.com/fppat/materials/ppi_phones_human_resource/index.html

under construction...