<p>かつて<a href="http://blog.kubosho.com/entry/using-atomic-design">Atomic Design の考え方と利点・欠点</a>という記事を書きました。<br>
この記事内で日本では<a href="https://abema.tv/">AbemaTV</a>で使われていると書きました。そして今でも AbemaTV では Atomic Design の考えに基づいてコンポーネントが作られています。</p>
<p>AbemaTV での経験を通じて、Web アプリケーションのクライアントサイドの開発者という立場から Atomic Design はどうなのかについて書いていきます。</p>
<p>なお AbemaTV ではビューライブラリとして React を使っているので、React 前提の話になります。</p>
<h2>Atomic Design に基づくのは実際どうなのか</h2>
<p>基本的には良いです。良い点について書いていたら<a href="https://ygoto3.com/posts/atomic-design-on-actual-project/">Atomic Design を実案件に導入 - UI コンポーネントの粒度を明確化した結果と副産物 | ygoto3.com</a>や<a href="https://www.slideshare.net/ygoto3q/atomic-desigin-powered-by-react-abematv/31">Atomic Design powered by React @ AbemaTV</a>に書いてある内容と似てきたので、良い点についてはこれらの資料を見てください。</p>
<p>ただし問題点もあります。いま思いつく限りでは大きく 2 つ問題があると考えています。</p>
<h3>人によってコンポーネントの粒度が違う</h3>
<p>Atomic Design において <code>atoms</code> はそれ単体で使うことはなく <code>molecules</code> や <code>organisms</code> 内に取り込まれた状態で使われます。</p>
<p>また <code>molecules</code> にあたるコンポーネントは単一責任の原則に基づくのが良いとされています。</p>
<p>しかしコンポーネントによっては <code>props</code> が多すぎるものもあります。特に <code>molecules</code> の一部コンポーネントは <code>props</code> が 22 個あります。<br>
実際に該当のコンポーネントは挙動を変更する理由がいくつかある状態です。</p>
<p>この場合は責務ごとにコンポーネントを分割すればよかったのかもしれません。<br>
もしくは<a href="https://reactjs.org/docs/higher-order-components.html">Higher-Order Components - React</a>を取り入れても良いかもしれません。</p>
<h4>デザイナーとデベロッパーのコンポーネントの粒度も違う</h4>
<p>今だとデザイナーが Sketch の Symbol 上に構築したコンポーネントの粒度とデベロッパーが実装したコンポーネントの粒度が違うものもあります。</p>
<p>デザイナーとデベロッパーのどちらかの考えに粒度を合わせるのが良いでしょう。<br>
この場合、基本的にはデザイナーの考えに合わせたほうが良いと思います。<br>
<a href="http://morishitter.hatenablog.com/entry/2016/07/29/204642">morishitter の CSS の書き方（2016 年夏） - morishitter blog</a>にもある「デザインの意図を正確に理解した上で書かれた CSS は破綻しない」です。</p>
<p>とはいえ、自分もあまり余裕がなかったため「なぜこのデザインなのか」をあまり聞けていません（Slack 上でどのデザインにするかやりとりしているときに「これが良いですねー」とか反応するくらい）。</p>
<p><a href="http://demo.patternlab.io/">Pattern Lab のデモ</a>に作りたいコンポーネントのカテゴリーがあったらお互いそれに沿うようにするのもいいでしょう。<br>
たとえば <code>blocks</code> だったら <code>molecules</code> で <code>sections</code> だったら <code>organisms</code> という感じです。</p>
<h3>コンポーネントのテストが面倒</h3>
<p>コンポーネントのテストを書く場合は <code>enzyme</code> を使って <code>find()</code> などを用いて要素があるかを探し、表示されている文字が期待のものと合致しているかなどをテストすると思います。</p>
<p>この場合テストとは直接的に関係ないコードがテストコード内に存在することになります。<br>
テストを書くときに Virtual DOM 内をいちいち探索しないといけなくなるため、そこまでテストコードが書かれていないコンポーネントが増えることにもなります。<br>
また各コンポーネントがどのような <code>props</code> を持っているか調べないといけないため特に <code>organisms</code> にあたるコンポーネントのテストは面倒になるでしょう。</p>
<p>そのため Jest の<a href="https://facebook.github.io/jest/docs/en/snapshot-testing.html">Snapshot Testing</a>のように、スナップショットとなるコードを書いてテストコード側でそれと合致するか確かめるようにする流れができつつあります。</p>
<hr>
<p>この記事は<a href="https://adventar.org/calendars/2216">AbemaTV Advent Calendar 2017</a>の 17 日目の記事でした。<br>
AbemaTV では<a href="https://recruit.abematv.co.jp/jobs/engineer/">Atomic Design のよりよい運用を考えたいデベロッパーを募集中</a>です。</p>

Atomic Designを実案件に導入して運用してみた結果はどうなのか

<p>Atomic Design はデザインシステムを作る方法論となります。<br>
デザインシステムというのはスタイルガイドやブランドのガイドラインなどを指すようです。</p>
<p>日本だと<a href="https://abema.tv/">AbemaTV（アベマ TV）</a>で使われています。<br>
（<a href="http://ygoto3.com/posts/atomic-design-on-actual-project/">Atomic Design を実案件に導入 - UI コンポーネントの粒度を明確化した結果と副産物 | ygoto3.com</a>より）</p>
<p>Atomic Design は今までのページ単位と違いコンポーネント単位でデザインカンプを作る考え方です。<br>
作ったコンポーネント同士の組み合わせでページを作ります。</p>
<p>Atomic Design はコンポーネントの単位を 5 つに分けています。<br>
その 5 つの単位は Atoms（原子）・Molecules（分子）・Organisms（有機体）・Templates（テンプレート）・Pages（ページ）です。<br>
各コンポーネントの詳細は次のとおりです。</p>
<h2>Atoms（原子）</h2>
<p>Atoms（原子）は、UI を構成する基礎的な要素が該当します。</p>
<p>フォームでいうと、画像で示すようにラベル・入力部分・ボタンの各要素が Atoms となります。<br>
他の要素では、カラーパレットやフォント、アニメーションが Atoms に入ります。</p>
<p><img src="//blog-assets.kubosho.com/atoms.png" alt="Atomsを指した図。フォームのラベル・入力フォーム・ボタンがAtomsとなる"></p>
<p>Atoms に振り分ける基準としては、<strong>対象の要素が機能的にそれ以上分割できない</strong> 場合、Atoms へ振り分けます。<br>
フォームで例えると、ラベルはそれ以上機能的に分割できません。<br>
また入力フォームやボタンもそれ以上機能的に分割できません。</p>
<p>Atoms 単体だと抽象的でどういう意味を持つかは分からないです。<br>
入力フォームだけ見ても、それがアカウント登録フォームもしくはコメント入力フォームという情報は読み取れません。</p>
<p>Atoms はコンポーネントの基礎部分になります。<br>
それは、Atoms を組み合わせてより大きなコンポーネントを構成するという点から言えることです。</p>
<p>また Atoms を俯瞰できるページを用意しておくことで、そのページがどのようにデザインされたかという雰囲気を感じ取ることができます。<br>
それによりページデザインに一貫性を持たせることができます。</p>
<h2>Molecules（分子）</h2>
<p>Molecules（分子）は、Atoms を組み合わせて作る要素です。<br>
この Atoms を組み合わせて Molecules を作るというのは「単一責任の原則」や UNIX 哲学の「1 つのプログラムは 1 つのことをうまくやる」に基づいているようです。</p>
<p>Molecules になることで意味を持つ要素となります。<br>
たとえば、Atoms であるラベル・入力フォーム・登録ボタンという 3 つのコンポーネントがあってもそれら単体は意味をなしません。<br>
しかし、これらの要素を組み合わせることにより「ラベルで示したことに応じて、入力フォームに何かを書いて、登録ボタンを押す」という意味が示せるようになります。</p>
<p><img src="//blog-assets.kubosho.com/molecules.png" alt="Moleculesを指した図。フォームのラベル・入力フォーム・ボタンをまとめたものがMoleculesとなる"></p>
<p>Molecules はできるだけ単純にして、再利用性や UI の一貫性を高めます。</p>
<h2>Organisms（有機体）</h2>
<p>Organisms（有機体）は、Atoms や Molecules、また他の Organisms を組み合わせて作る要素です。今までの Atoms や Molecules とは違い複雑な要素になります。<br>
ヘッダーやフッターと呼ばれる要素はこの Organisms になります。</p>
<p>たとえば画像で示すようなヘッダーは「タイトル」という Atoms と、「ナビゲーション」「SNS のボタン群」という Molecules が組み合わさって、ヘッダーという Organisms になっています。</p>
<p><img src="//blog-assets.kubosho.com/organisms.png" alt="Organismsを指した図。WebページのヘッダーやフッターなどがOrganismsとなる"></p>
<p>Organisms からそのページの特色が出やすくなります。</p>
<h2>Templates（テンプレート）</h2>
<p>ここから Atoms（原子）・Molecules（分子）・Organisms（有機体）といった化学的なものに例えることをしなくなります。<br>
これは仕事の依頼元や上司・同僚に見せるものということを明確にするため、より一般的な言葉を使います。</p>
<p>Templates（テンプレート）の説明に移ると、Templates はページ構造を説明するものです。<br>
Templates は Molecules や Organisms を組み合わせて作ります。</p>
<p>Templates の段階ではページ内容がまだ仮となります。Templates を言い換えるなら「<a href="https://www.google.co.jp/search?q=%E3%83%AF%E3%82%A4%E3%83%A4%E3%83%BC%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0&#x26;tbm=isch">ワイヤーフレーム</a>」になります。</p>
<h2>Pages（ページ）</h2>
<p>Pages（ページ）は、Template 内へ実際の文章や画像などが入ったものとなります。</p>
<p>ここまで 5 つの要素について概要を書きました。<br>
要素の振り分けかたについて、どのように考えたらいいかは<a href="http://atomicdesign.bradfrost.com/chapter-2/#atomic-design-is-for-user-interfaces">Atomic design is for user interfaces</a>内の Instagram で例えたものが分かりやすいと思います。</p>
<h2>Atomic Design の利点</h2>
<p>さて、Atomic Design を実際に適用した結果、次に挙げる 3 つの利点があると感じました。</p>
<h3>名前がついている</h3>
<p>Atomic Design はコンポーネントの大きさによって、それぞれ Atoms・Molecules・Organisms・Templates・Pages という名前がついています。<br>
この名前がついていることで、Atoms は「それ以上分割できないコンポーネント」ということや、Molecules の「Atoms を組み合わせた意味があるコンポーネント」という特徴が共有されやすくなると思います。</p>
<h3>デザインの変更に対応しやすくなる</h3>
<p>Atomic Design の考え方でコンポーネントを作ると、デザイン変更に対応しやすくなり再利用性も高くなります。<br>
特に Atoms や Molecules へ振り分けられるような細かいコンポーネントはデザイン変更にも強いです。</p>
<p>今回適用したページはそこまでデザイン変更が起こりませんでした。<br>
それでもデザイン変更があったときはいつもと比べて他コンポーネントへの影響を考えずに対応できました。</p>
<h3>セレクタの詳細度が平坦に近づく</h3>
<p>Atomic Design を適用するとセレクタの詳細度が平坦になるようです。</p>
<p>次の画像は今回 Atomic Design の考え方を使って作った CSS の詳細度を示したグラフですが、割と平坦なグラフになっています。</p>
<p><img src="//blog-assets.kubosho.com/css-valhalla.png" alt="神獄のヴァルハラゲートのイベントページのCSSの詳細度を指した図。飛び出すところがあまりない平坦なグラフとなっている"></p>
<p>また Atomic Design を採用している AbemaTV の CSS も突然詳細度が上がることなく平坦なグラフです。<br>
ただこれは中の人になって分かったことですが、CSS Modules の仕組み（css-loader）を取り入れているため CSS は各コンポーネントごとにスコープが閉じた状態で書くことができます。<br>
そのためセレクタの詳細度をあまり上げなくてもスタイル宣言をできるため、詳細度が抑えられています。</p>
<p><img src="//blog-assets.kubosho.com/css-abematv.png" alt="AbemaTVのCSSの詳細度を指した図。急に飛び出していない平坦なグラフとなっている"></p>
<h2>Atomic Design の欠点</h2>
<p>利点ばかりではなく、Atomic Design の欠点も見えました。</p>
<h3>デザイナーがどのようにデザインしていけばいいか分からない</h3>
<p>Atomic Design は「小さい単位でコンポーネントを作り大きいコンポーネントにしていく」というデザイン手法です。そのため、フロントエンド実装では利点があります。</p>
<p>しかしデザイナーからすると、Atomic Design の考え方でデザインすることは難しいかもしれません。<br>
実際、今回デザイナーへ Atomic Design について説明しました。<br>
ただ、デザインしてもらうときはコンポーネント単位ではなくページ単位でデザインしてもらう従来の方法をとりました。</p>
<p>デザイナーによるページデザインの段階で Atomic Design を取り入れることに関しては、どうしたらいいのかまだ分かりません。</p>
<h3>欠点に対しての対応</h3>
<p>今回はコンポーネントリストを作りました。以下の jsfiddle ではかなり簡略化したリストですが、以下のように Atoms・Molecules・Organisms とコンポーネントを分けて見せるようにしました。</p>
<iframe width="100%" height="300" src="//jsfiddle.net/bed3aj1k/2/embedded/result,css/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<p>デザイナーには通常通りページ単位でデザインカンプを作ってもらいました。<br>
そして、自分のほうでそのデザインカンプを見つつ、Atomic Design の各単位に要素を切り出し、コンポーネントを作りました。</p>
<p>作ったコンポーネントリストをプランナーやデザイナーに共有しておくことで、実機でどのように表示されるか分かりやすくなることと、開発者にも共有しておくことでコンポーネントを使うことを促し、結果としてコード量や実装の工数を減らすことを目論みました。<br>
また、コンポーネントリストは作っておくと、どのようにコンポーネントを分割するか意識することができます。</p>
<h2>まとめ</h2>
<p>今回初めて Atomic Design の考え方でページを作ってみました。<br>
結果としては、思ったより良い感じにハマった感があります。<br>
今後も Atomic Design の考え方に照らし合わせてコンポーネントを作り、良い感じに変更に強く分割されたコンポーネントを作っていきたいと思います。</p>
<h2>出典</h2>
<ul>
<li><a href="http://bradfrost.com/blog/post/atomic-web-design/">Atomic Design | Brad Frost</a></li>
<li><a href="http://atomicdesign.bradfrost.com/">Atomic Design by Brad Frost</a></li>
<li><a href="http://ygoto3.com/posts/smashing-conference-whistler-and-atomic-design/">最近よくクリエイターが移住するカナダで Atomic Design を学ぶ | ygoto3.com</a></li>
<li><a href="http://ygoto3.com/posts/atomic-design-on-actual-project/">Atomic Design を実案件に導入 - UI コンポーネントの粒度を明確化した結果と副産物 | ygoto3.com</a></li>
<li><a href="http://postd.cc/the-unicorn-workflow-design-to-code-with-atomic-design-principles-and-sketch/">珍しいワークフロー：Atomic Design の原則と Sketch でデザインからプログラミングまで | デザイン | POSTD</a></li>
<li><a href="http://design.dmm.com/entry/2016/02/05/153408">Atomic Design は Web 開発を救うのか - DMM.com ラボ デザイナーズブログ</a></li>
</ul>

学ぶ、考える、書き出す。

タグ「Atomic Design」の記事一覧