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

IBM Cloudのシステム発注は、業務要件と責任の範囲を整理し、RFPで複数社の提案を比べて進めます。工程に合った契約を選ぶと、費用と運用の負担を管理しやすくなります。

発注前の要件整理から委託先の選び方まで、発注の流れに沿って説明します。

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

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

IBM Cloudのシステム発注・外注の全体像

発注では、作る範囲と責任の分担を先に切り分けます。アプリ開発、基盤設計・構築、移行後の監視や障害対応のどこまでを委託するかで、必要な経験と契約条件が変わります。

IBM Cloudのシステムの構成要素

IBM Cloudのシステムは、業務機能を支える基盤に、アクセスと記録、既存資産との連携を組み合わせて作ります。

• 基盤と業務機能：アプリとDBに、ネットワークや認証を組み合わせた構成。
• アクセスと記録：ログや監査記録を別に管理する構成もあります。
• 既存資産との連携：現行環境と将来の運用体制を踏まえたサービス選び。
• 基盤候補：VPC、Power Virtual Server、Red Hat OpenShift on IBM Cloud。
• 連携候補：IBM API ConnectやMQも選択肢に入ります。

構成の一例では、WAFやAPI Gatewayでアクセスを受け、VPC内のアプリからマネージドデータベースやObject Storageへ接続します。

SAP、AS/400、Power系資産、社内ERP、工場システムなどの既存資産があると、単純なサーバー移転より、データ連携と業務変更の設計が重要になります。

発注形態の種類と使い分け

発注形態は、成果物をまとめて任せる請負、専門人材と協働する準委任、基盤や運用を任せるマネージドサービスの三つに分けて考えます。

• 請負：要件と成果物を明確にできる範囲で使う形です。
• 準委任：要件の検証や継続的な改善を進める場合に使います。
• マネージドサービス：基盤や運用を継続して任せられる形です。

ERP移行では、構想と現状調査を準委任で始め、移行設計と構築は請負や段階契約に分ける方法があります。

業務部門の判断が多い案件は、一括請負で頼むと、仕様変更のたびに追加費用が生じやすくなります。

運用監視を人月だけで依頼すると、対応範囲や品質基準が曖昧になりやすいため、SLAや月次報告の内容まで定めておきます。

発注前に決めるべき要件とRFPの作り方

RFPは、同じ前提で提案と見積を比べるための基準になります。そのため、目的、対象範囲、制約、受け入れ条件は、発注者側で先に整理しておきます。

IBM Cloudの利用を先に決めると、高機能すぎる構成や、運用で使い切れないサービスが提案に含まれることがあります。

業務目的と対象範囲の整理

導入目的は、業務上の目標に置き換えて文書にします。

• 業務目標：月次決算を早める日数や、API追加に要する営業日。
• 発注範囲：販売、会計、生産、顧客管理、分析のなかから、対象業務を切り分けた範囲。
• 利用・復旧条件：利用者数、ピーク時の処理量、停止時間、保存年限など。

今回の発注範囲と将来対応する範囲は分けて記載し、個人情報や決済情報の有無も確認します。

RTOは復旧目標時間、RPOは復旧時点の目標です。そのうえで、「4時間以内に復旧し、直近1時間分を超えるデータを失わない」のように、条件まで示します。

IBM Cloudとセキュリティの要件

RFPには、リージョンや冗長化、バックアップ・DR環境の条件を書いておきます。そのうえで、提案側に任せる判断と、発注者が指定する条件を分けておきます。

• クラウド構成：リージョン、ゾーン、バックアップ、DRの条件。
• サービス選定：アプリ、DB、ストレージ、ネットワーク、監視などの提案を求める対象。
• セキュリティ：IAM権限、特権ID記録、通信・保存データとバックアップの暗号化、Key Protect、監査、障害連絡を指定します。

具体的には、東京または大阪のリージョンを使うか、複数ゾーンで冗長化するか、別リージョンにバックアップやDR環境を置くかを確認します。

IBM CloudではSOCやPCIなどの情報を確認できます。ただし、認証だけで自社の要件を満たすとは限らないため、データ分類と委託先の責任も明記します。さらに、脆弱性対応の手順もRFPに具体的に記載します。

移行・受け入れ条件と発注者の役割

クラウド移行では、サーバーを動かすことより、マスタや履歴データを整える作業が難しい場合があります。そのため、品質確認の責任者は発注者側で決めておきます。

• データ品質：重複、欠損、コード、表記ゆれ、保存範囲の整理。
• 受け入れ条件：機能、性能、復旧、権限、監査、バックアップを含む条件。
• 納品物：基本・詳細設計書、構成図、IaCやスクリプト、テスト結果、ソースなどの指定。

整理の対象は、顧客、商品、取引先、勘定科目、組織などのデータです。

移行リハーサルについても、回数と判定基準をRFPに入れておきます。

受け入れ条件には、運用手順と教育資料も含めます。納品物には、詳細設計書、操作手順、アカウント情報も指定します。納品物を明確にしておくと、契約後の移行や他社への引き継ぎがしやすくなります。

IBM Cloudのシステム開発を外注する進め方

基盤、アプリ、データ、運用は互いに連動するため、短い構想確認を挟むと、総額と納期を管理しやすくなります。判断の根拠は、次の手順ごとに残しておきます。

構想整理と委託先候補の選定

まず、現行システムや業務フロー、データ連携、契約時期、障害履歴、運用体制を整理します。そのうえで、候補会社には、構成の理由と利用量増加への対応を説明してもらいます。

• 候補数：候補会社は2〜4社程度に絞ります。
• 比較方法：RFP回答、提案会、技術者面談、実績確認を、同じ順で行う方法。
• 得意領域：IBM Cloud全般、API・金融、OpenShift、業務アプリなどの領域。

日本IBMのように周辺サービスも扱う会社や、API連携・金融、OpenShift・ハイブリッドクラウドに強い会社があります。業務アプリ開発会社も候補になります。

2025年のIBMパートナー・プラス・アワードでは、CTC、MONO-X、エクサ、NECなどが、日本の部門別受賞企業として発表されました（出典: 日本IBM「2025 IBMパートナー・プラス・アワードの日本での受賞企業を発表」、2025年）。

表彰は候補を探す材料にはなりますが、自社と同規模の実績を示すものではありません。そのため、案件ごとに実装経験を確認します。

要件定義・設計・開発の段階的な進め方

要件定義では、業務要件と非機能要件を分けて合意しておきます。

• 業務要件：画面、帳票、承認、計算、連携などの機能。
• 非機能要件：可用性、性能、セキュリティ、バックアップ、監視などの条件。
• 導入段階：PoCで性能や復旧を確かめてから、対象を広げる進め方。

まず、環境の分離、ネットワーク、権限を決めておきます。そのほか、ログ保管先や障害通知先、拡張性、運用時間も決めます。

大規模ERPであっても、一括切替が必須とは限りません。小規模APIや社内業務でPoCを行い、運用引き継ぎを確認する進め方もあります。

段階導入では、二重入力やデータ連携の責任、並行稼働期間、切戻し条件が増えます。そのため、終了条件を契約書と計画書に記載しておきます。

テスト・移行・リリース後の運用の確認

本番移行の条件は、受け入れテストと移行リハーサルで確かめます。

• 受け入れテスト：負荷、通信断、DB障害、復元、権限、監査ログの確認。
• 移行リハーサル：切替手順を実際に動かせるかを確かめる作業。
• リリース後：監視、問い合わせ、修正、利用者対応の責任の分担。

テストは、発注者と受託会社のどちらが担当するかを決めておきます。

東京精密は、SAP S/4HANAで基幹を刷新し、IBM Cloudのマネージドサービスへ、基盤からSAPのBASIS運用までを委託しました。DR構成では、東京とオーストラリアのデータセンターを使っています（出典: IBM「株式会社東京精密 事例紹介」）。

自社でも外部に委託する運用範囲を決めておくと、導入後に自社で担う負担が明確になります。

IBM Cloudの外注で選ぶ契約形態

契約形態は、仕様変更、品質、納期、知的財産、障害対応について、リスクをどう分担するかで選びます。「固定価格なら安心」と考えてしまうと、要件の抜けが追加契約になる場合があります。

準委任でも、作業時間だけでなく、成果物、会議体、報告、体制を合意しておく必要があります。

準委任契約が向く場合

準委任契約では、受託会社が専門的な役務を提供し、稼働時間や体制を基準に精算します。

• 適する業務：構想、調査、要件定義、移行計画、運用設計などの業務。
• 契約で定めること：月次報告、課題、翌月計画、人員、成果物レビュー。
• 発注者の体制：意思決定者と業務担当者を置き、回答やマスタ整備を担う体制。

準委任は、完成したシステムの結果を保証する契約とは限りません。そのため、要件定義や設計レビューの完了条件と、次工程の判断者を定めておきます。

成果物と仕様を確定できる場合の請負契約

請負は、合意した成果物を完成させて納品・検収する契約です。受け入れ条件を具体的に決められる部分が、請負に向く部分です。

• 成果物：API仕様、画面、帳票、移行ツール、監視設定など。
• 検収条件：性能値、対応ブラウザ、処理件数、エラー時の動作を示すこと。
• 権利と費用：成果物の保有者と、クラウドなどの別費用。

検収基準を「問題なく使えること」とすると、不具合と仕様変更を区別しにくくなります。

なお、IBM Cloud利用料、第三者ライセンス、転送量、追加ゾーン、DR環境は、請負費と別に発生する場合があります。受託会社とIBMへの支払額は分けたうえで、価格改定や為替の扱いも確認します。ソースコード、設計書、Terraform、アカウントやログの権限を、誰が持つかも契約に明記します。

段階契約とマネージド運用の組み合わせ

各工程の成果物、次工程へ進む条件、変更管理の手順、未達時の扱いは、基本契約と個別契約に分けて定めます。

• 契約の分け方：構想・要件定義は準委任、開発・移行は請負、運用は月額契約という組み合わせ。
• 運用条件：監視、営業時間、一次・二次対応、通知時間、復旧目標。
• 時間外対応：24時間365日の夜間休日体制、緊急変更、エスカレーションの確認。

24時間365日対応は、通常時間帯の運用費だけで判断せず、緊急変更の承認手順やIBMなどへの連絡経路も確かめます。

大規模案件では、基盤、アプリ、移行、運用を別契約にすると、どこまでを誰が受け持つかが見えやすくなります。

マネージド運用では、一次・二次対応や障害の重大度、月次報告を含めます。定例会、パッチ適用、バックアップ検証も入れます。

IBM Cloudのシステム開発費用相場と内訳

費用は、クラウドの従量課金と、開発・移行・運用の委託費を合わせて考えます。

以下の金額は、IBM Cloud固有の一式価格ではなく、業務システムの相場と想定構成をもとにした、2025〜2026年向けの編集用の目安です。金額は、リージョンと契約によって変わります。ほかに、次の条件でも変わります。

• 割引：契約ごとの条件で、金額が変わります。
• ライセンス：製品費用を含むかどうかで、比較の結果が変わります。
• 冗長化：複数ゾーンにするか、別リージョンを使うかで、基盤費が変わります。
• 転送量：通信量の見込みで、月額が変わります。
• 24時間運用：夜間休日の体制を含むかで、運用費が変わります。

金額が条件によって変わるため、発注時は個別見積を取ります。

規模別の初期開発・移行費用の目安

各金額は推定のレンジです。製品ライセンスや業務改革費を含むかどうかで、比較の結果が変わります。

小規模なAPI、PoC、社内業務アプリの期間は2〜4か月程度です。規模が大きくなるほど、費用の幅も広がります。

• 小規模：API、PoC、社内アプリは初期300万〜1,000万円程度です。
• 中規模：高可用性の連携・顧客・販売管理は1,000万〜5,000万円程度です。
• 基幹刷新：SAPやERPなどは3,000万〜3億円以上の場合があります。
• 高い可用性・運用：金融・医療では初期5,000万円〜数億円以上の場合があります。

中規模のAPI連携・顧客管理・販売管理は4〜10か月程度で、費用は機能数、データ品質、連携数、テスト範囲によって変動します。

基幹刷新は、9か月から数年に及ぶ場合があります。また、高可用性、DR、監査対応、24時間運用を組み合わせる場合、基盤・運用費は月額200万〜1,500万円超のケースがあります。

見積書の工程と工数の分解

初期費用は工程別に分けると比べやすくなります。ただし、比率は案件によって変わります。

クラウド費用には、仮想サーバーやベアメタルのほか、Power Virtual Server、OpenShift、DB、Object Storageも含まれます。

バックアップ、監視、ログ、ネットワーク、ライセンスも費用項目になります。そのため、公開単価だけで月額総額を断定せず、利用量と契約条件を含めて試算します。

• 要件定義：初期費用の10〜15%程度を占めます。
• 設計・製造：設計25〜35%、製造30〜40%程度。
• テスト・移行：テスト15〜20%、移行・教育5〜10%程度。

担当者の役割と人日、単価を確認します。期間や前提、除外事項も、見積書で確かめます。

要件定義の費用を低く見せ、後工程や追加変更で費用を回収する見積もりもあります。

IBM Cloudの公開情報では、2025年4月にVPC仮想サーバーのWindows Standardライセンスが改定されました。vCPU時間あたり0.046ドルから0.051ドルへの改定です。

東京・大阪のIaaSロケーションプレミアムは20%です（出典: IBM Cloud Docs「IBM Cloud 価格の更新と調整」、2025年）。

月額費用とTCOの確認

基盤費は、構成や規模によって変わります。個別見積では、利用条件をそろえて比べます。

• 基盤費：小規模は月5万〜30万円、中規模は月30万〜150万円程度という推定。
• 高機能構成：月100万〜1,000万円超。金融・医療系では月200万〜1,500万円超の場合があります。
• 費用が上がる要因：SAP、OpenShift、Power Virtual Server、専用NW、SIEM、DR、24時間運用。
• 保守・改善：初期開発費の年15〜20%が、一つの基準になります。

確認する項目は、サーバー数、vCPU、ストレージ、転送量、バックアップ世代数です。たとえば、初期費用が3,000万円なら、保守費は年450万〜600万円、月37万〜50万円程度になります。

保守費は、24時間監視、アプリ改修、ライセンス更新、セキュリティ対応を含むかどうかで変わります。そのうえで、3〜5年のTCOを作成します。

TCOには、通信、監視、バックアップ、障害対応、契約終了時の移行費も含めます。初期費用だけでは、総額は判断できません。

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

会社の知名度やIBMのロゴだけでなく、担当チームが課題を理解し、設計から運用まで説明できるかで選びます。

VPC構築の経験と、SAP、Power、OpenShift、API連携を含む業務システムの経験では、対応範囲が異なります。そのため、類似案件の構成、期間、移行件数、運用体制、障害対応を質問します。

サービス単位での実装実績の確認

「IBM Cloudに対応できる」という説明だけでなく、担当したサービスと責任範囲を確かめます。

• 基盤：VPCのネットワーク設計を担当したか。
• 業務基盤：Power Virtual Server上のSAPやOpenShiftを扱ったか。
• 連携・運用：API Connect、DataPower、Db2やマネージドDB、監視、バックアップの担当経験。

あいおいニッセイ同和損保は、IBM Cloud上のAPI ConnectやDataPowerによるAPI連携基盤を5か月で導入しています（出典: IBM「あいおいニッセイ同和損害保険株式会社 事例紹介」）。

期間と構成は、自社案件の前提と照らして確かめます。

設計・移行担当のエンジニアが提案会に参加するかを確認します。営業担当だけで提案し、契約後に別チームへ引き継ぐ場合は、回答内容と体制図を記録しておきます。

発注側では、再委託の有無と所在地を確認します。ほかに、個人情報へアクセスする担当者、障害時の責任者、プロジェクトマネージャーの稼働率も確認します。

見積書の前提・含まれない費用・変更条件の比較

総額の安さを見る前に、同じ範囲を見積もっているかを確かめます。工程ごとに、含む作業と含まない作業を明らかにしておきます。

• 開発工程：要件定義、設計、開発、移行、テスト、教育、リリース支援、保守。
• 基盤関連：アカウント、回線、ライセンス、クラウド利用料、バックアップ、監視。
• 追加費用：脆弱性診断や第三者製品が見積に含まれるか。

工数の根拠が「一式」の場合は、画面とAPIの数に分解してもらいます。そのほか、連携先とデータ件数の数を示してもらい、移行リハーサル、テストケース、会議、文書の数も示してもらいます。

仕様凍結後の変更手順、追加単価、納期への影響、発注者の回答遅延の扱いを契約前に確認しておくと、予算超過を防ぎやすくなります。

データ所在と契約終了時のリスクの確認

個人情報を扱うシステムでは、データの保存場所、バックアップの場所、運用担当者のアクセス場所、再委託先の所在地を確認します。

個人情報保護委員会の「外国にある第三者への提供編」は、令和7年12月に一部改正されました。

• データ所在：データ、バックアップ、運用アクセス、再委託先の所在。
• 契約終了時：返却期間、削除証明、移行単価、クラウド契約名義の取り決め。
• 移行可能性：ソース、IaC、設計書、アカウントなどの扱い。

東京・大阪リージョンを使う場合でも、DR、サポート、ログ保管が別地域になることがあります。そのため、データフロー図で所在を確認します。

返却対象ごとに形式を定め、ログと暗号鍵の返却方法も契約に明記します。

同ガイドラインは、外国の第三者、委託先の監督、安全管理、外国第三者への提供の制限などを扱っています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（外国にある第三者への提供編）」）。法務・情報セキュリティ部門と確認します。

委託先の運用アカウントにしかアクセスできない状態や、独自スクリプトの説明がない状態は、別会社への移行を難しくします。

よくある質問

発注前によくある疑問を取り上げます。答えは、自社の規模や既存資産によって変わります。ただし、判断の順序を決めておくと、提案を比べやすくなります。

IBM Cloudのシステムは小規模な会社でも外注できますか？

外注できます。小規模なAPIや社内業務アプリ、PoCであれば、サービスと運用範囲を絞り、2〜4か月程度の段階導入を検討できます。

OpenShiftやDRを最初からすべて加えず、処理量、データの重要度、復旧目標に合う構成を選びます。そのうえで、将来拡張できる設計かどうかを委託先に確認します。

AWSやAzureではなくIBM Cloudを選ぶべきですか？

SAPやPower系資産、IBM製品、API連携、ハイブリッド構成、特定の運用要件がある場合は、IBM Cloudが候補になりやすいです。

ブランドだけで決めず、サービス提供状況や国内リージョン、料金に加えて、社内人材、委託先実績、契約終了時の移行性も、AWSやAzureと同じ条件で比べます。RFPに比較項目を入れておくと、採用理由を説明しやすくなります。

IBM Cloudのシステム開発費用はどのように見積もればよいですか？

初期開発・移行費と、IBM Cloudの月額基盤費は分けて見積もります。ほかに、次の費用も分けて扱います。

• ライセンス：製品の費用が、開発費とは別に生じる場合があります。
• 保守・改善：初期開発費の年15〜20%が、一つの基準になります。
• バックアップ：世代数で、月額が変わります。
• DR：別地域の環境を含むかで、基盤費が変わります。
• 24時間運用：夜間休日の体制を含むかで、運用費が変わります。

小規模なAPIやPoCは初期300万〜1,000万円程度、中規模の業務システムは1,000万〜5,000万円程度が、一つの推定レンジです。ただし、個別見積の代わりにはなりません。

複数社に依頼する際は、サーバー数、利用量、連携数、移行件数、監視時間、契約期間をそろえます。

RFPを作れない状態でも委託先へ相談できますか？

相談できます。現行業務、課題、対象データ、希望時期、予算上限、社内体制をまとめた簡易資料を渡せば、現状調査や構想策定から支援を受けられます。

相談時の提案は、そのまま最終仕様にはせず、複数社の調査結果を比べてからRFPや要件定義書を確定します。意思決定者と業務担当者も、早めに決めておきます。

まとめ

発注前の業務要件と責任範囲の整理

発注前には、業務目的とデータ所在を先に整理します。ほかに、次の項目も整理しておきます。

• RTO・RPO：復旧までの時間と、復旧時点の目標。
• 既存資産：SAPや社内ERPなど、現在使っている資産。
• 運用体制：運用を誰が担うか。
• 契約終了時の移行性：別の会社へ移せるかどうか。

会社の知名度やサービス名は、条件を整理したあとで比べます。

小規模APIやPoCなら段階導入を選び、SAPや基幹刷新では、業務改革、データ移行、DR、マネージド運用まで含む計画を作ります。

契約と見積の工程・費用・移行性の比較

RFPで範囲と受け入れ条件を示し、準委任、請負、マネージド運用を工程ごとに使い分けます。

費用は、開発費と利用料を分けて、2〜4社程度で比べます。ほかに、次の項目も各社で同じ範囲にそろえます。

• ライセンス：製品の利用料を含めるかどうか。
• 移行：作業範囲と費用の扱い。
• 保守：対応内容と、費用に含むかどうか。
• 監視・バックアップ：運用の範囲に含まれるかどうか。
• DR：災害時の復旧環境を含むかどうか。

マスタ整備、仕様凍結、切戻し、ソースコードと設計書、再委託、データ返却を契約に定めると、予算超過やベンダーロックインを防ぎやすくなります。

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

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