経緯とか
デザインリニューアルでコンポーネントベースでデザインし直すことになり、それなら Atomic Design を採用しようという話なりました。
そこで、
1. Atomic Design を採用してどんなメリットがあるのか知りたい
1. Atomic Design を知らないメンバー（主にエンジニア）にもなぜ採用するのか説明したい
という思いから自分なりに採用理由を整理してみることにしました。
（ちなみに本来採用理由はチームごとに少しずつ違うと思いますが、ここでは一般的に採用理由になるだろうと思った内容をまとめています。）
この記事の対象者
Atomic Design は知っているけど、何がよいのか知らない、または言語化できていないと思っている人
そもそも Atomic Design を知らない方は 2018年のフロントエンドエンジニア/デザイナーに知ってほしいAtomic Design - Qiita のような分かりやすい記事がたくさんあるので、そちらを読んでみて興味があれば本記事を読んでみてほしいです！
Atomic Design チョットデキル方は、ぜひこの記事にマサカリを投げてください。
Atomic Design とは
Atomic Design の説明は、「AbemaTV」に Atomic Design を導入した五藤佑典氏の「Atomic Design ~堅牢で使いやすいUIを効率良く設計する」の中での説明が一番綺麗にまとまっていると思うので、そのまま引用させていただきました。
Atomic Design は小さいUIコンポーネントを組み合わせてより大きなコンポーネントを作っていくためのデザイン・フレームワークです。UIコンポーネントを５つの階層に分類することにより、最終的にはアプリケーションのUIをこれ以上分割できない機能にまで分割することを開発者に意識させます。そのため、より大きなUIが必要になる場合はコンポーネントを組み合わせて作るしかありません。Atomic Design は、どんな単位でUIをコンポーネント化すればよいかを示してくれるとてもシンプルなフレームワークです。
Atomic Design は、アメリカ・ピッツバーグを拠点に活動する Web デザイナー Brad Frost 氏が提唱しました。Brad Frost 氏は、従来の画面ごとに UI デザインを作っていくという考え方ではなく、コンポーネントのしくみを設計することが Web をデザイン（設計）することだと考えています。Atomic Design の「Design」という言葉は、ビジュアル的なデザインという意味ではなく、「設計」という意味のほうが強いです。
引用元：Atomic Design ~堅牢で使いやすいUIを効率良く設計する（著：五藤 佑典）
Atomic Design を採用しないとしたら
メリット・デメリットを整理するには、その対比となるものが必要です。
ここではひとまず「従来の画面ごとに UI デザインを作っていくという考え方」を Atomic Design の対比とします。
（便宜上、「従来型デザイン」と呼ぶことにする。）
従来型デザインの場合のイメージ
views/ styles/
├── user ├── user
│ ├── index.html │ ├── index.css
│ ├── show.html │ ├── show.css
│ ├── edit.html │ ├── edit.css
│ └── _user_info.html │ └── _user_info.css
├── project ├── project
│ ├── index.html ......
... ....
├── common ..
│ ├── _header_nav.html
│ ├── _bottom_nav.html
│ ├── _side_nav.html
...
従来型デザインの問題点
UI の一貫性を保つのが難しい
画面ごとにデザインしていると、同じ「決定ボタン」なのに色や形が違うということが容易に起こります。共通パーツはあってもヘッダーやフッダーなどを共通パーツとして用意するようなケースが多く、ボタンやラベルなどの細部まで一貫性を保ちやすくする仕組みはありませんでした。
一貫性のない UI はユーザーがアプリを使う際の学習コストを増やしてしまい、ユーザーは常に目的のものを探して回ったり、操作した結果がうまく想像できず不安を抱えながらアプリを使ったりすることになります。最悪の場合、こうした大小様々なストレスによりアプリから離脱してしまうでしょう。
一貫性が低下する要因の１つは 「既存の UI を再利用しづらい」 ことです。
従来型デザインで既存の UI を再利用しようとすると、各画面を見て回って利用できそうな UI を探し、自分が作る画面に持ってきてからデザインを調整し…ということを毎回しなくてはなりません。なので、効率よく開発するなら既存の UI を再利用せずに画面ごとに自由に作ってしまう方が早いということになってしまいます。
また再利用性の低さは 変更に弱い ことの原因にもなります。元になった UI が変更されたときに、同じ UI を利用している画面を探して回って修正しなくてはならず、それを怠ると UI の一貫性はどんどん失われていきます。さらに元々１つの画面でしか使わない想定で作った UI パーツを共通化してしまうことで、「ある画面をちょっと修正したら別の画面が崩れてしまった！」ということが起こりやすくなります。
再開発による開発効率の低下が起こりやすい
再利用性の低さによる一貫性の低下は開発効率にも影響を与えます。
すでに同じ用途の UI があるのに、画面ごとに新しく UI デザインをするのは明らかに 車輪の再開発 になってしまいます。画面ごとに要件や機能を決めた上で、それに合う UI をデザインするのはとてつもないコストがかかります。
開発メンバーが少ないうちは、「今度こんな画面を作るんだけど、既存の UI で使えるところあるかな？」と聞いて回ったり、そもそも１人でデザインから実装までやったりすれば問題ないのですが、アプリが成長してメンバーが増えてくると、「誰に聞けばいいのか分からない」「なんて言って聞けばいいのか分からない（共通言語の不足）」など、コミュニケーションコストが一気に増大して開発効率がどんどん落ちていきます。
Atomic Design の登場
そこで登場したのがコンポーネントベースのデザイン手法である Atomic Design です。
ちなみに Atomic Design を考案した Brad Frost 氏が書いた記事 にも書いてある通り、Atomic Design は全く新しい手法ではなく、今までも行われてきた手法を方法論として明示したものです。
Atomic Design のメリット
UI の一貫性の向上
Atomic Design ではまずボタンやラベルといった最小単位のコンポーネント（Atom）のデザインを決めて、その Atom を組み合わせてさらに大きなコンポーネントを作っていきます。
画面をデザインするときは、それらのコンポーネントを組み合わせて作るという制約があるので、UI の一貫性を保ちやすくなります。コンポーネントは Atom や Molecules などの単位で１箇所にまとめてあるので探す手間も少なく、コンポーネントに分割する際にコンポーネントの名前や分類を決めてあるのでディレクトリ構造やファイル名から内容が想像しやすいように仕組みとしてサポートしてくれます。
再開発による開発効率の向上
こちらも同様に、アプリ内で使われている UI はコンポーネントとして一箇所で管理してあるので、そこを見れば自分が新しく作る画面で使える UI は揃っています。それを確認した上で、画面固有のデザインや新しく用意しなくてはならないコンポーネントのデザインに開発リソースを集中することができます。
また、コンポーネント名や分類はそのまま UI の議論やデザイン・エンジニア間の連携のための共通言語になり、コミュニケーションコストを大きく下げてくれます。
コンポーネント分割問題の解決
ここまではコンポーネントベースでデザインした場合のメリットです。
なので、「コンポーネントベースがいいのは分かったが、必ずしも Atomic Design じゃなくてもいいのでは？」という疑問が生まれます（私だけ？）。
しかし、UI をコンポーネントごとに分割すると必ず「どこまでが１つのコンポーネントなのか」「AとBのコンポーネントには同じ要素が含まれているので、その部分を直すとAとBを両方直さないといけない」と言った問題が発生します。
それらの問題を解決する方法の１つとして、Atomic Design を採用する方法があります。
Atomic Design を採用した場合のディレクトリ構造のイメージ
components/
├── atoms
│ ├── AtomImage
│ │ ├── index.vue
│ │ └── index.stories.js
│ ├── AtomButton
│ │ ├── index.vue
│ │ └── index.stories.js
│ └── AtomText
│ ├── index.vue
│ └── index.stories.js
├── molecules
│ ├── UserCard
│ │ ├── index.vue
│ │ └── index.stories.js
│ └── ProjectCard
│ ├── index.vue
│ └── index.stories.js
└── organisms
└── CardList
├── index.vue
└── index.stories.js
参考： Nuxt.js × Atomic Designのサービスデザインフロー
Atomic Design ではまず最小単位のコンポーネント（Atom）に分けて、次に Atom を組み合わせて…といった手順をふむことでコンポーネントを段階的に分割していく手順やそのときの基準となる考え方を提供してくれます。これらの手順や分割基準を０から考えていくのはかなりの経験が必要だと思います。
もちろん、Atomic Design を採用しただけでコンポーネント分割問題が全部解決するわけではなりません。しかし、チームとして「どうコンポーネントを分割していくか」を決める際に有用なフレームワークだと言えると思います。
まとめ
Atomic Design を採用するのは、
「一貫性のある UI デザインを効率よく実現するため」
参考
Atomic Design のメリット・デメリットについて書いてある記事を一部参考にさせていだきました。
Atomic DesignとSketchをウェブサービスのフルリニューアル時に採用した理由｜UUUM DESIGN｜note
Atomic Designに向き合ってみてわかったことをまとめてみた | Findy Engineer Lab - ファインディエンジニアラボ
Atomic Designの考え方と利点・欠点 – wkr.