Alternative Atomic Designをさがして

2018年6月7日 21:40

DMMのエンジニアで『React開発　現場の教科書』の著者でもある石橋啓太さんにお声がけ頂いて『ReactとAtomicDesignからみるコンポーネント開発』でお話をさせて頂きました。
テーマは個人的に関心のあった「Atomic Designの代替」を選びました。Atomic Designと言えば、いまや国内外含めてコンポーネント設計をする際に多くの人が参照する概念ですが、すべての環境に適切かと言えばそれはまだ疑問を残す余地があります。

「Atomic Designを採用してみたけどしっくりこなかったので自分たちに合った概念を考えてみた」という個人・組織がいるのはMediumの記事などを通じて知っていたので、そういった事例を集めてみたら面白いんじゃないかなと思ったのがこのテーマを選んだきっかけです。完全に趣味です。

Atomic Designへの疑問

Atomic Designについて知りたい人からの質問や、知っている人同士で雑談をするとほぼ必ず出てくるトピックが「Atomsから本当に作れるのか」「MoleculesとOrganismsの違いが不明瞭」の2つです（自分比）。おそらく、同様の疑問を抱いたり、聞いたり、聞かれたりした方も多いのではないでしょうか。

わかる。

めっちゃわかります。というか僕も知りたい。1つ目の疑問に対しては、プロセス的に難しかったので逆順（画面を作って細かく分解する）で着手するアプローチを取っていますが、MoleculesとOrganismsの振り分けはいまだに悩むんですよねぇ。

Alternative Atomic Designをさがして

実事例を紹介する前に、こういったAtomic Designに対しての疑問、あるいは代替手段の提案についてBrad Frost氏はどのように思われているのかを確認していきます。実はAtomic Designの文中にて、命名についてちゃんと言及されている箇所があります。

Atomic Designで私が選んだ名前は、私とUIデザインシステムを作成するときに協力してくれたチームにとって、本当にうまく機能してくれました。しかし、あなた(読者)とあなたの組織にとってはうまくいかないかもしれません。

Atomic Designは厳格な教義ではありません。結局のところ、どの分類を使用するかは、あなたとあなたの組織がより良いUIデザインのシステムを作り上げるために、効果的にコミュニケーションするかによって変わります
http://atomicdesign.bradfrost.com/chapter-2/#whats-in-a-name

なので、自分たちに合ったAtomic Designを模索するのはBradさん的にはウェルカムらしいです。実際、上記の節では後述するGE Predix Design Systemの事例が紹介されています。

もう1つBradさんの言葉を引用します。こちらはAtomic Designを「スタイルシートのためのコード構造について概説している方法論」と紹介している記事に対してのコメントです。

Atomic DesignはCSSアーキテクチャではなく、ユーザーインターフェイスについて考える方法論です。Atomic Designは、意図的な方法でユーザーインターフェイスを構築するのに役立つメンタルモデルであり、人々が同時にUIデザインシステムの部分と全体の両方を作成できるようにします。
（中略）
この記事はAtomic DesignとCSSについて語っている最初の記事ではありません。ですが、Atomic DesignはCSSとは関係がないことを明確にしたかったのです。
Structuring Sass: Saying Goodbye to Atomic Design Ambiguity

こちらは明確に「Atomic Designはユーザーインターフェイスを構築するのに役立つ方法論 / メンタルモデルである」と表明しています。Atomic Designの方法論をCSSアーキテクチャに応用した例に対してはBradさんも「イイネ！」とコメントしているので、どうやら「Atomic DesignがCSSアーキテクチャだと思われる」ことを好ましく思われていないようです。

それでは事例を見ていきましょう。

GE Predix Design System

GEのPredix Design Systemは先述のようにAtomic Designの文中で、命名規則についての話の中で事例として紹介されています。

アトミックデザインの分類法を使った初期段階のデザインシステムのコンセプトを見た一部の同僚は混乱した。高校の化学の時間に学んだ用語をソフトウェアのデザインに関するウェブサイトで使っていたからだ。アトミックデザインのメタファーが有効でないのが明白だったので、新しい分類法を作る必要があった。

我らはアトミックデザインをこの順で説明するのは階層構造を教えるには適しているがデザインシステムの適用するにはベストな方法ではないと思った。

Predix Design Systemの特徴は関係構造を逆転させ、Applicationと呼ばれる、デザインシステムについて記述されている場を入り口に据えたことにあります。デザインシステムの定義については本記事では触れませんが、より具体性（フレームが存在している、と言ったほうがいいかも？）のある概念だからこその流れと言えます。Atomsよりも抽象度の高いPrincipleが存在しているのも、同様にデザインシステムの文脈で作られているためでしょう。

FutureLearn

Alla Kholmatova氏が記事を書いたFutureLearnの事例では、MoleculesとOrganismsの違いについて悩まれている様子が書かれています。

molecules が organisms になるのにとても複雑な場合や、molecules と organisms の違い、そもそも双方のタイプがなぜ必要なのかなど、正確に理解するのに苦労しています。
（中略）
どのように分割すればよいかという共通理解がチーム内にありませんでした。
それは視覚的なプレゼンテーションについてなのか -例えばサイズなのか視覚的な複雑さなのか? 複雑さなのかコンテンツの重要性なのか? 機能についてなのか? コンテンツが機能を変更したらどうなるのか? そして機能が相対的で、ある要素が出現するコンテキストに依存してたら?

まさに、多くの方が悩まれている問題だと思います。 Alla氏はワークショップをおこない、MoleculesとOrganismsの再定義をおこないました。それがhelpersとstandalonesです。

helpers はそれ自身では意味を成しません。ここには、このグループの典型的な例が、いくつかあります。我々のインターフェイスの中では、molecules が典型的なヘルパーです。

standalone の要素はそれ自身の中で「生き残り」ます。すなわち、それは自分自身の独立したコンテンツと機能の構成として参照されます。
molecules は主に他のインターフェイスの要素をサポートします。organisms は主に自己完結型で、自分自身に依存しています。

この例はまさに「Atomic Designを自分たちの環境に合うように再定義した」好例の1つです。すべてに手を加えるのではなく、必要に応じてルールを変える。ワークショップをおこなったというのもプロセスとして素敵だなあと感じました。

Lewis+Humphreys

Lewis+Humphreysの事例でも、Atomic Designの命名規則に対しての言及があります。

Atom Designの比喩的な性質は、クライアント間で混乱を招くことがわかりました。特に、抽象的な命名規則は少し難しいかもしれません。そのため、私たちは（もちろん）他の偉大なデザイナーからも考えを借りて、コンポーネントベースのデザインに取り組んでいます。

そうして作られたのが Identity / Elements / Components / Compositions / Layout / Pages の6つの概念です。
詳しくは記事を読んで頂ければと思いますが、Componentsの集合体であるCompositionやグリッドやマージンといった抽象的な要素をまとめたLayoutを用いているのが印象的でした。ComponentsとCompositionだけで画面を構成できそうですね。

Airbnb DLS

大胆なアプローチを取っているのがAirbnbのDLS（Design Language System）です。

伝統的に、多くのスタイルガイドはコンポーネント要素をAtomic的な構成として定義し、より複雑なMoleculesを構築するために使用されています。理論的には、これは、一貫性のある柔軟なシステムを作成する上で効果的です。ですが実際には、これらの再利用可能なAtomsはさまざまな方法で使用され、あらゆる種類のMoleculesが生成されることがしばしば起こります。

個々のAtoms（またはAtomic Design）に頼るのではなく、私たちは生命体の要素としてのコンポーネントを検討し始めました。それらは機能と個性を持ち、プロパティのセットによって定義され、他のコンポーネントと共存することができ、独立して進化する（または死ぬ）ことができます。
これは、よりAtomic的なシステムと比較して、システムに関する重要なポイントの1つです。我々は、相互接続された部品やコンポーネントの複雑なネットワークを持っていません。

ここで言及されているのが、Atomsの柔軟性に対しての危機感です。Atomsの組み合わせによってMoleculesが生成「できてしまう」ことによって、意図しないMoleculesが生まれることを懸念しているのではないかと思われます。また、記事を読み進めると「Atoms / Moleculesを作っても、場所によって全く違うレイアウトに変容するやんけ」的なことが書かれています。
そうした状況に対してDLSがとったアプローチは「コンポーネントを最小単位とする」でした。
どのようにまとめているかは記事中のスクリーンショットをご覧頂きたいのですが、これとても面白いなと思いました。抽象度の高い要素はLonaで管理しているんですかね…？🤔

完全に余談ですが、YouTubeでLonaが操作されている動画を見つけたんですけど、なるほどこういう感じなのかーと見ていて面白かったです。

Backelite

Audrey Hacq氏が試みたのは「音符を使ってシステムを概念化する」という面白い手法です。

Atomic Designで使用される語彙はデザインチームの興味を引くことができませんでした。さらに悪いことに、混乱を招く可能性がありました。例えば「MoleculesとOrganismsの違いは何ですか？」または「テンプレートとページはどう比較しますか？」
そして、化学・生物学的なメタファーは非科学者の心（自分自身も含めて）にとって「怖い」と言えるものでした。

氏が最初に試したのはレゴをメタファーに用いる手法でしたが（Atomic Designやデザインシステムの例えにたびたび引用されます）、ブロックを組み立てるだけではない、という考えを伝えるためには別のメタファーが必要でした。そうして選ばれたのが、音符でした。

音符を組み合わせることで状態を説明しており、音符の連なり、ハーモニーはコンポーネントのレイアウトを、メロディーは画面の流れを、リズムはアニメーションやイラストレーション、ボイス&トーンを表しているそうです。
音符の採用によって、デザインシステムについて話すときにたびたび欠けている、感情的で創造的な側面を加えることができた、と氏は述べています。

Backeliteの事例は、システムを説明するのに自分たちに最適な概念を作っていいんだ、と読んだ人に示唆を与えてくれます。正直、私自身はこの事例を読んでもピンとこなかったのですが、それは私が氏のチームメンバーではないからなのです。

Abema TV

最後に紹介するのが、サイバーエージェントのエンジニア、五藤佑典さんが著書『Atomic Design ~堅牢で使いやすいUIを効率良く設計する』で紹介している階層の概念です。この事例ではAtomic Designの代替ではなく、各要素をわかりやすく再定義されています。分類のAlternativeといったところでしょうか。
本文中ではまず、ユーザーがアプリのUIを通して受ける関心事を、行動プロセスとデザインすべき対象とともにまとめています。

（行動プロセス：デザインすべき対象）
画面全体から情報を探す：画面全体のレイアウト
興味を引くコンテンツを見つける：ユーザーの行動を促すコンテンツの見せ方
コンテンツに促されて行動をする：行動を阻害しない操作性
全体を通してサービスに良い印象を抱く（そして再訪する）：デザインの統一性

続いて上記の関心事をAtomic Designの各要素に割り当てることで、

（層：関心）
Templates：画面全体のレイアウト
Organisms：ユーザーの行動を促すコンテンツの見せ方
Molecules：行動を阻害しない操作性
Atoms：デザインの統一性

このようにUIコンポーネントが持つべき関心事を分類されています。より詳しい内容は書籍やくだくらげさんのブログ記事をご参照頂きたいのですが、この整理方法はなるほど！と膝を打つものでした。Atomic Designを社内やチームに共有する時には原著の説明ではなく、五藤さんの分類法を引用すると理解スピードが増すのではないでしょうか。