Jakarta EEのシステム発注は、業務範囲と移行対象を整理し、RFPで要件をそろえ、契約と委託先を選ぶ順に進めます。この順で進めると、発注側と委託先の認識違いを減らせます。
全体像は、Jakarta EEのシステム開発の完全ガイドもあわせてご覧ください。
▼全体ガイドの記事
・Jakarta EEのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Jakarta EEのシステムで発注する対象
Jakarta EEのシステムは、企業向けJavaアプリケーションを構築・運用する標準仕様群を使って作る業務システムです。業務パッケージそのものとは違い、標準仕様の部品を組み合わせる形です。
Jakarta EEは業務システムの土台となる標準仕様
業務システムでは、画面やREST API、認証・認可を組み合わせます。そのほか、データベースやトランザクション、バッチ、メッセージング、監査ログも、業務に応じて加わります。
Jakarta EEには、ServletやRESTful Web Services、CDIなどの仕様があります。Persistence、Transactions、Security、Messagingなども、必要に応じて選びます。実行先には、選定したアプリケーションサーバーやクラウド基盤を使います。
- 部門向けWeb業務アプリ：Web ProfileやCore Profileを使います。
- 複雑な基幹連携や大量処理：DB、キュー、バッチ、監視まで設計します。
発注対象は、Jakarta EEという技術名ではなく、実現する業務機能と運用サービス一式です。範囲が曖昧なままだと、帳票や権限、障害復旧が完成後に別費用になりやすくなります。
新規開発・移行・ハイブリッドの分け方
案件の出発点となる開発方式は、新規開発、既存資産の移行、SaaSやパッケージとの組み合わせに分けて考えます。方式によって、調べる内容が変わります。
- 新規開発：スクラッチで作る場合の要は、業務要件とデータ移行の設計です。
- Java EE移行：javax.*からjakarta.*への名前空間変更の確認が中心です。
- 移行時の互換性：依存ライブラリ、XML設定、認証方式、サーバー、帳票、外部連携が調査対象です。
- ハイブリッド：SaaSやパッケージと自社開発の組み合わせです。
既存資産を残す場合は、移行調査と回帰テストの比重が大きくなります。
発注形態の選び方
発注形態は、要件の確定度や社内のIT人材、既存システムの複雑さで選びます。リリース時期と変更の多さも、判断の材料になります。
社内で決める事項と、開発会社に任せる事項を分けておくと、費用と責任範囲が見えやすくなります。
要件が固まっている場合の一括請負
画面一覧、業務フロー、外部連携、性能目標、受入条件が固まっていれば、設計からテストまで一括請負で依頼できます。そのため、成果物と納期も合意しやすい形になります。
一括請負は、社内の管理負担を抑えられます。一方で、発注前に要件が不足していると、仕様変更が追加費用や納期の延長につながります。
Jakarta EEのProfileやサーバー製品を委託先に提案してもらう場合は、採用理由と将来の移行可能性も成果物に含めます。
要件を一緒に整理する準委任と伴走型
現場ごとに業務が異なる場合や、Java EE資産の全体像が分からない場合は、要件定義や現状調査を準委任で始められます。関係部署の合意形成が必要な場合にも合います。
委託先のエンジニアは、社内の担当者と作業時間を共有しながら、業務フローやデータ項目、連携仕様、移行対象を整理していきます。
調査結果をもとに本開発だけを請負に切り替える二段階発注にすると、要件が定まらないまま大きな契約を結ぶリスクを抑えられます。
SaaSやパッケージとの組み合わせ
販売管理や勤怠など標準化しやすい領域はSaaSを使い、固有の承認や基幹連携だけをJakarta EEで開発する方法もあります。すべてをスクラッチで作る場合より、初期開発を抑えられる可能性があります。
- 連携とデータ：SaaSのAPI制限やデータの保存場所が対象です。
- 契約と責任：解約時の返却、利用料の改定、障害時の責任の所在です。
- 比較費用：開発費に加えて、5年程度の利用料、連携費用、運用工数を見積もります。
RFPと要件整理で決める事項
RFPは、委託先が同じ前提で見積もれるよう情報をそろえる文書です。機能一覧だけでは足りず、「対応可」という回答だけでは前提がそろいません。
RFPでは、対象範囲、前提条件、除外項目、検収方法、追加変更の扱いを指定します。Jakarta EEの案件では、仕様と実装製品は別物として扱います。
技術面では、想定するProfile、Javaの版、サーバー、DB、コンテナ基盤も明記します。
業務フローで示す業務要件
「画面20枚」といった数え方では、承認経路や例外処理、権限、帳票、通知、締め処理の工数が伝わりません。さらに、利用者の種類や処理件数も見積の前提になります。
- 業務の流れ：業務フロー、入力項目、承認条件、優先度
- 利用と出力：利用者、月間・ピーク時の件数、帳票、検索条件、通知先
- 連携と段階：外部連携の記載と、Must・Should・Couldによる初回機能と将来拡張の分け方
この情報がそろっていると、複数社の提案を同じ条件で比べられます。
Profile・Java・サーバーまで指定する技術要件
Jakarta EE 11は2025年6月26日に一般提供され、Java SE 17以上を前提としています。また、Java 21ではVirtual Threadsを利用できます。さらに、Jakarta Dataも加わりました（出典: Eclipse Foundation「Jakarta EE 11 Release」、2025年）。
- 仕様範囲：Web ProfileかPlatformか、採用する仕様の範囲です。
- 実行環境：Java 17か21か、サーバー名と版、サポート期限を含みます。
- 周辺基盤：データベース、認証基盤、メッセージングの指定です。
仕様の互換性と製品の商用サポートは、別々に確かめます。2026年8月時点では、Jakarta EE 12は開発中です（出典: Eclipse Foundation「Jakarta EE Releases」、2026年確認）。
納期が先であっても、「次期版に対応予定」という提案だけでは採用を決めません。そこで、互換性が正式に確認された製品や、Javaの長期サポート、既存アプリの移行計画を優先します。一方、将来の更新余地は別の項目で評価します。
数値で定める非機能要件と移行要件
「速い」「止まらない」といった表現では、会社ごとに解釈が変わります。そこで、可用性、応答時間、同時利用者数、バックアップ、復旧目標、監査ログを数値や条件で示します。さらに、脆弱性対応と監視時間帯も書いておきます。
たとえば、ピーク時の応答秒数や月間稼働率、RTO、RPO、ログ保存期間に置き換えます。
移行案件では、現行のjavax.*の利用箇所、依存ライブラリ、データ件数、文字コードを記載します。加えて、バッチ時間や切替可能時間、リハーサル回数、切戻し条件もRFPに含めます。
運用とセキュリティの責任分界
開発会社に任せる範囲は、リリースで終わるとは限りません。そのため、運用作業ごとに担当者を決めておきます。
- 更新と監視：Java・サーバーのパッチ、脆弱性確認、秘密情報の更新、監視が対象です。
- 障害と復旧：一次対応、バックアップからの復元、権限の見直しを誰が担うかです。
- 委託と個人データ：再委託先への連絡と、管理や削除の方法です。
Jakarta SecurityのAPIを採用しても、秘密情報の管理やネットワーク分離が自動的に整うわけではありません。個人データを扱う場合は、個人情報保護委員会のガイドラインに沿って、委託先の管理と削除の方法を確かめます。
請負と準委任の契約形態
契約形態は、成果物を固定できるか、発注者と受託者がどこまで共同で要件を決めるかで選びます。契約名そのものより、中身の取り決めが安全性を左右します。
契約書では、作業範囲、成果物、検収、変更管理を具体化します。さらに、再委託や知的財産、損害賠償、保守への移行条件も決めておきます。
成果物と受入条件が明確な請負契約
請負契約は、合意した成果物を完成させ、検収を受ける形に向いています。
- 成果物：基本設計書、詳細設計書、ソースコード、テスト仕様書、操作マニュアル、移行手順書などを一覧にします。
- 検収：期間と不具合修正の扱いを決めます。
- 契約の分割：要件定義・調査は準委任、開発・テストは請負に分ける方法もあります。
要件が未確定のまま全工程を請負にすると、追加変更の協議が頻発します。
探索や要件定義に合う準委任契約
準委任契約では、専門家としての調査や設計支援、開発支援などを一定期間依頼します。作業を進めながら成果の方向を決める場面に適しています。
- 現状把握：移行対象を洗い出し、現行環境を解析してもらいます。
- 技術検討：PoCや技術検証を任せる形です。
- 進行支援：プロジェクト管理や設計の面で助けてもらいます。
費用は作業時間や体制で決まることが多いため、月次報告、稼働上限、優先順位の決定者、成果物の最低ラインを契約書や発注書に明記しておきます。
変更管理と知的財産の取り決め
変更管理と知的財産の扱いは、契約の時点で取り決めておきます。
- 変更手順：起票者や承認者、影響調査の期限、追加見積の計算方法、納期変更の条件です。
- 構成変更：Jakarta EEの版、サーバー製品、DB、クラウド構成が変わると、設計・試験・運用手順に響きます。
- 成果物の保有：ソースコード、設定ファイル、CI/CD定義、テストデータ、設計書ごとの保有者と引き渡し形式です。
- 費用：オープンソースのライセンスと商用サポート費は、開発費とは分けて記載してもらいます。
Jakarta EEのシステム開発の費用相場
Jakarta EE専用の国内価格統計は、一般には公開されていません。そこで、業務システム全般の相場を、企業向けJavaシステムの規模と工程に合わせた初期予算の目安として示します。
- 小規模Web業務アプリ：300万〜1,000万円が目安です。
- 中規模業務システム：1,000万〜5,000万円が目安です。
- 大規模・基幹システム：5,000万〜1億円以上が目安です。
- Java EEからの移行：範囲と回帰テスト量によって、500万〜5,000万円以上です。
いずれも確定見積ではなく、要件や既存資産、連携数、可用性を前提にした費用の幅です。
機能数と連携・移行難易度で変わる規模別の費用
規模ごとに機能や運用条件を照らし合わせ、見積の前提をそろえます。
- 小規模：1部門で基本登録・検索・更新を行い、権限を限定して少数の帳票を扱います。
- 中規模：複数部門、承認、REST API、バッチに加えて、既存DBや会計・在庫との連携を含みます。
- 大規模：複数拠点、大量データ、24時間運用、監査、障害時の切替、複数回の移行リハーサルが必要です。
予算は、画面数よりも内訳で比べます。見積では、開発費、データ移行費、性能・脆弱性試験費、教育費を別行にしてもらいます。
要件定義・設計・実装・試験に分けた見積の内訳
費用の配分は案件によって異なります。業務システム全般では、次のような配分の目安が使われることがあります。
- 要件定義：10〜12%
- 設計・環境構築：22〜24%
- 実装：48〜50%
- テスト：15〜17%程度
この配分例は、Jakarta EE専用の統計ではなく、業務システム全般の費用整理です（出典: NotebookLMリサーチノート内「業務システム全般」の費用整理、2026年）。
発注時には、この配分例を比べる基準にして、各社に工数と単価の根拠を聞きます。
移行案件では、現行調査や変換、データクレンジング、回帰テスト、切替リハーサルを実装費とは分けて見ます。そのため、安すぎる見積の理由も見抜きやすくなります。
開発費と分けて見るクラウド・ライセンス・保守費
開発費と運用費は分けて考え、継続費の範囲と試算の条件を確かめます。
- 基盤と保守：サーバーサポートやJava保守、クラウドコンテナが対象です。
- 運用サービス：DB、ログ、監視、バックアップ、通信、脆弱性対応が含まれます。
AWS App Runnerの東京リージョン料金例では、アクティブコンテナは0.081米ドル／vCPU時間です。アクティブコンテナは、GB時間あたり0.009米ドルです（出典: Amazon Web Services「AWS App Runner料金」、2026年確認）。
0.5 vCPU・1GBを1台で24時間稼働させる単純計算では、コンテナ分だけで月約65米ドルになります。一方で、ログやDB、通信、バックアップ、監視は別料金です。
為替や利用量によっても費用は変わるため、月額を一つに断定せず、構成と利用量を添えて試算します。
委託先選定と見積比較で確認する事項
委託先は、Javaの経験年数や会社規模に加えて、Jakarta EEの業務システムを運用まで成り立たせられるかで選びます。
候補企業には、同じRFPと見積書式を渡し、機能、工数、単価、前提、除外、保守をそろえて回答してもらいます。最安値だけで決めないよう、提案に抜けている作業や、前提が自社の業務に合うかを見極めます。
対応Profileと実行基盤の具体的な確認
「Javaに対応できます」という回答では足りず、Profile、実装、Javaの版まで確かめます。
- Profile：Web、Core、Platform相当のうち、どれを使うかです。
- 実装：Open Liberty、WildFly、Payara、WebLogicなど、想定する製品です。
- Java：Java 17と21のどちらを採用するかです。
2025年のEclipse Foundation調査には、1,700人超が回答しました。回答者のうち、Jakarta EE利用は58%、Springは56%でした。また、Jakarta EE 11採用は18%でした（出典: Eclipse Foundation「2025 Jakarta EE Developer Survey」、2025年）。
この数字は市場全体のシェアではなく回答者ベースで、企業向けJavaの選択肢として評価されている状況がうかがえます。
総額より作業の含まれ方で比べる見積
見積は、工程や作業を行ごとに見ます。さらに、PMや上級SE、セキュリティ担当、インフラ担当が何人月含まれるかも確かめます。
- 開発工程：要件定義、基本・詳細設計、実装の各作業です。
- 試験と移行：各種試験、データ移行、教育、リリースの作業です。
- 引継ぎと品質：運用引継ぎの費用や、レビュー・品質管理が別料金かどうかです。
移行リハーサルや監視設計が除外されていると、後から追加費用が発生します。そのため、安く見える総額より、どの作業が含まれているかを確かめる必要があります。
PoCと技術回答による実力の確認
候補を絞ったら、代表的な業務フローで短いPoCを依頼し、資料だけでは分からない設計力を確かめます。
- 基本機能：REST API、DBアクセス、認証・認可、監査ログ、エラー処理を動かします。
- 実行と確認：コンテナへのデプロイと、ログの確認です。
- 移行検証：javax.*変換、依存ライブラリ更新、サーバー設定、回帰テスト方針を確かめます。
- 実績確認：Profile、サーバー、Java版、運用体制について質問します。
Java EEからの移行では、サーバー設定や回帰テストの方針を、サンプルコードで説明してもらいます。
OracleはCERNでのWebLogicのKubernetes活用事例を公開しています（出典: Oracle「WebLogic Server」CERN事例、2026年確認）。大規模環境のコンテナ運用を考える参考になります。ただし、公開事例の性能や構成をそのまま当てはめず、利用者数、可用性、運用要員、データ所在、障害時の復旧条件を自社の要件に置き換えて評価します。
仕様と保守責任が曖昧な提案
「標準機能で対応」としながら仕様が不明な提案には注意が要ります。「クラウド費用込み」とうたっていても、DBやログが含まれていない場合があります。
「移行可能」としながら切替リハーサルがない場合も、確かめる必要があります。さらに、質問への回答が担当者ごとに異なる提案や、技術選定の理由がない提案もリスクです。
運用開始後の窓口やSLAも確かめておきます。評価は、技術適合性、業務理解、移行計画、品質管理を分けて行い、セキュリティや運用、費用の透明性も別に見ます。そのうえで、価格だけで順位を付けないようにします。
よくある質問
Jakarta EEの発注では、技術選定や既存資産、費用、契約、運用範囲について質問が多く寄せられます。そこで、発注前に確かめておきたい前提とあわせて、質問への答えをまとめます。
Jakarta EEのシステムは一般的なWebシステムより高額ですか？
Jakarta EEを採用しただけで高額になるとは限りません。費用は、業務機能や連携数、データ量、可用性で決まります。さらに、既存資産の移行や商用サポート、保守体制も関係します。
標準APIや既存部品を活用して範囲を絞れば、費用を抑えられます。一方で、基幹業務の高可用性や大規模移行を含めると、小規模Webアプリより高くなります。
Java EEからJakarta EEへ移行するときに最初にすることは何ですか？
最初に、現行のJava EE版やjavax.*の利用箇所、依存ライブラリ、アプリケーションサーバーを一覧にします。認証、DB、外部連携、帳票、バッチも含めたうえで、移行対象と対象外を決めます。
次に、サンプル機能で変換やビルド、起動、テストを行います。そのうえで、本番全体を一度に移行するのではなく、回帰テストと切戻し条件を確かめながら、段階的に進めます。
この手順を踏むと、発注費用とリスクを見積もる材料がそろいます。
委託先にJakarta EEの実績を聞くときの質問は何ですか？
利用したJakarta EEの版とProfile、Java版、実行サーバーを聞きます。あわせて、DB・認証・メッセージングとの連携や、新規開発か移行かを尋ねます。
リリース後の保守体制や障害対応時間、脆弱性情報の確認方法、サポート終了時の更新計画も尋ねます。
ソースコードと設計書の引き渡し条件も確かめます。そのうえで、実績を自社の案件に応用できる根拠を説明できる会社を、候補に残します。
開発後の保守も同じ会社に委託すべきですか？
同じ会社なら、設計意図や障害履歴を引き継ぎやすくなります。ただし、保守を同じ会社に頼むことは必須ではありません。
別会社へ切り替えられるように、ソースコードや環境定義、テスト、監視設定、運用手順、ライセンス情報を受け取れる契約にしておきます。
同じ会社へ保守を依頼する場合は、月額の対応時間、障害の優先度、脆弱性対応、追加開発の単価を明確にして比べます。
まとめ
発注時は、技術名だけでなく、業務機能や既存のJava EE資産を押さえます。さらに、Profile、Javaとサーバーの版、非機能、データ移行、運用責任も確かめます。
新規開発と移行、SaaSとのハイブリッドを比べ、要件が固まった工程は請負、調査や要件定義は準委任と使い分けます。
発注前にRFPへ入れる項目
RFPでは、業務フローと利用者数、外部連携を示します。そのうえで、次の項目も入れておくと、各社の見積の前提がそろいます。
- 優先度
- 画面・API・帳票・バッチ
- データ量
技術と運用の面では、Jakarta EEのProfileとJavaの版、実行サーバーを含めます。ほかに、次の項目も入れます。
- 認証・認可
- 性能・可用性
- 移行・切戻し
- テスト
- クラウド・ライセンス・保守費
契約と検収条件も確かめます。同じ条件で複数社に提示して、前提、除外、工数、担当体制、リリース後の責任を比べれば、追加費用と手戻りを減らせます。
最初に行う現行資産の棚卸しと小さな技術検証
最初の技術確認では、既存資産の移行と新規開発で見る対象を分けておきます。
- Java EEの既存システムは、現行環境と依存関係を一覧にし、代表的な機能で移行できるかを検証します。
- 新規開発は、認証やDBアクセス、監査ログ、デプロイ、障害時のログ確認を含む小さなPoCで、提案会社の技術力と運用の現実性を確かめます。
予算は、この記事の費用幅を出発点にし、RFPとPoCの結果を見積に反映させて、正式見積へ進みます。
▼全体ガイドの記事
・Jakarta EEのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。