Strutsのシステム開発を外部に発注するときは、まず現行システムと業務要件を調べ、RFPで依頼する範囲を定めます。そのうえで提案と契約を比べ、段階的に移行する進め方を選ぶと、業務を止めずに進めやすくなります。
▼全体ガイドの記事
・Strutsのシステム開発の完全ガイド
AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。
Strutsのシステム発注・外注の考え方
発注で最初に決めたいのは、業務を止めずに何を維持し、何を変えるかです。Strutsを使い続けるかどうかは、この答えを踏まえて判断します。
新規開発と既存Strutsの刷新の判断軸
新規開発と既存システムは前提が違うため、それぞれ別の判断軸で考えます。
- 新規開発：Struts 1を前提にせず、サポートや更新、保守人材を軸に技術を比べます。
- 既存システム：画面や業務ルールの維持と、停止可能時間を踏まえた移行方針。
Apache公式は、2026年6月時点でStruts 7.2.1と6.10.0のリリースを案内しています。ただし、最新版であっても、既存資産が自動的に安全な状態へ移るわけではありません。
そのため、既存のStrutsでは、Javaの世代とJakarta EE対応を確かめ、JSPタグや認証方式、帳票も運用環境との適合性とあわせて見ておきます（出典：Apache Struts公式、2026年6月）。
Struts 1は2013年4月5日にサポートが終了しています。また、Struts 2.3も2019年9月12日にEOLとなっています。
IPAは、Struts 1を脆弱性情報一覧の対象外としています。一方、Struts 2については、影響するバージョンの確認とテスト後の更新を促しています（出典：IPA「Apache Struts2の脆弱性対策情報一覧」、2026年1月13日）。
発注前の業務と技術の境界
「Strutsの保守」とひとくくりにしたままでは、作業量を見積もれません。まず現状を把握するため、次の資産と利用状況を一覧にしておきます。
- システム構成：画面、Action、JSP、DBテーブル、帳票、バッチ
- 連携と利用状況：外部API、認証・権限、利用者数、月間トランザクション
- 保守資料：障害履歴、テスト資産、ソースコードの保管場所
技術資料が足りない項目は「現状不明」と書いておきます。情報が不足していること自体も、調査と見積もりに必要な条件です。
業務側では、残す業務と廃止する業務を分けます。そのうえで、手作業に戻せる業務と、SaaSやパッケージへ置き換えられる業務も見ておきます。
特に、Struts部分だけを書き換えても、複雑なSQLやバッチに業務ルールが残っていると、移行後のテストの量は減りません。技術と業務の対象範囲を一枚の表にまとめることが、見積もりのぶれを抑える出発点になります。
発注形態の選び方
発注形態は、完成責任を任せる範囲と、要件や運用の判断を自社に残す範囲で決めます。たとえば、現行調査だけを外部に頼み、その結果をもとに移行開発を別契約にする二段階の方式もあります。
全工程を一社に固定せず、リスクの大きい部分から外注する方法は、発注時の失敗を防ぐ助けになります。
一社への一括委託と責任の所在
一括委託では、要件定義から設計、開発、テスト、リリース、保守までを一社に依頼します。窓口が一本化されるため、障害時にどこまでを誰が受け持つかを整理しやすくなります。
社内にJavaやStrutsの担当者が少なく、業務部門も通常業務で手いっぱいなら、一括委託は現実的な選択肢です。ただし、丸投げしてしまうと、優先順位や受入基準まで委託先任せになります。
そこで、発注者側に責任者を置き、要件の承認者とデータ移行の責任者を決めておきます。テスト参加者とリリース判断者も決めておきます。成果物、会議の進め方、報告の頻度、課題管理の方法は、計画書や契約書に残しておきます。
部分委託・共同開発と社内に残す知見
社内に残す業務知識と、外部の専門性を借りる作業を分けて、役割を分担します。
- 外注する作業：現行調査（画面や依存ライブラリを含む）、脆弱性対応、テスト設計、クラウド移行
- 社内で担う作業：業務要件の決定と受入テスト。
- 複数社の調整：仕様の解釈や障害責任を明確にするため、窓口とレビュー担当を決めておきます。
- PMO支援：社内にPMやアーキテクトがいない場合は、第三者の支援でリスクを管理します。
複数社にまたがると、仕様の解釈や障害の責任が曖昧になりやすくなります。
Action、JSP、DB、バッチ、インフラに分けて頼む場合は、まず境界を決めます。そのうえで、レビュー担当、成果物の形式、問い合わせ窓口も定めておきます。
SaaS・パッケージへの置き換えの比較
業務が標準化しやすいか、独自ルールが多いかを見極めてから、移行先を比べます。
- 標準化できる業務：販売管理、勤怠、経費、問い合わせ管理はSaaS等で保守負担を抑えられる場合があります。
- 独自ルールが多い業務：固有EDI、複雑な料金計算、独自承認は、既存の知識を生かしながら段階的に移行します。
- 比較する案：「スクラッチ継続」「Spring系へ移行」「SaaS・パッケージ置換」の各案を、同じ前提で比べます。
総額には、初期費用、データ移行、API連携を含めます。教育や月額料金、追加設定、解約時のデータ返却も入れて、3〜5年で比べます。
Strutsのシステム発注・外注の進め方
既存Strutsの発注では、調査や要件定義を省くと、不明点が追加費用や納期の延長につながります。そのため、次の順に進めて、調査の時点で不明点も一覧にしておきます。
- 現行資産を調査する
- 業務要件と対象範囲を整理する
- RFPを作成して提案を比較する
- 契約を結び、設計・開発とテストを進める
- リリース後に保守を引き継ぐ
現行調査と要件整理による「変えない範囲」の決定
現行調査では、技術資産と業務要件を洗い出し、移行の対象と受入条件をはっきりさせます。
- 技術資産：リポジトリ、本番環境のコピー、WAR、設定を確認します。JSPやAction、Interceptor、独自タグ、依存ライブラリも対象です。
- 実行環境：Java、TomcatやJBoss、DB、OSのバージョンを台帳にまとめます。バッチ、帳票、メール、外部API、認証基盤も含めます。
- 業務要件：利用者、入力項目、権限、状態遷移を画面ごとに確認します。締め・例外処理、帳票、保存期間も同じ単位で見ます。
- 受入条件：画面の再現には、二重送信、セッション切れ、エラー表示、CSVの文字コード、端数処理が含まれる場合があります。
ソースコードがない、ビルド手順が分からない、担当者が退職したといった事情も、隠さずにリスクとして記載します。
解釈のずれは仕様変更につながるため、代表的な業務シナリオを受入条件のところまで書いておきます。
RFPに載せる成果物・移行方式・受入条件
RFPには、背景と目的、対象・対象外の業務、現行構成を書きます。利用者数や性能・セキュリティ要件、稼働時間、停止可能時間は、提案の条件をそろえるうえで欠かせません。納期、予算、保守体制も、同じRFPに載せます。
Struts 1か2か、具体的なバージョン、Java・コンテナ・DBのバージョン、JSPや独自フレームワークの有無まで明記します。そのため、対応できない会社を初期段階で除外できます。
成果物には、現行調査報告書、要件定義書、設計書、ソースコードがあります。テスト仕様書・結果や脆弱性診断結果、運用手順書、データ移行結果、リリース手順書なども含まれます。
- 移行方針：現行踏襲か再設計か、Struts更新かSpring MVC・Spring Boot移行かの区別。
- クラウド化：移行と同時に行うかどうかを明記します。
納品形式、レビュー回数、修正期限、ソースコードと著作権の扱いは、見積もり前に確かめます。
PoCと提案比較による移行の難所の確認
画面ごとに難しさが違うため、代表的なサンプルを選び、移行の難所を先に調べます。
- 画面機能：入力バリデーション、ファイルアップロード、帳票、複雑なセッション制御
- 連携機能：独自タグ、外部連携、バッチと画面のトランザクション
サンプルから、変換率、手作業の量、テストの方法、性能への影響を確かめます。1〜2か月程度の調査・PoCを先に行い、その成果を本開発のRFPに反映する進め方は、推測での見積もりより安全です。
提案は総額だけでなく、調査前提、対象画面数、テスト、移行後サポート、発注者側の作業、除外事項を、同じ表で比べます。
シーイーシーの公開事例では、Struts 1のEDIシステムをSpring MVCへ移行しました。画面の使い勝手を維持しながら、変換から運用テスト・リリースまで約6か月と紹介しています（出典：株式会社シーイーシー公開事例）。
サビテックジャパンの事例では、見積・契約・勤務・請求管理を含むStruts 1システムをSpring MVCへ移行しました。また、開発期間は6か月で、契約形態は請負とされています（出典：サビテックジャパン公開事例）。
どちらも個別の事例で、自社の期間を保証するものではありません。
Strutsの外注における契約形態と責任範囲
契約は、要件がどこまで確定しているか、成果物を検収できるか、途中で変更が入りそうかによって選びます。請負、準委任、派遣に近い支援では、受託者の責任や指揮命令系統が異なります。
作業時間や成果物の扱い、検収、変更管理も契約ごとに違うため、契約の名称だけで決めず、実際の分担と契約条項を法務担当者と確かめます。
請負契約の完成物と検収条件
請負では、合意した成果物を受託者が完成させ、発注者が検収します。そのため、完成の基準と、要件を変えるときの手順を明確にしておく必要があります。
要件定義書や設計書、ソースコード、テスト結果、移行結果などは、完成基準として文書にします。
- 検収条件：「問題なく動くこと」だけにせず、業務シナリオと合格基準を定めます。
- 変更管理：変更依頼から影響見積もり、承認、契約変更までの流れ。
- 品質確保：納期を理由に、テストなどの品質作業を外せない条件を設けます。
検収条件には、画面の再現範囲、データ件数、性能、権限、障害時の復旧、ブラウザー対応を含めます。
準委任が合う調査・要件定義・伴走支援
完成物や工数を固定しにくい工程では、準委任が使われることがあります。
- 対象工程：現行調査、構成検討、RFP支援、PMO、保守などが候補です。
- 調整のしやすさ：調査結果を見ながら優先順位を変えられ、初期調査の段階に合います。
- 契約内容：請負と違って完成結果は約束せず、作業時間、担当者、会議、報告書、調査対象を定めます。
- 工程の組み合わせ：開発は請負、調査やPMOは準委任にする方法もあります。
受託者は善管注意義務を負いますが、特定の完成結果を請け負う契約とは違います。そのため、未解決の課題と次工程の判断材料を記録し、成果が見えにくい契約にしないことが大切です。
契約に含める知的財産・秘密保持・保守
保守契約では、成果物の保有者、データ管理、保守対応の範囲をはっきりさせておきます。
- 成果物と権利：コード、設計、テスト、変換ツール、設定の保有者を確認します。CI/CDやDDL、手順書の保有者も確かめます。
- 引き継ぎ：汎用部品と固有成果物を分け、契約終了後に別会社へ移せる状態にします。
- データ管理：個人情報などを扱う場合は、再委託と国外保管を定めます。権限、ログ、事故報告期限、脆弱性連絡も、あわせて決めます。
- 保守範囲：受付時間、障害優先度、回答・復旧目標、パッチ、診断、更新を契約に記載します。
重要な作業がオプション扱いだと、契約は安く見えても、実際の運用費は高くなります。
Strutsのシステム発注にかかる費用相場の目安
Strutsのシステム開発に一律の料金表はありません。費用は、画面数、業務ロジック、データ量、外部連携によって変わります。さらに、テスト資産や停止制約、移行方式でも変わります。
2026年の業務系Webシステムの公開相場は、小規模が100万〜300万円、中規模が300万〜800万円、大規模が800万円から数千万円です（出典：イー・ジーシステム「システム開発の費用相場と見積書の読み方・2026年版」）。これは一般的な業務システムの目安で、Strutsに固有の確定価格ではありません。
規模別の予算レンジと初期計画
規模と作業範囲で予算レンジは変わります。そのため、案件の条件をそろえたうえで、初期計画に使います。
- 小規模：数画面・単一DB・少ない外部連携の保守や追加は100万〜300万円程度
- 中規模：複数業務に権限、帳票、API連携、総合テストを含めると300万〜800万円程度
- 大規模：基幹連携、EDI、複数DB、並行稼働、移行、夜間リリースで800万円から数千万円。要件次第でさらに増えます。
- Struts 1移行：Spring MVCやSpring Bootへの移行は1,000万〜3,000万円程度を仮置きする場合があります。
このレンジは公開料金ではなく、2〜4名程度が約6か月関わる場合の人月と、管理・予備工数から算出した試算です。
公開事例にも6か月前後の案件がありますが、画面数や連携数によって費用も期間も変わります。そのため、PoCの後に、必ず再見積もりを受けます。
工程別・作業別の内訳による見積もりの確認
見積もりの粒度を対象一覧と見比べ、開発一式に隠れた作業や運用費を確かめます。
「開発一式」では、対象の画面や機能が分かりません。画面、機能、API、帳票などの単位で、対象一覧と照合します。
- 工程別費用：要件定義、調査、設計、開発を分けて示してもらいます。テストや診断、移行、リリース、管理も、工程ごとに分けます。
- 初期費用以外：クラウド、サーバー、監視、バックアップの費用を確かめます。ライセンス、更新、障害対応の費用も含めます。
- 保守・運用費：問い合わせ、教育、データ保管、月次作業、緊急対応の単価を確認します。
保守費は契約によって違うため、初期開発費の一定割合だけでは判断できません。
旧バージョンを延命する場合は、パッチの調査や有識者の確保にかかる費用も、別に見ておきます。
委託先の選定と見積比較で確認する観点
委託先は、Javaの経験の有無だけでなく、既存のStruts資産を読み解き、業務を止めずに移行や保守ができるかで選びます。
提案の時点で、担当予定者がAction、JSP、設定ファイル、依存ライブラリを確認し、難所を説明できるかを見ます。また、実績の担当工程と、移行後の保守担当も確かめます。
作業の証拠で見るStruts実績
「Struts対応」という表記だけでなく、具体的な実績を確かめます。
- 実績の内容：Struts 1からSpring MVCへの移行、Struts 2の脆弱性対応、Java・Tomcatの更新を確認します。
- 担当工程：調査、変換、非互換対応、テスト設計のうち、どこを担当したかを確かめます。データ移行、リリース、保守も含みます。
- 調査・テスト力：代表対象を3つ挙げてもらい、入力検証、ファイル、帳票、API連携の調査・テスト方法を聞きます。
- 業務理解：同業界の実績がなくても、業務ルールをテストに落とせれば候補になります。
OracleやPostgreSQLを含む業務システムの保守経験も確かめます。自動変換について説明を受けるときは、手修正の見積もりと比較テストの方法も求めます。
見積比較の前提と除外事項のそろえ方
見積比較では、A社は現行調査を含み、B社は含まないといった前提のずれを、そろえてから比べます。
- 対象範囲：現行調査、画面・帳票・連携数、テストデータ、ブラウザー、OSを合わせます。
- 実施条件：性能、データ期間、休日・夜間作業、保証期間を同じ条件にそろえて再提示します。
- 契約方式：請負なら追加費用と検収、準委任なら体制、稼働時間、報告、終了条件を見ます。
- 保守費：問い合わせ、障害、パッチ、定期リリース、緊急呼び出しを含む5年間の総額で比べます。
固定価格と人月精算は前提が異なるため、同列で比べず、契約ごとの費用条件を確かめます。月額料金に含まれない作業には、追加費用の条件も確認しておきます。なお、価格差があれば、安い方の見積もりに作業の漏れがないかを確かめます。
受入テストとリリース後の責任の比べ方
業務全体や移行後データの正しさは、単体テストとは別の確認が必要です。
- 受入テスト：画面遷移、権限、セッション、帳票を確認します。バッチ、外部連携、同時利用、移行後残高も対象です。
- テストの分担：業務シナリオ、レビュー、総合・性能テスト、診断、修正、再テストの担当を決めます。
- リリース後：無償対応期間、復旧目標、ロールバックを確認します。監視、ログ、バックアップ、問い合わせの引き継ぎも見ます。
受入テストのデータを準備する人と実施する人も決めておき、バックアップからデータを復元できるかも確かめます。
移行後に見つかった業務ルールの漏れが、瑕疵になるのか追加改修になるのか、判断が分かれる場合があります。そのため、原因の調査や再発防止について、どこまでを誰が受け持つかを検収の前から話し合います。
よくある質問（FAQ）
Strutsの発注では、技術の更新に加えて、業務の継続、契約、保守も確かめる必要があります。
新規システムの開発でStrutsを選んでも問題ありませんか？
新規開発でStruts 1を選ぶことは、避けるべきです。既存資産との互換性などの特別な理由がある場合も、サポート状況、脆弱性対応、将来の保守人材、Javaやコンテナの更新計画を確かめます。そのうえで、Spring系やSaaS・パッケージも含めて比べます。
既存のStrutsシステムはすぐに全面移行すべきですか？
全面移行を急ぐ前に、バージョン、公開範囲、扱う情報、脆弱性を調べます。停止可能時間やソースコード、テストの状態も、あわせて確かめます。
パッチや隔離、短期保守で時間を確保しながら、段階的な移行や置き換えを計画します。業務とデータを一度に作り直すより、リスクと事業影響で優先順位を決めます。
見積もり依頼時に最低限伝える情報は何ですか？
まず、Struts、Java、Webコンテナ、DBの各バージョンを伝えます。そのうえで、画面数やAction数、帳票、バッチ、外部連携も示します。さらに、利用者数、停止可能時間、希望時期も添えます。
テスト資産とソースコードの有無も伝えます。不明な項目は「不明」と書き、現行調査を見積もりに含めてもらいます。
完成物、受入条件、保守範囲、契約形態、予算上限または予算レンジも、初期段階で共有しておくと、提案を比べやすくなります。
一番安い会社へ発注するのがよいですか？
価格が一番低くても、調査、テスト、移行、保守、障害対応に抜けがあると、追加費用や業務停止のリスクが高まります。
同じRFPと範囲のもとで、担当者の経験、成果物、除外事項、保守体制、5年間の総額を比べます。安さだけでなく、リスクを含めた総コストで判断します。
Strutsのシステムを発注・外注するときのまとめ
外注では、新規開発と既存システムの保守・刷新を分けて考えます。既存の場合は、Strutsに加えて、Java、Webコンテナ、DB、JSPの状態を調べます。Action、帳票、バッチ、外部連携、テスト資産も、あわせて確認します。
短期保守、Struts更新、Spring系への段階移行、SaaS・パッケージ置換は、同じ前提で比べます。
発注前に優先するRFPと契約の確認
発注前の確認は、RFPに書く内容と、契約で定める責任の二つに分けて考えます。
- RFP：目的、範囲、現行構成、変更・移行方針を書きます。成果物、受入条件、停止可能時間、保守要件も入れます。
- 契約：請負・準委任、変更管理、検収の条件を確認します。知的財産、再委託、秘密保持、脆弱性、障害時の責任も含めます。
費用は、小規模が100万〜300万円、中規模が300万〜800万円、Struts 1からSpring系への移行が1,000万〜3,000万円程度を、仮置きの目安にできます。
いずれも、公開相場や工数から作った目安です。そのため、正式な予算は現行調査とPoCの後に確定します。
最初の一歩は現行資産の一覧づくり
委託先を決める前に、現行資産と不明点を一覧にします。そのうえで、調査、脆弱性診断、PoCを小さな範囲で依頼します。
見積書では、金額だけでなく、前提、対象作業、除外事項、テスト、リリース後の保守を比べます。業務を止めない判断材料を、発注者と委託先で共有することが、発注の鍵になります。
▼全体ガイドの記事
・Strutsのシステム開発の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。