2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

小規模アプリでAtomic Designを採用したら管理が大変すぎてやめた話

Posted at

こんばんは、KoenigWolfです。
今回は 「Atomic Designって理論は素晴らしいけど、小規模アプリには向かないかも…?」 という話を、shadcn/uiを導入していた自分の実体験を交えてゆるっと共有したいと思います。


🎨 「とりあえずAtomic Designで」から始まった

小さな個人開発プロジェクトを始めたとき、コンポーネント設計のベストプラクティスを調べると、必ず出てくるのがAtomic Design

原子(Atom)、分子(Molecule)、有機体(Organism)、テンプレート(Template)、ページ(Page)に分けて整理する、あれです。

「なるほど、理にかなってるし、整理もされてて良さそう。
今後の拡張も考えて、最初からしっかり設計しておこう!」

そう思ったのが、すべての始まりでした。


🧱 Atomが増える。どこまでがAtom?

最初は楽しかったんです。
Buttonatoms に入れて、Inputatoms に入れて、ちょっと複雑になってきた FormFieldmolecules にして…。

でも、数日経つとある疑問が頭をもたげます。

このコンポーネント、Atom?Molecule?
CardHeaderってOrganism?それともMolecule

粒度の定義が曖昧になってくるんです。
チーム開発ならガイドラインを定めればいいかもしれませんが、これは小規模アプリ開発者は自分ひとり

それでも毎回「これはAtomか?Moleculeか?」と悩みながらディレクトリを分けていく。
気づけば、ディレクトリ構造のために思考コストを割いている自分がいました。


😵‍💫 shadcn/ui導入でディレクトリ迷子が加速

そんな中、shadcn/uiを導入しました。
理由はシンプルで「見た目が綺麗で、カスタマイズもしやすいし、手間が省けるから」。

ただここで新たな混乱が生まれます。

shadcn/uiのコンポーネント、どこに置く?
Button.tsxはshadcn由来なのか自作なのか?
atomsに置くのか?それとも別フォルダにする?

結果、こんな地獄に

src/
├── components/
│   ├── atoms/
│   │   └── Button.tsx ← shadcn?
│   ├── ui/
│   │   └── button.tsx ← これshadcn/uiの元ファイル
│   └── molecules/
│       └── CustomForm.tsx

もう、何が何やら

「同じ名前のButtonが複数ある」
「shadcn/uiの原型はuiにあるけど、ラップしたものはatoms?」
「でもそのatoms/Buttonも他からimportされてて、変更できない…」

完全にコンポーネント迷子になってしまいました。


📦 機能単位+shadcn/uiでシンプルに割り切るようになった

悩みに悩んだ末、Atomic Designはやめて、 機能ベース(Contextual/Feature-Based) に整理しました。
shadcn/ui のコンポーネントはcomponents/ui/に隔離して、shadcn依存であることが明確になるように統一。

src/
├── components/
│   └── ui/           ← shadcn/ui由来のコンポーネントはここに集約
│       ├── button.tsx
│       └── input.tsx
├── features/
│   └── user/
│       ├── components/
│       │   └── UserCard.tsx
│       ├── hooks/
│       └── utils/

この構成の良かった点

  • shadcn/uiの改修やアップデート管理が楽になった
  • 「どの機能の何に関係するか」が一目でわかる
  • 粒度で悩まない。悩みは「どこに置くか」だけ
  • 開発に集中できるようになった

Atomic Designは道具であって、目的じゃない

Atomic Designが悪いわけではありません。
むしろ、大規模なデザインシステムには非常に有効だと思います。

ただし、 小規模アプリでの導入には注意が必要 です。

  • 一人開発だと設計に悩む時間が増える
  • shadcn/uiのようなUIライブラリとの相性が悪い
  • 保守よりも分類にエネルギーを割いてしまう

特に個人開発においては、 「ルールを守るために疲弊する構成」より、「開発が楽しくなる構成」 の方が、よっぽど価値があると痛感しました。


✍️ 最後に

この記事が、

  • 「Atomic Design、使ってみたいけど実際どうなんだろう?」
  • 「shadcn/uiってどこに置けばいいか迷う…」
  • 「結局、何が正解なんだ?」

と悩んでいる方の参考になれば嬉しいです。

何度でも言いますが、設計はプロダクトの性質と開発者の性格によって最適解が変わる
だから、「自分にとっての最適解を探る過程」こそが大事なんだと思います。


🧵 ご意見や体験談があれば、ぜひコメントで教えてください!
この記事が役に立ったら、いいね・ストックもらえると励みになります 🙌

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?