Reactを使ったコンポーネント指向設計で、Atomic Designをやめようとしている話

はじめに

OHEYAGOの開発をしている田渕です!

OHEYAGOはtoCサイトなので、UI・UXを重要視しており、チームとしてデザイナーを2人抱えております。
デザイナーは他業務との兼任ですが、それに対してエンジニアは3人なので、デザイナーの割合がとても多いチームです。
エンジニアとデザイナーで共通認識を持ち、開発効率を向上させるために、デザインシステムとしてAtomic Designを採用していました。

しかし、運用がうまく行かず、ある問題が露わになってきたため、Atomic Designをやめようとしている最中です。

そこで、上手く行かなかった知見の共有として、どういった問題が出てきて、どのようなデザインシステムに舵を切ろうとしているのかを紹介します!

最初にAtomic Designを採用した理由

当時のチームには、Reactでの開発経験が多い人がおらず、コンポーネント設計も手探り状態でした。
お手本としてある程度参考にできそうなもので、当時流行っていたAtomic Designを選びました。

Atomic Designに求めていたことは、一貫したコンポーネント設計による保守性の高さと、開発効率の高さでした。

遭遇した問題

チーム全員でこちらの本を読み、開発を進めていました。
しかし、あるコンポーネントを作成した際に、それがmoleculesなのかorganismsなのか決められないということが頻発しました。

原典のサイトも見ながら議論しましたが、

Molecules are relatively simple groups of UI elements functioning together as a unit.
Organisms are relatively complex UI components composed of groups of molecules and/or atoms and/or other organisms.

relatively simplerelatively complexの間にある差が分からず、moleculesとorganismsの境目がどんどん曖昧になってしまいました。

moleculesとorganismsの境目が曖昧になった結果

moleculesとorganismsを切り分けるために考えるコストが非常に大きくなった結果、moleculesを作ることが億劫になってしまいました。
その結果、どんどんorganismsが多くなってしまい、organinsms自体が大きなコンポーネントになっていきました。(organismsの中でmoleculesを呼ばずにそのままdom要素があるイメージ)

moleculesとatomsが作られる回数が減り、コンポーネントの使い回しがあまりできなくなり、開発効率と保守性の高さを実現できなくなってしまいました。

そもそもの開発の背景と、至った結論

OHEYAGOでは、先に「画面をこういう風にしてほしい」という要望があり、さらにそれがどんどん変化していくことが多いです。
このようなスクラップビルドが多い環境では、Atomic Designに則って開発することは非常にコストが高く、現実的に難しいなという結論に至りました。

すなわち、「仕様で与えられた画面から分解していってコンポーネントを作る」という作業をしながら、Atomic Designのでの「小さなものを積み上げていく形も想定してコンポーネントを作る」という、ある種相反した思考を続けることに限界を感じてしまいました。

もちろん、Atomic Designが悪いという話をしているわけではなく、「現状のチームとプロダクトの性質では、Atomic Designは難しくて運用がうまく行かなくなってしまった」という意味です。

コンポーネントから先に作ってしまえる」という背景があるかどうかが、Atomic Designが上手く行くかどうかの鍵になっていると感じました。
事前に工数を確保して、使いそうなコンポーネントを予め作っておき、基本的にはそれを組み立てることで実装していく、という開発フローには非常にマッチしていると思います。

OHEYAGOでは、画面のイメージがガラッと変わるタイミングがそこそこ頻繁にあり、その際にAtomic Designほどの綿密な設計を練ることが、求められる開発速度とリソース的に難しかったです。
その結果、コンポーネントの粒度が大きくなってしまうと、使い回せる部分が減ってしまい、保守性の高さも開発効率の高さも実現できないため、思い切ってAtomic Designをやめようという結論に至りました。

導入中のデザインシステム

一方で、Atomic Designを取り入れたことで、非常に良かった面もあります。
templatesとpagesを、templatesはlayoutとlayoutに関連したロジックを扱う場所、pagesをそれ以外のロジック(API通信やページ遷移など)を扱う場所、と切り分けたことで、pagesは主にエンジニアが、templates以下は主にデザイナーが担当する、という分業により、開発効率が向上しました。

なので、この利点を活かしながら、organisms以下を刷新しようとしています。

結論から言うと、pages、templates、UI group、UI partsという切り分け方を採用しました。
organismsと一部のmoleculesをあわせてUI group、残りをUI partsとして、デザイン上の役割というより、再利用されるかどうかという役割の違いで明確に分けていくことにしました。

具体的な開発フローとしては、まずはUI groupを作り、その中で共通化できそうな部分を適宜見つけてUI partsに切り出していく、という共通化を行おうと思っています。
通化が甘くなってしまうという恐れ(既に似た部分が別のUI groupにあることに気づかず、もう一度作成してしまう恐れ)はありますが、そちらはStorybookなどでコンポーネントの一覧性を高めていくことで担保できるかなと考えています。

pages(layout以外のロジック), templates(layout関係のロジックとlayout), UI group(使いまわされないコンポーネント)、UI parts(使いまわされるコンポーネント)と明確に責務を分け、分類に困ることを減らしつつ、コンポーネント指向の旨味を最大限享受しようとしています!

おわりに

盲目的に既存のデザインシステムに則るのではなく、開発体制やプロダクトに合わせたデザインシステムを作っていき、環境の変化によって柔軟にデザインシステムも変化させていくことの重要性を感じました。
現状のデザインシステムの運用がうまくいくのかはわかりませんが、また何か気づいたことがあれば記事にしていこうと思います!