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

OpenShiftのシステム開発を発注するときは、範囲の整理、要件の数値化、工程ごとの契約と見積の比較の順に進めます。この順に進めると、責任分界が明確になり、投資判断につながります。

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

OpenShiftのシステムを発注・外注するときの全体像

OpenShiftシステムの外注範囲を企画・要件定義から運用保守まで4層に分けた図。
上流から稼働後まで、層ごとに担当を切り分けられます。

OpenShiftは、Kubernetesを中心とするエンタープライズ向けのアプリケーション基盤です。コンテナの実行に加えて、認証、ネットワーク、ストレージ、CI/CD、監視、セキュリティも扱うため、発注の前に担当範囲を広く見ておく必要があります。

クラスタ構築だけを発注する場合と、業務システムを移行・刷新する場合では、必要な会社や契約が異なります。さらに、開発、移行、運用のどこまでを頼むかによって、費用や納品物も変わります。

基盤構築と業務アプリ開発の分け方

基盤側と業務アプリ側では作業の中身が異なるため、分けて整理しておきます。

  • 基盤:Control Plane、Worker Node、レジストリ、ネットワーク、ストレージ、認証、監視、バックアップ、アップグレード設計
  • 業務アプリ:画面、API、バッチ、DB連携、外部接続、データ移行、利用部門の受入テスト

基盤会社に業務要件まで任せるか、アプリ会社と基盤専門会社を組み合わせるかで、RFPの書き方と管理の方法が変わります。

外注範囲の四つの層

外注範囲は四つの層に分けて考えると、誰が何を受け持つかを整理しやすくなります。

  • 企画・要件定義:社内で主導するほか、非機能要件や現行環境の調査を外注
  • OpenShift基盤:基盤の設計と構築
  • 業務アプリと移行:アプリの開発と既存データの移行
  • 運用保守:24時間365日の監視、障害時の一次切り分け、脆弱性対応、バージョンアップまで依頼するなら、運用体制を持つSI会社かマネージドサービス事業者と契約

発注側は、担当範囲を「一式」とせず、層ごとの成果物と窓口を示します。

ポイント

担当範囲は、基盤、業務アプリと移行、運用保守の層に分けて考えます。どの層を一社に任せ、どの層を別の会社に分けるかは、社内の技術者の数と運用の負荷で決めます。

OpenShiftのシステムに適した発注形態

企画・要件定義は発注者とパートナーが共同で進め、基盤構築とアプリ開発は工程ごとに契約します。運用保守を別契約か継続契約にしておくと、どこまでが範囲かを確認しやすくなります。

最初からすべてを一社に丸投げすると、比べられる単位がなくなり、費用や責任の分かれ目が見えにくくなります。そのため、発注形態は自社の技術者数、現行資産、納期、運用の負荷を基準に選びます。

一社への一括委託が向くケース

社内にクラウド、Kubernetes、ネットワーク、業務アプリの担当者がほとんどいない場合は、この形が合います。

  • 委託範囲:要件整理から構築、移行、運用の引き継ぎまで
  • 窓口:一本化でき、障害時の責任追及が複雑になりにくい
  • 納品物:設計書、Kubernetesマニフェスト、CI/CD定義、監視設定、テスト仕様書、運用手順書、ソースコード

一社に任せる場合でも、納品範囲は契約書に明記しておきます。特定の会社へ過度に依存しない状態を保つためです。

基盤会社とアプリ会社を分けるケース

既存アプリの知識を活かしたい場合は、基盤とアプリの委託先を分ける方法があります。

  • アプリ会社:既存業務アプリの改修とデータ移行
  • 基盤専門会社:OpenShiftの設計、構築、運用

分けて発注すると、技術を選ぶ自由度と比較の透明性が高まります。ただし、どこまでを誰が受け持つかが曖昧だと、通信設定、認証、ログ、障害の切り分けに隙間が生じます。

そこで、発注者が統合PMOを担うか、一社を全体統括に指定します。あわせて、インターフェースの一覧と課題の管理ルールも共通にします。

マネージドサービスを組み合わせるケース

マネージドサービスは、Control Planeの管理負担を抑えやすい選択肢です。

  • 候補:ROSA、Azure Red Hat OpenShift、OpenShift Dedicated
  • 費用:クラウドとOpenShiftの料金、ネットワーク、ストレージ、監視、バックアップ
  • 利用者側の責任:アプリの脆弱性修正、コンテナイメージ、DB、業務要件への対応

見積依頼書に責任分界表を添付し、監視の担当、連絡までの時間、復旧の条件を各社に確かめます。

ポイント

発注形態は、自社の技術者数、現行資産、納期、運用の負荷で選びます。会社を分けて発注するなら、責任の境界を先に決めておきます。

RFPと要件整理に書く内容

RFPに記載する業務要件、非機能要件、セキュリティと運用の責任分界、委託先管理を示すチェックリスト。
未確定の条件も分けておくと、提案の比較軸が揃います。

RFPには製品の指定だけでなく、業務上の目的と評価できる条件を書きます。発注側は、候補会社が同じ前提で提案できるよう、現行環境と対象業務を示し、利用者数やデータ量も共有します。

希望時期、予算区分、セキュリティ要件は、候補会社に同じ条件として伝えます。運用体制、納品物、提案書の形式も、条件として揃えておきます。

未確定の要件は、その旨を明記します。そのうえで、調査やPoCの見積に含めるかどうかを指定します。

業務要件と対象範囲の固定

業務要件と既存アプリの確認項目を先にそろえ、対象範囲を決めます。

  • 業務:対象部門、利用者の役割、業務フロー、画面・API・バッチ、外部連携、データ権限
  • アプリ:ソースコード、対応言語・ミドルウェア、OS依存、ローカルファイル、セッション管理、固定IP、夜間バッチ
  • データベース:種類と容量

現行資料が不足している場合は、RFPに現状調査を第一工程として記載します。調査の結果を見てから本開発の範囲を決める、二段階の発注にします。

非機能要件の数値化

OpenShift案件の品質と費用を左右するのは、CPUやメモリの量よりも非機能要件です。そのため、見積を比べられるよう、非機能要件は具体的な数値で示します。

  • 復旧と可用性:可用性、目標復旧時間RTO、目標復旧時点RPO
  • 性能と運用:ピーク時接続数、レスポンスタイム、ログ保持期間、バックアップ世代数、障害通知時間
  • 変更:リリース頻度、メンテナンス可能時間

「止まらない」のような書き方では、設計と見積を比べられません。平日日中に月間何分まで停止できるかを示し、障害発生から何時間以内に暫定復旧するかも書き加えると、比較の材料がそろいます。

セキュリティと運用の責任分界

RFPには、技術的な管理策と、委託先やサービスの確認事項を含めます。

  • 技術管理:認証方式、MFA、RBAC、NetworkPolicy、秘密情報の保管先
  • セキュリティ運用:イメージ検査、監査ログ、暗号化、バックアップ、復旧訓練、パッチ期限
  • 委託先管理:安全管理措置の事前確認、再委託の事前報告と承認、監査方法の決定
  • 公共・規制分野:クラウド、リージョン、保管場所、委託先の管理策をサービスごとに確認

個人情報保護委員会のガイドラインは、契約への必要事項の反映と取扱状況の把握を示しています(出典:個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」、2026年確認)。

また、デジタル庁は2026年3月にISMAPクラウドサービスリスト等を更新しています(出典:デジタル庁「ISMAPクラウドサービスリスト等を更新しました」、2026年)。調達の時点でリストを見て対象サービスを確かめ、掲載されていることと、自社システム全体が適合していることを分けて考えます。

ポイント

RFPには、業務要件と非機能要件を数値で書き、技術の管理策と委託先の確認事項も含めます。未確定の条件は、その旨を明記して候補会社に伝えます。

契約形態とOpenShiftのシステム費用相場

費用は、ライセンスやサービス料金だけでなく、クラスタやクラウドの料金も合算します。ネットワークやストレージの費用も加えます。

さらに、アプリ改修やデータ移行の費用を加えます。テストや教育、監視、保守の費用も含めて判断します。

完成の条件を決められる工程は請負が候補で、要件の変更が多い調査やアジャイル開発、運用支援は準委任が候補です。両者を組み合わせる方法もあります。契約名よりも、対価の対象と完成責任を負う人を確かめます。

請負と準委任の使い分け

工程ごとに、成果物と完成条件を定められるかどうかで、契約を使い分けます。

  • 請負:クラスタ構築や定型移行。成果物、受入条件、納期、検収方法を合意
  • 準委任:現状調査、要件定義、技術検証、アジャイル開発、継続運用

請負では、仕様変更や追加費用の扱いに加え、遅延や第三者製品の不具合が起きたときの扱いも定めます。

作業時間を投入することと、業務の成果を出すことは別です。そのため、成果の評価方法を決めるとともに、月次報告や稼働上限、交代要員、途中解約の条件も明確にします。

案件規模別の費用レンジ

OpenShift固有の初期費用には、公式の一律相場がありません。初期費用は、PoCから基幹刷新まで、案件の規模や作業範囲によって変わります。

  • 学習・PoC、軽微なコンテナ化:300万〜800万円
  • 中小規模:本番基盤と業務アプリ1〜3本で1,000万〜3,000万円
  • 基幹刷新など:モダナイズ、多クラスタ、多拠点移行で3,000万〜1億円超

この金額は、公式の定価ではなく、クラスタ設計、セキュリティ、CI/CD、アプリ改修の作業を含む概算です(出典:NotebookLMリサーチノート「OpenShiftのシステム」、2026年)。移行、テスト、運用設計も含みます。

AWS上でROSAを使う場合は、Worker NodeとHosted Control Planeの料金を分けて見積もります。

  • Worker Node:4vCPUあたり1時間0.171米ドル
  • Hosted Control Plane:クラスタあたり1時間0.25米ドル

料金はAWS公式の案内に基づきます(出典:Amazon Web Services「Red Hat OpenShift Service on AWS Pricing」、2026年確認)。

たとえば、月間730時間、4vCPU相当のWorkerを3つ置く場合は、0.171×730×3+0.25×730で計算します。ROSAのサービス料だけで約557米ドルになり、1ドル150円を仮に置くと約8.4万円です。

EC2やEBS、ロードバランサーなどのAWS料金は、この金額とは別です。通信、監視、バックアップの料金も、別に見積もります。

Red Hatの価格ページでも、クラウドサービスごとに料金体系が異なると示されています。セルフマネージド製品は、契約条件や構成によって個別に見積もられます。

見積書は費目ごとに別行にしてもらい、為替や利用量による変動リスクも示してもらいます。

  • 費目:Red Hat契約、クラウド利用料、構築・開発費、移行費、運用保守費
  • 変動要因:為替、利用量、24時間運用やSLAの有無

年間の保守・運用費は、業務システム全般の目安として初期開発費の15〜20%程度とし、そこにクラウドとサブスクリプションの費用を加える考え方があります。

ただし、年間の保守・運用費は、24時間運用やSLAを含むかどうかで変わります。固定の比率だけでは予算化できません。

2025年11月に一般提供されたOpenShift 4.20では、次の機能が強化されています。

  • AIワークロード、仮想化、外部OIDC
  • External Secrets Operator、ユーザーネームスペース、BGP
  • OpenShift VirtualizationによるVMとコンテナの同一基盤での管理

新機能を採用するほど、設計、検証、運用教育の範囲は広がります。そこで、発注するときは、採用する機能、サポート対象のバージョン、アップグレードの方針を提案書に記載してもらいます。

検証環境や、後から追加する機能も、提案書に記載してもらいます。出典は、Red Hatの資料「Red Hat OpenShift 4.20: Accelerating Virtualization and AI Innovation」です。確認時点は2025年11月です。

ポイント

工程ごとに、完成の条件を決められるかで請負と準委任を使い分けます。費用は、ライセンス、クラウド、開発・移行、運用保守の費用を合わせて見ます。

委託先の選定と見積比較の確認事項

委託先を選ぶ際の本番環境の条件、同じWBSによる見積、受入条件とリスク分担の3項目を並べた図。
3項目を横並びで照合すると、候補ごとの不足を見つけやすくなります。

委託先は、認定資格や製品の取り扱いだけでなく、本番稼働後まで責任を持てるかどうかで比べます。

候補には、製品やサブスクリプションを提供する会社や、ハイブリッドクラウドに強い会社があります。基盤構築を担うSI会社、業務アプリ会社、運用専門会社も、対象に入ります。

先に必要な役割を定めてから、各社の実績と体制を照らし合わせます。

本番環境の条件まで見た実績確認

「OpenShiftの案件がありますか」と尋ねるだけでなく、本番環境の条件も聞きます。

  • 基盤:利用バージョン、オンプレミスかクラウドか、ノード数、可用性
  • システム:対象アプリの種類、データ移行の有無
  • 運用:稼働後の範囲、障害対応の時間帯

可能であれば、匿名化した構成図、移行計画、運用設計書のサンプルを見せてもらいます。そのうえで、提案担当者と実装・運用の担当者が同じ前提で話しているかを確かめます。

同じWBSと前提による見積比較

総額だけでなく、同じWBSにそろえて、作業の抜けと前提条件を比べます。

  • 作業:調査、要件定義、設計、クラスタ、ネットワーク・認証、CI/CD
  • 開発・移行:アプリ改修、データ移行、テスト、教育、リリース
  • 運用:監視、バックアップ、運用引き継ぎ
  • 見積条件:人日、単価、期間、担当会社、契約費、税・為替、追加要件単価
  • 監視範囲:メトリクス、ログ・トレース・アラート、夜間通知、障害一次対応

特に注意したいのは、見積が安く見えても、非機能要件の検証や移行リハーサルが含まれていないケースです。

比較表は、「含む」「含まない」「別途見積」「発注者準備」の四区分で作ると、追加費用になりやすい項目を見つけやすくなります。

受入条件とリスク分担の契約化

受入条件には、画面の動作以外の検証と、発注者側の作業も含めます。

  • 合格条件:負荷試験の同時接続数、フェイルオーバー、復旧、脆弱性検査、ログ保存、権限分離、切り戻し、移行後の件数・金額突合
  • 発注者作業:マスタデータ提供、業務部門の受入テスト、ネットワーク申請、クラウド・Red Hat契約
  • リスク・PoC:仕様変更、既存アプリの制約、第三者製品の障害、データ品質に対し、成功条件、代替案、判断者を決めておく

発注者側が担う作業は、納期と依存関係の両方に入れておきます。Red Hatやクラウド側の仕様変更と追加の要望は、リスク台帳に記載します。

小さく検証してから本開発へ進めば、全社展開後に構成をやり直すリスクを抑えられます。

ポイント

委託先は、本番稼働後まで責任を持てるかで比べます。見積は同じWBSにそろえ、受入条件とリスクの分担を契約書に書いておきます。

OpenShiftのシステム発注に関するよくある質問

発注の過程では、製品の選択や業務アプリの移行について疑問が出てきます。さらに、費用や契約、運用の責任の分け方にも疑問が生じます。相談の前に確認しておきたい質問に、順に答えます。

OpenShiftのシステム発注は何から始めればよいですか?

発注の準備では、目的と現状を整理してから、調査を依頼します。

  • 整理事項:対象業務、現行アプリ、データ分類、希望時期、運用体制
  • 解決する課題:リリース速度、可用性、ハイブリッド環境、VM移行、セキュリティ統制

解決したい経営・業務の課題を先に明確にし、そのうえで現状調査か小規模PoCを発注します。製品の導入そのものを目的にしないためです。

OpenShiftのシステム費用を安くする方法はありますか?

費用を抑えるには、導入の範囲と移行の優先順位を整理します。

  • 環境ごとの目的:PoC、開発、本番、運用を分ける
  • 初期構成:不要な高可用性や多クラスタを入れない
  • 移行と活用:境界が明確な機能から段階移行し、マネージドサービス、標準Operator、既存CI/CDを使う

監視やバックアップ、セキュリティ、復旧試験を削ると、稼働後の損失が増えます。そのため、削る対象は機能と工程の優先順位で判断します。

OpenShiftの外注先は何社に見積を依頼すべきですか?

比較条件をそろえたうえで、複数社の提案と体制を確かめます。

  • 依頼先:まず2〜3社。分割発注なら全体統括会社も候補に含める
  • 見積条件:同じWBS、非機能要件、納品物
  • 確認事項:経験、障害対応、移行リハーサル、契約後の追加費用

2〜3社に絞ると、提案の質と比較作業の負担のバランスを取りやすくなります。

発注時に納品してもらうべきものは何ですか?

将来の保守や障害調査に必要な納品物を、作業範囲に応じて選びます。

  • 設計:構成図、要件定義書、基本・詳細設計書、ネットワーク・権限設計
  • 構築・検証:Kubernetesマニフェスト、Operatorと設定値、CI/CD、テスト計画・結果
  • 移行・運用:移行、バックアップ・復旧、監視、運用手順、教育資料、ソースコード

すべてが必要とは限りませんが、保守を別の会社に変える場合や、障害を調べる場合に必要な納品物は、契約書に列挙します。著作権や利用許諾、リポジトリ管理者、秘密情報の削除方法も、あわせて合意します。

まとめ

発注前に確認するポイント

発注の前には、基盤とアプリの範囲、非機能要件、契約の方式、費用の内訳を確かめます。納品物と運用の責任の分け方も確かめたうえで、同じ条件の下で候補会社の提案を比べます。

安さだけでなく、将来の保守と変更に必要な情報が残っているかも評価します。

最初の一歩は現状調査またはPoC

発注前の検討では、調査から発注条件までを順に整理します。

  1. 現状調査:現行アプリやデータの制約が不明なら、本番開発の一括発注は見送る
  2. 小規模PoC:不確実性の縮小と、成功条件、次工程の判断基準の設定
  3. 投資判断:OpenShiftを採用しない場合も含め、調査結果をもとにした判断
  4. 責任範囲:基盤、業務アプリ、データ移行、運用保守を分け、自社と委託先の役割を決める
  5. 発注形態:一括委託、基盤・アプリ会社の分担、マネージドサービスのうち、自社の人材と運用体制に合うもの
  6. RFPの要件:業務要件、可用性(RTO・RPO)、性能、認証、ログ、バックアップの記載
  7. 運用条件:移行、監視、アップグレード、再委託、納品物もRFPに含める
  8. 費用内訳:公式サービス料金、クラウド費、開発費、運用費を分けた比較
  9. PoC・軽微なコンテナ化:300万〜800万円が目安
  10. 中小規模:本番基盤と業務アプリ1〜3本の場合で、1,000万〜3,000万円
  11. 基幹刷新など:モダナイズや多拠点移行の場合で、3,000万〜1億円超の案件別レンジ
  12. 候補会社:2〜3社程度に同じ前提で依頼し、WBS、担当者、実績、非機能試験、移行リハーサルを確かめる
  13. 比較項目:障害対応、納品物、追加費用の条件
  14. 最新機能:技術トレンドだけでなく、サポート期間、運用人材、セキュリティ、3〜5年のTCOを含めた判断

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

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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