こんにちは
情報システム部のNです。

今回は、React開発において避けて通れない「コンポーネント設計」と「プロジェクトの持続性」についてお話しします。
Reactは非常に柔軟で、スピード感のある開発が可能なライブラリですが、設計を軽視すると開発スピードはすぐに失速します。

「なんか最近、変更を加えるのが怖くなってきた…」「ちょっと修正しただけで別の画面が壊れた…」という経験、ありませんか？
この記事では、そんな“Reactあるある”を防ぐための「コンポーネント設計の原則」と、プロジェクトの持続性を高めるための具体的な考え方をご紹介します。

■なぜコンポーネント設計が重要なのか？
Reactの強みは、UIを部品（コンポーネント）として分割・再利用できることです。

しかし、「なんとなく動けばOK」な設計を続けていると、気づかないうちに以下のような問題が積み上がります。

・似たようなUIがバラバラに存在し、修正コストが増大
・propsや状態が複雑化し、バグが発生しやすくなる
・他のメンバーがコードを読んでも意図がわからない

これを防ぐには、コンポーネントを正しく設計する原則を知り、それをベースに設計していくことが必要です。

■コンポーネント設計の3つの原則
1. 単一責任の原則（Single Responsibility Principle）
コンポーネントは、1つの役割だけを担うべきです。

// ❌ 悪い例：1つのコンポーネントがなんでもやっている
const UserCard = () => {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetchUser().then(setUser);
  }, []);

  return <div>{user?.name}</div>;
};

これを分割すると、以下のように見通しが良くなります。

// データ取得だけを担うコンテナ
const UserCardContainer = () => {
  const user = useUser(); // カスタムフックで取得
  return <UserCard user={user} />;
};

// UI表示だけを担うプレゼンテーションコンポーネント
const UserCard = ({ user }) => (
  <div>{user.name}</div>
);

このように、「見た目とロジックを分離」するだけでも、保守性がぐんと上がります。

2. 再利用性のある抽象化
コンポーネントは、1回きりではなく再利用されることを前提に設計しましょう。
例えばボタン。

// よく使うボタンコンポーネント
const Button = ({ children, onClick, variant = 'primary' }) => {
  const className = variant === 'primary' ? 'btn-primary' : 'btn-secondary';
  return <button className={className} onClick={onClick}>{children}</button>;
};

これを使えば、プロジェクト全体の見た目を統一しながらも柔軟なUIが作れます。

3. 型の明確化（TypeScriptで安心）
Propsは、何を受け取って何を返すのかを明確にしましょう。

TypeScriptを使えば型安全性が上がり、他の開発者も安心して使えます。

type Props = {
  user: {
    id: number;
    name: string;
  };
};

const UserCard: React.FC<Props> = ({ user }) => (
  <div>{user.name}</div>
);

propsが増えても、型がしっかりしていればメンテナンスも楽です。

■プロジェクトの持続性を高めるために必要なこと
さて、設計がしっかりしていても、プロジェクトの構造自体がゴチャついていては意味がありません。
以下の点を意識することで、プロジェクトの持続性をさらに高めることができます。

状態管理のスコープを明確に

・状態はできるだけ局所化し、必要以上に上位のコンポーネントに持たせない
・複数のコンポーネントで共有するなら、Context APIやZustandなどを使う
・グローバルステートをむやみに使わないこと

ディレクトリ構成を意味のある単位で整理する

src/
  components/     # UIパーツ群
    common/       # Buttonなどの汎用コンポーネント
    layout/       # Header / Footerなど
    features/     # 機能ごとのコンポーネント
  hooks/          # カスタムフック群
  pages/          # Next.jsならここにページ
  utils/          # 汎用関数

「どこに何があるか」が明確になれば、チーム内の認識も統一されます。

テストしやすい構成にする
UIとロジックを分けておくと、ロジック部分のユニットテストがしやすくなります。
また、React Testing Library を使えば、ユーザー目線での動作検証も可能です。

ドキュメントを軽くでも残す
・コンポーネントの使い方（propsの説明）
・ディレクトリ構成の意図
・状態管理のフロー

…などを、READMEやコード内コメントに軽くでも書いておくと、後任の開発者が助かります。

■おわりに
React開発はスピードが命ですが、その裏には設計と構造の積み重ねが必要です。
特に、チーム開発や中長期プロジェクトでは、「早く作る」よりも「壊れにくく育てられる」設計が重要になります。
今回ご紹介した原則や考え方が、あなたのReactプロジェクトの設計改善・持続性向上のヒントになれば嬉しいです！

// ❌ 悪い例：1つのコンポーネントがなんでもやっている
const UserCard = () => {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetchUser().then(setUser);
  }, []);

  return <div>{user?.name}</div>;
};

// データ取得だけを担うコンテナ
const UserCardContainer = () => {
  const user = useUser(); // カスタムフックで取得
  return <UserCard user={user} />;
};

// UI表示だけを担うプレゼンテーションコンポーネント
const UserCard = ({ user }) => (
  <div>{user.name}</div>
);

// よく使うボタンコンポーネント
const Button = ({ children, onClick, variant = 'primary' }) => {
  const className = variant === 'primary' ? 'btn-primary' : 'btn-secondary';
  return <button className={className} onClick={onClick}>{children}</button>;
};

type Props = {
  user: {
    id: number;
    name: string;
  };
};

const UserCard: React.FC<Props> = ({ user }) => (
  <div>{user.name}</div>
);

src/
  components/     # UIパーツ群
    common/       # Buttonなどの汎用コンポーネント
    layout/       # Header / Footerなど
    features/     # 機能ごとのコンポーネント
  hooks/          # カスタムフック群
  pages/          # Next.jsならここにページ
  utils/          # 汎用関数