Atomic Designが刺さる現場・刺さらない現場

Atomic Designと刺さらない現場

果物リン氏：前回もRoppongi vueでしゃべらさせていただきました果物リンです。

今回は実質懇親会LT的なノリだと思いますが、「Atomic Designと刺さらない現場」というタイトルでしゃべりたいと思います。今回の内容はちょっと若干過激なんじゃないかなと思うんですけど、まあ、お気持ちなのでというところで。

みなさん、Atomic Design使っていますか？　使ったことがあるよという方、手を挙げてもらっていいですか？

（会場挙手）

おっ、半分はいかないかな。4割ぐらいいそうですね。みなさん、Atomic Designがうまくいっているなと思う方、手を挙げてください。

（会場挙手）

1、2人いるかいないかぐらい。そんなにはいなさそうですね。はい、本日はそれを踏まえての発表になるかなと思います。

株式会社ゆめみの果物リンです。フロントエンドエンジニアとして働いていたら、いつまにかリードエンジニアという扱いになっていました。

最近、Ionic/Vueというものを推しています。Vueでネイティブアプリが作れるんですよね。マジでVueそのものでネイティブアプリが作れるので、本当にiPhoneアプリが作れるんですよ。おもしろいですよ。最近推しなんですけど。

モダンフロントエンド設計はだいたいAtomic Design？

さてさて、いきます。Atomic Designといえばこんなやつですよね。よく見るやつだと思います。

「モダンなフロントエンドのコンポーネント設計の話というと、だいたいAtomic Designの話しか出てこなくないですか？」みたいなところをちょっと話題にしたいんですよ。でも、実際にAtomic Designを私もちょっとやってみたんですけどね、なんかしっくりこないんですよ。

ちょっと考えてみたんですけど、「Atomic Designとは？」といえば、デザインを原子から組み立てるところが一番の特徴が挙げられると思うんですけど。なのですが、そもそもAtomic Designは全体に統一感を生み出すためのデザインシステムの1つなんですよね。

ここでいう「デザインシステム」という耳慣れないワードが出てきたかもしれません。ということでちょっと調べてみましょう。ググって上から2番目に出てきた「Web Design Trends」というサイトに「デザインシステムを正しく理解しよう」という記事がありました。そこにはこう書かれていました。

「デザインシステムとは、デザインの原則、概念、ガイド、コンポーネントなど、デザインに関するあらゆるルールを定めたもののことを言います」って書いてあるんですよね。

スタイルガイドやコンポーネントライブラリはデザインシステムの一部なので、Bootstrapを使ったことあると思うんですけど、これもデザインシステムの1つというわけなんですよね。調べて見ると、BootstrapをSketch上で再現するためのデザインシステムが配布されていたりするので、そんな感じです。

デザインシステムのメリットは、先ほどのサイトではこのように述べられていました。「一貫したデザインを作れるようになる」「チームでのデザイン制作をスムーズにする」「デザイナー以外の人と共通認識を持つ」とかって書いてあるんです。これはつまり、こいつは本来エンジニアのためのものじゃないんじゃないか説があるんですよね。

Atomic Designの原著をよく読むと、実装、つまりデータやロジックの責務については、実際に触れていないんですよね。なので、Atomic Designの文脈でデータやロジックの責務に関する考え方について触れられた記事とかは、基本的に後付けのはずです。原子から組み立てる発想がたまたまコンポーネントシステムと相性がよかっただけなんですよね。

Atomic Designを採用してコンポーネントの分割粒度に悩むことになるのは、実装の責務がどこにあるのかについて、そもそもAtomic Designの文脈から外れていると考えたわけです。

Atomic Designが刺さる現場・刺さらない現場

というところで、刺さる現場として、デザインシステムのメリットがほぼそのまま通用しまして、つまり継続開発が行われていることや規模が大きい場合、デザインに統一感を持たせることができる意味や制作チームのスケールという点で、もちろんAtomic Designは役に立ちますよね。

また、デザイナーさんとの共通言語としてAtomic Designが採用されて初めて機能するようになると思います。最終的な理想で言えば、デザイナーさんがStorybookを見たりしながら、コードをそのまま見て、コードに直接コミットしてくれるようになったら、理想的なかたちかなと思います。

一方、刺さらない現場ももちろんあります。継続開発しない現場や規模が小さい現場は、仮にAtomic Designを採用しても、メリットをあまり感じないと思います。

また、デザイナーとエンジニアの距離が遠い場合は有効活用しづらいんですよね。デザイナーのためのものなので、エンジニアのためではないところから入ると、あんまり刺さらないです。

そもそも、デザイナーがAtomic Designを採用していないのに、エンジニアの一方的な思惑でAtomic Designの採用というのは、ほぼ無駄に終わるんじゃないかなというのが私の感想です。

「そういうときにどうするの？」というのは、そもそもAtomic Designに頼らないところから出発するしかないかなという気がします。

泥臭い話なんですけど、心の赴くまま自分で分割していくしかないかなと。私は使い回さないものについては、ある程度、密に作ってしまうのもいいかなと思っています。使い回したくなったとか見通しが悪くなってきたあたりが分割の適当な理由かなと。

ディレクトリ分けとか悩むんですけど、今の私だったら、何か最初にCommonsとSpecialsみたいな感じで疎結合なものと密結合なものに分けて、さらに用途ごとにディレクトリを切ってみたいなことをたぶんやるんじゃないかなと思います。

まとめです。Atomic Designそのものはデザインする人のためのツールであって、エンジニアのためのツールではないです。現場によっては刺さらないこともあって、それはそれでしょうがないんじゃないか。こういう分け方、なんかいい名前がほしいなと思っています。なんかいいアイデア求めます。

というあたりで、今日の発表を終わりたいと思います。ありがとうございました。

（会場拍手）