Atomic Designから派生した、“オルタネイティヴ”な5つのデザインシステム

Atomic Designをどう使うか

吉竹遼氏（以下、吉竹）：では、LT2人目の吉竹です。よろしくお願いいたします。

今日来てる方で、エンジニアの方はどれくらいいらっしゃいますか？

（会場挙手）

やっぱりさすが、多いですね。デザイナーは……？

（会場挙手）

ディレクターさんは？

（会場挙手）

ちょっと後ろのほうにいましたね。それ以外、マーケターとかリサーチャーは……さすがにいらっしゃいませんね。

今日はエンジニアさんがたくさんいらっしゃるイベントかなと思って、なにを話そうかと思ってたんですけど。今回の題にもあるAtomic Designについて、お話しできればと思っています。

話す前に「お前は何者なんじゃ」ですが、改めて、吉竹と申します。バックグラウンドとしては、ずっとアプリのUIデザインをやってきた人間です。なので実はWebの経験はなくて、実装の話とかは、正直そんなにわかんないですが。

基本Sketchとかのデザインツールを使ってアプリのUIを構築して、エンジニアさんとコミュニケーションしていく、みたいなことを業務としてやっています。

最近独立して、フリーランスで活動させていただいたり。あと、一昨日発表があったんですが、最近では、THE GUILDという組織でパートナーとしてお世話になったりしています。

あと、みなさんの中に、椅子の上にシールが置かれている方がいらっしゃると思うんですが。これ、最近、友達と一緒にWebサービスを作りまして。簡単にいうと「デザイン版のはてブ」みたいなもので、今日、エンジニアさん多いと思うので、もしよろしければこちら見ていただいて、RSSとか登録していただくと、毎日いい感じのデザインの記事が流れてきます。宣伝でした。

そもそもAtomic Designとは？

まず最初にAtomic Designのおさらいを簡単にしようかなと思うんですが。さっきの話でもちょっとありましたが、Atomic Designについて「けっこう知ってるぜ」という方はどれくらいいらっしゃいますか？　だいたい概要喋れるよ、みたいな。

（会場挙手）

なるほど。ありがとうございます。「Atomic Design、まだそんなに知らないんだけど」という方。

（会場挙手）

ありがとうございます。じゃあ、簡単に説明しますね。Atomic Designとは、ブラッド・フロストさんが2013年に提唱した概念です（参考：Atomic Design Methodology）

いわゆるページとかインターフェースに含まれる要素、コンポーネントとかを、5つの段階で構成して、それを組み合わせることでサイトやサービスやアプリを作りましょう、というシステムです。その5つの段階を、科学用語に置き換えて説明しています。

まず、1番小さい単位がAtomsと呼ばれています。いわゆる原子です。Atomsの定義としては「それ以上分解できない基本要素」の段階となっています。例えばボタンとかテキストとか、あるいはもうちょっと抽象的な、色とか動きです。

それで、AtomsがたくさんくっつくとMoleculesという分子になる、と言っています。Moleculesの定義としては「1つのことがうまくできること」というふうに書かれてて、例えばテキストボックスというAtomと、ボタンというAtomを組み合わせて、入力方法を作る、というように定義されています。

例えばMolecules同士がくっついたり、MoleculesとAtomsがくっついたりすると、Organisms、生物みたいなものが生まれてきます。Organismsは、最終的なインターフェイスに近いような、比較的複雑なコンポーネントだったりします。

実際に使おうとするとやりづらい

Organismsが組み合わさると、Templatesという、いわゆるワイヤーフレームの状態になってきます。この状態ではまだコンテンツ、例えば写真とかテキストが入っていないので、このあと実コンテンツを入れると、最終形態のPagesになる。だいたいそういう感じで理解していただければと思います。

Atomic Designの中で、Instagramを例にとっているんですけど、こういう感じです。（スライドを指して）Atomsにボタンがあって、Organismsにナビゲーションバーとかタイムバーがある。Templatesはとくになにも書いてないけれども、Pagesになると写真とかユーザー名が入って、ちゃんとした中身になる、という感じです。

理屈ではこうなんですけど、Atomic Designというのは、わりとこう、実際に触ってみるとなかなか「ここってどうなの？」みたいなことが出てきます。僕もよく「Atomsから本当に作れるんですか？」と聞かれます。たぶん笑ってる方もいらっしゃると思うんですけど（笑）。

Atomsの段階では、色とかフォントとか、そういうものを作っていくんですけど、そこから着手するのは難しくありませんか、みたいな質問が第1位。

第2位は「MoleculesとOrganismsの違いがわからないんですけど、どうしたらいいんですか？」。どっちにどっちを入れればいいんですか、とよく聞かれます。

実はさっきのInstagramの例も、よく見るとナビゲーションバーがMoleculesにもあるし、Organismsにもある。どっちやねんということがあるんですね。それは、めっちゃわかるんです。

やりづらさをどう解消するか

そこで、ちょっと別のものを探しに行きませんか、というのが今回の主題です。オルタネイティブな、別世界のAtomic Designを探していこう、というふうに思っています。

つまりAtomic Designに疑問を持っている人が、別の構造とか仕組みを考えていないかを探していこう、という話です。なので、実装の話はぜんぜん出てこなくて、わりとフレームワークというか、命名とかの話になります。あるいはエンジニアさんにとっては「今後デザイナーとどうコミュニケーションしていこうか」という手掛かりとして、今回の話が役に立ってくれればいいな、と思っています。

まずは探しに行く前に「そもそも提唱者のブラッドさんはどう思ってるの？」というところを簡単に説明したいと思います。Atomic Designイヤなんだけど、というときに、ブラッドさんは歓迎しているのかどうか。

実は、さっきもお話ありましたけど、ブラッドさん自身も「Atomic Designはそもそも厳格なものじゃないですよ」と言ってます。

これは別の記事のコメントなんですが「Atomic Designって別にCSSのアーキテクチャじゃないよ」「ユーザーインターフェイスをみんなで考えるためのフレームワークとか方法なんです」と言っています。

なので、考え方とか思想とか、組織内でどう使われているか、そういうところに着目して探してみよう、ということで、今回いろいろ見つけてきました。

考える順番を逆にしてもいい

1個目が、GE（ゼネラル・エレクトリック）です。大きな企業ですけど、GEがPredix Design Systemというものを使っています。デザインシステムの話は長くなっちゃうのであんまり喋りませんけど、簡単にいうとガイドラインみたいなものだと思ってください（参考：GE’s Predix Design System）。

GEの人もやっぱり「困った」と。「AtomsとかMoleculesなんて高校の科学の用語を、なんで今ソフトウェアの世界で知らなきゃならんの？」みたいなところで、けっこう疑問だったらしいです。もっと別の言葉でいいんじゃないか、とか。

あとはAtomic DesignのAtoms、Molecules、という順番が、デザインシステムを作るには適切じゃなかった、って言ってるんですね。そこで彼はどうしたかと言うと、こういうふうにやりました。

（スライドを指して）ちょっとわかりづらいですが、オレンジが従来のAtomic Designで、上がGEの「俺たちが定義したものだぜ！」というものです。右からPrinciples、Basics、Components、Templates、Features、Applications、という単位になっています。なので、実はAtomic Designにはない概念があったり、あるいは、例えばOrganismsとTemplatesがTemplatesにまとまっているような作りになっています。

これでおもしろいのは、1個は継承関係を逆転させたこと。記事を読むとわかるんですが「まずApplicationsから作る」と言っているんですね。なんでかって言うと、デザインシステムの入り口をまず作る。それをどんどん掘るうちに、細かい部分がわかってくるような流れが良いんじゃないか、ということを言っています。だから、まずはApplicationsを追加する。

自分たちにわかりやすい呼び名に変える

あとは、やっぱり利用者が使う言葉に沿ったほうがいいんじゃないかと。とくにMoleculesとかは、デザイナーとかエンジニアさんが使う部分なので、シンプルにComponentsが良いんじゃないか、と言ったりしています。

あと、デザインシステムだからというのはあるんですが、Atomsよりももうちょっと抽象的な、「ビジョン」とか「1つの方向性」みたいなものを示す、Principles（原則）を追加したり、ということが特徴です。

2つ目の例はFutureLearnという会社で、やっぱり「MoleculesとOrganismsがわからない。そもそもなんで2つ必要なの？」というようなことを言っています（参考：Atomic Design の理解 : molecules と organisms をどのように分割するか）。例えば違いについて、サイズなのかとか、複雑さなのかとか、あるいはコンテンツの重要性なのかとか。どこで判断すればいいの、というのがやっぱりわからない。

そこで、ここの人たちはMoleculesとOrganismsを別の呼び方に変えました。helpersとstandaloneって言い方ですね。それぞれなにを指しているかって言うと、helpersはMoleculesに近くて「それ単体だと意味をなさないもの」というふうに定義しているそうです。

例えばここで見ると、シェアのブロックとかコンポーネントがあるけど、それだけだとまだちょっと意味が薄い、みたいな。そういうところをhelpersとして定義しているらしいです。

standaloneはもうちょっと具体的で「それ単体で独立しているもの」「独立したコンテンツと機能の構成として参照される」。例えばこの上のブロックでいくと、なにかやるものが決まっていて、それに対してアクションがとれる。この中で1個、完結をしている、というところが、standaloneの定義になっているらしいです。

新しい要素を作ってしまう

この人たちは、「迷ったらこういうふうに質問すると良いんじゃないか」みたいなところで、例えば補助的な要素なのか自立した要素なのかとか、あるいはなにか独立したセクションになっているかとか、そういう質問をすることで、helpersとstandaloneを定義できるんじゃないか、と言っています。

3つ目の事例はLewis+Humphreysで、ここも、Atomic Designの科学的な用語がクライアントにどうしても混乱を招く、と言っています。やっぱり命名規則が難しくて、ここはもうまるっきり全部、変えました（参考：How we’re using Component Based Design）。

6個、この要素をこの人たちが作りました。Identity、Elements、Components、Compositions、Layout、Pagesですね。IdentityはAtomsとかに近いものです。例えばカラーとか、書体の定義とかをしています。

次のElementsは、例えばパーツ単位みたいな。ボタンとか入力フォームとかをまとめたものを、Elementsと言ってます。

次のComponentsは、そのElementsで構成された要素だと言っています。おもしろいのが「必ずしもモジュール式に見える必要はありません」とも言っていることです。そのComponentsが組み合わさると、Compositionsですね。例えば、たぶん画面内の1ブロックというような定義かなと思います。そういうふうに、Componentsをまとめたものもさらに定義をしていたりします。

おもしろいのが、次でいきなり抽象的なものが出てくるんですね。Layoutというのが本当にレイアウトで、例えばグリッドシステムの話とか、マージンをどうするかをここで定義しています。

要素を減らす

最後はPagesです。これは、いわゆる1画面ずつのことをPagesというふうに呼んでいます。これはこの人たちが作った定義ですね。

けっこうAtomic Designに近い構成だな、というふうに思いました。あとはより抽象的な単位、Layoutを、なんであの順番なのかは僕もわかんないんですが、あそこに含んでいたり。あとはComponentsとCompositionsの違いは、慣れたらけっこう良さそうかなという印象を受けました。

次。事例4として、Airbnbですね。ここもDLS、Design Language Systemというシステムを作っています（参考：Creating the Airbnb Design System）。おもしろいのが、やっぱり「Atomsが難しい」ということで、なんとこの人たちはコンポーネントしか作らなかったらしいです。僕もブログの記事でしか読んでないので、具体的にはそんなに出てこなかったんですが。

もう「俺たちAtomsとかMoleculesとか作んないぜ！　コンポーネントだけを作って、それを組み合わせて画面を作っていくぜ！」とAirbnbは言っているらしいです。

結局、画面をまたいでいくと、こういうサムネイルみたいなものも、場所によってぜんぜん変わっちゃう。それを全部まとめるのは難しい、ということで、もう「コンポーネントが最小単位です」と言ってます。

とはいえ「じゃあその下位要素ってどう定義してんの？」というところはちょっと気になったり。でもコンポーネントだけに特化してるのはおもしろいな、と思いました。

最もコミュニケーションしやすい形を考えることが大切

最後は、Backeliteというところの、あまりメジャーではない、イレギュラーな感じの事例を持ってきました（参考：Atomic Design & creativity）。ここもやっぱり、Atomic Designの比喩が自分たちには合わなかった、と言っているんですね。そこでどうしたかと言うと、なんと楽譜からメタファーを持ってきたらしいです。本当にできるんかい、って感じですが（笑）。

けっこうこれがハマったらしくて、ハーモニー、メロディ、リズムという概念を使って画面を構築しているそうです。

例えば、ハーモニーはコンポーネントの並びを指してて、メロディは画面遷移のことですね。なにかしらの1つの機能を完了するのに、メロディという言葉を使っている。リズムは、アニメーションとかイラストレーションとか、ボイス＆トーンとか、そういったものに適用しているそうです。

この音楽のメタファーのおかげで、自分たちにとってはコミュニケーションとして、かなり創造的で良かった、と言ったりしているわけです。

僕にはちょっと、これが良いかどうかはわかんないですが（笑）。どういうふうにやってたんだろう、とは気になりました。

まとめです。どのような共通項を見いだせたか。サンプル数が少ないのでなかなか見つからなかったんですが「まぁそうだよね」ということがだいたい見つかりました。

みんなMoleculesとOrganismsに悩んでます。あとは科学用語がチームに馴染まないこと。この2つのポイントで、チームに合った構造とか命名規則を考えて実際に試しているのかな、と思いました。

Atomic Designに限らず、どういう名前を使ってどういう言葉でコミュニケーションするのかが1番大事なので。今後みなさんも、Atomic Designとかコンポーネントの構築を考える機会があれば、自分たちの組織とかチームに合った構造とか名称を、みんなで探してみるといいんじゃないでしょうか。

というところで、僕の発表は終わりとさせていただきます。どうもありがとうございました。

（会場拍手）