GREE Tech Conference 2022で発表された資料です。 https://techcon.gree.jp/2022/session/TrackC-5
REALITY株式会社 プロダクトデザイナー 吉田 明史REALITYにおけるデザインシステムの導入REALITY株式会社 Androidエンジニア 飯尾 直樹
View Slide
• 2019年にグリー株式会社/REALITY株式会社に新卒として入社• 入社時の役職はプロダクトマネージャー• 2021年12月からはプロダクトデザインチームに配属• 新機能開発におけるUI/UXの設計と並行してデザインシステムなどのタスクも行う• 好きな音楽はエクスペリメンタル・ヒップホッププロダクトデザイナー自己紹介 吉田明史2
• REALITY株式会社• 2022年3月入社• 前職:サーバーエンジニア• REALITY: Androidエンジニア• Jetpack Compose / UI / Architecture• Twitter: @pika_sigureクライアントエンジニア / Android自己紹介 飯尾直樹
Part 1 - REALITYの紹介Part 2 - デザイナーのデザインシステムへの関与Part 3 - エンジニアのデザインシステムへの関与Part 4 - まとめ今日の発表内容の概要4
REALITYの紹介
• REALITYはREALITY社が運営するモバイルアプリ• “なりたい自分で、生きていく”をミッションに、営為開発中REALITYというアプリについての概要REALITYについて6 アバター ライブ配信 コミュニケーション ゲーム ワールド
• 昨今のメタバース需要の高まりやコロナ禍以降の生活様式の変化なども影響し、ユーザー数が年々増加している• それに伴いREALITYアプリの開発チームの人員も増員中• プロダクトマネージャー• 2019年から2022年で約1.5倍• プロダクトデザイナー• 2019年から2022年で3倍• エンジニア• 2019年から2022年で約3倍REALITYの組織拡大フェーズなどについて
デザイナーのデザインシステムへの関与
• REALITYアプリリリースから長期間専任のデザイナーが一人という状況が続いていた• 先述の通り組織が拡大している背景もありデザイナーを増員すると共に、2021年12月に（ようやく！）正式にプロダクトデザインチームとして発足• 当時のメンバーは• マネージャー/リードデザイナー/デザイナー（専任）/デザイナー（兼任）• ちなみに現在のメンバーは• マネージャー/デザイナー（専任）x2/業務委託 x1.5プロダクトデザインチーム発足の流れデザイナーのデザインシステムへの関与
デザイナーが少ないことがもたらす悪循環デザイナーのデザインシステムへの関与改善意欲の向上 現実の前に敗れる 冒頭に戻るどんどん負債が積み上がっていくし効率を上げねば...!とはいえ定常タスクが多すぎて時間が確保できない...データ整理とかガイドライン定義したらもっと効率上がるのでは？
年代別デザインチームの状態と変遷デザイナーのデザインシステムへの関与一人だとどうしても課題特定,解決する時間がない2018~2020エンジニアも増えてるしそろそろ採用頑張らないとヤバい！2021 2022~現在採用できて人が増えたからやっと色んな課題に取り組める！
どうやって課題領域と課題の優先度を決めたか
UXボードの作成• UXボードとは• ペパボブログで紹介されていたデザイン力の可視化ツール• チームとしてはゼロからのスタートだったため、まずは他社事例を参考にした上で課題特定を試みた• UXボードに記載された各領域の中でも、より実際的にUIの制作に関わる領野の改善を目指すことを決めた• UIデザイン力と効率を上げれば余裕が生まれやすいと考えたため
当時UIデザインする上で抱えていた課題と悪循環デザイナーのデザインシステムへの関与コンポーネントの使い方がケースバイケースすぎる... 新規デザインを作るたびに無駄な時間がかかる...デザイン整理する時間も確保しづらい...実機とFigmaどっちが正しいんだっけ？Figmaのデザインデータが壊れている,紛失している...デザインのレビューに納得感がない...
デザインシステム導入に至るデザイナーのデザインシステムへの関与デザインシステムを作れば今抱えている課題全部解決では！？！デザインシステムを作れば...勝つ！！
ようやくデザインシステムの話
デザインシステム導入の際に陥りがちなミスデザイナーのデザインシステムへの関与デザインシステムは凄い！完璧なシステムを作るぞ！本格検討以前やることめちゃくちゃ多いのでは...？作業範囲検討 作業開始時点やることが多すぎるし一人じゃ無理だ...でもこれ以上工数を割けない...
少人数のチームで完璧なデザインシステムを作ろうとすると大体破綻するのでまずはスモールスタートが大事！
スモールなデザインシステムへの取り組み方デザイナーのデザインシステムへの関与インプット色々な手法も完成度もあるけど弊社の場合まずこれだけやれば良いのでは？批判検討 作業開始まずは勉強会とリサーチを地道に行って正しい知識を身につけよう範囲も絞ったし現実的なスケジュールで進められそう！
優先度1. デザインチームのMVV作成2. トークン化できるスタイルの定義3. 利用頻度の高いコンポーネントの定義4. スタイルのマスターファイルへの反映5. スタイルを反映させた実装6. コンポーネントのマスターファイルへの反映7. コンポーネントを反映させた実装最終的な優先度とやらなかったことデザイナーのデザインシステムへの関与20 やらなかったこと• 利用頻度の低いコンポーネントのシステム化• UXが関与する内容のシステム化• 定義完了した後、即座に本番へと反映させていくこと• 網羅性が高すぎるオリジナルのデザインシステムを参考にすること• ex.ant,Goldman Sachs,etc…
参考にしたデザインシステム
• デザイン作成に際して発生する無駄な思考コストを削減できる• 仮にこれまで議論されていなかった定義の曖昧さが浮上してもデザインシステムに組み込めば良い、という安心感がある• 適切な運用方針が定まっている場合、デザイン的資産が積み上がっていく• コンポーネントやスタイルなどへの理解度が上がる• 要件定義能力や意思決定能力が培われる• UI的な体験の統一性が生まれることによって、UI以外の観点からUXについて考慮しやすくなる作り進めた上で改めて感じるデザインシステム制作の意義デザイナーのデザインシステムへの関与
• アプリ開発をする上でデザインを作る、ということは必然的にENの関与が発生する• よって、定義段階でEN観点からのフィードバックを貰うことが望ましい• また、デザインシステムで定義されたトークンやコンポーネントをどのように管理/実装するか、はアプリの実装方針/スタイルに基づくため、ENに早期段階でヒアリングをすることが望ましい• 上記に加えてREALITYではwebやunityも混在するため、どこまでをnative完結にするか、などを相談する必要があった• これらの観点から、専任のENをアサインした上でデザインシステム対応チームを発足させたENとの連携デザイナーのデザインシステムへの関与
エンジニアのデザインシステムへの関与24
エンジニア視点のデザインシステム→ UIの開発効率の向上やデザインの統一
REALITYはどうなの...?
REALITYのUI構成27
• 配信• 配信視聴• 配信一覧• ゲーム• チャット• ガチャ• プロフィール• クローゼットREALITYの主要な画面28 視聴画面 ガチャ チャット
UnityREALITYのUIの構成配信画面 クローゼット ワールド ゲーム
Native(iOS, Android)REALITYのUIの構成配信一覧 チャット ガチャ一覧 プロフィール
Native & UnityREALITYのUIの構成
WebViewREALITYのUIの構成ガチャお知らせ ゲームお知らせ イベントページ
REALITYのUI構成→ Native & Unity & Web33 Android ロボットは、 Google が作成および提供している作品から複製または変更したものであり、クリエイティブ・コモンズ表示 3.0 ライセンスに記載された条件に従って使用しています。
REALITYのUIの難しさ34
• Native(iOS, Android) + Unity + Web• デザインの統一が難しい• 開発自体も複雑• デザインの整備が進んでいる訳ではなかった• 機能開発との優先度• 整備や改修への工数の不足• 開発組織の拡大REALITYのUIの難しさ・課題35
• 既存デザインの改修は優先度が低め• 直接的なビジネス的価値は高くなりにくい• 新規機能開発の方が重要性は高くなりがち• バグ対応 / リファクタリングも必要• UIの改善としても部分的になるケースが多い• コンポーネント単位の改修• ページ全体の改修は難しい• 結局はいたちごっこになりがち• 開発効率自体をあげたいデザイン改修に対する優先度REALITYのUIの難しさ・課題36
• Componentを意識した実装になっていなかった• そもそもデザインが意識されていないので難しかった• 部分的にエンジニアが共通化できる部分はしていた• 宣言的UIの実装が難しくなる• Component単位での実装をしたい• 模索しながらの実装になりがちデザイン改修しやすい実装REALITYのUIの難しさ・課題37 デザインが共通化されていない
• エンジニアの人数は右肩上がり• 今年初め時点から倍増• 開発メンバーの増加• 個人の実装の裁量も増加する• 統一感や品質の担保が難しくなっていく• 開発環境の整備が重要エンジニア組織の変化REALITYのUIの難しさ・課題
REALITYでのデザインシステム導入の取り組み39
• 通常の施策機能開発とは別線のプロジェクト• 中長期的な活動で一定の工数が必要• 一定の工数をTaskforceに優先できるようにする• REALITYでは15%• 明確なルールとすることで腰を据えて取り組める• デザインシステムへの取り組みをしやすくエンジニア目線のデザイン的課題についてTaskforce
• FigmaExport• https://github.com/RedMadRobot/figma-export• Figma上のデザインデータを自動的に出力する• icon, image• Component単位で画像の書き出しを実行する• デザインシステム上の画像リソースを自動エクスポートする• https://speakerdeck.com/yutoyazaki/automate-image-export-from-figma-to-ios-and-android-using-figma-exportエンジニア目線のデザイン的課題についてリソース出力の自動化41
• REALITYでは積極的に宣言的UIを導入中• 今年から本格的に進行中• Native• Jetpack Compose• SwiftUI• メリット• モダンかつ話題な技術• コード量の削減• 再利用性の向上• デザインシステムと相性が良いエンジニア目線のデザイン的課題について宣言的UIの導入42
• UIを実装するエンジニアはデザインシステムを使える状態に• デザインシステム自体の一定の理解• Figmaからデザインシステムの定義を読み取れる• 定義されたデザインシステムの実装を利用できるデザインシステムを使える環境の整備デザインシステムが使える環境43
• エンジニア全員が定義の部分から関わる必要はない• REALITYでは各クライアントからメイン担当が一人• Android / iOS / Web / Unity• 担当のエンジニア• 会議への参加• デザインに対するレビュー• 定義の実装• メンバーへの説明・浸透デザインシステムを使える環境の整備エンジニアの関わり方44
• 会議への参加• 担当するエンジニアのみの参加• エンジニアとデザイナーで協業して作り上げる• エンジニアがレビューすべき箇所• 命名や分岐、既存の実装箇所等• 実装に影響するので、エンジニアがレビューした方が良いデザイナー側との連携エンジニアの関わり方
• 定義の実装• Taskforceとして工数を持っているので着手しやすい• 担当エンジニアがそのままタスクを持つのがスムーズ• デザインシステムの説明・浸透• 実装されていても使われていなければ意味がない• メンバーに説明したり、コードベースで浸透させていく• デザインシステム以外の定義の置き換え• 過去の実装についてはDeprecatedにしていくデザイナー側との連携エンジニアの関わり方
まとめ
• そもそもPDとENとで異なるデザイン的課題を有しており、かつそれらが話し合われていないことが分かった• iOS/Androidでデザイン的に統一しやすい箇所とそうでない箇所の判別が容易になり、結果機能開発におけるデザイン作成においてデザインを統一すべきかそうでないかの判断がしやすい• マスターページの管理が楽になる• 既存デザインに対しての定期的な見直しがしやすい導入の成果まとめ48
• いかにコストカットしながら進めていくか• デザインシステムがあれば楽になるだろう、という側面は多々あることは理解しつつも、デザインシステムを構築するのは大変すぎる気配があるため着手できないケースや、そもそもの定常業務が忙しすぎてそれどころではない、みたいなケースは頻繁にありそう• 作業範囲を削りつつ、一歩目を定める必要がある• デザインシステムを推し進める担当者は、それがいかに大事であるかを周囲に伝えると共に、作業時間を確保できるように相談することが大事• ENとの連携や開発チームへの浸透作業• 意思決定者を明確に定めること進める上での課題まとめ49
• 新規メンバー中心に作り進められたこと• 2019年末から2022年初頭に入ったメンバーを中心にデザインシステムチームを組成し、各人がオーナーシップを持って取り組めたこと• デザインシステムを作ることが目的になりすぎず、あくまで課題ベースでデザインシステムの要素を抽出して作り進められたこと• 作り進める中で見つかった課題をちゃんと定例で話し合った上で軌道修正し、最適手段を模索できたこと• 担当メンバーに放り投げ、みたいにならずマネージャーレイヤーのメンバーも定例に参加し議論ができていたREALITY社におけるよかったポイントまとめ50
REALITY社は現在絶賛採用中です！• Meetyでのカジュアル面談• スカウト待ち登録• 月一のREALITY Meetup• 知り合いの社員がいる場合参加可能• Wantedlyからの応募など様々な形で採用をしておりますのでお気軽に面談/応募してみてください！採用まとめ51
ご清聴ありがとうございました！
53
gree_tech
brainpadpr
hacomono
sadonosake
elcuervo
shinrinakamura
tk3fftk
devopstaiwan
mitsuakitohei
yoshiitaka
herumi
gaelvaroquaux
non97
dotmariusz
addyosmani
3n
searls
holman
hatefulcrawdad
samlambert
zenorocha
geeforr
cromwellryan
productmarketing
danielanewman