PART 03 — 選定の評価軸中級者のための8つの実務軸

評価軸を決めずにフレームワーク比較を始めると、結局「触ったことがある方」を選んでしまいがちです。無自覚なバイアスに気づいてから、先に評価軸を言語化してから比較する進め方に変えました。

なぜ先に軸を決めるのか

図1: 中級者向けフレームワーク選定評価軸マトリクス

フレームワーク比較は、軸を決めずに始めると「なんとなく好きな方」に流れます。中級者ほど特定技術への慣れがあるため、無自覚なバイアスがかかりやすい。そこで先に 評価軸を言語化 し、各候補を同じものさしで測ります。これにより、後で「なぜこれを選んだか」を説明できる選定になります。

💡 軸は「新規」と「移行」で共通に使える

本シリーズは新規構築と Struts からの移行の両方を扱いますが、評価軸は共通です。違うのは 各軸の重み だけ。移行案件では「移行コスト」の比重が跳ね上がる、といった具合に調整します。

本シリーズで用いる評価軸は次の8つです。

#	評価軸	見るポイント
1	開発生産性	定型作業の自動化、設定の少なさ、scaffolding、開発時のホットリロードなど。最初の一歩から本番までの速さ。
2	保守性・テスタビリティ	DI による疎結合、ユニットテストの書きやすさ、コードの見通し。長期運用で効いてくる。
3	エコシステム／ライブラリ	認証・DBアクセス・バッチ・メッセージングなど、周辺機能を公式・準公式で賄えるか。
4	学習・チーム習熟コスト	ドキュメントの質、日本語情報、チームが立ち上がるまでの時間。中級者の再学習負荷。
5	LTS・セキュリティ更新の継続性	サポート期間の明確さ、脆弱性対応の速さ。EOLは選定の足切り条件になりうる。
6	移行コスト	既存資産（特に Struts）からの移行しやすさ。共存可否、段階移行の現実性。
7	人材確保・採用	求人市場での需要、経験者の母数。チームの増員・引き継ぎのしやすさ。
8	開発の活発さ	リリース頻度、コミュニティの勢い、将来性。停滞は将来の負債に直結する。

⚠️ 「速さ」だけで選ばない

ベンチマークの起動速度やスループットは魅力的に見えますが、フルスタックの業務システムでは 保守性・人材確保・サポート継続性 の方が長期コストに効くことが多いです。性能要件が本当に厳しい場合に限り、軸1・8の比重を上げてください。

同じ8軸でも、プロジェクトの性質によって優先順位は変わります。典型例を示します。

✅ 次の章では…

PART 04 で、この8軸で測る対象＝新世代フレームワークの選択肢を紹介します。Spring Boot を本命に、Quarkus / Micronaut / Jakarta EE（JSF）を中級者目線で整理します。

評価軸を設けても、使い方を誤ると形式的な比較で終わってしまう。実務でよくある落とし穴を整理する。

誤り	何が起きるか	正しい使い方
全軸を均等に重み付けする	プロジェクトの性質に関係なく「総合点が高い方」を選び、実際の要件に合わないフレームワークを採用してしまう	まずプロジェクトの特性（スピード重視か、長期運用かなど）を明確にし、重要な軸に高い重みを設定する
評価を1人で行う	評価者の経験・得意領域に偏った結論になり、チームの合意が得られにくい	アーキテクト・開発リード・運用担当など複数の視点で評価し、議論のたたき台として使う
評価時点の情報で固定する	半年後にフレームワークのサポート状況や採用市場が変化していても見直さない	長期プロジェクトではフェーズ移行のタイミングで評価を再確認する