― 分割は“設計判断”であって作法ではない ―
はじめに
React や Vue を使った開発を続けていると、
誰もが一度はこう悩みます。
・このコンポーネント、もう少し分けた方がいいのでは？
・責務が多そうだから切り出したけど、逆に読みにくくなった
・コンポーネントの粒度に、正解がある気がして迷い続けている
この悩みの厄介なところは、
lint でもフレームワークでも答えが出ない点です。
コンポーネント分割は、技術問題ではなく
設計者の判断そのものだからです。
この記事では
「コンポーネントを分けるべきか迷ったときに、自分に問いかける判断基準」
を、実務の失敗と違和感ベースで言語化します。
“きれいに分ける”話ではありません。
「あとから触る自分が楽かどうか」 を基準に考えていきます。
前提：分割＝正義、ではない
まず、はっきりさせておきたい前提があります。
コンポーネントは、分ければ分けるほど良いわけではありません。
責務分離、再利用性、テスト容易性。
これらは確かに重要です。
ただし、これらを“理想論として”追いすぎると、
次のような状態に陥りやすくなります。
・ファイルが増えすぎて全体像が見えない
・画面を直したいだけなのに、複数ファイルを行き来する
・props の受け渡しが増え、状態の流れが追えない
・「どこを直せばいいのか」が分からない
実務では、
一番よく変更される単位で、理解しやすいこと
の方が、圧倒的に重要です。
分割は目的ではなく、
変更しやすくするための“手段”に過ぎません。
よくある「分けすぎ」の失敗パターン
まずは、現場でよく見る分けすぎパターンを整理します。
見た目だけで分けてしまう
例えば、こんな分割です。
・タイトル用コンポーネント
・説明文用コンポーネント
・ボタン用コンポーネント
一見すると整理されていて、きれいに見えます。
しかし、それらが
その画面でしか使われない 場合、
分割のメリットはほとんどありません。
むしろ、
・JSX の流れが分断される
・画面構造が頭に入りづらくなる
・変更時に複数ファイルを開く必要が出る
というデメリットの方が勝ちます。
UI部品だからという理由だけで
即コンポーネント化するのは、
一度立ち止まって考えた方がいい判断です。
「将来使いそう」で分ける
設計時によく聞く言葉があります。
「あとで別の画面でも使うかもしれない」
正直に言うと、
この“かもしれない”は、ほとんど実現しません。
・別画面では微妙に仕様が違う
・結局 props が増えて汎用性が崩れる
・最終的に作り直す
実務で再利用されるコンポーネントは、
最初から再利用目的で生まれることの方が少ない
という印象があります。
再利用は「狙うもの」ではなく、
結果として生まれるものです。
責務分解をやりすぎる
設計思想としては正しそうでも、
やりすぎると逆効果になるケースもあります。
・表示専用
・ロジック専用
・データ整形専用
・バリデーション専用
理論的には美しいですが、
実装レベルでは「追いづらさ」が勝ちます。
特に中小規模の画面では、
1ファイルを読めば全体が分かる
という状態の方が、圧倒的にメンテナンスしやすいです。
分ける前に自分に問いかける5つの質問
ここからが本題です。
分割で迷ったとき、私が実際に自分に投げている質問を紹介します。
質問①：このコンポーネントは単独で意味を持つか？
分ける価値があるのは、
それ単体で役割を説明できるものです。
例えば、
・モーダル
・日付選択
・ページネーション
・ユーザーアバター
これらは、画面名がなくても説明できます。
一方で、
・この画面専用のタイトル
・このフォーム用の説明文
といったものは、単独では意味を持ちません。
「これは何をするコンポーネント？」
と聞かれて、
画面名なしで説明できないなら、
無理に分けない方が自然です。
質問②：この分割は変更に強くなるか？
分割の最大の目的は、ここです。
・変更時の影響範囲が狭くなるか
・修正箇所がすぐ特定できるか
もし分けた結果、
・props が増えた
・親コンポーネントが複雑になった
・状態の流れが追いづらくなった
のであれば、
それは変更に弱くなっている可能性があります。
きれいに見えても、
修正が怖くなる設計は良い設計とは言えません。
質問③：props を言葉で説明できるか？
props が増え始めたら、黄色信号です。
例えば、
value
setValue
isError
errorMessage
onBlur
こうした props を見て、
「なぜこれを親が持っているのか」
「なぜこの責務が子にあるのか」
を説明できるでしょうか。
props の数そのものよりも、
説明のしづらさに注目すると、判断しやすくなります。
質問④：JSX の流れは自然か？
分割後の JSX を、上から読んでみてください。
画面構造が、頭の中に自然に入ってくるでしょうか。
もし、
「実体を見るためにファイルを開かないと分からない」
と感じるなら、分けすぎのサインです。
JSX は単なる記述ではなく、
画面の設計図そのものです。
流れが読めなくなった時点で、
設計としては本末転倒です。
質問⑤：今、本当に困っているか？
最後は、とてもシンプルな問いです。
「今、この分割がないと困るか？」
・同じ処理が何度も出てきている
・変更頻度が高く、影響範囲が広い
・テストが書きづらい
こうした具体的な痛みがないなら、
無理に分ける必要はありません。
困ってから分けても、遅くはありません。
実務でおすすめの進め方
まずは大きめに作る
・1ファイルで完結
・ロジックとUIが同じ場所
・読めば全体が分かる
まずはこの状態を作ります。
違和感が出たら切り出す
・同じ処理が増えてきた
・ここだけ変更が多い
・テストしたくなった
この「違和感」は、
設計改善のサインです。
分割理由を言語化できないなら分けない
・なんとなく
・きれいだから
・よく見る構成だから
これらは、設計理由にはなりません。
まとめ
コンポーネント設計で大事なのは、
どれだけ細かく分けられるかではありません。
・変更しやすいか
・読みやすいか
・今の規模、今のチームに合っているか
です。
分けるか迷ったときは、こう問いかけてみてください。
「この分割は、未来の自分を助けるだろうか？」
その答えが Yes のときだけ、
コンポーネントを分ければいい。
実務では、
分けない勇気も立派な設計判断です。
