近年Webの界隈ではコンポーネントというフレーズを良く聞きます。
フロントエンドで言えばReact.jsやAngular.js、サーバサイドで言えばJavaのフレームワークであるJSFなんかがそうですね。
また、コーディング関係だけではなく、デザインでもこれからはコンポーネント化だ！なんて言われてたりもします。
ではコンポーネントとは一体何なのか。。。
簡単に言ってしまえば特定の機能を果たす単位、いわゆる部品ですね。
そして、その部品は一箇所限りでしか使用できないようにしてしまうと効率が悪いので、
色々な箇所で使えるように再利用可能な作りにします。
そういう意味だと、プログラムのクラスとかメソッドもコンポーネント？
という風に思われるかもしれませんが、
コンポーネントは一つのプロジェクトの中で再利用できるだけではなく、
より広く様々なプロジェクトで汎用的に利用できるものを特に指します。
（Reactとかで自分でコンポーネントを定義する場合はそのプロジェクトの中でしか使えないけどねｗ）
例えばBootstrapのcssを想像してください。
フラットUIで今や多くのサイトで使われていますね。
デザインの段階でボタンを設置する必要があり、Bootstrapのボタンを使おうとしたとします。
そんな時はどのボタンを使おうかBootstrapのボタンのデザインの中から選択し、
あとはそれを当てはめるだけです。
こんな感じで他の要素もすでにあるデザインの中から必要なものだけを選びだし、
あとは組み立てるだけの作業になります。
この時、選び出した要素をコンポーネント化した部品と捉えればメリットがわかるのではないでしょうか。
要は先に部品だけ揃えてしまってあとは組み立てるだけにしてしまえば、
メンテナンスが容易になり、品質が揃えやすくなるのです。
また、オリジナルの要素（部品）を使わずにすでに存在している要素を使うとなれば、
要素を作る工数が不要になるので、時間の短縮が図れるわけです。
サーバサイドのJSFで言えば、
ビューとクラスを部品と捉えればわかりやすいと思います。
JSFではまずビューを作り、そのビューに関連するクラスを別個で書くことができます。
通常であればURLを決めて、そのビューを表示するためのクラス（コントローラーとか）を書いて...
となるわけですが、そういった作業順を踏まなくてもそれぞれが実装に入れるため、
ビューという部品をフロントエンジニアが作り、クラスという部品をシステムエンジニアが作る。
といったように役割分担をして、場合によっては同時に作業ができるのです。
サーバサイドの人で言えば疎結合というキーワードを出せばわかりやすいですね。
これもメンテナンス性があがり、実装の時間短縮を図ることができるのです。
以上、メリットだけを挙げましたが、やはりデメリットもあります。
例えば部品化することで、その部品がどうやって作られているのか知ろうとする機会も時間もなくなるでしょう。
なので、何か緊急事態やバグが発生した場合に詳細な中身を知らないと、かえって復旧に時間を要する可能性があります。
また、上記の中で部品を組み立てればいいと簡単に言いましたが、
やはりどんな時も例外は出てきますよね。
例えばボタンのサイズが1箇所だけ別な大きさにする必要があったりとか...
そういう時に一手間加える必要があり、詳細な仕様を知らない分その一手間に時間を要することもあります。
結局どんな仕組みやフレームワークにもメリット・デメリットは必ずあるので、
そのプロジェクトの特性に合わせてその技術を採用すべきか検討してみてください。
