Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
複数サービスを運用するコンポーネント設計/Component design to operat...
Search
haraguchi
July 04, 2019
Technology
1
6.4k
複数サービスを運用するコンポーネント設計/Component design to operate multiple services
haraguchi
July 04, 2019
Tweet
Share
More Decks by haraguchi
See All by haraguchi
2019年のAtomicDesignコンポーネント設計/Atomic Design Component Design 2019
haraguchi
1
1.5k
Other Decks in Technology
See All in Technology
Autonomous Database - Dedicated 技術詳細 / adb-d_technical_detail_jp
oracle4engineer
PRO
4
10k
品質視点から考える組織デザイン/Organizational Design from Quality
mii3king
0
150
ZOZOマッチのアーキテクチャと技術構成
zozotech
PRO
3
1.4k
今!ソフトウェアエンジニアがハードウェアに手を出すには
mackee
11
4.5k
共有と分離 - Compose Multiplatform "本番導入" の設計指針
error96num
1
270
生成AIでセキュリティ運用を効率化する話
sakaitakeshi
0
390
DevIO2025_継続的なサービス開発のための技術的意思決定のポイント / how-to-tech-decision-makaing-devio2025
nologyance
1
350
「どこから読む?」コードとカルチャーに最速で馴染むための実践ガイド
zozotech
PRO
0
170
エラーとアクセシビリティ
schktjm
1
1.2k
250905 大吉祥寺.pm 2025 前夜祭 「プログラミングに出会って20年、『今』が1番楽しい」
msykd
PRO
1
590
なぜスクラムはこうなったのか?歴史が教えてくれたこと/Shall we explore the roots of Scrum
sanogemaru
5
1.5k
Kubernetes における cgroup v2 でのOut-Of-Memory 問題の解決
pfn
PRO
0
470
Featured
See All Featured
Optimising Largest Contentful Paint
csswizardry
37
3.4k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Docker and Python
trallard
45
3.5k
The World Runs on Bad Software
bkeepers
PRO
70
11k
Rails Girls Zürich Keynote
gr2m
95
14k
Designing for Performance
lara
610
69k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
840
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
jQuery: Nuts, Bolts and Bling
dougneiner
64
7.9k
Transcript
複数サービスを運用するコンポーネント設計 2019年7月4日 原口渉 SPACEMARKET Tech Meetup #2
2 自己紹介 原口渉 フロントエンドエンジニア styled-componentsでReactコンポーネントの設計・運用担当
3 今日話すこと
4 今日話すこと 1. スペースマーケットのフロントエンドのリポジトリ構成 2. サービス共通コンポーネント ・ 課題 ・ どのように解決したか 3. コンポーネント管理・運用について
4. まとめ
5 スペースマーケットのフロントエンドのリポジトリ構成
6 スペースマーケットのフロントエンドのリポジトリ構成 SPACEMARKET SPACEMARKET DASHBOARD SPACEMARKET EVENT SPACEMARKET BUSINESS SPACEMARKET
ACCOUNT フロントエンド共通リポジトリ サービス共通コンポーネントリポジトリ 1サービス1リポジトリ、プラスしてサービス共通リポジトリ 2つという構成です
7 スペースマーケットのフロントエンドのリポジトリ構成 SPACEMARKET SPACEMARKET DASHBOARD SPACEMARKET EVENT SPACEMARKET BUSINESS SPACEMARKET
ACCOUNT フロントエンド共通リポジトリ サービス共通コンポーネントリポジトリ 1サービス1リポジトリ、プラスしてサービス共通リポジトリ 2つという構成です 今日はこのリポジトリについてお話します
8 サービス共通コンポーネント
9 サービス共通コンポーネント • スペースマーケットの各サービスで使われている共通コンポーネント • 元々サービス共通コンポーネントというものはなく、各リポジトリにそれぞれコンポーネントがあった • いくつかの課題があった サービス共通コンポーネントとは
10 課題
11 課題 • 例えばボタンコンポーネントに修正が発生した場合に、全てのリポジトリにあるボタンコンポーネン トを修正しないといけなかった • 取り残されるリポジトリが出てきてしまった • そのためサービスによって同じボタンでも見た目に差が出てしまっていた 1.
コンポーネントの更新が手間だった
12 課題 • コンポーネントの粒度に関しての指針が明文化されていなかった • 各リポジトリを担当するエンジニアのそれぞれの思想で決めていたため、コンポーネント粒度がば らつきがあった • また課題1,2であげている理由から、再利用性に欠けており、メンテナンスもしづらかった 2.
コンポーネント粒度にばらつきが出てしまった
13 どのように解決したか
14 どのように解決したか • 1つのリポジトリからコンポーネントを読み込む形にした • コンポーネントを修正する時は 1つのリポジトリで完結するように 1. コンポーネントの更新が手間だった
15 どのように解決したか • サービスごとにコンポーネントを作成する必要がなくなり、作業時間と手間が大幅に減った • リポジトリ間のデザインや機能の差がなくなり、統一性を持たせることができた 結果
16 どのように解決したか • 粒度の統一性と汎用性を持たせて、再利用しやすいコンポーネントを作りたかった • デザイナーの粒度を参考に設計することに • デザイナーの粒度の思想に一番適していたデザインシステムの Atomic Designを採用
2. コンポーネント粒度にばらつきが出てしまった
17 Atomic Design
18 Atomic Design • Atomic Design はデザインシステムを作るための手段 • UIコンポーネントの粒度を、パーツやコンポーネント単位で定義していくもの
Atomic Designとは
19 Atomic Design • 最小単位で単一のコンポーネント • 最小単位のコンポーネントなので、多くのページで使われることが多い。 ◦
Button ◦ Icon ◦ Checkboxなど Atoms
20 Atomic Design • Atomsの組み合わせで作られるコンポーネント • 使い回すことを考え、汎用的に作る Molecules
21 Atomic Design • Atoms,Moleculesの組み合わせで作られるコンポーネント • 汎用性は考えない。 •
単独で成り立つことのできるコンポーネント Organisms
22 Atomic Design • コンポーネントのテンプレートとなるコンポーネント • 中身は入れずレイアウトを構成する Templates
23 Atomic Design • その名の通りページ全体のコンポーネント Pages
24 Atomic Design • 粒度の統一性を持たせることができた • 再利用のしやすいコンポーネントができた • エンジニアとデザイナー間で共通言語で話せるようになり、 ◦
「ここはAtomsで定義しちゃっていいよね?」 ◦ 「これはMolecules?Organisms?」など といったように、コミュニケーションがスムーズになった 結果
25 コンポーネント管理・運用について
26 コンポーネント管理・運用について • サービス共通コンポーネントの見た目は、 Storybookで確認しています
27 Storybook
28 Storybook • コンポーネントのUIを一覧で確認することのできるツール • スペースマーケットでマークアップを行う人はこのツールで、コンポーネント確認しながら作業しま す Storybookとは
29 Storybook
30 Storybook コンポーネントリスト コンポーネントのデザイン
31 Storybook サイズの異なるコンポーネントを確認することができる
32 Storybook テーマごとに分けられたカラーが反映されたコンポーネントを見比べることも可能
33 Storybook Storybookについてはブログに詳しく載っています! Atomic Designを使ってReactコンポーネントを再設計した話 Storybookの便利なaddon機能のご紹介
34 コンポーネント管理・運用について • このようにサービス共通コンポーネントを作成したことで、先程お話ししたように更新の手間が省け たり、Atomic Designの導入により、コンポーネントに統一性を持たせることができるようになった • この運用方法でサービス共通コンポーネントリポジトリには、日々コンポーネントが追加されている
35 コンポーネント管理・運用について • 現在スペースマーケットの frontend_component(master)にあるコンポーネントの数 ◦ Atoms: 47 ◦ Molecules:
92 ◦ Organisms: 70 ◦ Templates: 8 ◦ Pages: 29 合計 246!!! • 全てを自力で把握するのは難しい • 新しいコンポーネントを把握しているのが、担当デザイナー、エンジニア、レビュワーだけ • 同じコンポーネントを作ってしまうという可能性もある 把握していないコンポーネントが増えた
36 コンポーネント管理・運用について • 今あるコンポーネントを全て洗い出して把握するのは手間も時間もかかるため、新規のコンポーネ ントから把握することに • それなら担当のデザイナーとエンジニアに共有してもらうことに 把握していないコンポーネントが増えた
37 コンポーネント運用について • 週に1度、エンジニアとデザイナーでミーティングを行っています • そこで自分の担当している新規・追加のコンポーネントについて共有を行う どのように行っているか
38 コンポーネント運用について
39 コンポーネント運用について デザインが確定した 新規コンポーネント
40 コンポーネント運用について デザインが確定した 新規コンポーネント → Atoms列(作業中)
41 コンポーネント運用について デザインが確定した 新規コンポーネント → Atoms列(作業中) コンポーネント化が完 了したら「完了」列に 移動 →
42 コンポーネント運用について • 1番の目的であった新規・追加コンポーネントの把握ができるようになった • 既存コンポーネントの中で自分が把握していなかったコンポーネントを把握できた ◦ 現在開発しているページのコンポーネントを共通化できることがわかった まだ始めたばかりですが、今のところいい感じに運用できていると感じています よかったこと
43 まとめ コンポーネントを共通化とAtomic Designの導入により • 全体的に統一性を持ったコンポーネント設計ができるようになった • サービス間をまたいでいても、同じデザインのコンポーネントを使えるようになった • コンポーネントの更新の手間が減った
• コンポーネントの数が増え、管理が大変になった ◦ スペースマーケットでは、関係者で集まり共有を行うことでこの課題を解決していま す
None