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

by Cygames

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

⚫ 可用性や 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

Slide 58

Slide 58 text

⚫ 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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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