Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

gree_tech
PRO

October 25, 2022
Tweet

More Decks by gree_tech

Other Decks in Technology

Transcript

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

    View Slide

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


    View Slide

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

    View Slide

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


    View Slide

  5. REALITYの紹介

    View Slide

  6. • REALITYはREALITY社が運営するモバイルアプリ
    • “なりたい自分で、生きていく”をミッションに、営為開発中
    REALITYというアプリについての概要
    REALITYについて
    6

    アバター
 ライブ配信

    コミュニケーション
 ゲーム

    ワールド


    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  20. 優先度
    1. デザインチームのMVV作成
    2. トークン化できるスタイルの定義
    3. 利用頻度の高いコンポーネントの定

    4. スタイルのマスターファイルへの反

    5. スタイルを反映させた実装
    6. コンポーネントのマスターファイルへ
    の反映
    7. コンポーネントを反映させた実装
    最終的な優先度とやらなかったこと
    デザイナーのデザインシステムへの関与
    20

    やらなかったこと
    • 利用頻度の低いコンポーネントのシ
    ステム化
    • UXが関与する内容のシステム化
    • 定義完了した後、即座に本番へと反
    映させていくこと
    • 網羅性が高すぎるオリジナルのデザ
    インシステムを参考にすること
    • ex.ant,Goldman Sachs,
    etc…

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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


    View Slide

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

    View Slide

  26. REALITYはどうなの...?

    View Slide

  27. REALITYのUI構成
    27


    View Slide

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

    視聴画面 ガチャ チャット

    View Slide

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

    View Slide

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

    View Slide

  31. Native & Unity
    REALITYのUIの構成

    View Slide

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

    View Slide

  33. REALITYのUI構成
    → Native & Unity & Web
    33

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

    View Slide

  34. REALITYのUIの難しさ
    34


    View Slide

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


    View Slide

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


    View Slide

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

    デザインが共通化されていない

    View Slide

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

    View Slide

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


    View Slide

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

    View Slide

  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


    View Slide

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


    View Slide

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


    View Slide

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


    View Slide

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

    View Slide

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

    View Slide

  47. まとめ

    View Slide

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


    View Slide

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


    View Slide

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


    View Slide

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


    View Slide

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

    View Slide

  53. 53


    View Slide