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

Seasar2の移行・刷新は、要件整理から運用定着まで6フェーズで進めます。現行資産の棚卸しから始め、方式選定、設計・開発、旧新比較テストを経て、稼働と定着へ進みます。

現行資産の棚卸し、段階的な方式選定、旧新比較テストの順に進めると、業務を止めずに安全性と保守性を高めやすくなります。

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

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

Web機能とデータ処理、運用機能が結び付く構成です。

Seasar2の案件は、新規にSeasar2を採用する案件と、既存のSeasar2を持つ企業の刷新案件に分けて考えます。

構成としては、DIとAOPを中心に、SAStrutsやJSPなどのWeb層、S2DaoやS2JDBCなどのデータアクセス層を使います。さらに、バッチや外部連携も使われるため、Webアプリ一つに複数の技術と運用手順が結び付く場合があります。

Seasar2の技術概要

Seasar2は、Javaの業務Webシステム向けに国内で広く利用された軽量フレームワークとDIコンテナです。

依存関係の組み立て：S2Containerが、サービスやDAOを必要な部品として組み合わせます。
共通処理の分離：AOPにより、トランザクション、ログ、認証を業務ロジックから切り離せます。
DBアクセス：S2Daoが、データベース処理の定型作業を減らします。
複数要素の連携：Actionを起点に、dicon設定やSQL、バッチが業務機能の裏側で結び付きます。

The Seasar Project公式サイトは、多くのプロダクトが2016年9月26日にEOLとなったと案内しています。また、プロジェクトによるメンテナンスとサポートも終了しています（出典：The Seasar Project公式「EOLについて」）。

ドキュメントやソースコードが公開されていても、現在のJava、OS、APサーバー、データベースとの互換性は保証されません。さらに、新たな脆弱性への公式対応も保証されません。そのため、2026年時点で新規開発に採用する場合は、短期の検証用途を除き、Spring MVCやSpring Bootなどと比較して判断します。

新規開発と既存システムの移行の違い

新規開発と既存システムの移行では、引き継ぐ業務知識と選べる方式が異なります。

新規開発：業務要件に合う技術を選びやすい一方、既存移行では稼働中の処理を守りながら、業務知識を引き継ぎます。
移行時の確認：締め処理、例外時の手作業、夜間バッチ、帳票、権限、外部API、担当者だけが知る復旧手順を見ます。
移行方式：一時延命、機能単位のSpring移行、API境界での段階切り替えから選べます。
業務ごとの方式：標準業務はSaaSやパッケージへ寄せ、独自業務だけを再開発する形もあります。

移行では、画面を新しくしても、計算結果や承認経路が変われば業務上は失敗です。そのため、方式は停止可能時間、業務の独自性、データ移行の難しさ、残したい運用知識から判断します。

ポイント

Seasar2の案件は、新規採用か既存システムの刷新かで、見るべき条件が変わります。刷新では、停止可能時間や業務の独自性から方式を絞り込みます。

Seasar2のシステム開発の進め方・流れ・手順

次の工程へ進む前に成果物と合否条件を確認します。

移行・刷新は、要件整理、方式選定、設計開発、テスト、稼働、定着の6フェーズで進めます。

各フェーズの成果物と合否条件は、事前に決めておき、次の工程へ進む前に確認します。先にコード変換を始めると、不要な機能や曖昧な業務ルールまで新環境へ持ち込むことがあります。そのため、まず現行資産を洗い出し、業務上の重要度を整理します。

フェーズ1：要件整理と現行資産の棚卸し

最初に、何を残し、変え、廃止するかを決めます。判断の材料として、構成と運用を項目ごとに一覧にします。

技術構成：Seasar2本体のバージョン、SAStruts、S2Struts、S2Dao、S2JDBC、dicon、JSP
実行環境：JavaとJDK、APサーバー、OS、RDBMS
業務と運用：ジョブ、帳票、外部連携、認証・権限、ログ、バックアップ
規模と負荷：画面数、ソース行数、バッチ本数、連携先、月次・年次処理、ピーク時利用者数

棚卸しでは、実際に使われる機能を業務部門に確認します。担当者が説明できるか、業務ルールが文書化されているかも、あわせて調べます。

入力から出力までの業務ルールや締め・取消処理を再現できるかを確認します。加えて、障害時の切り戻し手順や個人情報・決済情報の有無、停止可能な時間帯も見ておきます。

構成図、機能・データ項目・外部連携・リスクを、それぞれ一覧にして残します。そのうえで、移行対象と廃止対象の判定表を作ります。判定表には、画面数やソース行数だけでなく、業務の再現に必要な情報をそろえます。

フェーズ2：移行先と開発方式の選定

方式選定では、フレームワーク名よりも、業務を安全に引き継げるかを優先します。業務特性に応じて方式を分ける選択肢もあります。

標準業務：SaaSやパッケージの採用を検討
独自性の高い業務：Spring MVCやSpring Bootでの再構築
変更範囲を抑えたい機能：段階移行を検討します

全面再構築、部分移行、延命を比べるときは、費用、期間、停止時間を並べて見ます。保守性やデータ移行リスクも、同じ比較に含めます。

S2Daoを使う場合は、MyBatisなどへ移すか、既存インターフェースを再利用するかを確認します。たとえば、公開事例では、S2DaoからSpring 5への移行時に既存インターフェースを再利用しました。

同事例では、MyBatisへ移植し、データアクセス層を画面から分離して、JUnitで確認しています（出典：株式会社スタイルズ「ケース4」）。また、移行単位とテスト単位を合わせると、不具合を切り分けやすくなります。

フェーズ3：設計・開発とデータ移行

設計では、機能要件に加えて非機能要件を文書にまとめます。性能と稼働、復旧と記録、セキュリティについて、値や方針を決めておきます。

性能と稼働：応答時間、同時利用者数、稼働時間
復旧と記録：障害復旧目標、バックアップ世代数、監査ログの保存期間
セキュリティ：権限分離、暗号化、個人情報のマスキング

古いJDKやAPサーバーを残すか、JavaのLTS版やクラウドへ同時に更新するかも、基本設計で決めます。

開発では、画面、サービス、DAO、バッチ、帳票、外部連携を一度に変えず、機能単位で移行します。変換できないdicon設定、独自インターセプター、SQL、JSPの画面遷移、例外処理は、とくに注意して確認します。なお、変換ツールを使う場合でも、人手の確認は必要です。

データ移行では、項目対応表と変換ルールを決めます。さらに、欠損時の扱いや重複排除、移行リハーサル、件数と金額の照合を決めておきます。最後に、移行後に旧データを参照できる期間も設計します。

フェーズ4：旧新比較を含むテスト

移行後も業務の結果を守るには、テストの方式だけでなく、比較内容や判定条件まで決めておく必要があります。

テストの種類：単体、結合、総合、性能、権限、脆弱性、業務受入、障害復旧の各検査を行います。
旧新比較：同じ入力で、処理結果、明細件数、金額、状態、帳票、連携ファイルを照合します。
データ条件：空欄、上限値、過去日、取消、重複、権限外操作、連携停止、タイムアウトを含めます。
記録と合意：実施者、日時、条件、期待・実績値、差異、修正番号を残し、両者で合格基準を決めます。

合格基準の例は、重大障害ゼロ、重要業務の現新差異ゼロ、中軽微障害の責任者承認済みです。締め処理や例外処理まで一致しているかを確認し、合意した基準をリリース判定に使います。

フェーズ5：稼働判定と切り替え

安全に本番へ切り替えるため、判定会議では、テスト結果と運用準備、切り替え方式を確認します。

参加者とテスト：業務、情報システム、開発会社、運用担当者が集まり、完了率と重要機能の合格状況を見ます。
稼働準備：移行リハーサル、性能試験、脆弱性対応、窓口、監視、復元、利用者手順書の準備状況です。
切り替え方式：一括、部門ごとの段階リリース、旧新並行稼働のいずれかを選びます。
停止時間が短い場合：基幹業務では、読み取り機能から登録・更新へ段階的に進める方法もあります。

延期や中止の条件は、事前に決めておきます。また、切り戻すデータ時点、二重登録の防止、経営判断者も定めておきます。さらに、初回の締め処理までを安定稼働期間とし、開発会社の待機体制を契約に含めます。

フェーズ6：運用定着と保守体制の整備

稼働後も社内で対応を続けられるよう、利用者への引き継ぎから保守条件まで整えます。

利用者と管理者：操作説明と設定手順を整え、旧担当者から処理背景や例外運用を引き継ぎます。
社内運用：障害時の一次切り分け、問い合わせ分類、変更申請、リリース手順を用意します。
保守契約：問い合わせ受付時間、重大障害の初動時間、復旧目標、脆弱性情報の確認方法、JDK・ミドルウェアの更新方針、バックアップ監視を明記します。
契約範囲：追加改修の単価と成果物の引き渡し範囲を定めます。

IPAの2026年「情報セキュリティ10大脅威」では、組織向け4位に脆弱性を悪用した攻撃が挙がっています。また、2位はサプライチェーンや委託先を狙った攻撃です（出典：IPA「情報セキュリティ10大脅威 2026」、2026年）。

そのため、EOL技術では脆弱性対応と委託先管理を正式な運用項目に加えます。担当者個人の善意に頼らず、体制として進められることが求められます。

ポイント

次の工程へ進むかは、そのフェーズの合否条件を満たしているかで決めます。迷ったときは、業務の結果が旧システムと同じかどうかを基準にします。

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

診断・設計から稼働準備までが費用項目に含まれます。

画面数やソース行数から費用を断定するのは難しく、Seasar2専用の公的な価格表もありません。費用を左右するのは、調査量、S2Daoや独自設定の複雑さ、外部連携です。

データ移行、旧新比較テスト、停止可能時間、Java・DB・インフラの同時更新でも、費用は変わります。金額は、2026年時点の一般相場と移行事例による目安で、確定した見積もりではありません。

移行診断から大規模刷新までの費用目安

移行診断・資産棚卸しは、100万円から500万円程度が目安で、期間は2週間から6週間程度です。診断では、ソース、設定、DB、実行環境を調べ、画面、帳票、バッチ、外部連携も対象にして、残す機能と廃止機能を分けます。

小規模な業務Webシステムの部分移行：300万円から1,500万円程度
中規模の移行・刷新：1,200万円から4,000万円程度
大規模・基幹システム：3,000万円から1億円超になる可能性

上記は作業範囲による推定レンジです。税、クラウド利用料、ライセンス、第三者診断を含むかどうかで、金額が変わります。

SIAの2026年7月更新記事は、人月単価を小規模100万〜180万円、中規模150万〜220万円、大規模180万〜250万円としています。また、同記事は、保守費を新規開発費の年15〜25％としています。さらに、レガシー技術の単価は10〜15％高くなりやすいとも説明しています（出典：SIA株式会社「受託開発の費用相場」、2026年7月更新）。

Seasar2移行では、新規CRUD開発より現行資産の解析とテストを厚めに見込みます。

費用の項目構成

Seasar2移行の見積金額は、各工程の作業に加えて、環境更新や並行稼働の範囲によっても変わります。

診断・設計：移行診断、要件整理、基本・詳細設計
開発・移行：コード変換・実装、データ移行
稼働準備：テスト、リリース、教育、プロジェクト管理
別費用の場合がある項目：JDK・APサーバー・DB・OS更新、クラウド、監視、バックアップ、脆弱性診断、ライセンス、旧環境の並行稼働
公開事例：Seasar 2.4からSpring 5へ移行したWebアプリ3本、約300メソッド、約16万ステップの案件

「移行一式」と書かれた見積もりでは、対象外の作業を判断しにくいです。公開事例は約5か月、約20人月です（出典：株式会社スタイルズ「ケース4」、公開情報）。

この規模を人月単価100万〜250万円で計算すると、2,000万〜5,000万円程度になります。この試算は公開規模をもとにした参考値で、同社の見積額ではありません。

自社案件では、画面数だけでなく、業務ルール、連携、テスト、切り替え条件をそろえて見積もります。

ポイント

費用は、調査量、外部連携、データ移行、テストの範囲で変わります。見積もりは「移行一式」のような表記だけでなく、対象外の作業まで確かめて比べます。

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

相見積もりでは、合計金額だけでなく前提と工数の根拠を比べます。調査を省くと一見安く見えても、後半で仕様漏れやテスト不足が表面化することがあります。

3社程度に同じ資料を渡し、同じ質問をします。そのうえで、工程別工数、成果物、除外事項、追加費用の条件を比べます。

発注前に準備する資料

RFPや見積依頼書には、Seasar2の現行構成と規模、実行環境、運用条件を記載します。分からない項目は空欄にせず、「調査で確定する項目」と明示します。

構成と規模：JDK・ミドルウェアのバージョン、画面・Action数、ソース規模、dicon・JSPの量、DAO・SQL
業務と連携：バッチ、帳票、外部API、認証方式、利用者数、ピーク時間、データ件数
制約：停止可能時間、法令・監査要件

業務部門からは、必須機能、廃止候補、手作業、月次・年次の締め、障害時の代替手段を集めます。なかでも、特定の担当者だけが使う機能や年に一度だけ必要な帳票は、アクセスログとヒアリングの両方で確かめます。ソースに加え、テストデータ、過去障害票、運用手順、監査記録も提出すると、診断の精度が上がります。

開発会社の比較観点

候補会社には、Seasar2の構成要素ごとの実績を確認します。「Seasar2対応」と書かれていても、関連技術すべての経験があるとは限りません。

案件経験：類似案件の画面数、連携数、工期
移行と検証：Spring・MyBatisの版、手動修正比率、現新比較方法、移行リハーサル回数
体制：担当者交代時の引き継ぎ方法

このほか、S2Dao、S2JDBC、SAStrutsの扱いを確かめます。独自diconやバッチ、帳票、外部連携も、同じ範囲で確認します。

納品の範囲も会社ごとに比べます。設計書、ソース、設定に加えて、次の記録や資料も納品対象に含めます。

テストコード・結果
IaC、OSS一覧
脆弱性記録
運用手順
教育資料

再委託、知的財産権、終了時の引き継ぎ、保守終了後のデータ返却、障害時にどこまでを誰が受け持つかも契約前に確認します。安価な会社を選ぶ場合は、調査やテストの省略が安さの理由になっていないか見極めます。

見積もりの抜け漏れを防ぐチェック項目

見積書は、対象範囲、費用要因、追加条件、契約上の責任の観点で確認し、項目ごとに抜けがないかを見ます。

工程と対象：要件整理、設計、実装、移行、テスト、教育、稼働支援、保守が含まれているかを見ます。
対象機能：画面、バッチ、帳票、外部連携、監査ログ、権限、性能、バックアップ、障害復旧が対象に入っているかを確かめます。
費用要因：SIA株式会社の2026年相場情報は、人月単価・工数に加え、外部連携、性能、可用性、セキュリティ、短納期を挙げています。
追加条件と責任：「一式」「別途」「想定外」という表記、診断後の追加費用、仕様変更、データ不整合時の取り扱い、クラウド上限、脆弱性対応期限を見ます。

請負か準委任かで、完成責任と進捗リスクの分担が変わります。そのうえで、納品物と受入基準を契約書や仕様書に結び付け、責任範囲を明確にします。

ポイント

見積もりは、金額の大小よりも、前提と工数の根拠がそろっているかで判断します。同じ資料を複数社に渡し、比べる条件をそろえます。

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

既存のSeasar2システムを持つ企業から寄せられやすい質問を、判断時に確認したい条件とあわせて紹介します。

Seasar2は2026年に新規開発へ使えますか？

技術的に動かせる可能性はありますが、通常の業務システムでは慎重に判断します。

終了時期：Seasarプロジェクト公式は、多くのプロダクトが2016年9月26日にEOLと案内しています。
サポートと互換性：公式の保守対応が続くか、現行JDKで動くかを確かめます。
運用面：脆弱性対応、人材確保、将来の保守費も比較します。
技術選定：既存システムとの互換性など明確な理由がなければ、Spring Bootなどの現行技術を選ぶと、長期運用の選択肢を残せます。

Springへ移行するとデータや業務機能は失われませんか？

適切な方式とテストで消失リスクを抑えられますが、自動的に保証されるわけではありません。そのため、重要業務の合格基準を決めておきます。そのうえで、項目対応表、変換ルール、旧新比較を実施し、移行後の結果が元の業務と合うかを確かめます。

移行リハーサル
件数・金額照合
利用者受入

S2DaoのSQL、dicon設定、バッチの実行順、例外処理、帳票の端数計算は、画面単位で確認すると漏れやすい項目です。

Seasar2の移行を急がずに保守し続けてもよいですか？

延命を続ける場合は、安全性と運用体制の両面から状況を確認します。

延命の期限：短期の延命は選択肢になりますが、終わりの時期と条件を決めずに先送りするのはおすすめできません。
継続リスク：脆弱性、担当者不在、JDK・OSのサポート期限、障害時の復旧可否、監査要件を診断します。
暫定対策：最低限のパッチ、アクセス制御、ログ監視、バックアップ、保守要員を確保します。

診断から部分移行へ進む時期と延命終了の基準を、経営層と共有します。

ポイント

EOL技術の扱いは、公式の保守対応と現行JDKとの互換性、保守費を含めて判断します。延命を選ぶ場合も、終わりの時期と条件を先に定め、脆弱性対応と保守要員の手当てをしておきます。

まとめ：Seasar2のシステム開発の段階的な進め方

Seasar2の移行では、技術の置き換え自体を目的にせず、業務を止めず安全性と保守性を高めることを目指します。まず、現行資産と業務ルールを棚卸しし、延命、部分移行、全面刷新、SaaS・パッケージ化を比べます。その後、設計開発、旧新比較テスト、切り戻し計画、利用者教育、保守契約まで一続きに進めます。

最初に押さえる3つのポイント

Seasar2は公式EOL済みです。現行環境が動くことと、安全に使い続けられることを分けて判断します。

業務を再現するには、コードだけでなく、S2Dao、dicon、JSP、バッチ、帳票、外部連携までを対象にします。

費用は診断、移行、テスト、並行稼働、保守を含む総保有コストで比べます。工程別人月と除外事項が分かる見積もりを選びます。

次に行うべきアクション

移行診断から複数社の比較までは、順に準備を進めます。

現行構成図、画面・バッチ、外部連携、DB、担当者、障害履歴を集め、2週間から6週間程度の移行診断を依頼します。
診断後、同じRFPで複数社に見積もりを依頼し、方式、テスト計画、成果物、保守、脆弱性対応を費用と合わせて比べます。
業務部門と情報システム部門で判断基準を共有し、段階的な刷新につなげます。

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

▼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を創業。