Jakarta EEのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Jakarta EEのシステム開発は、要件整理と基盤の選定を経て、設計から定着まで段階を追って進みます。

まず業務と品質の条件を決め、それに合う実行基盤を選ぶことで、長期運用できる基盤になります。全体像は、Jakarta EEのシステム開発の完全ガイドもご覧ください。

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Jakarta EEのシステム開発の全体像

用途に応じて必要な仕様を組み合わせます。

Jakarta EEは、企業向けJavaアプリケーションを作るための標準仕様群です。販売管理や受発注などの業務パッケージそのものではありません。

Web画面、REST API、認証・認可を、対応サーバー上で組み合わせて作ります。DBアクセス、トランザクション、バッチ、メッセージングも、同じ仕組みの中で組み合わせる対象です。

開発の前に、支える業務と必要な品質を決めておきます。「Jakarta EEを使う」と決めた段階では、要件を満たせるかまだ判断できません。

Jakarta EEの定義と仕様・製品の違い

Jakarta EEは、旧Java EEを引き継いだ企業向けJavaアプリの標準仕様です。仕様と製品は別物なので、実装製品は案件に合わせて選びます。

実装製品：GlassFish、WildFly、Payara、Open Liberty、WebLogicなど
標準仕様の利点：独自機能への過度な依存を避け、サーバー移行や保守会社変更を検討しやすくする
Jakarta EE 11：2025年6月に一般提供
提案書の確認項目：Profile、実装製品と版、JDK、DB、認証方式

Jakarta EE 11はJava SE 17以上が前提です。さらに、Java 21のVirtual Threadsを活用できるほか、Jakarta DataやTCKの改善も含まれます（出典: Eclipse Foundation「Jakarta EE 11 Release」、2025年）。

製品ごとに、対応するProfile（Platform、Web、Core）やJavaの組み合わせは異なります。そのため、「Jakarta EE 11対応」の一文だけでは選定できません。

向いているシステムの種類

長期運用や正確なトランザクション、認証・認可が重要な業務システムに向いています。可用性や監査性が求められる場合も、対象になります。

業務管理：販売、顧客・会員、受発注の各システム
社内・基幹連携：社内ポータルや基幹連携システム
高い整合性が必要な業務：決済、公共・金融系の業務アプリケーション

複数部門が同じデータを参照し、整合性を守りながら段階的に機能を追加する案件では、標準APIと実行基盤の利点が出やすくなります。

単純なフォームや短期の試作には、Web ProfileかCore Profileで必要な仕様だけを使う方法が適しています。

不要な機能まで含むPlatformを選ぶと、学習範囲や設定、試験項目が増えます。運用監視も広がり、そのぶん費用も膨らみます。

小さく始める場合でも、標準APIとサーバー固有の設定や拡張は設計書で分けておきます。この区分があると、将来の拡張や移行を判断する際に役立ちます。

ポイント

Jakarta EEは業務パッケージではなく、企業向けJavaの標準仕様です。製品と仕様を分けて捉え、業務に合う組み合わせを提案書で確かめることが判断の目安になります。

Jakarta EEのシステム開発の進め方

業務の条件を先に決めると、技術選定の判断基準が定まります。

技術選定から始めると、失敗しやすくなります。そのため、現場の業務と経営上の目的を先にそろえ、必要な仕様と実行基盤を選んでから、設計・実装・試験へ進みます。

工程は6フェーズに分かれ、要件整理から定着までを順に進めます。各段階で、成果物と判断基準を決めておきます。

フェーズ1：要件整理による業務範囲と品質の確定

画面や機能の一覧にとどめず、業務イベントと品質条件に分けて整理します。

業務範囲：開始条件、担当者、承認経路、入力データ、連携先、例外処理、処理量、利用時間
業務イベント：受注登録、在庫引当、出荷指示、請求確定、取消、締め処理など
イベントごとの動き：担当者、実行時点、参照・更新データ、失敗時の戻し方
処理性能：利用者数、ピーク同時接続数、1時間あたりの処理件数、許容応答時間
運用・復旧条件：復旧目標時間・時点、保守時間帯、保存期間、監査ログ対象、バックアップ世代数

品質は、測れる基準で定めます。「速く」「止まらず」のような表現のままでは、何を満たせば合格かが分かりません。

たとえば、ピーク時に何秒以内に応答するか、何分以内に復旧するか、バックアップを何世代残すかを決めます。

フェーズ2：Profile・サーバー・Javaの選定

要件に合わせて、実行基盤の候補を比べます。新規開発とJava EE移行では、さらにPoCや互換性の確認も行います。

Profile選定：画面・REST API中心ならWebまたはCore、複雑な処理・メッセージング・バッチならPlatform相当
比較表：Profile範囲、Jakarta EE版、Java 17・21の実績、DBドライバー、認証基盤、メッセージング製品、監視方法
新規開発のPoC：小さな業務フローで標準APIとの境界、認証、DB更新、トランザクション、監査ログ、コンテナ化、デプロイ、障害ログを確認
Java EE移行：依存ライブラリ、設定、javax.*からjakarta.*への変更、XML、JPA、認証、外部連携を洗い出す

名称が似ていても、同じ版のAPIがすべて動くとは限りません。そのため、PoCで解消しきれない不確実性は、見積書のリスク項目に記します。

フェーズ3：設計・開発での標準化と拡張性の両立

業務と技術を一体で設計し、標準化、再現性、レビューを通じて拡張性を保ちます。

業務・データ設計：フロー、画面、API、データモデル、権限、エラー、バッチ、連携、ログ、バックアップ
整合性・非同期処理：エンティティ、トランザクション境界、排他制御、再実行、重複配信、順序、タイムアウト、デッドレター、再処理担当
開発環境：Maven依存関係、Java、サーバー、コンテナ、環境変数、秘密情報を再現できる形にし、CIでビルド、単体試験、脆弱性、イメージ検査を行う
コードレビュー：不要な独自拡張、個人情報を含む障害ログ、トランザクションをまたぐ処理

Jakarta Persistenceの条件を先に定めておくと、画面ごとの個別実装によって整合性が崩れるのを防げます。

フェーズ4：テストによる機能・性能・移行の検証

試験は単体から受入まで順に進めるだけでは不十分です。そのため、Jakarta EE特有の機能と運用も試験計画に含めます。

機能・連携：認証・認可、トランザクション、同時更新、外部APIのタイムアウト
運用・安全性：バッチ再実行、帳票、監査ログ、バックアップ復元、障害復旧、脆弱性
移行確認：既存と同じ入力で同じ結果になる回帰テスト

性能試験の合否は、平均値だけでなく、ピーク時の95パーセンタイル、エラー率、DBロック待ちで判断します。CPU・メモリやキューの滞留も、あわせて見ます。

移行案件では、本番相当のデータを匿名化して試験します。移行リハーサルは複数回実施し、データ件数や文字コード、日付を含めます。NULLや重複キーも対象に入れます。

終了条件は、重大度ごとの未解決件数、性能基準、復旧時間、利用部門の受入サインです。「一通り確認した」だけで終えず、この条件で判断します。

フェーズ5：稼働での切り替えと復旧手順の実行

稼働前の判定会議では、機能やデータの条件に加え、性能、セキュリティ、運用の条件も確認します。

切り替え方式は、一括移行、段階移行、並行稼働から選びます。業務の停止許容時間とデータ同期の難易度に合わせて決めます。

切り替え当日は、停止から監視開始までを時刻順に進めるため、作業ごとに担当者と完了条件を割り当てておきます。当日の作業は次の4つで、問題があれば最後に切り戻します。

バックアップを取得し、書き込みを停止する
最終データを移行し、疎通を確認する
利用部門の確認と告知を行い、監視を開始する
問題があれば切り戻す

稼働後は初日だけでなく、1週間から1か月程度の安定化期間を計画します。

ログイン失敗、APIエラー、処理時間を追跡します。さらに、バッチ遅延、問い合わせ、データ不整合も対象にし、一次切り分けの担当を決めておきます。

切り戻し手順は文書にまとめたうえで、リハーサルで実際に復旧できるかを確かめます。バックアップがあることと、復元後に業務を再開できることは、別々に確認します。

フェーズ6：定着での運用と改善の仕組み化

利用部門と運用担当者が自力で業務を続けられるよう、手順、責任、改善の確認方法を整えます。

日常運用：操作マニュアル、権限申請、ユーザー追加、月次バッチ、障害連絡、ログ確認、バックアップ復元
委託先との運用：脆弱性確認、リリース承認、何分以内に受け付けるか、原因調査者、復旧判断者を手順やSLAに記載
月次KPI：利用率、入力漏れ、処理時間、問い合わせ・障害件数、復旧時間、リリース頻度
改善・保守：業務効果、セキュリティ、データモデル、試験範囲、費用で機能追加を評価し、サポート期限、脆弱性、クラウド料金も見直す

機能追加には優先順位を付け、完成後に放置される状態を避けます。

ポイント

要件整理から定着までの6フェーズを、業務と技術を行き来しながら進めます。選定の前に業務範囲と品質を数値で決めておくことが、判断の目安になります。

Jakarta EEのシステム開発の費用相場とコストの内訳

Jakarta EE案件の費用は、技術名だけでは決まりません。そのため、業務システム全般の相場をJakarta EE利用案件向けに読み替えた、初期予算の目安を示します。

これは、Jakarta EE専用の公的な価格統計ではありません。金額は、画面、API、バッチといった機能の範囲で変わります。帳票や連携、移行、試験、運用も、範囲に入るかどうかで差が出ます。

規模別の初期開発費と期間の目安

初期開発費と期間は、規模や移行の範囲で変わります。目安は次のとおりで、要件や構成によって上下します。

小規模Web業務アプリ：1部門、基本登録・検索・更新、少数の権限・帳票、外部連携なしまたは少数。300万〜1,000万円、3〜6か月程度
中規模業務システム：複数部門、承認、REST API、バッチ、DB・既存システム連携。1,000万〜5,000万円、6〜12か月程度
大規模・基幹：高可用性、複数拠点、大量データ、複数基幹連携、厳格な監査、移行リハーサル。5,000万〜1億円以上、12か月から2年以上の場合がある
Java EE移行：500万〜5,000万円以上、4〜18か月程度

Java EEからの移行費と期間の目安は、NotebookLM「業務システム全般」のQ&Aを基にしたリサーチノート（2026年）によります。

小規模の費用幅は、要件を絞り既存部品を使う場合の下限です。ただし、各金額は個別見積ではありません。

移行では、javax.*の置換に加え、依存ライブラリやサーバー設定も対象になります。認証、JPA、外部連携、回帰試験、段階リリースまで含むほど、上限に近づきます。

人件費・移行費・クラウド費の内訳

開発費は工程ごとに分けて考えます。リサーチノートの目安では、次の割合になります。

要件定義：10〜12%程度
設計・環境構築：22〜24%程度
実装：48〜50%程度
テスト：15〜17%程度

移行や性能試験は、本体費用に含まれない場合があります。脆弱性診断や教育、運用引き継ぎも、本体費用の外になることがあります。見積書で別行になっているかを確認します。

クラウド費は、開発費とは別のランニングコストです。例として、AWS App Runnerの東京リージョンの単価を見てみます。

メモリ：プロビジョニング済みコンテナは0.009 USD／GB時間
vCPU：アクティブなコンテナは0.081 USD／vCPU時間

料金例の出典は、AWS「App Runnerの料金」（2026年確認）です。ログや転送、DBは別料金で、バックアップや監視、WAF、ロードバランサーも別に加算されます。

環境数や可用性の構成によっても費用は変わるため、単価だけで月額を決めつけず、構成と利用量をAWS料金計算ツールなどで試算します。

保守運用費は、一般的な業務システムでは初期開発費の年15〜25%程度、または月15万〜80万円程度が目安です。

平日日中の問い合わせ対応と、24時間365日の障害対応では体制が異なります。そのため、対応範囲を分けて契約します。

対応範囲には、問い合わせや障害の一次対応、原因調査を含めます。脆弱性対応やOS・JDK・サーバーの更新も、範囲に入るかを確認します。さらに、機能改修、バックアップ復元、性能改善も、契約に含むかを明記します。

ポイント

費用は技術名では決まらず、規模、移行範囲、試験、クラウド、保守の前提で変わります。金額を比べる前に、これらの前提を各社で同じにそろえることが判断の目安です。

Jakarta EEのシステム開発で見積もりを取る際のポイント

前提をそろえると、各社の提案差を見分けやすくなります。

見積もりの依頼では、技術名より業務範囲と成果物を示します。各社が同じ前提で比べられるよう、RFPを用意します。

RFPには、機能一覧や業務フロー、利用者と権限を記します。画面・帳票・API、連携先、データ件数、移行対象も、あわせて記載します。非機能要件や希望時期、保守条件も記載します。まだ決まっていない事項は「未定」と書き、調査費や追加見積の条件を明示します。

要件と成果物をそろえた比較の土台

見積依頼書には、納品物の有無を明記します。そのうえで、各社の工数差を説明できる粒度まで要件を分けます。

設計・開発資料：要件定義書、基本・詳細設計書、ソースコード
試験・移行資料：テスト仕様書と結果、移行計画
運用資料：運用設計書、マニュアル、引き継ぎ資料

画面ごとの入力項目や検索条件は、一つずつ分けて書きます。権限や帳票、外部API、バッチも、本数と頻度まで書き分けます。

移行では、対象テーブルと件数を記載します。変換やクレンジング、照合、リハーサル回数も、書いておきます。

非機能要件では、利用時間やピーク負荷、可用性を確認します。バックアップや復旧目標、ログ保存期間も、確認項目です。

暗号化、脆弱性診断、監査証跡も定義します。個人情報の扱いも決めておきます。「標準対応」とだけ書くと、範囲があいまいになります。

認証・認可や秘密情報、TLSの範囲を確かめます。依存ライブラリ検査やWAF、ネットワーク分離、事故報告も、範囲を見ます。要件ごとに検証方法と責任者を割り当てます。

ベンダーのJakarta EE実績の具体的な確認

「Javaの経験が豊富」という説明にとどめず、技術、類似案件、実装証跡を確かめます。

技術と運用実績：Profile、実装製品、Java 17・21、Java EE移行、DB・認証・メッセージング連携、コンテナ・Kubernetes、障害対応
過去事例：業界・画面数、ピーク処理量、可用性、移行方式、稼働後の保守体制、予定外の課題と解決方法
提案の証跡：実装候補の対応表、PoC範囲、各組み合わせの動作証跡

たとえば、Jakarta EE 11 Web ProfileでServlet、REST、Persistence、Securityを使う構成になるかを確認します。Java 21と特定サーバーの組み合わせは、証跡で確かめます。認証や固有設定が標準API外にある場合は、移行費用と代替案も比べます。

追加費用と責任分界の契約前の明確化

契約では、変更対応と保守責任を定めておきます。手順があいまいだと、追加費用や納期の遅れにつながりやすくなります。

変更手順：要求受付、影響調査、見積提示、承認、納期変更、追加試験
工数に影響する変更：外部API仕様、移行件数、帳票、認証要件、24時間運用
OSSの保守範囲：脆弱性監視、パッチ、窓口・対象版、障害連絡、ライセンス確認の担当

オープンソースは利用料がかからなくても、保守費まで不要とは限りません。

NISC「サイバーセキュリティ2025」は、委託先を含むサプライチェーンで停止や漏えいが波及するリスクを示しています（出典: 国家サイバー統括室「サイバーセキュリティ2025」、2025年）。

開発会社、クラウド、運用会社の責任範囲が途切れないよう、契約と運用手順で結びます。

ポイント

見積を比べる前に、同じ前提の要件と成果物をそろえ、追加費用と責任分界の条件を契約前に決めておくことが判断の目安です。

Jakarta EEのシステム開発でよくある質問

発注前によく出る疑問を取り上げます。採用の可否は、流行だけでなく、既存資産と業務の複雑さで判断します。運用体制や必要な可用性、将来の移行方針も、判断材料になります。

Jakarta EEとSpringはどちらを選ぶべきですか？

技術名だけで決めず、既存環境とチーム、運用方針をあわせて比べます。

Jakarta EEを候補にする条件：既存Java EE資産、標準準拠、サーバー運用、長期保守を重視
比較する条件：チーム経験、利用ライブラリ、クラウドネイティブ化の方針、採用する運用基盤

2025年調査の回答者では、Jakarta EEの利用が58%、Springが56%、Jakarta EE 11の採用が18%でした（出典: Eclipse Foundation「2025 Jakarta EE Developer Survey」、2025年）。

この調査は1,700人超の回答者によるものです。市場全体のシェアを示す統計ではありません。

Java EEからJakarta EEへ移行できますか？

移行できます。既存の資産と互換性を確かめながら、切り替えを段階的に進めます。手順は次の4つです。

版と依存関係を確認し、対象資産を洗い出す
javax.*からjakarta.*への変更、JDK・サーバー、XML、JPA、認証、外部ライブラリ、Webサービスを調べる
データ移行と回帰テストを含むPoC、移行リハーサルを行う
本番を一度に変えず、並行稼働または段階リリースにする

段階的に切り替えると、停止リスクを抑えやすくなります。

Jakarta EE 11対応と書かれた提案で何を確認すべきですか？

「Jakarta EE 11対応」の記載は、実際の組み合わせと証明方法まで確認します。

対応構成：Profile、仕様、実装製品と版、Java、DB、認証基盤、コンテナ
互換性の証拠：TCKや互換性の確認方法、開発・試験・本番の組み合わせ

「Java 17以上」と「Java 21で本番運用できる」は、同じ意味ではありません。そのため、構成を提案書に固定します。

Jakarta Security 4.0は複数認証機構の基本APIと組み込みIdentity Storeを含み、Java SE 17以上が最低要件です（出典: Jakarta EE「Jakarta Security 4.0」、2026年確認）。

APIがあっても、秘密情報の管理や監査設計まで済んでいるとは限りません。

開発費以外にどのような費用がかかりますか？

開発費以外の項目も、初期、継続、移行に分けて見積もります。

クラウド・基盤：計算、DB、ストレージ、通信、ログ、監視、バックアップ、WAF、証明書、商用サーバーサポート
安全性・運用：脆弱性診断、教育、保守運用
Java EE移行：調査、ライセンス・サポート契約見直し、データ移行、回帰試験、切り替えリハーサル

見積書は、初期、月額、年額、臨時作業に分けて見ます。また、開発会社とクラウド事業者の責任範囲も確認します。

ポイント

採用の判断は、既存資産や業務の複雑さ、運用体制を基にします。「Jakarta EE 11対応」の表記は、組み合わせと証明方法まで見て判断します。

まとめ

Jakarta EE開発は、要件整理、選定、設計開発、テスト、稼働、定着の6段階で進みます。段階ごとに、業務と技術を行き来しながら判断します。

最初に、業務範囲と非機能要件を数値で示します。次に、Profile、Java、サーバー、DB、認証、運用基盤の組み合わせを、PoCで確かめます。

Jakarta EE 11対応という表記だけで決めず、実際の実行環境と互換性を見ます。

初期予算の目安は、小規模Web業務アプリで300万〜1,000万円、中規模で1,000万〜5,000万円です。大規模・基幹は5,000万〜1億円以上、Java EE移行は500万〜5,000万円以上が目安です。

これはリサーチノートに基づく一般的な幅です。見積もるときは、画面数や連携数、移行データの前提をそろえます。可用性、試験、クラウド、保守も、同じ条件で示してもらいます。

成果物や追加費用の条件、障害・脆弱性対応、サポート期限、責任分界は、見積書で確認します。

発注前に現行資産を洗い出し、業務フローを整理すると、比べやすい見積に近づきます。

特に、Java EE移行や24時間運用では、技術選定に加えて、データ移行、回帰テスト、切り戻し、運用引き継ぎが成否を左右します。

また、長期運用では、定着後のKPIと改善の責任も計画します。作って終わりにしないことが大切です。

▼全体ガイドの記事
・Jakarta EEのシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
 ・スクラッチシステム開発の完全ガイドブック
 ・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。