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

GREE Tech Conference 2022で発表された資料です。
https://techcon.gree.jp/2022/session/TrackC-5

Transcript

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

3. • REALITY株式会社 • 2022年3月入社 • 前職:サーバーエンジニア • REALITY: Androidエンジニア • Jetpack Compose / UI / Architecture • Twitter: @pika_sigure クライアントエンジニア / Android 自己紹介 飯尾直樹
4. Part 1 - REALITYの紹介 Part 2 - デザイナーのデザインシステムへの関与 Part 3 - エンジニアのデザインシステムへの関与 Part 4 - まとめ 今日の発表内容の概要 4

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

7. • 昨今のメタバース需要の高まりやコロナ禍以降の生活様式の変 化なども影響し、ユーザー数が年々増加している • それに伴いREALITYアプリの開発チームの人員も増員中 • プロダクトマネージャー • 2019年から2022年で約1.5倍 • プロダクトデザイナー • 2019年から2022年で3倍 • エンジニア • 2019年から2022年で約3倍 REALITYの組織拡大フェーズなどについて
8. デザイナーのデザインシステムへの関与
9. • REALITYアプリリリースから長期間専任のデザイナーが一人という状況が続いていた • 先述の通り組織が拡大している背景もありデザイナーを増員すると共に、 2021年12月に （ようやく！）正式にプロダクトデザインチームとして発足 • 当時のメンバーは • マネージャー/リードデザイナー/デザイナー（専任）/デザイナー（兼任） • ちなみに現在のメンバーは • マネージャー/デザイナー（専任）x2/業務委託 x1.5 プロダクトデザインチーム発足の流れ デザイナーのデザインシステムへの関与
10. デザイナーが少ないことがもたらす悪循環 デザイナーのデザインシステムへの関与 改善意欲の向上 現実の前に敗れる 冒頭に戻る どんどん負債が積み 上がっていくし効率を 上げねば...! とはいえ定常タスクが 多すぎて時間が確保 できない... データ整理とかガイ ドライン定義したら もっと効率上がるの では？
11. 年代別デザインチームの状態と変遷 デザイナーのデザインシステムへの関与 一人だとどうしても 課題特定,解決する 時間がない 2018~2020 エンジニアも増えてる しそろそろ採用頑張ら ないとヤバい！ 2021 2022~現在 採用できて人が増え たからやっと色んな課 題に取り組める！
12. どうやって課題領域と課題の優先度を決めたか
13. UXボードの作成 • UXボードとは • ペパボブログで紹介されていたデザ イン力の可視化ツール • チームとしてはゼロからのスタートだった ため、まずは他社事例を参考にした上で 課題特定を試みた • UXボードに記載された各領域の中でも、 より実際的にUIの制作に関わる領野の改 善を目指すことを決めた • UIデザイン力と効率を上げれば余 裕が生まれやすいと考えたため
14. 当時UIデザインする上で抱えていた課題と悪循環 デザイナーのデザインシステムへの関与 コンポーネントの使 い方がケースバイ ケースすぎる... 新規デザインを 作るたびに無駄 な時間がかか る... デザイン整理す る時間も確保し づらい... 実機とFigma どっちが正しい んだっけ？ Figmaのデザイ ンデータが壊れ ている,紛失して いる... デザインのレ ビューに納得感 がない...
15. デザインシステム導入に至る デザイナーのデザインシステムへの関与 デザインシステムを作 れば今抱えている課 題全部解決で は！？！ デザインシステムを作 れば...勝つ！！
16. ようやくデザインシステムの話
17. デザインシステム導入の際に陥りがちなミス デザイナーのデザインシステムへの関与 デザインシステムは 凄い！完璧なシス テムを作るぞ！ 本格検討以前 やることめちゃく ちゃ多いので は...？ 作業範囲検討 作業開始時点 やることが多すぎる し一人じゃ無理だ... でもこれ以上工数 を割けない...
18. 少人数のチームで完璧なデザインシステムを作ろうとすると 大体破綻するのでまずはスモールスタートが大事！
19. スモールなデザインシステムへの取り組み方 デザイナーのデザインシステムへの関与 インプット 色々な手法も完成度も あるけど弊社の場合ま ずこれだけやれば良 いのでは？ 批判検討 作業開始 まずは勉強会とリ サーチを地道に行っ て正しい知識を身に つけよう 範囲も絞ったし現実的 なスケジュールで進め られそう！
20. 優先度 1. デザインチームのMVV作成 2. トークン化できるスタイルの定義 3. 利用頻度の高いコンポーネントの定 義 4. スタイルのマスターファイルへの反 映 5. スタイルを反映させた実装 6. コンポーネントのマスターファイルへ の反映 7. コンポーネントを反映させた実装 最終的な優先度とやらなかったこと デザイナーのデザインシステムへの関与 20
 やらなかったこと • 利用頻度の低いコンポーネントのシ ステム化 • UXが関与する内容のシステム化 • 定義完了した後、即座に本番へと反 映させていくこと • 網羅性が高すぎるオリジナルのデザ インシステムを参考にすること • ex.ant,Goldman Sachs, etc…
21. 参考にしたデザインシステム
22. • デザイン作成に際して発生する無駄な思考コストを削減できる • 仮にこれまで議論されていなかった定義の曖昧さが浮上してもデザインシステムに組 み込めば良い、という安心感がある • 適切な運用方針が定まっている場合、デザイン的資産が積み上がっていく • コンポーネントやスタイルなどへの理解度が上がる • 要件定義能力や意思決定能力が培われる • UI的な体験の統一性が生まれることによって、 UI以外の観点からUXについて考慮しやす くなる 作り進めた上で改めて感じるデザインシステム制作の意義 デザイナーのデザインシステムへの関与
23. • アプリ開発をする上でデザインを作る、ということは必然的に ENの関与が発生する • よって、定義段階でEN観点からのフィードバックを貰うことが望ましい • また、デザインシステムで定義されたトークンやコンポーネントをどのように管理 /実装す るか、はアプリの実装方針/スタイルに基づくため、ENに早期段階でヒアリングをすること が望ましい • 上記に加えてREALITYではwebやunityも混在するため、どこまでをnative完結にする か、などを相談する必要があった • これらの観点から、専任のENをアサインした上でデザインシステム対応チームを発足さ せた ENとの連携 デザイナーのデザインシステムへの関与
24. エンジニアのデザインシステムへの関与 24

25. エンジニア視点のデザインシステム → UIの開発効率の向上やデザインの統一
26. REALITYはどうなの...?
27. REALITYのUI構成 27

28. • 配信 • 配信視聴 • 配信一覧 • ゲーム • チャット • ガチャ • プロフィール • クローゼット REALITYの主要な画面 28
 視聴画面 ガチャ チャット
29. Unity REALITYのUIの構成 配信画面 クローゼット ワールド ゲーム
30. Native(iOS, Android) REALITYのUIの構成 配信一覧 チャット ガチャ一覧 プロフィール
31. Native & Unity REALITYのUIの構成
32. WebView REALITYのUIの構成 ガチャお知らせ ゲームお知らせ イベントページ
33. REALITYのUI構成 → Native & Unity & Web 33
 Android ロボットは、 Google が作成および提供している作品から複製または変更したものであり、クリエ イティブ・コモンズ表示 3.0 ライセンスに記載された条件に従って使用しています。
34. REALITYのUIの難しさ 34

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

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

37. • Componentを意識した実装になっていなかった • そもそもデザインが意識されていないので難しかった • 部分的にエンジニアが共通化できる部分はしていた • 宣言的UIの実装が難しくなる • Component単位での実装をしたい • 模索しながらの実装になりがち デザイン改修しやすい実装 REALITYのUIの難しさ・課題 37
 デザインが共通化されていない
38. • エンジニアの人数は右肩上がり • 今年初め時点から倍増 • 開発メンバーの増加 • 個人の実装の裁量も増加する • 統一感や品質の担保が難しくなっていく • 開発環境の整備が重要 エンジニア組織の変化 REALITYのUIの難しさ・課題
39. REALITYでのデザインシステム導入の取り組み 39

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

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

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

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

45. • 会議への参加 • 担当するエンジニアのみの参加 • エンジニアとデザイナーで協業して作り上げる • エンジニアがレビューすべき箇所 • 命名や分岐、既存の実装箇所等 • 実装に影響するので、エンジニアがレビューした方が良い デザイナー側との連携 エンジニアの関わり方
46. • 定義の実装 • Taskforceとして工数を持っているので着手しやすい • 担当エンジニアがそのままタスクを持つのがスムーズ • デザインシステムの説明・浸透 • 実装されていても使われていなければ意味がない • メンバーに説明したり、コードベースで浸透させていく • デザインシステム以外の定義の置き換え • 過去の実装についてはDeprecatedにしていく デザイナー側との連携 エンジニアの関わり方
47. まとめ
48. • そもそもPDとENとで異なるデザイン的課題を有しており、かつそれらが話し合われてい ないことが分かった • iOS/Androidでデザイン的に統一しやすい箇所とそうでない箇所の判別が容易になり、 結果機能開発におけるデザイン作成においてデザインを統一すべきかそうでないかの 判断がしやすい • マスターページの管理が楽になる • 既存デザインに対しての定期的な見直しがしやすい 導入の成果 まとめ 48

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

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

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

52. ご清聴ありがとうございました！