AAAタイトル開発と在宅勤務を支えるゲームエンジンエンジニアとテクニカルアーティストの取り組み

AAAタイトル開発と在宅勤務を支えるゲ
ームエンジンエンジニアとテクニカルア
ーティストの取り組み
1/68

View Slide

このセッションで得られること
Cygames は現在、AAAタイトルを制作しており、日々スケールし続ける大規模な組織になってきました。
そうした中、このコロナ禍をきっかけに、プロジェクト全体がオフィス勤務から在宅勤務へと移行しま
した
このセッションでは、オフィス勤務からいかに在宅勤務への移行に対応したかを、「ネットワーク環境
の変化」と「コミュニケーション手段の変化」の２側面から紹介します
本事例を通して、スケールし続ける大規模開発へいかに対応していけるか、いかに効率的かつ快適な開
発環境をチームメンバーに提供できるかのアイデアとして持ち帰っていただければと思います
2/68

View Slide

足立和弥
Cyllista Game Engine ゲームエンジニア
a
Cyllista Game Engine 開発においてテストやバイナリ配信の自
動化や、ゲーム開発のためのユーティリティツールの作成など開
発環境の整備を主に担当
自己紹介
岸川貴紀
デザイナー部テクニカルアーティストチームスペシャリスト
a
リードテクニカルアーティストとして、エフェクトをメインにサ
ポートしつつ、プロジェクト内のテクニカルアーティストチーム
の舵切りや各種ツール開発・パイプライン開発を担当
3/68

View Slide

プロジェクトメンバーが在宅勤務に移行するまでの経緯
COVID-19 の影響で在宅勤務を検討する機運が高まり、プロジェクトメンバーの在宅勤務を可能にする
開発環境の構築が必要になった
2020年3月30日在宅勤務のための準備を開始する
2020年4月8日最低限在宅勤務に耐えうる開発環境の対応が完了する
2020年4月10日~13日機材配送して在宅勤務を開始する
2020年4月13日以降出社していた時と遜色のない開発環境構築を目標に改善を進める
4/68

View Slide

在宅勤務を行う上での２大懸念点
ネットワーク環境の変化
⚫ 会社の VPN 帯域は他プロジェクトの開発を阻害するような使い方はできない
⚫ 各家庭によって異なる回線環境での開発をサポートしなくてはいけない
コミュニケーション手段の変化
⚫ 個人間のコミュニケーションがすべてオンラインになる
⚫ 今まで経験したことのない環境下で開発を続けなくてはいけない
⚫ 情報のやりとりの仕方が変化しつつも、情報の伝達の抜けをなるべく防ぐ必要がある
⚫ 個々の環境においても継続するエンジンサポート
⚫ 在宅環境になる事で起こる事を含め、エンジンへのサポート体制
5/68

View Slide

アジェンダ
Cyllista Game Engine について
ネットワーク環境の変化への対応
⚫ Perforce での共有方法について
⚫ アセットキャッシュの共有方法について
⚫ 低速回線や不安定な回線に対するフォローについて
⚫ DCC / エンジン回りのプロジェクトメンバー向けツール対応について
コミュニケーション手段の変化への対応
⚫ 在宅勤務時の各種情報共有とキャッチアップ性の改善・向上の取り組みについて
⚫ Cyllista Game Engine のゲーム開発者のサポート体制について
6/68

View Slide

ハイエンドコンソール向けの最高のゲームエンジン
⚫ Cygames 内製
⚫ ハードウェアが最高のパフォーマンスを出せる
⚫ ゲーム開発者が最高のパフォーマンスを出せる
講演
⚫ ダイナミックな変更を可能にするCyllista Game Engineのオープンワールド向けプロシージャル
背景制作ツールと描画機能[Cygames Tech Conference 2021]
⚫ Python による大規模ゲーム開発環境～Cyllista Game Engine 開発事例～ [CEDEC2020]
⚫ Cygames における次世代ハイエンドコンソール向けゲームエンジンの開発～最高のコンテンツを
支えるゲームエンジン～ [CEDEC2017]
7/68

View Slide

アジェンダ
8/68

View Slide

オフィス勤務での Perforce 環境
⚫ AWS 上に Perfoce Primary、社内ネットワーク内に Perforce Proxy を配置して運用している
⚫ 社内ネットワークは 10Gbps の回線となっていて、回線速度がネックにならないようにしている
社内ネットワーク（10Gbps）
Perforce Proxy
開発環境
Perforce Primary
開発環境
開発環境
9/68

View Slide

在宅勤務での Perforce 環境
単純に自宅から VPN を通して Perforce Proxy と接続した場合
⚫ 10Gbps の帯域で接続できるわけではないので通信速度が出ない
⚫ VPN の帯域を圧迫してしまう
VPN
Perforce Proxy
自宅
開発環境
自宅
開発環境
開発環境
Perforce Primary
10/68

View Slide

改善後の在宅勤務での Perforce 環境
⚫ 自宅から社内の Peforce Proxy へ接続しても 10Gbps 回線の恩恵が受けられない
⚫ 自宅からは AWS 上の Perofrce Primary へ直接接続するルートを取ることにした
VPN
Perforce Primary
Perforce Proxy
自宅
開発環境
自宅
開発環境
開発環境
11/68

View Slide

自宅から VPN を通さず Primary Server へ接続するための設定
⚫ インフラ部署との協力のもと対応を進める
⚫ Primary Server との通信は VPN を通さないルールを設定する
⚫ VPN を通らない通信のセキュリティを担保するため、 Primary Server への接続は暗号化する
VPN
自宅
開発環境
Perforce Primary との通信
そ
の
他
の
通
信
Perforce Primary
12/68

View Slide

Perforce の接続先の設定ミス検知
⚫ 自宅から Perforce Proxy へ接続すること自体は可能
⚫ 本人が気づくことなく VPN の帯域を圧迫することになる
⚫ 自宅から Perforce Proxy へ接続するような設定になっていた場合、変更を促すダイアログが出る
13/68

View Slide

アジェンダ
14/68

View Slide

ファイルリクエスト
⚫ ゲーム内で読み込まれるアセットは必要に応じて独自の中間ファイルから対象プラットフォーム向け
にコンバートされたものとなる
⚫ 開発中はファイルサーバーがゲームプロセスからのファイルリクエストを受ける
⚫ コンバート済みであればそのバイナリファイルを返す
⚫ コンバートが必要であればアセットサーバーへコンバートリクエストをかけてその結果をゲームプロセスに返す
ファイル
マネージャー
開発ツール群
開発中のアセットのロードについて
ゲームプロセス
ファイルバイナリ
アセット
マネージャー
コンバートリクエスト
コンバート結果
15/68

View Slide

コンバートした結果生成されたアセットは今後もリクエストされる可能性があるので、アセットキャッ
シュとして蓄積する
アセットキャッシュについて
コンバート
結果
開発ツール群
ゲームプロセス
ファイル
マネージャー
ファイル
リクエストアセット
マネージャー
コンバート
リクエスト
アセットキャッシュ
アセットの
ストア
アセットの
フェッチ
ファイル
バイナリ
16/68

View Slide

誰かの開発環境でコンバートされた結果は他の開発環境でも同様にコンバートされている可能性がある
そこで開発者間でもコンバート後のアセットを共有することでコンバートするよりも高速にアセットを
ロードできる
アセットキャッシュをサーバーで共有する
アセットキャッシュのストアとフェッチ
17/68
サーバー
開発環境
開発環境

View Slide

オフィス勤務でのアセットキャッシュの共有
Perforce の時と同様社内の高速回線内にアセットキャッシュサーバーを立てて運用
サーバー
開発環境
開発環境
開発環境
18/68

View Slide

在宅勤務でのアセットキャッシュの共有
単純に自宅から VPN を通して Proxy Server と接続した場合
⚫ 10Gbps の帯域で接続できるわけではないので通信速度が出ない
⚫ VPN の帯域を圧迫してしまう
VPN
サーバー
自宅
開発環境
自宅
開発環境
開発環境
19/68

View Slide

改善後の在宅勤務でのアセットキャッシュの共有
Perforce と同様に VPN を通らず、AWS 上のアセットキャッシュサーバーと通信できるようにアセッ
トキャッシュサーバーを機能拡張した
VPN
サーバー
サーバー
自宅
開発環境
自宅
開発環境
開発環境
20/68

View Slide

アセットキャッシュの効果検証
在宅勤務の環境で特定のレベルが起動するまでの時間を計測
検証環境
⚫ 実機用アセットが何もない状態（ワーストケース）
⚫ 必要なアセットキャッシュはサーバーに存在している
⚫ 計測環境は下り 150Mbps 程度の回線速度
※ 普段の開発中は変更されたアセットの分だけを取得するので数分程度
21/68

View Slide

アセットキャッシュの効果検証結果から
十分な回線速度が確保できていればアセットキャッシュの恩恵を受けられる
⚫ 回線速度が 50Mbps を下回ると徐々にキャッシュの恩恵が薄れる
⚫ 結果、低速回線環境向けに対策が必要であることがわかった
低速回線環境向けの運用回避策
⚫ 必要なアセットキャッシュをまとめて取得するバッチを配布する
⚫ 任意のタイミングで実行しておけば待たされる時間を運用で回避できる
⚫ 朝会中、昼休み中、ミーティング中など
⚫ 業務開始直後は朝会などミーティングが集中する時間帯なのでその時間に実行しておくことを推奨している
22/68

View Slide

アセットキャッシュサーバーを利用した
アセット受け渡しの事例
23/68

View Slide

アセットキャッシュサーバーを経由して未リリースの変更を渡す
⚫ アセットキャッシュサーバーはキーとコンバート済みアセットを扱うもの
⚫ 実装としてはキーとバイナリデータのペアを扱っている
⚫ これを利用して未リリースの変更を他の作業者に渡す機能をアセットの保留として提供している
アセットを保留しておく
保留されたアセットの取得
サーバー
24/68
開発環境
開発環境

View Slide

アセットが保留できることのメリット
アセットをリリースすることなく受け渡しができることで以下のようなメリットがある
⚫ 下流の作業が必要な変更をリリースせずに次の作業者へ渡せる
⚫ リリース前にアセットの変更について他のスタッフがチェックできる
⚫ アセットに問題がある場合にそのアセットをリリースせずにエンジニアに渡せる
25/68

View Slide

保留したアセットの受け渡しについて
アセットをリリースせず保留しておき、 URI を生成する
⚫ cyllista://asset/unshelve-asset?hashkey=39f3f6e1fb5a4eeb8d357ca742d98681
⚫ この URI はユーザーの操作によって変更が保留されたときに自動生成される
この URI を他の作業者に伝えて実行してもらう
⚫ 保留されたアセットがその作業者の環境に展開される
⚫ 展開された変更内容は編集中の画面に即座に反映される
⚫ URI を伝える手段は Slack やメールなど URI を認識できるツールであればよい
26/68

View Slide

保留したアセットの受け渡しデモ
デモ動画は以下の YouTube アーカイブをご覧ください
https://youtu.be/Uic-J6nj8Q4?list=PLSx6MdBnoFbAzBFI-gBTYO0-GowOZx3Nc&t=1182
27/68

View Slide

アジェンダ
28/68

View Slide

低速回線や不安定な回線で問題になった事例
クラッシュレポートのデータサイズが大きすぎてアップロードに時間がかかる
⚫ ファイルサイズの調整で対応する
自動で同期されるサムネイル画像が多すぎてツールのレスポンスが落ちる
⚫ 同期タイミングと量の調整をユーザーにコントロールしてもらうことで対応する
作業中ユーザーが気づかないうちに VPN の切断、再接続が起きる
⚫ VPN の切断、再接続を検知してユーザーに通知する
29/68

View Slide

クラッシュレポートのデータサイズについて
⚫ ゲームがクラッシュしたときの情報をクラッシュレポートとしてサーバーに集約
⚫ クラッシュレポートのファイル内訳
レポートに含まれるファイルファイルサイズ
ダンプファイル 100MB
ゲームのログファイル数100MB ～ 1GB超
開発ツールのログファイル数100MB ～ 1GB超
合計数100MB ～ 2GB超
ワーストケースで合計2GBを超えるので VPN の帯域圧迫も問題だがアップロードにかかる時間も問題
になる
30/68

View Slide

⚫ ダンプファイルは調査コストとのバランスでサイズ変更はしない
⚫ ゲームのログファイルは最新のログから上限 100MB に制限
⚫ ツールのログファイル最新のログから上限 100MB に制限
⚫ 合計 300MB 程度であればアップロードにかかる時間も許容できる
クラッシュレポートのデータサイズ削減
レポートに含まれるファイル削減後削減前
ダンプファイル 100MB 100MB
ゲームのログファイル 100MB 数100MB ～ 1GB超
開発ツールのログファイル 100MB 数100MB ～ 1GB超
合計 300MB 数100MB ～ 2GB超
31/68

View Slide

サムネイル画像が多すぎてツールのレスポンスが落ちる
⚫ 低速回線の環境で大量のサムネイル画像の同期がネックになっていた
⚫ サムネイル画像は Perforce で管理されていて、ツールが必要に応じて自動取得する仕組みになっている
⚫ サムネイル画像は大量にあるので低速回線だと取得に時間がかかりすぎてしまうので必要な分だけユーザー
の操作で取得するよう、サムネイル画像の取得量の制御をユーザーに委ねることにした
32/68

View Slide

ユーザーが任意でサムネイルを取得
⚫ 仮アイコンの状態からユーザーの操作によって取得したアセットのサムネイルに表示が変わる
33/68

View Slide

配置済みのアセットのサムネイルは自動取得
⚫ 配置されているアセットのサムネイルは自動取得
⚫ 表示の仕様上、自動取得は数枚であることがわかっている
⚫ 大きな負荷にはならないと判断
34/68

View Slide

ユーザーが気づかないうちに VPN の切断、再接続が起きる
VPN の切断が起こると通信処理中のツールが意図しない動作になってしまう
⚫ VPN が再接続すると IP アドレスが変わってしまい、切断時と同様にツールが意図しない動作になってしまう
⚫ この意図しない動作をしたときに「ツールの問題」なのか「VPN の問題」によるものなのかが非常に分かり難く原
因の調査に時間がかかってしまうので、切断、再接続が起きた時点で解決したい
⚫ ということで VPN の切断、再接続が起きたらユーザーに知らせて対応してもらうことにした
35/68

View Slide

VPN 切断と再接続の判定処理
VPNの切断判定方法
⚫ VPN クライアントソフトが提供している CLI を利用
⚫ 定期的に VPN のステータスをチェックして未接続の状態を検知したらダイアログでユーザーに通知している
VPN 再接続の判定は以下の 2 パターン
⚫ VPN 接続後に IP アドレスが変わっていないか
⚫ VPN が有効になって以降、定期的に IP アドレスが変わっていないかをチェック
⚫ IP アドレスが変わっていれば VPN のクライアントが再接続処理したものとみなす
⚫ 外部のアドレス情報が取得できなくなっていないか
⚫ Python の socket.getaddrinfo() を定期的に実行し、gaierror 例外で失敗しないことをチェック
⚫ VPN 再接続処理中にアドレスの解決が失敗すると、その結果が Windows の DNS キャッシュ乗ってしまいア
ドレスの解決ができなくなってしまうのではないかという見解のもと行っているチェック
⚫ VPN を再接続すると解決するようなのでこのケースも検知して VPN の再接続をユーザーに促す
36/68

View Slide

VPN 切断、再接続検知ダイアログ
⚫ VPN の切断や再接続が検知されると、接続確認とツールの再起動を促すダイアログが出現する
⚫ 作業中のデータを保存することと、VPN の再接続を行ってからツールを再起動するように促す
⚫ VPN の再接続が正しくできていない場合は再度ダイアログが出現する
⚫ ダイアログは突然出てくるのでキー入力で閉じてしまわないようにキー入力は受け付けないようにし
ておく
⚫ 「なにかダイアログが出たけど消えちゃった」を避けたい
37/68

View Slide

アジェンダ
38/68

View Slide

背景
⚫ 元々は、社内共有サーバーにツールを置き、そこから直接起動してもらっていた
⚫ ツールの安全性やプロジェクトを横断的にサポートするため
⚫ レンダーディスパッチャー（CI）で自動化する際に都合が良いため
問題
⚫ 様々な回線速度・安定性のユーザー環境からアクセスするには、不安定・速度の低下が発生
⚫ ツールが落ちてしまうことや、DCCツール自体の起動速度にまで影響してしまっていた
対策・対応
⚫ プロジェクトでは Perforce を使用しているため、その環境を利用する選択をした
⚫ ローカルから読み込むことになるので、ネットワーク速度の影響を受けない
⚫ Cyllista Game Engine のアップデートツールの実行時に同時に配布が出来る
⚫ 安全に配布が出来る
ツール利用のネットワーク環境への対応
39/68

View Slide

Mayaのツールへの Perforce/ShotGrid 統合例
⚫ プロジェクトでは、Perforce を使用している
⚫ その恩恵をワークフローに取り込む
⚫ 結果作業の簡略化や安全性を担保出来る様にする
⚫ Maya 上でファイルを開く際には専用のエクスプローラーを用意
⚫ Perforce のチェックアウトや最新状態の取得も可能
⚫ ShotGrid のステータス変更連携
⚫ ShotGrid 上のアセットのタスクに対してステータス変更を加えることが出来る
40/68

View Slide

⚫ 取得したデータを元に、マテリアルのパラメーター設定とマテリアルの書き出しを行えるツール
⚫ Perforce チェックアウトやリバート、リリースなどが行えるようになっている
Substance のツールへの Perforce 統合例
41/68

View Slide

まとめ: ネットワーク環境の変化
VPN の帯域を圧迫しない環境の構築
⚫ Perforce Server やアセットキャッシュサーバーとの接続は直接 AWS 上のインスタンスへ接続す
ることで対応
各家庭によって異なる回線環境での開発をサポート
⚫ VPN の不意な切断、再接続を検知
⚫ 低速な回線のために通信量を調整
Perforce の利用によりネットワーク通信をあまり考慮しなくて良い設計
⚫ 大容量のものを扱う際に、ネットワークの回線を考慮しなくてよい
⚫ ファイル探索などによる連続的通信を行わなくてよく、安定してファイルアクセスが出来る
42/68

View Slide

アジェンダ
43/68

View Slide

在宅勤務時のコミュニケーション時の問題
在宅時には、特に以下の様なコミュニケーション問題が発生する
⚫ アセット作成や実装状態の連絡不足
⚫ 現タスクの状態や、上流から下流までのタスク関係者への進行状況の伝達不足
⚫ 開発や開発運用においての仕様のドキュメント作成はしても、その周知が至らない
⚫ 繁忙期に差し掛かるごとに増す、上記各種の欠如が顕著になってくる
⚫ さざまなヒューマンエラーやプロジェクト内のカオスを生み出す事になる
44/68

View Slide

オフィス勤務時と在宅勤務時の変化
オフィス勤務時在宅勤務時
45/68

View Slide

オフィス勤務時と在宅勤務時の変化
情報が閉じた場所にたまりがちになってしまう
⚫ 情報が、チャットツールやタスク管理ツールに分断されて残りがちになる
⚫ 1:1 / グループ内などで情報が閉じてしまい、サイロ化が発生してしまう
⚫ 本来関係があるはずの人も取り残されていきがちになる
物理的な距離があり、物理的なすれ違いによるコミュニケーションが取りづらくなる
⚫ 偶然のコミュニケーション頻度が落ちる
46/68

View Slide

情報の抜け落ちの問題を解決する
このコミュニケーションの齟齬を解決するには、二つの側面からカバーする必要がある
運用でカバーする
⚫ ツールやサービスの使い方のルールを定めるなど
⚫ 基本の事ではあるが、「文化」を構築する上では大事な要素
システムでカバーする
⚫ それぞれのツールやサービスを自動連携によって統合する
⚫ １つの場所に投稿された情報を、別のメディアにも送信・同期し、透過性を高める
⚫ なるべくコミュニケーションの留まりをシステム的に無くし、「気づかせる」様にする
47/68

View Slide

運用面でカバーすべきところ
運用ルールをプロジェクトで定める
⚫ この際に、用語の統一性を必ず担保するように努める
⚫ 例えば、work -> 作業用、dev -> 開発向け、といったプレフィックスを使った運用
⚫ work_character -> キャラクター作業向け
⚫ dev_jira -> Jiraの関わる開発・開発向け
使用する単語は、組織内で共通用語とすることを前提に選定する
⚫ それぞれのツールに応じて、それぞれの単語ルールなどを設定しない
⚫ ゲームエンジンの中の言語からそれぞれのツールまで統一性を担保するように努めている
⚫ work という Prefix 語は、「ゲーム開発に関する作業を行う」という定義
⚫ work_rig、work_light
⚫ dev という Prefix 語は、「ゲーム開発には直接には影響しないが、周辺のツールや運用の開発に関係する」と
いう定義
⚫ dev_outsource、dev_shotgrid
48/68

View Slide

システムでカバーすべきところ
それぞれのツール内で情報が閉じない様、ツール間の連携を補完する設計・実装をする
コミュニケーションパイプラインで解決する
⚫ コミュニケーション
⚫ 「情報伝達」のこと
⚫ 「人と人との情報伝達」のみではなく、「人とコトとモノ」の間の「情報伝達」を指しています
49/68

View Slide

コミュニケーションパイプラインの3つのメディアについて
50/68

View Slide

コミュニケーションパイプライン(CP)と設計(CPD)
CPとは
⚫ 各種メディア・コミュニケーションツールやサービスを連結させるパイプをまとめてシステムセットとして呼称
CPを考えるメリット
⚫ 情報の透過性が確保できるようになる
⚫ ゲームタスクのコメントをタスクツールの記録として残しつつ、チャットツールで通知を受け取られる
⚫ 同時に、ゲーム制作タスクに紐づいたアセットをタスクと接続しなおして、適切にアセット管理を行える
⚫ 同時に、ゲーム制作タスクのステータスをドキュメント上で確認できる
CPDを考えるメリット
⚫ 「情報の蓄積」も適切な場所に行えるような運用を構築する事ができます
⚫ 新たにツールを選択する際に、ツールの選択によって、情報の滞りが起きてしまう悪循環を未然に防げる
⚫ そのツールは本当に必要なものか？別のツールの方が今の情報透過性を高められるのでは？
51/68

View Slide

コミュニケーションパイプライン設計（CPD）
52/68

View Slide

コミュニケーションパイプライン設計（CPD）
Cyllista Game Engine
Mail
DCC Tools
Jira
ShotGrid
Confluence
Slack
53/68

View Slide

Jira → Confluence
⚫ JiraとConfluenceには、同じAtlassian製品という事で、統合機能が標準で用意されている
⚫ Jira課題の進捗や状況をConfluenceにドキュメントとして掲載することが出来る
⚫ 週報や月末進捗などの際にレポートとして作成する事で、各タスクのキャッチアップやスケジューリングに役立て
る事が出来る
Jira Confluence
54/68

View Slide

⚫ Jira の機能・プラグインで、Jira Automation というものがある
⚫ Jira の課題が特定のイベント時に Slack に自動通知されるように実装している
⚫ セキュリティのため、Webhook の情報が漏れてもアクセスできない様、IP 制限された踏み台サーバ
ーを経由して、Slack に送信される
Jira → Slack
Jira Automation
Slack
Jira 踏み台 + Slack App
55/68

View Slide

ShotGrid → Slack
⚫ アセットの作成やタスクのステータス変更時に、従属するタスクの担当者へ変更内容を通知する
⚫ 統合には、ShotGrid Webhook という Outgoing 系の Webhook 機能を使う
⚫ それぞれのサービス間の通信には IP 制限や暗号化通信を前提とする
56/68

View Slide

⚫ 可用性や SysOps の観点から、ShotGrid Events ではなく、サーバレス環境を構築する
⚫ ShotGrid Webhook (Open Beta) をトリガーに Lambda を実行
⚫ サーバレスアプリケーションの構築は、AWS SAM を使用して一気に構築できる
⚫ ローカルテストをするための sam local invoke が非常に便利！
⚫ 実行コードは、プロジェクト標準でもある Python で全て実装
⚫ ShotGrid Application として管理
⚫ その他の各種 ShotGrid 自動化も実装
⚫ AWS 対応時のポイント
⚫ SQS: Webhook の6秒タイムアウト対応
⚫ DynamoDB: 冪等性への対応
ShotGrid → Slack
API Gateway SQS Lambda
ShotGrid Slack
DynamoDB
CloudWatch SMS Chatbot
DEBUG
SAM
ShotGrid Application
踏み台 + Slack App
57/68

View Slide

⚫ ShotGrid と Jira の役割の違い
⚫ ShotGrid: コンセプトアートやアセット、カットなどの制作管理に加えて外部パートナー管理などに活用
⚫ Jira: ゲーム制作タスクをアジャイル的に管理するために活用
⚫ ShotGrid と Jira を連携する内製アプリケーションを作成
⚫ Task (Jira) ↔ Order Entity (ShotGrid)を連携する
⚫ Order Entity は、内部で実装したカスタムエンティティ
ShotGrid ↔ Jira
SQS Lambda
Lambda
(Jira内の自動化)
Lambda
Lambda
ShotGrid Jira
SQS
API Gateway
API Gateway
ShotGrid Application
ShotGrid Jira Bridge
58/68

View Slide

Cyllista Game Engine → Jira / ShotGrid / Slack
⚫ Cyllista Game Engine へのエクスポート時に、外部連携ができるようになっている
⚫ 使用した Python モジュール
⚫ ShotGrid: ShotGrid Python API
⚫ Jira: Python Jira
⚫ Slack: Requests + Slack API
⚫ コメントなどエクスポート時に記載するフローを取る
⚫ リリース連絡忘れなどの途絶えを防ぐ
⚫ タスクにもリリース情報を記録してログ管理
⚫ リリースしたアセット情報と Order Entity を紐づけ
Cyllista Game Engine
Release Dialog
Slack
Jira
ShotGrid
Maya
59/68

View Slide

CP構築の技術選定で気を付ける事
サービスの保守と要望が出た際の対応のしやすさで選定する
⚫ 公式の統合機能や、GUI が存在するプラグインを優先して検討する
⚫ 統合機能の担当者以外でも調整できる余地を残しておく
CP全体を俯瞰してツール・サービスを選定する
⚫ 利用目的が重なってしまい二重・三重管理になってしまうことを避ける
⚫ ツール単体よりも、ビジネスロジック層を分析する
⚫ 部分的に導入できるかを検討し、時には切り捨てる事も考慮できると尚良い
特にセキュリティには気を配る
⚫ IP 制限や暗号化通信は前提として構築する
⚫ AWS に関しては、Cygamesではインフラチームと連携し構築している
60/68

View Slide

結果、何がよくなったか
プロジェクトの繁忙期においても、ディレクター・エンジニア・アーティスト・TA・制作管理といった
広範囲をそれぞれ集中して、また、俯瞰して情報を追う事ができている
⚫ 成果物チェックやタスク管理、ドキュメント共有を円滑に進める事ができている
注意しておきたいのが、実はこの問題はオフィス勤務時でも役に立つものであること
⚫ 在宅勤務の様な情報伝達形態の変化は、通常でも起きることがあり、それが「繁忙期」の時期にあたる
⚫ この設計と実装はそもそも3年以上前から進めており、既に一部は運用状態にあった
⚫ そもそも上手くCPDを上手く行うという事は、「オフィスに居たとしても、在宅勤務時にもコミュニケーションで
きる環境を作る事が出来る」という事になる
TAとしてのメリットも
⚫ 各班の進行状況がより表面に現れてくる
⚫ 相談対応や技術提案を、相手からの相談を待たずとも能動的に進めることがとてもし易くなった
61/68

View Slide

アジェンダ
62/68

View Slide

在宅勤務向けに開始した運用
相談窓口となるSlackチャンネルの運用
⚫ Slack に相談窓口となるチャンネルを作成し、ツール班のメンバーが毎朝通話を開始する
⚫ 2021年8月以降はハドルミーティングに切り替え
⚫ 困ったことや相談事がある人はいつでもこの通話に参加してきてもOK
⚫ ツール班のメンバーが対象
⚫ 10:00 ～ 19:00 までは基本的にこの通話に参加したまま業務をする
⚫ ミュートにするのはOK
⚫ 集中したい時は通話を抜けるのはOK（用があれば通話に招待される）
63/68

View Slide

相談窓口のチャンネルを始めた背景
当初はツール班内のコミュニケーションを円滑にするために始めた
⚫ 朝会以外に会話する機会が少なくなってしまった
⚫ 話したいことがあるときは「通話いいですか？」「いいですよ」とテキストでやり取りの後、通話するという感じ
で気軽に会話ができなかった
⚫ 一人暮らしだと１日だれとも話さないことも…
結果
⚫ 不具合の相談などでユーザーをこの通話に招待してツール班のメンバーで事情を聴くということが
多くなり、困ったときにはだれでもこの通話に相談に来てOKにしようということになった
64/68

View Slide

相談窓口チャンネルの効果
困ったら通話に参加して相談すればどうにかなるという体制が構築できた
⚫ 常にオープンな相談窓口の通話が開いていることで、相談先に迷う人をフォローできるようになった
⚫ 不具合報告や要望に対してのリアクションを早く起こせるようになった
⚫ 不具合の状況を通話しながら画面共有で確認できるので情報共有が早くなった
⚫ 現場最速！という意識がツール班に芽生える
コミュニケーションが円滑になった
⚫ ちょっとした質問や相談が気軽にできるようになった
⚫ オフィスのように座席の距離がないので、声をかけやすくなった
⚫ ちょっとした雑談もオフィスにいたときのように活性化した
65/68

View Slide

参考: プロジェクトの Slack 運用ルール
チャット
⚫ 返信が必要な場合は必ず対象者にメンションをつける
⚫ 自分宛のメンションには必ず返信する
⚫ グループメンションにも必ず返信もしくはリアクションをする
⚫ 定時時間外でもメンションは付ける
⚫ メンションされる側が通知の制御を行う
通話
⚫ 業務時間中は、いつ、誰に対しても Slack 通話を発信してよい
⚫ Slack 通話の着信は出れなければ出ないで OK
⚫ 雑談は意識して行う
⚫ 時間を決めて出入り自由の雑談用の通話を立てるなど
66/68

View Slide

まとめ: コミュニケーション手段の変化
コミュニケーションパイプラインを考えてツールやサービス選択・統合構築をしていく
⚫ 情報の透過性を高める事で、「伝えた、伝えてない」を無くす！
⚫ パイプをつなぐ仕組みが多岐に渡るので、保守性や安全性も込みで構築していく
⚫ こうした仕組みは、在宅勤務以外（複合も込み）でも有効
運用ルールを共有して文化構築をしていく
⚫ 困ったことがあったときに相談できる場所を明確に示しておくことで相談先に困る人をフォロー
⚫ ルールを明文化して共有することで、プロジェクトメンバー間のコミュニケーションに対する認識
が揃う。
67/68

View Slide

最高の開発環境で最高のゲームを
68/68

View Slide

AAAタイトル開発と在宅勤務を支えるゲームエンジンエンジニアとテクニカルアーティストの取り組み

AAAタイトル開発と在宅勤務を支えるゲームエンジンエンジニアとテクニカルアーティストの取り組み

Cygames

More Decks by Cygames

Other Decks in Technology

Featured

Transcript