なぜ今フレームワーク選定を語るのか
Javaのサーバーサイド開発は、長らく Struts が事実上の標準でした。その結果、いまも多くの業務システムがStrutsベースで稼働しています。 一方でStrutsは新規開発で選ばれることがほぼなくなり、保守・刷新の対象として語られる存在になりました。
つまり中級者が直面する選定は、大きく2つの文脈に分かれます。ひとつは 新規構築で何を選ぶか、もうひとつは レガシー（Struts）からどこへ、どう移るか です。 本シリーズはこの両方に答えることをゴールとします。
💡 選定ミスのコストは後から効く
フレームワークの選定は、学習コスト・保守コスト・採用（人材確保）・スケール余地に長期にわたって影響します。「とりあえず動く」で選ぶと、数年後に技術的負債として跳ね返ります。だからこそ 評価軸を言語化してから 選ぶことが重要です。
本シリーズの想定読者
本シリーズは 実務経験のある中級者 を想定しています。具体的には次のような方です。
- Javaでの開発経験があり、MVC・DI・テンプレートエンジンといった用語の説明は不要な方
- 既存のStrutsシステムの保守や刷新を任されている、あるいはこれから関わる方
- 新規プロジェクトの技術選定を検討する立場（リード・アーキテクト含む）の方
そのため各フレームワークの「入門的な紹介」は最小限にとどめ、設計思想・移行コスト・実務での判断材料に紙幅を割きます。
本記事における「フルスタック」の定義
「フルスタック」という言葉は文脈で意味が変わります。本シリーズでは、比較が崩れないよう次のように定義を固定します。
フルスタック構成では、フレームワーク選定とあわせて テンプレートエンジン の選択も論点になります。代表的なものを整理しておきます。
| テンプレート | 立ち位置 | 備考 |
|---|---|---|
| Thymeleaf | 現在のフルスタックJavaの主流 | 素のHTMLとして表示でき、デザイナーとの協業がしやすい。Spring と相性が良い。 |
| JSP | レガシー構成で多用 | Struts や古い構成で広く使われた。新規では非推奨の流れ。 |
| JSF（Facelets） | 標準仕様ベース | Jakarta EE のコンポーネント指向。状態を持つUI向き。 |
| その他 | Mustache / FreeMarker / Qute 等 | 軽量・用途特化。Quarkus は Qute を持つ。 |
扱うフレームワークとシリーズ構成
本シリーズでは、Struts をレガシーの代表＝「なぜ移行が必要か」を示す引き合いとして位置づけ、移行先・新規構築の候補として Spring Boot を本命に、Quarkus / Micronaut / Jakarta EE（JSF）を比較します。全7回の構成は次のとおりです。
| 回 | テーマ |
|---|---|
| PART 01 | はじめに — 前提と「フルスタック」の定義（本記事） |
| PART 02 | レガシーの象徴としての Struts — なぜ移行が必要か |
| PART 03 | 選定の評価軸 — 中級者のための8つの実務軸 |
| PART 04 | 新世代フレームワークの選択肢 — Spring Boot / Quarkus / Micronaut / Jakarta EE |
| PART 05 | 比較 — Struts vs 新世代（評価軸マトリクス） |
| PART 06 | Struts からの移行戦略 |
| PART 07 | 意思決定フローとまとめ |
✅ 次の章では…
PART 02 では、本シリーズの論点の起点となる Struts を取り上げます。なぜ新規開発で選ばれなくなったのか、EOL（サポート終了）の状況と重大な脆弱性の歴史、そして設計思想の観点から「時代が変わった」ことを整理します。