Atomic Design の課題と解決策：LX DESIGN の大規模リファクタリング事例

はじめに

はじめまして。
LX DESIGNでフロントエンドエンジニアを担当している吉継と申します。
今回が初めての技術記事執筆になりますので、お手柔らかによろしくお願いします🙌

2024年初頭から半年間にわたり、LX DESIGNではフロントエンドの大規模リファクタリングを実施しました。私がちょうどジョインしたタイミングでもあり、その際にリファクタリングの方針や技術選定を担当させていただきました。

リファクタリングの全体像については、以下の記事をご覧ください。
(弊社のフロントエンドのエースですが、文章センスも圧倒的で羨ましい限りですw)
https://zenn.dev/lxdesign_blog/articles/c40708cdd87878

本プロジェクトでは、Atomic Design がUI設計の基盤として採用されていました。Atomic Design を初めて扱う私の最初の印象は、「ファイルを分けるための仕組み」程度のものでした。しかし、実際に取り組むにつれて、Atomic Design が抱える潜在的な課題や運用上の難しさ に直面しました。

リファクタリングの方針を定める中で、この Atomic Design をどのように解釈し、運用に落とし込むか がプロジェクトの成否を分ける大きな鍵となりました。本記事では、Atomic Design についての詳細な解説は割愛し、私が直面した問題点とそれに対する改善策を具体的に振り返ります。

想定する読者

この記事は以下のような方に向けています。

• Atomic Design の採用を検討している
• Atomic Design を採用しているが、運用上の課題に直面している
• ディレクトリ構成やコンポーネント設計を見直したい

結論

Atomic Designを採用する場合、共通認識を持つためのルール作りが必須 です。
また、Atomic Design を忠実に守ることよりも、開発効率やコードの生産性向上を目的とした柔軟な運用 を心がけるべきです。

発生していた問題

1. 再利用性の低さ

再利用性の低い Atoms / Molecules が増え、開発効率が低下していました。
特に Molecule が独自のロジックや状態を多く持つ場合、他の機能で再利用できず、本来の Atomic Design の目的から逸脱していました。

2. ロジックの所在が不明確

ロジックの所在が曖昧で、以下のような問題が発生していました。

• Molecule レベルで API 通信を行っているケースもあれば、Page レベルで API 通信を行い、レスポンスを Props で渡しているケースもあり、統一性が欠けていた。
• 状態管理に Jotai を使用しているものの、Jotai に密結合した Atom や Molecule は特定の機能下でしか使用できず、結果として同じようなコンポーネントが複数生まれ、再利用性が損なわれていた。

3. コンポーネントを探しにくい

/components配下に数百のファイルが雑然と並んでいる状態で、共通コンポーネントと特定の機能のみで使用するコンポーネントが混在していました。このため、既存のコンポーネントを見つけられず、結果として同じようなものを何度も作り直してしまうケースが散見されました。

対処した内容

1. 再利用性の向上

「再利用できない Atoms / Molecules は原則作らない」 というルールを制定しました。これにより、各コンポーネントの責務を明確化し、再利用性を高めることを目指しました。

実装例

以下の例で、特定の用途に閉じた Molecule を汎用的な設計に変更しました。
❌ NG例（再利用性が低い）
特定のフォーム要素に特化した Molecule:

<SchoolGradesField />
<StudentsNumberField />
<SchoolMinutesField />

✅ OK例（再利用性を意識した設計）

<Field required title="学年" />
<Field title="人数" />
<Field title="授業時間" />

2. 明確なルールづくり

各階層における役割と制約を以下のように明確化しました。

階層	呼び出せる階層	再利用性	API通信	Jotaiやロジックとの結合
Atoms	基本行わない	必須	不可	不可
Molecules	Atoms	必須	不可	原則不可
Organisms	Molecules, Organisms	不要	原則不可	可
Pages	Organisms	不要	通信可能	可

• 基本的に下の階層のみを呼び出せるようにしました。一方、モーダルのように特定のユースケースで必要な場合があるため、OrganismsがOrganismsを呼び出すことは例外的に許容しました。
• 原則不可項目を必要に応じて許容する場合は、必ずコード中にコメントで理由を明記する運用ルールを追加しました。

3. ディレクトリ構成の変更

ファイルを探しやすくするため、共通コンポーネントと機能固有のコンポーネントを分離し、構造を見直しました。

Before

/components
  ├── atoms
  ├── molecules
  ├── organisms
  └── pages

After

/components
  ├── atoms
  ├── molecules
  └── organisms
/features
  ├── teachers
      ├── components
          ├── molecules
          ├── organisms
          └── pages

• 全機能で使用可能な再利用性の高いコンポーネントのみを /components 配下に集約。
• 各機能に閉じたコンポーネントを /features 以下に配置。ディレクトリ構成をページパスに沿って整理し、探しやすさを向上。

まとめ：Atomic Design を効果的に運用するために

Atomic Design は単なるディレクトリ分割の手法ではなく、コンポーネントの再利用性を向上させる設計思想 です。しかし、実際に運用する際には、いくつかの課題が伴います。本記事で紹介したように、以下のポイントを押さえることが重要です。

1. 拡張ルールの策定

• Atoms、Molecules、Organisms 各階層での役割を明確化し、共通認識を持つことで、開発チーム全体が一貫性のあるコードを書くことができます。

2. 柔軟なカスタマイズの許容

• Atomic Design に忠実であることが目的ではなく、開発効率や生産性を高めることが最優先 です。
• チームの状況やプロジェクトの要件に応じて、Atomic Design のルールをカスタマイズしたり、一部無視したりすることも必要です。

3. 再利用性の向上を目的とする

• ディレクトリ分割そのものに満足してしまわず、各コンポーネントの再利用性を意識して設計することが重要 です。
• Molecule の肥大化や独自ロジックの持ち込みを防ぎ、共通化できる部分は積極的に共通化する方針を採用しました。

今回のリファクタリングを通じて、Atomic Design を効果的に運用するためには、ルールの整備と柔軟な対応の両立が必要不可欠 であると改めて実感しました。これらの取り組みが、結果的に開発チーム全体の生産性を高め、保守性を向上させる鍵になると考えています。