『SCARLET NEXUS』 - 大規模なコンシューマーゲーム開発におけるShotGrid活用事例

――本日はよろしくお願いします。はじめに、皆様の自己紹介と担当業務をお聞かせください。

BNS 東：バンダイナムコスタジオ（以下BNS）の東（あずま）です。『SCARLET NEXUS』プロジェクトでは、開発前半はアートマネージャーとしてアート周りの管理を、後半からはプロジェクトマネージャーとしてShotGridを活用しながら全体の統括を担当しています。リリース後の現在は、ダウンロードコンテンツ（DLC）の開発が続いているので、そちらも引き続き見ています。

トーセ 後田：トーセ山崎スタジオに所属する後田（うしろだ）です。本作には　2019年9月からプランナーとして参加しています。ShotGridに関しては運用ルールの決定やサイトの構築まで行っています。

トーセ 沖田：同じくトーセ山崎スタジオでマネージャーを務める沖田（おきた）です。トーセ側の開発ディレクターとして日々の進捗管理にShotGridを利用しています。

株式会社 バンダイナムコスタジオ
第２スタジオ プロジェクトマネージャー
東 毅之 氏 （Azuma Takeshi）

株式会社トーセ
山崎スタジオ マネージャー
沖田 茂宏 氏（Shigehiro Okita）

株式会社トーセ
山崎スタジオ リードプランナー
後田 崇弘 氏 (Takahiro Ushiroda)

――これまでのゲーム開発ではどのように進捗管理を行われていましたか？

BNS 東：バンダイナムコスタジオではプロジェクトによって様々な進捗管理ツールを利用しており、RedmineやMicrosoft Project、Excelなどが利用されています。アートについては独自のツールで管理していたタイトルもあります。
小規模な開発ではExcelを使った進捗管理でも特に不都合を感じることは無いかもしれません。しかし、次世代コンシューマーゲームのように大規模な開発では、社外の多くの方と密接な協業がより一層必要になり、これまでの管理方法では厳しくなるなと感じていました。

トーセ 沖田：トーセでもプロジェクトによって管理方法は変わるのですが、最終的にはエクセルを使用しているケースが多いかもしれません。しかし、Excelの場合、担当者ごとに複数のファイルが出来てしまったり、どれが最新ファイルか分からなくなるというありがちな問題が発生していました。ExcelファイルをしっかりとSVN（バージョン管理ツール）を使ってバージョン管理しても、今度は現場では見やすくするために独自のカスタマイズをローカル環境で行ってしまいます。Redmineを利用しているプロジェクトでは、直感的な情報管理が難しくRedmineとExcelの二重管理状態に陥ってしまうといったケースも散見されました。

――ShotGridを導入されたきっかけは何でしょうか？

BNS 東：もともと本作の開発を進めるにあたりプロジェクト管理ツールに関するリサーチを行っており、ShotGridにも興味を持っていました。最初はAREA JAPANにあるユーザ事例などをチェックしていました。そして、実際にハンズオンセミナーに参加してShotGridの構造を理解すると、これはゲーム開発にも活用ができそうだと感じました。

トーセ 後田：そして、2017年6月頃に東さんから本作のアートアセットに対する管理ツールとしてShotGridを使ってみないかという打診がありました。トーセ側でも色々と検証を行ったところ、最終的にはアートアセットの管理だけではなく、プロジェクト全体の進捗管理ツールとして導入するほうがより成果が出そうだという結論に至りました。

――プロジェクト全体で利用されたとのことですが、具体的にどういった職種の方たちが使われたのでしょうか？

トーセ 後田：『SCARLET NEXUS』の開発では複数のセクションの担当スタッフが集まってスクラムを組んでいました。例えば、プレーヤー、敵、レベルデザイン、UI、モーションといったゲーム構成要素毎にスクラムが存在します。そして、各スクラムは、スクラムマスター、プランナー、アーティスト、プログラマーといったメンバーで構成されています。つまり、ゲーム開発に携わるタスクを持ったスクラムメンバーの全員がShotGridを利用しました。

BNS 東：トーセ側の開発スタッフの皆さんだけでなく、BNS側でも私を含めてアートディレクターやシナリオディテクターもShotGridを活用していました。開発のピーク時には他の委託先とのコミュニケーションにも利用していました。最大120名ぐらいでShotGridを利用していたと思います。

――従来の管理方法から新しくShotGridに移行するにあたり、苦労された点はどこでしたか？今までのやり方から変わる場合、現場からの抵抗があり、浸透させるのが難しいと聞きます。

トーセ 沖田：ゲーム技術の進化はとても速く、必要とされるコンテンツの増加に伴い開発コストも毎年高くなっています。開発スタッフも現状のまま留まるのではなく、変わらないといけないという意識を強く持っているスタッフが多いので、前向きな考えで対応をしてくれました。シンプルな使い方を徹底して徐々に慣れてもらうことで、まったく問題なく現場にShotGridは浸透していきました。

トーセ 後田：ただ、スムーズに浸透させるために2つの社内マニュアルを用意して、開発スタッフ全体にプレゼンと説明を行いました。1つ目の資料は、全員で共通の認識を持つためのものです。ShotGridには毎日アクセスして自ら更新することが重要だという内容を紹介しています。データベースは一人でも協力しない人間がいると不完全なデータとなり成り立ちません。しっかりと情報更新を行うことでリアルタイムの状況が見える化され、自分自身の負荷が軽減されるメリットがあることを伝えてあります。そして、使い方はシンプルにタスクのページだけを確認してもらうようにしています。

2つ目の資料としては、各スクラムのリーダー向けの操作説明をドキュメント化しています。パイプラインステップや独自フィールドの追加方法、情報を登録する際の注意事項を細かく説明しています。こういったマニュアルや意識付けは、共通意識を持つためやルールの統一化にはとても重要なことだと思います。

――導入後は順調にShotGridを利用できましたか？

トーセ 後田：タスク登録や情報更新はしっかりと行われ、現場からもスケジュール管理やコミュニケーションがとても良くなったと好評でした。

ところが、運用を続ける中でスクラムマスターからある問題が定義されました。遅延している作業に対応するためタスクの分解を行おうとすると、それがどのタスクと関連していて今後どういった作業のスケジュールに影響するかが分かりにくいというものでした。

ShotGridはデータべース構造のため、本来ならば関連性は問題なく把握できるはずです。しかし、スクラム毎に裁量を持たせて自由に運用を任せていたために、サイトの構築方法によってはタスクの関連性が分かりづらい状況のスクラムも中にはあったようです。そこで、プロジェクトの途中から私が交通整理を行うことにしました。スクラムを超えてプロジェクト内で横断的に制作物を管理・確認ができるように運用ルールや情報の登録方法をあらためて整理する工夫を行いました。

BNS 東：スクラム毎にまとめ方が違った当時は、俯瞰で状況を把握したい私のような立場の人間にはちょっと見づらかったかもしれません。運用が成熟してきた最新のDLC（ダウンロードコンテンツ）開発では、スケジュールやタスク同士の関連性がとても把握しやすくなったと感じています。

トーセ 沖田：ShotGridの進化を大まかに分けると、第一世代が導入した当初のスクラム単位での独自活用、第二世代がルール統一による横断的な情報管理の実現、第三世代がDLC開発での成熟した運用といった感じになると思います。

――ShotGridはデータベースなので過去のデータを壊さずに使い方を進化させていくことができるのも面白いところですよね。ちなみに第二世代の横断的な情報管理を実現するためには、どういったルールを設定されたのでしょうか？

トーセ 後田：まず、制作物を分類しやすくするために「パイプライン ID 」と「パイプライン ID 枝番」というフィールドを用意しました。親チケットに対するサブチケットのようなイメージです。これにより、制作物の一覧表示をグループ化で見やすく切り分けられるようにしました。

そして、制作物の作業となるタスクにも「パイプラインID ALL 」と「パイプライン ID 枝番 ALL 」というフィールドを用意してあります。こちらのフィールドは、タスクビューでのグループ化した時の見た目をスマートにする役割があります。

トーセ 沖田：例えば、DLC開発のスケジュールでは現状1400個ほどのタスクが存在します。「パイプラインID ALL 」の項目ではDLC1、DLC2、DLC3とリリース時期で分類を行っています。そして、「パイプライン ID 枝番 ALL 」では、それらがどのスクラムのタスクであるかを定義しています。

これらの情報でグルーピング表示を行うことで、スクラム > 成果物 > リリース時期 と見やすく分類が行えます。また、DLC1、DLC2、DLC3などリリース毎に表示するタブも用意してあります。開発は並行して行われているので、全体進行の確認に関わるスタッフはDLC1～３の全タスクを一覧で確認するケースのほうが多いかもしれません。

トーセ 後田：このように適切なラベル分けを行うことで、あるタスクの遅延やスケジュール変更が別の関連タスクにどういった影響を及ぼすかを分かりやすく把握ができるようになりました。

トーセ 沖田：そうですね。制作物の提出期日は事前に決まっています。期日に間に合うように、ShotGridでクリティカルパスも考慮しながら確認と相談が行えることで、目標が達成できるスケジュールを組み上げやすくなりました。

もちろん、最初からきっちりと運用方針を固めるというのがベストだとは思います。しかし、開発を進めながらベストな運用に進化させられる機動性もShotGridの魅力なのかもしれません。

――他にもプロジェクトの途中で運用が変化していった項目はありますか？

トーセ 沖田：タスクのステータスも最初は細かい粒度で登録していました。しかし、細かく分けてしまうと切り替えがかえって煩雑と感じたため、運用しながら使用するステータスをどんどん絞っていきました。

BNS 東：例えば、"BNSチェック"という弊社スタッフに対するチェック依頼のステータスが存在した時期もあります。しかし、日々のミーティングやSlackでフィードバックや承認を行い、ステータスの切り替えはトーセ様にお任せするほうが効率的だと判断したため最終的にこれは利用しなくなりました。

トーセ 後田：他にも作業が全て"完了"したというステータスの前に"仮データ"や"本データ"といった分類のステータスもありました。しかし、どの作業が遅れているのかが埋もれて分かりにくくなったために本末転倒で利用しなくなりました。

トーセ 沖田：そんなこともありました。最終的には作業としてほぼ終わっている状態だが完了ではないタスクを"調整"というシンプルなステータスを設けました。

"調整"ステータスは、遅れているタスクを把握するためだけでなく"調整"の中からどのタスクのクオリティをあげるかといった優先順位を決める際も便利です。

適切なステータス管理と条件設定でウォーニング（警告）を表示する機能を併用すると、状況が手遅れになってしまう前に先行して対応がとれました。期日が過ぎたタスクを赤く表示させると、対応が必要な項目が一目瞭然です。

――タスク管理の際はレビュー機能も活用されていたのでしょうか？

トーセ 沖田：はい、例えばモーションチームのスクラムではインゲームのモーションやフェイシャルアニメーションの制作を行っています。キャラクター表現に重要な要素であるモーション制作も、修正指示やレビュー確認をShotGrid内で行うことでクオリティやコミュニケーションの向上を実感できています。

レビューの際にはMayaやゲームエンジン上で再生したアニメーションのキャプチャ動画をShotGridにアップして確認を行っています。途中工程のレビューは全てShotGrid上の動画で行い、最終段階のチェックのみ実際のゲームエンジン内で動きを確認しています。

トーセ 後田：また、イベントチームのスクラムは、ShotGridを最も活用しているセクションの一つです。ゲームで発生する530ほどのイベントシーンのクオリティアップにレビュー機能が使われています。

映画やアニメといった映像制作の業界では既にShotGridが幅広く受け入れられていると思いますが、同じような作業のゲームのカットシーン制作でも力を発揮してくれます。

イベント制作ではアニマティクス、Unreal Engineのブループリント、ファイナル、エフェクト、サウンドといった流れで作業工程が進みます。工程のタスク毎にスレッド形式でやりとりが残せて、ビジュアルで明確に指示を伝えられるのはとても便利です。530にも及ぶイベントシーンに対する大量のタスクが同時に動く状況でも混乱は生じませんでした。

なお、イベントチームなどいくつかのスクラムではグラフ機能も活用しています。知りたいステータスの情報を抽出したグラフをクリックするだけでソースデータを素早く確認ができるのはとても便利です。例えば、スクラムマスターはグラフ上をクリックするだけでチェック待ちのステータス一覧を即座に確認ができます。

――他にもアセットの制作、レベルデザインやUIといった様々なゲーム要素もShotGridで管理されていたのですね。

トーセ 後田：そうですね。ユニークなものとしては、議事録的な使い方も行っていました。ゲーム開発ではマイルストーン毎にロムを仕上げて実際にゲームのテストプレイを行っています。そこではBNSさんとトーセでお互いに様々な改善案の意見を出し合います。そういった意見もShotGrid上にしっかりと記録を残すようにしました。

もちろん、内容によってはSlackでコミュニケーション行ったり、簡易的にExcelを使ってやりとりを行ったりもします。しかし、最終的な議論の結果がどうなったのかをShotGridに情報を集約して、記録を残すことは重要だと考えています。

トーセ 沖田：ゲーム開発ではこのようなコミュニケーションを重ねながら膨大な数の作業をこなす必要があります。そういえば、あの意見はどうなったっけ？と後で確認したい場合にもShotGrid内に記録されていると素早く振り返ることができるのは大きなメリットです。パイプラインの項目にスクラムのタスクも連動させられるので、どのセクションの人がその意見に対応したかも把握できるのは便利でした。こういった意見リストのような使い方は今後も活用していきたいと考えています。

BNS 東：他にも変わった使い方としては、プロジェクト初期にトーセ様側で発見されたバグの管理にもShotGridを使っていました。

本格的なデバッグ作業に関しては、トーセ様による実装が終了後、デバッグ専門の会社によって行われます。ただ、その前段階で開発中に見つかるバグもありまして、それについてはShotGridでステータスを管理していました。その後、本格的なデバッグを開始する際、対応済みや未修正のバグの情報をCSVデータとして書き出し、バンダイナムコで使用しているウェブベースのバグトラッキングシステムへと移行されました。初期段階からの対応状況が正確にデバッグ会社へと引き継がれ適切なフォローが行われることに役立ちました。

――適切に情報を蓄積することで後に活かせるということですね。かなり幅広い形でShotGridを使われていますが、導入効果はいかがでしょうか？

トーセ 沖田：具体的な数値化は難しいのですが、作業をタスク化して登録する行為がチーム内で習慣化したことによってプロジェクトの見える化に成功した結果、クリエイティブな作業により注力できる環境が生まれたと実感しています。

BNS 東：立場に応じて必要な情報だけを表示するページやタブを簡単に作成できるのも効果的でした。私自身も様々なスクラムの進捗状況を一括で把握するための確認ページを自分用に作成して使っています。

データベース構造になっているので、ページを複製してもデータソースが全て連動するのは大きなアドバンテージです。また、単一プロジェクトだけでなく複数のプロジェクトをまたいで情報を引っ張って表示が可能なのもShotGridの魅力です。

今回のプロジェクトでは、APIを用いたツール開発は一切行わずに標準機能だけで利用しています。それでも、十分な費用対効果があったと感じています。将来的にはさらなる自動化やMayaとの連携などツール開発も視野に入れ、進化させて行きたいですね。

――最後にShotGridに興味がある方にメッセージをお願いします。

トーセ 沖田：初めにどのように運用するかの計画と設計をしてから、ご使用頂けた方がより効果的な運用が出来るかと思います。弊社も開始時は上手く運用できず、理解し慣れるまで時間を要しました。

最終的に、ゲーム開発作業の進行管理をほぼShotGridで統一できたのは、各スクラムやセクションの特性に合わせた管理方法で行えつつ、全体の確認が行いやすいプラットフォームだという所が大きいと感じています。

クラウド上で皆がリアルタイムに情報共有しながら作業を進められるシステムのありがたみをぜひ体験して欲しいと思います。

トーセ 後田：セクションを超えた情報の一元化を実現できて、さらに進捗の管理やレビューも行える。そして、拡張性も高いという他のツールには無い幅広い魅力をもっているのがShotGridだと思います。セキュリティ環境も高くコロナ禍のリモートワーク状態でも安心して利用が出来ました。開発の規模が大きくても小さくても、それぞれで導入効果をもたらしてくれるはずです。

BNS 東：今回、ShotGridの導入で実現できたプロジェクトの効率化については、BNS社内の他のコンシューマーゲームプロジェクトからもヒアリングがありました。その後、既に導入を決定したプロジェクトもありますし、検討中のプロジェクトも増えています。今後は、BNS社内でもShotGridの採用がさらに進んでいくのではと感じます。

活用ができれば確実に費用対効果をもたらしてくれるはずです。まずは実際に検証で触ってみるのが良いのではないでしょうか。分からないことや不安があれば、代理店やオートデスクのスタッフの方に相談すれば導入をしっかりとアシストしてくれるはずです。

――はい、導入にあたっては全力でフォローさせていただきます！
東様、沖田様、後田様、本日は貴重なお話をありがとうございました。

※記載されている会社名・製品名は、各社の商標、または登録商標です。
（※1） Xbox Series X|Sは米国Microsoft Corporationおよび/またはその関連会社の登録商標または商標です。
（※2）"PlayStation"は、株式会社ソニー・インタラクティブエンタテインメントの登録商標または商標です。

「SCARLET NEXUS™」
SCARLET NEXUS™ & ©BANDAI NAMCO Entertainment Inc.