Autodeskの提供するプロジェクト管理ソフトウェア「ShotGrid」の魅力や活用事例を紹介するリアルイベント「Autodesk ShotGrid Meetup Tokyo 2024」が2024年1月24日（水）に開催された。

本記事では、フレイムハーツ リードVFXアーティスト妹尾雄太氏、同社プロジェクトマネージャー瀧本佳奈実氏によるセッション「ShotGridで受託案件の管理を効率化する！」のレポートをお届けする。

フレイムハーツ 瀧本佳奈実氏（以下、瀧本）：フレイムハーツはゲーム開発及びCG映像制作に特化した、デジタルコンテンツ制作会社です。 今回はShotGridを活用した受託案件の管理の効率化事例について紹介させていただきます。

フレイムハーツ 妹尾雄太氏（以下、妹尾）：今回は大きく2つのテーマに分けてお話をさせていただきます。

当社では長期開発案件のアセット受託のみだとか、モデルだけ、エフェクトだけといったように、細かい単位での開発依頼をいただくことが多いです。前半部では、そういった長期案件の一部工程を担うようなケースにおいて、こういうセットアップでプロジェクトを回しました、といった事例紹介をさせていただきます。

後半部では、ShotGridを使って複数の案件を並列管理した際に出てきた問題点をどのように解決したか、事例紹介をさせていただきます。

長期案件向けのShotGridセットアップ事例

瀧本：それではまずは、継続案件をモデルにした受託制作の事例について解説させていただきます。当社ではShotGridを使ったことで、管理制作コストが1プロジェクトあたり、毎月0.5人月ほど抑えることができました。

具体的な案件でのご紹介は難しいので、架空の案件を例としてご紹介させていただきます。まず今回想定する架空案件の概要は、以下の通りです。

・長期運営タイトルである
・一部パートのアセット制作を5年以上請け続けている
・毎月30点前後の物量を請けている

つまり30点×12ヶ月×5年で、約1800点のデータがあるという想定になります。さらに1点の制作につき複数の工程が必要で、社内のプロジェクトマネージャー（以下、PM）1名がリードを含めた全体の進捗管理をしている、といったよくある受託案件の例としたいと思います。

こういった受託案件を取り回す際、よくある運用としてはExcelやスプレッドシートでアセットリストや進捗リストを管理し、データはフォルダ単位でサーバーに保存、パイプライン間の申し送りはメッセージツールなどを使用するといったケースが多いと思います。

瀧本：ただこういった運用においては、作業者が情報を参照する際、スケジュールはExcelで確認して、データをサーバーに見に行って、注意事項はメッセージツールで見て……と、情報を見に行く先が多岐に渡ってしまうという問題が発生します。情報が点在していて、かつ情報の参照元の相互の連携が薄いと、情報の粒度を揃える必要があったり、情報の見落としがあったりと、不都合が発生しやすくなります。また過去のデータが1800点近くあると、保存はできてもそれを管理することは人力では難しくなってきます。

これらの問題点が、ShotGridを活用することで解決できました。ここからは、実際の制作のながれに沿って、ShotGridを使うことによってどの工程でどのような効果があったのかを説明していきます。

長期案件向けのセットアップの大まかなながれは、以下の通りです。

①クライアント様と制作内容の打ち合わせ
②ShotGridにアセット、タスク、フェーズを登録する
③作業者へのタスク割り振りとスケジュール調整
④作業開始
⑤中間提出、FB対応
⑥納品

瀧本：ShotGridを活用することにより、このうち特に①～③の工程において、必要な情報が参照しやすくなり、情報を抽出する速度が確実に向上しました。その内容をさらに掘り下げて解説します。

まず制作内容の詳細を、制作物名をアセット、工程をタスク、納期をフェーズとしてそれぞれShotGridに登録していきます。

瀧本：アセットが毎月30点、1つのアセットにつき工程が2〜3あると仮定すると、タスクの数は60～90程度になります。フェーズに関しては、1ヶ月の間に上旬、中旬、下旬の3回納期があるという想定で、各アセットの納期をガントチャート上で管理、表示するために使用しています。

Excelなどで管理する場合はこの量のタスクをひとつずつ記載する必要がありますが、ShotGridならCSVでまとめて登録することで、時間短縮ができます。また、同じような制作物の場合、あらかじめタスクテンプレートを作成しておくと、さらに登録する時間が短縮できます。

さらにアセットにはタグが付けられるので、例えばシーズナルイベントのデータに、「ハロウィン」とか「〜コラボ」などのタグを付けておけば、あとから過去のイベントの情報を一括で抽出できて便利です。 

ここまでの工程でShotGridに制作物の情報が登録できたら、作業者のスキルと納期をふまえてタスクの割り振りを行います。視覚的に納期に間に合うかを見ながら割り振りが行えるので、調整がしやすくなっています。また、タスクに親子付けを行うことで、先行の工程と後の工程が逆になったときにエラーが出るようになり、スケジュールミスが発生しにくくなることも利点です。

続いて、④作業開始～⑥納品の工程におけるShotGridの活用事例について解説していきます。

後半部の工程においてShotGridを使っていて良かったと感じたポイントは、情報がShotGridに集約されて画一化され、情報取得の手間の削減や取得漏れのリスクが減る点、そして過去の情報が圧倒的に参照しやすいという点です。

瀧本：作業開始の段階では、作業者はShotGridのアセットページさえ見ておけば、申し送りされている内容を把握することができます。また工程ごとにタスクを登録してステータスを更新しておけば、後工程の作業をする際に、前工程が正しく完了しているかを確認することができるので、工程ごとに担当者が異なっても行きちがいが起きにくいです。

瀧本：実際に作業が始まったら、作業者の方には、タスクに紐付けて成果物をShotGridの「バージョン」にアップしてもらいます。

アップされたらリードがバージョンから内容をチェックして、フィードバックを行なったりOKを出したりと、チェック結果をもとに制作物のステータスを変えていきます。当社では、未着手から納品まで11種類のステータスを使えるようにしてあります。その上で、ステータスを誰がどのタイミングで更新するかルール化しておくことで、常に最新の状況が追いやすく、制作物が想定通り進捗しているか、納品漏れしていないか確認しやすくなります。

さらに、バージョンを使うことで、例えば数年前に作ったアセットを再調整するといったタスクが発生した時、数年前の担当者や当時のやり取りがバージョンのノートから確認できたりするので、その当時の状況をふまえての制作がしやすくなります。

瀧本：データをクライアントに提出する際も、「クライアントレビューサイト」の機能を使うことで、伝言ゲームじみたフィードバックのやり取りが発生せず、シンプルに運用できます。クライアント側も、バージョンの画面上でそのままペン入れしたりコメントを入れたりしてフィードバックを返せるので、わざわざストレージ上にデータをアップロードし直したり、フィードバック内容を作業者にもう一回振り分けたりする手間が発生しません。双方にとって余計な作業を減らすことが可能です。

ShotGridを活用することによって、あらゆる情報を画一化し、膨大なデータのなかから必要な情報のみを素早く引き出すことができるようになりました。作業時は基本的にShotGridを見ればいいので、情報管理が楽になり、かつ抜け漏れの可能性も低くなっています。結果として、管理・制作コストの大幅な削減に繋がりました。

ShotGridを活用し、複数のプロジェクトを画一的に管理

妹尾：続いては私から、ShotGridを使ったプロジェクトの並列管理についてお話しさせていただきます。

当社もそうなのですが、制作会社では先ほどの事例のようなプロジェクトが同時複数走っているケースが多いかと思います。プロジェクト単体では効率化が図れていたとしても、複数のプロジェクトが同時進行していると、どうしても作業者がプロジェクトをまたいで稼働していたり、ひとつのプロジェクトが終わったら次のプロジェクトに行ったりと、管理上の課題が出てくるようになります。

妹尾：たとえばアーティストさんだと、Aのプロジェクトをやった後にBのプロジェクトに入ったらそれぞれで全然レイアウトが違うので覚えるのが大変だとか、Aのプロジェクトでは1週間スパンで進捗管理をしていたのに、Bのプロジェクトではデイリーでやっていて進行管理の情報粒度が揃っていないとか、そういう問題が起きたりもします。

また管理職側としては、VFXアーティストが複数のプロジェクトに散っているけど、それぞれの稼働状況が一覧でみえないと運営しづらいという問題もありました。そこで、そういった問題を解決するためにShotGridを使って、2つの施策を実施しました。

まずひとつめの施策は、「プロジェクトテンプレート」という機能を使って、ページレイアウトや設計を統一したことです。

事前にレイアウトしたページの設計、各種ステータス、それからパイプラインと呼ばれる工程などをまとめてテンプレート化する機能を使い、今後新しくプロジェクトを立てる際にはこのテンプレートを設定してくださいというルール付けで運用しました。

妹尾：またその際の注意点として、「ステータスやパイプラインは軽率に増やさない」というルールを用いて運用しました。これは過去に担当者が独自にステータスをカスタマイズしていった結果、プロジェクトごとにステータスがちがってしまい、うまく管理ができないという状況に陥った反省からです。

ただし、個別のプロジェクトごとのカスタマイズはShotGridの魅力でもあるので、「個別のカスタマイズはプロジェクトの規模に応じて許可する」というルールも設け、状況に応じて柔軟に運用しています。

ふたつめの施策は、アーティストやPMが必要な情報のみを引っ張ってこられるダッシュボードページをつくったことです。

妹尾：アーティストであれば自分が現在入っているプロジェクトのタスクが見たいでしょうし、管理職であれば自分が管理しているスタッフがどんなタスクを持っているかを見たい、PMであればスケジュールやタスクの消化率を知りたい……といったように、職種によって、プロジェクトから得たい情報はそれぞれ異なると思います。そのため、それぞれの職種が必要とする情報を引っ張ってこられるダッシュボードページを作成しました。

新しい施策を行うと、どうしてもそれに対応するための学習コストがかかってしまいます。当社では、ShotGridの設計は2～3人ほどで行っています。管理職やPM、実働するアーティストの学習コストがなるべく少なくなるような運用を心がけ、ShotGridを活用しています。