Java EEのシステムを発注・外注するときは、現状の資産を調べ、RFPで要件を整理したうえで、複数社の提案を比べて契約を結びます。そのあと段階的に開発し、移行リスクを把握しながら運用へつなげます。
全体像は、Java EEのシステム開発の完全ガイドでも確認できます。
▼全体ガイドの記事
・Java EEのシステム開発の完全ガイド
AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。
Java EEシステムの概要と発注前の決めごと
Java EEのシステムは、企業向けのWeb・業務アプリを作るための標準仕様群を使います。
既製の業務パッケージとは別に、仕様を組み合わせて作るものです。
画面にはServletやJSP、業務ロジックにはCDIやEJBを使います。データアクセスを担うJPAや、トランザクションを管理するJTAも組み合わせます。REST APIのJAX-RSや、認証・認可、メッセージング、バッチも構成要素です。
発注時は、技術要件だけでなく、実現する業務と運用水準も決めます。
Java EEとJakarta EEの違いの確認
仕様の変遷と対応状況を押さえると、既存環境を移行できるか、新規開発の基盤をどこに置くかを判断できます。
- 仕様の移管：Java EEはOracleからEclipse Foundationへ移され、Jakarta EEとして発展しています。
- API名の変更：Jakarta EE 9以降は`javax.*`が`jakarta.*`に変わるため、旧システムを新サーバーへそのまま載せられるとは限りません。
- 既存環境の調査：JDKやサーバー、Java EEの版、ライブラリを対象にします。非標準API、DB、外部連携も含みます。
- Jakarta EE 11：2025年6月に正式リリースされた版で、対象はJava 17以上です。
- 今後の計画：2026年時点ではJakarta EE 12も開発中です。新規開発ではサーバーの認定範囲とサポート期間を確認し、既存開発は移行段階を分けて進めます。
この版では、Java 21の仮想スレッド、Jakarta Data、互換性テストの近代化などを取り入れています（出典: Eclipse Foundation「Jakarta EE 11 Release」、2025年）。
画面以外も含めた発注範囲
見積額は画面数だけでは決まらないため、発注範囲に含める対象を整理しておくと、追加費用になりやすい作業を事前に把握できます。
- 業務処理：夜間バッチ、帳票、権限、承認経路まで含めます。
- 連携と移行：API・ファイル連携とデータ移行の範囲を確かめます。
- 運用と復旧：監査ログ、バックアップ、切り戻し、利用者教育も扱います。
受発注システムなら、受注登録に加えて在庫引当や出荷連携、請求を業務シナリオに含めます。
締め処理や取消、再送、エラー時の手動復旧も、同じシナリオのなかで扱います。
発注時は、目的と対象業務、利用者と拠点を整理します。
発注側は、データ量と外部連携を確かめ、希望稼働日と同時接続数も書き出しておきます。
可用性やRTO・RPOは、障害時の停止時間やデータをどこまで戻すかを決める項目です。
発注条件には、セキュリティ、納品物、運用体制も含めます。
未確定の項目は、そのまま提案を依頼するものと、発注までに確定させるものに分けておきます。こうすると、追加費用になりうる範囲がつかみやすくなります。
Java EEのシステム開発を発注・外注する進め方
相談のあとは、すぐに開発へ入らず、企画から運用の引き継ぎまで段階を踏んで進めます。特に既存システムの刷新では、短期間のアセスメントやPoCで不確実な点を減らしておくと役立ちます。
- 企画と現状調査を行い、資産や課題を洗い出します。
- 業務と技術の要件をまとめ、RFPで提案の条件を示します。
- 複数社の提案を比べ、契約と責任分界（どこまでを誰が受け持つか）を決めます。
- 設計・開発、テスト、移行を経て、運用の段階に入ります。
発注形態を目的に合わせた選択
発注形態は、要件の確定度や必要な支援範囲に合わせて選びます。判断にあたっては、成果物と納期を明確にできるかが大きな手がかりになります。
- 一括請負：システム全体を一社へ任せ、窓口を集約します。
- 支援型：企画や要件定義を支援会社へ依頼します。
- ラボ型・準委任型：開発人員や継続的な技術支援を得られます。
- アセスメント型：既存システムの調査を切り出します。
要件が固まっていれば、請負が向いています。
既存資産の調査や業務整理を含む場合は、準委任で調査し、範囲が確定してから請負へ移す方法があります。
請負では、契約後の仕様変更が、追加費用や納期延長につながることがあります。
準委任には、発注側の意思決定者とレビュー担当者が欠かせません。
人員の補充だけを目的にすると、業務設計や品質保証の責任が曖昧になりやすいです。
契約書と作業計画書には、成果物と役割を記します。
レビュー方法と報告頻度も、同じ文書に書いておきます。
最初の現状調査と小さなPoC
最初の依頼では現状資産台帳を作り、移行見積の前提を確かめておきます。ソースコードを読まず、画面一覧だけで出した費用は、比べるときに注意が必要です。
- 資産を記録：コードや設定、ライブラリ、サーバーを並べます。DB、ジョブ、帳票も含めます。
- 構成を記録：外部連携と運用手順、JDK、サーバー製品と版を押さえます。
- リスクを記録：APIや保守期限、脆弱性、担当者の有無が対象です。
台帳には、`javax.*`か`jakarta.*`か、独自拡張、サーバーのエディションも書き込みます。
PoCでは、代表画面や認証、DBアクセスなど、移行リスクが高い処理を小さく動かします。
`javax.*`の変換、サーバー互換性、性能を確かめます。
ログやコンテナ化も含めて確認し、変換できない箇所と代替策は成果物に残します。
PoCは、見積の前提とリスクを事実に近づけるための小さな検証です。本番を完成させる工程とは混同しないようにします。
業務単位の開発と、テスト・切り戻しの設計
全機能を一度に作らず、業務上のまとまりごとに優先順位を付けます。データの流れと利用開始の順番に沿って開発します。たとえば、顧客、商品、権限を先に整え、そのあとに受注、請求、外部連携を作ります。
各反復では、利用部門が受入条件を確認します。
未解決の課題は、次の範囲へ持ち越すか、リリース条件を見直すかを決めます。
テストは、単体・結合・総合・受入の各段階で行います。
- 性能と復旧：同時接続数やバッチ時間、権限の誤設定、障害復旧を確かめます。
- 移行と連携：件数照合や外部連携の再送、バックアップ復元を試します。
- 本番準備：並行稼働と切り戻し、データ凍結時刻を決めます。
利用者教育と問い合わせ窓口、稼働後30日・90日の改善体制まで合意しておくと、リリース直後の混乱を抑えられます。
RFPと要件整理でJava EEの発注条件を固める方法
RFPは、何をどの品質でいつまでに作るかを委託先へ伝える文書です。
現状や条件も示すほど、提案と見積を比べやすくなります。
RFPには、現状の課題や対象業務、利用者、業務量を書きます。既存資産や連携先、制約、予算の考え方、提案してほしい選択肢も記載します。
利用者の行動と例外処理による業務要件
業務要件には、利用者や使うデータ、条件、承認を書きます。機能名を並べただけの一覧は避けます。
- 通常処理：業務の開始から、結果を次の業務へ渡すまでを書きます。
- 例外処理：取消、差し戻し、重複、期限切れ、通信失敗を含めます。
- 運用変更：再送、権限変更、組織改編、月次・年次締めを扱います。
例外処理を足すと、画面やAPIだけでなく、DB制約やバッチ、監査ログ、テストケースにも影響します。
非機能要件は、測定方法まで決めて書きます。「高速」「安全」「止まらない」といった言葉だけでは、合格を判定できません。
ピーク時の同時接続数や主要画面の応答時間、夜間バッチの完了時刻を定めます。月間稼働率やRTO・RPOも決めます。ログ保存期間、障害通知時間、脆弱性修正期限も、あわせて定めます。
業務、情報システム、セキュリティ、経理・法務が、要件をレビューします。
発注後の承認者も、あらかじめ決めておきます。
技術要件の移行性と保守性
技術要件では、製品名だけでなく、選定理由や代替案、更新方針も示します。将来の変更で必要になる修正範囲も、納品物に残します。
- 基盤：Java・JDKの版、Jakarta EEのプロファイル、サーバー、DB、OSを示します。
- 開発運用：コンテナ、CI/CD、監視、ログ、認証基盤を指定します。
Jakarta EE、Spring Boot、Quarkusは、人材や標準API、サーバー運用で比べます。クラウド方針や長期サポート、ライブラリも比較の観点にします。
RFPには、製品を固定する理由と代替案、サポート終了時の更新方針も書きます。
独自APIを使う場合は、サーバーを変えるときに修正が要る箇所を一覧にします。
JBoss EAP 8.1はJakarta EE 10に対応していますが、全仕様を同じ条件で使えるとは限りません。対応表とPoCで確かめます（出典: Red Hat「JBoss Enterprise Application Platform Supported Standards」、2026年更新）。
RFPに明記するセキュリティと納品物
個人情報を扱う場合は、安全管理措置を非機能要件に落とし込みます。
ガイドラインでも、アクセス範囲の限定や従業者の識別・認証が例示されています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。
- アクセスと記録：認証と最小権限、管理者操作の監査ログを定めます。
- 保護と対応：通信・保存データの暗号化、バックアップ、診断、依存ライブラリ更新を決めます。
- 委託管理：事故連絡と再委託先の管理を明記します。
納品物には、ソースコードのほか、要件定義書、基本・詳細設計書、API仕様、DB定義も含めます。
テスト計画と結果、移行・切り戻し手順、運用設計、構成図も確認します。
監視設定やIaC、ライセンス一覧、SBOM、管理者マニュアル、教育資料も、納品の範囲に含めます。
著作権の帰属、第三者ライブラリの利用条件、ソースと設定の引き渡しは、契約の前に決めます。
開発環境の再現方法と、脆弱性が見つかった場合の修正責任も、契約で定めます。
Java EEの外注で選ぶ契約形態と責任分界
契約形態は、名称だけでなく、成果物や指揮命令、検収、変更管理を合わせて判断します。
個別契約の内容は、法務担当と確認します。
- 請負：業務要件と成果物が確定した開発に適します。
- 準委任：調査や要件定義など、協議しながら進める業務に適します。
請負契約で具体化する成果物と検収条件
請負契約では、成果物と検収の条件を具体化します。
変更時の手順や見積前提も、あらかじめ合意しておきます。
固定価格であっても、資料不足や前提の変化を委託先が無制限に負担するわけではありません。そのため、データ件数や連携仕様、利用者数、既存環境へのアクセス、レビュー期限を見積の前提として書いておきます。
- 完成・検収条件：業務シナリオ、性能試験の合格基準、移行データ照合、障害重大度、受入期間を定めます。
- 検収後の対応：不具合対応と保守開始日を決めます。仕様変更は、受付方法や費用・納期への影響を見積もり、変更管理票に残します。
- 見積の前提：前提が曖昧だと、資料不足や条件の変化が起きたとき、責任範囲も不明確になります。
- 前提変更：崩れた前提に対して、再見積と協議の手順まで合意します。
準委任契約で管理する作業範囲と意思決定
準委任では、作業範囲と発注側の意思決定を、きちんと管理する必要があります。
完成責任や納期も、請負と同じとは限りません。
- 依頼する作業：一定期間、専門家と調査・設計・開発を進めます。要件変更や既存コードの調査、移行方式の検証に適します。
- 進捗確認：月次報告で、課題や次月計画、残課題、判断待ちを見ます。
- 自社の役割：プロダクト責任者と業務側の意思決定者を置き、委託する作業と、自社で決める業務ルールや受入条件を分けます。
- 指揮命令と相談：直接の指揮命令は、契約や労務上の問題につながる可能性があります。そのため、役割と連絡経路を決め、必要に応じて法務・労務に確認します。
再委託・知的財産・保守の境界
開発では、アプリやサーバー、DB、監視、クラウド、診断など、複数社が関わることがあります。そのため、再委託の範囲と管理責任を確認しておきます。
- 情報管理：海外拠点への持ち出し、秘密情報、個人データの扱いを押さえます。
- 事故対応：事故時の連絡期限と、実際の担当者を確かめます。
- 知的財産：コード・設計書の利用権、汎用部品、第三者ライセンスを定めます。
著作者人格権への対応も確認します。
開発したテスト資産やフレームワークの扱いも、決めておきます。
保守契約では、窓口や対応時間、重大度別の一次応答、復旧目標を決めます。
脆弱性パッチやJDK・サーバーの更新、追加開発の単価も定めます。
保守会社を分ける場合は、引き継ぎ期間と文書の品質を受入条件にします。
Java EEのシステム開発費用相場とコストの内訳
Java EEの開発には、全国で共通の価格表がありません。
費用は、規模や業務の複雑さ、既存資産によって変わります。加えて、サーバーや連携、移行、試験、保守水準も影響します。
ここで示す金額は、公開相場と人月モデルから推定したレンジです。個別案件の確定価格ではありません。
また、商用ライセンスやクラウド費用の有無も、分けて見積もります。
規模別の初期開発費のレンジ
初期開発費と期間は、業務規模や含める機能によって幅があります。次に示すのは、規模と条件ごとの目安です。
- 小規模：単一業務のWeb化は300万〜800万円、2〜6か月程度です。
- 中規模：複数部門や外部API等を含み800万〜5,000万円、6〜12か月程度です。
- 大規模・基幹：複数拠点や段階移行等を含み5,000万円〜3億円超、12か月〜2年以上の場合があります。
小規模の目安は、画面、API、RDBが中心で、連携や移行が少ない場合です。社内申請や顧客管理などが当てはまります。
中規模には、受発注や販売管理などが当てはまります。複数部門や外部API、バッチ、帳票、権限、データ移行を含みます。
大規模では、大量取引や複雑な連携、冗長化、24時間運用を含むことがあります。
既存のJava EEを移行する場合は、1,000万〜1億円超の幅があります。移行費にはコード調査や`javax.*`変換、サーバー更新が関わります。加えて、回帰試験やクラウド化、データ移行も含まれます。
資料の有無や業務の難しさによって、費用は上下します。
人月単価と工数で見る見積の妥当性
人月モデルは、見積の構造を確認するために使います。掲載単価は、受託会社の発注額そのものではありません。
フリーランススタート掲載案件の平均月額単価は、2025年4月に74.6万円でした（出典: エン・ジャパン株式会社、2025年4月集計）。
たとえば、5人が6か月働くと30人月になります。単価が74.6万円なら約2,238万円ですが、それが発注額と同じになるとは限りません。
- 追加費用：PMや分析、レビュー、試験も加わります。さらに、会社経費や環境、管理、リスク対応も含まれます。
- 役割別工数：PM、PL、SE、PGの人数と期間を確認します。加えて、テスター、インフラ、セキュリティの担当も見ます。
- 工程別工数：要件定義、設計、実装、テスト、移行、管理の工数を、工程ごとに把握します。
保守・ライセンス・クラウドを含む3〜5年の総額
初期費用が低くても、保守や基盤費を含めると総額は変わります。そのため、3〜5年の総保有コストで比べます。
- 運用保守：監視、障害対応、バックアップ、ログ保管を確認します。
- 基盤と更新：商用サーバー、クラウド、WAF、JDK更新を含めます。
- 追加対応：診断、追加開発、バージョン更新を分けます。
保守費の目安は、初期開発費の年15〜25％、または月15万〜80万円程度です。24時間監視や即時対応の有無で、この幅は変わります。
このレンジも、案件の条件から算出した目安です。契約前には、個別の見積が必要です。
初期費と移行、ライセンスは、分けて見積もります。月額利用料や保守、追加開発、更新、終了時のデータ返却も、個別の項目として扱います。
SaaSやパッケージで代替できる標準業務は、初期が数十万〜数百万円、月額で抑えられる可能性があります。
独自の審査、計算、製造、連携ロジックを、スクラッチで開発する場合は、3〜5年の総額で比べます。
委託先の選定とJava EEの見積比較で見るポイント
委託先は、資産との近さや、業務と技術をつなぐ力、知識移管を確認して選びます。知名度や総額だけでは選びません。
候補企業には同じRFPを渡し、見積形式や前提、除外を揃えます。体制や日程、リスク、検収条件も、同じ基準で比べます。安い提案であっても、含まれる範囲を確認します。
条件の近さで見る実績
実績は、自社の条件に近い案件か、移行や運用の実力も含めて見ます。「Javaの実績が豊富」という説明だけでは判断できません。
- 技術と基盤：JDK、Java EE・Jakarta EE、サーバー、DBを照合します。
- 業務と運用：規制、データ量、同時接続、24時間運用を比べます。
- 移行と検証：移行方式、構成差分、試験、保守体制を確認します。
WebLogic、WebSphere、JBoss EAP、Cosminexusなども、自社の利用環境と近いかを確かめます。可能であれば、提案の時点で、その根拠も説明してもらいます。
営業だけでなく、担当予定者の経験年数も確認します。PM、設計者、開発、インフラ、試験、保守の担当が対象です。
担当者の変更や交代時の引き継ぎ、再委託、稼働率、遠隔と常駐の割合も聞きます。提案内容と実行体制の差も、ここで見極めます。
前提・除外・予備費をそろえた見積比較
合計だけでなく、工程・役割・成果物ごとに比べます。費用や工数の対象範囲をそろえることが大切です。
- 工程費：要件定義から保守まで、各工程の費用が入っているかを確認します。
- 役割工数：PM、開発、基盤、セキュリティ、移行担当を見ます。
- 除外費用：テストデータや外部改修、ライセンス、試験環境、診断費が、除外に入っているかを押さえます。
価格差の理由を質問し、高い・安いだけで判断しないようにします。コード調査や改修、回帰試験、データ整備の工数も確認します。
運用設計、文書、稼働後支援が抜けると、後工程で追加費用になることがあります。
未確定の要件は、予備費や別見積の条件にします。また、発注時に許容できる追加費用の上限を、社内で決めておきます。
委託先への質問で見るリスク対応力
提案の説明では、移行条件や検証方法を具体的に質問します。説明が抽象的な場合は、成果物や判定基準まで確認します。
- 移行調査：`javax.*`や非標準API、古いライブラリをどう検出しますか。
- 性能検証：どの環境・データ量で性能要件を検証しますか。
- 運用と保守：障害時の一次対応時間や脆弱性・JDKの更新費用は保守に含まれますか。
回答があいまいな場合は、成果物名や判定基準、類似課題、担当者を追加で確かめます。
情報を出し切れない場合は、現状調査とRFP作成の支援だけを先に委託する方法もあります。
業務の優先順位や投資の判断は、自社で行います。
週次の意思決定会議や課題・変更管理、品質指標、経営層への報告を設けます。
長期運用では、ベンダー任せにしないことが欠かせません。
Java EEのシステム発注でよくある質問
費用や移行の可否は、現行の資産と要件で変わります。そのため、一般的な目安と、個別に確認が必要な事項を分けて示します。
Java EEは古い技術なので、発注時に採用しない方がよいですか？
新規開発と既存資産を分け、仕様の継続性や運用条件を確認したうえで判断します。
- 仕様の継続：Java EEは旧称で、仕様群はJakarta EEとして継続しています。既存資産を、すぐに廃棄する必要はありません。
- 新規開発：Jakarta EE、Spring Boot、Quarkusを、要件と運用体制で比べます。
- 既存資産：`javax.*`、JDK、サーバー、ライブラリ、保守期限を調べたうえで、延命・移行・段階的な切り出しのどれにするかを判断します。
Java EEのシステム開発費用はどのくらいかかりますか？
小規模は300万〜800万円、中規模は800万〜5,000万円、大規模・基幹は5,000万円〜3億円超が目安です。
既存のJava EEを移行する場合は、1,000万〜1億円超まで幅があります。変換や回帰試験、データ移行、サーバー更新、クラウド化の有無で、金額は変わります。
ライセンスやクラウド、保守、セキュリティ診断は、含むかどうかを分けて見積もります。
Java EEに詳しい担当者が社内にいなくても外注できますか？
外注は可能ですが、業務側の責任者と意思決定者は社内に置く必要があります。まずは、資産調査や業務ヒアリング、RFP作成の支援を依頼できます。
成果物とリスクを確認してから開発へ進めば、技術判断を委託先に丸投げしにくくなります。提案の時点では、担当者、説明、納品物を確認します。あわせて、知識移管と稼働後の保守体制も見ておきます。
既存のWebLogicやWebSphereを移行するとき、何を確認しますか？
JDKやJava EE仕様、`javax.*`・`jakarta.*`、サーバー固有APIを調べます。さらに、JDBCドライバや認証、JMS、バッチ、帳票、外部連携も確かめます。
設定や性能、運用手順も確認します。そのうえで、代表機能のPoCと回帰試験によって、変換・改修・据え置きの範囲を決めます。
移行先の仕様対応とサポート期間に加え、障害時の切り戻しや、自社で保守できるかも評価します。
まとめ｜Java EEのシステム発注における要件・契約・総額の判断
まず、Java EEとJakarta EEの関係や資産、業務、移行範囲を整理します。
RFPには、性能や可用性、セキュリティ、監査を記します。バックアップや納品物、保守SLAも、あわせて書きます。
請負と準委任の責任分界を明確にし、運用までの費用と事業上の効果を見ます。
資産台帳と発注条件の作成
委託先へ相談する前に、JDKやサーバー、DB、ライブラリを一覧にします。連携やバッチ、帳票、権限、データ量、運用課題も、同じ一覧に加えます。
不明な項目は未調査として残し、調査やPoCを初期の範囲に含めます。その結果を見て、次の発注を判断できます。
運用までを含めた見積の比較
費用の範囲、委託先の実行体制、移行リスクを併せて確認し、初期費用だけに偏らないように判断します。
- 費用範囲：同じRFPで、工程工数や前提、除外を照合します。さらに、ライセンス、クラウド、保守、更新、診断、移行後支援も比べます。
- 実行体制：技術力に加えて、業務理解や試験、障害対応を確認します。文書や知識移管、担当者も見て、3〜5年の総額で判断します。
- 移行判断：リスクの高い範囲をPoCで確かめてから全面刷新に進むことが、発注の成功につながります。
▼全体ガイドの記事
・Java EEのシステム開発の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。