Atomic Designを実践して得た学びと失敗 - コネヒト開発者ブログ

🙋‍♂️エンジニアの@dachi_023です。約4ヶ月ぶりに記事を書きます、がんばります。

この記事について

コンポーネントやAtomic Designについて書いています。ここではUIデザインのフローに関するAtomic Designの実践ではなく、開発(実装)のフローにはめ込んだ場合にどうすべきなのか、というお話をしています。

コンポーネントとAtomic Design

ReactやVueをはじめとするライブラリのお陰でフロントエンド開発に「コンポーネント」という考え方が浸透した今日この頃ですが、そんなコンポーネントの設計についての話なんかをしているとよく現れるのが今回の主題に挙げている「Atomic Design」です。Atomic Designはデザインシステムを効率よく作成するための手段のひとつですが、その中に登場するコンポーネントを5階層(Atoms, Molecules, Organisms, Templates, Pages)に分類するという手法がコンポーネント指向なライブラリと相性が良く、設計や実装に取り込むことで今までよりもエンジニアとデザイナーの認識も揃えやすそうだよね〜、といった理由などにより次第にメジャーな手法となっていきました。*1

ちなみに、Atomic Designに関する解説などはしないのでよくわからないけど気になるなという方は下記のweb書籍、もしくは「Atomic Design」で検索して出てきた解説記事などを読んでいただくことをオススメします。 atomicdesign.bradfrost.com

直近1年くらいは特に「Atomic Designを参考に設計・実装しました」系の記事やスライドを見る機会も増えてきたのですが、結構ハマりどころとか似てるんじゃないかな？と思ったので溜まった学びを本記事にまとめることで誰かの役に立てれば良いなと思っています。

Atomic Designによって得られた恩恵

「共通言語」を手に入れたことによってコミュニケーションの質が上がりました。例えば、導入前は分類するための指標がないのでコンポーネントの粒度が個人の判断任せになっていて、レビューをする際もお互いに何が正解なのかが分からずで不健全な状態が続いていました。それに比べ導入後は「このUIをAtomsとして1つのコンポーネントに切り出してください」といったコミュニケーションができるようになったのでレビューがしやすくなりました。

実践し始めた当初はエンジニア1名(私だけ)のプロジェクトで開発してたこともあって、UIを型にはめて分類できるようになったことがめちゃくちゃ便利〜！と思っていたんですが、それよりもチームメンバーにエンジニア・デザイナーがいる環境でチーム内で同じ認識を持つための道具としての方が受ける恩恵が大きいなと感じました。コミュニケーション大事。

f:id:dachi023:20191019034838p:plain Atomic Design Methodology | Atomic Design by Brad Frost

ハマりどころと、それをどう解決したか

Atomic Designっていいところがいっぱい！やっていこ！と思えるんですが、開発手法におけるベストプラクティス、みたいな話でもないので開発にそのまま当てはめると痛い目を見ます。というわけで、ハマったポイントが複数あるのでそれぞれ書いていきます。

5階層であることは重要ではない

5階層あるんか！キッチリ分けたろ！となるかもしれませんが、別にいらなければ使わなければいいですし、逆にこういう層が欲しいなぁ〜っていうのがあれば足してもいいと思います。Atomic Designはあくまで「コンポーネントを分解する時にこういう考え方をするといいよ」というアドバイス的なもの(だと私は解釈しています)なので、どういう形で実装されるかは実践するエンジニア・デザイナー次第です。例えば実装時にうちのプロダクトではTemplatesは使わなさそうなので4階層でやります。とかそういう感じです。チームやプロダクトに合わせた構成でやっていくのが1番だと思います。

Atomsから作っていくのが難しい

例えばボタンとかラベルのようなUI的にも分かりやすく「これ以上分解できない」ものは簡単だと思うのですが、作っていかないと気づかないものやその時点では本当に必要なのかが分からないものもあるはずです。そういう時はOrganismsやPagesを作って、それを分解していくのが良いと思います。どこから作るか、にこだわり過ぎずチームとして効率的に開発・デザインできる順番で良さそうです。

MoleculesなのかOrganismsなのか

この問題はよく見かける気がするんですが「Moleculesに求めるもの」「Organismsに求めるもの」が定義できていればいいだけだと思っています。他の階層についても同じで、それぞれどんな条件を満たしている時にその階層になるのか、でやればいいと思います。チーム内で各階層のコンポーネントについての定義ができていて、ちゃんと共通認識となっていれば判断に迷わないはずです。

ちなみに、私は「Organismsはそれ単体で画面上に存在しうるもの」と考えていて、それに満たないもので複数のAtomsによって構成されていいれば全てMoleculesとしています。Atomic Design Methodology に出てくるUIを例に挙げると、ヘッダーは単体で画面に表示されていても1つのUIとして機能するのでOrganisms、それに比べて検索フォームは検索する対象が(= 何を検索するのかがUIとして明示的で)なければ存在している意味がありません。かつ、フォーム(Atoms)とボタン(Atoms)のセットなのでMolecules、という風に考えています。

Atomic Design Methodology | Atomic Design by Brad Frost

Organisms以降のコンポーネントがFatになりがち

(ここだけ考え方ではなくて具体的な実装の話をしています)

組み合わせるコンポーネントの数が増えるにしたがってコード量も増えがちです。ディレクトリ構造が下記のようになっているとOrganisms内のみで使用されるコードを逃がす場所がなく、1コンポーネント内に大量のコードが詰め込まれることになりやすいです。

# Before
src
├ atoms
│ ├ Button.jsx
│ └ Input.jsx
├ molecules
│ └ SearchForm.jsx
└ organisms
　 └ Header.jsx

なので、下記のようにディレクトリを1つ掘り下げて、Organisms内で閉ざしておきたいが分割した方が可読性が上がりそうなコードを置く場所を作ってあげると実装しやすいです。実際の実装では「分割はできるが再利用性がないもの」を考慮しないと結構辛いシーンが多いのでその辺は柔軟に実装側でカバーできるようにしておくと良いと思います。

#After
src
├ atoms
│ ├ Button.jsx
│ └ Input.jsx
├ molecules
│ └ SearchForm.jsx
└ organisms
　 └ Header
　 　 ├ index.jsx
　 　 ├ Logo.jsx
　 　 └ Menu.jsx

エンジニアがAtomic Designから得たもの

「コンポーネントをどう分類するか」に尽きると思います。これをフロントエンドの設計に当てはめた時にめちゃくちゃ使いやすくなるよね、が多くのエンジニアにウケたし、実際やってみて良かったことが多かったからだと思います。ただ、そのままでは使いづらい部分も多いよね、という話でより具体的な実装の話を持ち出したAtomic Componentsというものも出ていたみたい*2です。