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

Seasar2のシステムを発注・外注する場合は、単純な保守会社探しではなく、EOL済みの技術資産と業務知識を棚卸しし、延命・部分移行・Springなどへの刷新・SaaSやパッケージへの置き換えを比較してから委託先を決めることが重要です。

既存のSeasar2システムが動いていても、「今後も保守できるのか」「移行費用はいくらか」「どのような会社に依頼すれば安全か」は別途検討が必要です。この記事では、発注形態の選び方、RFPや要件整理の方法、契約形態、2026年時点の費用目安、委託先と見積書を比較するポイントまで、発注者の立場で順番に解説します。

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

Seasar2のシステムを発注・外注する前に知るべき全体像

Seasar2のシステム発注を検討する担当者

Seasar2は、Javaで業務Webシステムを構築するために国内で広く利用されたフレームワークです。S2ContainerによるDIやAOP、S2Dao・S2JDBCなどのデータアクセス、SAStrutsやJSPによる画面、バッチ、外部連携を組み合わせて動作しているケースが多く、発注時には「Seasar2」という一語だけでなく、周辺資産まで見なければ正確な見積もりになりません。

Seasar2は新規開発より移行・保守を前提に考えます

最初に押さえるべき点は、Seasarプロジェクトの多くのプロダクトが2016年9月26日にEOLとなり、公式のメンテナンスとサポートが終了していることです。公式サイトではドキュメント、ソースコード、Mavenリポジトリが継続公開されていますが、公開されていることは、現在のJDK・OS・APサーバーや新たな脆弱性への公式サポートを意味しません(出典: The Seasar Project公式、EOL情報)。そのため、2026年時点で新しい業務システムをSeasar2で作る前提の発注は、将来の保守、採用、セキュリティ、クラウド対応まで含めて慎重に見直す必要があります。

既存システムを持つ企業は、いきなり全再構築を決めるのではなく、業務停止の許容時間、担当者の退職リスク、データの重要度、外部連携の数、JDKやDBの更新期限を整理します。その結果、短期の延命で時間を確保するのか、画面や機能単位で段階移行するのか、業務パッケージへ置換するのかを判断しやすくなります。

発注対象はフレームワークだけでなく業務資産全体です

発注前には、Seasar2本体のバージョンだけでなく、SAStruts・S2Struts・Teeda・JSP、dicon設定、インターセプター、S2Dao・S2JDBC・S2Hibernate、バッチ、帳票、ジョブ管理、認証・権限、外部API、メール、ファイル連携を一覧化します。ソースコードの行数だけでは、締め処理や例外処理の複雑さを評価できません。

特に注意したいのは、業務仕様がソースコードや運用担当者の経験に分散しているケースです。画面が表示されても、月次締め、金額計算、取消、権限変更、再実行、夜間バッチだけが旧システムと異なることがあります。したがって、成果物にはコードだけでなく、業務フロー、データ定義、テストケース、運用手順、障害時の切り戻し方法まで含めることが大切です。

Seasar2のシステム発注ではどの発注形態を選ぶべきですか?

発注形態を比較する業務システム担当者

結論として、既存Seasar2の資産が大きい場合は、最初から一社に全面委託するより、診断・資産棚卸しを小さな契約で切り出し、その結果に応じて移行本体を発注する形が安全です。既存仕様が十分に分かっている場合は一括請負も選べますが、ブラックボックスが残る場合は、調査工程と実装工程を分けたほうが追加費用や責任範囲を管理しやすくなります。

診断・資産棚卸しだけを先に外注する方法です

現行構成が分からない企業には、移行診断を先行発注する方法が向いています。対象リポジトリ、dicon、DBスキーマ、JDK、APサーバー、OS、画面、帳票、バッチ、外部連携を調べ、稼働中・未使用・重複・廃止候補に分けてもらいます。さらに、S2Daoのマッピング、独自拡張、トランザクション、認証・認可、テストの有無を確認すると、本体移行の難所が見えてきます。

一般的な目安では、診断・資産棚卸しは2〜6週間程度で、費用は100万〜500万円程度のレンジが想定されます。ただし、これはSeasar2専用の公定価格ではなく、公開されている業務システム相場と調査範囲から置いた推定です。成果物として、対象一覧、依存関係、移行方式案、リスク一覧、概算人月、優先順位、次工程のRFP案まで受け取れるかを確認します。

部分移行・段階移行で業務停止リスクを抑える方法です

全機能を一度に移すと、テスト範囲と切り戻しの難度が大きくなります。そこで、利用頻度が高く、独立性のある業務からSpring MVCやSpring Bootなどへ移し、APIやデータ連携を境界にして旧システムと新システムを一時的に共存させる方法を検討します。たとえば、参照系画面を先に移し、次に登録・承認・締め処理を移すと、利用者の確認を受けながら進められます。

段階移行では、旧新のデータ整合性、二重更新の防止、障害時の切り戻し、旧環境の停止条件を先に決めます。委託先には「何をもって移行完了とするか」を機能単位で説明してもらい、画面が開くことだけでなく、業務結果が一致することを受入条件にします。

パッケージ・SaaS・スクラッチを業務単位で比較します

Seasar2の機能をそのまま作り直すことだけが正解とは限りません。標準化しやすい勤怠、経費、ワークフロー、顧客管理などはSaaSやパッケージを比較し、独自性が高く競争力に直結する業務だけをスクラッチ開発する組み合わせも現実的です。業務を変えられない部分を無理にパッケージへ合わせると、追加カスタマイズで費用が膨らみ、逆に独自機能をすべて作り直すと移行リスクが高まります。

比較時は初期費用だけでなく、月額利用料、ユーザー数課金、データ移行、API連携、帳票、権限、監査ログ、バックアップ、サービス終了時のデータ返却まで見ます。候補ごとに「業務適合度」「移行できない機能」「運用負荷」「5年程度の総保有コスト」を並べると、安価に見える選択肢の見落としを防げます。

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

RFPと要件を整理する発注プロセス

発注は「会社を探して見積もりをもらう」だけではなく、発注者が業務の目的と制約を整理し、候補会社が同じ条件で提案できる状態を作るプロセスです。診断、RFP作成、提案比較、契約、要件定義、開発、テスト、移行後保守の順に区切ると、途中で前提が変わったときも判断しやすくなります。

最初に目的・対象範囲・業務上の成功条件を整理します

最初に「Seasar2を新しくする」ではなく、「何を改善すれば事業が継続できるか」を言語化します。たとえば、JDKやAPサーバーのサポート切れを解消する、障害復旧時間を短くする、担当者が変わっても保守できるようにする、月次締め処理の時間を短くする、といった成果条件です。技術の変更だけを目的にすると、利用者が困っている業務課題が後回しになります。

対象範囲は、画面数、帳票数、バッチ数、DB数、外部システム、利用者数、権限区分、データ件数、停止可能時間、法令・監査要件で整理します。現行資料が足りない場合は「不明」を無理に埋めず、不明点を調査項目としてRFPに載せます。不明点が残ったまま固定価格を求めると、受注後に追加見積もりが発生しやすくなります。

RFPには現行構成と移行後の成果物を具体的に書きます

RFPには、背景、目的、対象業務、現行構成、想定する移行先、対象外の範囲、希望時期、予算の考え方、体制、提案期限、評価基準を記載します。技術情報では、Seasar2のバージョン、S2DaoやS2JDBCの利用状況、dicon、Java・JDK、APサーバー、DB、OS、ミドルウェア、ソース規模、テスト資産、外部連携を可能な範囲で提示します。

さらに、成果物を明記します。設計書、ソースコード、設定ファイル、DB定義、テストコード、テスト結果、移行手順、切り戻し手順、運用設計、監視設定、脆弱性対応方針、第三者OSS一覧、引き継ぎ資料まで含めます。自動変換ツールを利用する場合は、ツールの適用範囲、手修正の割合、変換ログ、利用権、将来の再実行方法も確認します。

提案依頼では技術案・体制・リスク対応を同じ粒度で求めます

候補会社には、移行方式、対象範囲、工程、体制、役割分担、前提条件、除外事項、リスク、テスト方針、データ移行方針、保守体制、概算費用を同じ様式で提出してもらいます。「Springへ移行できます」という説明だけでなく、S2Daoのマッピング、独自インターセプター、JSP、帳票、バッチ、外部APIをどう扱うのかを項目別に確認します。

提案説明では、実際にSeasar2の構成を理解している担当者が参加するかを見ます。営業担当だけでなく、診断責任者、移行設計者、テスト責任者、運用引き継ぎ担当者を確認し、契約後に誰が作業するかを明らかにします。公開事例として、スタイルズはSeasar 2.4とS2DaoからSpring 5への移行で、Webアプリ3本、約300メソッド、約16万ステップ、約20人月、約5か月の事例を掲載しています(出典: 株式会社スタイルズ公開事例)。このような具体的な実績の有無は、単なる対応可否より比較材料になります。

Seasar2のシステム委託で選ぶ契約形態と責任分界

システム委託契約と責任範囲を確認する場面

契約形態は、診断や要件定義を準委任、仕様が固まった移行開発を請負にするなど、工程ごとに分けて考えると実態に合いやすくなります。契約名だけで決めず、成果物、作業範囲、検収条件、変更管理、再委託、知的財産、情報管理、障害対応、終了時の引き継ぎを文書化します。

準委任契約は調査や要件定義の不確実性に向いています

準委任契約は、一定の業務を専門家に委託し、稼働時間や役割に応じて報酬を支払う形です。現行調査、業務ヒアリング、移行方針の検討、技術検証のように、着手前に作業量や難所を完全に確定しにくい工程で使いやすい契約形態です。一方、完成品の品質を一括で保証する契約ではないため、月次の成果報告、レビュー、課題一覧、次月の計画を合意して管理します。

発注者側も、必要な資料や担当者をいつ提供するかを決めます。現場ヒアリングが遅れる、検証環境が用意されない、データの意味を確認できる人が不在になると、委託先だけでは進められません。作業時間だけでなく、発注者の協力事項と遅延時の扱いまで契約書や作業計画に書いておくと、責任の押し付け合いを避けられます。

請負契約は範囲と検収条件が固まってから使います

請負契約は、合意した成果物を完成させ、検収を経て報酬を支払う形です。移行対象、画面・帳票・バッチ、性能、対応ブラウザ、データ移行件数、テスト合格基準、切り替え条件が固まっていれば、予算と納期を管理しやすくなります。ただし、要件が曖昧なまま「一式」で請負にすると、対象外機能や仕様変更が追加費用になり、双方に不満が残ります。

検収は「納品された」ではなく「業務受入テストに合格した」と定義します。特にSeasar2移行では、旧システムとの結果比較、境界値、権限、異常系、再実行、締め処理、外部連携停止時の挙動を検収項目に含めます。請負範囲外の追加要件が出た場合の見積もり単位と承認者も、契約時点で決めておくことが重要です。

知的財産・セキュリティ・保守移管を契約に入れます

ソースコード、設定、IaC、テストコード、設計書、変換ツールの出力、ログ、第三者OSSの一覧とライセンスを誰が保有するかを明記します。既存コードの著作権や、委託先が持つ共通部品の利用条件が曖昧だと、将来別会社へ保守を移すときに支障が出ます。再委託先の範囲、国外保管の有無、個人情報へのアクセス、バックアップの暗号化、アクセスログの保存期間も確認します。

保守契約では、障害の重大度ごとの受付時間、一次回答、復旧目標、脆弱性の調査と修正、JDK・OS・DBの更新、監視、バックアップ、定期報告、担当者交代時の引き継ぎを決めます。IPAの「情報セキュリティ10大脅威2026」では、組織向けの1位がランサム攻撃、2位がサプライチェーンや委託先を狙った攻撃、4位がシステムの脆弱性を悪用した攻撃です(出典: IPA、情報セキュリティ10大脅威2026)。EOLシステムの外注では、委託先管理そのものを要件に含めます。

Seasar2のシステム発注費用・移行費用の相場

Seasar2システム移行費用を見積もる担当者

Seasar2専用の公的な価格表はありません。費用は、現行資産の複雑さ、業務仕様の不明確さ、画面・帳票・バッチ数、外部連携、DB移行、テスト範囲、停止できない時間、JDK・OS・APサーバーの更新、クラウド化の有無で変わります。以下の金額は2025〜2026年に公開された一般的な業務システム相場と、公開されたSeasar2移行事例から整理した目安であり、特定案件の確定金額ではありません。

診断・部分移行・中規模刷新のレンジを分けて見ます

移行診断・資産棚卸しは、2〜6週間で100万〜500万円程度が一つの推定レンジです。小規模な部分移行は、数十画面、単一DB、外部連携が少ないケースで300万〜1,500万円程度、期間は3〜8か月程度が目安です。中規模の移行・刷新は、複数Webアプリ、S2DaoやS2JDBC、バッチ、帳票、外部API、データ移行を含めて1,200万〜4,000万円程度、6〜15か月程度を見込む考え方があります。

大規模な基幹システムで、複数部門、複数DB、24時間運用、並行稼働、厳格な監査が必要な場合は、3,000万円〜1億円超、12か月から数年に及ぶ可能性があります。一般的な2026年のシステム開発相場では、人月単価が60万〜200万円程度、小規模100万〜300万円、中規模500万〜1,000万円、大規模1,000万円〜数千万円以上と紹介されています(出典: SIA株式会社「システム開発の費用・相場 2026年版」)。Seasar2移行は調査・回帰テストが加わるため、単純な新規CRUD開発の相場をそのまま当てはめないことが大切です。

公開事例と人月単価で概算を組み立てます

費用の大枠は「人月単価×必要人月」に、PM、要件定義、環境構築、クラウド、ライセンス、データ移行、セキュリティ診断、教育、保守を加えて考えます。たとえば、公開されたスタイルズの事例にある約20人月へ、2026年の一般的な人月単価60万〜200万円を機械的に掛けると、1,200万〜4,000万円という計算になります。これは同社の見積額ではなく、公開事例と一般相場を使った参考計算です。

実際には、同じ20人月でも、発注者がテストデータと業務仕様を用意できるか、旧新比較を何ケース実施するか、Java・DB・APサーバーを同時更新するかで変わります。見積書では総額だけでなく、工程別人月、役割別単価、前提条件、含まれない作業、予備費、追加変更の単価を確認します。

保守・運用費と移行しない場合のリスクも予算化します

公開後の保守は、初期開発費の年15〜25%程度を一つの基準に置く考え方がありますが、これは契約内容によって変わる目安です。JDK・OS・APサーバー・DBの更新、脆弱性診断、監視、バックアップ、障害対応、追加改修を含むかで、月額や年額の意味が変わります。安い保守契約でも、EOL製品の脆弱性修正や担当者不在には対応しない場合があるため、対象外を確認します。

移行を先送りする場合も、費用がゼロになるわけではありません。古いJDKやAPサーバーを動かすための特別な環境、属人化した障害対応、採用難、監査対応、緊急のサーバー更新、事業停止の損失が発生する可能性があります。延命を選ぶときは、脆弱性の監視、アクセス制限、バックアップと復旧訓練、担当者育成、移行原資の積み立てを計画に含めます。

Seasar2の委託先選定と見積比較で確認するポイント

Seasar2の移行委託先と見積書を比較する場面

委託先は、会社名や見積金額だけで決めないことが重要です。Seasar2を知っていることに加えて、業務仕様を読み解く力、Java・DB・APサーバーを同時に更新する力、現新比較テスト、データ移行、運用引き継ぎ、EOL後の脆弱性対応を確認します。候補は2〜4社程度に絞り、同じRFPで提案を依頼すると比較しやすくなります。

Seasar2の構成要素別実績と移行後の技術力を見ます

実績確認では、「Javaに強い」という一般的な説明だけでなく、S2Container、dicon、S2Dao、S2JDBC、SAStruts、JSP、バッチ、帳票、独自拡張を含む案件の経験を質問します。移行先がSpring MVCなのかSpring Bootなのか、データアクセスをMyBatisなどへ変えるのか、既存DBを維持するのかも確認します。移行後の技術スタックを自社で保守できるよう、設計判断と教育の有無も評価します。

公開情報では、ウェインがSeasar2からSpringへの移行で、資産解析、自動変換、カバレッジ検証、現新比較、Java・DB・APサーバーの変更、移行後保守を案内しています。また、TDCソフトは2026年に公開したMovina Javaフレームワークマイグレーションサービスで、Seasar2などからSpring Framework等への移行を、コード解析・自動変換・自動テストと業務システムの知見を組み合わせて支援するとしています(出典: 各社の公式サービス情報)。ただし、サービス掲載だけで自社案件への適合が確定するわけではないため、担当者・実績・対象範囲を提案時に検証します。

見積書は総額ではなく前提・工数・除外項目を比較します

見積比較では、まず同じ範囲を見積もっているか確認します。A社は診断と開発を含み、B社は開発だけ、C社はクラウド費用と保守を別計上ということがあるためです。工程別に要件定義、設計、変換・実装、データ移行、テスト、教育、切り替え、PM、予備費、保守を並べ、含む・含まない・条件付きの三つに分類します。

価格が極端に安い場合は、テスト、ドキュメント、移行後の障害対応、旧環境の並行稼働、手修正、データクレンジングが抜けていないかを見ます。逆に高い場合は、不要な全再構築、過剰なクラウド構成、利用しない機能、過大なPM体制が含まれていないかを確認します。金額差の理由を説明でき、前提が変わった場合の再見積もり方法を提示できる会社が信頼しやすい候補です。

候補会社への質問で責任分界と将来の保守性を確かめます

候補会社には、「Seasar2のどの構成要素を何件扱ったか」「S2Daoの移行で手修正はどこに出るか」「現新比較テストを何ケース行うか」「旧DBを継続利用する期間はどれくらいか」「JDK・DB・APサーバーの更新を誰が担当するか」「障害時に切り戻せるか」「成果物を別会社へ引き渡せるか」を質問します。回答が具体的で、前提条件やリスクを隠さないことが重要です。

また、保守担当者が移行開発の担当者と同じか、担当者交代時にどの資料で引き継ぐか、移行後に社内へ知識移管するかを確認します。自動変換ツールは工数短縮に役立つ一方、業務ルールの正しさを自動判定するものではありません。ツールの利用を理由にテストやレビューを削らない提案になっているかを見極めます。

よくある質問(FAQ)

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

Seasar2の発注では、技術の可否だけでなく、現行業務を止めずに移行できるか、移行後に保守できるかが重要です。ここでは、発注前によく寄せられる質問に、判断条件を添えて回答します。

Seasar2で新規システムを開発しても問題ありませんか?

原則として、2026年時点の新規開発でSeasar2を第一候補にすることはおすすめしません。多くのプロダクトが2016年9月26日にEOLとなり、公式サポートが終了しているためです。既存資産を使い続ける合理的な事情がある場合でも、短期の延命計画とSpringなどへの移行計画を同時に作り、脆弱性・人材・保守契約のリスクを評価します。

Seasar2からSpringへの移行費用はいくらですか?

診断は100万〜500万円程度、部分移行は300万〜1,500万円程度、中規模の移行・刷新は1,200万〜4,000万円程度という推定レンジがあります。ただし、Seasar2専用の公定価格ではなく、公開されている一般的な業務システム相場と公開移行事例から整理した目安です。画面数、S2Daoやバッチ、外部連携、テスト、データ移行、JDK・DB更新の範囲をRFPに書き、複数社から同じ条件で見積もりを取ります。

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

適切な棚卸し、データ移行設計、旧新比較テストを行えば、データや機能を維持する計画は立てられますが、無条件に失われないとは言えません。独自SQL、S2Daoのマッピング、diconの設定、バッチ、帳票、例外処理、権限、過去データの欠損や重複を事前に確認します。移行前バックアップ、リハーサル、受入テスト、切り戻し条件を契約と計画に含めることが安全です。

何社に見積もりを依頼すると比較しやすいですか?

まず2〜4社程度に同じRFPで依頼すると、比較と発注者側の負荷のバランスを取りやすくなります。最初から社数を増やすより、Seasar2の構成要素別実績、業務システムの経験、診断の進め方、テストと保守の提案を確認して候補を絞ります。金額だけでなく、前提、除外項目、体制、成果物、移行後の責任分界を並べ、説明の具体性で評価します。

まとめ

Seasar2システムの発注計画をまとめる担当者

発注前に現行資産と業務上の制約を確認します

Seasar2のシステムを発注・外注するときは、まず公式サポートが終了した技術であることを前提に、現行資産と業務知識を棚卸しします。そのうえで、延命、部分移行、Springなどへの刷新、SaaS・パッケージへの置換を比較し、自社の業務停止リスクと将来の保守性に合う方式を選びます。

契約・予算・保守を一つの計画として比較します

発注では、RFPに目的、対象範囲、現行構成、外部連携、テスト、データ移行、切り戻し、成果物、保守条件を明記します。診断や要件整理は準委任、範囲と検収条件が固まった移行開発は請負など、工程に応じて契約形態を分けると責任分界を明確にできます。費用は診断100万〜500万円程度、部分移行300万〜1,500万円程度、中規模移行1,200万〜4,000万円程度という推定レンジを起点にし、見積書の前提・工数・除外項目を比較します。

最後に、安い会社を選ぶのではなく、S2Daoやdiconなどの構成要素を理解し、業務結果の現新比較、データ移行、脆弱性対応、成果物の引き渡し、移行後の保守まで説明できる会社を選びます。最初の一歩として、現行構成の一覧と業務上止められない処理を書き出し、診断範囲を定めることから始めると、発注の失敗を減らせます。

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

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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