Atomic Designの分類を見直す。3階層から始める、UI変更に強いコンポーネント設計

• keyboard_arrow_down はじめに
• keyboard_arrow_down Atomic Designの魅力と落とし穴
• keyboard_arrow_down 現場で使える代替アプローチ：3層で十分
• keyboard_arrow_down 実践で重要な設計原則
• keyboard_arrow_down まとめ

「このボタンは独立したコンポーネントにすべき？」
「フォームの一部として直接書く？」

コンポーネントベースの開発をしていると、「適切な分割粒度」を判断しなければならない場面に数多く直面します。小さすぎると管理が煩雑になり、大きすぎると再利用が困難になる。この絶妙なバランスを見つけるのは、多くの開発者が悩むポイントです。

この悩みを解決する手法として、一時期「Atomic Design」が大きな注目を集めました。しかし実際に導入してみると、便利な側面ばかりではなかったようです。本記事では、Atomic Designについて振り返り、現代のフロントエンド開発により適した実践的アプローチを提案します。

Atomic Designは、2013年にBrad Frost氏が提唱したUI設計手法です。化学の原子（Atom）の概念を借りて、コンポーネントを最小の単位から順にAtoms（原子）、Molecules（分子）、Organisms（有機体）、Templates（テンプレート）、Pages（ページ）の5階層に分類します。

この手法は、多くの開発者がコンポーネント設計の軸となる考え方を決めきれていなかった時代に現れたため、多くの人々が意思決定の拠り所としました。特に好まれた点としては以下の点が挙げられると、筆者は考えます。

2010年代後半にデザインシステムへの意識が業界内で高まったこととも相乗効果を起こし、「コンポーネント設計といえばAtomic Design」という風潮さえ生まれました。

Atomic Designの関心

Atomic DesignはUIを階層的に体系化する手法です。最小の部品から段階的に複雑な構造を作り上げることで、一貫性のあるデザインシステムを構築できます。

この手法では、まず Atoms（原子）としてButton、Input、Iconなどの最小単位の部品を定義します。次に Molecules（分子）では、これらのAtomsを連携させて一つの機能を実現します。例えば、InputとButtonを組み合わせたSearchBoxなどがこれに該当します。さらに Organisms（有機体）では、MoleculesやAtomsを組み合わせて、より複雑な部品を構築します。ページヘッダーや商品カードなど、特定の機能を持つコンポーネントがこの階層に位置します。

▲Atomic Designの5階層

一方で Templates（テンプレート）は、ワイヤーフレームとして導線設計を行い、構造のみを提供します。最終的に Pages（ページ）では、Templatesに具体的な部品を当て込んで実際のページを作成します。
このようにAtomic Designを整理すると、大きく分けて2つの関心事があることが分かります。PagesとTemplatesは画面全体の体験設計に関心があり、一方でOrganisms、Molecules、Atomsは再利用可能な部品を生み出すことに関心があります。

実践で見えてきた課題

コンポーネント設計の指針を求めていたReactエンジニアたちに、Atomic Designは広く受け入れられました。しかしながら、流行りものになってしまったこともあり、自分たちのチームやプロダクトにフィットするかどうかをあまり検討せずに導入してしまったケースも見られました。

十分なリソースを割いてデザインシステムを構築・運用できるチームであれば、すべての階層を分けてコンポーネントを設計する価値があるのかもしれませんが、現実にはそこまでのリソースを確保できるチームばかりではありません。

杓子定規に階層を再現しようと努力するあまり、小さいMoleculesをAtomsと区別するための議論や、大きいMoleculesをOrganismsと区別するための議論に時間を費やしたチームもあったことでしょう。TemplatesとPagesを分けて実装したはいいものの、Templatesを更新しながらユーザー導線を調整する習慣がないチームやプロダクトでは、ただ単にファイルが分割されているだけの不便なものとして扱われたことでしょう。

あらゆる技術選択と同様に、Atomic Designもまた、チームとプロダクトにフィットする形に調整しながら導入するべきものだったのです。

これまで見てきたAtomic Designの課題を踏まえて、より実践的なアプローチを考えてみましょう。多くの現場経験から言えるのは、実際に必要なのは3つの層だけだということです。

この3層構造では、MoleculesとTemplatesを省略することで、分類の迷いを大幅に削減できます。もちろん、細かな粒度での部品管理ができなくなるという側面はあるものの、各層の役割は明確で、実際の開発現場でも判断に迷うケースが少なくなります。

Atoms（最小単位の部品）では、Button、Input、Iconといった、プロジェクト全体で共通して使用される基本的なUI要素を定義します。これらはデザインシステムの基盤となる部品で、一貫性のあるUIを構築するための土台となります。

Organisms（機能単位の部品）では、AtomsやHTMLの基本要素を組み合わせて、特定の機能を持つコンポーネントを構築します。ページヘッダー、商品カード、コメントフォームなど、複数のページで再利用される可能性のある部品がここに該当します。ビジネスロジックを含む場合もあります。

Pages（ページ固有の部品）では、OrganismsやAtomsを組み合わせて、特定のページでのみ使用されるコンポーネントを作成します。ページ固有の状態管理や振る舞いを担当し、実際のユーザー体験を形作る最終的な層となります。

この簡潔な3層構造により、チーム内での認識統一が容易になり、コンポーネントの分類に関する無駄な議論を避けることができます。また、コードの見通しも良くなり、新しいメンバーがプロジェクトに参加した際の理解も早くなります。

機能中心のフォルダ構成

3層アプローチと合わせて採用したいのが、機能中心のフォルダ構成です。従来の階層ベースの分類ではなく、ビジネス機能ごとにコンポーネントを整理することで、開発効率が大幅に向上します。

src/
├── features/
│   ├── auth/
│   │   ├── LoginForm.jsx // Organisms
│   │   └── SignupForm.jsx // Organisms
│   └── product/
│       ├── ProductCard.jsx // Organisms
│       └── ProductList.jsx // Organisms
└── shared/
    ├── Button.jsx // Atoms
    └── Input.jsx // Atoms

このフォルダ構成では、認証機能や商品機能といった関連するコンポーネントが同じディレクトリに配置されます。機能追加や修正の際に、関連するファイルがまとまっているため、作業効率が向上します。また、機能単位での影響範囲の把握も容易になり、メンテナンス性が大幅に改善されます。

Pagesコンポーネントについては、通常pages/やroutes/といったルーティングに対応したディレクトリに配置するか、各featureフォルダ内でpages/サブディレクトリとして管理するのが一般的です。具体的な配置は、使用しているフレームワークのルーティング規約に従うことをお勧めします。

突然Atomic Designの用語が出てこなくなって戸惑ったかもしれませんが、重要なのは設計思想としての分類であって、フォルダの命名としての取り回しの良さはまた別問題です。 atoms/ や organisms/ などの命名を採用することでAtomic Designにおける立ち位置を明確に示すことはできる点だけは有用ですが、あまり意識しすぎると原理主義的になってしまう人もいるので、命名としては残さないほうがよいと筆者は考えます。

3層アプローチを採用する際に、合わせて意識したい設計原則がいくつかあります。これらを理解することで、より質の高いコンポーネント設計が可能になります。

意味のある命名を心がける

コンポーネントの命名では、見た目の特徴よりも機能や役割を重視することが重要です。デザインが変更されても、名前と実装の一貫性を保つことができるからです。

// ❌ 見た目に依存した命名
function RedButton() { }
function BigCard() { }

// ✅ 機能や役割を表す命名
function SubmitButton() { }
function ProductCard() { }

見た目ベースの命名では、デザイン変更のたびに名前と実装の矛盾が生じる可能性があります。機能ベースの命名なら、見た目が変わっても役割は変わらないため、長期的な保守性が向上します。

責務の分離を徹底する

一つのコンポーネントに複数の責務を詰め込むFat Componentは、保守性とテスト性を著しく損ないます。責務ごとに適切に分割することで、理解しやすく変更に強いコードを作ることができます。

// ❌ 多くの責務を持つコンポーネント
function UserDashboard() {
  // ユーザー情報の管理
  // 投稿の表示・編集
  // コメントの処理
  // 通知の管理
  // 数百行のコードが続く...
}

// ✅ 責務ごとに分割されたコンポーネント
function UserDashboard() {
  return (
    <div>
      <UserProfile />
      <PostsSection />
      <NotificationArea />
    </div>
  );
}

このように分割することで、各コンポーネントが単一の責任を持ち、テストや修正が容易になります。Custom Hooksを活用して状態管理ロジックをコンポーネントから分離することも、責務の分離に効果的です。

Atomic Designは理論的なフレームワークとして価値がありますが、現実のプロジェクトでは課題も多いことが分かりました。重要なのは、チームとプロダクトの特性に合わせて、実用的なアプローチを選択することです。

3層構造（Pages/Organisms/Atoms）と機能中心のフォルダ構成を組み合わせることで、分類の迷いを減らし、開発効率を向上できます。加えて、意味のある命名と責務の分離を心がけることで、長期的に保守しやすいコードベースを構築できます。

次回は「フォルダ設計の実践論」として、コンポーネントファイルの効果的な整理・管理手法について詳しく解説します。適切なコンポーネント分割ができたら、それらをどう整理するかが次の重要なステップとなります。

コンポーネント設計に唯一の正解はありませんが、基本原則を理解し、チームの状況に応じて柔軟に適用することで、開発効率と品質の両立を実現できるでしょう。