REALITYにおけるデザインシステムの導入

by gree_tech

Slide 1

Slide 1 text

REALITY株式会社　プロダクトデザイナー　吉田明史 REALITYにおけるデザインシステムの導入 REALITY株式会社　Androidエンジニア　飯尾直樹

Slide 2

Slide 2 text

• 2019年にグリー株式会社/REALITY株式会社に新卒として入社 • 入社時の役職はプロダクトマネージャー • 2021年12月からはプロダクトデザインチームに配属 • 新機能開発におけるUI/UXの設計と並行してデザインシステムなどのタスクも行う • 好きな音楽はエクスペリメンタル・ヒップホッププロダクトデザイナー自己紹介吉田明史 2 

Slide 3

Slide 3 text

• REALITY株式会社 • 2022年3月入社 • 前職:サーバーエンジニア • REALITY: Androidエンジニア • Jetpack Compose / UI / Architecture • Twitter: @pika_sigure クライアントエンジニア / Android 自己紹介飯尾直樹

Slide 4

Slide 4 text

Part 1 - REALITYの紹介 Part 2 - デザイナーのデザインシステムへの関与 Part 3 - エンジニアのデザインシステムへの関与 Part 4 - まとめ今日の発表内容の概要 4 

Slide 5

Slide 5 text

REALITYの紹介

Slide 6

Slide 6 text

• REALITYはREALITY社が運営するモバイルアプリ • “なりたい自分で、生きていく”をミッションに、営為開発中 REALITYというアプリについての概要 REALITYについて 6  アバター  ライブ配信  コミュニケーション  ゲーム  ワールド 

Slide 7

Slide 7 text

• 昨今のメタバース需要の高まりやコロナ禍以降の生活様式の変化なども影響し、ユーザー数が年々増加している • それに伴いREALITYアプリの開発チームの人員も増員中 • プロダクトマネージャー • 2019年から2022年で約1.5倍 • プロダクトデザイナー • 2019年から2022年で3倍 • エンジニア • 2019年から2022年で約3倍 REALITYの組織拡大フェーズなどについて

Slide 8

Slide 8 text

デザイナーのデザインシステムへの関与

Slide 9

Slide 9 text

• REALITYアプリリリースから長期間専任のデザイナーが一人という状況が続いていた • 先述の通り組織が拡大している背景もありデザイナーを増員すると共に、 2021年12月に（ようやく！）正式にプロダクトデザインチームとして発足 • 当時のメンバーは • マネージャー/リードデザイナー/デザイナー（専任）/デザイナー（兼任） • ちなみに現在のメンバーは • マネージャー/デザイナー（専任）x2/業務委託 x1.5 プロダクトデザインチーム発足の流れデザイナーのデザインシステムへの関与

Slide 10

Slide 10 text

デザイナーが少ないことがもたらす悪循環デザイナーのデザインシステムへの関与改善意欲の向上現実の前に敗れる冒頭に戻るどんどん負債が積み上がっていくし効率を上げねば...! とはいえ定常タスクが多すぎて時間が確保できない... データ整理とかガイドライン定義したらもっと効率上がるのでは？

Slide 11

Slide 11 text

年代別デザインチームの状態と変遷デザイナーのデザインシステムへの関与一人だとどうしても課題特定,解決する時間がない 2018~2020 エンジニアも増えてるしそろそろ採用頑張らないとヤバい！ 2021 2022~現在採用できて人が増えたからやっと色んな課題に取り組める！

Slide 12

Slide 12 text

どうやって課題領域と課題の優先度を決めたか

Slide 13

Slide 13 text

UXボードの作成 • UXボードとは • ペパボブログで紹介されていたデザイン力の可視化ツール • チームとしてはゼロからのスタートだったため、まずは他社事例を参考にした上で課題特定を試みた • UXボードに記載された各領域の中でも、より実際的にUIの制作に関わる領野の改善を目指すことを決めた • UIデザイン力と効率を上げれば余裕が生まれやすいと考えたため

Slide 14

Slide 14 text

当時UIデザインする上で抱えていた課題と悪循環デザイナーのデザインシステムへの関与コンポーネントの使い方がケースバイケースすぎる... 新規デザインを作るたびに無駄な時間がかかる... デザイン整理する時間も確保しづらい... 実機とFigma どっちが正しいんだっけ？ Figmaのデザインデータが壊れている,紛失している... デザインのレビューに納得感がない...

Slide 15

Slide 15 text

デザインシステム導入に至るデザイナーのデザインシステムへの関与デザインシステムを作れば今抱えている課題全部解決では！？！デザインシステムを作れば...勝つ！！

Slide 16

Slide 16 text

ようやくデザインシステムの話

Slide 17

Slide 17 text

デザインシステム導入の際に陥りがちなミスデザイナーのデザインシステムへの関与デザインシステムは凄い！完璧なシステムを作るぞ！本格検討以前やることめちゃくちゃ多いのでは...？作業範囲検討作業開始時点やることが多すぎるし一人じゃ無理だ... でもこれ以上工数を割けない...

Slide 18

Slide 18 text

少人数のチームで完璧なデザインシステムを作ろうとすると大体破綻するのでまずはスモールスタートが大事！

Slide 19

Slide 19 text

スモールなデザインシステムへの取り組み方デザイナーのデザインシステムへの関与インプット色々な手法も完成度もあるけど弊社の場合まずこれだけやれば良いのでは？批判検討作業開始まずは勉強会とリサーチを地道に行って正しい知識を身につけよう範囲も絞ったし現実的なスケジュールで進められそう！

Slide 20

Slide 20 text

優先度 1. デザインチームのMVV作成 2. トークン化できるスタイルの定義 3. 利用頻度の高いコンポーネントの定義 4. スタイルのマスターファイルへの反映 5. スタイルを反映させた実装 6. コンポーネントのマスターファイルへの反映 7. コンポーネントを反映させた実装最終的な優先度とやらなかったことデザイナーのデザインシステムへの関与 20  やらなかったこと • 利用頻度の低いコンポーネントのシステム化 • UXが関与する内容のシステム化 • 定義完了した後、即座に本番へと反映させていくこと • 網羅性が高すぎるオリジナルのデザインシステムを参考にすること • ex.ant,Goldman Sachs, etc…

Slide 21

Slide 21 text

参考にしたデザインシステム

Slide 22

Slide 22 text

• デザイン作成に際して発生する無駄な思考コストを削減できる • 仮にこれまで議論されていなかった定義の曖昧さが浮上してもデザインシステムに組み込めば良い、という安心感がある • 適切な運用方針が定まっている場合、デザイン的資産が積み上がっていく • コンポーネントやスタイルなどへの理解度が上がる • 要件定義能力や意思決定能力が培われる • UI的な体験の統一性が生まれることによって、 UI以外の観点からUXについて考慮しやすくなる作り進めた上で改めて感じるデザインシステム制作の意義デザイナーのデザインシステムへの関与

Slide 23

Slide 23 text

• アプリ開発をする上でデザインを作る、ということは必然的に ENの関与が発生する • よって、定義段階でEN観点からのフィードバックを貰うことが望ましい • また、デザインシステムで定義されたトークンやコンポーネントをどのように管理 /実装するか、はアプリの実装方針/スタイルに基づくため、ENに早期段階でヒアリングをすることが望ましい • 上記に加えてREALITYではwebやunityも混在するため、どこまでをnative完結にするか、などを相談する必要があった • これらの観点から、専任のENをアサインした上でデザインシステム対応チームを発足させた ENとの連携デザイナーのデザインシステムへの関与

Slide 24

Slide 24 text

エンジニアのデザインシステムへの関与 24 

Slide 25

Slide 25 text

エンジニア視点のデザインシステム → UIの開発効率の向上やデザインの統一

Slide 26

Slide 26 text

REALITYはどうなの...?

Slide 27

Slide 27 text

REALITYのUI構成 27 

Slide 28

Slide 28 text

• 配信 • 配信視聴 • 配信一覧 • ゲーム • チャット • ガチャ • プロフィール • クローゼット REALITYの主要な画面 28  視聴画面ガチャチャット

Slide 29

Slide 29 text

Unity REALITYのUIの構成配信画面クローゼットワールドゲーム

Slide 30

Slide 30 text

Native(iOS, Android) REALITYのUIの構成配信一覧チャットガチャ一覧プロフィール

Slide 31

Slide 31 text

Native & Unity REALITYのUIの構成

Slide 32

Slide 32 text

WebView REALITYのUIの構成ガチャお知らせゲームお知らせイベントページ

Slide 33

Slide 33 text

REALITYのUI構成 → Native & Unity & Web 33  Android ロボットは、 Google が作成および提供している作品から複製または変更したものであり、クリエイティブ・コモンズ表示 3.0 ライセンスに記載された条件に従って使用しています。

Slide 34

Slide 34 text

REALITYのUIの難しさ 34 

Slide 35

Slide 35 text

• Native(iOS, Android) + Unity + Web • デザインの統一が難しい • 開発自体も複雑 • デザインの整備が進んでいる訳ではなかった • 機能開発との優先度 • 整備や改修への工数の不足 • 開発組織の拡大 REALITYのUIの難しさ・課題 35 

Slide 36

Slide 36 text

• 既存デザインの改修は優先度が低め • 直接的なビジネス的価値は高くなりにくい • 新規機能開発の方が重要性は高くなりがち • バグ対応 / リファクタリングも必要 • UIの改善としても部分的になるケースが多い • コンポーネント単位の改修 • ページ全体の改修は難しい • 結局はいたちごっこになりがち • 開発効率自体をあげたいデザイン改修に対する優先度 REALITYのUIの難しさ・課題 36 

Slide 37

Slide 37 text

• Componentを意識した実装になっていなかった • そもそもデザインが意識されていないので難しかった • 部分的にエンジニアが共通化できる部分はしていた • 宣言的UIの実装が難しくなる • Component単位での実装をしたい • 模索しながらの実装になりがちデザイン改修しやすい実装 REALITYのUIの難しさ・課題 37  デザインが共通化されていない

Slide 38

Slide 38 text

• エンジニアの人数は右肩上がり • 今年初め時点から倍増 • 開発メンバーの増加 • 個人の実装の裁量も増加する • 統一感や品質の担保が難しくなっていく • 開発環境の整備が重要エンジニア組織の変化 REALITYのUIの難しさ・課題

Slide 39

Slide 39 text

REALITYでのデザインシステム導入の取り組み 39 

Slide 40

Slide 40 text

• 通常の施策機能開発とは別線のプロジェクト • 中長期的な活動で一定の工数が必要 • 一定の工数をTaskforceに優先できるようにする • REALITYでは15% • 明確なルールとすることで腰を据えて取り組める • デザインシステムへの取り組みをしやすくエンジニア目線のデザイン的課題について Taskforce

Slide 41

Slide 41 text

• FigmaExport • https://github.com/RedMadRobot/figma-export • Figma上のデザインデータを自動的に出力する • icon, image • Component単位で画像の書き出しを実行する • デザインシステム上の画像リソースを自動エクスポートする • https://speakerdeck.com/yutoyazaki/automate-image-export-from-figma-t o-ios-and-android-using-figma-export エンジニア目線のデザイン的課題についてリソース出力の自動化 41 

Slide 42

Slide 42 text

• REALITYでは積極的に宣言的UIを導入中 • 今年から本格的に進行中 • Native • Jetpack Compose • SwiftUI • メリット • モダンかつ話題な技術 • コード量の削減 • 再利用性の向上 • デザインシステムと相性が良いエンジニア目線のデザイン的課題について宣言的UIの導入 42 

Slide 43

Slide 43 text

• UIを実装するエンジニアはデザインシステムを使える状態に • デザインシステム自体の一定の理解 • Figmaからデザインシステムの定義を読み取れる • 定義されたデザインシステムの実装を利用できるデザインシステムを使える環境の整備デザインシステムが使える環境 43 

Slide 44

Slide 44 text

• エンジニア全員が定義の部分から関わる必要はない • REALITYでは各クライアントからメイン担当が一人 • Android / iOS / Web / Unity • 担当のエンジニア • 会議への参加 • デザインに対するレビュー • 定義の実装 • メンバーへの説明・浸透デザインシステムを使える環境の整備エンジニアの関わり方 44 

Slide 45

Slide 45 text

• 会議への参加 • 担当するエンジニアのみの参加 • エンジニアとデザイナーで協業して作り上げる • エンジニアがレビューすべき箇所 • 命名や分岐、既存の実装箇所等 • 実装に影響するので、エンジニアがレビューした方が良いデザイナー側との連携エンジニアの関わり方

Slide 46

Slide 46 text

• 定義の実装 • Taskforceとして工数を持っているので着手しやすい • 担当エンジニアがそのままタスクを持つのがスムーズ • デザインシステムの説明・浸透 • 実装されていても使われていなければ意味がない • メンバーに説明したり、コードベースで浸透させていく • デザインシステム以外の定義の置き換え • 過去の実装についてはDeprecatedにしていくデザイナー側との連携エンジニアの関わり方

Slide 47

Slide 47 text

まとめ

Slide 48

Slide 48 text

• そもそもPDとENとで異なるデザイン的課題を有しており、かつそれらが話し合われていないことが分かった • iOS/Androidでデザイン的に統一しやすい箇所とそうでない箇所の判別が容易になり、結果機能開発におけるデザイン作成においてデザインを統一すべきかそうでないかの判断がしやすい • マスターページの管理が楽になる • 既存デザインに対しての定期的な見直しがしやすい導入の成果まとめ 48 

Slide 49

Slide 49 text

• いかにコストカットしながら進めていくか • デザインシステムがあれば楽になるだろう、という側面は多々あることは理解しつつも、デザインシステムを構築するのは大変すぎる気配があるため着手できないケースや、そもそもの定常業務が忙しすぎてそれどころではない、みたいなケースは頻繁にありそう • 作業範囲を削りつつ、一歩目を定める必要がある • デザインシステムを推し進める担当者は、それがいかに大事であるかを周囲に伝えると共に、作業時間を確保できるように相談することが大事 • ENとの連携や開発チームへの浸透作業 • 意思決定者を明確に定めること進める上での課題まとめ 49 

Slide 50

Slide 50 text

• 新規メンバー中心に作り進められたこと • 2019年末から2022年初頭に入ったメンバーを中心にデザインシステムチームを組成し、各人がオーナーシップを持って取り組めたこと • デザインシステムを作ることが目的になりすぎず、あくまで課題ベースでデザインシステムの要素を抽出して作り進められたこと • 作り進める中で見つかった課題をちゃんと定例で話し合った上で軌道修正し、最適手段を模索できたこと • 担当メンバーに放り投げ、みたいにならずマネージャーレイヤーのメンバーも定例に参加し議論ができていた REALITY社におけるよかったポイントまとめ 50 

Slide 51

Slide 51 text

REALITY社は現在絶賛採用中です！ • Meetyでのカジュアル面談 • スカウト待ち登録 • 月一のREALITY Meetup • 知り合いの社員がいる場合参加可能 • Wantedlyからの応募など様々な形で採用をしておりますのでお気軽に面談 /応募してみてください！採用まとめ 51 