---
title: Yahoo!ニュースでAtomicDesignに取り組んだ話 #ヤフー名古屋
tags:  #ヤフー名古屋  
author: [Yahoo!デベロッパーネットワーク](https://www.docswell.com/user/ydnjp)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/V4EQ91QXEP.jpg?width=480
description: 2019年8月6日に開催されたヤフー名古屋Tech Meetup #3の内容です。  #3 は「Webフロントエンドを支えるノウハウ」をテーマに開催しました。
published: August 09, 19
canonical: https://www.docswell.com/s/ydnjp/ZRMRJK-2019-08-09-151855
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/V4EQ91QXEP.jpg)

Yahoo!ニュースで
Atomic Designに取り組んだ話
ヤフー名古屋 TechMeetup #3 / 2019.08.06
Reiko Kayama


# Page. 2

![Page Image](https://bcdn.docswell.com/page/DKJ4XRN2J1.jpg)

鹿山 玲子 Kayama Reiko
ヤフー株式会社 デザイナー
•
•
2016年にヤフー株式会社に新卒入社
•
今日お話しする案件に携わったのは2019年以降なのでわりと最近
Yahoo!ニュース アプリ・Webのデザイン、フロントエンド開発を担当


# Page. 3

![Page Image](https://bcdn.docswell.com/page/PLE1NQ5KJG.jpg)

2018年頃からYahoo!ニュース(web版)を作り直し中
Atomic Designに取り組んでみましたが色々ありました
主要
ハンデ生む感動 離島の甲子園
国内
地域
国際
経済
エースナンバー不在 一体誰に
プロ野球支える洗濯仕事人
集めた甲子園の土 今はどこに
サッカー代表 次世代どう育成
政府 補助金の使い道検討へ
W杯 SNSで最も人気の試合は
1320
鳥の群れ襲来 試合再開遅れる
サッカー チームの経営状態は
4/29(日)12:12
最低賃金 地域差拡大は問題か
ハンデ生む感動 離島の甲子園
336 4/29(日)12:12
ふるさと納税 返礼悩む自治体
Jリーグ 12のチームが“経営危
機”状態に
ブルージェイズ川崎 “日本人メジャー内野手限界説”に待った！
THE PAGE - 4/29(木) 10:10
THE PAGE 4/29(木) 10:10
イチローの東京開幕戦後はど
うなる？
THE PAGE 4/29(木) 10:10
＜プロ野球＞あのトレードの結果は？5年間のトレードを振り返る
THE PAGE - 4/29(木) 10:10
なぜ日ハムの吉田輝星は沖縄2
軍キャンプ初日にブルペンに
入らなかったのか？
336 4/29(日)12:12
消費税国会 与野党の攻防激化
336 4/29(日)12:12
シニアに格安スマホ 注意点は
456 4/29(日)12:12
集めた甲子園の土 今はどこに
1231 4/29(日)12:12
プロ野球支える洗濯仕事人
IT


# Page. 4

![Page Image](https://bcdn.docswell.com/page/8GEW4M5P72.jpg)

Atomic Designとは？


# Page. 5

![Page Image](https://bcdn.docswell.com/page/W47Z2QN6E3.jpg)

Atomic Design
= 画面を構成する要素を最小単位のAtoms(原子)から定義して5段階に分けて、
要素を組み合わせていく設計方法。
http://atomicdesign.bradfrost.com/chapter-2/#atomic-design-is-for-user-interfaces


# Page. 6

![Page Image](https://bcdn.docswell.com/page/KYJ6V68L7V.jpg)

Atoms
原子
Templates
分子
有機体
これ以上分割できない
最小単位
http://atomicdesign.bradfrost.com/chapter-2/#atomic-design-is-for-user-interfaces
テンプレート
ページ


# Page. 7

![Page Image](https://bcdn.docswell.com/page/5GJ5D69MJ4.jpg)

Atoms
Templates
原子
分子
これ以上分割できない
原子 + 原子
有機体
最小単位
http://atomicdesign.bradfrost.com/chapter-2/#atomic-design-is-for-user-interfaces
テンプレート
ページ


# Page. 8

![Page Image](https://bcdn.docswell.com/page/V9E28M2RER.jpg)

Atoms
Templates
原子
分子
有機体
これ以上分割できない
原子 + 原子
分子 + 分子
最小単位
http://atomicdesign.bradfrost.com/chapter-2/#atomic-design-is-for-user-interfaces
テンプレート
ページ


# Page. 9

![Page Image](https://bcdn.docswell.com/page/5D7Y6XY5JM.jpg)

Atoms
Templates
原子
分子
有機体
テンプレート
これ以上分割できない
原子 + 原子
分子 + 分子
ページの枠組み
最小単位
http://atomicdesign.bradfrost.com/chapter-2/#atomic-design-is-for-user-interfaces
ページ


# Page. 10

![Page Image](https://bcdn.docswell.com/page/2VENZ1P4E8.jpg)

Atoms
Templates
原子
分子
有機体
テンプレート
ページ
これ以上分割できない
原子 + 原子
分子 + 分子
ページの枠組み
画面全体
最小単位
http://atomicdesign.bradfrost.com/chapter-2/#atomic-design-is-for-user-interfaces


# Page. 11

![Page Image](https://bcdn.docswell.com/page/GY79Z53473.jpg)

デザインや開発をする時、この段階に沿って要素を定義していく
components
└ atoms /
└ button /
└ thumbnail/
└…
└ molecules /
└ form /
└ tab /
└…
└ organisms /
└ cards /
└ dialog /
└…
└ templates /
└ header /
└ footer /
└…
└ pages /
└ top /
└ information /
└…
http://atomicdesign.bradfrost.com/chapter-2/#atomic-design-is-for-user-interfaces


# Page. 12

![Page Image](https://bcdn.docswell.com/page/5G781YMVED.jpg)

Atomic Designに取り組んだ理由


# Page. 13

![Page Image](https://bcdn.docswell.com/page/ML7LQ43RER.jpg)

今までの課題のイメージ
工業製品に例えると・・見た目や仕様箇所が同じ部品が
各工場で別の名前で管理されていたり、システムが微妙に違っていたり、
仕様を調整する場合、各工場長と相談の上スケジュールを合わせたりする調整コストも必要になるなど
A工場
B工場
「車輪」
C工場
「wheel」
(※Webサービスなので設計や運用でもうちょっと効率化できそうな課題)
「車の輪」


# Page. 14

![Page Image](https://bcdn.docswell.com/page/54EM1KDPJW.jpg)

今までの課題
コードの話
•
画面ごとに構成が違うため、見た目は同じでも実装時に作り直すことが多い。
•
共通で読み込んでいるファイルを上書きするなど、その場しのぎの対応も混ざっ
ており、依存関係が複雑化していて影響範囲が読めない。(安易に整理できない)
→ 車輪の再発明をやめたい


# Page. 15

![Page Image](https://bcdn.docswell.com/page/ZPERLX4YE9.jpg)

Atomic Designをゆるくして導入
正式なのは難しそうなので4つの分類にして数ヶ月運用を続けました
小
大
•
Parts
-
「分子」&amp;「原子」 (ボタン、ページネーションetc)
•
Modules
-
「Partsより大きい粒度」くらい (リストetc)
•
Frames
-
「テンプレート」(ページの大枠)
•
Contents
-
「ページ」(各画面と対応したファイル)


# Page. 16

![Page Image](https://bcdn.docswell.com/page/NP7XW624EX.jpg)

ルール
各要素の中に入れられるもの
小
大
•
Parts
&gt;
Parts (入れ子可能)
•
•
•
Modules
&gt;
Parts
Frames
&gt;
Modules
Contents
&gt;
Frames


# Page. 17

![Page Image](https://bcdn.docswell.com/page/637KV1MPED.jpg)

結果… 4つでも難しかった😣


# Page. 18

![Page Image](https://bcdn.docswell.com/page/4LJ3MQY475.jpg)

変わったこと


# Page. 19

![Page Image](https://bcdn.docswell.com/page/V8JD6955EG.jpg)

変わったこと
〜今まで〜
B工場
A工場
「車輪」
C工場
「wheel」
「車の輪」


# Page. 20

![Page Image](https://bcdn.docswell.com/page/4VEPYZGDE8.jpg)

変わったこと
〜新環境〜
「車輪」
バラバラになっていたモノを整理・統合


# Page. 21

![Page Image](https://bcdn.docswell.com/page/L27VGW6G7Q.jpg)

実際にやったこと
•
PartsとModuleの使い分けなど、Atomic Design的な構成をどう進めるか相談
•
決まった内容を資料に残していつでも見れるようにする (ガイドライン作成、
githubのissue化など)
•
各画面の統廃合の方針を決めたら、ガイドラインに沿って開発を進める


# Page. 22

![Page Image](https://bcdn.docswell.com/page/Z5JG8D2DJL.jpg)

上手くいったところ
•
開発：ボタンや画像など単純なパターンは共通化できた。
•
表示確認：AtomicDesignとStorybookの相性が良かった。
•
デザイン：SketchもAtomic Designを意識して作成。
(仕様書作りなどでデザイナー以外の職種でも使ってもらえている)


# Page. 23

![Page Image](https://bcdn.docswell.com/page/V47Q91PX7P.jpg)

上手くいかなかったところ
•
要素の分類や、親子関係の制限が厳しすぎて使いにくくなってきた
•
•
•
画面が増えていくにつれPartsとModulesの管理も大変に😢
ルールを守るためだけに無くてもいい要素をかませたり、徐々にメリットよりも運用の大
変さが上回ってきた
エンジニアとデザイナーで認識や進め方が全然違って難しかった
(例：コンポーネントの分け方)
デザイナー「A画面で作ったUIをそのままB画面で使いたいです！😄」
エンジニア「AとBはそれぞれ別ファイルで作るけどHTMLは使い回しましょう😄」


# Page. 24

![Page Image](https://bcdn.docswell.com/page/DKE4XRY2E1.jpg)

現在


# Page. 25

![Page Image](https://bcdn.docswell.com/page/PL71NQ6KEG.jpg)

現在
•
Atomic Design風の分類はやめる
•
コンポーネントの粒度で区切るのではなく、ページ単位で関連
するリソースを集約


# Page. 26

![Page Image](https://bcdn.docswell.com/page/8G7W4MWPJ2.jpg)

まとめ


# Page. 27

![Page Image](https://bcdn.docswell.com/page/W4JZ2Q5673.jpg)

まとめ
•
Atomic Designの考え方自体はGood。でも厳密にやろうとす
るとメリットよりも運用の大変さが上回ることも。
•
分類の制約だけの問題ではなく、デザインするときにデザイ
ンパターンを細かくしすぎない意識が平和に繋がりそう。


# Page. 28

![Page Image](https://bcdn.docswell.com/page/KYE6V69LJV.jpg)

ご静聴ありがとうございました！


# Page. 29

![Page Image](https://bcdn.docswell.com/page/5GE5D6NME4.jpg)

Appendix


# Page. 30

![Page Image](https://bcdn.docswell.com/page/V9728M5R7R.jpg)

環境
•
フロントエンド
•
•
•
利用ツール
React (+Redux)
TypeScript
サーバーサイド
•
Node.js
Visual Studio Code
(開発)
Sketch
(デザイン)
Abstract
(デザイン)


# Page. 31

![Page Image](https://bcdn.docswell.com/page/5DJY6XK5EM.jpg)

開発フロー
UI
仕様確定
Component
切り分け相談
静的な
動的な
Component実装
画面の開発
※storybookで表示確認できる
程度まで
デザイナー
ディレクション
デザイナー
エンジニア
デザイナーがタタキを作って
エンジニアにレビューをもらう
デザイナー
エンジニア


# Page. 32

![Page Image](https://bcdn.docswell.com/page/2V7NZ1R478.jpg)

Storybookとは
便利なやつです
Reactで作られたUIを確認できる
UIを表示するときにセットするデータも見れる


