コンポーネントを「分けすぎない」判断基準
― 分割は“設計判断”であって作法ではない ―
はじめに
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 のときだけ、
コンポーネントを分ければいい。
実務では、
分けない勇気も立派な設計判断です。
この記事の最新差分を見る
| 削除: ― 分割は正義ではない、という実務の話 ― | |
| 削除: はじめに（この記事で何がわかるか） | |
| 追加: ― 分割は“設計判断”であって作法ではない ― | |
| 追加: はじめに | |
| 追加: React や Vue を使った開発を続けていると、誰もが一度はこう悩みます。 | |
| 追加: ・このコンポーネント、もう少し分けた方がいいのでは？・責務が多そうだから切り出したけど、逆に読みにくくなった・コンポーネントの粒度に、正解がある気がして迷い続けている | |
| 追加: この悩みの厄介なところは、lint でもフレームワークでも答えが出ない点です。 | |
| 追加: コンポーネント分割は、技術問題ではなく設計者の判断そのものだからです。 | |
| 追加: この記事では「コンポーネントを分けるべきか迷ったときに、自分に問いかける判断基準」を、実務の失敗と違和感ベースで言語化します。 | |
| 追加: “きれいに分ける”話ではありません。「あとから触る自分が楽かどうか」 を基準に考えていきます。 | |
| 追加: 前提：分割＝正義、ではない | |
| 追加: まず、はっきりさせておきたい前提があります。 | |
| 追加: コンポーネントは、分ければ分けるほど良いわけではありません。 | |
| 追加: 責務分離、再利用性、テスト容易性。これらは確かに重要です。 | |
| 追加: ただし、これらを“理想論として”追いすぎると、次のような状態に陥りやすくなります。 | |
| 追加: ・ファイルが増えすぎて全体像が見えない・画面を直したいだけなのに、複数ファイルを行き来する・props の受け渡しが増え、状態の流れが追えない・「どこを直せばいいのか」が分からない | |
| 追加: 実務では、一番よく変更される単位で、理解しやすいことの方が、圧倒的に重要です。 | |
| 追加: 分割は目的ではなく、変更しやすくするための“手段”に過ぎません。 | |
| 追加: よくある「分けすぎ」の失敗パターン | |
| 削除: フロントエンド開発を続けていると、必ず一度はこう悩みます。 | 追加: まずは、現場でよく見る分けすぎパターンを整理します。 |
| 削除: 「このコンポーネント、もっと分けた方がいいのでは？」「でも、分けた結果わかりにくくなっている気もする……」 | |
| 削除: コンポーネント設計には多くの“正論”があります。しかし実務では、その正論どおりにやった結果、保守しづらいコードが生まれることも少なくありません。 | |
| 削除: この記事では「あえて分けない」という判断をどうやって下すかその思考プロセスを言語化します。 | |
| 削除: 設計に迷ったとき、「なぜ今回は分けなかったのか」を説明できる状態になることがゴールです。 | |
| 削除: 背景・前提条件 | |
| 追加: 見た目だけで分けてしまう | |
| 追加: 例えば、こんな分割です。 | |
| 追加: ・タイトル用コンポーネント・説明文用コンポーネント・ボタン用コンポーネント | |
| 追加: 一見すると整理されていて、きれいに見えます。 | |
| 追加: しかし、それらがその画面でしか使われない 場合、分割のメリットはほとんどありません。 | |
| 追加: むしろ、 | |
| 追加: ・JSX の流れが分断される・画面構造が頭に入りづらくなる・変更時に複数ファイルを開く必要が出る | |
| 追加: というデメリットの方が勝ちます。 | |
| 追加: UI部品だからという理由だけで即コンポーネント化するのは、一度立ち止まって考えた方がいい判断です。 | |
| 追加: 「将来使いそう」で分ける | |
| 追加: 設計時によく聞く言葉があります。 | |
| 追加: 「あとで別の画面でも使うかもしれない」 | |
| 追加: 正直に言うと、この“かもしれない”は、ほとんど実現しません。 | |
| 追加: ・別画面では微妙に仕様が違う・結局 props が増えて汎用性が崩れる・最終的に作り直す | |
| 追加: 実務で再利用されるコンポーネントは、最初から再利用目的で生まれることの方が少ないという印象があります。 | |
| 追加: 再利用は「狙うもの」ではなく、結果として生まれるものです。 | |
| 追加: 責務分解をやりすぎる | |
| 追加: 設計思想としては正しそうでも、やりすぎると逆効果になるケースもあります。 | |
| 追加: ・表示専用・ロジック専用・データ整形専用・バリデーション専用 | |
| 追加: 理論的には美しいですが、実装レベルでは「追いづらさ」が勝ちます。 | |
| 追加: 特に中小規模の画面では、1ファイルを読めば全体が分かるという状態の方が、圧倒的にメンテナンスしやすいです。 | |
| 追加: 分ける前に自分に問いかける5つの質問 | |
| 追加: ここからが本題です。分割で迷ったとき、私が実際に自分に投げている質問を紹介します。 | |
| 追加: 質問①：このコンポーネントは単独で意味を持つか？ | |
| 追加: 分ける価値があるのは、それ単体で役割を説明できるものです。 | |
| 追加: 例えば、 | |
| 追加: ・モーダル・日付選択・ページネーション・ユーザーアバター | |
| 削除: 本記事は、以下のような前提で書いています。 | 追加: これらは、画面名がなくても説明できます。 |
| 削除: React / Vue などのコンポーネント指向UI | |
| 削除: 実務の中〜大規模プロジェクト | |
| 削除: 数ヶ月〜数年運用されるコードベース | |
| 削除: 自分以外の人も触る前提 | |
| 削除: 個人開発や短命なプロジェクトでは、もう少し割り切った判断も成立します。 | |
| 削除: なぜ「分けすぎ問題」が起きるのか | |
| 削除: 多くの場合、原因は技術力不足ではありません。 | |
| 削除: コンポーネントは小さく | |
| 削除: 責務は単一に | |
| 削除: 再利用できる形で | |
| 削除: これらはすべて「正しい教え」です。ただし、文脈を無視して適用すると事故が起きます。 | |
| 追加: 一方で、 | |
| 追加: ・この画面専用のタイトル・このフォーム用の説明文 | |
| 追加: といったものは、単独では意味を持ちません。 | |
| 追加: 「これは何をするコンポーネント？」と聞かれて、画面名なしで説明できないなら、無理に分けない方が自然です。 | |
| 追加: 質問②：この分割は変更に強くなるか？ | |
| 追加: 分割の最大の目的は、ここです。 | |
| 追加: ・変更時の影響範囲が狭くなるか・修正箇所がすぐ特定できるか | |
| 追加: もし分けた結果、 | |
| 追加: ・props が増えた・親コンポーネントが複雑になった・状態の流れが追いづらくなった | |
| 追加: のであれば、それは変更に弱くなっている可能性があります。 | |
| 追加: きれいに見えても、修正が怖くなる設計は良い設計とは言えません。 | |
| 追加: 質問③：props を言葉で説明できるか？ | |
| 追加: props が増え始めたら、黄色信号です。 | |
| 追加: 例えば、 | |
| 追加: valuesetValueisErrorerrorMessageonBlur | |
| 追加: こうした props を見て、「なぜこれを親が持っているのか」「なぜこの責務が子にあるのか」を説明できるでしょうか。 | |
| 追加: props の数そのものよりも、説明のしづらさに注目すると、判断しやすくなります。 | |
| 追加: 質問④：JSX の流れは自然か？ | |
| 追加: 分割後の JSX を、上から読んでみてください。 | |
| 追加: 画面構造が、頭の中に自然に入ってくるでしょうか。 | |
| 追加: もし、 | |
| 追加: 「実体を見るためにファイルを開かないと分からない」と感じるなら、分けすぎのサインです。 | |
| 追加: JSX は単なる記述ではなく、画面の設計図そのものです。 | |
| 追加: 流れが読めなくなった時点で、設計としては本末転倒です。 | |
| 追加: 質問⑤：今、本当に困っているか？ | |
| 追加: 最後は、とてもシンプルな問いです。 | |
| 追加: 「今、この分割がないと困るか？」 | |
| 追加: ・同じ処理が何度も出てきている・変更頻度が高く、影響範囲が広い・テストが書きづらい | |
| 追加: こうした具体的な痛みがないなら、無理に分ける必要はありません。 | |
| 追加: 困ってから分けても、遅くはありません。 | |
| 追加: 実務でおすすめの進め方 | |
| 追加: まずは大きめに作る | |
| 追加: ・1ファイルで完結・ロジックとUIが同じ場所・読めば全体が分かる | |
| 削除: 結果として、こんな状態になります。 | 追加: まずはこの状態を作ります。 |
| 削除: ファイル数が異常に多い | |
| 追加: 違和感が出たら切り出す | |
| 追加: ・同じ処理が増えてきた・ここだけ変更が多い・テストしたくなった | |
| 追加: この「違和感」は、設計改善のサインです。 | |
| 削除: 親 → 子 → 孫 → 曾孫まで追わないと処理が読めない | 追加: 分割理由を言語化できないなら分けない |
| 削除: props が中継され続けている | |
| 削除: 変更時に「どこを直せばいいのか」即座に判断できない | |
| 削除: これは設計が細かすぎるのではなく、判断基準が言語化されていないことが問題です。 | |
| 削除: 判断基準①：その部品は「一緒に変更され続けるか」 | |
| 削除: 最も重要な基準です。 | |
| 削除: 表示仕様を変えると、必ずロジックも変わる | |
| 削除: 文言修正と挙動修正がセットで発生する | |
| 削除: 将来も同時に変更される可能性が高い | |
| 削除: この関係にあるなら、分けない方が安全です。 | |
| 削除: 「将来再利用できそうだから」は理由として弱く、「将来も一緒に変更されるかどうか」の方がはるかに重要です。 | |
| 削除: 再利用“できる”より、再利用“される”かで考えます。 | |
| 削除: 判断基準②：名前を自然に付けられるか | |
| 削除: 分割を検討するとき、コンポーネント名を考えてみてください。 | |
| 削除: 名前が長くなる | |
| 削除: 説明的すぎる | |
| 削除: しっくりこない | |
| 削除: こう感じた場合、まだ意味のある単位になっていない可能性が高いです。 | |
| 削除: 「行数が多いから」「JSXがゴチャっとしてきたから」 | |
| 削除: この理由だけでの分割は、あとで読む人に負債を残すことが多いです。 | |
| 削除: 判断基準③：UIとロジックは本当に独立しているか | |
| 削除: 理屈の上では分離できても、実際には強く結びついているケースがあります。 | |
| 削除: 表示条件がビジネスロジックに依存している | |
| 削除: UI変更が状態管理に直結する | |
| 削除: props が増え続ける未来が見える | |
| 削除: この場合、分割によって可読性が下がることも珍しくありません。 | |
| 削除: 分けることで理解しやすくなるか、分けることで追跡コストが上がるか。 | |
| 削除: ここを冷静に見ます。 | |
| 削除: 「分けすぎたコード」が生む実務的な痛み | |
| 削除: 実際の現場では、こんな声をよく聞きます。 | |
| 削除: 「この画面、どこから読めばいいの？」 | |
| 削除: 「結局この画面で何をしてるの？」 | |
| 削除: 「修正したら別の画面が壊れた」 | |
| 削除: これらはバグではなく、構造が把握しづらいことによる問題です。 | |
| 削除: 特にレビューや引き継ぎの場面で、「一目で全体像が見えない」コードは致命的です。 | |
| 削除: あえて「まとめる」という設計判断 | |
| 削除: 画面専用で、再利用されないことが分かっているなら、あえて1ファイルにまとめる判断は十分アリです。 | |
| 削除: 開けば処理の流れが分かる | |
| 削除: UIとロジックの関係が明確 | |
| 削除: 修正時にファイル移動が不要 | |
| 削除: これは“雑”なのではなく、将来の保守を見据えた合理的な選択です。 | |
| 削除: 実務で意識しているマインドセット | |
| 削除: 最初から最適解を出そうとしない | |
| 削除: 分けるのは「必要になった瞬間」でいい | |
| 削除: 設計は固定ではなく、成長させるもの | |
| 削除: 設計において重要なのは、「今のフェーズで何が一番読みやすいか」です。 | |
| 削除: 将来の可能性を考えすぎて、現在の可読性を犠牲にしないようにします。 | |
| 追加: ・なんとなく・きれいだから・よく見る構成だから | |
| 追加: これらは、設計理由にはなりません。 | |
| 変更なし: まとめ | 変更なし: まとめ |
| 削除: コンポーネント分割は目的ではない | |
| 削除: 一緒に変更されるものは一緒に置く | |
| 削除: 名前が付けにくい分割は疑う | |
| 削除: 将来より「今の保守性」を優先する判断も正解 | |
| 追加: コンポーネント設計で大事なのは、どれだけ細かく分けられるかではありません。 | |
| 追加: ・変更しやすいか・読みやすいか・今の規模、今のチームに合っているか | |
| 追加: です。 | |
| 削除: 分ける・分けないは感覚論ではなく、説明できる判断基準を持つことが重要です。 | 追加: 分けるか迷ったときは、こう問いかけてみてください。 |
| 削除: この記事が、「今回は分けなかった理由」を自信を持って説明できる助けになれば嬉しいです。 | |
| 追加: 「この分割は、未来の自分を助けるだろうか？」 | |
| 追加: その答えが Yes のときだけ、コンポーネントを分ければいい。 | |
| 追加: 実務では、分けない勇気も立派な設計判断です。 |
この記事は役に立ちましたか？