毎回似たような質問を受けて似たような説明を繰り返すうちに、いっそフローチャートにしてしまおうと思い立ちました。新規か移行かで分岐させるだけでも、意思決定はかなり楽になります。
意思決定フロー
図1: プロジェクト特性に応じた選定フローチャート
選定は「新規か、既存（Struts）保守か」を起点に分岐させると整理しやすくなります。
Q1. 新規開発か、既存 Struts の保守・刷新か？
新規 → Q2 へ
既存 Struts → Q3 へ
▼
Q2.（新規）起動速度・低メモリが要件として明確か？
いいえ → Spring Boot ＋ Thymeleaf（基本線）
はい → Quarkus / Micronaut を検討
▼
Q3.（既存）EOL バージョンを使っている／インターネットに面しているか？
はい → 優先度「高」。段階移行（→ Spring Boot）を計画化
いいえ → サポート対象へ更新しつつ移行を計画
▼
Q4.（移行）規模は大きく、稼働を止められないか？
はい → 段階移行（ストラングラー）
いいえ・小規模 → 全面刷新も可
ユースケース別のおすすめ
| ケース | おすすめ | 理由 |
|---|---|---|
| 新規フルスタック開発 | Spring Boot ＋ Thymeleaf | 総合力・エコシステム・人材すべてが厚い。迷ったらこれ。 |
| レガシー（Struts）の刷新 | 段階移行 → Spring Boot | 移行先として情報・実績が最多。共存しやすい。 |
| 軽量・高速起動・サーバーレス | Quarkus / Micronaut | 起動速度・メモリ効率に優れる。性能要件が明確な場合。 |
| 標準仕様・既存EE資産あり | Jakarta EE / JSF | ベンダー非依存。既存資産を活かせる。 |
選定チェックリスト
- 評価軸（8つ）に重みをつけ、プロジェクト文脈に合わせたか
- サポート継続性（LTS / EOL）を足切り条件として確認したか
- 既存 Struts が EOL バージョンでないか、脆弱性の影響を受けないか確認したか
- 移行は段階か全面か、規模とリスクから判断したか
- 移行前に挙動を固定する自動テスト（安全網）を用意したか
- 共存期間の期限とマイルストーンを決めたか
- 人材確保・引き継ぎのしやすさを考慮したか
まとめ：実践的な結論
フルスタックJavaのフレームワーク選定は、突き詰めるとシンプルな結論に収れんします。
💡 結論
① 新規開発なら Spring Boot ＋ Thymeleaf が基本線。特別な性能要件があるときだけ Quarkus / Micronaut を検討する。
② Struts は新規非推奨。既存資産は「危険だから今すぐ全部捨てる」でも「動いているから放置」でもなく、計画的な移行対象として捉える。
③ 移行は 段階移行（ストラングラー）＋安全網（テスト）を基本とし、共存は期限を切る。
重要なのは、Struts を悪者にすることではなく、評価軸に照らして自分のプロジェクト文脈で根拠を持って選ぶことです。本シリーズがその判断の土台になれば幸いです。
意思決定フローでよくある落とし穴
フレームワーク選定の議論が迷走するパターンには共通の原因がある。最後に整理しておく。
| 落とし穴 | 何が起きるか | 対処法 |
|---|---|---|
| 「とりあえず Spring Boot」で根拠なく決める | チームに Spring の知識がなく、習熟コストがプロジェクト序盤に集中して遅延が発生する | 選定理由を ADR に残し、学習コスト・習熟期間の計画を合わせて立てる |
| 移行を「いつかやる」で先送りする | Struts の脆弱性リスクが放置されたまま、担当者が変わるたびに「現状維持」が繰り返される | EOL・脆弱性スコアを材料に移行計画を提案し、期限とマイルストーンを確定する |
| 技術的優位性だけで決める | 採用市場・チームの既存スキルを考慮せず、エンジニアの確保・育成が困難なフレームワークを選んでしまう | ⑦人材確保の軸を意識し、求人市場や社内の既存スキルセットを確認してから決定する |