JSPのシステムを発注するときは、既存資産の調査、要件と契約範囲の整理、段階的な開発と移行の順に進めると、費用や納期の見通しを立てやすくなります。前提を整えないまま見積を依頼すると、会社ごとに条件が異なり、比べられなくなります。
▼全体ガイドの記事
・JSPのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
JSPのシステムを発注・外注する前の全体像
JSPは、Javaを使うWebアプリケーションで、サーバー側のデータをHTML画面に表示します。リクエストを受けるのはServletやControllerで、Serviceなどの業務ロジックが処理したModelの結果を、JSPが描画するのが基本の役割分担です。
発注仕様に「JSPで作成」とだけ書くと、JSPの担当範囲が不明確になります。そのため、既存のJavaやデータベースの扱いも合わせて指定します。
保守・移行・刷新の方針の切り分け
業務を止めずに改善するには、JSPを残すかどうかより先に、対象範囲を決めることが大切です。方針は、次のように分けられます。
- 保守改修：既存画面を軽く直し、現行のJSP、Servlet、データベース、認証基盤を活用する方針です。
- 基盤移行：Javaやアプリケーションサーバーが古く、脆弱性対応や人材確保に不安があるときの選択肢です。
- 画面刷新：利用者の使い勝手やスマートフォン対応のために、JSP画面をAPIや別技術へ段階的に置き換える方法。
三つを混ぜたまま見積を依頼すると、会社ごとに前提が異なり、比べられません。そこで、既存JSPの改修、javax.*からjakarta.*への移行、画面の再構築は、別の作業パッケージに分けます。このように分けると、価格差と提案内容を見分けやすくなります。
JSPの役割と既存資産の把握
JSPファイルの数だけでは、既存資産と機能の関係が伝わりません。そこで、発注資料には両者の関係も示します。
- 対象資産：画面、帳票、バッチ、API、外部連携、権限、データ移行の一覧。
- 業務機能：ログイン、検索、一覧、登録、承認、CSV出力を、業務単位で切り分けます。
- 依存先：画面が呼び出すServletやController、データベース、ファイル保管先を確認しておく。
仕様書がない場合は、まず現行解析を先行発注します。画面一覧と業務フローを作ってから本開発を依頼すると安全です。
Servlet 6.0では、SingleThreadModelが削除されています。関連する属性なども、Jakarta Server Pages 3.1で非推奨です。出典はEclipse Foundation「Jakarta Server Pages 3.1」（2026年確認）です。
javax.*を使う旧Java EE時代のシステムは、移行先のコンテナやライブラリが決まるまで、互換性を断定できません。そのため、委託先には、Javaバージョン、コンテナ、JSP仕様、タグライブラリ、認証方式、依存ライブラリの調査を求めます。
JSPのシステム開発に適した発注形態の選び方
発注形態は、システムの不確実性、社内のIT人材、納期、どこまでを誰が受け持つかで選びます。既存JSPの小さな改修と、業務や技術を見直す新規開発では、向いている発注方法が異なります。
特に仕様の見えないレガシーシステムでは、最初から一括請負に固定するより、調査・要件定義と開発・保守を分けたほうが、リスクを抑えられます。
請負契約が向くケース
請負契約は、合意した成果物を完成させ、検査に合格した状態で引き渡す形態です。範囲や条件が固まった作業に向いています。
- 向く案件：画面追加の対象、入力項目、帳票、テスト条件、納期が固まった保守改修や小規模開発です。
- 注意点：完成責任を委託先に持たせやすい一方、要件変更により追加費用や納期の変更が生じることがあります。
成果物は「JSPファイル」だけでは決めません。設計書やソースコードに加えて、テスト仕様書と結果、データ移行手順も対象に含めます。さらに、環境設定、運用手順、脆弱性診断結果も入れます。
また、受入条件と検収期限、瑕疵対応、変更管理の方法も、契約書や仕様書に書き込みます。
準委任契約が向くケース
準委任契約は、専門家による作業や役務の提供を受ける形態です。工数や答えが開始時点で決めにくい仕事に向いています。
- 向く作業：現行JSPの解析、要件定義、技術調査、移行検証、アジャイル型の段階開発が中心です。
- 注意点：作業時間や体制は明確になりますが、完成物の範囲と品質は発注者側も管理が必要です。
準委任では、まず月ごとの稼働時間と担当者を確認します。そのうえで、作業報告とレビューの方法、成果物、再委託の条件を取り決めます。
発注者が担当者へ直接細かく指揮命令すると、契約の実態と法的な整理が合わない可能性があります。そのため、責任者を通じて作業依頼と進捗確認を行います。
段階発注が向くケース
仕様が不明な既存JSPや、移行の可否が読めない大規模システムでは、作業を段階に分けて発注すると、調査後に次の段階へ進むかを判断しやすくなります。
- 現行調査
- 要件定義・RFP作成
- PoC
- 開発
- 移行
- 保守
第一段階では、画面一覧と業務フローを作り、依存関係、リスク、概算工数をそろえます。第二段階では、複数社から同じ条件で提案と見積を受けます。
段階発注では、最終的な総額が最初から固定されない点に注意が必要です。ただし、調査を省いて大きな請負契約を結ぶより、早い段階で技術的な不確実性を発見できます。
経営層には、各段階の継続判断の条件と上限予算を示しておきます。さらに、調査のあとに中止、縮小、刷新のいずれも選べるようにします。
RFPと要件整理で決めるべき発注条件
RFPは、委託先に提案を求めるための資料です。技術名だけでなく、解決したい業務課題、対象範囲、現状を書きます。さらに、期待する成果、制約条件、提案してほしい内容も記載します。
デジタル庁の標準ガイドラインでも、要件定義書や調達仕様書のテンプレートが公開されています。発注者が要件と評価項目を先に整える考え方も示されています（出典: デジタル庁「デジタル社会推進標準ガイドライン」、2026年更新）。
業務要件と機能要件の切り分け
要件は、業務の流れとシステム機能に分けて整理します。
- 業務要件：誰が、いつ、どの業務をどこまで改善するかを記します。
- 業務の例：営業担当者が得意先別に受注状況を検索し、承認者が金額と在庫を確認する流れ。
- 機能要件：検索条件、一覧項目、入力チェック、権限、CSV出力、通知、エラー処理の定義。
確定後に販売管理や会計へ連携する業務の流れも、要件に含めます。
難易度は、画面の数よりも中身で変わります。単純な一覧画面と、承認・在庫引当・外部API連携を持つ画面を、同じ一画面として扱わないことが大切です。
RFPには、画面ごとの主要操作と利用ロールを記します。さらに、連携先とデータ量、ピーク時間、帳票の有無も書きます。こうすると、各社の見積前提をそろえられます。
非機能要件の数値による定義
非機能要件では、性能、可用性、障害対応を定めます。セキュリティやバックアップ、監査、運用についても、決めておきます。
- 性能・稼働：通常時とピーク時の同時利用者数、画面応答時間の目標、月間稼働時間を決めます。
- 障害・記録：障害発生時の復旧目標、バックアップ世代、ログ保存期間の設定。
- 運用時間：メンテナンス可能時間の定義。
数値が決まっていないと、委託先は安全側の構成で見積もるか、最低限の構成で提案するしかありません。
個人情報や営業機密を扱うなら、対策の範囲もRFPに含めます。
- 管理策：アクセス権限、暗号化、操作ログ、委託先の入退室・端末管理の定め。
- 検査と連絡：脆弱性診断の実施と、インシデント時の連絡期限の決定。
JSP画面は、入力値の出力やセッション、フォーム送信を多く扱います。そのため、XSSやCSRFへの対策は、試験項目と合格基準まで指定します。
移行と運用の条件の事前整理
新規開発でも、既存マスタや履歴を使うなら、移行の要件が必要です。
- データ条件：対象テーブル、件数、コード変換、重複や欠損の扱いを決めます。
- 切替条件：リハーサル回数、旧システムとの並行稼働、切替日、切戻しの条件。
データの意味や連携方式が整理されていないと、画面を刷新しても、リリース後に業務が止まるおそれがあります。
運用の担当と、保守契約の対応範囲も明確にしておきます。
- 担当者：ユーザー登録、障害の一次受付、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年確認）。
- 入力とDB：JSTLやELでの適切なエスケープと、SQLのプレースホルダーの利用。
- セッションと権限：CSRFトークン、セッションID更新、アクセス制御を、仕様と試験に含める。
- 保守：依存ライブラリの更新を、仕様と試験の対象にする。
契約では、成果物の権利と委託条件を確認します。
- 成果物の権利：所有権・利用権、ソースコードや設計書の引渡し、第三者ライセンスの整理。
- 委託条件：再委託、秘密保持、個人情報、損害賠償、検収、瑕疵対応の取り決め。
- 終了時の引継ぎ：契約終了時の引継ぎ、他案件への流用、発注者による改修可否を決めます。
著作権譲渡や著作者人格権の扱いは、法務担当者と整理します。
重要な処理のCSRF対策では、IPAが、POST処理と推測困難な秘密情報の確認方法を示しています（出典: IPA「安全なウェブサイトの作り方 1.6 CSRF」、2026年確認）。
「セキュリティ対応済み」という説明を受けたら、診断対象、検出時の修正期限、再試験方法まで、契約上の作業に含めます。
よくある質問（FAQ）
JSPのシステムを発注する際に、担当者からよく寄せられる質問をまとめます。費用や技術の判断は案件の条件で変わるため、回答の前提も合わせて確認してください。
JSPで新規のシステム開発を発注しても問題ありませんか？
既存のJava人材やJSP資産、社内標準、長期保守の体制があるなら、JSPを選ぶ合理性があります。
利用者向けの新規画面や人材確保を重視するなら、Spring Bootとサーバーサイドテンプレート、ReactやVueなども比較します。
技術の知名度だけでなく、10年程度の保守体制、移行方針、セキュリティ更新を含めて判断します。
JSPのシステム開発費用はどのくらいですか？
小規模な既存画面の改修なら100万〜500万円程度、部門向けの新規業務システムなら500万〜1,500万円程度が一つの目安です。
複数部門の販売・在庫・承認や大規模移行では、1,500万〜5,000万円以上になる場合があります。
JSP専用の確定相場はないため、同じ条件を各社へ提示して見積を取ります。その条件には、画面や連携、データ移行に加えて、非機能要件とテスト範囲も含めます。
JSPに対応できる開発会社はどのように探しますか？
「JSP対応」というキーワードだけでなく、既存Javaシステムの解析やJakarta移行の実績を確認します。また、データ移行、外部連携、クラウド運用、脆弱性対応まで見ます。
候補会社へ同じRFPを渡し、担当者、作業範囲、成果物を比べます。さらに、保守体制、再委託の有無、見積の前提も比較します。判断は、実際に担当するチームとの面談と提案内容で行います。
請負と準委任はどちらを選べばよいですか？
成果物や範囲、検収条件が固まった画面改修や小規模開発には請負が向いています。一方で、調査、要件定義、移行検証、段階開発など不確実性が高い作業には、準委任が向いています。
実務では、現行調査と要件定義を準委任、合意した機能開発を請負、リリース後を保守契約とする組み合わせも選べます。契約名より、責任範囲、成果物、作業指示、変更管理を整合させることが大切です。
まとめ
JSPのシステム発注では、JSPを使うかどうかより、既存資産をどこまで残すかを先に明確にします。どの業務を、いつまでに安全に使える状態へ移すかも、出発点になります。
保守改修、Jakarta移行、画面刷新、パッケージやSaaSへの置換を分けて考えます。必要であれば、現行調査から段階的に発注します。
RFPには、業務要件と機能要件、性能・可用性・セキュリティなどの非機能要件を記載します。さらに、データ移行、成果物、運用保守も書き込みます。
費用の目安は、小規模改修で100万〜500万円程度、部門向けの新規開発で500万〜1,500万円程度です。そのうえで、比べるときは、画面数だけでなく、連携、移行、テスト、保守も含めて見ます。
委託先は、JSPの経験だけでなく、Java・Jakartaの移行力や業務理解で選びます。加えて、セキュリティ、運用体制、ドキュメントの引渡し、担当者の継続性も見ます。
同じRFPで複数社を比べ、安さだけでなく、見積の前提と将来の保守費用まで確認することが、発注後の追加費用やベンダーロックインを防ぐ方法です。
▼全体ガイドの記事
・JSPのシステム開発の完全ガイド
▼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を創業。