Servletのシステム開発を発注するときは、現行資産を調査し、要件と契約範囲を定めてから、設計・開発・移行・保守へ進みます。この流れで進めると、発注後の手戻りを抑えやすくなります。全体像は、Servletのシステム開発の完全ガイドにもまとめています。
▼全体ガイドの記事
・Servletのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Servletのシステム発注・外注前の全体像
Servletの発注では、まず対象業務、利用者、扱うデータ、必要な品質を整理します。技術名から委託先を探すのは、その後です。
新規開発と既存Servletの刷新では、調べる項目が異なります。たとえば、「Java開発」という同じ見積でも、作業範囲は大きく変わります。
Servletと業務Webシステムの違い
Servletと業務Webシステムは別のものとして区別し、発注範囲を構成要素ごとに決めます。
- Servlet：HTTPリクエストを処理し、レスポンスを返すAPI
- コンテナ：APIのライフサイクルやURLマッピングなどを管理
- 業務システム：画面、業務ロジック、DB、連携などを組み合わせる
Apache Tomcat、Jetty、Undertowなどのコンテナは、セッションやCookie、認証・認可も担います。さらに、Filter、Listener、非同期処理も管理します。
発注書に「Servletで開発」とだけ書くと、画面数や帳票、権限などが見積もりから抜けるおそれがあります。データ移行とAPI連携、性能とバックアップも、同じように見落としやすい項目です。
画面を表示するJSP、業務ロジック、JDBCやJPAによるデータアクセスは、発注範囲に含めるかを決めます。RDB、外部API、バッチ処理も、同じく判断の対象です。
Servlet APIを直接実装するか、Spring Bootなどを使うか、コンテナを実行基盤にするかは、委託先に提案を求める事項です。
新規開発と既存資産の刷新の違い
新規開発と既存刷新では調査の起点が異なるため、構成や移行方法の決め方も、別の観点で考えます。
- 新規開発：業務フローや拡張性を基準に技術構成を選ぶ
- 既存刷新：現行資産を洗い出し、継続・更新・再構築を比べる
新規開発では、Javaのバージョンとフレームワークに加えて、コンテナやクラウド、データベースを選びます。CI/CDと監視の方法も、あわせて決めます。
既存側では、web.xmlやURLマッピングなどの設定を調べます。セッションへの依存やJSP内の業務ロジック、直接SQLも確認します。さらに、手作業のデプロイ方法も調べます。そのうえで、保守を続ける案から、段階的な更新、再設計、全面再構築までを比べます。
旧来のJava EE資産では、javax.servlet.*からjakarta.servlet.*への名前空間の変更が、移行の論点になります。なお、Jakarta Servlet 6.1は、Java SE 17以上を最低要件としています。
依存ライブラリやアプリケーションサーバー、テスト環境と運用手順も確認します（出典: Eclipse Foundation「Jakarta Servlet 6.1」、2026年確認）。
Servletのシステム発注形態の選び方
発注形態は、社内の要件整理力と既存資産の複雑さ、納期、リリース後の改修量から選びます。
IT部門が少なく基幹連携も必要な場合は、一括外注が候補です。業務知識を社内に残すなら、伴走型が候補になります。業務や技術の方針が不明確なときは、診断やPoCから始めます。
要件定義から保守までの一括外注
社内にJavaやインフラの担当者が少なく、複数部門の業務をまとめて刷新する場合は、一括委託が候補になります。
- 委託範囲：要件定義から保守までを一括して任せる
- 窓口：設計、実装、テスト、移行、教育、リリースを一つの窓口で担う
- 発注者の役割：業務上の意思決定と、納品物の指定
ただし、業務上の意思決定は発注者が担います。そのため、登録や承認の担当者、正とするデータ、障害時に止められる業務を、発注側で決めておく必要があります。
ヒアリングや業務フロー、画面・API設計も、委託範囲に含めます。納品物には、設計書とソースコード、テスト証跡などを含めます。環境定義、運用手順、管理者アカウントも加え、担当者が替わっても引き継げる状態にします。
診断・設計・移行などの部分外注と内製化
社内に業務知識があり、運用や軽微な改修を自社で続けるなら、部分外注が向いています。
- 外部へ依頼：コード診断、移行方針、設計、セキュリティレビュー
- 社内で担当：画面追加、日常の問い合わせ、継続的な運用
- 成果物：現行資産の洗い出し結果、移行一覧、検証結果、API仕様、テスト計画、研修
難しい連携の実装も委託できます。その場合も、成果物の範囲とレビュー方法を決めて、委託先の知見が特定の人に閉じないようにします。さらに、本番環境へアクセスできる期間と権限も、契約前に決めておきます。
小さな診断やPoCの先行発注
既存コードが読みにくい、JavaやTomcatの版が分からない、移行件数を把握できない。こうした場合は、全面刷新の前に診断を発注できます。
- 診断範囲：1業務または1画面群のコード・設定・DB・連携
- 確認結果：移行難易度、技術選択、概算工数、リスク
- PoC：認証、データ取得、権限、外部連携、エラー処理を一部検証
- 成果物：本番へ進む条件、残る資産、見積もりの前提
見た目のよいデモで終わらせず、実際に一部を動かします。そうすると、検証の費用が本番契約へ自動的に膨らむのを防げます。
小規模な診断やPoCの費用は、対象範囲や期間によって変わります。定額とは決めつけず、個別に見積もります。
ServletのRFP・要件整理で明記する項目
RFPは、複数の委託先から同じ条件で提案と見積を受けるための資料です。ただし、最初から完璧な仕様書を作る必要はありません。
RFPには、目的や対象範囲、利用者、現行構成を分けて書きます。機能やデータ、外部連携、非機能も、同じ資料の中で扱います。納期、納品物、保守条件もあわせて記載します。不明な点は、提案事項と発注者が決める事項に分けて残します。
目的・対象範囲・利用者の整理
RFPには、目的や対象範囲、利用者と業務の流れを具体的に書きます。
- 目的：誰のどの業務をどう変えるか、目標と対象外の業務
- 利用者：役割、人数、同時利用者数、利用条件
- 利用環境：時間帯、社外アクセス、共有端末、認証、権限変更頻度
- 業務範囲：入口から完了までのユースケースと必要画面
営業部門が受注情報を登録し、管理部門が基幹へ転記する例では、受注登録から承認、在庫確認、基幹連携までを対象にします。履歴検索も含めます。
目標は、二重入力の削減と登録当日の共有です。利用者は、一般ユーザーや承認者、管理者、外部協力会社などに分けます。
対象外の業務も明記しておくと、提案範囲が広がるのを防げます。
画面数だけで発注すると、管理画面やエラー画面、帳票が抜けやすくなります。CSV入出力やバッチ、監査ログも、抜けやすい項目です。そのため、業務の入口から完了まで洗い出します。
機能要件と非機能要件の分け方
機能要件と非機能要件を分けて、操作と品質の両面から仕様を具体化します。
- 機能：顧客・商品・受注の登録と検索、承認、帳票、CSV
- 連携：ファイルアップロード、メール通知、バッチ、外部API
- 非機能：同時接続数、応答時間、稼働時間、復旧目標、バックアップ、ログ保存、監視
- セキュリティ：暗号化、脆弱性診断、パッチ、ブラウザ対応、基盤範囲
バッチや外部API連携も対象に含めます。そのうえで、必須項目や重複防止、入力エラーの扱いを決めます。取消や履歴、再実行、同時更新時の扱いも、あわせて決めます。
セッション切れや二重送信、タイムアウトのほか、連携先の応答遅延も、シナリオに含めます。さらに、ログの保存期間も定めます。
基盤側では、WAFやロードバランサー、コンテナを範囲に含めます。RDBやストレージ、秘密情報管理も、対象に入れます。「安全にする」で終わらせず、OWASP ASVS 5.0やIPAの委託開発向けガイドを参照します。
移行・連携・テストの前提
既存資産の洗い出し、データ移行の方針、テスト条件を、RFPに含めます。
- 洗い出し：ソース、設定、DBテーブル、マスタ、過去データ、連携先
- 移行方針：新環境へ移行、参照用に保管、不要データを廃棄
- テスト：単体から受入まで、担当者と合否基準を決める
外部接続先や帳票テンプレート、ジョブ定義も対象です。移行範囲によって工数が変わるため、文字コードや日付の形式、コード体系の違いを確認します。重複や欠損、個人情報の保存期間も見ておきます。
旧画面と新画面の結果を比べ、API再送やトランザクション境界を試します。権限差やファイル上限を確認し、セッション切れやバックアップ復元も試します。
実データに近い匿名化データを使い、合否基準とテスト証跡を納品条件にすると、検収の判断がはっきりします。
Servletのシステム開発の契約形態（請負と準委任）
契約形態は、仕様と成果物が固まっているか、発注後も調査や改善が続くかで選びます。
請負は、合意した成果物の完成と検収を重視します。一方で、準委任は、専門人材や作業時間による支援を重視します。
刷新では、工程ごとに契約を分ける方法もあります。たとえば、診断や要件定義は準委任、仕様確定後の開発と移行は請負、リリース後の改善は準委任とします。
要件と成果物が固まった部分の請負契約
仕様と受入条件が固まっている工程では、成果物と検収を軸に、請負を検討します。
- 適する条件：画面、業務、API、データ項目、権限、移行件数、受入条件が確定
- 合意事項：成果物、納期、検収方法、契約不適合への対応
- 変更時：新要件は、変更管理と追加見積で扱う
請負は予算を管理しやすい一方で、発注後の新要件には追加見積が必要です。また、「開発一式」だけで済ませず、成果物にはソースコードや設定、インフラ定義を書きます。設計書とテスト結果も、成果物に含めます。
移行ツールやマニュアルを成果物に含むかを確認します。教育やリリース支援も、同じ扱いにするかを決めます。あわせて、仕様・納期の変更と、第三者ライブラリのライセンスを定めます。
著作権や利用権、再委託の可否は、契約書と個別仕様書でそろえて定めます。
調査・伴走・継続改善の準委任契約
作業内容が進行中に変わる調査や支援は、準委任を検討します。
- 対象業務：コード読解、移行比較、要件整理、助言、開発レビュー
- 進め方：発注者と委託先が共同で判断しながら進める
- 契約条件：人数、役割、期間、範囲、報告、レビュー、品質指標
発注者と委託先が共同で判断するため、ブラックボックス化した資産の調査や段階的な刷新と相性があります。
レビューの頻度や時間外対応も、あらかじめ合意します。月次報告には、調査した画面数や解消した課題、残課題、次月の判断事項を含めます。そのうえで、作業時間と進捗を管理します。
保守・脆弱性対応・権利の責任分界
リリース後の脆弱性対応では、確認の対象と、契約上の担当範囲を決めます。
- 確認対象：Java、Servletコンテナ、OS、RDB、ライブラリ
- 契約事項：情報窓口、重大度ごとの初動時間、パッチ期限、緊急時の回避策
- 運用範囲：定期更新の費用、監視、ログ確認の担当
IPAは、2026年の利用者向けガイドで、自社開発や委託開発を含むシステムについて、委託先とセキュリティ品質や対応プロセスを合意することの重要性を示しています（出典: IPA「製品利用者向けガイド」、2026年）。
Apache Tomcat公式の情報では、2026年にも認証やTLS、HTTP関連の修正が掲載されています。Rewriteやファイル処理に関する修正もあります。
また、Tomcat 9.0.xのサポート終了も案内されています（出典: Apache Tomcat公式「Security Vulnerabilities」「End of support for Apache Tomcat 9.0.x」、2026年確認）。そのため、利用中の版を継続して確認する体制が必要です。
Servletのシステム発注・外注費用の相場
Servlet単体の定価や公定の開発価格はありません。そのため、画面数、業務ロジック、利用者数、外部連携、データ移行などの規模から、工数を積み上げて考えます。
セキュリティや可用性、運用体制も見積もりに影響します。ここで示す目安は、2025〜2026年のJava・業務システム開発の相場と構成要素をもとにしたものです。実際の費用は、要件定義の後に再見積もりします。
規模別の費用の幅（300万円台から1億円超）
規模ごとに画面数や構成、期間を確認すると、費用の目安を比べられます。
- 小規模・MVP：300万〜800万円程度、2〜4か月程度
- 中規模：800万〜2,500万円程度、4〜8か月程度
- 大規模刷新：2,500万円〜1.5億円以上となる場合がある
小規模・MVP（Minimum Viable Product）は、1部門で5〜15画面を想定します。ログインや基本登録・検索、単一DB、簡易帳票を含みます。
中規模は、複数部門で15〜50画面を想定します。権限・承認やCSV・API、外部サービス連携、総合テストを含みます。
大規模刷新は、全社利用で50画面超を想定します。複数DBや基幹連携、旧Servlet移行を含みます。さらに、データ移行や冗長化、監査、段階リリースも含まれます。
金額は、Servlet固有の価格表ではなく、Java開発の公開相場と業務システムの規模から算出したレンジです（出典: リサーチノート「Servletのシステム」、2026年）。
画面数が少なくても、24時間稼働や厳格な監査、複雑な連携があれば、費用は上振れします。
人件費・移行費・非機能費の内訳
見積もりは単価だけで比べず、工程ごとの人月と、実装以外の費用を分けて比べます。
- 人月単価：エンジニア50万〜200万円、PM等130万〜250万円の例
- 別計上の可能性：既存調査、データ移行、性能試験、教育など
- 見積比較：一式項目を分け、範囲や別途条件を確認
Java開発の公開相場では、人月単価の例としてエンジニアは50万〜200万円程度、PMやアーキテクトは130万〜250万円程度が示されています（出典: 株式会社ripla「Java開発の完全ガイド」、2025年）。
工程ごとの人月は、要件定義や設計、実装、テストを中心に確認します。移行やPMに加えて、インフラとセキュリティの人月も見ます。
既存資産の読解やデータクレンジング、移行ツールは、実装費と別に計上される場合があります。並行稼働や性能試験、脆弱性診断、利用者教育も、別の項目になることがあります。
画面数やデータ件数、連携先と、テスト環境や納品物を、各項目に対応づけます。別途項目の発生条件が明記されていれば、後から予算を管理できます。
クラウド・保守・監視のランニングコスト
初期開発費に加えて、構成と保守範囲に応じた運用費も、見積もりに含めます。
- 基盤費：計算資源、RDB、ストレージ、負荷分散、転送、バックアップ、監視
- 検証環境：月数千円〜数万円。本番冗長化・RDB等は月5万〜30万円以上の推定
- 保守費：初期開発費の年15〜25%程度を仮置きする考え方
ログ保管やWAF、証明書のほか、サポートや保守人員も対象です。AWSのt3.mediumは、2 vCPU・4GiBのインスタンス例です。
公式ページの料金例は米国東部リージョンのLinux料金です。そのため、東京リージョンや周辺サービスの費用は、別途確認します（出典: AWS「Amazon EC2 T3インスタンス」、2026年確認）。
本番構成の金額は、構成から推定したものです。障害や脆弱性への対応、OSやJavaの更新、軽微な改修を、月額にどこまで含むかを比べます。
Servletの委託先選定と見積比較の確認項目
委託先は、「Servlet対応」「Javaに強い」という言葉だけでなく、自社に似た課題の解決実績で選びます。
新規開発や既存Servletの保守、javaxからjakartaへの移行、TomcatやJavaの更新では、必要な経験がそれぞれ異なります。
クラウド化や基幹連携も含めて実績を確認します。匿名化した事例であっても、規模や担当範囲、技術を聞きます。移行対象や品質管理、リリース後の体制も、あわせて確認します。
技術実績と担当体制の確認
技術選定の理由と、契約後に実務を担う担当者の体制を確認します。
- 技術：Java・Servlet API、コンテナ、DB、認証、CI/CD、監視、クラウド
- 既存資産：設定やコードの調査方法と移行単位
- 担当体制：役割、経験、稼働率、交代時の引き継ぎ、再委託
- 責任範囲：PM、業務設計、Java、インフラ、セキュリティ担当を体制図で確認
既存システムなら、web.xmlやFilter、Listener、JSPの扱いを、どう調べるかを確認します。セッションや直接SQLについても、同じように確認します。加えて、何単位で移行するかも聞きます。
Servlet 6.1を採用するかだけでなく、現行資産との互換性と保守期限を判断できることが重要です。
提案時のシニア担当者が契約後はレビューだけを担い、実装や障害対応を別チームに任せる場合もあります。
同じ前提の見積項目と除外項目
相見積もりは作業項目と前提条件をそろえ、含まれる範囲を比べます。
- 作業項目：要件定義、設計、実装、テスト、移行、インフラ、教育、保守、PMの金額と人月
- 比較条件：画面・API数、連携先、データ件数、接続数、環境、納品物、保守時間
- 除外項目：「別途」の発生条件、算定方法、上限、実施時期
異なる条件は、差分欄に記します。安い見積もりでは、要件定義やデータ移行が含まれているかを確認します。性能試験や脆弱性診断の有無も、あわせて見ます。利用者教育やリリース後の障害対応も、確認しておきます。
作業範囲や品質基準が具体的な提案は、追加費用を抑えやすくなります。リスク対応や納品物についても、具体性を確認します。
発注前の追加費用と移行失敗のリスク
契約前に未確定事項を洗い出し、移行と運用のリスクに備えます。
- 主なリスク：仕様の属人化、古いライブラリ・コンテナの期限、画面やFilter内の業務ルール
- 事前対応：短期アセスメントとリスク一覧で、影響と回避策、担当を定義
- リリース計画：段階・カナリア・並行稼働、ロールバック、DB復元、連絡網を決定
移行データの品質が悪い場合も、リスクになります。そのため、各リスクに発生条件と判断期限を割り当てます。
発注者が受入テストを行うなら、テストデータや環境、担当者、期間を確保します。
監視アラートやパッチ適用、ログ確認の担当者を決めます。問い合わせや軽微な改修の担当者も決め、見積と契約に反映します。
Servletのシステム発注・外注でよくある質問（FAQ）
Servletの外注では、技術用語や既存資産、費用、契約と保守責任について、疑問が生じやすくなります。そこで、発注前に押さえたい質問に答えます。
Servletだけを指定すれば業務システムを作れますか？
業務システムを完成させるには、Servletに加えて画面や業務ロジック、DBが必要です。さらに、認証や権限、外部連携、テスト、運用基盤も欠かせません。
発注時は、必要な機能と非機能を定めたうえで、委託先に技術構成を提案してもらう方法が適しています。
古いServletシステムは作り直すべきですか？
すぐに全面再構築する必要はありません。まず、利用状況や障害・変更の頻度、Java・コンテナの保守期限を調べます。
セキュリティリスクや業務ルールの複雑さ、移行できるデータも確認します。保守継続や段階更新から、再構築までを比べます。javaxからjakartaへの移行やAPI化も、選択肢に入ります。
小さな機能で互換性を検証してから全体方針を決めると、移行失敗のリスクを抑えやすくなります。
Servletの発注費用を抑えるにはどうすればよいですか？
単価だけを下げようとせず、要件漏れと手戻りを減らします。対象業務や画面、データに加えて、連携、非機能、受入条件を整理します。
また、複数社へ同じRFPを渡します。既存資産の診断やPoCを先に行い、優先度の低い機能を後続フェーズへ分ける方法もあります。
テストや移行、セキュリティ、保守を削ると、リリース後の総費用が増えます。そのため、品質に必要な工程は残します。
委託先へ最初に確認する質問は何ですか？
自社に似たServlet案件で担当した範囲と、Java・コンテナ・フレームワークの版の判断方法を尋ねます。
移行やデータ連携、性能の検証を誰が担うかも確認します。脆弱性の検証と、担当交代時の引き継ぎ内容も尋ねます。
見積の人月や除外項目、再委託の扱いも聞きます。ソースコードと設計書の権利、保守の初動時間も確認します。そうすると、技術力と契約条件を比べられます。
Servletのシステム発注・外注で失敗しないためのまとめ
Servletの発注では、技術名だけで丸投げせず、業務目的と現行資産の状態を発注者と委託先で共有します。
費用は画面数だけで決まりません。Java・コンテナの更新や権限、外部連携、データ移行などを含めて、非機能やテスト、保守まで見ます。
発注前に確認する5つのポイント
発注前に確認する項目を、進行順に並べます。
- 新規開発か既存刷新かの確認
- 一括外注、部分外注、PoCのうち適した方法の選択
- 業務・機能・非機能・移行の要件整理
- 請負と準委任の責任範囲をそろえること
- 見積、保守、セキュリティ条件の同じ前提での比較
5点がそろえば、価格だけでなく納品物とリスクも含めて、委託先を選べます。
特に、既存Servletでは、調査せずに固定価格を決めると、互換性の問題や移行対象の増加が起きやすくなります。
発注側は、最初にアセスメントを発注し、その結果をもとに本開発のRFPと契約を分ける方法もあります。
現行資産とRFPのたたき台の準備
最初の相談に向けて、現行資産と運用状況の分かる資料を集めます。
- システム情報：画面一覧、web.xml、Java・Tomcatの版、DB構成
- 業務・運用情報：外部連携、障害履歴、運用手順、利用者と権限
- 移行情報：移行したいデータと、分かっていること・不明なこと
そうすると、委託先は調査範囲と初期見積を示しやすくなります。
既存資産を活かせる可能性がある一方で、保守期限やセキュリティ、属人化を放置すると、刷新が難しくなります。
資料が不完全でも、既知のことと不明なことを分けて渡せます。そのうえで、業務と技術の両方を理解する委託先と、要件と費用、契約、運用を段階的に詰めることが、発注後の手戻りを減らします。
▼全体ガイドの記事
・Servletのシステム開発の完全ガイド
▼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を創業。