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

WebSphereのシステムを発注するときは、まず現行の資産を洗い出すところから始めます。そのうえで、発注形態を選び、契約と費用、委託先を順に決めていきます。

稼働後は、移行・テスト・運用引き継ぎまで管理します。全体像は、WebSphereのシステム開発の完全ガイドにまとめています。

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

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

発注前に整理するWebSphereの全体像

WebSphereのシステムは、IBM WebSphere Application Server（WAS）を中心に組み立てられます。その周りには、Java業務アプリ、DB、外部連携、認証、監視なども含まれます。

IBMは、WASをオンプレミス、VM、コンテナ、クラウド、ハイブリッド環境で重要なJavaアプリを実行する環境と説明しています（出典: IBM「WebSphere Application Server」、2026年8月確認）。

WASの位置づけ：Javaアプリの実行基盤

販売管理や顧客管理、契約管理などの画面や業務ルールは、WAR・EAR形式などのJavaアプリに実装します。そのアプリをWASに配備して動かします。

• 実行基盤：トランザクションや接続プール、セッション、認証・認可、TLS、配備、クラスター運用を、WASが支えます。
• 発注範囲：新規開発・改修やDB・IBM MQ接続、帳票、バッチ移行も必要になる場合があります。

「WAS構築一式」とだけ発注すると、たとえば、ソース解析や証明書、夜間バッチの作業が見積から外れるおそれがあります。JNDIや外部API、障害時の切り戻しも、範囲を明記しておくべき項目です。

継続利用でも、委託範囲は現行環境の一覧をもとに決めます。バージョンやアプリ数、連携先を一覧に残し、利用者数やJava SDK、ピーク負荷も加えると、範囲の食い違いを減らせます。

traditional WASとLibertyの選び方

候補となる方式は、現行環境の構成と今後の開発方針から絞り込みます。

• traditional WAS：既存のJava EEアプリを大きく変えずに使うなら、継続利用や更新が候補になります。
• Network Deployment・Base：クラスターや集中管理、高可用性が求められる場合は前者、単一サーバーに近い構成なら後者を検討します。
• Liberty系：新規開発やコンテナ化、CI/CDを進めるなら、WebSphere LibertyやOpen Libertyが候補になります。

IBMの案内では、2025年7月時点でWebSphere 8.5.5と9.0.5に計画されたサポート終了日はありません（出典: IBM「WebSphere Application Server – Support FYI」、2025年7月17日更新）。

ただし、製品サポートが続くことと、Java、OS、DB、修正レベルを安全に保てることは別の問題です。改修量と運用負荷を中心に、ライセンスや人材確保も比べます。

比較対象には、継続利用、Libertyへの再配置、OpenShiftやIaaSへの移行を含めます。

WebSphereの発注形態の選び方

発注形態には、一括委託、総合SIerへのプライム発注、要件整理と構築を分ける分離発注があります。適した形は、WASや業務の知識、資産の複雑さ、停止可能時間によって変わります。

一括委託で窓口を一本化しやすい方法

一括委託では、窓口をまとめる利点と、委託先の体制を見ておきます。

WAS設計からJavaアプリ開発、DB・ネットワーク構築、移行、テスト、運用引き継ぎまでを、一社がまとめて受け持つ形です。

• 窓口と責任：WASに詳しい担当者が少ない企業や、既存資料が乏しい企業に向いています。
• 実績の確認：高可用性や監査、24時間365日の運用を求めるなら、類似規模の総合SIerを候補に入れます。

一社の提案だけでは、価格や設計を判断しにくいです。そのため、ライセンス・基盤、アプリ改修、移行、テスト、保守を分けた見積を求めます。

再委託や技術者の経験を確かめ、ソースコードやIaC、運用手順書をどこまで渡すかも決めておくと、ベンダーロックインを防げます。

要件整理と構築を分けた発注の進め方

業務要件を整理しにくい場合は、独立したコンサルタントやPMOに現状分析とRFP作成を依頼できます。

• 提案比較：第三者が要件を整理したあとで複数社から提案を受けると、条件をそろえて比べられます。
• 方式の選択肢：候補を初めから狭めず、traditional WAS、Liberty、Open Liberty、IaaS、コンテナを比べます。

分離発注では、基盤・アプリ・ネットワーク・DB・MQのどこに原因があるかを切り分ける責任が、会社ごとに分かれます。そのため、体制図でプライム責任者と各社の範囲を定めます。

統合テストの主催者やリリース判定者、障害時の連絡順も、同じ体制図に定めます。

分離すると費用が抑えられることもありますが、調整会議と統合管理の工数も予算に含めておきます。

移行の不確実性が高い場合の段階発注

現行の設定や依存関係が不明なら、本開発の前に4〜8週間程度の現状診断・移行評価を発注します。現状診断では、アプリや連携、性能、脆弱性、運用手順を調べます。JavaやAPI、JNDI・JMS、証明書も、この段階で確かめます。

継続利用とLiberty移行を比べるときは、診断の成果物を次工程のRFPや見積の前提にします。そうすると、想定外のアプリが後から見つかる事態を防ぎやすくなります。

RFPと要件整理で決める項目

RFPは、委託先に同じ条件で提案と見積を依頼する文書です。目的と範囲、現行資産を書き、データや連携、非機能要件のほか、時期や予算、検収条件も含めます。

不明な点は空欄にせず、「現状調査で確認する項目」として残します。そうすると、調査の工数も見積に含めてもらいやすくなります。

業務目的と対象範囲の数値化

成果を判断できるよう、「古いWASを新しくしたい」という目的を、業務目的と対象範囲として具体化します。

• 業務範囲：受注から請求までのどの工程を対象にするか、利用部門と拠点を決めます。
• 測定指標：利用者数やピーク、停止時間、応答を測る指標を決めます。処理件数や復旧時間、移行許容差も整理します。
• 新規開発：画面や帳票、バッチを対象にします。権限や承認、監査証跡、例外処理も含めます。
• 基盤移行：既存の環境を移すのか、パッケージとして稼働させるのかを示します。そのうえで、変更範囲、互換性、性能回帰、切り戻しを定めます。

現行WASと周辺連携の棚卸し

現行の基盤やアプリ、周辺システムの情報をそろえると、調査の範囲を見積に反映できます。

• 基盤情報：WAS版やFix Pack、Java SDK、OS、台数とクラスター、デプロイ単位、設定場所を記録します。
• アプリ情報：WAR・EARやFW、Java EE APIを含むアプリの構成を一覧にします。独自ライブラリやJNDI・JMS、DB接続、証明書期限も書き加えます。
• 資料不足：資料がない場合は、リバースエンジニアリングや実機調査の工数も初期見積に含めます。
• 周辺構成：LB、Webサーバー、DB、IBM MQ、認証、監視などを洗い出します。ファイル・API、バックアップ、ジョブ、ログも対象です。
• 連携条件：通信方式と認証方式、送受信データ、再送、タイムアウトを記録します。障害時の責任者も、あわせて残します。

JNDIやMQ、証明書は見落としやすく、移行後の障害につながりやすい項目です。そのため、RFPに連携一覧を添付します。

RFPに含める非機能要件とPoC

要件は法令名を挙げるにとどめず、どの機能と運用で満たすかまで書きます。

• 非機能要件：可用性や性能、拡張性、セキュリティを定めます。さらに、バックアップ、災害対策、監視、運用時間、RTO・RPOも決めます。
• データ保護：ログ期間やパッチ停止手順を書きます。さらに、アクセス制御や認証、不正アクセス防止、委託先管理も記します。
• PoCの対象：画面や重要処理、外部連携、ピーク負荷を試します。片系やDBの停止、MQの滞留、認証失敗、証明書切れも試します。
• PoCの確認：障害時の再試行やロールバックを試し、費用や成果物、設定・コードの再利用条件を決めます。

WebSphere外注の契約形態と役割分担

現状診断や要件整理は作業内容が変わりやすい工程です。一方で、設計書やプログラムは成果物を合意しやすい工程です。

そのため、契約は一つにまとめず、工程ごとに契約形態や成果物、検収、変更手続きを決めます。追加費用と責任を管理するうえで、この区切りが役立ちます。

要件整理の準委任と開発の請負

作業の不確実性や成果物の定まり方に応じて、契約形態を選びます。

• 準委任：現状調査や要件定義、技術支援、PMO、運用改善など、作業の遂行を依頼する工程に向きます。
• 請負：合意した設計や設定、プログラム、テスト成果物を完成させ、検収する工程に適しています。

調査後に作業が変わるため、稼働時間や担当者、会議体、調査報告書を先に定めておきます。

責任の範囲は、契約名よりも中身で決めます。準委任なら報告内容と期限を、請負なら仕様変更や前提変更の扱いを決めておきます。

要件が未確定の工程に完成責任を求めると、認識がずれやすくなります。また、仕様が確定した開発を時間精算で進めると、互いの理解がずれたまま進むおそれがあります。

契約書に明記する成果物・知的財産・変更管理

契約後に認識がずれないよう、引き渡す内容や権利、変更の扱いを具体的に書きます。

• 成果物・引渡し：診断結果や要件・設計、WAS設定、server.xml、IaCを定めます。さらに、ソースや試験、移行・運用手順、監視、教育資料も明記します。
• 権利・情報管理：著作権や翻案権、第三者ライブラリ、既存資産の扱いを確認します。秘密情報や再委託、脆弱性、データの返却・消去も確かめます。
• 変更管理：追加単価や承認者、納期への影響、緊急変更を定めます。そのうえで、「一式」見積は固定項目と変動項目に分けます。

納品形式やリポジトリ、アカウントの所有者、引渡し時期も明記します。設定や自動化スクリプトがないと、別の会社へ保守を移す際に、環境を再現できないおそれがあります。

発注者と受託者の作業分担（RACIのような整理）

発注者と受託者、複数の会社のあいだでは、担当する作業と調整役を明確にします。

• 発注者：業務の優先順位やキーユーザー、データ確認を担い、受入テストとリリース判断も受け持ちます。
• 受託者：技術調査や設計、構築、開発を担います。テストや移行支援、操作教育も担当します。
• 複数社の連携：DB・ネットワーク・認証基盤を別の会社が受け持つ場合は、会社間の調整役を明記します。

個人・機密データの持ち出し、アクセス権、ログ、バックアップの責任を分けます。端末やリモート接続、脆弱性修正についても、担当を決めておきます。

IBMのCVE-2025-13333 bulletinでは、WAS 8.5・9.0が影響製品として挙げられています。

修正済みiFixやFix Packが推奨されています（出典: IBM「Security Bulletin: CVE-2025-13333」、2026年3月9日更新）。

保守契約には、脆弱性の通知や評価、検証、適用、緊急時の連絡時間まで含めます。

WebSphereのシステム発注費用と相場

WebSphere案件の国内標準価格表は公開されていません。そのため、ここに示す金額は、業務システムの規模感と基盤・移行工数から置いた初期仮説です。

総額は、ライセンスやクラウド、機器、移行で変わります。24時間運用や税の有無も、総額を左右します。そのため、同じ前提で正式見積を取ります。

診断・小規模開発・移行ごとの費用レンジ

費用と期間の目安は、作業規模と対象となる移行内容ごとに異なります。

• 診断：アプリ一覧や依存関係、外部連携、性能、脆弱性、移行先候補を調べ、100万〜300万円、4〜8週間程度が初期仮説です。
• 小規模開発：小規模なWAS環境の構築と、単純な業務アプリ1〜数本が対象で、300万〜700万円、3〜6か月程度が目安です。
• Liberty等への再配置：traditional WASからLibertyやコンテナへ移す場合は、500万〜2,000万円、3〜9か月程度です。
• 複数業務・拠点の刷新：1,000万〜3,000万円、6〜12か月程度です。
• 大規模基幹：3,000万〜1.5億円以上、9〜24か月程度まで上振れする可能性があります。

小規模開発には、開発・テスト環境や認証、監視、バックアップ、基本CI/CDが含まれます。一方で、診断と小規模開発の金額は、ライセンスやクラウド料金を除く想定です。

再配置では、互換性やserver.xml、JNDI・JMSの確認に加えて、証明書やログ、性能・障害試験の作業も増えます。

各金額は、ノートに基づく推定レンジで、個別案件の価格を断定するものではありません。

ライセンス費と開発・基盤費の分けた見積

IBMの価格ページでは、Hybrid Edition Standard subscriptionが「Starting at USD 759.00」と示されています。この金額は、国や税、提供条件で変わる参考価格です（出典: IBM「WebSphere Hybrid Edition Pricing」、2026年8月確認）。

• 権利構成：表示には、1 VPCのNetwork Deployment、4 VPCのBase、8 VPCのLiberty Coreなどが含まれます。
• 契約条件：日本での期間や課金単位、サポート、為替、販売条件を確認し、年額や総額と決めつけないようにします。
• 見積内訳：ライセンス・保守、基盤、WAS・アプリ、DB・MQの費用を分けます。さらに、移行や試験、教育、管理、引き継ぎも別の項目にします。

費用の中心になりやすい人件費は、ノートの一般目安では開発費の60〜80％程度ですが、作業内容によって変わります。見積では、ロールや人月、単価、期間を確認します。

初期費用と分けた保守・クラウド・更新費

初期費用のほかに、保守の範囲と稼働後に続く費用も見積もります。

• 保守範囲：対応内容によって、費用は変わります。
• 保守費の仮説：初期開発費の年15〜25％程度を想定します。24時間365日の監視や緊急対応は、別のSLAで見積もります。
• クラウド等の費用：利用料やストレージ、転送、バックアップ、監視が発生します。コンテナ基盤やイメージ検査、商用サポートも発生します。

保守の範囲には、問い合わせや製品修正、Java・OS更新、脆弱性評価が含まれます。そのほか、Fix Packや障害解析、性能改善、監視、バックアップ、リリース支援もあります。

IBMのSOMPO事例では、Liberty移行後に100台超のサーバーと7環境を少人数で管理し、CPUコアを54％、メモリを33％削減したとされます（出典: IBM「SOMPO Holdings」、2025年掲載）。ただし、実際の結果は構成や条件で変わるため、自社の負荷試験で効果を確かめます。

WebSphereの委託先選定と見積比較のポイント

委託先には、IBM製品の経験に加えて、Java EE・Jakarta EEの経験があるかを確認します。既存解析やWAS管理、クラウド・Kubernetes、性能試験、運用引き継ぎの経験も見ておきます。

知名度や年数だけでなく、同業種や利用者数、連携数、停止制約が近い案件での担当実績を聞きます。

現行資産の診断から運用までの一貫した実績確認

委託先の提案力は、現行資産の調査から運用支援まで、具体的な事例で確かめます。

• 技術実績：診断例や互換性調査、Liberty・Open Liberty移行の判断、クラウド・OpenShift設計について質問します。
• 担当体制：提案担当だけでなく、設計・構築・移行・保守を担う技術者が参加するかを確かめます。
• 運用対応：監視や一次切り分け、ログ、復元について確認します。パッチ試験、夜間リリース、性能調査、受付時間も確かめます。

古いWASの構築経験がある会社でも、コンテナやCI/CD、脆弱性対応は別に確かめる必要があります。

IBMは、Libertyをコンテナ・KubernetesやCI/CDに適したランタイムと説明しています。

自社のパイプラインへ組み込めるかは、委託先の設計力にも左右されます（出典: IBM「WebSphere Hybrid Edition Pricing」、2026年8月確認）。

同じ項目と前提で揃えた見積の比較

提案を公平に比べるには、各社の作業範囲と見積条件をそろえる必要があります。

• 見積項目：同じRFPをもとに、ライセンス・保守、基盤、アプリ、DB・MQを揃えます。移行や試験、教育、PM、引継ぎも、同じ項目で並べます。
• 比較条件：金額や範囲、人数、期間、前提・除外を並べます。成果物、検収、追加単価、保守開始日も、そろえて示してもらいます。

A社は移行を含み、B社は移行が別料金だとすると、総額の数字は条件がそろわないまま並びます。そのため、価格や要件適合、実績、体制を評価します。さらに、移行・試験、セキュリティ、運用、契約も評価の対象に加えます。

安くても、調査や受入支援が除外されていれば、追加費用と社内の負担が生じます。一方で、高額な提案にも、不要な改修や過剰な冗長化が含まれる場合があります。

説明会では、見積の前提と除外事項を一つずつ確かめます。

候補会社への質問による提案力の見極め

候補会社には、互換性の確認や試験をどう進めるかを尋ねます。

• 互換性・改修：8.5.5から9.0.5への調査や、Liberty移行時の改修判断について質問します。
• 試験・障害対応：JNDIやJMS、証明書、バッチ、データ照合について、本番障害の一次対応まで尋ねます。

手順や成果物、判定基準を説明できる会社は、見積の根拠も示しやすい傾向があります。

事例では、アプリ・サーバー数や同時接続、停止時間、移行方式を聞きます。試験期間や体制、稼働後の改善も、あわせて聞いておきます。

社名や金額を出せなくても、規模と課題を説明できるかを確認します。

担当者の継続や変更承認者、引き継ぎ期間も、提案書に記載してもらいます。

発注後の移行・テスト・運用引き継ぎの管理

受託者に任せきりにすると、要件の漏れや移行データの不備を見逃したまま本番を迎えるおそれがあります。

そこで、週次会議で課題やリスク、変更を確認します。品質や予算、次の判断も同じ会議で扱い、業務責任者が意思決定を止めない体制にします。

移行テストの照合範囲（件数・金額・連携結果）

発注後の品質は、機能・性能・移行データをそれぞれ検証して確かめます。

• 機能・連携：WAS切替やDB・MQ、認証、帳票を試します。バッチやAPI、監視、バックアップも確かめます。
• 性能試験：ピーク接続や処理待ち、メモリ、GC、CPU、DB・MQの滞留を確認します。
• Liberty・コンテナ：ログ・設定の外部化や再起動、スケール、配備手順も検証します。
• データ照合：件数や売上・請求の合計、日時、文字コードを突き合わせます。重複や欠損、状態、マスタ、再送、監査証跡も確認します。

移行は複数回のリハーサルで確かめ、停止可能時間内に移行できるか、失敗時に戻す地点を決めます。

切り戻しの判断者と期限も、計画に記載します。

運用設計と引き継ぎの検収条件

稼働後の分担と、発注者が運用を引き継ぐための確認事項を、先に整理しておきます。

• 運用分担：アプリの配備やWAS・OSパッチ、証明書更新の担当を決めます。ログの保存期間も決めておきます。
• 管理設計：管理コンソールは公開網から分け、最小権限やMFA、監査ログ、緊急アカウントを設計します。
• 引き継ぎ演習：障害の再現やログ確認、バックアップ復元、検証環境へのパッチ適用を行います。

IPAのTLS暗号設定ガイドラインは2025年4月に更新されています（出典: IPA「TLS暗号設定ガイドライン」、2025年4月25日更新）。TLS終端、暗号スイート、証明書更新も、現行の指針に合わせます。

手順書や監視一覧、連絡網を引き渡し、既知の問題やライセンス、アカウント管理も含めます。

発注側が自力で日常運用できることを、検収条件にします。

WebSphereのシステム発注でよくある質問

外注では、製品の将来性や移行、費用、ソースコードについて質問が集まりやすい傾向です。

判断の根拠は、提案書と契約書に残しておきます。

WebSphereは古い製品なので新規発注しない方がよいですか？

Java EE資産や運用実績、連携、可用性を活かせるなら、traditional WASを更新しながら使う方法があります。

製品の古さより、用途を基準に考えます。

新規開発やコンテナ化の場合は、Liberty・Open Libertyも比べます。そのうえで、IBMのサポートやJava・OSのライフサイクル、商用サポートを確認します。

WebSphereのライセンス価格だけで発注費用を判断できますか？

ライセンス価格は、発注費用の一部にすぎません。基盤やアプリ改修、連携、データ移行も発生します。さらに、性能・障害・セキュリティ試験や教育、保守も費用になります。

公式価格は参考表示で、条件によって変わります。そのため、同じRFP条件で内訳付きの見積を取り、初期費用と継続費用を分けて比べます。

WebSphereの移行にソースコードは必要ですか？

ソースと設定があれば、互換性の調査と改修範囲を見積もりやすくなります。なくても、実機調査やバイナリ解析で進められる場合があります。

ただし、独自ライブラリやJNDI・JMS、証明書、バッチ、外部連携は把握しにくくなります。そのため、ソースや設定、ビルド手順、テストデータ、運用資料の所在と利用権を確認します。

WebSphereの外注契約で特に確認することは何ですか？

成果物や検収、変更、知的財産、再委託を確認します。

セキュリティや脆弱性、データ返却・消去、保守SLA、障害責任も、あわせて確かめます。

WASやアプリ、DB、MQの範囲を、構成図に示します。ネットワークやクラウド、監視も同じ図に入れます。発注者のレビュー、データ提供、受入、リリース判断の期限も明記します。

WebSphereのシステム発注・外注方法まとめ

発注先は、製品名やライセンス価格より先に、現行の資産から考えます。WASやJavaアプリ、DB、MQを洗い出し、認証や監視、バックアップ、外部連携も含めます。

継続利用やLiberty、Open Liberty、クラウド、コンテナを比べたうえで、RFPに条件を整理します。業務目的や非機能要件、データ、試験、停止時間、運用も書き込みます。

複数社から同じ条件で提案を受け、診断や要件整理は準委任、確定した開発は請負など、工程に応じて契約します。

診断、開発、移行、基盤、ライセンス、保守を分けて見積もり、前提と除外を確認します。委託先は、診断から運用までの同規模の実績で選びます。

ソースや設定、IaC、試験結果、運用資料の引き渡しと、脆弱性・パッチ対応を契約に残します。比較の条件をそろえておけば、過度なカスタマイズや予期しない追加費用を抑えられ、将来も運用しやすくなります。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【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を創業。