『プロジェクトセカイカラフルステージ！ feat. 初音ミク』UI全面リニューアルの対応事例とそれを支えたタスクフォースチームの紹介【CAGC2024】

Slide 1

Slide 1 text

『プロジェクトセカイカラフルステージ！ feat. 初音ミク』 UI全面リニューアルの対応事例とそれを支えたタスクフォースチームの紹介 1 プロジェクトセカイカラフルステージ！ feat. 初音ミク本間純平小林大峰クライアントエンジニアクライアントエンジニア

Slide 2

Slide 2 text

プロジェクトセカイカラフルステージ！ feat. 初音ミク 2 ユーザー数 1000万人超 X（旧Twitter）フォロワー数 200万人公式YouTube チャンネル登録者数 156万人 ● 『初音ミク』と『人間』が織りなす新しい物語・新しい展開 ● 2D･3D･Live2D−− それぞれ描かれる魅力的なキャラクターたち ● VOCALOID曲を中心に有名楽曲を多数収録したリズムゲーム ● 数多の著名クリエイターから提供される楽曲・クリエイティブ魅力的なキャラクター（シナリオ・イラスト）× リズムゲーム

Slide 3

Slide 3 text

UIリニューアルとは？

Slide 4

Slide 4 text

4 『プロジェクトセカイカラフルステージ！ feat. 初音ミク』(以降、プロジェクトセカイ) の 3周年アップデートにて行われた施策の一つ。ゲーム内の全ての画面のUIをリニューアルさせる。 (レイアウトや挙動の刷新、及びそれらに使われている画像素材の作り直し) UIリニューアルとは？ Old New Renewal！

Slide 5

Slide 5 text

5 大きく勝手は変わらないが、UIデザインが変わる UIリニューアルとは？

Slide 6

Slide 6 text

UIリニューアルの目的

Slide 7

Slide 7 text

UIリニューアルの目的 7 リリースから3年が経ったプロジェクトセカイのUIを、古さを感じさせないUIにアップデートする

Slide 8

Slide 8 text

UIリニューアルの課題

Slide 9

Slide 9 text

9 UIリニューアルの課題 1. 多すぎる画面数 2. 過去の技術的負債 3. 止まらない運用開発

Slide 10

Slide 10 text

10 UIリニューアルの課題 1. 多すぎる画面数 2. 過去の技術的負債 3. 止まらない運用開発

Slide 11

Slide 11 text

UIリニューアルの課題 / 多すぎる画面数 11 ● 画面数約200画面 ● 固有ダイアログ数300以上 ● UIアニメーションの刷新おまけにTextをTextMeshProに総替え　　　　　　　　　　

Slide 12

Slide 12 text

UIリニューアルの課題 / 多すぎる画面数 12 ● 画面数約200画面 ● 固有ダイアログ数300以上 ● UIアニメーションの刷新おまけにTextをTextMeshProに総替え　　　　　　　　　　

Slide 13

Slide 13 text

UIリニューアルの課題 / 多すぎる画面数 13 Q. ひとりで100画面くらい対応できればいけるか...？ (当初二人）

Slide 14

Slide 14 text

UIリニューアルの課題 / 多すぎる画面数 14 A. さすがに厳しい.... ので、各課題に対するアプローチを考えていく

Slide 15

Slide 15 text

UIリニューアルの課題 / 多すぎる画面数 15 課題に対するアプローチ ● 画面数約200画面 / 固有ダイアログ数300以上 → ● UIアニメーションの刷新 →

Slide 16

Slide 16 text

UIリニューアルの課題 / 多すぎる画面数 16 課題に対するアプローチ ● 画面数約200画面 / 固有ダイアログ数300以上 → 共通化や自動化など工夫をしながらひたすら頑張る！ ● UIアニメーションの刷新 → UIが変わればアニメーションも当然変わる。アニメーション班に　制作環境とレギュレーションをお渡ししてお任せする

Slide 17

Slide 17 text

UIリニューアルの課題 / 多すぎる画面数 17 課題に対するアプローチ TextをTextMeshProに総替え　→

Slide 18

Slide 18 text

UIリニューアルの課題 / 多すぎる画面数 18 課題に対するアプローチ TextをTextMeshProに総替え　→ 効率化できるよう、テキストの拡張を作成し、置き換え作業を簡単にワンクリックで置き換え！と、言う拡張

Slide 19

Slide 19 text

UIリニューアルの課題 / 多すぎる画面数 19 やらなくてはいけない物量は変わらないとにかく無駄な所にコストをかけないように、共通化や自動変換を最大限行う

Slide 20

Slide 20 text

20 UIリニューアルの課題 1. 多すぎる画面数 2. 過去の技術的負債 3. 止まらない運用開発

Slide 21

Slide 21 text

UIリニューアルの課題 / 過去の技術的負債 21 ● 読解が難しくなってしまった楽曲選択画面 ● コールバック地獄で進行するゲームリザルト ● 複雑なシナリオシーンのコード ● 混在する非同期処理（CoroutineやUniTask）

Slide 22

Slide 22 text

UIリニューアルの課題 / 過去の技術的負債 22 ● 読解が難しくなってしまった楽曲選択画面 ● コールバック地獄で進行するゲームリザルト ● 複雑なシナリオシーンのコード ● 混在する非同期処理（CoroutineやUniTask）さらに、３年間の運用の中で、改修によって生まれた一時コードが点在

Slide 23

Slide 23 text

23 これからも向き合って行かなくてはいけないものなので、お掃除しましょう！ UIリニューアルの課題 / 過去の技術的負債

Slide 24

Slide 24 text

UIリニューアルの課題 / 過去の技術的負債 24 課題に対するアプローチ ● 可読性が低く、複雑になりすぎているコードは可能な限りリファクタリングを行う ● チームに馴染みのありそうな MVCモデルの設計に思想を統一し、なるべく寄せていく ● 非同期処理を UniTaskのasync/awaitに統一する ● １画面上で状態が切り替わる場合は、ステートマシンで管理 (極小単位の物は除く) ● 言わずもがなだが、コメントは書く

Slide 25

Slide 25 text

UIリニューアルの課題 / 過去の技術的負債 25 ルールを決めること、守ることはとても大事。プロジェクトが大きくなるにつれて大変になる！

Slide 26

Slide 26 text

26 UIリニューアルの課題 1. 多すぎる画面数 2. 過去の技術的負債 3. 止まらない運用開発

Slide 27

Slide 27 text

UIリニューアルの課題 / 止まらない運用開発 27 運用開発とは、定常的なアップデートのための開発のこと。アップデートを1年止めるわけにはいかないため、平行しながらUIリニューアルの作業を進める必要があった

Slide 28

Slide 28 text

28 アップデート内容は、ユーザーの皆様の声によって決まることも多々あるため、既にリニューアルを終えた画面に改修が入った場合、再度リニューアルを行っていく UIリニューアルの課題 / 止まらない運用開発リニューアル再度リニューアル機能改修/追加 UIリニューアルチーム運用開発チーム

Slide 29

Slide 29 text

UIリニューアルの課題 / 止まらない運用開発 29 課題に対するアプローチアップデートで追加する処理やアセットは、とにかく取り込みやすいようにする！ 1. 1機能1ブランチでの開発を運用開発側に徹底する 2. 機能のロジック部分は極力Utilityやサービスとして外に逃がす 3. 追加する画面のアセットは、小さい単位でUIパーツとして管理する

Slide 30

Slide 30 text

UIリニューアルの課題 / 止まらない運用開発 30 最大の敵はPrefabファイルのコンフリクト

Slide 31

Slide 31 text

31 UIリニューアルの課題 1. 多すぎる画面数 2. 過去の技術的負債 3. 止まらない運用開発

Slide 32

Slide 32 text

32 UIリニューアルの課題銀の弾丸はなかった。 1. 多すぎる画面数 2. 過去の技術的負債 3. 止まらない運用開発

Slide 33

Slide 33 text

その他の課題 33 作業を進めるにつれて、他にもたくさんの課題があった。ユーザーの皆様の意見や需要に合わせ、想定よりも大きく変更があったり、社内レビューのフィードバックの量は多く、既に刷新の終わった画面を何度も刷新を行った。見えていなかった作業も段階が進むにつれて見えるようなっていく。

Slide 34

Slide 34 text

その他の課題 34 作業を進めるにつれて、他にもたくさんの課題があった。ユーザーの皆様の意見や需要に合わせ、想定よりも大きく変更があったり、社内レビューのフィードバックの量は多く、既に刷新の終わった画面を何度も刷新を行った。見えていなかった作業も段階が進むにつれて見えるようなっていく。メンバー全員のやりたい！を実現するのはとても大変。優先度付けと取捨選択はとても大事！

Slide 35

Slide 35 text

UIリニューアルを終えて 35 やりきれた部分とやりきれなかった部分が残る結果となった。今後のアップデートで順次対応していきたい。運用開発と平行でUIを全面リニューアルする事例が少なかったので、今回のリニューアルを終えての学びは自分にとっても、チームにとっても非常に多かった。

Slide 36

Slide 36 text

UIリニューアルを終えて 36 やりきれた部分とやりきれなかった部分が残る結果となった。今後のアップデートで順次対応していきたい。運用開発と平行でUIを全面リニューアルする事例が少なかったので、今回のリニューアルを終えての学びは自分にとっても、チームにとっても非常に多かった。何より、チームで意見を言い合いながらモノを作っていくことは本当に楽しい

Slide 37

Slide 37 text

37 大変だったUIリニューアルを助けるべく、立ち上がってくれたタスクフォースチームがありました。

Slide 38

Slide 38 text

38 UI夢を語る会

Slide 39

Slide 39 text

39 ということで後半の小林君とバトンタッチです

Slide 40

Slide 40 text

40 UI夢を語る会について

Slide 41

Slide 41 text

UI夢を語る会とは？ 41

Slide 42

Slide 42 text

UI夢を語る会とは？ 42 「Colorful Paletteが作るUIのクオリティをアップさせて、他社の作品を上回るレベルのものを生み出せるようにしたい」という目標を達成するために集まった会

Slide 43

Slide 43 text

活動開始まで 43

Slide 44

Slide 44 text

今までのワークフロー 44 アプリ画面のカンプアプリ画面 1. 作成 2. カンプを確認して実装 3. QAでの不具合/修正 4. 修正内容が問題ないか確認 UIデザイナーエンジニア確認

Slide 45

Slide 45 text

45 「もしかして、UIデザイナー側で修正できたりしませんか？」？

Slide 46

Slide 46 text

もしもUIデザイナーがUnityを触れたら 46 アプリ画面のカンプアプリ画面 1. 作成 2. 作ったカンプに沿って実装 3. QAでの不具合/修正 UIデザイナー

Slide 47

Slide 47 text

47 というわけで雑談から始めてみました。「もしかして、UIデザイナー側で修正できたりしませんか？」

Slide 48

Slide 48 text

48 雑談で出た現状の問題点 ● UIの修正をエンジニアが行ってUIデザイナーさんが確認する流れを改善したい ● ワークフローの改善をしたい ● 同じ見た目の画面なのに違うデザインパーツが使われている ● そもそもカンプ画像と実際の画面に違いが出てしまっている etc.

Slide 49

Slide 49 text

49 改善案 ● 「良いカンプ画像」について話し合う ○ どういう情報を伝えることができればエンジニアは UIを綺麗に組みやすいか etc.

Slide 50

Slide 50 text

50 改善案 ● UIデザイナーさんがUnity学ぶ & エンジニアがPhotoshop学ぶ ○ 両者の共通認識分野を広げる ○ 適材適所で、UI修正をUIデザイナーができるような状態が理想 ● 「良いカンプ画像」について話し合う ○ どういう情報を伝えることができればエンジニアは UIを綺麗に組みやすいか etc.

Slide 51

Slide 51 text

51 改善案 ● UIデザイナーさんがUnity学ぶ & エンジニアがPhotoshop学ぶ ○ 両者の共通認識分野を広げる ○ 適材適所で、UI修正をUIデザイナーができるような状態が理想 ● 「良いカンプ画像」について話し合う ○ どういう情報を伝えることができればエンジニアは UIを綺麗に組みやすいか etc.

Slide 52

Slide 52 text

52 「UIデザイナーがUnityを触れるようになりたい」を叶える

Slide 53

Slide 53 text

53 活動内容

Slide 54

Slide 54 text

54 実行したこと「UIデザイナーがUnity触れるようになりたい」を叶える ● 既存画面の修正をエンジニアと一緒に作業しながら行って、 GitとUnityを使ったワークフローを覚える。 ● 週一　18:00 ~ 19:00の時間を使ってゆっくり進める ● 約半年間でUIデザイナーさんが、1から修正・コミット・PRマージまで自分でできる状態を目指し、 UIリニューアルの実務に組み込めるようにする ● 機能修正とかは含めず、 UI位置修正が出来るようになる UIリニューアルに間に合ったら最高だね！　という夢を掲げてスタートする

Slide 55

Slide 55 text

活動の流れ 55 10月 ● 活動開始 12月〜 ● 基礎を覚える 2月〜 4月 ● uPaletteの勉強 ● UIリニューアルの作成済み画面を模写してみる ● 実務に組み込む 6月〜 8月

Slide 56

Slide 56 text

56 GitHubとSourceTreeの使い方を覚える

Slide 57

Slide 57 text

57 Unityの基礎を覚える

Slide 58

Slide 58 text

58 簡単な画面を模写してみる

Slide 59

Slide 59 text

59 簡単な画面を模写してみる

Slide 60

Slide 60 text

60 uPalette勉強会

Slide 61

Slide 61 text

61 やってみて ● 実際にUIリニューアルのBU期間に間に合わせることができた ○ 画像の差し替えや位置調整などを UIデザイナーさんだけで行うことができた ○ エンジニアが対応するときの約3倍の速度でバグを潰せた ● 新規画面のベース作りを UIデザイナーさんだけで行うことができた ● 両者の共通認識を広げることができた ○ なぜカンプと違いが起きてしまうか、などを知ることができた ● UIデザイナーさんの「やってみたい」を増やすことができた ○ UIアニメーションやエフェクト表現などの提案が増えた

Slide 62

Slide 62 text

まとめ ● UIリニューアルで全ての画面の UIのリニューアルを行った ○ 全ての画面を限られた時間で変更していくには工夫が必要だった ■ 共通化や自動変換を最大限行う ■ 取捨選択を行う ■ ルールを決めること、守ることがとても重要 ● UI夢を語る会によってUIデザイナーさんがUnityを触れるようになった ○ UIリニューアルチームを助けることができた ○ 今後のワークフローの改善に繋げることができた

Slide 63

Slide 63 text

63 ご静聴ありがとうございました。