うちのデザインシステム.pdf

うちのデザインシステム
NewsPicks Web Engineer / イイダユカコ
2023.6.17@デザインシステムの話☕

01 自己紹介
©NewsPicks Inc. All Rights Reserved.
イイダユカコ
NewsPicks Web エンジニア
経歴
2013年に株式会社サイバーエージェントに入社し、サーバサイドエンジニアを
経て、2015年よりフロントエンドエンジニアとして従事。 2019年9月より株式会
社ニューズピックスにて、 Web フロントエンドをメインに担当。現在はニューズ
ピックスの Web プロダクトに関するリアーキテクチャプロジェクトとリニューアル
プロジェクトに携わる。
推進する中で Observability や Accessibility などの普及を図っています。
気になってくれたら Twitter で @becyn で見てもらえるとうれしいです！
いつものやつ

今日は超オフな感じで喋るから、「
NP として」というより、
「個人の考えとして」っていう文脈強めです、アシカラズ！！！！！！

1. デザインシステムってなんっけ？
2. NewsPicks におけるデザインシステム
a. 期待値＆立ち位置
b. アウトプット＆管理方法
c. 具体的な開発フロー
3. で、デザインシステムやったほうがいいの？
00 本日お話すること

01
デザインシステムってなんっけ？

01 デザインシステムってなんっけ？
一貫したデザインや操作性でウェブサイトやアプリを提供するための仕組み
デジタル庁
デジタル庁のデザインシステムは以下で確認できるよ！
ググってもすぐ出てくる、必読サイト 💪
https://www.digital.go.jp/policies/servicedesign/designsystem/

● 昨今数多くの企業やサービスがデザインシステムづくりを行っている、大デザインシステム時代
● 多くのデザインシステムが公開され、自社のブランディングとして扱われるケースもある 👀
○ イケてる企業にみんな就職したいし、その分野に没頭できるという環境を暗に示せてるしね

● 昨今数多くの企業やサービスがデザインシステムづくりを行っている、大デザインシステム時代
● 多くのデザインシステムが公開され、自社のブランディングとして扱われるケースもある 👀
○ イケてる企業にみんな就職したいし、その分野に没頭できるという環境を暗に示せてるしね
おい、待て！！
かっこいいだけ
かよ！！！！！

落ち着いてくれ、「だけ」じゃないのよ。

● サービス内操作の一貫性向上
○ 限られた component しか使用されなくなるため、自然と操作の種類が絞られる
○ 結果「XX (サービス名) ぽい動き」「XX だとこう動く」を
ユーザーに理解してもらいやすいように、愛着がわく（わかれる）サービスに
01 デザインシステムに何を期待してるん？（サービスにとって）
よく勉強会とかで見る、
UXのハニカム構造をピラミッド図にしたやつ

● サービス内の操作性の一貫性向上
○ 限られた component しか使用されなくなるため、自然と操作の種類が絞られる
○ 結果「XX (サービス名) ぽい動き」「XX だとこう動く」を
ユーザーに理解してもらいやすいように、愛着がわく（わかれる）サービスに
● 「自分たちの色」を自分たちで認識する、意識する、プロダクトに還す
○ 知見やこれまでの判断が積み重なることで、迷ったときの判断材料にもなる
○ DNA を継承し続けることでどんどん「自分たちの色」を濃くすることに繋がる
01 デザインシステムに何を期待してるん？（サービスにとって）

● デザインの作業効率の向上
○ 使い回し前提でデザインするよう意識するのでデザイン量産を抑えられる（工数節約！）
○ 自然と 1 component に対して汎用的に作ろうという意識が働き、
全体で扱う component 数が減る（メンテナンス軽減！）
● 開発の作業効率の向上
○ product 内で使用する component を絞ることで使い回しができるようになる
● 「よくわかんないけど、これ使えば作れる」を仕組み化
○ デザイナーにとってもエンジニアにとっても「わからんが OK」を実現
○ 特にアクセシビリティ等一定理解がむずかしいものを扱う事例も目立つよね
01 デザインシステムに何を期待してるん？（現場にとって）

そして、デザインシステムに求めているものも多種多様！

● 会社やチームによって、デザインシステムに求めることは違っているし、アウトプットも違う
○ 例えば、
■ プロダクトのデザインの統一感を見せたい
■ 自社のブランドを表現したい
■ デザイン工数、開発工数を下げたい
■ 全体のデザインに関する仕様を一覧して理解を深めたい
■ 新しく入ったメンバーへのオンボーディング資料としたい
● これらを解決するため「デザインシステム」になったり、ならなかったりする
○ それは会社やチームの判断によるとしか言えないし、正解はないところ
01 デザインシステムに何を期待してるん？（多種多様編）

書籍『ちいさくはじめるデザインシステム』
● 日本でデザインシステムに力を入れている
名だたる Web 企業のアンケート調査がまとまってる
○ SmartHR、CyberAgent、freee、デジタル庁、Ubie、など
● 一回の飲み会代より安い値段 (¥2,860) でここまでまとまってて、
最後の章だけで、まじでペイする。飲み代浮いた。
● 答えは一つじゃないと教えてくれる、
始める前に読みたい、まじで推薦できる指南書な一冊
https://amzn.asia/d/ixLqzvW

書籍『ちいさくはじめるデザインシステム』
● ちなみにこの本で取り扱ってる「デザインシステム」は、
ロゴ、文章、印刷ガイドライン、イラストレーションなど
Web におけるデザインシステムから更に一歩踏み込んだ内容に
なっているので、そちらも気になる方には是非お手にとってみて！
https://amzn.asia/d/ixLqzvW

ちょっと悪い気しない印象になってきたハズ？
（でも、まだピンとこないなーが本音だよね）

ここまではザックリ概要！具体例を紹介するよー！

02
デザインシステム
NewsPicks における

● 2013年9月
○ NewsPicks（サービス）サービス提供を開始、翌年2014年6月より Web サービスの提供を開始
2019年9月私、入社。当時は、NewsPicks ではない新規プロジェクトに配属
● 2021年7月
○ NewsPicks のややレガシーな技術スタックを見た上で、技術刷新を提案し、
ついに Web Product を page 毎に技術刷新開始（リアーキテクチャ Project）🎉
● 2022年
○ 上記の流れにデザイナーチームが乗ってくれて、デザイン刷新も推進（リニューアル Project）が始動 🎉
○ この流れで「デザインシステム project」が同時始動 🎉
02 NewsPicks におけるデザインシステム（誕生秘話）

デザインシステムのきっかけになった「リニューアル Project」ってなに？
● 既存の機能を据え置きに、全体デザインがガッツリ変わる（作り直しのイメージに近い）
○ エンジニアもデザイナーも超ヘビーな作業。超覚悟必要。ものによっては 5年計画。
● リニューアルを page 毎に進めていく中で、定義していく component も整理
● すべてのページをリニューアルする前提だったので、全ページに適応すべく、
デザイントークンを見直し、デザインシステムまで昇華させ、育てていくことに！
> 2022年より、並行して page 毎のデザイン刷新も推進（リニューアル Project）
02 NewsPicks におけるデザインシステム（誕生秘話）

02.a
期待値＆立ち位置

02.a
● デザイン工数の低減、開発工数の低減
○ 全体工数を下げ、素早く技術刷新＆デザインリニューアルを完了させたい
○ デザイン知識の継承をデザイナー、エンジニア、両方に残していきたい
● Web におけるアクセシビリティを向上
○ ある程度知識がないと難しいアクセシビリティの知識を包括したデザインシステム上の component を使うだけで開
発に関わる全てのメンバーがアクセシブルな実装を可能にできる
● Unit 外開発メンバーが Web 開発に参加する時の心理的ハードルを低減
○ NewsPicks の開発組織の構造上、開発者は普段 Web フロントエンドを触ってる人に限らない
■ いわゆるフルスタックエンジニア組織
○ ドキュメントの充実、ある程度「これ使えば OK」っていうのを用意したかった
NewsPicks における期待値

● 少なくとも、Web のリニューアル＆技術刷新が終わるまで＆
今の組織構造が変わる（ Web の開発が特定の Unit に限定する）まではデザインシステムを
育て続ける意義があると考えられる
● そのため、開発を進めていく中で、通常の page 開発だけでなく、
○ デザインシステムドキュメントの更新
○ デザインシステムドキュメントに沿った component 実装の追加実装
などを行いながら、じっくり育てていく必要がある
02.a NewsPicks における立ち位置
以上のことから、「デザインシステムを始めると、それ以降のデザイン /開発更新時の毎度、
デザインシステム側のメンテナンスが必要化かチェックする必要がある」といえる

02.b
アウトプット＆管理方法

● 3つの資料に分けて管理
○ 資料に応じて、メインの管理者（メンテナー）が違っている
○ それぞれに対してお互いに声を掛け合ってメンテナンスを促している状態（持ちつ持たれつ）
02.b NewsPicks における、アウトプット＆管理方法
Web アクセシビリティガイドライン
デザインシステムドキュメント component 集
エンジニア管轄
（本当はもっと広めたい）
デザイナー管轄エンジニア管轄
どういった概念かを定義 👈の概念をどう実装し使用できるかを提示 👈の中の特定分野で何に気をつけているか説明

● 全ての component デザインシステム化されているわけではない
○ 現在は、サイト横断で使用されるもの、積極的に意識してデザインに組み込みたいものが対象
■ 例: News を表示する component 、サイト全体で使用されるボタン component
02.b NewsPicks における、アウトプット＆管理方法
そろそろイメージわかせたいと思うので、ちょっとだけ画面共有するね 🤫

02.c
具体的な開発フロー

02.c NewsPicks における、具体的な開発フロー
ある日の開発風景
デザイナーエンジニア

デザイナー
デザインできました！
おけ！レビューしまーす！
これ、デザインシステムで定義された
この component 使えないですかね？
デザイナーチームこれ、デザインシステムで定義された
この component を調整した形でいけない？
デザインシステムドキュメント側も
一緒に更新しときます！
デザイナー

ありがとうございますー！
エンジニア
デザイナー
デザインできました！仕様共有します！
デザイナー
今回の仕様でデザインシステム
ドキュメント側も更新しました！
実装の際にcomponent 集も
更新お願いします！
承知の助！
エンジニア

あ、これ、デザインシステム側の
この component で代えてもいいですか？
エンジニア
デザイナー
デザイナー
あー、たしかに工夫できそうですね。
これでいきましょう！
新しい見せ方だと思うのでドキュメント更新
しておきますねー！
承知の助！component 集も更新する！
エンジニア

あ、これ、アクセシビリティ的にちょっと
工夫したほうが良いかも！
エンジニア
デザイナー
デザイナー
あー、たしかに。
背景色を調整して…うん、良さそうです！
これ、他でも使うと思うので、
デザインシステムで管理したいです！
承知の助！
component 集側にも新しく追加します！
エンジニア

デザイナーエンジニア

03
デザインシステム
やったほうがいいの？
で、結局のところ、

05 デザインシステムやったほうがいいの？
● GOOD
○ ドキュメントを普段から整理しようという気持ちになり、仕様書の健全化に繋がっている
○ うちは組織構造上相性がよく、オンボーディング資料にもなりいい感じ
● MORE
○ それでもやっぱり忙しい時は更新作業の手が止まっちゃう！
■ タスク優先度の見直し、管理工数も考えないと事故る

05
● 組織でも、チームでも多種多様、サービスの数だけデザインシステムの形は違う
○ まずは、デザインシステムに何を期待しているのかチームや組織で話し合おう
○ 「何を解決したいか」に向き合って、デザインシステムが有効そうならやってもいいかも
● 解決方法が沢山ある中で、なぜデザインシステムなのかを人に話せるか
○ プロダクト全体の仕様策定/デザイン/開発効率が上がったり、
チームの誰かが救われる未来があるならやってもいいかも！
○ ちょっとキツそうな例
■ かっこいいしイケてる企業風だから、運用経験を経歴書に書きたいから
● 運用できる組織構造や周囲の理解があることが大前提
○ 作ったけど「（メンテ大変すぎて）作って終わった」になりがち（実際に見た）
○ 「あいつら作りたいから作ってるだけ」となるとキツイ（実際に見た）
デザインシステムやったほうがいいの？
サービスや組織課題に
向き合うのじゃ…
絶対に、じゃ…

00
まとめ

● デザインシステムについて、事例を交えながらざっくりお伝えしました！
○ 実践的な話（どこから始めたらいい？等）はまた別の機会に！
■ それはそれで話したいことが沢山ある！！笑
○ これも一例でしかないので偏りはありますが
…（なので、そのつもりで持ち帰ってくださいｗ）
○ 今後いろんなデザインシステムを見かける際
「このデザインシステムは何に特化したデザインシステムだ？」等
面白がる機会に繋がればうれしいです！
● デザインシステムする /しないも論点ではあるが、
一番大事なのはプロダクトや組織課題と向き合うこと
○ 向き合った結果のアウトプットがデザインシステムになったりならなかったりしてるだけ
● デザインシステムをやるなら、相当な覚悟が必要
○ （だと思ってる）
○ デザインシステム始めたら、見せあいっ子しましょ！！
00 本日のまとめ

06
Q&A Time
以上！聴いてくれてありがとー！

最初からガチガチではなく、ゆっくりプロダクトを作りながら成長させていくイメージが近い
個人の感想です！
途中デザインも仕様も変わるし、最初にガチッとは難しそう。
デザインシステムとプロダクトを一緒に成長させていくイメージ。
（なので、プロダクトが成長する限り、デザインシステムも成長するのです
…終わりのない戦いのようにも感じる
…！！笑）
Q. 最初からガチガチに作るとデザインやりにくすぎるし
結局途中で変えるとこ多いけど、みんなどうゆう順序でやってるのか気になる
ともや氏

Q. デザインする前からデザインシステム作らんよね？そんなことできんよね？
ともや氏
ある程度どんな layout/component が必要かわかってないと厳しそう
一気につくるというより、プロダクトと一緒に成長させる方が手戻りも少なくいいと思う
実際にプロダクトに反映した時に無理のないシステムになってるかどうか確認しながら作ったほうが
よりプロダクトにフィットしたデザインシステムになるんじゃないかと思う！
（すげえ敏腕デザイナーとかだったら違うんかな？ｗ
いずれにせよ神業だと思うｗ）

Q. デザインシステムとデザインルールの違いの説明からあっても良いかと思ったりしました 󰢦
ごとうみな
デザインルールは「白って 200色あんねん」を防止する方法
デザインガイドラインは「この白を使う理由」を説明する場所
デザインシステムは「この白ってあのサービスの白だよね！」と思わせる方法
ちなみに、デザインシステムの中に「デザイントークン」と呼ばれるものもあり、
ルールをシステムに組み込んだ形だと個人的には思ってる！
アンミカ様の画像をここに貼ってましたが
アップロード用にいらすとやのお姉さんに
代理で出てもらってます（跡地）

● 「デザインルール」に留める
● 「デザインシステムと呼ばれる XX の部分だけ取り入れる」
など色々ある気がする
結局デザインシステムをやる
/やらないって「プロダクトをどう管理していくかの設計」なので、
それに合ったやりかたをしていくのがいいのかなって思う！
Q. これ系でデザインシステム以外の対応方法って具体的にどんなのがあるん？

うちのデザインシステム.pdf

Recommended

Recommended

More Related Content

Similar to うちのデザインシステム.pdf

Similar to うちのデザインシステム.pdf (20)

うちのデザインシステム.pdf