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

Strutsのシステムを発注・外注する場合は、フレームワーク名だけで委託先や予算を決めず、既存資産の調査、業務要件、移行方針、テスト範囲まで分けて依頼することが重要です。

StrutsはJava Webアプリケーションの画面やリクエスト処理を支えるフレームワークであり、販売管理、受発注、在庫、会員、EDIなどの業務システム全体を指す言葉ではありません。この記事では、Strutsのシステムを新規に作る場合と、既存システムを保守・刷新する場合を分け、発注形態、RFP、契約、費用相場、委託先の選び方、見積比較のポイントを順番に解説します。

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

Strutsのシステム発注・外注はどのように考えるべきですか？

結論からいうと、最初に決めるべきなのは「Strutsを使うか」ではなく、「業務を止めずに何を維持し、何を変えるか」です。新規開発でStruts 1を採用する理由はなく、既存システムでStrutsが使われている場合は、バージョン、脆弱性、JavaやWebコンテナ、データベース、外部連携を調査してから、保守継続か段階移行かを選びます。

新しい業務システムを作る発注であれば、Struts 1の採用を前提にせず、現在のサポートやセキュリティ更新を受けられる技術、将来の保守人材を確保しやすい構成を比較します。Apache公式は2026年6月時点でStruts 7.2.1とStruts 6.10.0のリリースを案内していますが、最新版を使えば自動的に既存資産を安全に移行できるわけではありません。Javaの世代、Jakarta EE対応、JSPタグ、認証方式、帳票、運用環境まで含めた適合性の確認が必要です（出典: Apache Struts公式、2026年6月）。

一方、既存のStrutsシステムは、画面をそのまま使いたい、業務ルールを変えたくない、停止可能な時間が短いという事情があります。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やバッチに業務ルールが残っていれば、移行後のテストは減りません。技術と業務の両面を一枚の対象範囲にまとめることが、見積もりのぶれを抑える出発点です。

発注形態はどれを選べばよいですか？

発注形態は、完成責任まで任せたいのか、要件や運用の判断を自社に残したいのかで選びます。Strutsのシステムでは、現行調査だけを外部へ依頼し、その結果をもとに移行開発を別契約にする二段階方式も有効です。いきなり全工程を一社へ固定せず、リスクの大きい部分から小さく外注する考え方が失敗を防ぎます。

要件定義から設計、開発、テスト、リリース、保守までを一社へ依頼する方式は、窓口が一本化され、障害時の責任分界を整理しやすい点がメリットです。社内にJavaやStrutsを理解する担当者が少なく、業務部門も通常業務で手いっぱいであれば、一括委託が現実的です。

ただし、丸投げにすると、業務上の優先順位や受入基準まで委託先任せになります。発注者側にプロジェクト責任者を置き、要件の承認者、データ移行の責任者、テスト参加者、リリース判断者を決めます。一括委託でも、成果物一覧と会議体、報告頻度、課題管理の方法を契約書や計画書に残すことが必要です。

現行調査、脆弱性対応、テスト設計、クラウド移行など、特定の作業だけを外注する方式は、社内に業務知識や運用ノウハウを残しやすい方法です。たとえば、既存画面の棚卸しと依存ライブラリの調査を外注し、業務要件の決定と受入テストは自社が担当する分担が考えられます。

一方で、複数社をまたぐと、仕様の解釈や障害の責任が曖昧になりやすくなります。StrutsのAction、JSP、DB、バッチ、インフラを別会社に分ける場合は、インターフェース、レビュー担当、成果物の形式、問い合わせ窓口を先に決めます。社内にPMやアーキテクトがいない場合は、第三者のPMO支援を加えると、価格比較だけでは見えないリスクを管理しやすくなります。

販売管理、勤怠、経費、問い合わせ管理など、業務を標準化できる領域は、Strutsを改修するよりSaaSやパッケージへ置き換えた方が保守負担を抑えられる場合があります。逆に、取引先固有のEDI、複雑な料金計算、独自の承認ルールなどは、既存システムの知識を生かした段階移行が適しています。

比較では、初期費用だけでなく、データ移行、API連携、ユーザー教育、月額料金、追加設定、解約時のデータ返却を含めた3〜5年の総額を見ます。発注先には「スクラッチ継続」「Spring系へ移行」「SaaS・パッケージ置換」の3案を同じ前提で提案してもらうと、技術の好みではなく事業への適合性で判断できます。

Strutsのシステム発注・外注はどのように進めますか？

発注は、現行調査、要件整理、RFP作成、提案比較、契約、設計・開発、テスト、リリース、保守引き継ぎの順に進めます。既存Strutsでは、調査と要件定義を省略して開発会社へ見積もりを求めると、後から不明点が追加費用や納期延長になります。調査段階で分からないことを分からないまま可視化することが、発注の品質を上げます。

最初の調査では、リポジトリや本番サーバーのコピー、WARファイル、設定ファイル、JSP、Action、Interceptor、独自タグ、依存ライブラリを確認します。さらにJava、TomcatやJBossなどのWebコンテナ、DB、OS、バッチ、帳票、メール、外部API、認証基盤のバージョンを台帳化します。ソースコードがない、ビルド手順が不明、担当者が退職しているといった情報も、隠さずリスクとして記載します。

業務要件では、画面ごとの利用者、入力項目、権限、状態遷移、締め処理、例外処理、帳票、データ保存期間を確認します。特に「今の画面と同じにする」という要望は、見た目だけでなく、二重送信防止、セッション切れ、エラー表示、CSVの文字コード、端数処理まで含むことがあります。発注者と受託者でこの解釈がずれると、完成後に仕様変更が多発するため、代表的な業務シナリオを受入条件まで書きます。

RFPには、背景と目的、対象業務、対象外の業務、現行構成、利用者数、性能要件、セキュリティ要件、稼働時間、停止可能時間、希望納期、予算の考え方、保守体制を記載します。Strutsの発注では、Struts 1かStruts 2か、具体的なバージョン、Java・コンテナ・DBのバージョン、JSPや独自フレームワークの有無を明記すると、対応できない会社を初期段階で除外できます。

移行を依頼する場合は、現行踏襲か再設計か、StrutsのアップデートかSpring MVC・Spring Bootへの移行か、クラウド化を同時に行うかを分けて書きます。成果物は、現行調査報告書、要件定義書、設計書、ソースコード、テスト仕様書・結果、脆弱性診断結果、運用手順書、データ移行結果、リリース手順書などです。納品物の形式、レビュー回数、修正期限、ソースコードと著作権の扱いも、見積もり前に確認します。

Strutsの移行は、すべての画面が同じ難易度ではありません。入力バリデーション、ファイルアップロード、帳票、複雑なセッション制御、独自タグ、外部連携、バッチと画面のトランザクションなどを代表サンプルに選び、変換率、手作業の量、テスト方法、性能への影響を確認します。1〜2か月程度の調査・PoCを先に発注し、その成果を本開発のRFPへ反映する方式は、全体を推測で見積もるより安全です。

複数社の提案は、総額だけでなく、調査の前提、対象画面数、含まれるテスト、移行後のサポート、発注者側の作業、除外事項を同じ表で比較します。公開事例では、シーイーシーがStruts 1のEDIシステムについて、画面の使い勝手を維持しながらSpring MVCへ移行し、変換から運用テスト・リリースまで約6か月と紹介しています（出典: 株式会社シーイーシー公開事例）。サビテックジャパンの事例も、見積・契約・勤務・請求管理を含むStruts 1システムをSpring MVCへ移行し、開発期間6か月、契約形態は請負と記載しています（出典: サビテックジャパン公開事例）。ただし、これらは個別事例であり、自社の期間を保証するものではありません。

Strutsの外注で契約形態と責任範囲をどう決めますか？

契約形態は、要件が固まっているか、成果物を検収できるか、途中で変更が出るかで選択します。請負、準委任、派遣に近い支援では、受託者の責任、指揮命令系統、作業時間、成果物、検収、変更管理が異なります。名称だけでなく、実際の業務分担と契約書の条項を法務担当者と確認することが大切です。

請負は、合意した成果物を完成させ、発注者が検収する形に向いています。要件定義書、設計書、ソースコード、テスト結果、移行結果など、完成の基準を文書化しやすい開発・移行工程で使われます。検収条件が「問題なく動くこと」の一文だけでは、画面の再現範囲、データ件数、性能、権限、障害時の復旧、ブラウザー対応を巡って争いになりやすいため、業務シナリオと合格基準を定義します。

請負で注意したいのは、発注者が要件を途中で変更したときの扱いです。追加機能、対象画面の増加、テストデータ作成の追加、停止時間の短縮などが発生した場合に、変更依頼、影響見積もり、承認、契約変更の流れを決めておきます。納期を優先してテストを削ることがないよう、品質に関わる作業を除外できない条件も設けます。

現行調査、アーキテクチャ検討、RFP作成支援、PMO、保守のように、作業内容は定義できても完成物や工数を最初から固定しにくい工程には、準委任が使われることがあります。発注者と受託者が調査結果を見ながら優先順位を変えられるため、ブラックボックス化したStrutsシステムの初期段階に向いています。

準委任では、受託者が一定の善管注意義務を負う一方、特定の完成結果を請け負う契約とは異なります。作業時間、担当者、会議体、報告書、調査対象、未解決課題、次工程の判断材料を明確にし、成果が見えにくい契約にしないことが必要です。開発工程を請負、調査とPMOを準委任にするなど、工程ごとに組み合わせる方法もあります。

Strutsの保守を外注するときは、ソースコード、設計書、テストコード、変換ツール、設定ファイル、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・コンテナ・DBの更新、障害対応、問い合わせ、教育、データ保管が発生します。保守・運用費は契約内容によって大きく異なるため、初期開発費の一定割合だけで判断せず、月次作業と緊急対応の単価を確認します。特に旧バージョンを延命する場合は、パッチ調査や有識者確保の費用を別に見ておく必要があります。

委託先の選定と見積比較では何を確認しますか？

委託先は「Javaを扱えるか」だけでなく、Strutsの既存資産を読み解き、業務を止めずに移行・保守できるかで選びます。提案段階で担当予定者が実際にStrutsのAction、JSP、設定ファイル、依存ライブラリを確認し、難所を説明できるかを見ます。公開実績の有無だけでなく、どの工程を担当したのか、移行後の保守を誰が担うのかまで確認してください。

実績を確認するときは、「Struts対応」と書かれているだけで満足しません。Struts 1からSpring MVCへ移行したのか、Struts 2の脆弱性対応をしたのか、JavaやTomcatを更新したのか、OracleやPostgreSQLを含む業務システムを保守したのかを質問します。現行調査、変換、非互換対応、テスト設計、データ移行、リリース、保守のどこを担当したかが、委託先の適合性を判断する材料です。

提案に、代表的な移行対象を3つ挙げてもらうのも効果的です。たとえば、入力バリデーションとエラー表示、ファイルアップロード、帳票出力や外部API連携をどのように調査・テストするかを聞きます。「自動変換できます」と言う会社には、変換できない部分の判定、手修正の見積もり、比較テストの方法を確認します。自社と同じ業界の実績がなくても、業務ルールを抽出してテストに落とし込む力があれば候補になります。

見積比較では、A社が現行調査を含み、B社が含まないといった前提の違いをそろえます。画面数、帳票数、外部連携数、テストデータ、ブラウザー、対応OS、性能目標、移行対象データの期間、休日・夜間作業、リリース後の保証期間を同じ条件で再提示します。価格差が出たときは、安い方が優れているのではなく、含まれていない作業がないかを確認します。

また、固定価格と人月精算を混ぜて比較しないことも重要です。固定価格の請負なら、追加費用が発生する条件と検収基準を見ます。準委任なら、月ごとの体制、稼働時間、成果報告、終了条件を確認します。保守費についても、月額に含まれる問い合わせ、障害対応、パッチ適用、定期リリース、緊急呼び出しの範囲を同じ表に書くと、5年間の総額を比較しやすくなります。

Strutsのシステムでは、単体テストが通っても、画面遷移、権限、セッション、帳票、バッチ、外部連携、同時利用、データ移行後の残高が正しいとは限りません。見積もりに、業務シナリオの作成、発注者レビュー、総合テスト、性能テスト、脆弱性診断、障害修正、再テストが含まれているかを確認します。受入テストのデータと実施者を発注者・受託者のどちらが用意するかも決めます。

リリース後は、初期不具合の無償対応期間、重大障害の復旧目標、旧環境へのロールバック、監視、ログ確認、バックアップ復元、問い合わせの引き継ぎを確認します。特に移行後に初めて発覚する業務ルールの漏れは、契約上の瑕疵なのか追加改修なのか判断が分かれます。原因調査と再発防止の責任分界を、検収前から話し合っておくと安心です。

よくある質問（FAQ）

Strutsの発注では、技術の更新だけでなく、業務の継続、契約、保守まで確認する必要があります。ここでは、発注担当者から相談されやすい質問に、判断の基準を直接回答します。

新規開発でStruts 1を選ぶことは避けるべきです。既存資産との互換性など、特別な理由がある場合も、サポート状況、脆弱性対応、将来の保守人材、Javaやコンテナの更新計画を確認し、Spring系やSaaS・パッケージを含めて比較します。

すぐに全面移行できるとは限りません。まずバージョン、公開範囲、扱う情報、脆弱性、停止可能時間、ソースコードとテストの状態を調査し、パッチ・隔離・短期保守で時間を確保しながら、段階移行や置き換えの計画を作ります。サポート切れだからという理由だけで業務とデータを一度に作り直すのではなく、リスクと事業影響を並べて優先順位を決めます。

Strutsのバージョン、Java・Webコンテナ・DBのバージョン、画面数、Action数、帳票、バッチ、外部連携、利用者数、停止可能時間、希望時期、既存のテスト資産、ソースコードの有無を伝えます。分からない項目は「不明」と書き、現行調査を見積もりに含めてもらいます。完成物、受入条件、保守範囲、契約形態、予算の上限または予算レンジも初期段階で共有すると、提案の比較がしやすくなります。

一番安い会社が適切とは限りません。調査、テスト、移行、保守、障害対応が見積もりから抜けていると、契約後の追加費用や業務停止のリスクが高まります。同じRFPと同じ対象範囲で、担当者の経験、成果物、除外事項、保守体制、5年間の総額を比較し、安さではなくリスクを含む総コストで判断します。

Strutsのシステムを発注・外注するときのまとめ

Strutsのシステムを外注する際は、まず新規開発か既存システムの保守・刷新かを分けます。既存の場合は、Strutsのバージョンだけでなく、Java、Webコンテナ、DB、JSP、Action、帳票、バッチ、外部連携、テスト資産を調査します。そのうえで、短期保守、Strutsの更新、Spring系への段階移行、SaaS・パッケージ置換を同じ前提で比較します。

RFPには目的、対象範囲、現行構成、変更方針、移行方式、成果物、受入条件、停止可能時間、保守要件を記載します。契約では、請負か準委任か、変更管理、検収、知的財産、再委託、秘密保持、脆弱性対応、障害時の責任を具体化します。費用は小規模100万〜300万円、中規模300万〜800万円、既存Strutsの大規模移行は1,000万〜3,000万円程度を仮置きできますが、いずれも公開相場・工数から作る目安であり、正式な予算は現行調査とPoC後に確定します。

委託先を決める前に、現行資産の一覧と不明点を作り、調査・脆弱性診断・PoCの範囲を小さく依頼します。見積書は金額だけでなく、前提、含む作業、除外事項、テスト、リリース後の保守を比較します。Strutsのシステムを安全に発注する鍵は、技術を一気に置き換えることではなく、業務を止めないための判断材料を発注者と委託先で共有することです。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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