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

2021/11/14 Cygames Tech Conference

Transcript

1. AAAタイトル開発と在宅勤務を支えるゲ ームエンジンエンジニアとテクニカルア ーティストの取り組み 1/68
2. このセッションで得られること Cygames は現在、AAAタイトルを制作しており、日々スケールし続ける大規模な組織になってきました。 そうした中、このコロナ禍をきっかけに、プロジェクト全体がオフィス勤務から在宅勤務へと移行しま した このセッションでは、オフィス勤務からいかに在宅勤務への移行に対応したかを、「ネットワーク環境 の変化」と「コミュニケーション手段の変化」の２側面から紹介します 本事例を通して、スケールし続ける大規模開発へいかに対応していけるか、いかに効率的かつ快適な開 発環境をチームメンバーに提供できるかのアイデアとして持ち帰っていただければと思います 2/68
3. 足立 和弥 Cyllista Game Engine ゲームエンジニア a Cyllista Game Engine 開発においてテストやバイナリ配信の自 動化や、ゲーム開発のためのユーティリティツールの作成など開 発環境の整備を主に担当 自己紹介 岸川 貴紀 デザイナー部 テクニカルアーティストチーム スペシャリスト a リードテクニカルアーティストとして、エフェクトをメインにサ ポートしつつ、プロジェクト内のテクニカルアーティストチーム の舵切りや各種ツール開発・パイプライン開発を担当 3/68
4. プロジェクトメンバーが在宅勤務に移行するまでの経緯 COVID-19 の影響で在宅勤務を検討する機運が高まり、プロジェクトメンバーの在宅勤務を可能にする 開発環境の構築が必要になった 2020年3月30日 在宅勤務のための準備を開始する 2020年4月8日 最低限在宅勤務に耐えうる開発環境の対応が完了する 2020年4月10日~13日 機材配送して在宅勤務を開始する 2020年4月13日以降 出社していた時と遜色のない開発環境構築を目標に改善を進める 4/68
5. 在宅勤務を行う上での２大懸念点 ネットワーク環境の変化 ⚫ 会社の VPN 帯域は他プロジェクトの開発を阻害するような使い方はできない ⚫ 各家庭によって異なる回線環境での開発をサポートしなくてはいけない コミュニケーション手段の変化 ⚫ 個人間のコミュニケーションがすべてオンラインになる ⚫ 今まで経験したことのない環境下で開発を続けなくてはいけない ⚫ 情報のやりとりの仕方が変化しつつも、情報の伝達の抜けをなるべく防ぐ必要がある ⚫ 個々の環境においても継続するエンジンサポート ⚫ 在宅環境になる事で起こる事を含め、エンジンへのサポート体制 5/68
6. アジェンダ Cyllista Game Engine について ネットワーク環境の変化への対応 ⚫ Perforce での共有方法について ⚫ アセットキャッシュの共有方法について ⚫ 低速回線や不安定な回線に対するフォローについて ⚫ DCC / エンジン回りのプロジェクトメンバー向けツール対応について コミュニケーション手段の変化への対応 ⚫ 在宅勤務時の各種情報共有とキャッチアップ性の改善・向上の取り組みについて ⚫ Cyllista Game Engine のゲーム開発者のサポート体制について 6/68
7. Cyllista Game Engine について ハイエンドコンソール向けの最高のゲームエンジン ⚫ Cygames 内製 ⚫ ハードウェアが最高のパフォーマンスを出せる ⚫ ゲーム開発者が最高のパフォーマンスを出せる 講演 ⚫ ダイナミックな変更を可能にするCyllista Game Engineのオープンワールド向けプロシージャル 背景制作ツールと描画機能[Cygames Tech Conference 2021] ⚫ Python による大規模ゲーム開発環境 ～Cyllista Game Engine 開発事例～ [CEDEC2020] ⚫ Cygames における次世代ハイエンドコンソール向けゲームエンジンの開発～最高のコンテンツを 支えるゲームエンジン～ [CEDEC2017] 7/68
8. アジェンダ Cyllista Game Engine について ネットワーク環境の変化への対応 ⚫ Perforce での共有方法について ⚫ アセットキャッシュの共有方法について ⚫ 低速回線や不安定な回線に対するフォローについて ⚫ DCC / エンジン回りのプロジェクトメンバー向けツール対応について コミュニケーション手段の変化への対応 ⚫ 在宅勤務時の各種情報共有とキャッチアップ性の改善・向上の取り組みについて ⚫ Cyllista Game Engine のゲーム開発者のサポート体制について 8/68
9. オフィス勤務での Perforce 環境 ⚫ AWS 上に Perfoce Primary、社内ネットワーク内に Perforce Proxy を配置して運用している ⚫ 社内ネットワークは 10Gbps の回線となっていて、回線速度がネックにならないようにしている 社内ネットワーク（10Gbps） Perforce Proxy 開発環境 Perforce Primary 開発環境 開発環境 9/68
10. 在宅勤務での Perforce 環境 単純に自宅から VPN を通して Perforce Proxy と接続した場合 ⚫ 10Gbps の帯域で接続できるわけではないので通信速度が出ない ⚫ VPN の帯域を圧迫してしまう 社内ネットワーク（10Gbps） VPN Perforce Proxy 自宅 開発環境 自宅 開発環境 開発環境 Perforce Primary 10/68
11. 改善後の在宅勤務での Perforce 環境 ⚫ 自宅から社内の Peforce Proxy へ接続しても 10Gbps 回線の恩恵が受けられない ⚫ 自宅からは AWS 上の Perofrce Primary へ直接接続するルートを取ることにした 社内ネットワーク（10Gbps） VPN Perforce Primary Perforce Proxy 自宅 開発環境 自宅 開発環境 開発環境 11/68
12. 自宅から VPN を通さず Primary Server へ接続するための設定 ⚫ インフラ部署との協力のもと対応を進める ⚫ Primary Server との通信は VPN を通さないルールを設定する ⚫ VPN を通らない通信のセキュリティを担保するため、 Primary Server への接続は暗号化する 社内ネットワーク（10Gbps） VPN 自宅 開発環境 Perforce Primary との通信 そ の 他 の 通 信 Perforce Primary 12/68
13. Perforce の接続先の設定ミス検知 ⚫ 自宅から Perforce Proxy へ接続すること自体は可能 ⚫ 本人が気づくことなく VPN の帯域を圧迫することになる ⚫ 自宅から Perforce Proxy へ接続するような設定になっていた場合、変更を促すダイアログが出る 13/68
14. アジェンダ Cyllista Game Engine について ネットワーク環境の変化への対応 ⚫ Perforce での共有方法について ⚫ アセットキャッシュの共有方法について ⚫ 低速回線や不安定な回線に対するフォローについて ⚫ DCC / エンジン回りのプロジェクトメンバー向けツール対応について コミュニケーション手段の変化への対応 ⚫ 在宅勤務時の各種情報共有とキャッチアップ性の改善・向上の取り組みについて ⚫ Cyllista Game Engine のゲーム開発者のサポート体制について 14/68
15. ファイルリクエスト ⚫ ゲーム内で読み込まれるアセットは必要に応じて独自の中間ファイルから対象プラットフォーム向け にコンバートされたものとなる ⚫ 開発中はファイルサーバーがゲームプロセスからのファイルリクエストを受ける ⚫ コンバート済みであればそのバイナリファイルを返す ⚫ コンバートが必要であればアセットサーバーへコンバートリクエストをかけてその結果をゲームプロセスに返す ファイル マネージャー 開発ツール群 開発中のアセットのロードについて ゲームプロセス ファイルバイナリ アセット マネージャー コンバートリクエスト コンバート結果 15/68
16. コンバートした結果生成されたアセットは今後もリクエストされる可能性があるので、アセットキャッ シュとして蓄積する アセットキャッシュについて コンバート 結果 開発ツール群 ゲームプロセス ファイル マネージャー ファイル リクエスト アセット マネージャー コンバート リクエスト アセットキャッシュ アセットの ストア アセットの フェッチ ファイル バイナリ 16/68
17. 誰かの開発環境でコンバートされた結果は他の開発環境でも同様にコンバートされている可能性がある そこで開発者間でもコンバート後のアセットを共有することでコンバートするよりも高速にアセットを ロードできる アセットキャッシュをサーバーで共有する アセットキャッシュのストアとフェッチ 17/68 アセットキャッシュ サーバー 開発環境 開発環境
18. オフィス勤務でのアセットキャッシュの共有 Perforce の時と同様社内の高速回線内にアセットキャッシュサーバーを立てて運用 社内ネットワーク（10Gbps） アセットキャッシュ サーバー 開発環境 開発環境 開発環境 18/68
19. 在宅勤務でのアセットキャッシュの共有 単純に自宅から VPN を通して Proxy Server と接続した場合 ⚫ 10Gbps の帯域で接続できるわけではないので通信速度が出ない ⚫ VPN の帯域を圧迫してしまう 社内ネットワーク（10Gbps） VPN アセットキャッシュ サーバー 自宅 開発環境 自宅 開発環境 開発環境 19/68
20. 改善後の在宅勤務でのアセットキャッシュの共有 Perforce と同様に VPN を通らず、AWS 上のアセットキャッシュサーバーと通信できるようにアセッ トキャッシュサーバーを機能拡張した 社内ネットワーク（10Gbps） VPN アセットキャッシュ サーバー アセットキャッシュ サーバー 自宅 開発環境 自宅 開発環境 開発環境 20/68
21. アセットキャッシュの効果検証 在宅勤務の環境で特定のレベルが起動するまでの時間を計測 検証環境 ⚫ 実機用アセットが何もない状態（ワーストケース） ⚫ 必要なアセットキャッシュはサーバーに存在している ⚫ 計測環境は下り 150Mbps 程度の回線速度 ※ 普段の開発中は変更されたアセットの分だけを取得するので数分程度 21/68
22. アセットキャッシュの効果検証結果から 十分な回線速度が確保できていればアセットキャッシュの恩恵を受けられる ⚫ 回線速度が 50Mbps を下回ると徐々にキャッシュの恩恵が薄れる ⚫ 結果、低速回線環境向けに対策が必要であることがわかった 低速回線環境向けの運用回避策 ⚫ 必要なアセットキャッシュをまとめて取得するバッチを配布する ⚫ 任意のタイミングで実行しておけば待たされる時間を運用で回避できる ⚫ 朝会中、昼休み中、ミーティング中など ⚫ 業務開始直後は朝会などミーティングが集中する時間帯なのでその時間に実行しておくことを推奨している 22/68
23. アセットキャッシュサーバーを利用した アセット受け渡しの事例 23/68
24. アセットキャッシュサーバーを経由して未リリースの変更を渡す ⚫ アセットキャッシュサーバーはキーとコンバート済みアセットを扱うもの ⚫ 実装としてはキーとバイナリデータのペアを扱っている ⚫ これを利用して未リリースの変更を他の作業者に渡す機能をアセットの保留として提供している アセットを保留しておく 保留されたアセットの取得 アセットキャッシュ サーバー 24/68 開発環境 開発環境
25. アセットが保留できることのメリット アセットをリリースすることなく受け渡しができることで以下のようなメリットがある ⚫ 下流の作業が必要な変更をリリースせずに次の作業者へ渡せる ⚫ リリース前にアセットの変更について他のスタッフがチェックできる ⚫ アセットに問題がある場合にそのアセットをリリースせずにエンジニアに渡せる 25/68
26. 保留したアセットの受け渡しについて アセットをリリースせず保留しておき、 URI を生成する ⚫ cyllista://asset/unshelve-asset?hashkey=39f3f6e1fb5a4eeb8d357ca742d98681 ⚫ この URI はユーザーの操作によって変更が保留されたときに自動生成される この URI を他の作業者に伝えて実行してもらう ⚫ 保留されたアセットがその作業者の環境に展開される ⚫ 展開された変更内容は編集中の画面に即座に反映される ⚫ URI を伝える手段は Slack やメールなど URI を認識できるツールであればよい 26/68
27. 保留したアセットの受け渡しデモ デモ動画は以下の YouTube アーカイブをご覧ください https://youtu.be/Uic-J6nj8Q4?list=PLSx6MdBnoFbAzBFI-gBTYO0-GowOZx3Nc&t=1182 27/68
28. アジェンダ Cyllista Game Engine について ネットワーク環境の変化への対応 ⚫ Perforce での共有方法について ⚫ アセットキャッシュの共有方法について ⚫ 低速回線や不安定な回線に対するフォローについて ⚫ DCC / エンジン回りのプロジェクトメンバー向けツール対応について コミュニケーション手段の変化への対応 ⚫ 在宅勤務時の各種情報共有とキャッチアップ性の改善・向上の取り組みについて ⚫ Cyllista Game Engine のゲーム開発者のサポート体制について 28/68
29. 低速回線や不安定な回線で問題になった事例 クラッシュレポートのデータサイズが大きすぎてアップロードに時間がかかる ⚫ ファイルサイズの調整で対応する 自動で同期されるサムネイル画像が多すぎてツールのレスポンスが落ちる ⚫ 同期タイミングと量の調整をユーザーにコントロールしてもらうことで対応する 作業中ユーザーが気づかないうちに VPN の切断、再接続が起きる ⚫ VPN の切断、再接続を検知してユーザーに通知する 29/68
30. クラッシュレポートのデータサイズについて ⚫ ゲームがクラッシュしたときの情報をクラッシュレポートとしてサーバーに集約 ⚫ クラッシュレポートのファイル内訳 レポートに含まれるファイル ファイルサイズ ダンプファイル 100MB ゲームのログファイル 数100MB ～ 1GB超 開発ツールのログファイル 数100MB ～ 1GB超 合計 数100MB ～ 2GB超 ワーストケースで合計2GBを超えるので VPN の帯域圧迫も問題だがアップロードにかかる時間も問題 になる 30/68
31. ⚫ ダンプファイルは調査コストとのバランスでサイズ変更はしない ⚫ ゲームのログファイルは最新のログから上限 100MB に制限 ⚫ ツールのログファイル最新のログから上限 100MB に制限 ⚫ 合計 300MB 程度であればアップロードにかかる時間も許容できる クラッシュレポートのデータサイズ削減 レポートに含まれるファイル 削減後 削減前 ダンプファイル 100MB 100MB ゲームのログファイル 100MB 数100MB ～ 1GB超 開発ツールのログファイル 100MB 数100MB ～ 1GB超 合計 300MB 数100MB ～ 2GB超 31/68
32. サムネイル画像が多すぎてツールのレスポンスが落ちる ⚫ 低速回線の環境で大量のサムネイル画像の同期がネックになっていた ⚫ サムネイル画像は Perforce で管理されていて、ツールが必要に応じて自動取得する仕組みになっている ⚫ サムネイル画像は大量にあるので低速回線だと取得に時間がかかりすぎてしまうので必要な分だけユーザー の操作で取得するよう、サムネイル画像の取得量の制御をユーザーに委ねることにした 32/68
33. ユーザーが任意でサムネイルを取得 ⚫ 仮アイコンの状態からユーザーの操作によって取得したアセットのサムネイルに表示が変わる 33/68
34. 配置済みのアセットのサムネイルは自動取得 ⚫ 配置されているアセットのサムネイルは自動取得 ⚫ 表示の仕様上、自動取得は数枚であることがわかっている ⚫ 大きな負荷にはならないと判断 34/68
35. ユーザーが気づかないうちに VPN の切断、再接続が起きる VPN の切断が起こると通信処理中のツールが意図しない動作になってしまう ⚫ VPN が再接続すると IP アドレスが変わってしまい、切断時と同様にツールが意図しない動作になってしまう ⚫ この意図しない動作をしたときに「ツールの問題」なのか「VPN の問題」によるものなのかが非常に分かり難く原 因の調査に時間がかかってしまうので、切断、再接続が起きた時点で解決したい ⚫ ということで VPN の切断、再接続が起きたらユーザーに知らせて対応してもらうことにした 35/68
36. VPN 切断と再接続の判定処理 VPNの切断判定方法 ⚫ VPN クライアントソフトが提供している CLI を利用 ⚫ 定期的に VPN のステータスをチェックして未接続の状態を検知したらダイアログでユーザーに通知している VPN 再接続の判定は以下の 2 パターン ⚫ VPN 接続後に IP アドレスが変わっていないか ⚫ VPN が有効になって以降、定期的に IP アドレスが変わっていないかをチェック ⚫ IP アドレスが変わっていれば VPN のクライアントが再接続処理したものとみなす ⚫ 外部のアドレス情報が取得できなくなっていないか ⚫ Python の socket.getaddrinfo() を定期的に実行し、gaierror 例外で失敗しないことをチェック ⚫ VPN 再接続処理中にアドレスの解決が失敗すると、その結果が Windows の DNS キャッシュ乗ってしまいア ドレスの解決ができなくなってしまうのではないかという見解のもと行っているチェック ⚫ VPN を再接続すると解決するようなのでこのケースも検知して VPN の再接続をユーザーに促す 36/68
37. VPN 切断、再接続検知ダイアログ ⚫ VPN の切断や再接続が検知されると、接続確認とツールの再起動を促すダイアログが出現する ⚫ 作業中のデータを保存することと、VPN の再接続を行ってからツールを再起動するように促す ⚫ VPN の再接続が正しくできていない場合は再度ダイアログが出現する ⚫ ダイアログは突然出てくるのでキー入力で閉じてしまわないようにキー入力は受け付けないようにし ておく ⚫ 「なにかダイアログが出たけど消えちゃった」を避けたい 37/68
38. アジェンダ Cyllista Game Engine について ネットワーク環境の変化への対応 ⚫ Perforce での共有方法について ⚫ アセットキャッシュの共有方法について ⚫ 低速回線や不安定な回線に対するフォローについて ⚫ DCC / エンジン回りのプロジェクトメンバー向けツール対応について コミュニケーション手段の変化への対応 ⚫ 在宅勤務時の各種情報共有とキャッチアップ性の改善・向上の取り組みについて ⚫ Cyllista Game Engine のゲーム開発者のサポート体制について 38/68
39. 背景 ⚫ 元々は、社内共有サーバーにツールを置き、そこから直接起動してもらっていた ⚫ ツールの安全性やプロジェクトを横断的にサポートするため ⚫ レンダーディスパッチャー（CI）で自動化する際に都合が良いため 問題 ⚫ 様々な回線速度・安定性のユーザー環境からアクセスするには、不安定・速度の低下が発生 ⚫ ツールが落ちてしまうことや、DCCツール自体の起動速度にまで影響してしまっていた 対策・対応 ⚫ プロジェクトでは Perforce を使用しているため、その環境を利用する選択をした ⚫ ローカルから読み込むことになるので、ネットワーク速度の影響を受けない ⚫ Cyllista Game Engine のアップデートツールの実行時に同時に配布が出来る ⚫ 安全に配布が出来る ツール利用のネットワーク環境への対応 39/68
40. Mayaのツールへの Perforce/ShotGrid 統合例 ⚫ プロジェクトでは、Perforce を使用している ⚫ その恩恵をワークフローに取り込む ⚫ 結果作業の簡略化や安全性を担保出来る様にする ⚫ Maya 上でファイルを開く際には専用のエクスプローラーを用意 ⚫ Perforce のチェックアウトや最新状態の取得も可能 ⚫ ShotGrid のステータス変更連携 ⚫ ShotGrid 上のアセットのタスクに対してステータス変更を加えることが出来る 40/68
41. ⚫ 取得したデータを元に、マテリアルのパラメーター設定とマテリアルの書き出しを行えるツール ⚫ Perforce チェックアウトやリバート、リリースなどが行えるようになっている Substance のツールへの Perforce 統合例 41/68
42. まとめ: ネットワーク環境の変化 VPN の帯域を圧迫しない環境の構築 ⚫ Perforce Server やアセットキャッシュサーバーとの接続は直接 AWS 上のインスタンスへ接続す ることで対応 各家庭によって異なる回線環境での開発をサポート ⚫ VPN の不意な切断、再接続を検知 ⚫ 低速な回線のために通信量を調整 Perforce の利用によりネットワーク通信をあまり考慮しなくて良い設計 ⚫ 大容量のものを扱う際に、ネットワークの回線を考慮しなくてよい ⚫ ファイル探索などによる連続的通信を行わなくてよく、安定してファイルアクセスが出来る 42/68
43. アジェンダ Cyllista Game Engine について ネットワーク環境の変化への対応 ⚫ Perforce での共有方法について ⚫ アセットキャッシュの共有方法について ⚫ 低速回線や不安定な回線に対するフォローについて ⚫ DCC / エンジン回りのプロジェクトメンバー向けツール対応について コミュニケーション手段の変化への対応 ⚫ 在宅勤務時の各種情報共有とキャッチアップ性の改善・向上の取り組みについて ⚫ Cyllista Game Engine のゲーム開発者のサポート体制について 43/68
44. 在宅勤務時のコミュニケーション時の問題 在宅時には、特に以下の様なコミュニケーション問題が発生する ⚫ アセット作成や実装状態の連絡不足 ⚫ 現タスクの状態や、上流から下流までのタスク関係者への進行状況の伝達不足 ⚫ 開発や開発運用においての仕様のドキュメント作成はしても、その周知が至らない ⚫ 繁忙期に差し掛かるごとに増す、上記各種の欠如が顕著になってくる ⚫ さざまなヒューマンエラーやプロジェクト内のカオスを生み出す事になる 44/68
45. オフィス勤務時と在宅勤務時の変化 オフィス勤務時 在宅勤務時 45/68
46. オフィス勤務時と在宅勤務時の変化 情報が閉じた場所にたまりがちになってしまう ⚫ 情報が、チャットツールやタスク管理ツールに分断されて残りがちになる ⚫ 1:1 / グループ内などで情報が閉じてしまい、サイロ化が発生してしまう ⚫ 本来関係があるはずの人も取り残されていきがちになる 物理的な距離があり、物理的なすれ違いによるコミュニケーションが取りづらくなる ⚫ 偶然のコミュニケーション頻度が落ちる 46/68
47. 情報の抜け落ちの問題を解決する このコミュニケーションの齟齬を解決するには、二つの側面からカバーする必要がある 運用でカバーする ⚫ ツールやサービスの使い方のルールを定めるなど ⚫ 基本の事ではあるが、「文化」を構築する上では大事な要素 システムでカバーする ⚫ それぞれのツールやサービスを自動連携によって統合する ⚫ １つの場所に投稿された情報を、別のメディアにも送信・同期し、透過性を高める ⚫ なるべくコミュニケーションの留まりをシステム的に無くし、「気づかせる」様にする 47/68
48. 運用面でカバーすべきところ 運用ルールをプロジェクトで定める ⚫ この際に、用語の統一性を必ず担保するように努める ⚫ 例えば、work -> 作業用、dev -> 開発向け、といったプレフィックスを使った運用 ⚫ work_character -> キャラクター作業向け ⚫ dev_jira -> Jiraの関わる開発・開発向け 使用する単語は、組織内で共通用語とすることを前提に選定する ⚫ それぞれのツールに応じて、それぞれの単語ルールなどを設定しない ⚫ ゲームエンジンの中の言語からそれぞれのツールまで統一性を担保するように努めている ⚫ work という Prefix 語は、「ゲーム開発に関する作業を行う」という定義 ⚫ work_rig、work_light ⚫ dev という Prefix 語は、「ゲーム開発には直接には影響しないが、周辺のツールや運用の開発に関係する」と いう定義 ⚫ dev_outsource、dev_shotgrid 48/68
49. システムでカバーすべきところ それぞれのツール内で情報が閉じない様、ツール間の連携を補完する設計・実装をする コミュニケーションパイプラインで解決する ⚫ コミュニケーション ⚫ 「情報伝達」のこと ⚫ 「人と人との情報伝達」のみではなく、「人とコトとモノ」の間の「情報伝達」を指しています 49/68
50. コミュニケーションパイプラインの3つのメディアについて 50/68
51. コミュニケーションパイプライン(CP)と設計(CPD) CPとは ⚫ 各種メディア・コミュニケーションツールやサービスを連結させるパイプをまとめてシステムセットとして呼称 CPを考えるメリット ⚫ 情報の透過性が確保できるようになる ⚫ ゲームタスクのコメントをタスクツールの記録として残しつつ、チャットツールで通知を受け取られる ⚫ 同時に、ゲーム制作タスクに紐づいたアセットをタスクと接続しなおして、適切にアセット管理を行える ⚫ 同時に、ゲーム制作タスクのステータスをドキュメント上で確認できる CPDを考えるメリット ⚫ 「情報の蓄積」も適切な場所に行えるような運用を構築する事ができます ⚫ 新たにツールを選択する際に、ツールの選択によって、情報の滞りが起きてしまう悪循環を未然に防げる ⚫ そのツールは本当に必要なものか？別のツールの方が今の情報透過性を高められるのでは？ 51/68
52. コミュニケーションパイプライン設計（CPD） 52/68
53. コミュニケーションパイプライン設計（CPD） Cyllista Game Engine Mail DCC Tools Jira ShotGrid Confluence Slack 53/68
54. Jira → Confluence ⚫ JiraとConfluenceには、同じAtlassian製品という事で、統合機能が標準で用意されている ⚫ Jira課題の進捗や状況をConfluenceにドキュメントとして掲載することが出来る ⚫ 週報や月末進捗などの際にレポートとして作成する事で、各タスクのキャッチアップやスケジューリングに役立て る事が出来る Jira Confluence 54/68
55. ⚫ Jira の機能・プラグインで、Jira Automation というものがある ⚫ Jira の課題が特定のイベント時に Slack に自動通知されるように実装している ⚫ セキュリティのため、Webhook の情報が漏れてもアクセスできない様、IP 制限された踏み台サーバ ーを経由して、Slack に送信される Jira → Slack Jira Automation Slack Jira 踏み台 + Slack App 55/68
56. ShotGrid → Slack ⚫ アセットの作成やタスクのステータス変更時に、従属するタスクの担当者へ変更内容を通知する ⚫ 統合には、ShotGrid Webhook という Outgoing 系の Webhook 機能を使う ⚫ それぞれのサービス間の通信には IP 制限や暗号化通信を前提とする 56/68
57. ⚫ 可用性や 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
58. ⚫ 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
59. 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
60. CP構築の技術選定で気を付ける事 サービスの保守と要望が出た際の対応のしやすさで選定する ⚫ 公式の統合機能や、GUI が存在するプラグインを優先して検討する ⚫ 統合機能の担当者以外でも調整できる余地を残しておく CP全体を俯瞰してツール・サービスを選定する ⚫ 利用目的が重なってしまい二重・三重管理になってしまうことを避ける ⚫ ツール単体よりも、ビジネスロジック層を分析する ⚫ 部分的に導入できるかを検討し、時には切り捨てる事も考慮できると尚良い 特にセキュリティには気を配る ⚫ IP 制限や暗号化通信は前提として構築する ⚫ AWS に関しては、Cygamesではインフラチームと連携し構築している 60/68
61. 結果、何がよくなったか プロジェクトの繁忙期においても、ディレクター・エンジニア・アーティスト・TA・制作管理といった 広範囲をそれぞれ集中して、また、俯瞰して情報を追う事ができている ⚫ 成果物チェックやタスク管理、ドキュメント共有を円滑に進める事ができている 注意しておきたいのが、実はこの問題はオフィス勤務時でも役に立つものであること ⚫ 在宅勤務の様な情報伝達形態の変化は、通常でも起きることがあり、それが「繁忙期」の時期にあたる ⚫ この設計と実装はそもそも3年以上前から進めており、既に一部は運用状態にあった ⚫ そもそも上手くCPDを上手く行うという事は、「オフィスに居たとしても、在宅勤務時にもコミュニケーションで きる環境を作る事が出来る」という事になる TAとしてのメリットも ⚫ 各班の進行状況がより表面に現れてくる ⚫ 相談対応や技術提案を、相手からの相談を待たずとも能動的に進めることがとてもし易くなった 61/68
62. アジェンダ Cyllista Game Engine について ネットワーク環境の変化への対応 ⚫ Perforce での共有方法について ⚫ アセットキャッシュの共有方法について ⚫ 低速回線や不安定な回線に対するフォローについて ⚫ DCC / エンジン回りのプロジェクトメンバー向けツール対応について コミュニケーション手段の変化への対応 ⚫ 在宅勤務時の各種情報共有とキャッチアップ性の改善・向上の取り組みについて ⚫ Cyllista Game Engine のゲーム開発者のサポート体制について 62/68
63. 在宅勤務向けに開始した運用 相談窓口となるSlackチャンネルの運用 ⚫ Slack に相談窓口となるチャンネルを作成し、ツール班のメンバーが毎朝通話を開始する ⚫ 2021年8月以降はハドルミーティングに切り替え ⚫ 困ったことや相談事がある人はいつでもこの通話に参加してきてもOK ⚫ ツール班のメンバーが対象 ⚫ 10:00 ～ 19:00 までは基本的にこの通話に参加したまま業務をする ⚫ ミュートにするのはOK ⚫ 集中したい時は通話を抜けるのはOK（用があれば通話に招待される） 63/68
64. 相談窓口のチャンネルを始めた背景 当初はツール班内のコミュニケーションを円滑にするために始めた ⚫ 朝会以外に会話する機会が少なくなってしまった ⚫ 話したいことがあるときは「通話いいですか？」「いいですよ」とテキストでやり取りの後、通話するという感じ で気軽に会話ができなかった ⚫ 一人暮らしだと１日だれとも話さないことも… 結果 ⚫ 不具合の相談などでユーザーをこの通話に招待してツール班のメンバーで事情を聴くということが 多くなり、困ったときにはだれでもこの通話に相談に来てOKにしようということになった 64/68
65. 相談窓口チャンネルの効果 困ったら通話に参加して相談すればどうにかなるという体制が構築できた ⚫ 常にオープンな相談窓口の通話が開いていることで、相談先に迷う人をフォローできるようになった ⚫ 不具合報告や要望に対してのリアクションを早く起こせるようになった ⚫ 不具合の状況を通話しながら画面共有で確認できるので情報共有が早くなった ⚫ 現場最速！という意識がツール班に芽生える コミュニケーションが円滑になった ⚫ ちょっとした質問や相談が気軽にできるようになった ⚫ オフィスのように座席の距離がないので、声をかけやすくなった ⚫ ちょっとした雑談もオフィスにいたときのように活性化した 65/68
66. 参考: プロジェクトの Slack 運用ルール チャット ⚫ 返信が必要な場合は必ず対象者にメンションをつける ⚫ 自分宛のメンションには必ず返信する ⚫ グループメンションにも必ず返信もしくはリアクションをする ⚫ 定時時間外でもメンションは付ける ⚫ メンションされる側が通知の制御を行う 通話 ⚫ 業務時間中は、いつ、誰に対しても Slack 通話を発信してよい ⚫ Slack 通話の着信は出れなければ出ないで OK ⚫ 雑談は意識して行う ⚫ 時間を決めて出入り自由の雑談用の通話を立てるなど 66/68
67. まとめ: コミュニケーション手段の変化 コミュニケーションパイプラインを考えてツールやサービス選択・統合構築をしていく ⚫ 情報の透過性を高める事で、「伝えた、伝えてない」を無くす！ ⚫ パイプをつなぐ仕組みが多岐に渡るので、保守性や安全性も込みで構築していく ⚫ こうした仕組みは、在宅勤務以外（複合も込み）でも有効 運用ルールを共有して文化構築をしていく ⚫ 困ったことがあったときに相談できる場所を明確に示しておくことで相談先に困る人をフォロー ⚫ ルールを明文化して共有することで、プロジェクトメンバー間のコミュニケーションに対する認識 が揃う。 67/68
68. 最高の開発環境で最高のゲームを 68/68