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

WebSphereのシステムを発注・外注するなら、WASのライセンスやサーバー構築だけでなく、Javaアプリケーション、データベース、MQ、認証、移行、テスト、保守までを含めて委託範囲を定義することが重要です。

WebSphereは業務パッケージではなく、企業向けJavaアプリケーションを動かす実行基盤です。そのため、発注形態の選択、RFPと要件整理、準委任・請負の使い分け、費用相場、委託先の評価、見積比較の方法を順番に整理しなければ、契約後に追加費用や責任分界の曖昧さが生じやすくなります。本記事では、既存WASの継続利用からLibertyやクラウドへの移行まで、発注前に確認すべき実務を解説します。

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

WebSphereのシステムを発注する前に全体像を整理します

WebSphereのシステムとは、IBM WebSphere Application Serverを中心に、Javaで作られた業務アプリケーションとデータベース、外部連携、利用者認証、監視などを組み合わせた企業向けシステムです。IBMはWASを、オンプレミス、VM、コンテナ、クラウド、ハイブリッド環境でミッションクリティカルなJavaアプリケーションを実行するランタイム環境と説明しています（出典: IBM「WebSphere Application Server」、2026年8月確認）。発注時は、WASそのものと、その上で動く業務機能を分けて考えることが出発点です。

販売管理、顧客管理、契約管理などの画面や業務ルールは、WAS上に配備されるWAR・EAR形式などのJavaアプリケーションに実装されます。WASはトランザクション処理、接続プール、セッション管理、認証・認可、TLS、アプリケーション配備、クラスター運用などを支える役割です。したがって「WebSphereを導入する」という依頼でも、実際には業務アプリの新規開発、既存アプリの改修、DBやIBM MQとの接続、帳票やバッチの移行まで必要になる場合があります。

発注書やRFPに「WAS構築一式」とだけ書くと、アプリのソースコード解析、JNDI設定、証明書、外部API、夜間バッチ、障害時の切り戻しが見積対象から外れるおそれがあります。現行システムを継続利用する場合でも、バージョン、Java SDK、アプリ数、連携先、利用者数、ピーク時の負荷を一覧にしてから委託範囲を決めます。

既存のJava EEアプリケーションを大きく変えずに動かしたい場合は、WebSphere Application Server traditionalの継続利用やバージョン更新が候補になります。クラスター、集中管理、高可用性が必要な大規模環境ではNetwork Deploymentを検討し、単一サーバーに近い構成ではBaseを検討します。新しい開発やコンテナ化、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の発注形態はどれを選びますか？

WebSphereの発注形態は、メーカーや販売パートナーへの一括委託、総合SIerへのプライム発注、要件整理と構築を分ける分離発注の3つに整理できます。どれが正解というものではなく、発注者側にWASと業務の知識がどの程度あるか、既存資産がどれだけ複雑か、停止できる時間がどれだけあるかで適した形が変わります。

WASの設計、Javaアプリの開発、DBやネットワークの構築、移行、テスト、運用引き継ぎまでを一社にまとめる方法です。責任の所在や問い合わせ窓口を一本化しやすく、WebSphereに詳しい担当者が少ない企業や、既存システムの資料が不足している企業に向いています。特に金融、保険、公共などで高可用性、監査、24時間365日運用を求める場合は、類似規模の実績を持つ総合SIerを候補にします。

一方で、一社の提案だけでは価格や設計の妥当性を判断しにくくなります。契約前に、WASのライセンス・基盤費、アプリ改修費、データ移行費、テスト費、保守費を分けた見積を求めます。また、再委託の有無、担当技術者の経験、ソースコードやIaC、運用手順書の引渡し範囲を確認し、ベンダーロックインを防ぎます。

自社で業務要件を整理しにくい場合は、まず独立したコンサルタントやPMOに現状分析とRFP作成を委託し、その後に複数社から構築提案を受ける方法があります。第三者が要件と見積の前提を整えるため、各社の提案を同じ条件で比較しやすくなります。特定ベンダーに有利な要件にならないよう、RFPではtraditional WAS、Liberty、Open Liberty、IaaS、コンテナなどの選択肢を限定しすぎないことが大切です。

ただし、分離発注では障害時に原因が基盤、アプリ、ネットワーク、DB、MQのどこにあるかを切り分ける責任が分かれます。設計段階で、プライム責任者、各社の担当範囲、統合テストの主催者、リリース判定者、障害時の連絡順を体制図に落とし込みます。分離することで安くなると決めつけず、調整会議や統合管理の工数も予算に含めます。

現行WASの設定やアプリの依存関係が分からない場合は、最初から本開発を一括発注せず、4〜8週間程度の現状診断・移行アセスメントを先に発注する方法が有効です。アプリ一覧、Javaバージョン、API、JNDI、JMS、証明書、外部連携、性能、脆弱性、運用手順を調べ、継続利用とLiberty移行の候補を比較します。診断成果物を次工程のRFPや見積の前提にできるため、後から「想定外のアプリが見つかった」というリスクを抑えられます。

RFPと要件整理では何を決めますか？

RFPは、委託先に同じ条件で提案と見積を出してもらうための依頼書です。WASのバージョンだけでなく、業務の目的、対象範囲、現行資産、データ、外部連携、非機能要件、希望時期、予算、検収条件を記載します。要件を細かく書けない場合でも、分からない項目を空欄にせず「現状調査で確認する項目」として明示すると、各社が調査工数を見積に反映しやすくなります。

「古いWASを新しくしたい」だけでは、発注先が成果を判断できません。受注登録から出荷、請求までのどこを対象にするのか、利用部門と拠点はいくつか、同時利用者数とピーク時間帯はどれくらいか、停止できる時間は何時間かを整理します。応答時間、月間処理件数、障害復旧時間、データ移行の許容差など、測定できる目標を置くと、提案と受入テストの基準が一致します。

業務アプリを新規開発するのか、既存アプリを移行するのか、パッケージをWAS上で稼働させるのかも明示します。業務機能の新規開発を含むなら、画面、帳票、バッチ、権限、承認、監査証跡、例外処理を対象にします。基盤移行だけなら、アプリの変更範囲、互換性検証、性能回帰、切り戻しを対象にします。ここを分けるだけで、見積の比較可能性が大きく高まります。

技術面では、WASのエディションとバージョン、Fix Pack、Java SDK、OS、サーバー台数、クラスター構成、デプロイ単位、設定ファイルの保管場所を記載します。アプリごとにWAR・EAR、フレームワーク、古いJava EE API、独自ライブラリ、JNDI名、JMSキュー、データソース、証明書の有効期限を一覧化します。資料が存在しない場合は、リバースエンジニアリングや実機調査を見積の初期工程に含めます。

WASの外側にも、ロードバランサー、Webサーバー、DB、IBM MQ、認証基盤、ファイル連携、外部API、監視、バックアップ、ジョブ管理、ログ基盤があります。連携先ごとに、通信方式、認証方式、送受信データ、再送の条件、タイムアウト、障害時の責任者を記録します。JNDIやMQ、証明書の見落としは移行後の障害につながりやすいため、RFPに連携一覧を添付します。

WebSphereの発注では、機能要件より非機能要件が後回しになりやすい点に注意します。可用性、性能、拡張性、セキュリティ、バックアップ、災害対策、監視、運用時間、RTO・RPO、ログ保存期間、パッチ適用の停止手順をRFPに入れます。個人データを扱う場合は、アクセス制御、利用者の識別・認証、不正アクセス防止、委託先管理などを業務要件に落とし込みます。法令名だけを列挙せず、どの機能と運用で満たすかを確認します。

候補を一社に絞る前に、代表的な画面、重要トランザクション、外部連携、ピーク負荷、片系停止、DB停止、MQ滞留、認証失敗、証明書期限切れなどをPoCで検証します。正常系だけで動作確認を終えず、障害時にリトライやロールバックが成立するかを確かめます。PoCの実施費用と成果物、次工程で再利用できる設定やコードの扱いも、最初の契約で決めます。

WebSphere外注の契約形態と役割分担を決めます

WebSphere案件では、現状診断や要件整理のように作業内容が変わりやすい工程と、設計書、プログラム、テスト結果など成果物を合意しやすい工程が混在します。すべてを一つの契約にまとめるのではなく、工程ごとに契約形態、成果物、検収、変更手続きを決めると、追加費用と責任分界を管理しやすくなります。

準委任契約は、現状調査、要件定義、技術支援、PMO、運用改善など、専門家が一定の作業を遂行する工程に向いています。調査の結果によって次に必要な作業が変わるため、稼働時間、担当者、会議体、調査報告書などを定めます。請負契約は、合意した設計書、設定、プログラム、テスト成果物などを完成させ、検収する工程に向いています。

契約形態の名称だけで責任が決まるわけではありません。準委任でも何をいつまでに報告するかを決め、請負でも仕様変更や前提条件の変化をどう扱うかを決めます。要件が固まっていない段階で完成責任だけを求めたり、仕様が確定している開発を時間精算だけで進めたりすると、双方の認識がずれやすくなります。

成果物には、現状診断書、要件定義書、基本・詳細設計書、WAS設定、server.xml、IaC、ソースコード、テスト仕様書・結果、移行手順書、運用設計書、監視設定、教育資料を含めるか確認します。納品形式、リポジトリの場所、アカウントの所有者、引渡し時期も明記します。特に設定ファイルや自動化スクリプトが納品されないと、別の会社へ保守を切り替えるときに再現できないおそれがあります。

著作権、翻案権、第三者ライブラリのライセンス、既存資産の権利、秘密情報、再委託、脆弱性報告、データ返却・消去も確認します。追加開発の単価、変更要求の承認者、納期への影響、緊急変更の扱いを変更管理票に定めます。「一式」の見積を受けた場合は、何が固定で何が変動するかを契約書と見積条件に分けて書いてもらいます。

発注者は、業務上の優先順位を決め、現場のキーユーザーを選び、データの正しさを確認し、受入テストとリリース判断を行います。受託者は、技術調査、設計、構築、開発、テスト、移行支援、操作教育を担当します。DBやネットワーク、認証基盤を別会社が持つ場合は、受託者間の調整を誰が担うかを明記します。

個人データや機密情報を扱う場合は、開発環境へのデータ持ち出し、アクセス権、ログ、バックアップ、作業端末、リモート接続、脆弱性修正の責任を分けます。2026年3月にIBMが更新したCVE-2025-13333のセキュリティ bulletinでは、WebSphere Application Server 8.5と9.0が影響製品として示され、修正済みiFixやFix Packの適用が推奨されています（出典: IBM「Security Bulletin: CVE-2025-13333」、2026年3月9日更新）。保守契約には、脆弱性情報の通知、評価、検証、適用、緊急時の連絡時間を含めます。

WebSphereのシステム発注費用と相場を確認します

WebSphere案件に限定した国内の標準価格表は公開されていないため、ここで示す開発費は確定価格ではなく、業務システムの一般的な規模感とWebSphere特有の基盤・移行工数から置いた初期仮説です。ライセンス、クラウド利用料、機器、データ移行、24時間運用、税金を含むかどうかで総額は大きく変わります。見積を依頼するときは、下記のレンジを予算検討の起点に使い、同じ前提で正式見積を取得します。

現状診断・移行アセスメントは、アプリ一覧、依存関係、外部連携、性能、脆弱性、移行先候補を調べる範囲で、100万〜300万円、4〜8週間程度が初期仮説です。小規模なWAS環境構築と単純な業務アプリ1〜数本の開発は、開発・テスト環境、認証、監視、バックアップ、基本的なCI/CDまで含めると、300万〜700万円、3〜6か月程度が目安になります。いずれもライセンスやクラウド料金を除く想定です。

traditional WASからLibertyやコンテナへ再配置する案件は、アプリの互換性修正、server.xml、JNDI、JMS、証明書、ログ、性能・障害試験が増えるため、500万〜2,000万円、3〜9か月程度のレンジを置きます。複数業務・複数拠点の刷新は1,000万〜3,000万円、6〜12か月程度、金融・保険・公共などの大規模基幹システムは3,000万〜1.5億円以上、9〜24か月程度まで上振れする可能性があります。これらはノートに基づく推定レンジであり、案件の金額を断定するものではありません。

IBM WebSphere Hybrid Editionの公式価格ページには、Standard subscriptionが「Starting at USD 759.00」と表示されています。ただし、IBM自身が国、税、提供条件によって変わる参考価格と説明しており、1 VPCのNetwork Deployment、4 VPCのBase、8 VPCのLiberty Coreなどの権利構成を含む表示です（出典: IBM「WebSphere Hybrid Edition Pricing」、2026年8月確認）。日本での契約期間、課金単位、サポート範囲、為替、販売パートナー経由の条件は個別に確認し、この表示を年間総額やプロジェクト総額と断定しません。

見積は、ライセンス・保守、サーバーやクラウド、ネットワーク、WAS設計・構築、Javaアプリ開発・改修、DB・MQ連携、データ移行、テスト、教育、プロジェクト管理、運用引き継ぎに分けます。費用の中心は人件費になりやすく、ノートの一般的な目安では開発費の60〜80％程度を人件費として見ますが、作業内容によって変わります。各工程の担当ロールと人月、単価、期間を確認し、「一式」の内訳を明らかにします。

保守費は、問い合わせ対応だけでなく、IBM製品の修正情報、JavaやOSの更新、脆弱性評価、WASのFix Pack適用、障害解析、性能改善、監視設定、バックアップ確認、リリース支援をどこまで含むかで変わります。ノートでは初期開発費の年15〜25％程度を保守の初期仮説としていますが、これは契約内容によって変わる目安です。24時間365日の監視や緊急駆け付けを求める場合は、通常時間の保守と別のSLAで見積を分けます。

Libertyやクラウドを選んでも、クラウド利用料、ストレージ、転送量、バックアップ、監視、コンテナ基盤、イメージ検査、商用サポートがなくなるわけではありません。IBMのSOMPO事例では、WebSphere Libertyへのモダナイズ後に100台超のサーバーと7環境を少人数で管理し、CPUコア54％削減、メモリ使用量33％削減を実現したとされています（出典: IBM「SOMPO Holdings」、2025年掲載）。ただし、IBMも実際の結果は顧客の構成や条件で変わると記載しているため、自社の負荷試験で効果を確かめます。

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

委託先は、IBM製品を扱えるかだけでなく、Java EE・Jakarta EE、既存アプリ解析、WAS管理、クラウドやKubernetes、性能試験、運用引き継ぎを一つの案件で経験しているかを確認します。会社の知名度やWebSphereの導入年数だけでなく、現行環境と同じ業種、利用者数、連携数、停止制約を持つ案件の担当実績を聞くことが重要です。

候補会社には、現行WASの診断サンプル、互換性問題の洗い出し方法、LibertyやOpen Libertyへの移行判断、クラウド・OpenShiftの設計経験を質問します。提案担当者だけでなく、実際に設計・構築・移行・保守を担当する技術者が打ち合わせに参加するかも確認します。WebSphereの構築経験があっても、古いバージョンの単純なサーバー構築だけでは、現代のコンテナ化や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月に更新されているため、TLS終端、暗号スイート、証明書更新の手順も現行の指針に合わせて確認します（出典: IPA「TLS暗号設定ガイドライン」、2025年4月25日更新）。

運用引き継ぎは、資料を受け取るだけでは完了しません。受託者が障害を再現し、発注者がログを確認し、バックアップから復旧し、パッチを検証環境へ適用する演習を行います。手順書、監視一覧、連絡網、既知の問題、ライセンス情報、アカウントの管理方法を引き渡し、発注者が自力で日常運用できることを検収条件に含めます。

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

WebSphereの外注では、製品の将来性、移行の必要性、費用の含まれ方、ソースコードの扱いについて質問が集中します。契約前に疑問を解消し、判断の根拠を提案書と契約書へ残すことが重要です。

一律に避ける必要はありません。既存のJava EE資産、運用実績、連携、可用性要件を活かせる場合は、traditional WASを継続しながら計画的に更新する方法があります。新規開発やコンテナ化ではLibertyやOpen Libertyを含めて比較し、IBMのサポート状況、Java・OSのライフサイクル、必要な商用サポートを確認して決めます。

判断できません。ライセンスやサブスクリプションのほか、基盤、アプリ改修、外部連携、データ移行、性能・障害・セキュリティ試験、教育、保守が発生します。IBMの公式価格は参考表示であり、契約条件によって変わるため、RFPと同じ前提で委託先から内訳付きの見積を取り、初期費用とランニング費用を分けて比較します。

多くの場合、ソースコードと設定ファイルがあるほど、互換性調査と改修範囲の見積を正確にできます。ソースコードがなくても実機調査やバイナリ解析で進められる場合はありますが、独自ライブラリ、JNDI、JMS、証明書、バッチ、外部連携の依存関係を漏れなく把握しにくくなります。契約時にソースコード、設定、ビルド手順、テストデータ、運用資料の所在と利用権限を確認します。

成果物、検収、追加変更、知的財産、再委託、セキュリティ、脆弱性対応、データの返却・消去、保守SLA、障害時の責任分界を確認します。WASだけでなく、アプリ、DB、MQ、ネットワーク、クラウド、監視のどこまでが契約範囲かを構成図と一覧表で示します。発注者側のレビュー、データ提供、受入テスト、リリース判断の期限も明記すると、受託者だけに責任を押し付けない現実的な計画になります。

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

WebSphereのシステムを発注するときは、WASの製品名やライセンス価格だけで委託先を決めないことが重要です。まず、WAS、Javaアプリ、DB、MQ、認証、監視、バックアップ、外部連携を含む現行構成を棚卸しし、継続利用、Liberty、Open Liberty、クラウド、コンテナの選択肢を比較します。

次に、業務目的、対象範囲、非機能要件、移行データ、テスト、停止時間、運用体制をRFPに整理し、同じ条件で複数社から提案を受けます。現状診断や要件整理は準委任、仕様が固まった開発や成果物は請負など、工程に応じて契約を使い分けます。費用は診断、開発、移行、基盤、ライセンス、保守を分解し、前提と除外事項を確認します。

委託先は、WebSphereの経験年数だけでなく、同程度のJava資産、連携数、可用性要件を持つ案件で、診断から移行、テスト、運用引き継ぎまで担当できるかを見極めます。ソースコード、設定、IaC、テスト結果、運用資料の引渡しと、脆弱性・パッチ対応の責任も契約に残します。発注前に比較の軸を整えれば、過度なカスタマイズや予期しない追加費用を抑え、将来も運用できるWebSphereのシステムを実現しやすくなります。

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

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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