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

JSPのシステム開発を発注・外注するなら、JSPの対応可否だけでなく、既存資産の解析、要件定義、Java・Jakarta移行、データ連携、運用保守まで含めて委託範囲を決めることが重要です。

JSPは業務Webシステムで長く使われてきた技術ですが、発注時に画面数だけを伝えると、後から仕様確認や移行、セキュリティ対策の費用が膨らみやすくなります。この記事では、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先選定、見積比較、よくある質問まで、JSPのシステムを外注する担当者がそのまま使える順番で解説します。

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

JSPのシステムを発注・外注する前の全体像

JSPのシステムとは、Javaを使うWebアプリケーションで、サーバー側のデータをHTML画面として表示する仕組みです。ServletやControllerがリクエストを受け、Serviceなどの業務ロジックが処理し、JSPがModelの結果を画面に描画する役割分担が基本となります。したがって、発注仕様に「JSPで作成」と一言だけ書くと、どこまでをJSPに任せるのか、既存のJavaやデータベースをどう扱うのかが不明確になります。

最初に決めるべきことは、JSPを残すかどうかではなく、業務を止めずにどの範囲を改善するかです。既存画面の軽微な修正であれば、現在のJSP、Servlet、データベース、認証基盤を活用する保守改修が候補となります。Javaやアプリケーションサーバーが古く、脆弱性対応や人材確保に不安がある場合は、実行環境を新しくする基盤移行を検討します。利用者体験やスマートフォン対応を大きく改善したい場合は、JSP画面を段階的にAPIや別の画面技術へ置き換える刷新が候補となります。

この三つを混ぜたまま見積を依頼すると、会社ごとに前提が違うため比較できません。発注前に「既存JSPの改修」「javax.*からjakarta.*への移行」「画面の再構築」を別の作業パッケージとして整理すると、価格差と提案内容を見分けやすくなります。

発注資料には、JSPファイルの数だけでなく、画面・帳票・バッチ・API・外部連携・権限・データ移行の関係を記載します。ログイン、検索、一覧、登録、承認、CSV出力などの機能を業務単位に分け、画面から呼び出すServletやController、データベース、ファイル保管先を確認します。仕様書が残っていない場合は、開発会社に現行解析を先行発注し、画面一覧と業務フローを作成してから本開発を依頼する方法が安全です。

2026年時点のJakarta Server Pages 3.1では、Servlet 6.0で削除されたSingleThreadModelに関連する属性などが非推奨となっています（出典: Eclipse Foundation「Jakarta Server Pages 3.1」、2026年確認）。旧Java EE時代のjavax.*を使うシステムは、移行先のコンテナやライブラリが決まるまで互換性を断定できません。委託先には、現在のJavaバージョン、コンテナ、JSP仕様、タグライブラリ、認証方式、依存ライブラリを調査する工程を求めます。

JSPのシステム開発に適した発注形態の選び方

発注形態は、システムの不確実性、社内のIT人材、納期、責任分界で選びます。既存JSPの小さな改修と、業務や技術を見直す新規開発では、適する発注方法が異なります。最初から一括請負に固定するより、調査・要件定義と開発・保守を分けたほうが、仕様の見えないレガシーシステムではリスクを抑えやすくなります。

請負契約は、合意した成果物を完成させ、検査に合格した状態で引き渡す形態です。画面追加の対象、入力項目、帳票、テスト条件、納期が固まっている保守改修や、小規模な新規システムに向いています。発注者は完成責任を委託先に持たせやすい一方、要件変更のたびに追加費用や納期変更が生じやすくなります。

請負で依頼する場合は、成果物を「JSPファイル」とだけ書かず、設計書、ソースコード、テスト仕様書・結果、データ移行手順、環境設定、運用手順、脆弱性診断結果まで定義します。受入条件、検収期限、瑕疵対応、変更管理の方法も契約書や仕様書に含めます。

準委任契約は、専門家の作業や役務の提供を受ける形態です。現行JSPの解析、要件定義、技術調査、移行検証、アジャイル型の段階開発など、開始時点で工数や答えが確定しにくい仕事に向いています。作業時間や体制が明確になる一方、完成物の範囲や品質を発注者側も管理しなければなりません。

準委任では、月ごとの稼働時間、担当者、作業報告、レビュー方法、成果物の定義、再委託の条件を確認します。委託先の担当者へ発注者が直接細かな指揮命令をすると、契約の実態と法的な整理が合わなくなる可能性があります。日々の業務指示ではなく、責任者を通じて作業依頼と進捗確認を行う体制を設計します。

仕様が不明な既存JSPや、移行可否が読めない大規模システムでは、現行調査、要件定義・RFP作成、PoC、開発、移行、保守の順に発注を分けます。第一段階で画面一覧、業務フロー、依存関係、リスク、概算工数をそろえ、第二段階で複数社から同じ条件の提案と見積を受ける流れです。

段階発注は、最終的な総額が最初から固定されない点に注意が必要です。ただし、調査を省いて大きな請負契約を結ぶより、早い段階で技術的な不確実性を発見できます。経営層には、各段階の継続判断条件と上限予算を示し、調査後に中止・縮小・刷新のいずれも選べるようにします。

RFPと要件整理で決めるべき発注条件

RFPは、委託先に提案を求めるための資料です。技術名を並べるだけでなく、解決したい業務課題、対象範囲、現状、期待する成果、制約条件、提案してほしい内容を記載します。デジタル庁の標準ガイドラインでも要件定義書や調達仕様書のテンプレートが公開されており、発注者が要件と評価項目を先に整える考え方が示されています（出典: デジタル庁「デジタル社会推進標準ガイドライン」、2026年更新）。

業務要件には、誰が、いつ、どの業務を、どの状態まで改善するのかを書きます。たとえば、営業担当者が得意先別に受注状況を検索し、承認者が金額と在庫を確認し、確定後に販売管理や会計へ連携する、といった業務の流れです。機能要件には、検索条件、一覧項目、入力チェック、権限、CSV出力、通知、エラー処理などを落とし込みます。

画面数を数えるだけでは、同じ一画面でも難易度が違います。単純な一覧画面と、複雑な承認・在庫引当・外部API連携を持つ画面を同じ一画面として扱わないことが重要です。RFPには、画面ごとの主要操作、利用ロール、連携先、データ量、ピーク時間、帳票の有無を記載し、見積の前提をそろえます。

非機能要件は、性能、可用性、障害対応、セキュリティ、バックアップ、監査、運用を定める項目です。たとえば、通常時とピーク時の同時利用者数、画面応答時間の目標、月間の稼働時間、障害発生時の復旧目標、バックアップ世代、ログ保存期間、メンテナンス可能時間を決めます。数値がないと、委託先は安全側の構成を見積もるか、最低限の構成で提案するしかありません。

個人情報や営業機密を扱う場合は、アクセス権限、暗号化、操作ログ、委託先の入退室や端末管理、脆弱性診断、インシデント時の連絡期限もRFPへ含めます。特にJSPの画面では、入力値の出力、セッション、フォーム送信が多いため、XSSやCSRF対策を「対応する」の一言で済ませず、試験項目と合格基準まで指定します。

新規開発でも、既存のマスタや履歴を使うなら移行要件が発生します。対象テーブル、データ件数、コード変換、重複や欠損の扱い、移行リハーサルの回数、旧システムとの並行稼働、切替日、切戻し条件を決めます。JSPの画面だけを新しくしても、データの意味や連携方式が整理されていなければ、リリース後に業務が止まる可能性があります。

運用では、誰がユーザーを登録し、誰が障害を一次受付し、誰がJavaやコンテナの更新を判断するかを定めます。保守契約に、平日対応だけでなく、脆弱性情報への対応、ログ調査、バックアップ確認、リリース作業、問い合わせ件数の上限が含まれるかも確認します。ソースコードと設計書を受け取るだけでなく、引継ぎ会や運用訓練を成果物に含めると、担当者の退職による属人化を抑えやすくなります。

JSPのシステム開発を発注してから納品するまでの進め方

発注後は、要件を固めてから一気に開発するのではなく、早い段階で現行システムと新しい構成の差を確認します。JSPの改修、Javaの更新、データ移行、クラウド・コンテナ化を同時に進める案件では、技術課題を小さな検証でつぶし、業務側の受入基準を段階的に作る流れが有効です。

最初に、現行のJSP、Servlet、Controller、Service、SQL、バッチ、帳票、認証、外部連携を棚卸しします。画面を実際に操作して、仕様書に書かれていない権限ルール、エラー時の運用、手作業の補完を確認します。そのうえで、保守継続、基盤移行、画面刷新、パッケージやSaaSへの置換を、業務影響、費用、期間、人材、将来性で比較します。

既存コードの静的解析だけでは、データの意味や現場の例外処理が分からない場合があります。現場担当者へのヒアリング、アクセスログの確認、問い合わせ履歴の分析を組み合わせます。初期段階で作るべき資料は、システム構成図、画面・帳票一覧、インターフェース一覧、データ移行方針、リスク一覧、概算スケジュールです。

設計では、画面遷移、入力チェック、権限、データモデル、API、例外処理、ログ、監視、バックアップを決めます。JSP内に業務ロジックやSQLを直接書き込む構成が残っている場合は、表示と処理を分離し、共通タグやバリデーション、エラー表示を標準化します。新規画面を別技術で作る場合は、既存JSPと新画面の認証・セッション・権限が混在しないように設計します。

開発中は、機能単位のレビューと結合テストを繰り返します。データ移行は本番直前の一回だけにせず、テストデータで複数回リハーサルします。移行時間が業務停止可能時間を超えそうなら、差分移行、並行稼働、夜間切替、段階リリースなどを選びます。委託先には、課題・変更・決定事項を一覧で管理し、発注者が毎週確認できる状態を求めます。

受入テストは、発注者が業務で使えるかを確認する工程です。委託先の単体テストや結合テストとは別に、利用者ロール別の業務シナリオ、異常系、権限エラー、帳票、外部連携、性能、バックアップ復元、監査ログを確認します。合格条件と未解決課題の扱いを先に決めておくと、検収時の認識違いを抑えられます。

リリース前には、切替手順、担当者、連絡網、監視、切戻し条件、利用者への案内を確認します。切替後の一定期間は、問い合わせ件数、エラー、応答時間、データ連携結果を重点的に確認し、保守契約へ引き継ぎます。納品をゴールにせず、運用開始後の改善とセキュリティ更新まで含めて発注計画を組み立てます。

JSPのシステム開発を外注する費用相場と内訳

JSP単体の公的な価格表はないため、以下は2026年時点の一般的なJava業務Webシステムの相場と、公開されている業務系システムの費用情報を組み合わせた目安です。実際の金額は、画面数、業務ルール、ユーザー数、既存DB、外部連携、移行データ、性能・可用性・セキュリティ要件で変わります。特定の金額をJSPの標準価格として断定せず、同じ条件で複数社へ見積を依頼します。

小規模な画面追加や保守改修は、既存DBと認証を利用し、5〜20画面程度、一覧・登録・CSV出力が中心なら、100万〜500万円程度が一つの目安です。要件定義やテストを含めて1〜4か月程度の案件が想定されますが、古いコードの解析や複雑な権限がある場合は上振れします。

部門向けの新規業務システムは、20〜60画面、複数ロール、承認、帳票、外部連携を含めて500万〜1,500万円程度、期間は3〜8か月程度が目安です。販売・在庫・ワークフローなど複数部門が使う中規模案件は1,500万〜5,000万円程度、全社基幹の刷新や大規模な移行は5,000万円〜1億円超となる場合があります。これらは公開されている2026年の業務系システム相場と、JSPを含むJava業務Webシステムの一般的な工数から推定したレンジです（出典: イー・ジーシステム「システム開発の費用相場と見積書の読み方 2026年版」、2026年）。

費用は、人月単価、必要工数、付帯費用の組み合わせで決まります。見積書では、現行調査、要件定義、基本設計、詳細設計、JSP・Java実装、単体・結合・総合テスト、データ移行、インフラ構築、脆弱性診断、教育、リリース支援を分けて確認します。人月単価だけが安くても、テストや移行が別途扱いなら総額は比較できません。

公開されている2026年の費用解説では、人月単価と工数に加えて、ハードウェア、ライセンス、外注部品、保守契約などの付帯費用が発生し、要件定義の精度で見積が倍以上動く場合もあるとされています（出典: イー・ジーシステム、2026年）。JSPの案件では、Javaやコンテナのバージョンアップ、商用ミドルウェア、クラウド利用料、監視、バックアップ、SSL証明書なども別枠で確認します。

初期費用だけでなく、保守改修、問い合わせ対応、脆弱性対応、Java・コンテナ・ライブラリの更新、バックアップ確認、クラウドやサーバーの利用料を見積もります。リサーチノートで整理された業務システムの目安では、初期費用の15〜25％程度を年間保守の一つの目安としますが、24時間運用、監視、障害対応、改修枠を含むかで変動します。保守範囲と月間の対応時間を確認し、開発費と運用費を分けて予算化します。

移行後に別会社へ保守を引き継ぐ可能性があるなら、ソースコード、ビルド手順、環境構築手順、データベース定義、テスト証跡、障害履歴を納品物に含めます。引継ぎ可能な成果物がなければ、毎年の保守費用が高止まりし、委託先の変更も難しくなります。

委託先の選定と見積比較で確認するポイント

「JSP対応」と書かれている会社でも、既存画面の保守だけを得意とする会社、Java・Jakarta移行を得意とする会社、クラウドや大規模業務の運用を得意とする会社があります。技術名の一致だけで決めず、自社と同じ業務規模、データ量、セキュリティ要件、運用時間の実績を確認します。

候補会社には、次の点を具体的に質問します。既存JSPのコード解析と保守の実績は何件あるか、javax.*からjakarta.*への移行をどの環境で検証したか、Java・コンテナ・データベースの担当者を誰が担うか、現行仕様が不足していても調査できるかを確認します。

さらに、要件定義から運用まで同じ責任者が関わるか、再委託先と担当範囲はどこか、障害時の連絡と復旧体制はどうか、脆弱性診断や性能試験を誰が実施するか、ソースコードと設計書をどの形式で納品するかも聞きます。回答が抽象的で、提案書に担当者名や作業手順がない場合は、価格が安くても慎重に評価します。

見積比較では、まず総額ではなく前提条件をそろえます。現行調査の範囲、画面・帳票数、連携本数、データ量、ユーザー数、テスト範囲、移行回数、教育、リリース支援、保守期間、クラウド費用が同じかを確認します。そのうえで、要件定義・設計・実装・試験・移行・管理の工数を並べます。

安い見積には、要件定義、受入支援、セキュリティ試験、移行リハーサル、ドキュメント、リリース後の保証が含まれていない場合があります。逆に高い見積には、将来の拡張や冗長化など、RFPで求めていない提案が含まれる場合があります。各社へ「必須」「提案」「対象外」を分けて記載してもらい、差分を質問してから価格を比較します。

JSPの画面では、入力値の表示、フォーム送信、Cookieによるセッション管理、権限による画面制御が発生します。IPAは、入力内容をWebページへ出力する箇所でXSSが起こり得ること、ログインや個人情報入力画面は特に注意が必要であることを説明しています（出典: IPA「安全なウェブサイトの作り方 1.5 クロスサイト・スクリプティング」、2026年確認）。JSTLやELによる適切なエスケープ、SQLのプレースホルダー、CSRFトークン、セッションID更新、アクセス制御、依存ライブラリの更新を仕様と試験に含めます。

契約では、成果物の所有権と利用権、ソースコード・設計書の引渡し、第三者ライブラリのライセンス、再委託、秘密保持、個人情報の取扱い、損害賠償、検収、瑕疵対応、契約終了時の引継ぎを確認します。新しく作ったプログラムを別案件へ流用できるか、発注者が改修できるか、著作権の譲渡や著作者人格権の扱いを法務担当者と整理します。

特に重要な処理のCSRF対策では、IPAがPOSTによる処理と推測困難な秘密情報を確認する方法を示しています（出典: IPA「安全なウェブサイトの作り方 1.6 CSRF」、2026年確認）。委託先へ「セキュリティ対応済み」と言わせるだけでなく、脆弱性診断の対象、検出時の修正期限、再試験の方法を契約上の作業に落とし込みます。

よくある質問（FAQ）

JSPのシステムを発注する際に、担当者からよく寄せられる質問をまとめます。費用や技術の判断は案件条件で変わるため、回答の前提も合わせて確認します。

既存のJava人材、JSP資産、社内標準、長期保守の体制があるなら、JSPを選ぶ合理性があります。一方、利用者向けの新規画面や人材確保を重視する場合は、Spring Bootとサーバーサイドテンプレート、ReactやVueなども比較します。技術の知名度だけでなく、10年程度の保守体制、移行方針、セキュリティ更新を含めて判断します。

小規模な既存画面の改修なら100万〜500万円程度、部門向けの新規業務システムなら500万〜1,500万円程度が一つの目安です。複数部門の販売・在庫・承認や大規模移行では1,500万〜5,000万円以上になる場合があります。JSP専用の確定相場ではないため、画面、連携、データ移行、非機能要件、テスト範囲を同じ条件で各社へ提示して見積を取ります。

「JSP対応」というキーワードだけでなく、既存Javaシステムの解析、Jakarta移行、データ移行、外部連携、クラウド運用、脆弱性対応まで実績を確認します。候補会社へ同じRFPを渡し、担当者、作業範囲、成果物、保守体制、再委託の有無、見積の前提を比較します。社名や規模だけで決めず、実際に担当するチームとの面談と提案内容で評価します。

成果物、範囲、検収条件が固まった画面改修や小規模開発は請負が向いており、調査、要件定義、移行検証、段階開発など不確実性が高い作業は準委任が向いています。実務では、現行調査と要件定義を準委任、合意した機能開発を請負、リリース後を保守契約とする組み合わせも選べます。契約名ではなく、責任範囲、成果物、作業指示、変更管理を整合させます。

まとめ

JSPのシステム開発を発注・外注するときは、JSPを使うかどうかよりも、既存資産をどこまで残し、どの業務をいつまでに安全に使える状態へ移すかを明確にすることが出発点です。保守改修、Jakarta移行、画面刷新、パッケージやSaaSへの置換を分け、必要なら現行調査から段階的に発注します。

RFPには、業務要件、機能要件、性能・可用性・セキュリティなどの非機能要件、データ移行、成果物、運用保守を記載します。費用は小規模改修で100万〜500万円程度、部門向け新規開発で500万〜1,500万円程度などのレンジを参考にしつつ、画面数だけでなく連携、移行、テスト、保守を含めて比較します。

委託先は、JSPの経験だけでなく、Java・Jakartaの移行力、業務理解、セキュリティ、運用体制、ドキュメントの引渡し、担当者の継続性で選びます。同じRFPで複数社を比較し、安さではなく、見積の前提と将来の保守費用まで確認することが、発注後の追加費用やベンダーロックインを防ぐ方法です。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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