WebSphere開発は、要件整理と方式選定で進め方を決め、設計・開発に入ります。そのあと、テスト、切替、運用定着の順に進めます。この順で進めると、移行や刷新の判断がぶれにくくなります。
全体像は、WebSphereのシステム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・WebSphereのシステム開発の完全ガイド
Webサービス開発の工程ごとの進め方と注意点については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
WebSphereのシステム開発の全体像
WASは、Javaで作られた業務アプリケーションを動かすランタイムで、販売管理や顧客管理の機能そのものではありません。
WASを入れただけでは、システムは完成しません。
設計の範囲は、利用者からDBまでの一連の構成です。Webサーバーやロードバランサー、WASクラスター、業務アプリも、この範囲に含まれます。IBM MQなどのメッセージングのほか、認証、監視、バックアップも対象になります。
WASと業務アプリケーションの役割の切り分け
移行調査では、WASと業務アプリ・DBの役割を分けて、確認する資産を整理します。
- WASの役割：WAR・EARの配備や、トランザクション、接続プール、セッション管理の支援。
- 基盤機能：認証・認可、TLS、ログ、クラスター運用も、WASが受け持つ機能です。
- アプリ・DBの役割：受注計算、顧客情報、在庫引当、帳票、バッチのルールを扱う部分。
- 現行調査：WASのエディションとバージョン、Java SDK、EAR・WAR、フレームワーク、JNDI名、JMSキューを洗い出す。
- 接続・運用資産：DBドライバー、証明書、外部API、バッチ、運用スクリプト、監視項目、ソース・設定の所在、ビルド手順、障害時作業。
役割の境界が曖昧なままだと、設定変更とアプリ改修の範囲が混ざり、追加費用が発生しやすくなります。そのため、要件定義の段階で必要な変更を明らかにしておきます。
調査で所在や手順が分からない点も記録しておくと、ブラックボックス化した環境でも移行範囲を見積もる材料になります。
traditional WAS・Liberty・Open Libertyの違い
方式を選ぶ際は、既存資産、必要な機能、運用形態を見比べます。サポート条件も、あわせて確認します。
- traditional WAS：既存のJava EE業務システムを続けて運用しやすい、フル機能型です。
- Network Deployment：クラスター、集中管理、高可用性が必要な構成に向きます。
- WebSphere Liberty：機能を選んで有効化でき、コンテナやKubernetes、CI/CDと組み合わせやすい方式です。
- Open Liberty：オープンソース系で、API互換性、商用サポート、IBM製品との連携は個別に確かめる必要があります。
「古いWASだから廃止」や「Libertyなら必ず安い」という見方は、そのまま当てはまるとは限りません。
IBMは2026年にも、8.5.5系と9.0.5系の更新情報を公開しています。
判断の材料は、JavaやOS、修正レベルです。
判断では、運用人材、アプリ互換性、今後の開発方針も合わせて考えます。
推奨更新情報はWebSphere Application Server推奨更新情報で確認し、実環境のサポート契約と照合します。
WebSphereのシステム開発の進め方
WebSphere案件では、サーバーとアプリを別々に進めず、要件と運用を起点にして6段階で管理します。
各段階の終了条件を先に決めておくと、テスト直前に非機能要件やデータ移行方式が変わるリスクを抑えやすくなります。
フェーズ1：要件整理による目的と制約の明確化
業務目的は、「処理を速くする」「停止時間を短くする」「既存Java資産を活用する」などの言葉で書き出しておきます。
あわせて、必須（Must）の業務機能も定めます。RFPには、許容停止時間、RTO・RPOを記します。同時利用者数、ピーク時間帯、月間処理件数も書き加えます。
個人情報や決済情報を扱うかどうか、既存契約の終了時期も書いておきます。
要件整理では、次の5項目を確認します。分からない点を「未確認」と残しておくことも、この段階の成果です。
- 業務・基盤：業務アプリ、WASのバージョンとエディション、Javaのバージョン。
- 接続先：DB・MQ・外部API、証明書の発行者と期限。
- 復旧：障害時の切替方法、バックアップと復旧時間。
- 環境・保守：開発・検証・本番の環境数、保守窓口とSLA。
- 所有者：ソースコード・設定・IaCを、誰が持つのか。
フェーズ2：選定による継続・移行・刷新の比較
方式は、同じ評価軸で比べます。評価軸は、短期の改修量と5年程度の運用費です。さらに、将来のJava更新とスキル確保も見ます。
- 現行維持：traditional WASの継続。
- 再配置：Libertyへの移行。
- 基盤移行：OpenShiftなどのコンテナ、AWS・AzureなどのIaaSへ移す。
- 再構築：業務アプリの作り直し。
また、障害時の復旧、ライセンス、サポート条件も、評価シートにまとめます。既存資産を活かす場合は、互換性を診断したうえで、代表アプリを使ってPoCを行います。
PoCでは、画面に加えてJNDI経由のDB接続、JMS送受信、認証を含めます。ファイル入出力と帳票も対象です。外部APIのタイムアウトも、業務シナリオの中で試します。
LibertyやHybrid Editionへの移行では、IBM提供のTransformation AdvisorやMigration Toolkitなどを検討します。
各ツールが自動で検出できる範囲も、あわせて確かめます。
フェーズ3：設計・開発での接続と運用の作り込み
設計では、構成図にネットワーク、ロードバランサー、クラスターを記載します。セッション管理も含めます。
DB接続プールやJNDI、JMSに加えて、認証基盤も構成図に含めます。
全体図には、ログ、監視、バックアップも入れます。
高可用性を求める場合は、台数を増やすことに加えて、復旧時の動作を決めておきます。
- 停止・再接続：片系停止時のセッション継続とDB障害時の再接続。
- 復旧・切替：MQ滞留時のリカバリーとDNS・証明書の切替。
開発では、環境の差分を手作業で作らず、できる範囲でコード化します。server.xmlやデータソースの設定、JMS設定、秘密情報も、そのコードで管理します。
コンテナイメージとデプロイ手順もコード化したうえで、開発・検証・本番の差分をレビューします。
アプリ改修では、互換性の修正と業務仕様の変更を分けて扱います。
変更の理由、テストケース、ロールバック方法は、チケットに残しておきます。
フェーズ4：テストによる正常系と異常系の検証
単体・結合・総合・受入試験に加えて、WebSphere特有の非機能試験も計画します。非機能試験では、次の負荷や障害をシナリオにします。
- 負荷・性能：通常・ピーク時の応答時間、接続プール枯渇、メモリ増加、GC、ログ量。
- 基盤障害：再起動時間、バックアップ復旧、片系停止、ネットワーク遅延。
- 接続・認証：DB停止、MQ滞留、認証失敗、証明書期限切れ。
データ移行では、件数だけでなく、金額・数量の合計や日付とタイムゾーンも照合します。文字コード、NULL、重複の扱いも確認します。採番、再送、監査証跡も対象です。
業務部門が確認できるよう、検証帳票を作ります。
完了条件には、重大障害がゼロであることと、未解決の課題ごとに責任者と期限を明確にすることを置きます。テスト完了の条件には、性能目標の達成と、切戻し手順のリハーサル完了も加えます。
「全テスト実施」という事実だけでは、完了とはしません。
フェーズ5：稼働での切替とロールバックの管理
切替と切戻しは、次の内容を計画にまとめて管理します。
- 切替日時、停止時間、利用者への告知、最終バックアップ、データ差分の反映を、分単位で整理する。
- DNS・ロードバランサーの変更、監視開始、連絡網、判断者を、切替計画に記しておく。
- 段階リリースや並行稼働が可能なら、低リスクの業務や拠点から始め、結果を見て対象を広げる。
- 検知するメトリクスや業務エラー、検知時間、切戻し承認者、新規データの扱い、旧環境への戻し方を決める。
「問題があれば戻す」と書くだけでは、切戻しは機能しません。検知条件と切戻しの手順を、具体的に決めておきます。
新旧両方の環境に書き込む期間がある場合は、二重登録や更新順序の逆転を防ぐ方式を、業務部門と合意しておきます。
フェーズ6：定着での運用と改善の継続
運用担当者が、業務への影響まで判断できる体制を整えます。
手順書には、日次・週次・月次の確認と、障害時の対応を記します。
- 日次：稼働確認。
- 週次：容量確認。
- 月次：パッチ、証明書、アカウント確認。
- 障害時：一次切り分けと、IBM・クラウドへの問い合わせ条件の確認。
引継ぎは、説明会で済ませるだけでなく、障害訓練と復旧訓練で確かめます。
セキュリティも、定着工程で扱います。たとえば、IBMが2026年2月に公表したCVE-2025-13333は、WAS 8.5と9.0を対象にしています。この脆弱性は、管理時のセキュリティが期待より弱くなる可能性があり、CVSS基本値は4.4です。
暗号化パスワードを使うセルでは、追加の手順が必要です。
修正済みのiFixやFix Packは、変更管理のもとで適用します。検証環境での確認とバックアップ、適用後の確認、切戻しを含めます。詳細はIBMのセキュリティ・ブリテンで確かめます。
WebSphereのシステム開発にかかる費用相場
WebSphereに限った国内の一律価格表は、公開されていません。
ここに示すのは、リサーチノートの業務システム相場とWAS・Java基盤の作業範囲から推定した、初期検討用のレンジです。
費用は、ライセンス、クラウド利用料、機器によって変わります。さらに、データ移行や24時間運用の有無でも変わります。発注時は、前提条件を分けて見積もります。
作業規模別の概算レンジ
規模ごとの金額と期間は、要件を置いたうえでの推定値です。公開標準価格ではありません。
- 現状診断・移行アセスメント：100万〜300万円程度、4〜8週間。
- 小規模構築：小規模なWAS環境と単純な業務アプリ1〜数本なら、300万〜700万円程度、3〜6か月。
- Liberty・コンテナ再配置：traditional WASから再配置する場合、500万〜2,000万円程度、3〜9か月。
- 中規模刷新：複数業務・複数拠点でDB、MQ、外部API、権限、監査ログ、データ移行を含み、1,000万〜3,000万円程度、6〜12か月。
- 大規模基幹系：金融・保険・公共で多重化、DR、限界性能試験、段階切替まで行う場合、3,000万〜1.5億円以上、9〜24か月になる可能性があります。
現状診断・移行アセスメントは、アプリ一覧や依存ライブラリ、Java・API、外部接続を調べる想定です。
移行の検討では、性能、脆弱性、移行先候補も見ます。
期間と金額は、規模や作業条件によって変わります。
ここに示す額は、確定価格ではなく初期検討の目安です。
ライセンス・基盤・保守の費用の分け方
開発・ライセンス・保守の費用は、前提や課金単位ごとに分けて考えます。
- ライセンス表示：Standard subscriptionは「Starting at USD 759.00」です。
- 契約条件：価格ページにはNetwork Deployment、Base、Liberty Coreなどのデプロイ選択肢を組み合わせる考え方が示されています。
- 開発工数：PM・アーキテクト、WAS・Java基盤SE、アプリ開発者、クラウド・Kubernetes担当、テスター、運用担当ごとの工数。
- 工数配分の目安：リサーチノートの一般的な配分は、要件定義10〜12%、設計・環境構築22〜24%、実装48〜50%、テスト15〜17%です。
- 保守：初期開発費の年15〜25%程度を仮置きし、IBMサポート、脆弱性対応、Java・OS・コンテナ更新、障害対応の範囲を確認します。
表示額は、国・税・提供条件によって変わる参考の表示です。
年額や日本円の導入費とは断定できません。
契約期間と課金単位、必要なVPCは、IBMまたは販売パートナーに確かめます。
価格の最新情報は、IBM WebSphere Hybrid Editionの価格ページを参照します。
WAS移行では、診断や移行リハーサル、非機能試験が増える傾向があります。
事例の数値を自社見積もりに当てはめる際の注意
事例の削減率を自社に当てはめる前に、条件と安全性を確かめます。
- SOMPO Holdingsの事例：Libertyへのモダナイズ後、100台超のサーバーと7環境を少人数で管理しています。
- 削減実績：CPUコア54%、メモリ使用量33%の削減が報告されています（出典：IBM「SOMPO Holdings」、公開事例）。
- 自社での検証：アプリ構成、負荷、集約前の余剰、運用方式の違いで、同じ効果になるとは限りません。PoCと性能試験で確かめます。
- 削減候補：未使用環境、重複監視、手作業のデプロイ、不要なアドオンが対象です。
台数やテストを先に削ると、復旧時間や将来の改修費が増えることがあります。そのため、RTO・RPOと性能の下限は守ります。監査やセキュリティも、削らずに守ります。
WebSphereの見積もりを取る際のポイント
見積もりは、合計額だけで比べず、前提と開発範囲、納品物をそろえて比べます。
WASの経験年数に加えて、一貫して説明できるかも確かめます。
比較先には、アプリ解析とJava互換性の対応力を尋ねます。
クラウド・コンテナ、性能・障害試験、運用引継ぎへの対応も確かめます。
現行資産と非機能要件の資料
問い合わせの前に、現行環境と運用の資料をそろえておきます。情報が手元になくても、既存記録から初期診断の材料を出せます。
- 現行構成：WASのバージョン・エディション、セル構成、アプリ数、Javaの版。
- 処理・接続：DB・MQ、外部接続、ピーク同時接続、データ量、停止可能時間。
- 移行・体制：クラウド希望、予算、運用体制。
- 既存記録：画面一覧、障害履歴、月次処理件数、バックアップ時間、現在の体制。
見積依頼書には、開発・検証・本番の環境数と、移行対象と対象外を書きます。
データ移行の期間や並行稼働の有無も記載します。
性能目標とRTO・RPO、監査ログは、明記します。認証方式、証明書の管理者、納品物も、同じ依頼書に書きます。「一式」と書かれた項目は、具体的な数量を質問します。
対象アプリ数と環境数、試験回数を確認します。
レビュー回数と現地対応日数も確かめます。
複数社の同条件での比較
得意分野の異なる会社を、2〜3社程度選びます。同業種か、同程度のユーザー数や似た連携数の実績があるかも確認します。
- 総合・基幹支援：メーカー直系の総合支援や大規模基幹SI。
- 基盤移行：基盤設計・保守、AWS・Azure・OpenShiftへの移行。
- アプリ刷新：Javaモダナイズ。
公開事例が海外中心の場合は、日本語窓口や国内保守を質問します。
時差や障害時のエスカレーションも尋ねます。
評価シートでは、現行診断の内容と、traditional・Liberty・Open Libertyの選択根拠を比べます。
Java EE・Jakarta EE互換性も比較の対象です。
クラウド・OpenShift、性能・障害試験、24時間運用の対応も確認します。ソースコード・IaC・設計書の引渡し、脆弱性修正SLAも対象です。
提案書で回答がない項目は、未計上の可能性があります。そのため、安い見積もりに対しては、その理由を確かめます。
追加費用と契約上のリスクの事前確認
追加費用が出やすい作業は、見積もりの段階で確認します。現行解析、古いライブラリの修正、JNDI・JMS・証明書の再設定がこれに当たります。
- データ・試験：データクレンジング、性能試験のやり直し、移行リハーサル。
- 切替・運用：夜間切替、稼働後の並走支援。
前提が崩れた際の変更管理と単価は、契約書に明記します。承認方法と納期への影響も、同じ契約書に書きます。
ソースコードやビルド定義、WAS設定の納品を確認します。IaCやテスト仕様書の納品も確かめます。
障害履歴と運用手順書も対象です。
ログの保管先と、第三者ライブラリのライセンスも確認します。著作権や利用権の帰属も、あわせて確かめます。
特に、納品物がないと他社へ移行できないことがあります。
自社で運用するために必要な情報は、契約前に一覧にします。
個人データを扱う場合は、製品が認証を受けているかどうかだけでは判断しません。
業務アプリのアクセス制御や管理者の識別・認証、監査ログは、要件に入れます。
バックアップと委託先管理も、要件として扱います。
暗号スイートやTLS終端、相互TLSを決めます。証明書更新の方法も含みます。
決める際は、IPAのTLS暗号設定ガイドライン第3.1.1版（2025年4月25日公開）の推奨セキュリティ型などを参考にします。
WebSphereのシステム開発でよくある質問
よくある疑問には、製品の古さやTomcatとの違いがあります。Liberty移行やソースコードの必要性も挙がります。発注前の判断材料になるよう、順に回答します。
WASは古いシステムなので、すぐに廃止すべきですか？
すぐに廃止する必要はありません。製品やJava、OSの状況と修正レベル、業務上のリスクを確認して判断します。
IBMの更新情報やサポート契約を見ながら、現行WASを使う期間、Libertyへ移す時期、アプリ改修の範囲を段階的に決めます。
サポート対象であっても、古い設定や担当者不足がリスクになる場合があります。
Tomcatで代替すれば、WebSphereより安くなりますか？
ランタイム費だけなら比べられる場合がありますが、Tomcatで同じ機能が得られるとは限りません。
トランザクションや接続プール、JMSを補う製品や設計が必要です。認証や管理の機能、クラスター、運用監視も用意します。
WAS標準機能の再実装費、テスト、保守人材を含めた5年総額で比べます。
Libertyへ移行すれば、必ず費用を削減できますか？
必ず削減できるとは限りません。SOMPO事例のように、CPUコアやメモリを減らせる可能性はあります。
一方で、アプリ改修やコンテナ基盤、CI/CDの費用が先に発生します。監視や教育、ライセンス、テストの費用も、先にかかります。
代表アプリでPoCを行い、性能や運用工数、障害復旧に加えて5年総額も比べたうえで、対象範囲を決めます。
移行や再構築にソースコードは必要ですか？
互換性診断と安全な移行には、ソースコードとビルド定義が必要です。EAR・WAR、設定ファイル、依存ライブラリも必要です。
- 用意するもの：DB定義、テストデータ、運用手順。
- 代わりの進め方：バイナリ解析や実機テストで進められる部分があります。
- コードの不足：改修範囲と費用の不確実性が高まります。
- 権利面の確認：利用権、第三者ライブラリ、データ持ち出しの可否。
保守費用には何を含めるべきですか？
保守の内容は、項目ごとに分けて確認します。
- 保守作業：IBM問い合わせ、パッチ適用、OS・コンテナ更新、脆弱性調査など。
- 障害分析：一次切り分けと性能劣化の分析。
- 定期の確認：証明書更新、バックアップ確認、監視、定例報告。
24時間365日の受付に加えて、契約には、復旧目標と対応時間を記します。対象外のアプリ改修、オンサイト対応、緊急変更の単価も書き込みます。
まとめ
WASを業務アプリと混同せず、Javaアプリ、DB、MQを含めて設計します。認証、監視、運用も、設計の範囲に入れます。全体は、要件整理から定着まで6段階で進めます。
現行資産と6フェーズの判断材料の準備
まず、WASやJava、EAR・WARを含む現行資産を洗い出します。JNDI・JMS、DB、外部API、証明書を一覧に加えます。監視、バックアップ、ソースコードも、同じように扱います。
継続、Liberty再配置、コンテナ化、クラウド移行、再構築を比較します。初期費用だけでなく、性能、可用性、セキュリティも見ます。さらに、運用人材と5年総額も判断材料にします。
見積もりの範囲・根拠・納品物の確認
推定相場は比較の材料にしつつ、契約前に範囲と最新の条件を確かめます。
- 診断・小規模構築：診断100万〜300万円、小規模構築300万〜700万円。
- 再配置・刷新：Liberty再配置500万〜2,000万円、中規模刷新1,000万〜3,000万円。
- 大規模基幹系：3,000万〜1.5億円以上が目安で、ライセンス等の条件で変わります。
- 契約前の確認：範囲や工数、試験、切替、成果物の比較と、公式価格・サポート・脆弱性情報の確認。
対象データに関する法令やガイドライン、開発会社の現行体制も確かめます。PoCと移行リハーサルで、リスクを見極めます。
自社のリスクを事前に確かめておくことが、WebSphereを安定して使うことにつながります。
▼全体ガイドの記事
・WebSphereのシステム開発の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。