JSPのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

JSPのシステム開発は、要件整理から始めて、稼働と定着まで6つのフェーズで進みます。既存の資産を生かしながら、保守しやすい仕組みへつなげていくのが基本の流れです。

開発の全体像は、JSPのシステム開発の完全ガイドでも確認できます。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

JSPのシステム開発の全体像

JSPは、Javaの処理結果をHTMLとして表示するサーバー側のテンプレート技術です。ブラウザからのリクエストは、ServletやControllerが受け取り、認証や入力チェックを行います。

業務処理はService層が担い、取得したデータをJSPに渡して画面を生成するのが基本の役割分担です。開発では、この分担を保ったまま、業務と技術の両面から段階的に判断していきます。

JSP・Servlet・Java業務ロジックの役割分担

JSPに処理が多く残っていると、画面を変えたときに業務ルールへの影響を追いにくくなります。そこで、既存コードのJSPに何を書いているかを先に確かめます。表示と画面部品はJSP、入力検証と画面遷移はControllerが担う形に分けます。

• 業務ルール：Serviceに切り出すと、画面変更の影響を見通しやすくなります。
• データ取得：RepositoryやDAOなどの層に分けて扱います。
• 現行コード：JSP内にSQLや複雑な条件分岐、権限判定が残っていれば、画面改修の前に洗い出します。

画面機能では、ログインや権限別メニュー、一覧検索、登録・更新・削除などが代表的です。帳票・CSV出力や承認のほか、マスタ参照と外部連携も対象に含まれます。

画面数が少なくても、権限の種類や締め処理、データ移行が増えると、設計とテストの工数は大きくなります。連携時刻や監査ログの扱いも、工数を押し上げる要因になります。そのため、規模を画面数だけで判断しないことが大切です。

保守・基盤移行・画面刷新・置換の4ルート

既存JSPを使う企業は、全面リプレースだけに絞らず、業務の状況に合うルートを比べます。残す範囲と作り替える範囲の組み合わせで、ルートは次の4つに分かれます。

• 保守改修：既存画面と認証を残し、必要な機能を改修する進め方です。
• 基盤移行：JSP・Servletは保ったまま、Javaやコンテナ、ライブラリ、OSを更新します。
• 画面刷新：業務単位や画面単位で、新しい画面技術へ移行します。
• パッケージ・SaaS置換：業務をパッケージやSaaSに寄せ、JSPシステムの縮小や廃止を図ります。

2026年時点では、Jakarta Server Pages 3.1がJakarta EE 10向けの仕様として公開されており、Java SE 11以上が最低要件です（出典: Eclipse Foundation「Jakarta Server Pages 3.1」、2022年）。

Java EE時代のjavax.*を使う既存システムは、jakarta.*の環境へそのまま配置できるとは限りません。そのため、まず互換性と依存ライブラリを確かめ、コンテナや設定、テストへと確認を広げていきます。

新規に採用する場合も、将来の担当者が保守できるか、画面要件を満たせるかを含めて判断します。

JSPのシステム開発の6フェーズ

要件整理、選定、設計開発、テスト、稼働、定着の6フェーズに分けて進めると、成果物と判断の時期を管理しやすくなります。段階ごとに終了条件を決めておけば、未確定の業務ルールを残したまま実装へ進む事態を防げます。

1. 要件整理フェーズでの現状と目的の確認

まず、開発する理由を言葉にします。画面数から入ると、目的があいまいなまま設計へ進んでしまうからです。

対象業務と利用者、拠点、処理量を整理します。あわせて、現行の課題と改善指標、稼働希望日を確かめます。法令や社内規程の制約も、この段階で把握しておきます。

既存システムでは、JSPやServlet、Controllerの構成を一覧にします。Javaのバージョンやコンテナ、DBも同じ表に記録します。加えて、バッチや外部API、帳票を書き出します。認証と運用手順も、一覧に含めます。

成果物には、業務フローに加えて、機能・画面・データ項目・連携・権限の各一覧を含めます。非機能要件と移行対象の一覧も、成果物として残します。仕様書に書かれていない手作業の補正や締め処理の例外、担当者だけが知る再処理の方法は、利用部門に確認しておきます。

• 業務範囲：対象業務と対象外業務を明確にします。
• 優先度：各機能に優先順位を付けます。
• 受入と移行：受入担当者と、移行しないデータの扱いを定めます。

2. 選定フェーズでの残す範囲と作り替える範囲

JSPを継続する案と、基盤移行、画面刷新、パッケージやSaaSへの置換を比べます。判断軸は、コードの再利用性や業務の独自性、操作性です。加えて、Java人材やセキュリティ更新、将来の連携、総保有コストも見ていきます。

既存画面を残せば、短期の変更量を抑えられます。一方で、古いライブラリや属人化が残るおそれもあります。そこで、代表的な業務シナリオを使った小さなPoCや技術検証を行い、候補を絞ります。

• 一連の業務：ログインから検索、登録、承認、帳票出力まで通して試します。
• 技術と移行：権限と入力エラー、トランザクション、既存DBへの接続、応答を確かめます。
• 引き継ぎ：Java・コンテナの動作、javax.*からjakarta.*への影響、成果物の引き渡し、保守担当を見ておきます。

3. 設計開発フェーズでの画面と業務ロジックの分離

設計では、部品ごとの役目と、画面の作り方を決めます。

• 責務設計：画面遷移、API・Servlet、Service、DB整合性、バッチ、外部連携、ログ、権限、障害復旧の各担当を決めます。
• 画面標準：共通レイアウト、入力部品、エラー表示、日付・金額書式、アクセシビリティ、二重送信防止の決まりを統一します。
• 実装方法：JSPのスクリプトレットは増やさず、JSTLやEL、共通タグで組みます。
• 開発とレビュー：優先度の高い業務から作り、利用部門が確かめられる単位でレビューします。
• 設計書：正常系に加えて、未入力や形式不正、権限不足、データなし、同時更新、タイムアウト、連携失敗のときの動きを記します。

成果物は、コードに加えて仕様書とDB定義、環境設定を更新します。テスト仕様と運用手順も、コードと歩調を合わせて直します。

4. テストフェーズでの業務シナリオと非機能の検証

テストは4段階に分けて、それぞれの役割を明確にします。

• 単体：JSPの表示値や入力エラー、タグ、共通部品を一つずつ確かめます。
• 結合：Controller、Service、DB、外部連携をつなぎ、通しで動かします。
• システム：利用者の業務シナリオを最初から最後まで実行します。
• 受入：現場が実際に使うデータと権限で、業務が止まらないかを見ます。

テストケースには、正常系に加えて、権限別の表示や直接URL、別ユーザーIDの指定を含めます。セッション切れや同時更新、連携先の停止も、ケースに入れておきます。大量データやCSVの文字コード、帳票の改ページも確かめます。

見た目が合っていても、認可漏れや二重登録が残っていれば受入はできません。そのため、欠陥の重要度と修正期限、再テストの責任者、残課題の扱いを決め、合格条件を記録しておきます。

5. 稼働フェーズでの移行と切り替え

稼働前の準備から本番切り替え、稼働直後の確認までを、一連の手順として組み立てます。

• 移行リハーサル：切り替えに必要な準備と、データ照合の手順を試します。
• 切り替え判定：データ照合や重大障害の解消、アカウント、問い合わせ窓口、復旧手順が揃っているかを見ます。
• 稼働後の監視：画面エラーに加えて、処理時間やDB接続数、連携キュー、バッチ、監査ログを追います。

リハーサルでは、環境構築や権限登録、バックアップを試します。監視や障害連絡、切り戻しも、試す対象に含めます。さらに、移行データの件数や欠損・重複も確かめます。

コードの変換や日付・金額の精度、旧システムとの照合方法は、事前に決めておきます。

停止できない業務では、旧システムと新システムを並行稼働させるか、段階的に切り替えます。また、切り替え当日に初めて試す作業は残さないようにします。

切り戻しの条件と判断者を事前に定めておけば、現場が混乱したときも、感覚に頼らず判断できます。

6. 定着フェーズでの運用と改善の仕組み

稼働後は、支援や保守、改善の仕組みを、利用状況に応じて見直し続けます。

• 利用者支援：操作説明や権限設定、問い合わせ、障害連絡、データ確認を運用に組み込みます。
• 保守：JDKやServletコンテナ、JSP関連ライブラリ、OS、ミドルウェアの更新責任と頻度を決めておきます。
• 定期確認：脆弱性やバックアップの復元、監査ログ、性能、担当交代時の引き継ぎを、定例の作業にします。
• 改善：利用率や処理時間、問い合わせ件数、手戻り件数を月次で追い、業務効果から次の改修を判断します。

最初の数週間は、問い合わせをFAQや手順に反映し、質問が続く画面を改善候補として記録します。

保守契約では、各製品の更新責任と頻度を明確にしておくと、継続的な運用につながります。また、更新作業を担う範囲を明らかにしておけば、後から担当の食い違いも起きにくくなります。

JSPのシステム開発費用の相場と内訳

JSP単体の公開価格は少ないため、一般的なJava業務Webシステムの相場に、既存資産や移行条件を加えて目安を考えます。費用は、JSPという技術名だけで決まるわけではありません。

費用は、画面数や業務ルール、ユーザー数によって変わります。既存DBや外部連携、移行の範囲も、費用に影響します。可用性やセキュリティ、保守範囲も、金額を左右します。

2026年公開の相場では、人月単価はスキルや地域により60万〜200万円程度です（出典: SIA株式会社「システム開発の費用・相場 2026年版」、2026年）。

規模別の費用レンジ（4ケース）

費用や期間は、規模と含まれる機能によって変わります。次に挙げるのは、公開相場に基づく推定レンジで、個別案件の確定見積ではありません。

• 小規模改修：既存認証・DB・共通部品を使う5〜20画面程度なら100万〜500万円程度で、期間は1〜4か月が目安です。
• 部門向け新規：20〜60画面で複数ロール、帳票、承認、外部連携を含む場合、500万〜1,500万円程度、期間は3〜8か月ほどです。
• 中規模案件：複数部門で使い、データ移行や複数連携を含む場合、1,500万〜5,000万円程度、6〜12か月になることがあります。
• 全社基幹刷新：大量データ、複数拠点、24時間運用、災害対策、段階移行を含む場合、5,000万〜1億円超、12〜24か月以上も想定されます。

初期費用とランニングコストの内訳

見積もりでは、初期作業と稼働後の費用を分けて、含まれる作業と前提を確かめます。「開発一式」のようにまとめられた見積もりでは、範囲を比べられなくなります。

• 初期作業：要件整理、現行解析、基本・詳細設計、JSP・Java開発、連携、テスト、移行、教育、稼働支援に分けて示します。
• 工数と単価：人月単価、工数、担当ロール、期間を確かめます。画面や連携を足したときの差額も、試算できるようにしておきます。
• 稼働後費用：保守改修、障害対応、更新、脆弱性対応、クラウド・サーバー利用料、監視、バックアップ、問い合わせ対応の費用を見ます。

初期費用の15〜25％程度を年間保守の目安とするケースもありますが、保守範囲によって変わるため、固定の値ではありません。24時間監視やSLA、緊急パッチ、機器費用の有無は、別々に確認します。

JSPのシステムの見積もりを取る際のポイント

見積もりの精度は、開発会社の能力だけでなく、発注側が前提を示せるかで変わります。依頼が曖昧なままだと、各社が想定する範囲がずれ、価格を比べられなくなります。

RFPや依頼書には、業務目的や対象範囲、現行資産、利用者を書きます。あわせてデータや連携、品質を示し、稼働時期や納品物、保守条件も記載します。

画面数だけでなく業務・データ・連携の具体化

各社の見積もり条件をそろえるため、業務・データ・連携・非機能の情報を具体的に示します。

• 機能と利用状況：ログイン、検索、登録、更新、削除、承認、帳票、CSV、通知と、利用者ロール、件数、ピーク時間、入力項目、エラー処理を整理します。
• 画面・連携・移行：画面の新規・改修・廃止を分けたうえで、既存画面のスクリーンショットや、裏側のAPI、SQL、バッチ、帳票定義を確かめます。
• 非機能要件：可用性、性能、同時利用者数、バックアップ、復旧目標、監視、ログ保管、権限、脆弱性診断、OS・ミドルウェア更新を盛り込みます。
• 既存環境：Javaのバージョンと、javax.*とjakarta.*の別を押さえます。

移行対象のテーブルと件数、保持期間を整理します。変換の方法や、旧システムとの照合方法も、あわせて決めておきます。

既存環境では、Servletコンテナや認証基盤、DBドライバーを確かめます。JSTLや独自タグの有無も確認しておきます。必要な情報が分からない場合は、見積もりの前に現行解析を別工程として依頼する方法もあります。

発注先への4つの質問と比較の観点

候補の会社には、担当範囲や移行・保守の進め方を具体的に質問します。次の観点を、同じ条件でそろえて見ていきます。

• 現行と移行：現行解析と保守の担当者、Java EEからJakarta EEへの移行経験を確かめます。
• 開発と安全性：画面・業務ロジック・DB・連携の範囲と、セキュリティ・脆弱性診断の範囲を聞きます。
• 切り替えと成果物：移行・切り戻しの検証方法と、納品するコード・設計書・テスト証跡を確認します。
• 稼働後：保守担当者と更新責任者を明らかにします。

「JSPに対応できます」との回答に加えて、同業種や同規模の実績、担当工程を聞きます。利用者数や移行前後の技術、障害対応体制も確認します。

業務シナリオを渡し、前提条件やリスク、成果物、スケジュールを具体的に示せるかを見ます。安く見せたあとで要件整理やテストを足す提案よりも、不確実性を最初から説明する提案を高く評価します。

セキュリティ・契約・追加費用のリスク

セキュリティと契約条件、見積もりの除外項目は、分けて確認します。

• HTML出力：検索語やエラー内容などの入力値は、文脈に応じてエスケープします。
• SQLとセッション：SQLの安全な扱いと、認証・セッション対策をRFPで確かめます。
• 契約：請負・準委任、検収条件、仕様変更、再委託、障害時のSLA、コード・設計書の権利、環境設定やIaCの引き渡し、契約終了時の移管を見ます。
• 除外項目：データクレンジングや脆弱性診断、クラウド費用、ライセンス、利用者教育、休日の切り替え支援が、見積もりに含まれるかを示してもらいます。

IPAは、検索結果や確認・再入力画面、エラー表示を、クロスサイト・スクリプティングの注意箇所として挙げています（出典: IPA「安全なウェブサイトの作り方」、2025年確認）。また、SQLの組み立てでは、文字列連結を避けてプレースホルダーを使います（出典: IPA「安全なウェブサイトの作り方 1.1 SQLインジェクション」、2025年確認）。

URL単位の認可やCSRF対策、セッションIDの更新、Secure・HttpOnly・SameSite属性も、RFPに記載します。

予算に含む作業と含まない作業を同じ表で比べると、追加費用を抑えやすくなります。

JSPのシステム開発に関するよくある質問

新規採用や既存システムの移行、費用、発注先の選び方について、前提ごとに確かめます。

JSPは2026年に新規開発で採用しても問題ありませんか？

採用の可否は、既存のJava資産や人材、画面要件を見て決めます。さらに、保守期間や将来の移行方針も合わせて判断します。

Jakarta Server Pages 3.1と、更新を続けられるJava・コンテナ・ライブラリを前提にします。そのうえで、表示と業務ロジックを分けて作ります。

高度な画面操作やスマートフォン対応が中心になる場合は、別の技術も含めて、総保有コストを比べます。

古いJSPシステムはすぐに全面リプレースすべきですか？

全面リプレースが正解かどうかは、業務の状況によって変わります。まず、業務価値や変更頻度、性能を洗い出します。保守できないコードや脆弱性、移行しにくいデータも対象にします。そのうえで、4つの対応ルートを比べます。

停止できない業務では、移行リハーサル、並行稼働、段階切り替えを行い、業務影響と切り戻し条件を確認します。

JSPのシステム開発費用を抑えるにはどうすればよいですか？

対象業務や画面数、権限、外部連携を整理します。移行データと非機能要件、保守範囲も、あわせて書き出します。そのうえで、同じ条件で複数社へ見積もりを依頼します。

既存認証や共通部品の再利用、優先度の低い機能の後続化も選択肢になります。ただし、テストや脆弱性対応、バックアップ、運用の引き継ぎを削ると、稼働後費用や障害リスクが増えます。そのため、初期費用だけで判断しないことが大切です。

開発会社には何を確認すればよいですか？

新規画面の開発に加えて、現行解析やJava・Jakarta移行、データ移行の担当範囲も聞きます。認証・認可や脆弱性診断、クラウド運用については、担当範囲を確かめます。障害対応や利用者教育、保守も、どこまでを担うかを聞きます。

担当者の経験や再委託の範囲、成果物を確認します。見積もりの前提や、契約終了時の引き継ぎも、あわせて聞いておきます。業務シナリオを渡し、設計・テスト・切り替えの方法を具体的に提案してもらえば、各社を比べやすくなります。

まとめ

JSPのシステム開発では、JSPファイルを作ることに加えて、業務と現行資産を把握し、対応ルートを選び、画面と業務ロジックを分けて進めます。

業務シナリオと非機能要件のテストを行い、移行リハーサルを経て稼働させます。その後は、教育や監視、更新、改善までを運用に定着させていきます。

着手前に確認するチェックリスト

着手前には、対象業務と対象外業務、現行構成、利用者と権限を確認します。画面や連携、バッチ、移行データも見て、性能や可用性、セキュリティの要件を整理します。そのうえで、受入担当と稼働日、切り戻し条件を決めておきます。

見積もりでは、要件整理や現行解析、設計、開発を項目ごとに分けます。テストや移行、教育、保守も、同じように項目として並べます。ソースコードや設計書などの納品物も、見積もりに明記します。

最初の一歩は現行資産と業務課題の洗い出し

JSPを残すかは、業務継続性やセキュリティ、人材を並べて判断します。そこに、変更のしやすさと総保有コストも加えます。代表業務を一つ選び、現行画面からDB、連携、運用までを一覧にします。

6フェーズごとに成果物と受入条件を置いておくと、予算超過やベンダーロックインを防ぎ、使われ続けるシステムにつながります。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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