Java EEのシステム開発の発注/外注/依頼/委託方法について

Java EEのシステム開発を発注・外注するなら、技術名だけで依頼先を決めず、既存資産・業務要件・運用条件・移行範囲を整理したうえで、複数社の提案と見積を同じ条件で比較することが重要です。

Java EEは現在Jakarta EEへ発展していますが、現場には旧Java EE 6〜8のシステム、WebLogicやWebSphereなどの商用サーバー、`javax.*`を使う既存アプリが残っています。この記事では、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先の選定、見積比較、失敗を防ぐ確認事項まで、発注担当者が社内で説明しやすい順に解説します。

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

Java EEのシステムとは何ですか？発注前に何を決めますか？

Java EEのシステムは、企業向けのWeb・業務アプリケーションを構築するための標準仕様群を使ったシステムです。画面を作るServletやJSP、業務ロジックを管理するCDIやEJB、データアクセスを担うJPA、トランザクションを管理するJTA、REST APIのJAX-RS、認証・認可、メッセージング、バッチなどを組み合わせて構築します。業務パッケージそのものではないため、発注時には「Java EEで作る」という技術要件だけでなく、実現したい業務と運用水準を定義する必要があります。

Java EEはOracleからEclipse Foundationへ移管され、現在はJakarta EEという名称で発展しています。特にJakarta EE 9以降はAPIのパッケージ名が`javax.*`から`jakarta.*`へ変わったため、旧システムをそのまま新しいアプリケーションサーバーへ載せられるとは限りません。発注前に、利用中のJDK、アプリケーションサーバー、Java EEのバージョン、依存ライブラリ、非標準API、データベース、外部連携を調べることが大切です。

2025年6月に正式リリースされたJakarta EE 11は、Java 17以上を対象にし、Java 21の仮想スレッド、Jakarta Data、互換性テストの近代化などを取り入れています（出典: Eclipse Foundation「Jakarta EE 11 Release」、2025年）。2026年時点ではJakarta EE 12も開発中であるため、新規開発では対応するアプリケーションサーバーの認定範囲とサポート期間を確認し、既存開発では移行の段階を分けて計画します。

業務システムの見積が膨らむ原因は、画面数だけでは説明できません。夜間バッチ、帳票、権限、承認経路、他システムとのAPI・ファイル連携、データ移行、監査ログ、バックアップ、障害時の切り戻し、利用者教育までが開発範囲に含まれるためです。たとえば受発注システムなら、受注登録画面だけでなく、在庫引当、出荷連携、請求、締め処理、取消、再送、エラー時の手動復旧まで業務シナリオに含めて整理します。

発注前に決めるべき項目は、目的、対象業務、利用者と拠点、データ量、外部連携、希望稼働日、同時接続数、可用性、RTO・RPO、セキュリティ、納品物、運用体制です。未確定の項目を無理に決める必要はありませんが、「未確定のまま提案を依頼する項目」と「発注までに確定する項目」を分けておくと、後から追加費用になる範囲を把握しやすくなります。

Java EEのシステム開発を発注・外注する進め方

発注は、相談先を探してすぐに開発を始めるのではなく、企画、現状調査、要件整理、提案比較、契約、設計・開発、テスト、移行、運用引き継ぎの順に進めます。既存Java EEの刷新では、最初から全面移行を約束するより、短期間のアセスメントやPoCを置いて不確実性を減らす方が安全です。

発注形態は、システム全体を一社へ任せる一括請負、上流の企画・要件定義を支援会社へ依頼する支援型、開発チームの人員を補うラボ型・準委任型、既存システムの調査だけを切り出すアセスメント型に分けて考えます。要件が固まっていて成果物と納期を明確にできる場合は請負が向きますが、ブラックボックス化した既存資産の調査や業務整理まで含む場合は、調査フェーズを準委任で始め、確定した範囲を請負へ移す方法が現実的です。

一括請負は窓口を集約しやすい一方、契約後に仕様変更が増えると追加費用や納期延長が起きやすくなります。準委任は不確実な課題を一緒に解くのに向いていますが、発注側にも意思決定者とレビュー担当者が必要です。人員補充だけを目的にすると、業務設計や品質保証の責任分界が曖昧になりやすいため、成果物、役割、レビュー方法、報告頻度を契約書と作業計画書へ記載します。

既存Java EEの発注で最初に依頼したい成果物は、ソースコード・設定ファイル・ライブラリ・サーバー構成・DB・ジョブ・帳票・外部連携・運用手順を一覧にした現状資産台帳です。台帳には、`javax.*`か`jakarta.*`か、JDKのバージョン、サーバー製品とエディション、独自拡張、保守期限、脆弱性対応状況、担当者の有無を記録します。ソースコードを読まずに画面一覧だけで移行費を出す提案は、比較の前提として注意が必要です。

PoCでは、代表的な画面、認証、DBアクセス、バッチ、外部API、帳票など、移行リスクが高い処理を小さく動かします。`javax.*`から`jakarta.*`への変換、利用中サーバーの互換性、性能、ログ出力、コンテナ化の可否を確認し、変換できない箇所と代替策を成果物に残します。PoCの目的は本番を完成させることではなく、見積の前提とリスクを事実に近づけることです。

開発は、全機能を一度に作るのではなく、業務上のまとまりで優先順位を付けます。たとえば顧客・商品・権限を先に整え、その後に受注・請求・外部連携を開発するなど、データの流れと利用開始の順番を設計します。各イテレーションで利用部門が受入条件を確認し、未解決の課題を次の範囲へ持ち越すか、リリース条件を見直すか判断します。

テストでは、単体・結合・総合・受入だけでなく、同時接続数、バッチ時間、障害復旧、権限誤設定、データ移行の件数照合、外部連携の再送、バックアップからの復元を確認します。本番移行では、並行稼働、切り戻し条件、移行対象データの凍結時刻、利用者教育、問い合わせ窓口、稼働後30日・90日の改善体制まで合意しておくと、リリース直後の混乱を抑えられます。

RFPと要件整理でJava EEの発注条件を固める方法

RFPは、委託先へ「何を、どの品質で、いつまでに、どの条件で作ってほしいか」を伝える文書です。技術の指定だけを厚くするのではなく、現状の課題、対象業務、利用者、業務量、既存資産、連携先、制約、予算の考え方、提案してほしい選択肢を記載します。発注側の判断材料が増えるほど、提案書の比較が容易になり、見積の抜け漏れも見つけやすくなります。

要件整理では、機能名を並べるだけでなく、誰が、どのデータを使い、どの条件で、何を承認し、どの結果を次の業務へ渡すかを記載します。通常処理だけでなく、取消、差し戻し、重複登録、期限切れ、通信失敗、再送、権限変更、組織改編、月次・年次締めも対象にします。これらの例外処理が後から追加されると、Java EEの画面やAPIだけでなく、DB制約、バッチ、監査ログ、テストケースまで影響します。

非機能要件は、曖昧な「高速」「安全」「止まらない」ではなく、測定方法まで決めます。たとえばピーク時の同時接続数、主要画面のレスポンスタイム、夜間バッチの完了時刻、月間稼働率、RTO・RPO、ログ保存期間、障害通知の時間、脆弱性修正の期限を記載します。業務部門、情報システム部門、セキュリティ担当、経理・法務などがレビューし、発注後に誰が承認するかも決めておきます。

Java EEの技術要件では、利用するJava・JDKのバージョン、Jakarta EEのプロファイル、アプリケーションサーバー、DB、OS、コンテナ基盤、CI/CD、監視、ログ、認証基盤を指定または候補として示します。ただし製品名を固定する場合でも、なぜ必要なのか、代替案を提案してよいのか、サポート終了時にどう更新するのかを記載します。ベンダーの独自APIに依存する場合は、将来のサーバー変更時に修正が必要な範囲を納品物として残します。

新規開発でJakarta EEを採用するか、Spring BootやQuarkusを採用するかは、流行ではなく既存人材、標準APIの利用範囲、アプリケーションサーバーの運用、クラウド・コンテナ方針、長期サポート、採用予定のライブラリで判断します。たとえばJBoss EAP 8.1はJakarta EE 10に対応していますが、利用する仕様のすべてを同じ条件で使えるとは限らないため、候補製品の対応表とPoCで確認します（出典: Red Hat「JBoss Enterprise Application Platform Supported Standards」、2026年更新）。

個人情報を扱う場合は、認証、認可、最小権限、管理者操作の監査ログ、通信・保存データの暗号化、バックアップ、脆弱性診断、依存ライブラリの更新、インシデント連絡、再委託先の管理を非機能要件に落とします。個人情報保護委員会の通則編では、個人データを扱う従業者の識別・認証や、アクセス可能な範囲を限定するアクセス制御が安全管理措置の例として示されています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。

納品物は、ソースコードだけでなく、要件定義書、基本・詳細設計書、API仕様、DB定義、テスト計画と結果、移行手順、切り戻し手順、運用設計、監視設定、構成図、IaC、ライセンス一覧、SBOM、管理者マニュアル、教育資料まで確認します。著作権の帰属、第三者ライブラリの利用条件、ソースコードと設定の引渡し、開発環境の再現方法、脆弱性が見つかった場合の修正責任も契約前に決めます。

Java EEの外注で選ぶ契約形態と責任分界

契約形態は、請負か準委任かを名前だけで選ばず、成果物・指揮命令・検収・変更管理の仕組みと合わせて判断します。業務要件と成果物が確定している開発は請負、現状調査・要件定義・技術支援のように作業の進め方を協議しながら進める業務は準委任が適しやすいです。実際の契約では、委託範囲と個別契約の内容を法務担当と確認します。

請負契約では、何を完成とみなすかが重要です。画面やAPIの本数だけでなく、業務シナリオ、性能試験の合格基準、移行データの照合、障害の重大度、受入期間、瑕疵や不具合への対応、検収後の保守開始日を定義します。仕様変更の受付方法、変更が費用・納期へ与える影響の見積、緊急変更の扱いを変更管理票に残すことで、口頭依頼による認識違いを防ぎます。

固定価格の請負でも、発注側の資料不足や前提条件の変化まで委託先が無制限に負担するわけではありません。データ件数、連携先の仕様、利用者数、既存環境へのアクセス、レビュー期限など、見積の前提を契約書・提案書・要件定義書のどこに置くかを揃えます。前提が崩れたときの再見積と協議の手順まで合意することが必要です。

準委任契約では、一定期間の作業を依頼し、専門家と一緒に調査・設計・開発を進めます。要件が変わりやすいプロジェクトや、既存コードの調査、移行方式の検証には向いていますが、成果物の完成責任や納期を請負と同じように期待すると齟齬が生じます。月ごとの作業報告、消化した課題、次月の計画、残課題、判断待ち事項を定例で確認します。

準委任で特に重要なのは、発注側のプロダクト責任者と業務側の意思決定者です。委託先へ任せる作業と、発注側が決める業務ルール・優先順位・受入条件を分けます。委託先の担当者へ発注側が直接指揮命令する場合は、契約や労務上の問題につながる可能性があるため、役割と連絡経路を整理し、必要に応じて法務・労務の確認を受けます。

Java EEの開発では、アプリケーション、サーバー、DB、監視、クラウド、セキュリティ診断など複数の会社が関わることがあります。再委託を認める範囲、再委託先の管理責任、海外拠点へのデータ持ち出し、秘密情報の管理、個人データの取扱い、事故時の連絡期限を確認します。特に、一次請け会社の提案金額だけを見ていると、実際の担当者や障害時の連絡先が見えにくくなるため注意します。

知的財産では、開発したソースコード・設計書・テスト資産の利用権、汎用部品やフレームワークの扱い、第三者ライセンス、著作者人格権への対応を確認します。保守契約では、問い合わせ窓口、対応時間、重大度ごとの一次応答、復旧目標、脆弱性パッチ、JDKやサーバーのバージョンアップ、追加開発の単価を定めます。初期開発と保守を別会社へ分ける場合は、引き継ぎ期間とドキュメントの品質を受入条件に含めます。

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

Java EE固有の全国一律の価格表はないため、費用はシステム規模、業務の複雑さ、既存資産の状態、サーバー製品、連携数、データ移行、性能・セキュリティ試験、保守水準で変わります。以下の金額はJava・業務システムの公開相場と人月モデルから推定したレンジであり、個別案件の確定価格ではありません。商用サーバーのライセンスやクラウド費用を含むかどうかでも総額が変わるため、見積書では分けて表示してもらいます。

小規模の社内申請、顧客管理、単一業務のWeb化であれば、初期開発費は300万〜800万円、期間は2〜6か月程度が一つの目安です。画面・API・RDBが中心で、連携や移行が少ない場合のレンジです。中規模の受発注・販売管理で、複数部門、外部API、バッチ、帳票、権限、データ移行を含む場合は、800万〜5,000万円、6〜12か月程度を見込みます。

複数拠点、大量トランザクション、複雑な連携、冗長化、24時間運用、段階移行を含む大規模・基幹システムは、5,000万円〜3億円超、12か月〜2年以上のレンジになることがあります。既存Java EEの移行は、コード調査、`javax.*`から`jakarta.*`への変換、サーバー更新、回帰試験、クラウド化、データ移行を含めて1,000万〜1億円超の幅で見る必要があります。これは規模別の目安であり、業務難易度や既存資料の有無で上下します。

人月モデルは、見積の構造を確認するために使います。公開データでは、エン・ジャパンの「フリーランススタート」に掲載された2025年4月のフリーランスエンジニア案件の平均月額単価は74.6万円でした（出典: エン・ジャパン株式会社、2025年4月集計）。これはフリーランス案件の掲載単価であり、受託会社の発注額そのものではありませんが、技術者工数を考える際の参考になります。

たとえば5人が6か月稼働すると30人月です。単価74.6万円を単純に掛けると約2,238万円ですが、実際の発注額にはPM、業務分析、設計レビュー、テスト、会社経費、環境、管理、リスク対応などが加わるため、同じ金額になるとは限りません。役割別にPM・PL・SE・PG・テスター・インフラ・セキュリティの人数と期間を出してもらい、要件定義、設計、実装、テスト、移行、管理の工数を確認します。

初期費用が安くても、保守運用、商用アプリケーションサーバーのサポート、クラウドの常時稼働、WAF、監視、バックアップ、ログ保管、セキュリティ診断、JDK・ミドルウェア更新を含めると総額が変わります。保守費は初期開発費の年15〜25％、または月15万〜80万円程度を一つの目安にできますが、24時間監視や障害時の即時対応を含むかで大きく変わります。このレンジも案件条件から算出した目安で、契約前に個別見積が必要です。

見積比較では、初期開発費、移行費、ライセンス・サブスクリプション、クラウド、保守、追加開発、バージョンアップ、終了時のデータ返却を分けます。SaaSやパッケージで代替できる標準業務は初期数十万〜数百万円と月額で抑えられる可能性がありますが、独自の審査、計算、製造、連携ロジックをスクラッチ開発する場合は、3〜5年の総保有コストで比較します。

委託先の選定とJava EEの見積比較で見るポイント

委託先は、会社の知名度や見積総額だけでなく、同じ種類の資産を扱えるか、業務と技術を橋渡しできるか、発注側に知識を移管できるかで選びます。候補企業には同じRFPを渡し、見積書の形式、前提条件、除外項目、体制、スケジュール、リスク、検収条件を揃えてもらいます。安い提案が優れているとは限らず、範囲が抜けているために安く見えていないかを最初に確認します。

「Javaの実績が豊富」という説明だけでは不十分です。JDKの世代、Java EE・Jakarta EEの仕様、WebLogic・WebSphere・JBoss EAP・Cosminexusなどのサーバー、DB、業界規制、データ量、同時接続数、24時間運用、移行方式が自社と近い事例を確認します。可能であれば、提案時に画面の実績ではなく、アーキテクチャ、移行前後の差分、テスト方法、稼働後の保守体制を説明してもらいます。

担当予定者の経験も重要です。営業や提案責任者だけでなく、実際のPM、アーキテクト、Java EE開発者、インフラ担当、テスト責任者、保守責任者の役割と経験年数を確認します。契約前に担当者が変わる可能性、交代時の引き継ぎ、再委託の有無、稼働率、遠隔・常駐の割合を聞いておくと、提案書と実行体制の差を見極めやすくなります。

見積書は合計金額だけでなく、工程別・役割別・成果物別に比較します。要件定義、設計、開発、テスト、移行、教育、リリース、保守の各費用が含まれているか、PM・SE・PG・インフラ・セキュリティ・データ移行の工数が計上されているかを確認します。テストデータ作成、外部システム側の改修、商用ライセンス、クラウド環境、性能試験環境、診断費が除外されていないかも重要です。

各社の見積を比較するときは、価格の差を「高い・安い」で終わらせず、差分の理由を質問します。特に、既存コードの調査工数、移行できない機能の改修、回帰試験、データクレンジング、運用設計、ドキュメント、稼働後の支援が抜けると、後工程で追加費用になりやすいです。未確定要件は、予備費や別途見積の条件として示してもらい、発注時に許容できる上限を社内で決めます。

提案説明では、「`javax.*`の既存アプリをどの条件で`jakarta.*`へ移行できますか」「非標準APIや古いライブラリはどう検出しますか」「性能要件をどの環境・データ量で検証しますか」「障害時に誰が何分以内に一次対応しますか」「脆弱性やJDKの更新費用は保守に含まれますか」と質問します。回答が抽象的な場合は、成果物名、判定基準、過去の類似課題、担当者を追加で確認します。

発注側が情報を出し切れない場合は、現状調査とRFP作成支援だけを先に委託する方法もあります。要件定義を外部へ任せる場合でも、業務の優先順位、投資判断、リスク許容度は自社が決めます。ベンダー任せにせず、週次の意思決定会議、課題管理、変更管理、品質指標、経営層への報告を設けることが、長期運用するJava EEのシステムでは特に重要です。

Java EEのシステム発注でよくある質問

ここでは、発注担当者が委託先へ相談する前に抱きやすい疑問へ回答します。費用や移行可否は現行資産と要件で変わるため、一般的な目安と、個別に確認すべきポイントを分けて考えます。

Java EEという名称は旧称ですが、仕様群はJakarta EEとして継続しており、既存Java EE資産をすぐに廃棄する必要はありません。新規開発ではJakarta EE、Spring Boot、Quarkusなどを要件と運用体制で比較し、既存システムでは`javax.*`、JDK、サーバー、ライブラリ、保守期限を調査して、延命・移行・段階的な切り出しを判断します。

目安は、小規模で300万〜800万円、中規模で800万〜5,000万円、大規模・基幹で5,000万円〜3億円超です。既存Java EEの移行は1,000万〜1億円超まで幅があり、`javax.*`から`jakarta.*`への変換、回帰試験、データ移行、サーバー更新、クラウド化の有無で大きく変わります。ライセンス、クラウド、保守、セキュリティ診断を含むかを分けて見積もることが必要です。

外注できますが、業務側の責任者と意思決定者は社内に必要です。まず現状資産の調査、業務ヒアリング、RFP作成支援を依頼し、成果物とリスクを確認してから開発へ進むと、技術判断を委託先に丸投げしにくくなります。提案時には、担当者の経験、説明の分かりやすさ、納品物、知識移管、稼働後の保守体制を確認します。

JDK、Java EEの仕様、`javax.*`・`jakarta.*`、サーバー固有API、JDBCドライバ、認証、JMS、バッチ、帳票、外部連携、設定ファイル、性能、運用手順を確認します。代表機能を使ったPoCと回帰試験を行い、変換・改修・据え置きの範囲を決めます。移行先の対応仕様やサポート期間だけでなく、障害時の切り戻しと、移行後に自社で保守できるかも評価します。

まとめ｜Java EEのシステム発注は要件・契約・総額で判断します

Java EEのシステムを発注・外注するときは、最初にJava EEとJakarta EEの関係、既存資産の状態、対象業務、移行範囲を整理します。次に、RFPへ機能要件だけでなく、性能、可用性、セキュリティ、監査、バックアップ、納品物、保守SLAを記載し、請負・準委任の責任分界を明確にします。

委託先へ声をかける前に、JDK・サーバー・DB・ライブラリ・連携・バッチ・帳票・権限・データ量・運用課題を一覧化します。分からない項目は未調査として残し、現状調査やPoCを最初の委託範囲に含めます。これにより、根拠の薄い一括見積ではなく、調査結果に応じて次の発注判断ができるようになります。

候補会社の比較では、同じRFPで工程別の工数、前提、除外、ライセンス、クラウド、保守、更新、セキュリティ、移行後の支援を確認します。技術力だけでなく、業務理解、テストと障害対応、ドキュメント、知識移管、契約後の責任者まで見て、3〜5年の総額と事業上の効果で判断します。最初から全面刷新を決めず、リスクの高い範囲をPoCで検証することが、Java EEのシステム発注を成功へ近づけます。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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