結論：WebSphereのシステム開発費は、WASのライセンスだけで決まるのではなく、
既存Javaアプリの調査、基盤構築、連携、テスト、移行、保守まで含めて考える必要があります。
国内案件の初期検討では、現状診断だけなら100万〜300万円、小規模な環境構築とアプリ対応なら300万〜700万円、
複数業務の移行や高可用性を含むと1,000万〜3,000万円程度が一つの目安です。
ただし、WebSphereは販売管理や顧客管理そのものではなく、Java業務アプリケーションを動かす実行基盤です。
そのため、同じ「WebSphereのシステム」でも、既存WASを維持するのか、Libertyやコンテナへ移行するのか、
24時間365日の可用性を求めるのかで費用と期間は大きく変わります。この記事では、
2026年時点で確認できる公式情報とリサーチノートの推定レンジをもとに、見積もりの内訳、
価格帯、変動要因、コストを抑える進め方を説明します。
▼全体ガイドの記事
・WebSphereのシステム開発の完全ガイド
WebSphereのシステムとは何ですか？
WebSphereのシステムとは、主にIBM WebSphere Application Serverを実行基盤として、
Javaで作られた業務アプリケーションを動かす企業向けシステムです。利用者の画面、
業務ロジック、データベース、外部サービス、認証、監視などをつなぎ、業務処理を安定して実行する役割を担います。
費用を考えるときは、WASという一つの製品価格ではなく、アプリケーションと周辺基盤を含むシステム全体で見ることが大切です。
WASは業務アプリではなく実行基盤です
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
WASには、WARやEAR形式のJavaアプリケーションを配備し、トランザクション処理、接続プール、セッション管理、認証・認可、TLS。クラスター構成、アプリの監視などを支える機能があります。
業務画面やデータ項目を自動で用意するパッケージではないため、販売管理を新しく作る場合は、業務要件、画面、データベース、帳票、バッチ。APIを別途設計する必要があります。
IBMの日本語製品ページでは、WASをオンプレミス、VM、コンテナ、クラウド。
ハイブリッド環境でミッションクリティカルなアプリケーションを動かすエンタープライズ向けJavaサーバー実行環境と説明しています。
（出典: IBM「WebSphere Application Server」、2026年閲覧）。
この位置づけを理解しないまま「WASの導入費だけ」を比較すると、開発会社が行うアプリ改修や周辺連携の費用が後から追加されやすくなります。
traditional WAS・Liberty・Open Libertyの違いを見ます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
traditional WASは、既存のJava EE業務システムを継続運用しやすいフル機能型の実行環境です。
単一サーバーに近い構成で始めるBaseと、複数サーバーのクラスター、集中管理、高可用性を組みやすいNetwork Deploymentがあり。
ユーザー数、障害時の切り替え、拠点数によって選択が変わります。
Libertyは必要な機能を選んで動かす軽量なランタイムで、コンテナ、Kubernetes、CI/CDと組み合わせやすい点が特徴です。
Open Libertyはオープンソースを基盤とする選択肢ですが、IBMの商用サポート、互換性、利用するJava EE・Jakarta EE機能。運用責任の分担を確認する必要があります。
IBMの公式ドキュメントでも。
Libertyにはtraditional WASのすべての機能やAPIがそのまま含まれるわけではないと説明されています。
出典はIBMのtraditionalとLibertyの機能差資料です（2026年閲覧）。
WebSphereの開発費用相場はどれくらいですか？
WebSphere案件の国内標準価格表は一般公開されていないため、以下の金額は契約額を保証するものではありません。
リサーチノートにある業務システム全般の相場と、WebSphere特有の基盤・移行工数を組み合わせた初期検討用の推定レンジです。
ライセンス、クラウド利用料、機器、データ移行、24時間運用の費用をどこまで含むかで、
同じ規模でも見積総額は変わります。
規模別の開発費用と期間の目安です
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
現状診断や移行アセスメントだけを依頼する場合は、100万〜300万円、期間は4〜8週間程度が初期仮説になります。
アプリ一覧、Javaバージョン、WAS設定、JNDI、JMS、DB、外部API、証明書、性能、脆弱性、運用手順を調べ。
traditional WASを継続するかLiberty・クラウドへ移るかを整理する費用です。
開発・テスト環境を含む小規模なWAS構築と、単純な業務アプリ1〜数本の対応は、300万〜700万円、3〜6か月程度が一つの目安です。
中規模で複数の業務、DB、MQ、外部API、権限、データ移行を扱う場合は1,000万〜3,000万円、6〜12か月程度になりやすいです。
金融、保険、公共などで多重化、DR、性能限界試験、監査、段階切替まで求める大規模基幹系では、3,000万〜1.5億円以上、9〜24か月になる可能性があります。
これらは要件と体制から推定したレンジであり、実際の契約額はRFPと現行資産の調査結果で確定します。
ライセンスとインフラは別枠で確認します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
IBMのWebSphere Hybrid Edition価格ページには。Standard subscriptionが「Starting at USD 759.00」と表示されています。
そこでは、1 VPCのWAS Network Deployment、4 VPCのWAS Base。
8 VPCのLiberty Coreを組み合わせる考え方が示されていますが、IBM自身が国、税、提供条件。
地域で価格が変わる参考表示だと明記しています。（出典: IBM「WebSphere Hybrid Edition – Pricing」、2026年閲覧）。
したがって、表示額を日本の年間料金やプロジェクト総額と断定することはできません。
参考として、1ドルを150円と仮置きして機械的に換算すると約11.4万円ですが、これは為替換算にすぎず、契約期間、課金単位、サポート。製品エディション、日本向けの販売条件を含んでいません。
さらに、サーバーやコンテナのCPU・メモリ、OS、DB、ロードバランサー、ストレージ、バックアップ、監視、ネットワーク、ログ保管、クラウド転送量は。ライセンスとは別の費用です。
見積書では「ライセンス」「クラウド・機器」「構築」「アプリ改修」「保守」を分けて記載してもらいます。
費用の内訳は人件費・基盤費・運用費です
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
WebSphere案件の費用は、まずPM・アーキテクト・WAS基盤SE・Java開発者・クラウド担当・テスター・運用担当の人件費に分かれます。
リサーチノートでは一般的に人件費が開発費の60〜80%程度を占めると整理されていますが、これは案件の契約形態と工程配分で変わる目安です。
要件定義、設計、実装、テストの比率だけでなく、移行アセスメント、リハーサル、切り戻し設計の工数も独立項目にしておくと、追加費用を把握しやすくなります。
次に、WASやLibertyのライセンス、JavaやOSのサポート、クラウドまたは物理機器、DB・MQ、認証基盤、監視、バックアップ。セキュリティ製品などの基盤費があります。
最後に、脆弱性対応、パッチ検証、障害一次対応、性能監視、問い合わせ、定期報告、OSやJavaの更新を含む保守費があります。
保守を初期開発費の年15〜25%程度と仮置きすることはできますが、24時間365日対応やSLA、オンサイト対応が加わると上限を超えるため。数字だけで判断しないことが大切です。
WebSphereの開発費用が変動する要因は何ですか？
同じWASを使う案件でも、費用差の中心はソフトウェア名ではなく、既存資産の複雑さと非機能要件です。
見積もりの精度を上げるには、アプリ本数だけでなく、依存関係、連携数、ピーク負荷、
停止可能時間、データ量、運用体制まで初期段階で共有します。
古いJavaと設定の互換性が工数を左右します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
traditional WASからLibertyへ移す場合、EAR・WARを配備し直せば終わるとは限りません。
JNDI名、JMSキュー、データソース、認証方式、証明書、セッション、トランザクション、独自API、古いJava EE仕様、ログ出力。
バッチ実行の差分を調べ、必要に応じてソースコードと設定ファイルを修正します。
ソースコードが不足している場合や、担当者しか知らない手作業が残っている場合は、調査と再現検証の費用が増えます。
Libertyは軽量でコンテナに向く一方、traditional WASで利用していた機能がすべて同じように利用できるとは限りません。
IBMの公式ドキュメントも、セキュリティを含む一部機能やAPIはサポート範囲が異なると説明しています。
移行先を先に決めて費用を期待するのではなく、代表アプリを使った互換性調査と小規模PoCを実施してから本見積もりへ進みます。
可用性・セキュリティ要件で構成が変わります
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
単一サーバーで業務時間だけ動かすシステムと、複数ノードで24時間365日稼働させるシステムでは、必要な構成が違います。
後者ではロードバランサー、クラスター、セッション設計、共有ストレージ、監視、バックアップ、遠隔地のDR、障害時の切り替え、復旧訓練まで設計するため。WASの設定費だけを比べても意味がありません。
RTOやRPO、許容停止時間、同時接続数を数値で示すと、必要以上の構成を避けやすくなります。
個人情報や決済情報を扱う場合は、認証・認可、管理コンソールのネットワーク分離、TLS、秘密情報の管理、監査ログ、脆弱性対応、バックアップの暗号化が必要です。
個人情報保護委員会のガイドラインは、アクセス制御や識別・認証。
不正アクセス防止などの安全管理措置を示しています。（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年閲覧）。
要件定義後にセキュリティを追加すると、設計変更と再試験が発生しやすくなります。
DB・MQ・外部連携とデータ移行が膨らみやすいです
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
WebSphereの業務システムは、DB、IBM MQなどのメッセージング、認証基盤、基幹ホスト、外部API、帳票、ファイル転送と接続していることが多いです。
連携先が増えるほど、接続方式、タイムアウト、リトライ、重複送信、文字コード、証明書、障害時の再処理を確認するテストが増えます。
見積書の「外部連携一式」という表現だけでは、何本のAPIやキューが含まれるのか分からないため、接続先を一覧にします。データ移行も、テーブル件数を移すだけでは不十分です。
金額や件数の合計、日付・タイムゾーン、文字コード、重複、欠損、参照整合性、移行後の再送、監査証跡を照合し、リハーサルと切り戻しを行います。
停止できない業務では並行稼働や段階切替が必要になり、移行設計と運用調整の比率が高くなるため、開発費と期間が上振れしやすくなります。
見積もりに含めるべき費用の内訳は何ですか？
比較しやすい見積もりは、作業のまとまりと前提条件が分かれています。「環境構築一式」
「移行一式」「保守一式」のような大きな項目だけでは、安く見える見積もりに必要作業が含まれているのか判断できません。
最低でも、調査、設計、構築、アプリ対応、テスト、移行、教育、保守を区切ってもらいます。
現状診断・アセスメント費用を独立させます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
最初に、WASのバージョン、Fix Pack、Java SDK、OS、アプリ本数、EAR・WAR、フレームワーク、JNDI、JMS、DB、外部接続。
証明書、監視、バックアップ、ソースコード、設定ファイル、運用手順を確認します。
診断の成果物は、単なる現状報告ではなく、互換性リスク一覧、移行候補、追加調査事項、概算工数、優先順位、PoC計画にします。これが100万〜300万円程度のアセスメント費用に含まれるかを確認します。
現行環境の情報が不足している場合は、安い概算を出すことより、調査を先に契約する方が結果的に安全です。
特に、担当者の記憶だけで設定を再現している場合、未使用に見えるキューや証明書が本番業務に必要なことがあります。
診断を省くと本開発中に想定外の依存関係が見つかり、追加費用と納期遅延につながります。
設計・環境構築・アプリ改修を分けます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
設計では、ネットワーク、ロードバランサー、WASセルまたはサーバー、クラスター、DB・MQ、認証、ログ、監視、バックアップ。開発・検証・本番の環境差分を決めます。
クラウドやコンテナを選ぶ場合は、イメージ管理、秘密情報、デプロイ、ロールバック、脆弱性スキャン、可観測性も対象です。
環境を作るだけでなく、同じ手順で再構築できる設計書やIaCを成果物に含めると、将来の保守費用を抑えやすくなります。
アプリ改修は、互換性のある設定変更だけで済むのか、JavaやAPIの更新が必要なのか、画面や業務ロジックの変更まで行うのかで大きく違います。
アプリ単位、画面単位、連携単位で工数を分け、改修しない範囲も明示します。
ライセンスを契約する会社と開発会社が異なる場合は、製品サポートの範囲とアプリ改修の責任分界も見積書に記載します。
テスト・移行・リリースの費用を省略しません
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
テストは、単体・結合・システム・性能・障害・セキュリティ・運用リハーサルに分けます。
特にWASでは、片系停止、セッション引き継ぎ、DB接続枯渇、MQ滞留、外部APIのタイムアウト、証明書期限切れ、ログ欠落。管理コンソールのアクセス制御を確認します。
正常系の画面確認だけを見積もっている場合、リリース前に非機能試験が追加されるため注意が必要です。
移行では、データ変換、バックアップ、リハーサル、並行稼働、切替、切り戻し、利用者周知、運用引継ぎを含めます。
移行後の問い合わせ窓口や初期安定化支援も、無償対応と決めつけず期間と件数の前提を置きます。これらを初期見積もりに含めるほど金額は高く見えますが、後から追加される予算外作業を減らす効果があります。
保守・サポート費の対応範囲を確認します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
保守費には、IBM製品の問い合わせ、Fix PackやiFixの情報提供、脆弱性の影響調査、Java・OS更新の検証、監視、障害一次対応、原因調査。定例会、運用改善などがあります。
WAS 8.5.5と9.0.5について、IBMは2025年7月のサポート情報で計画済みのサポート終了日がないと案内していますが、Java、OS。
製品エディション、修正レベルごとの条件は別に確認が必要です。（出典: IBM「WebSphere Application Server – Support FYI」、2025年7月更新）。
IBMの推奨アップデート一覧では、traditional WASとLibertyのFix Packや継続的なリリースが案内されています。
サポート終了日がないことは、更新作業が不要という意味ではありません。
保守契約では、脆弱性情報を受けて何営業日で影響を判定するか、本番適用前の検証環境を誰が用意するか、障害時にどこまで調査するかを明確にします。
WebSphereシステム開発はどのように進めますか？
費用を適正にするには、要件定義で決めることと、調査後に決めることを分けます。いきなり本番基盤を作るのではなく、
現行資産と業務上の優先度を確認し、代表的な処理で移行リスクを検証してから、段階的に開発範囲を確定します。
要件定義で業務と非機能を数値化します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
業務要件では、対象部門、利用者、画面、帳票、バッチ、承認、外部連携、データ保持期間、将来の拡張を定義します。
非機能要件では、同時接続数、ピーク時間帯、レスポンスタイム、稼働時間、RTO、RPO、監査ログ、バックアップ期間、脆弱性修正の期限を数値で示します。
「速い」「止まらない」といった表現だけでは、必要なWAS構成やテスト範囲を決められません。現行をそのまま再現する機能と、廃止・簡素化する機能も分けます。
既存画面や帳票をすべて残すと移行は分かりやすい一方、不要な負債まで引き継ぐ可能性があります。費用を抑えたい場合は、業務上の必須度と利用頻度を確認し、段階リリースに回せる機能を要件定義で決めます。
現行資産の棚卸しとPoCを実施します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
棚卸しでは、WASの版数とFix Packだけでなく、Java、OS、アプリケーション、ライブラリ、DB、MQ、証明書、外部API、バッチ。運用スクリプト、監視項目、障害履歴を一覧にします。
担当者へのヒアリングだけでなく、設定ファイル、ログ、デプロイ履歴、ソースコード、IaCの有無を照合します。ここで情報の欠落を見つけることが、追加費用を抑える最初のポイントです。
PoCでは、最も複雑なアプリや重要な連携を一つ選び、WASからLibertyへの配備、認証、DB接続、MQ送受信、ログ、性能、障害切り替えを試します。
IBMにはTransformation AdvisorやMigration Toolkitなどのモダナイゼーション支援ツールがありますが。
ツールの診断結果だけで本番移行の成功を保証するものではありません。
PoCの結果を本見積もりの前提に反映し、未検証の項目をリスクとして残します。
環境構築とアプリ対応を段階的に進めます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
設計では、開発・検証・本番の構成、ネットワーク、WASセル、クラスター、DB・MQ、認証、監視、バックアップ、秘密情報、ログ、リリース手順を定義します。
次に、開発環境でアプリを配備し、互換性修正、設定変更、データ接続、連携を進めます。環境ごとの差分を手作業で増やすと、リリース時の確認が増えるため、可能な範囲で設定管理とデプロイを自動化します。
性能・障害・移行リハーサルを経てリリースします
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
テストでは、業務シナリオ、連携、負荷、障害、セキュリティ、運用手順を確認します。負荷試験は平均値だけでなく、ピーク時のCPU、メモリ、スレッド、DB接続、MQ滞留、レスポンスタイムを見ます。
障害試験では、片系停止、DB停止、ネットワーク遅延、認証失敗、証明書の期限切れを想定し、検知から復旧までの時間が要件に合うか確認します。
移行リハーサルでは、バックアップ、データ変換、差分反映、切替、利用者確認、切り戻しを通しで実施します。
リリース後は、初期安定化期間の監視項目と問い合わせ窓口を決め、運用チームへ設計書、設定、手順、既知の問題、連絡先を引き渡します。
開発完了を本番稼働だけで判断せず、運用が自走できる状態までを成果とします。
WebSphereシステムのコストを最適化するポイントは何ですか？
コスト最適化は、単純に安いエディションへ変えることではありません。必要な可用性、
性能、サポート、セキュリティを満たしながら、使っていない機能、重複する環境、手作業、
不要なデータ、過剰なインスタンスを減らす考え方です。初期費用と運用費を分け、3〜5年程度の総保有コストで比較します。
要件に合わせてランタイムと容量を適正化します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
まず、すべてのアプリに同じWASエディションや高性能サーバーを割り当てる必要があるかを確認します。高可用性が必要な中核処理と、停止可能な社内処理を分け、必要な環境だけクラスターやDRを採用します。
Libertyやコンテナが適するアプリでも、互換性調査、商用サポート、監視、イメージ更新の運用費まで含めて判断します。
IBMのSOMPOホールディングス事例では、WebSphere Libertyを利用したモダナイゼーション後に。
100台以上のサーバーを少人数で管理し、CPUコア54%削減。メモリ33%削減を実現したと公表されています。（出典: IBM「SOMPO Holdings」、2026年閲覧）。
これは個別の大規模事例であり、すべての会社で同じ削減率になるわけではありませんが、ランタイム選択とアプリ・インフラの見直しを同時に行う価値を示す参考情報です。
一括刷新ではなく段階移行にします
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
すべてのアプリを同時に移行すると、テスト環境、移行担当者、切替時間、障害対応の負荷が一気に増えます。
最初に依存関係が少なく、業務影響を抑えやすいアプリで移行手順と監視を確立し、次に重要度の高いアプリへ広げると、リスクと手戻りを抑えやすくなります。
段階移行では、古い環境と新しい環境の二重運用費が一時的に発生するため、並行期間を事前に決めます。
既存WASをすぐに廃止できない場合でも、アプリの棚卸し、Java更新、設定のコード化、監視の標準化を先に進められます。
移行しない判断も、調査結果と保守期限、脆弱性、担当者の確保を記録しておくと、将来の再見積もりが容易になります。
自動化と運用標準化で継続費を下げます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
環境ごとに管理画面から設定する運用は、担当者の工数と設定差分を増やします。
WAS設定、アプリ配備、証明書更新、バックアップ確認、監視設定、リリース、ロールバックをスクリプトやパイプラインで再現できるようにします。
自動化の初期費用は必要ですが、複数環境や多数アプリを長期運用する場合は、作業時間とヒューマンエラーを減らす効果が期待できます。
運用標準化では、アラートの重要度、一次切り分け、エスカレーション、パッチ適用、障害後の振り返り、設計書の更新を定義します。
IBMのFix PackやLibertyの継続的な更新を取り込める検証環境を用意し、本番適用の手順と中止基準を決めます。
保守を丸ごと外注する場合も、設定とログを発注者が読める状態にしておくと、ベンダー変更時の移行費を抑えられます。
成果物と権利を契約で確保します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
費用を抑えるために納品物を減らすと、将来の保守や移行で別の費用が発生することがあります。
ソースコード、WAS設定、server.xml、デプロイ手順、IaC、テスト仕様書、性能結果、障害対応手順、ライセンス情報。パスワード管理の引継ぎ方法を契約書と仕様書に記載します。
ソースコードの所有権、利用許諾、改変・再利用の範囲、第三者ライブラリのライセンスも確認します。成果物を自社で再利用できる状態にすると、次回の機能追加やベンダー変更でゼロから調査する費用を避けられます。
開発会社に任せる範囲と自社が持つ範囲を明確にし、安い初期見積もりだけでなく、運用期間を含む総額で判断します。
WebSphereの見積もりを取る際のポイントは何ですか？
複数社から見積もりを取るときは、同じ前提条件を渡すことが重要です。WebSphereに詳しいという言葉だけでなく、
Javaアプリ解析、WAS基盤、クラウド・Kubernetes、性能試験、移行、
運用引継ぎを担当できる体制と実績を確認します。会社の知名度や単価だけで決めず、同程度のアプリ数、
ユーザー数、連携数、停止条件を扱った事例を聞きます。
RFPに現行環境と前提条件を書きます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
RFPには、現行WASのバージョン、Java、OS、アプリ本数と容量、DB・MQ、外部API、ユーザー数、ピーク同時接続、データ量、稼働時間。
停止可能時間、RTO・RPO、クラウド希望、予算感、希望時期、運用体制を記載します。
Liberty、Open Liberty、traditional WAS、IaaS、コンテナの比較を求める場合は、製品名を決め打ちせず、互換性、性能。サポート、3〜5年の総額で提案してもらいます。
情報が分からない項目は空欄にせず、「調査して確定」「提案者の仮定を明示」と書きます。
見積もりの前提一覧に、アプリのソースコードが提供されること、環境へのアクセスが可能なこと、ユーザー側の確認担当者が確保されることを記載すると。発注後の認識違いを減らせます。
金額だけでなく比較軸をそろえます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
比較表には、アセスメント、traditional WAS・Liberty・Open Libertyの対応、Java EE・Jakarta EE互換性。
クラウド・OpenShift、性能・障害・セキュリティ試験、24時間運用、成果物、脆弱性修正SLA、追加変更の単価を並べます。
初期費用が安くても、調査、移行、教育、保守、クラウド利用料が別建てなら、総額では高くなることがあります。提案会では、想定リスクを質問します。
たとえば「JNDIとMQの設定が資料と一致しない場合に誰が調査するか」「Libertyで非対応の機能が見つかった場合の代替案は何か」を確認します。
「本番障害時の一次対応とIBMへの問い合わせはどちらが行うか」も確認します.
リスクを具体的に説明できる会社ほど、見積もりの前提も明確になりやすいです。
追加費用・契約・引き渡し条件を確認します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
契約前には、仕様変更の定義、前提条件が外れた場合の再見積もり、納期変更、検収条件、瑕疵対応、保守開始日、脆弱性対応、第三者製品の費用を確認します。
「一式」に含まれる作業と含まれない作業を一覧にし、移行リハーサル、切り戻し、休日切替、利用者教育、初期安定化支援を除外しないようにします。
契約終了後に必要なソースコード、設定ファイル、設計書、テスト結果、運用手順、ライセンス証書、アカウント情報の引き渡しも決めます。
特に、著作権や改変・再利用の範囲が曖昧だと、別会社へ保守を移すときに追加費用や許諾確認が発生します。見積もりの安さと同じくらい、将来の自由度を確認します。
WebSphereのシステム開発費用に関するよくある質問
ここでは、費用を調べる担当者が特に迷いやすい質問に答えます。正確な金額は現行資産と要件の調査後に決まるため、
回答は公開情報と一般的な推定レンジとしてご覧ください。
WASのライセンス価格だけ分かれば総額を出せますか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
いいえ、ライセンス価格だけでは総額を出せません。
WebSphereはJava業務アプリを動かす基盤なので、アプリ改修、サーバー・クラウド、DB・MQ、認証、監視、バックアップ、テスト、移行。保守を加える必要があります。
IBMの価格ページにも参考表示はありますが、国、税、提供条件、契約単位で変わるため、日本向けの見積もりを別途取得します。
Libertyへ移行すれば必ず安くなりますか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
必ず安くなるとは限りません。
Libertyは軽量でコンテナやCI/CDに向くため、環境や運用を適正化できる可能性がありますが、互換性調査、ソースコード修正、設定変更。性能・障害試験、二重運用の費用が先に発生します。
IBMのSOMPO事例の削減率は有用な参考情報ですが、アプリ、サーバー数、運用方式が異なる企業にそのまま適用できる数字ではありません。
WebSphereの移行にソースコードは必要ですか？
多くのケースで必要です。互換性の確認やJava・APIの修正、ビルド、テスト、デプロイを行うには、
ソースコード、依存ライブラリ、設定ファイル、ビルド手順が必要になります。ソースコードが提供できない場合は、
バイナリでの動作確認、設定の再現、ベンダーへの照会が必要になり、診断費用と移行リスクが高くなる可能性があります。
保守費用には何を含めるべきですか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
製品サポート、脆弱性の影響調査、Fix PackやiFixの検証、Java・OS更新、監視、障害一次対応、原因調査、定例報告、運用改善を分けて記載します。
受付時間、対応時間、復旧目標、オンサイトの有無、問い合わせ件数、対象外のアプリ改修を決めないと、保守費用の比較ができません。
初期開発費の年15〜25%という目安を使う場合も、24時間対応やDR運用が含まれるかを確認します。
まとめ
WebSphereのシステム開発費は、WASのライセンス単価だけでなく、現状診断、
Javaアプリの互換性対応、基盤構築、DB・MQ・外部API、データ移行、性能・障害・セキュリティ試験、
保守まで含めて判断します。初期検討では、診断・移行アセスメント100万〜300万円、
小規模構築300万〜700万円、中規模刷新1,000万〜3,000万円、大規模基幹系3,000万〜1.5億円以上という推定レンジを使えますが、
いずれも前提条件付きの目安です。
費用を比較するときの結論です
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
IBMの公式価格は参考値として確認し、国内開発費、クラウド費、機器費、保守費を分けます。
traditional WASを継続する場合も、Libertyやコンテナへ移行する場合も、互換性と非機能要件を先に調査します。
安さだけでなく、障害時に復旧できること、脆弱性へ継続対応できること、将来のベンダー変更で資産を持ち出せることを含めて総保有コストを評価します。
発注前に行うべき一歩です
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
まず現行WASのバージョン、Java、アプリ本数、DB・MQ、外部連携、ピーク負荷、停止可能時間、運用体制、ソースコードと設定ファイルの所在を整理します。
そのうえで、100万〜300万円程度のアセスメントを含む提案を複数社へ依頼し、作業範囲、成果物、追加費用、保守SLA、移行後の責任分界を比較します。
WebSphereの経験年数だけでなく、同じ複雑さの案件を最後まで運用へ引き継いだ実績を確認することが、予算と品質を両立する近道です。▼全体ガイドの記事
・WebSphereのシステム開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。