Atomic Designは役に立たない。
アトミックデザインを採用する会社では「これってAtom？それともMolecule？」といった議論が少なからず行われています。しかしこの議論は完全に無駄で、不毛で、時代遅れなものです。私も度々そういった現場で面倒に感じることがあったので、この解決策としてある方法を行い、Atomic Designの呪縛から脱することができました。その具体的な方法をシェアします。
Introduction
今月頭頃に、Atomic Designが少し話題になりました。
デザイナーあるいはフロントエンドエンジニアとしてTwitterで活動している方であれば、もしかしたらご覧になったかもしれません。
このスレッドです。↓
Atomic Designによる混乱
Atomic Designを真面目に使う現場には、常にある混乱があります。
WEBの世界で活動するデザイナーあるいはフロントエンドエンジニアなら、こんな話を見聞きしたことがあるでしょう。
デザイナーA
「このコンポーネントはAtomsで作るのがいいかな？Moleculesの方がいいかな？」
デザイナーB「Atomsじゃない？」
エンジニアA「いやいやMoleculeでしょう」
エンジニアB「私はAtomsでもいいと思う」
これがAtomic Designの現場です。新しいコンポーネントが生まれるたび…というのは言いすぎですが、低くない頻度でこのような会話と議論が行われます。
開発の進行に影響を及ぼすのも問題ですが、目に見える緩慢さ・ボトルネック感が非常に目を引くストレスとなり、チームへのエンゲージメント(あるいはルールへの納得感)をちょっとずつ削いでいくことが最も痛い損害です。
ストレスを避けようとして、コンポーネントまわりのDesignOpsも停滞しがちになります。
更に重要なことに、その場に複数名いれば、その答えはバラけることが多くあります（Atomic Designの信奉者同士でも！）。
実験してみましょう。下記の画像を見てください。そして問いかけに対し答えを考えてみてください。
いかがでしたか？
私はこれはMoleculeだと思いました。あなたの答えは何だったでしょうか。きっと、デザイナーならAtom、エンジニアならMoleculeだと答えたのではないかなと思います。
私の予想は外れているかもしれませんが、自分と考えが一致する人しか居ないと保証することはできません。
誰もがAtomic Design流の分類法の専門家でもなければ解釈は一致せず、そんなことはあり得ないため、議論は生まれ続けるわけです。
最も重要な問題は…
また、Atomic Designの分類が完璧だったとしても、より根本的な問題が残ります。
それは、そんな分類には意味も価値も無いということ。なぜならその通りの構造はコードでは実現できないからです。
実際にAtomic Designで開発してみれば体感できると思いますが、Atomic Designで作られたデザインは、結局フロントエンドのコードになる際に大きな再解釈が行われます。
実装や背景事情によってアーキテクチャが異なるのに、どうしてAtomic Designだけはその影響を受けずにいられるでしょう？
あるいは、あるコンポーネントがAtomかMoleculeか、あるいはOrganismか判別できたとして、それが開発にとって何するものだというのでしょう？
そのままでは各コンポーネントは何に使うべきかすら分かりません。ドメインやビジネスロジックといった責務で分類する方が実践的です。（これについては”余談2”にて後述）
よりテクニカルな問題
Atomic Designは、自分で自分を上手く説明・定義することが出来ていません。
たとえばAtomについては「最小の要素」という定義です。
が、最小の単位はフロントエンド（HTML）とデザインでは異なるため、デザイナーとエンジニアの間で翻訳を噛ませないと議論が噛み合いません。まるで言語の壁のようです。
また、その定義の曖昧さが原因で、デザイナーの作ったファイルを見ると色んなものがAtomになっていることがあります。
Atomic 2.0
近年ではデザイントークンという概念および技術が登場したため、真の意味でのAtomはデザイントークンであるという認識がデザイナーに広まりつつあります。これは技術的にも納得できる良い傾向です。
例えば昨年の今日に投稿されたAtomic 2.0では、Atomはトークンに置き換えられています。
自分のやっている方法
姿勢
こういった混乱を経験してきた身として、Atomic Designについての自分の意見は次のとおりです。
Atomic Designは
概念としては優秀だけど、
実用性は皆無。
Atomic Designには真面目に向き合ってはいけません。こんなに人を翻弄するメジャーな概念もありません。雰囲気だけ使うのが正しい対応方法および活用方法です。
無駄なことについて、無駄な時間と労力を必要とするのですから。
でも1つだけ言っておくと、Atomic Design自体はグレートです。
ひとたび採用するとフロントエンドのアーキテクチャが正義だということを忘れたり、現実に対応するためにAtomic Designが維持できなくなるという現実問題があるだけで。
まあそれが致命的なんですが。
解消のための具体策
宣言する
私がOpsに参加しているチームでは、コンポーネントについて「Atomic Designは使いません」と名言しています。1
実践内容にAtomic Designに影響を受けたものがあるため、何も言わなければAtomic Designだと解釈されかねないからです。
名言することによってそもそもAtomic Designではなくなるので「これはAtom？」といった無意味な混乱の芽を摘むことが出来ます。
3種・5つのドキュメント
コンポーネントを表すものはFigmaのライブラリとNotionに分け、またコンポーネントとは別にデザイントークンを用意しています。
そして実装ベースのコンポーネントについてもNotionにドキュメントを作っています。
ライブラリはAtomic2.0を採用しカスタマイズ
Figmaで作成しているコンポーネントは、Atomic2.0を標準として採用し、中身はある程度カスタマイズしています。
が、Atomic Designとは無関係な、ただドキュメントを読みやすくするためのコンポーネント種別です。実装とは無関係です。
ハンドオフではコンポーネントを3分割
また、コンポーネントをドキュメントに落としたり挙動や仕様についてハンドオフする際、コンポーネントを下記の3つに分割して記述しています。
Blocks：ページを除いて最大粒度のコンポーネント
Entity：トークンを除いて最小粒度のコンポーネント
Others：それ以外の全てのコンポーネント
これはコンポーネントの粒度別につけているためAtomic Design的です。
が、これもAtomic Designとは無関係な、ただドキュメントを読みやすくするためのコンポーネント種別です。実装とは無関係です。
説明する際も「とりあえず大きさ別に並べただけです。名前にも意味はありません。ただの呼称です。」と案内しています。
余談1
分かる人には分かるかもしれませんが、この構成はデザインシステム化することで自動化できるものです。そして私たちもそれを志向しており、現在システム化へ向けて動いているところです。
余談2
上記コンポーネントたちは、コードになる過程でエンジニアの手によってBaseコンポーネント、Commonコンポーネント、Domainコンポーネントへ分類・変換されています。
このBCD Design2はAtomic Designライクですが、意味による分類であり開発にとってフレンドリーです。コンポーネントの本体はデザインファイルではなくコードですから、より実用的と言えるでしょう。
結論
私たちはデザインとコードが1:1の同一性を持つことを目指して努力していますが、Atomic Designを採用するとこの問題を複雑にしてしまいます。デザインファイルと開発の本質的な差の軽視による諸々が原因で、Atomic Designは言語の壁のように機能するからです。
DesignOpsがこの沼から抜け出す方法はシンプルで、ほとんど唯一です。Atomic Design自体を排除するのです。少なくともそう宣言するのです。
テクニックや事例も色々と載せましたが、この意思決定と表明こそが最も大きなソリューションでした。
今後もこのような情報を発信していきます。興味がある方は、ぜひSubscribeと私のTwitterもフォローしてくださいね🙏
【「Atomic Designは使いません」と名言しています。】
当時はAtomic Designを支持した人もチームにはいました。が、その弱点や実用性の欠如を説いてどうにか説得し、最終的には正式に宣言しました。
良い記事ありがとうございます！