The following two tabs change content below.
アバター画像

メンバー

福岡市博多区でWebシステム開発の受託・ラボ型SES・web集客サービス、３つのWebサービスを提供中

フロントエンド開発は、コンフォートゾーンに留まり続けたいエンジニアにとっては、

・ストレスがかかり

・不安を煽られ

・パニックに陥る

そんなポジションかもしれません。

その理由は、最新のツールが次々に登場するため、常に学習が求められるからです。

そんな社会・市場の変化についていけない方は、Web系のフロントエンド開発に向いてません。

業務外の時間を活用して学ぶことがきつい方は、早めにあきらめて、竜宮城のような場所から決して出ないように、チャレンジと無縁の環境で「ゆっくりと快適な毎日」をお過ごしください。

コンフォートゾーンとは、居心地が良く不安を感じない状態ですね。

例えば、茹でガエルの話が有名ですね。カエルは、ゆっくりぬるま湯の温度を上げられると居心地が良く気づかない、そして気づいたときには熱湯になっているが、もう動けない…最後は沸騰して幸せに〇ぬ。

人の本質は

「変わりたくない」

「変えられたくない」

というコンフォートゾーンを求めている、と言われています。

そして、いつの時代も社会から高評価・高年収な人の考え方の共通点は、

人の本質とは真逆で、

皮肉にも「成長」「変化」「進化」といったラーニングゾーンを求めている、と言われています。

この記事では、「成長・変化・進化したい」ラーニングゾーンを求めるエンジニアさんに向けて、現在のweb系アプリのフロントエンド開発における主要な

・フレームワーク

・ライブラリの特徴

・TypeScriptとの関係

・実際の開発現場での使い分け

について、私自身の拙い経験を交えながらお伝えします。

あなたが今いる場所が、ぬるま湯に浸かった茹でガエルのようなコンフォートゾーンだとしたら危機感を持たれているはずです。

もし、あなたが一歩踏み出し、ラーニングゾーンへ身を置きたいのなら、web系のフロントエンド開発ツールを学ぶ、この成長の機会を逃さないようにされてください。

フレームワークとライブラリの違い

大前提ですが、「フレームワーク」と「ライブラリ」の違いを認識できていない人が非常に多い気がしますので、解説します。

フレームワークとは

「フレームワーク」とは、アプリケーション開発の枠組み(機能全体)を提供する土台ですね。

車の場合、エンジン、タイヤ、ハンドル、椅子、アクセル、ブレーキ、ライトなどが揃って動きますが、その全体の仕組みのことがフレームワークですね。

例えば、セダン、F1、4WD、スポーツカー、ワゴン、トラック、バスなどのフレームワークがありますね。各フレームワークで部品の形や大きさや強さが変わりますから、スポーツカーを作る車工場(フレームワーク)を使用するとスポーツカーが作りやすいということですね。

どのフレームワークを使うか？の選定は、そもそもどんな車を必要としているのか？という目的に合わせて選定すればよいだけです。

「このフレームワーク(車生産工場)について、学びたい！身に付けたい！」という手段が目的化している方がたまにいますが、

「こんなシステム(車)を作りたいけど、どんなフレームワーク(車生産工場)を選定してUI開発をしたらよいのか？」

「トラック工場の仕事が学びたい！身に付けたい！」ではなく、

「大きなモノを運ぶ車を作りたいけど、どんな工場(いすゞ、HINO、トヨタ、マツダなど)を選定したらよいのか？」と考えて車を作る、という考え方をすると「フレームワークとは？」について理解できるのではないでしょうか？

そして、あなたの目的にピッタリな大きなモノが運べる車を納品しやすくなるはずです。何回か使って慣れればの話です。

ライブラリとは

「ライブラリ」とは、アプリケーション開発で簡単に活用できるコード(部品)の集まりです。

車の部品でいうと、タイヤはホイールやネジなど部品の集まりで作られています。

エンジンも、金属や電気を通すいくつもの部品が集まっています。

ライトも電球や導線やガラスやプラスチックの部品で作られていますよね。

この部品の集まりがライブラリです。

この前提を抑えて、web系のUI開発(フロントエンド)に使用する「フレームワークやライブラリ」の解説をご確認ください。

フロントエンド開発ツール3選

フロントエンド開発ツールは、以下のような要素が重視されています：

  • コンポーネント志向: 再利用可能なパーツでUIを組み立てる考え方
  • 状態管理の明確化: データの流れと変化を追跡しやすくする仕組み
  • ビルドプロセスの統合: 開発と本番環境を分離し最適化する工夫
  • 型システムとの相性: 安全性と開発効率を高めるための型付け

こうした要素は、「速く作る」から「安全に、長く使えるものを作る」という価値観のシフトを反映しているようにも思います。

各フレームワークとライブラリの特徴

1. React

特徴:

  • 仮想DOMによる効率的な画面更新
  • JSXによる宣言的なUI構築
  • 関数型プログラミングの考え方を取り入れた設計

メリット:

  • 豊富なエコシステムと情報源の多さ
  • 大規模アプリケーションでも破綻しにくい設計思想
  • コンポーネントの再利用性の高さ

デメリット:

  • 初学者には概念理解のハードルが高い
  • 小規模プロジェクトではオーバースペックになりがち
  • ボイラープレートコードが多くなる傾向

React学習中に、「Hooksって何だ？」と悩んで夜を明かしたことも懐かしい思い出です。しかし、概念が腹落ちしたとき、コードの見え方が一変する体験は何物にも代えがたいものでした。

jQueryからの移行は、まるで自転車から宇宙船に乗り換えるような感覚でした。

2. Vue

特徴:

  • 直感的なテンプレート構文
  • 段階的な学習曲線
  • シングルファイルコンポーネント

メリット:

  • HTMLに近い構文で学習しやすい
  • 公式ドキュメントの質の高さ
  • 必要な機能が標準で揃っている安心感

デメリット:

  • 大規模アプリケーションでの設計パターンがやや不明確
  • Reactと比べて求人市場が限定的
  • オプションAPIとComposition APIの使い分けが悩ましい

あるプロジェクトでは、HTML/CSSに詳しいがJavaScriptの経験が浅いデザイナーと協業する機会がありました。

Vueを採用したことで、「template」部分はデザイナーが、「script」部分はエンジニアが担当するという自然な分業が可能になり、コミュニケーションコストが驚くほど下がりました。

3. Svelte

特徴:

  • コンパイル時に最適化され、ランタイムライブラリが最小限
  • 直感的な反応性システム
  • 標準的なHTMLに近い書き方

メリット:

  • 少ないコード量で同等の機能を実現できる爽快感
  • 優れた初期表示パフォーマンス
  • 学習コストの低さ

デメリット:

  • コミュニティと情報量がまだ発展途上
  • 大規模プロジェクトでの実績例が少ない
  • サードパーティライブラリの選択肢の制限

初めてSvelteでアプリを作ったときは、コード量の少なさに目を疑いました。「これで本当に動くの？」と思いながらビルドしたアプリが、軽快に動作したときの驚きは今でも忘れられません。

TypeScriptとの相性

React + TypeScript: 公式で強力にサポートされており、コンポーネントのprops型定義が直感的です。ただ、高度なジェネリック型などを活用する場合は学習コストがかかります。あるプロジェクトでは、型定義のおかげでコンポーネント間のデータの受け渡しミスが激減し、「これが正しい使い方か」を確認するための無駄な問い合わせが減りました。

Vue + TypeScript: Vue 3からTypeScriptサポートが格段に向上しましたが、Vue 2時代は苦労した記憶があります。Composition APIを使うことで型の恩恵を最大限に受けられますが、Options APIでは型の恩恵を感じにくい部分もあります。

Svelte + TypeScript: 直感的な型定義が可能ですが、コンパイラの出すエラーメッセージがやや分かりづらいことがあります。シンプルな構造のため、基本的な型定義は簡単です。

パフォーマンスの比較

初期表示速度: Svelteが最も高速で、次いでVue、Reactという印象です。あるメディアサイトでは、同じデザインをSvelteとReactで実装比較したところ、初期表示が約35%速くなった経験があります。ただし、適切な最適化を施せばどのフレームワークでも十分な速度を出せることも事実です。

開発の快適さ: これは個人の好みによりますが、私の経験では

  • React: エコシステムの充実度で他を圧倒
  • Vue: 学習曲線とドキュメントの分かりやすさが魅力
  • Svelte: シンプルさと直感的な書き方が心地よい

デバッグのしやすさ: TypeScriptとの組み合わせでは、Reactが最も堅固なエラーメッセージを提供します。「あぁ、またうっかりundefinedアクセスしてしまった」という自分の凡ミスを、コンパイル時に教えてくれるのは本当にありがたいものです。

フレームワーク選定で最も大切にしないといけないことは、「どんなシステムを作るのか？目的から逆算した選定をする」という視点です。

顧客が

・どのような目的でシステムを導入し

・どのような基準で「導入してよかった」となり

・どのようなエンジニアと契約継続したいか

を想像すれば、フレームワークの選定で大切なことが「顧客の目的から逆算すること」だとわかると思います。

ということで、「安全に長く使えるもの」を導入して顧客が喜ぶ姿を想像しながら、以下のユースケース別おすすめフレームワーク、ライブラリをご確認ください。

ユースケース別おすすめフレームワーク

プロジェクトの規模や目的によって最適な選択肢は異なります。

小規模開発・学習目的

Vue.jsが最適です。学習曲線が緩やかで、初学者でも挫折しにくい設計になっています。5ページ程度のポートフォリオサイトを新人エンジニアと一緒に作ったとき、Vue.jsの採用で、彼は1週間で基本的な概念を理解して自走できるようになりました。

中規模サービス開発

React + TypeScriptの組み合わせが強力です。特に、複数人で開発する場合、型の恩恵が大きく出ます。あるチームプロジェクトでは、TypeScriptの導入により、「このコンポーネントには何を渡せばいいの？」という質問が劇的に減り、コミュニケーションコストが下がりました。

パフォーマンス重視のプロジェクト

Svelteを検討する価値があります。特に初期ロード時間が重要なメディアサイトやLP系では、その差が顕著に出ることがあります。私が担当したニュースサイトでは、ページ表示速度が改善されたことでSEOスコアも向上し、トラフィックが15%増加した例もあります。

大規模・長期運用プロジェクト

Reactのエコシステムと TypeScriptの組み合わせが安定感があります。数年前に立ち上げたプロジェクトが今も破綻なく拡張できているのは、この組み合わせの力だと実感しています。

TypeScriptが重要視される理由

早朝の緊急対応を減らせる: 実行前にバグを発見できる安心感

コードを書く人と読む人をつなぐ架け橋: 型がドキュメントの役割を果たす

リファクタリングに伴う恐怖を和らげる: 変更の影響範囲が明確になる

チーム開発での意思疎通を円滑に: データ構造の共通認識ができる

最後に

最適なフレームワーク選びに悩んでいる方へのアドバイスは、以下のようなものです：

顧客の目的から逆算して選定する。

web系システムUI開発が目的の顧客向けには、web系UI開発に適したフレームワークやライブラリの中から要件定義フェーズで規模や計画に合わせて選定していきましょう。

あなたは、どんなエンジニアになりたくて、どんなエンジニアになりたくないですか？

あなたの顧客は、どちらのエンジニアに高いお金を払い、どちらのエンジニアの単価を安く抑えたいと感じるでしょうか？

あなたが顧客の立場でエンジニアを選ぶ時、どちらのエンジニアに高い料金を継続して支払いたくなるのか？答えは明確ですよね。

でも、なぜか…

人の本質は、「ぬるま湯に浸かりたくて、茹でガエル」を求めています。

そして、皮肉にも社会から評価が高い人々の共通点は、その茹でガエルとは逆の、変化・進化・成長を求めている点です。

あなたがどちらになりたいか？次第ですね。

コンフォートゾーンからラーニングゾーンに主人公が一歩踏み出す「映画・人生」の方が、自分らしい！面白い！カッコイイ！応援したくなる！楽しそう！そう感じるエンジニアさんに、「フロントエンド開発ツール」のスキル向上をオススメします。

私も日々勉強の身ではありますが、この記事が皆様の一助となれば幸いです。

お互い学び、「成長痛」になったら「プロテインを補給」して大きく強くなるアスリートのように、エンジニアとして変化・進化・成長率にこだわる生き方が楽しい！そう感じる方は、この機会に、ご応募お待ちしています！