「どう作り続けるか」 ― 9年目のREALITYが挑んだアセット制作フローの再設計

by gree_tech

Embed

Start on current slide

Slide 1

Slide 1 text

「どう作り続けるか」 9年目のREALITYが挑んだアセット制作フローの再設計 REALITY株式会社テクニカルアーティスト池谷駿弥

Slide 2

Slide 2 text

池谷駿弥 (Shunya Iketani) REALITY株式会社テクニカルアーティスト ● 2022年、グリー株式会社（現グリーホールディングス株式会社）へ新卒入社し、REALITY株式会社に配属 Unityエンジニアとしてアバター機能の開発やアセット運用を担当 ● 約1年半の社内プロジェクトを経て、2025年7月のTechnical Artチーム発足に寄与 ● 現在はTAとして、アセット制作パイプラインの整備からアプリ機能の開発まで幅広く担当 2

Slide 3

Slide 3 text

目次・アジェンダ ● アプリ「REALITY」と、REALITYのアセット ● アセットを「どう作り続けるか」 ● アセット制作パイプラインの改善 ○ 品質担保の安定化 ○ 管理の安定化 ● まとめ 3

Slide 4

Slide 4 text

アプリ「REALITY」 4

Slide 5

Slide 5 text

自分好みのアバターでライブ配信 REALITY（リアリティ）は、誰でもスマホ１台でアバターの姿になり、顔出しナシでライブ配信、ゲームやチャットなどコミュニケーションを楽しむことができるアプリです。 2018年8月リリース今年、9年目 🎉

Slide 6

Slide 6 text

楽しみは盛りだくさん！ 6

Slide 7

Slide 7 text

膨大なアセット制作 Unityを用いて開発されており、アバター・家具アイテム合わせて ● 毎月340以上の新規アイテム、 2800以上の新規ファイルを制作 ● 月10本前後の新規ガチャがリリースされ、平均1ガチャ/3日ペースで新作ガチャが登場毎週アセットリリースが行われる体制 7

Slide 8

Slide 8 text

急激な制作加速事業方針の変化に伴い、アセット制作数が爆発的に増加し、現在では過去の約5倍の制作量へアバターガチャ家具ガチャ過去3年は⽉1~2本で推移家具ガチャ開始新たなアバターアイテム制作チーム発⾜新シリーズのアバターガチャ開始 8

Slide 9

Slide 9 text

How We Build? 9

Slide 10

Slide 10 text

How We Build? 長期運用のため、「どう作るか」だけでなく... 10

Slide 11

Slide 11 text

「どう作り続けるか」 11

Slide 12

Slide 12 text

REALITYアバターアイテム制作パイプライン企画 2D (Photoshop) 3D (Maya) マスタデータ入稿 Unity 組み込みビルド実機確認 PR レビューリリース ● パイプライン / 各工程の具体的なフローともに、リリース当初から 5年の間に大きな変化なし ● 工程によっては、長期運用に伴って属人化が発生し、制作加速のボトルネックに... 12

Slide 13

Slide 13 text

運用期間が長いと、なぜ属人化するのか多くの機能開発・アセット制作により、アセット仕様・データが複雑化・多様化全ての仕様・機能を詳細に把握した上で、アセットの制作とチェックが必要他開発環境・他アセットへの影響を回避しながら、制作物がデータ格納・ビルド・リリースされる「運用事故を回避し安定的な制作を行うこと」が目的 13

Slide 14

Slide 14 text

矛盾する二大命題への直面制作加速効率的にアセットを作り続け、量産する VS 安定化運⽤事故を起こさずアセットを制作する効率化による制作加速を行ってきたが、制作現場は限界を迎えた矛盾する2つを高い次元で両立させる必要がある 14

Slide 15

Slide 15 text

効率性を維持しながら、安定性を実現する制作加速効率的にアセットを作り続け、量産する VS 安定化運⽤事故を起こさずアセットを制作する効率化はすでに行ってきたので、済み品質担保の安定化誰もが⾼⽔準なアセット制作が可能で、「必然的な」安定性を醸成させる管理の安定化「ミスが起こり得ない」管理体制の実現 15

Slide 16

Slide 16 text

制作パイプラインへの反映 2つに分離してアプローチできることが、制作パイプラインからもわかる ● アセットそのものを作る工程に対して、品質担保の側面から ● 制作したアセット・メタ情報の共有・ビルド・リリースなどの工程に対して、管理の側面から企画 2D (Photoshop) 3D (Maya) マスタデータ⼊稿品質担保の安定化誰もが⾼⽔準なアセット制作が可能で、「必然的な」安定性を醸成させる Unity 組み込みビルド実機確認 PR レビューリリース管理の安定化「ミスが起こり得ない」管理体制の実現 16

Slide 17

Slide 17 text

2つの「安定化」の側面から各工程の改善を実施品質担保の安定化誰もが⾼⽔準なアセット制作が可能で、「必然的な」安定性を醸成させる管理の安定化「ミスが起こり得ない」管理体制の実現効率的なアセット制作を維持しながら「事故のない安定的な制作」を実現する！ 17

Slide 18

Slide 18 text

品質担保の安定化 18

Slide 19

Slide 19 text

品質担保の安定化 3Dデータにおける事例企画 2D (Photoshop) 3D (Maya) マスタデータ入稿 Unity 組み込みビルド実機確認 PR レビューリリース 19

Slide 20

Slide 20 text

品質担保の安定化 Mayaで破綻が確認できない問題 REALITYでは柔軟な体型変更が行え、どのような体型でも耐えうる3D制作が要求される突き抜け回避などの調整がより困難となり、 Unity組み込み後に破綻が判明し、 Maya ⇔ Unityの往復作業に... 20

Slide 21

Slide 21 text

品質担保の安定化 Maya上で「Unityの見た目」を再現 Unity上の体型変更機能と同等機能を、Maya上に実装 → 破綻をMaya上で再現でき、即座に修正可能に 21

Slide 22

Slide 22 text

品質担保の安定化 Maya上で「Unityの見た目」を再現 Unity上の体型変更機能と同等機能を、Maya上に実装 → 破綻をMaya上で再現でき、即座に修正可能に突き抜けが発生しているメッシュが赤くハイライトされる 22

Slide 23

Slide 23 text

品質担保の安定化 Unity組み込みにおける事例企画 2D (Photoshop) 3D (Maya) マスタデータ入稿 Unity 組み込みビルド実機確認 PR レビューリリース 23

Slide 24

Slide 24 text

品質担保の安定化 Unity組み込みにおける改善 ● アバターアイテムアイコンの作成 ● 組み込み状態のチェック 24

Slide 25

Slide 25 text

品質担保の安定化 Unity組み込み事例共通の問題点アバターアイテム仕様の多様性・複雑性が非常に高く、仕様により組み込み方法が大きく異なる！約30のカテゴリ数、約50の種別数シェーダの種別/マテリアルプロパティ値の違い約30のカテゴリ REALITY独自の特殊効果/機能の有無マニュアル化しても膨大すぎるため、組み込み対象の仕様がどれに該当するかの照合自体が困難同カテゴリにおける装着部位などのによる種別違い 25

Slide 26

Slide 26 text

品質担保の安定化アバターアイテムアイコン ● アイテム仕様ごとに異なる作成手法 ● デザインに応じて柔軟に撮影をカスタマイズできる手法が必要アイテムに応じて、撮影・作成手法が異なるアプリUI上に表示される 26

Slide 27

Slide 27 text

品質担保の安定化以前のアイコン作成手順(服アイテム) 以前は、「グリーンバッグ + 緑肌で撮影 → Photoshopで編集」と言う作業だった → 定型的な作業にもかかわらず、非常に手間な作業網⽬など、複雑な形状の肌部分を透過させることは⾮常に困難 27

Slide 28

Slide 28 text

品質担保の安定化アイコン撮影ツール ● 常時制作する全仕様に対応し、種別ごとに全く異なる手法を1ボタンで実現 ● 一部アイテムは魅力的な表現を可能とするため、画角調整も可能実際に生成された画像服アイテムの場合、撮影用シェーダにより肌を透過させている 28

Slide 29

Slide 29 text

品質担保の安定化以前の組み込み状態のチェック ● 組み込み対象がどの仕様に該当するのかの照合すら難しい ○ → チェック作業は、シニアアーティストやアバター担当エンジニアですら一苦労 ● 目視でのチェック体制だったが、膨大すぎて工数・心理面ともに限界だった... ○ ガチャの場合、「月3~6本」 × 「約30アイテム、500ファイル」 × 「修正回数」 ○ 20営業日換算の単純計算で、最低でも150ファイル/日の工数が必要 29

Slide 30

Slide 30 text

品質担保の安定化チェックツール ● ● ● 膨大な仕様の組み合わせによるバリエーション全仕様に対応ビジュアル的制約・システム制約・暗黙知(ノウハウ)まで総合的に踏まえ実装した、完全自動チェック仕様自動判別から、データ間参照、ファイル内の詳細なパラメータに至るまで、非常に詳細なチェックを実現対象を選択するだけファイル間の整合確認 ● 作業者自身でチェック ● 「ツールがOKを出せば問題ない」というルールという体制へ 30

Slide 31

Slide 31 text

品質担保の安定化「品質担保の安定化」におけるポイント確信度の向上 100%正しく動く・見える状態へ近づけ、パイプラインの各工程ごとの品質向上と手戻り防止思考の単純化複雑・多様な仕様を隠蔽し、「思考の単純化」を図り、本来の「創造的作業」に専念させるシステムからルールを作る暗黙知・ノウハウまで含めた総合システムにより、システムに従えば「必然的に」ルール通りに 31

Slide 32

Slide 32 text

管理の安定化 32

Slide 33

Slide 33 text

管理の安定化ビルド・実機確認における事例企画 2D (Photoshop) 3D (Maya) マスタデータ入稿 Unity 組み込みビルド実機確認 PR レビューリリース 33

Slide 34

Slide 34 text

管理の安定化 REALITYアセットのブランチ構成とAssetBundle ● REALITYでは、Git, GitHubによってバージョン管理。リリース単位ごとにブランチ作成 ● アセット確認者がAssetBundleのバージョンを意識しなくとも済むように、後方互換性を保つブランチツリー構成が組まれており、専用ブランチまで順番にマージしてビルドメインブランチ次にリリースのアバターガチャその次にリリースのアバターガチャシリーズごとのツリー (アバターショップ, 家具ガチャ, ギフトアセット, etc…) 開発環境ABビルド用ブランチ順番にマージを行い、マージ後のブランチでABビルド合計約30以上のブランチで並行的に制作されている 34

Slide 35

Slide 35 text

管理の安定化以前の開発環境ABビルド体制 ● 各ガチャシリーズの責任Art担当者から、アセット担当エンジニアへビルド依頼 ● アセット担当エンジニアが順番に手動マージした上で、ビルドを実施なぜエンジニアがマージ？課題・リスク ● 約30以上のブランチ全てを把握し、適切に制御する必要性 ● ブランチ間マージ時におけるコンフリクト解消対応 ● マージ順のミスによるチーム全体成果の消失リスクの回避 35

Slide 36

Slide 36 text

管理の安定化開発環境ABビルド体制の改善 Art 自身でビルド可能 API経由で起動 GitHub Actions Slack Bot develop asset/gachakamikoma エンジニアブランチツリーを定義するだけ asset/gacha-love-illumination マージ順を提供 assetbundle-lab マージ後のブランチで ABビルド定型作業のみをシステム移譲し、本来人間が行うべき制御部のみを分離 36

Slide 37

Slide 37 text

管理の安定化 PRレビューにおける事例企画 2D (Photoshop) 3D (Maya) マスタデータ入稿 Unity 組み込みビルド実機確認 PR レビューリリース 37

Slide 38

Slide 38 text

管理の安定化以前のPRレビュー体制 ● Unity組み込み時と同様、どの仕様に該当するのかの照合すら難しい ● Unity Editorで1ファイルずつ詳細に目視でチェックする体制 ○ ガチャの場合、「月3~6本」 × 「約30アイテム、500ファイル」 × 「修正回数」 ○ 1回あたり5時間以上の工数をかけることも多々あり膨⼤すぎて⼯数‧⼼理⾯ともに限界 38

Slide 39

Slide 39 text

管理の安定化 PRレビュー体制の改善 ● ● Unity組み込み時のチェックツールを流用し、GitHub ActionsでPRレビューを自動化ビジュアル的制約・システム制約・暗黙知(ノウハウ)まで総合的に踏まえ、全仕様に対応 PRに特定ラベルをつけるだけアイテムごとにレビュー結果が確認可能 5時間以上の工数が5分に！ 39

Slide 40

Slide 40 text

管理の安定化ファイルごとの詳細なチェック結果もPR上で確認可能 Unity Editorでのチェックと同じ内容 GitHubで確認困難なバイナリデータやデータ間参照なども問題なし！ 40

Slide 41

Slide 41 text

管理の安定化 GitHub Actionsチェックの恩恵 ● 変更差分全てを調べている & 全仕様対応ツールなので、不要データの混入を検知可能 ● アイテムごとの結果をアセット制作目的と比べることで、意図しない変更を検知可能不要データ混入制作企画として、追加予定のものでないなら、意図しない変更発生と判断可能 41

Slide 42

Slide 42 text

管理の安定化 GitHub Actionsチェックの恩恵 ● 変更差分全てを調べている & 全仕様対応ツールなので、不要データの混入を検知可能 ● アイテムごとの結果をアセット制作目的と比べることで、意図しない変更を検知可能リリース前の最後の工程として、絶対に壊れたアセットを「リリースできない」ゲートキーピング体制を実現 42

Slide 43

Slide 43 text

管理の安定化リリースにおける事例企画 2D (Photoshop) 3D (Maya) マスタデータ入稿 Unity 組み込みビルド実機確認 PR レビューリリース 43

Slide 44

Slide 44 text

管理の安定化以前のリリース体制アバター・ルーム・ワールド・ギフトなどの各領域担当エンジニアが、PdM定義のスケジュールと、 Art提出のPRを手動照合し、リリースビルド前にマージを行う 4/13にガチャリリースしたいらしいので、該当のPRを探して4/8にマージして、 4/10のABリリースに載せる 44

Slide 45

Slide 45 text

管理の安定化以前のリリース体制リリース作業担当エンジニアが、各領域担当エンジニアにマージ済みかを確認してからビルドするリリースReady? OK! アバター担当エンジニアリリースReady? No… リリース作業エンジニアルーム担当エンジニアアセット進捗いかがでしょう？ルーム担当 Art リリースReady? OK! ギフト担当エンジニア 45

Slide 46

Slide 46 text

管理の安定化リリース体制の改善 PdMはリリース日のNotion登録だけ。エンジニアはPRレビューだけ。 → Notion, GitHub PR、どちらかが不正の場合は、マージ & リリースが強制ストップリリース日対象のPR PdM判断のリリース可否 (PdM) 確認中... (エンジニア) Approve！リリース準備できてない！ PRはApproveされているが、NotionでWIPがついてるのでストップ 46

Slide 47

Slide 47 text

管理の安定化リリース体制改善による効果 ● マージ・取りまとめ・リリース意思確認など、定型作業をシステム移譲し、本来人間が行うべき判断部分のみを分離 ● 各領域担当、PdM・エンジニアそれぞれが、Notion / GitHubを通じて独立してリリース可否判断が行え、本来の自身の責任範囲のみに注力できる体制に 47

Slide 48

Slide 48 text

管理の安定化「管理の安定化」におけるポイント定型作業のシステム移譲と、制御部への人の集中「制御部」を見極め分離することで、一括管理体制と分散稼働を両立可能人に依存しない検知と、強制停止の仕組みをつくる新規仕様や意図しない変更を後続工程に流さないゲートキーピングを行う体制責任範囲の分散属人化を徹底排除しながら適切な責任範囲分割を行うことで、独立した作業を可能に 48

Slide 49

Slide 49 text

まとめ 49

Slide 50

Slide 50 text

矛盾する二大命題を高い次元で両立！制作加速安定化効率的にアセットを作り続け、量産する運⽤事故を起こさずアセットを制作する品質担保の安定化誰もが⾼⽔準なアセット制作が可能で、「必然的な」安定性を醸成させる管理の安定化「ミスが起こり得ない」管理体制の実現効率的なアセット制作を維持しながら「事故のない安定的な制作」が可能に！ 50

Slide 51

Slide 51 text

まとめ「人」に依存しないことが、最大の「人を活かす」道個人の経験や知識をシステムに移植し、チェック・管理から解放。本来の「創造的作業」に集中でき、責任と作業負荷を適切に分散できる。「システムからルール」を作り、思考の単純化を図る暗黙知まで含めた広範な知見のシステム組み込みと、システム自体をルールとする運用により、複雑・多様な仕様を隠蔽し、スケーラブルで長期的な安定性を支える基盤へアセット制作の加速と安定は、両立できる矛盾しトレードオフとされる効率化と安定性は、適切なプロセス設計により高い次元で統合可能スケール可能なチーム体制を実現し、「作り続ける」長期運用でも問題なし！ 51

Slide 52

Slide 52 text

ご案内改善に至った組織としての経緯などは別セッションにて発表しています REALITYにTAチームができるまでの軌跡〜ミッション：ガチャ本数５倍に対応せよ！〜 Track C 14:00~ 52