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

Strutsのシステム開発は、現行業務を止めずに要件を整理し、既存資産の調査から設計・テスト・稼働後の定着までを段階的に進めることが成功の要点です。新規開発でStruts 1を採用するのではなく、既存システムの保守、脆弱性対応、StrutsからSpring系への移行を含めて判断する必要があります。

本記事では、販売管理、受発注、在庫、会員管理などの業務システムを想定し、Strutsのシステム開発の進め方を「要件整理→選定→設計開発→テスト→稼働→定着」の6フェーズで解説します。費用相場、見積もりで確認すべき項目、ベンダーへの質問、移行時のチェックリストまでまとめますので、社内で企画を立てる担当者や開発会社を比較する担当者にも役立ちます。

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

Strutsのシステム開発の全体像は？

Strutsは業務パッケージそのものではなく、JavaでWebアプリケーションを構築するためのMVCフレームワークです。画面、業務ロジック、データベース、認証、帳票、バッチ、外部APIなどを組み合わせて、初めて「Strutsのシステム」として業務を支えます。したがって、進め方を決めるときはフレームワークの更新だけでなく、業務機能と周辺基盤を含めて考えます。

Struts 1では、リクエストを受けるAction、フォーム値を扱うActionForm、画面遷移を定義するstruts-config.xml、JSPタグライブラリが典型的な構成です。Struts 2ではAction、Interceptor、OGNL、struts.xmlなどが中心になります。実際の業務システムでは、TomcatやJBossなどのWebコンテナ、OracleやPostgreSQLなどのデータベース、SpringやHibernate、帳票ツール、夜間バッチ、外部サービスとの連携が加わります。

調査の最初に作るべきものは、単なる画面一覧ではなく、画面とAction、参照・更新テーブル、権限、外部連携、帳票、バッチを結びつけた構成図です。例えば受注登録画面を調べる場合は、入力チェック、在庫引当、得意先マスタ参照、売上計上、メール通知、エラー時のロールバックまで追います。業務ルールがJavaやSQLに埋め込まれている場合、画面を新しくしてもルールを再現できなければ移行は成功しません。

新規開発でStruts 1を選ぶことは、サポート終了とセキュリティ対応の観点から避けるべきです。Apache公式のEOL一覧では、Struts 1.xは2013年4月5日、Struts 2.3.xは2019年9月12日、Struts 2.5.xは2023年10月30日にEOLとなっています（出典: Apache Struts公式「End-of-Life Versions」、2026年確認）。既存システムについては、古いという理由だけで廃棄を決めず、業務価値、脆弱性、停止可能時間、移行難易度を調査して方針を決めます。

選択肢は、短期のパッチ適用と保守、サポート対象のStrutsへの更新、Spring MVCやSpring Bootへの段階移行、SaaS・パッケージへの置き換え、全面的なスクラッチ開発の5つに整理できます。標準的な業務はパッケージへ寄せ、競争優位に直結する処理だけをJavaで残すハイブリッドも現実的です。判断では「何を使うか」より「何年、どの体制で安全に業務を継続するか」を先に定義します。

Strutsのシステム開発の進め方

Strutsのシステム開発は、技術者がすぐにコードを書くより、現行業務と技術資産の不確実性を減らす順番で進めることが重要です。ここでは、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズに分けます。各フェーズの終了条件を決めてから次へ進むと、後工程での手戻りや追加請求を抑えやすくなります。

最初に、対象業務、利用者、処理量、繁忙期、停止可能時間、法令・監査要件、個人情報や決済情報の有無を整理します。次に、WARファイル、ソースコード、JSP、設定ファイル、Action、Interceptor、独自タグ、ライブラリ、Java・Tomcat・DBのバージョンを一覧化します。画面数だけでは工数が読めないため、Action数、テーブル数、外部連携数、帳票数、バッチ数、権限パターン、テストデータの有無も数えます。

この段階のチェックリストは、(1)業務フローと画面遷移が一致しているか、(2)ソースコードと本番環境のバージョンが一致しているか、(3)担当者の頭の中だけにある例外処理がないか、(4)外部APIやEDIの接続先・認証方式を把握しているか、(5)障害時の復旧手順を再現できるか、です。成果物として構成図、画面・Action一覧、連携一覧、課題・リスク一覧、現行テストの棚卸しを残します。

現行調査の結果をもとに、短期保守、Struts更新、Spring系移行、SaaS・パッケージ置換、スクラッチの案を比較します。評価軸は、セキュリティ、業務継続性、将来の採用・保守性、既存データの再利用、画面変更の大きさ、移行期間、総保有コストです。例えばインターネット公開で脆弱性の影響を受ける場合は、保守継続の安さよりも、パッチ適用または移行を早く始められる案を優先します。

代表画面を使った小規模なPoCも有効です。入力チェック、認証、ファイルアップロード、トランザクション、帳票、外部APIのうち、難易度の高い処理を2〜5種類選び、移行後の実装方法、変換率、テスト工数、性能を確認します。PoCで「変換できる」と分かっても、業務上の期待結果が一致するとは限らないため、現行画面と新画面の比較条件まで合意してから本開発へ進みます。

設計では、業務要件を機能要件・非機能要件に分けます。機能要件には画面、帳票、バッチ、権限、データ更新、APIを記載し、非機能要件には応答時間、同時利用者数、可用性、ログ保存、バックアップ、監視、障害復旧、脆弱性対応を記載します。StrutsからSpring系へ移行する場合は、JSPの見た目だけでなく、Actionの状態管理、Interceptor、入力値変換、エラー処理、二重送信防止、セッションの扱いを設計し直します。

開発は、基盤部品、代表画面、共通エラー処理、認証、データアクセスから作り、パイロット開発で標準化します。自動変換ツールを使う場合も、変換対象と手作業対象を明確にし、生成コードのレビュー責任を決めます。シーイーシーが公開するStruts 1からSpring MVCへの事例では、変換、現行と移行後の比較検証、運用テスト、リリースまで約6か月とされています（出典: 株式会社シーイーシー公開事例、確認時点2026年）。ただし期間は画面数や連携数で変わるため、自社へそのまま当てはめず、PoCの結果から再見積もりします。

テストは、単体、結合、システム、受入、性能、セキュリティ、障害復旧を分けて計画します。移行案件では、現行システムと新システムへ同じ入力を与え、画面表示、登録データ、計算結果、帳票、外部連携の差分を比較する「現新比較」が特に重要です。TISのFintan公開事例でも、現行ソースの全量調査、StrutsのTOKENによる二重サブミット防止など、非互換点を先に検討してからテスト方針と製造へ進んでいます（出典: TIS株式会社 Fintan「StrutsからSpring MVCへのマイグレーション事例」）。

受入条件には、重要業務のシナリオ、合格率、重大障害の残存可否、性能基準、データ件数、権限パターン、ブラウザ、夜間バッチ、連携先の確認方法を記載します。テストケースは正常系だけでなく、入力漏れ、桁あふれ、同時更新、二重送信、タイムアウト、外部サービス停止、DB障害、権限外アクセスまで含めます。受入担当者が業務部門の場合は、技術用語ではなく「受注を登録して出荷指示が作成される」といった業務シナリオで合意します。

稼働前には、データ移行リハーサル、切り替え手順、担当者、開始・終了時刻、連絡網、監視項目、バックアップ、ロールバック条件を決めます。停止できるのが休日の数時間だけなら、一括切り替えではなく、読み取り系や管理系から段階的に移行し、旧システムと新システムのデータを突合する方式を検討します。個人情報を扱う場合は、移行データの一時ファイル、作業者の権限、ログ、廃棄方法も計画に含めます。

切り替え判断は「予定時刻になったから」ではなく、データ件数と金額、在庫、権限、主要画面、連携、バッチの確認が完了したかで決めます。万一、重大な差分や性能劣化が発生した場合に、どの条件で旧環境へ戻すのかを事前に決めておきます。ロールバックできない移行では、経営層を含めた意思決定者とリスク許容度を合意してから本番作業へ進みます。

稼働後は、問い合わせ対応だけで終わらせず、運用設計を定着させます。日次のバックアップ確認、ログ監視、月次の障害・性能レビュー、四半期の脆弱性情報確認、Java・Tomcat・DB・ライブラリの更新計画を運用カレンダーに入れます。IPAはApache Struts 2の脆弱性について、基本的に修正パッチを適用してアップデートし、事前テストで動作を確認する必要があると案内しています（出典: IPA「Apache Struts2の脆弱性対策情報一覧」、最終更新2026年1月13日）。

利用部門向けには、操作マニュアルだけでなく、業務別の手順、エラー時の連絡先、よくある質問、教育担当者を用意します。開発会社との契約には、脆弱性パッチ、障害対応時間、休日対応、性能監視、軽微な改修、ソースコード・設計書の引き渡し範囲を明記します。定着の指標として、問い合わせ件数、処理時間、手作業の削減、障害の再発率、パッチ適用までの日数を毎月確認すると、改善の優先順位を決めやすくなります。

Strutsのシステム開発にかかる費用相場と内訳

Struts単体の定価はなく、費用は画面、Action、DB、連携、帳票、バッチ、テスト資産、停止制約、移行方式で大きく変わります。以下は2026年の業務Webシステム相場、Java系エンジニアの人月単価、公開されている移行期間を組み合わせた推定レンジです。公開されたStruts移行事例でも費用は非公開であるため、特定金額の断定ではなく、予算を置くための目安として利用します。

現行調査、脆弱性診断、移行PoCは100万〜300万円、期間は1〜2か月程度が一つの目安です。数画面・単一DB・連携少数の保守や機能追加は100万〜300万円、1〜3か月程度、中規模の複数業務をまたぐ機能追加や再構築は300万〜800万円、3〜6か月程度を目安にします。これらは2026年の小規模・中規模業務Web開発相場を参照した推定で、診断だけか改修まで含むかによって変わります（出典: 2026年公開の業務Webシステム費用相場情報、リサーチノート整理）。

Struts 1からSpring MVCやSpring Bootへ移行する場合は、1,000万〜3,000万円、4〜8か月程度を置くケースがあります。これは2〜4名が6か月稼働し、Java系人月単価を月80万〜120万円程度として、要件整理、プロジェクト管理、テスト、予備工数を加えた推定です。50画面以上、複雑な権限、EDI、複数DB、並行稼働、データ移行を含む大規模基幹刷新では、3,000万〜1億円超、6〜18か月になることもあります。画面数だけでなく、例外処理と連携の数を必ず加味します。

見積書では、要件整理・現行調査、基本設計・詳細設計、製造、データ移行、単体・結合・総合・受入支援、インフラ構築、リリース、プロジェクト管理を分けて確認します。別途になりやすいのは、脆弱性診断、性能試験、帳票の再現、外部接続先との調整、休日切り替え、旧環境の並行稼働、操作教育、ドキュメント整備です。安い見積もりでも、これらが含まれていなければ後から追加費用になります。

運用保守は、初期開発費の年15〜25%程度を仮置きすることがありますが、これは契約範囲から組み立てる予算上の目安です。脆弱性パッチだけか、24時間監視や障害一次対応まで含むかで金額は変わります。初期費用だけでなく、移行後3〜5年の保守、クラウド・ライセンス、診断、教育、将来のJavaやミドルウェア更新を足して、総保有コストで比較します。

Strutsのシステム開発で見積もりを取るポイント

見積もりの精度は、発注前にどれだけ不確実性を見える化できるかで決まります。「Strutsの改修一式」だけでは会社ごとの前提が異なり、価格比較ができません。現行バージョン、画面数、Action数、DB、連携先、帳票、バッチ、データ件数、停止可能時間、希望する方式を同じ資料で渡し、調査・PoCと本開発を分けて提案してもらいます。

RFPには、目的と背景、対象業務、利用者数、ピーク時の処理量、現行と希望する将来構成、環境制約、セキュリティ要件、データ移行、テスト、稼働条件、保守条件を記載します。資料として、画面一覧、業務フロー、ER図、連携仕様、帳票サンプル、障害履歴、テストケース、ソースコードの提供範囲をそろえます。機密情報を含む場合は、秘密保持契約を締結したうえで、必要最小限の情報を共有します。

要件が確定していない場合は、いきなり固定価格の本開発を求めず、現行調査を準委任や調査フェーズとして発注し、その成果物をもとに本見積もりへ進む方法が安全です。成果物の例は、構成図、依存ライブラリ一覧、脆弱性影響、移行方式比較、PoC結果、課題一覧、概算工数、次フェーズの見積条件です。調査の終了条件を決めておけば、調査だけで終わるリスクも抑えられます。

候補会社には、Struts 1・2のどの資産を扱った経験があるか、Action・JSP・設定ファイル・独自フレームワークを調査できるか、Spring MVCやSpring Bootへの移行事例があるかを質問します。加えて、担当予定者の経験年数、脆弱性対応の方法、現新比較テストの実施方法、データ移行の責任分界、稼働後の保守体制、ソースコードと設計書の引き渡し範囲を確認します。会社名やJava対応という一般的な説明だけでなく、匿名化された実績の工程と成果物を聞くことが大切です。

比較では、金額だけでなく、調査の深さ、見積もりの前提、除外項目、追加変更の単価、納期の根拠、テスト範囲、障害時の責任、契約終了時の引き継ぎを同じ表に並べます。例えば「テスト一式」と書かれていても、単体テストだけか、現新比較、性能、脆弱性、受入支援まで含むかで意味が違います。最安値の提案より、前提が明確で、リスクと対策を説明できる提案を選ぶ方が、総額を管理しやすくなります。

よくあるリスクは、現行仕様が文書化されていない、業務ルールがソースやSQLに埋もれている、担当者しか例外処理を知らない、テストデータがない、外部接続先を変更できない、切り替え時間が短い、旧環境へ戻せない、というものです。対策は、要件整理で業務部門を参加させ、代表画面のPoCを行い、現新比較の正解データを作り、連携先とリハーサルを実施することです。

セキュリティ面では、Struts本体だけでなく、Java、Webコンテナ、ライブラリ、OS、DB、認証、ファイルアップロード、ログをまとめて確認します。Apache公式は、EOL版にはセキュリティパッチやバグ修正を提供しないと説明しています（出典: Apache Struts公式「End-of-Life Versions」、2026年確認）。「外部公開していないから安全」と決めつけず、社内ネットワークからの侵入、委託先接続、バックアップ、管理画面の権限も含めてリスクを評価します。

Strutsのシステム開発でよくある質問

Strutsのシステム開発では、技術の古さだけでなく、今の業務を安全に維持できるか、どの範囲を移行するか、何を根拠に費用を決めるかが質問されます。ここでは、特に判断に迷いやすい3つの質問へ直接回答します。

Struts 1やEOLとなったStruts 2.3・2.5を新規開発で採用することは避けるべきです。Apache公式のダウンロードページでは、2026年確認時点でStruts 7.2.1や6.10.0などの現行系が案内されていますが、採用時はJavaやWebコンテナとの互換性、サポート方針、脆弱性情報を確認します。既存資産の短期保守と、新しい業務システムの技術選定は分けて判断します。

全てを一度に作り直す必要はありません。現行調査で業務ルール、画面、データ、連携を分解し、変換ツールや共通部品で再利用できる部分と、手作業で設計し直す部分を分けます。読み取り系や利用頻度の低い機能から段階移行し、現新比較と利用部門の受入を繰り返す方式なら、業務停止と一括切り替えのリスクを下げられます。

画面数だけでなく、Action数、DBテーブル、外部連携、帳票、バッチ、権限、データ移行、テスト、停止制約を提示し、現行調査とPoCを先に行うと精度が上がります。見積書では、含む項目、含まない項目、前提、追加変更の扱い、検収条件、保守範囲を確認します。費用は小規模100万〜300万円、中規模300万〜800万円、Struts移行1,000万〜3,000万円などの推定レンジを出発点にし、調査結果で更新します。

まとめ：Strutsのシステム開発は6フェーズで判断します

Strutsのシステム開発は、要件整理、選定、設計開発、テスト、稼働、定着の順に、各フェーズの終了条件を確認しながら進めます。既存Strutsでは、バージョンと脆弱性だけでなく、画面、Action、JSP、DB、連携、帳票、バッチ、業務ルール、テスト資産を棚卸しし、保守・更新・Spring移行・パッケージ置換を比較します。

着手前は、現行バージョンとEOL状況を確認し、業務停止可能時間、画面・Action・DB・連携・帳票・バッチの数を把握します。代表画面でPoCを行い、移行方式、テスト方法、データ移行、ロールバック、セキュリティ対応、保守体制を提案書に明記してもらいます。費用は推定レンジから始め、調査・設計・開発・テスト・稼働後保守を分けて比較します。

いきなり全面刷新を決めるのではなく、まず構成資料と課題を集め、開発会社へ現行調査とPoCの範囲を相談します。技術名だけで判断せず、業務価値、セキュリティ、移行難易度、3〜5年の総保有コストを並べることで、自社に合う進め方を選びやすくなります。現場・情報システム部門・経営層が同じ終了条件を持てることが、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を創業。