OpenShiftのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

OpenShiftのシステム開発は、要件整理から運用定着まで6つの工程を順に進めると、後戻りや追加費用を抑えやすくなります。

工程ごとの内容、費用相場、発注準備も本文で扱います。全体像は、この後に載せた完全ガイドでも確認できます。

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

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

OpenShiftのシステム開発の全体像

OpenShiftは、Red Hatが提供するKubernetesベースの企業向けアプリケーション基盤です。

複数の業務アプリを、その基盤の上で継続して運用できます。

OpenShiftでは、認証や権限、ネットワーク、ストレージを標準化できます。

開発や運用では、CI/CD、監視、脆弱性対策、アップグレードも標準化できます。

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

OpenShiftのシステムは、プラットフォーム基盤と業務アプリケーションに分けて考えます。

• プラットフォーム基盤：Control Plane、Worker Node、レジストリ、ストレージ、ネットワーク、認証、監視
• 業務アプリ：販売管理、顧客管理、製造管理、API、バッチなど

業務ロジックやデータベース、既存システムとの連携は、OpenShiftとは別に作り込む必要があります。

依頼範囲には、クラスタ構築のほかコンテナ化と改修を明記します。

データ移行や受入テスト、保守も、範囲に含めて書きます。

依頼範囲が曖昧だと、基盤が完成したあとにアプリを載せられない場合があります。

移行が追加請求になることもあります。

OpenShiftを選ぶ理由の確認

OpenShiftは、Kubernetesの柔軟性を保ちながら、企業向けの標準機能をまとめて扱えます。採用するかどうかは、自社の運用条件に合うかで判断します。

• 企業向け機能：標準設定、認証・認可、Operator管理、Webコンソール、製品サポート
• 適する環境：複数環境を共通で管理する場合や、複数チームで開発を続ける場合
• 代替案との比較：小規模な単一アプリなら、マネージドコンテナやサーバーレスが合う場合もある
• 採用判断：3〜5年の総保有コスト、リリース頻度、監査要件、既存VM、AI・仮想化計画

オンプレミスやベアメタル、VMwareを、共通の考え方で管理できます。さらに、パブリッククラウドやエッジも同じ考え方で管理できます。複数チームが開発、テスト、本番を繰り返す環境でも、効果を発揮しやすくなります。

OpenShiftのシステム開発の進め方

OpenShiftの案件は、6つのフェーズに分けて進めると抜け漏れを抑えやすくなります。各フェーズで、何を渡すかと判断基準を決め、次へ進む条件を発注側と開発会社で合意します。その合意は、後戻りと追加費用を減らすことにもつながります。

フェーズ1：要件整理と目的・非機能要件の決定

要件整理では、解決したい業務課題を定義します。OpenShiftの導入は、その課題を解く手段として位置づけます。

• 注文集中への対応：月末の注文集中に耐える
• リリース短縮：四半期ごとのリリースを毎週にする
• 共通運用：オンプレミスの基幹とクラウドの新サービスを管理する

目的がはっきりしないまま機能を選ぶと、使わない機能の構築費が増えるおそれがあります。

非機能要件には、通常時とピーク時の同時接続数、応答時間、稼働時間を含めます。

RTO（復旧目標時間）とRPO（復旧時点目標）も、あわせて決めておきます。

ログ保持期間、バックアップ世代数、データ所在地を洗い出します。認証方式と脆弱性の修正期限も確認します。さらに、開発者数と環境数も押さえます。

個人データを扱う場合は、データフローと委託先を要件に加えます。アクセス記録と漏えい時の連絡経路も含めます。

現行アプリとVMを一覧にし、データベースやファイル保存の依存関係を確認します。業務部門の受入条件と切り戻し条件、発注者側のマスタ整備担当も決めます。これらが未確定の場合は、その場合の対応として、本番構築を急がず、現状調査または短期PoCを先に見積もります。

フェーズ2：方式とサービスの選定

候補にするのは、セルフマネージド、ROSA、Azure Red Hat OpenShiftです。また、OpenShift DedicatedやIBM Cloudなども候補に入ります。

• セルフマネージド：配置やネットワークを制御しやすく、運用作業は自社か委託先が担う
• マネージド：Control Planeの負担を減らせるが、料金と、どこまでを誰が受け持つかの確認が必要
• 構成条件：リージョン、マルチAZ、既存接続、ID連携、ストレージ、バックアップ
• 運用条件：更新の主導者、障害窓口、Kubernetes案との費用・機能差

セルフマネージドでは、クラスタや証明書、ストレージの運用を自社か委託先が担います。脆弱性対応とアップグレードも、その役割に含まれます。一方、マネージドでは、サービス料金とクラウド基盤料金の二重構造も確認します。

選定時には、各方式の費用と、ストレージ性能が要件を満たすかも確認します。

OpenShiftのサポートや標準化、開発者体験が、追加費用に見合うかを判断します。

2025年11月に一般提供されたOpenShift 4.20では、外部OIDCなどが強化されています（出典：Red Hat「Red Hat OpenShift 4.20: Accelerating Virtualization and AI Innovation」、2025年）。

強化対象には、External Secrets Operator、仮想化、AIワークロードも含まれます。まず、契約中のエディションと対象バージョンを確認します。さらに、運用チームの習熟度や既存アプリとの互換性も見ておきます。

フェーズ3：基盤とアプリの設計・開発

設計では、クラスタ構成図に加えて、アプリの依存先と障害時の振る舞いを定義します。

• クラスタと権限：Project、Namespace、RBAC、ResourceQuota、NetworkPolicy
• 接続と保存：Route、ロードバランサー、永続ボリューム、外部DB、レジストリ
• 運用機能：監視、ログ、バックアップ、秘密情報の保管先

Security Context Constraintsも設計対象に含めます。

コンテナ化では、イメージを作るだけでなく、設定値を環境変数や外部設定へ分離し、ログを標準出力へ集約する必要があります。

セッションやファイルは、Podのローカル領域に置かない構造へ改修します。Javaや.NET、COBOLのアプリについては、移行対象と対象外を決めます。また、VMware上のVMも、その判断の対象になります。

モノリスを一度に細かいマイクロサービスへ分けない点も大切です。

環境差を減らすため、Gitリポジトリでマニフェストを管理します。CIでテストとイメージ検査を行い、承認済みの変更は、CDまたはGitOpsで環境に反映します。

納品物には、ソースコードやマニフェスト、パイプライン定義を含めます。設定一覧と権限一覧も納品物に入れます。さらに、接続情報の管理方法や設計書、テスト仕様書、運用手順書も引き継ぎます。

フェーズ4：機能・非機能・移行テストの実施

機能テストに加えて、非機能や移行の面からも確かめます。

• 負荷試験：ピーク時の同時接続数と応答時間を測る
• 障害試験：Pod、Node、AZ、ストレージ、外部API停止時の復旧を確かめる
• セキュリティ試験：最小権限、認証失敗、NetworkPolicy、脆弱性、ログを確認する
• 移行・受入試験：データを突合し、移行時間や受入条件を記録する

移行時は、データ件数、キーの重複、文字コードを突合します。さらに、日付とマスタの対応関係も突き合わせます。秘密情報がログに出ていないか、監査ログを検索できるかも確かめます。

移行リハーサルは少なくとも一度行い、実測時間と停止可能時間を記録します。そのうえで、切り戻し手順と業務部門の確認者も残します。

受入条件は、業務シナリオと件数、証跡を含めて文書化します。未解決の不具合をどう扱うかまで、同じ文書に記します。

フェーズ5：稼働判定と切り替え

稼働前のGo判定は、技術面と業務面に分けて行います。

技術面では、監視・アラートとバックアップからの復元を確認します。証明書の期限と容量、権限は、判定条件になります。また、脆弱性の状況や連絡網、当番表も、判定条件に含めます。

業務面では、主要シナリオやマスタ、権限を確認します。さらに、帳票と外部連携、利用者教育は、完了しているかを見ます。

切り替え方式には、一括移行、業務や拠点ごとの段階移行、旧環境との並行稼働があります。

停止可能時間が短く、データ更新も多い場合は、切り替え作業を順番に計画します。

1. 事前同期の実施
2. 最終差分の移行
3. 切り替え後のデータ照合
4. 必要な場合の切り戻し時刻の決定

各作業の時刻は、分単位で計画します。

稼働当日は、開発会社と業務責任者の連絡先を一枚にまとめます。基盤、ネットワーク、データの担当者も、同じ紙に載せます。

フェーズ6：運用の定着と継続的な改善

稼働後は、クラスタ運用とアプリ運用について、どこまでを誰が受け持つかを明確にします。

• 担当範囲：更新計画、脆弱性判定、Pod・Node障害の一次切り分け、問い合わせ
• 24時間365日対応：監視時間、復旧開始までの時間、休日の承認者、代替連絡先、報告期限
• 定着指標：デプロイ頻度、変更失敗率、平均復旧時間、重大アラート未対応時間
• 定期運用：月次の容量・費用確認と、四半期ごとの更新、DR訓練、権限と不要なNamespace・イメージの整理

Red Hatやクラウドへの問い合わせ担当は、運用設計書に記載します。指標には、バックアップ復元テストの成功率と脆弱性の期限内修正率も使います。導入直後から障害訓練を行い、運用手順を検証します。

OpenShiftのシステム開発にかかる費用相場

費用は、Red Hatのサービス、クラウドまたはハードウェア、基盤構築、アプリ改修に分けて考えます。さらに、データ移行やテスト、教育、運用保守も費用の項目になります。

セルフマネージド版には一律の価格がなく、移行費を含んだ公式の総額表もありません。ここで示すのは、公開価格と一般的な業務システムの工程相場を組み合わせた概算です。そのうえで、契約の前には、構成と責任の分け方に基づく個別見積もりを取ります。

公開価格から見るクラウド利用料の試算

Red Hatの予約利用価格は、4vCPU・3年契約で1時間0.076米ドルからです（出典：Red Hat「OpenShift pricing」、2026年8月確認）。

• 含まれる範囲：最低Worker構成が必要なサービス料金
• 別途必要な費用：クラウド基盤、ストレージ、通信、LB、監視、バックアップ
• ROSAサービス料金：Worker 4vCPUあたり0.171米ドル/時、HCPは0.25米ドル/時追加
• 月額例：730時間/月、1米ドル=150円、HCP Worker 3台なら約557米ドル、約8.4万円
• 6台の場合：約931米ドル、約14.0万円。マルチAZではWorker、インフラ、Control Planeが各3台必要

ROSAの料金とHosted Control Planeの追加料金はAmazon Web Servicesの価格案内に基づきます（出典：Amazon Web Services「Red Hat OpenShift Service on AWS Pricing」、2026年8月確認）。

この試算は料金の仕組みをつかむためのもので、総額ではありません。なお、EC2やEBS、ロードバランサー、データ転送などのAWS基盤費は、別途かかります。

実際の月額は、リージョンとインスタンスタイプによって変わります。ストレージ容量や通信量、契約期間でも変わります。

構築・アプリ開発・移行の概算レンジ

概算の額と期間は、構成や移行範囲によって異なります。

• 学習・PoC：開発用クラスタと軽微なアプリ1〜2本で300万〜800万円、1〜3か月
• 本番基盤：HA構成と業務アプリ1〜3本で1,000万〜3,000万円、3〜6か月
• 基幹移行：モダナイズ、多クラスタ、複数拠点、段階移行で3,000万〜1億円超、6〜18か月

金額は公式の定価ではなく、要件別の作業範囲を置いた推定です。要件定義や設計の範囲で、金額は変わります。さらに、クラスタ構築、ネットワーク、認証、監視の範囲も、金額を左右します。

アプリ改修や移行の範囲も、費用に影響します。テストや教育、運用引き継ぎの範囲も、費用に関わります。

たとえば、新規アプリをスクラッチで開発する場合は、画面やAPIの費用が上乗せされます。DBや外部連携の費用も、別に加わります。

一般的な業務システムの運用保守は、初期開発費の15〜20%程度が目安です。一方で、OpenShiftでは利用料とRed Hat契約の費用が上乗せされます。

さらに、監視やバックアップ、24時間対応、アプリ保守も加わります。アップグレードや障害訓練を含めた3〜5年のTCOで比べます。

OpenShiftの見積もりを取る際のポイント

見積もりの精度は、前提条件をどこまで整理できているかで変わります。発注側は、現行環境や対象アプリ、利用者数を示します。そのうえで、ピークやデータ量、停止可能時間も伝えます。

発注側は、セキュリティ基準と運用時間、納品物も、依頼の時点で共有します。

発注前の要件と前提条件のまとめ

見積依頼書には、前提条件を一枚にまとめて書きます。前提が揃っているほど、見積もりの精度は上がります。

• システム前提：目的、業務、現行構成、移行対象、利用者、環境数、稼働時間
• 非機能・契約前提：RTO・RPO、負荷、データ分類、認証、クラウド、納期、既存ベンダー分担
• 互換性調査：コンテナ化、セッション、ファイル保存、外部接続、OS・ミドルウェアのサポート期間
• 発注者作業：データ整備、受入テスト、教育、申請、承認、法務・監査確認の担当と期限

発注者の協力が曖昧なまま固定価格で契約すると、納期と費用が争点になりやすくなります。

複数社の同条件での比較

少なくとも2〜3社に同じRFPを渡し、内訳を分けた見積書を求めます。

• 費目：ライセンス、クラウド、構築、アプリ改修、移行、テスト、教育、保守
• 見積条件：工程別工数、単価、前提、除外事項、再見積もり条件
• 不足の可能性：安価な提案は非機能試験、バックアップ、監視、設計書などが対象外の場合がある
• ベンダー体制：担当範囲、事例、クラウド、障害対応、更新実績、成果物の権利と範囲

極端に安い提案では、移行リハーサルや稼働後支援が含まれるかも確認します。

ベンダーには、基盤だけか業務アプリまでか、データ移行と24時間運用まで担えるかを尋ねます。また、資格者の人数だけでなく、本番事例も確認します。

リスクと契約上の責任の分け方

セキュリティ基準への適合は、OpenShiftの導入とは別に確かめる必要があります。

• 適合責任：Compliance Operatorを使っても、適合の責任は利用者にある
• 個人データ：個人情報保護法の安全管理措置、委託先の監督、漏えい時の対応、国外での取扱いを確かめる
• 公共案件：製品ではなく、利用するクラウドサービスのISMAP対象状況を確かめる
• 契約条件：SLA、障害通知、脆弱性修正、サポート版、データ削除、ログ保持、再委託、データ返却を確認する
• 予防策：PoC、段階移行の切り戻し条件、週次の変更・課題管理でリスクを抑える

Compliance Operatorは、実装を検査し、改善を補助します（出典：Red Hat Documentation「Compliance Operator」、2026年8月確認）。

Red Hat、クラウド事業者、SI会社、利用企業のうち、どこが何を保証するかは契約によって変わります。

失敗例には、非機能要件の後回しや、全機能の一括マイクロサービス化、マスタや移行の丸投げがあります。監視やバックアップを後から付けることや、仕様凍結後の追加要求を管理しないことも、失敗の典型です。一方で、仕様凍結後の変更は、変更管理表と課題管理表に載せて週次で更新します。

OpenShiftのシステム開発でよくある質問

費用や期間は、アプリ数と移行の難しさで変わります。ここに示す数字は判断の出発点とし、自社の要件で計算し直します。

OpenShiftとKubernetesはどちらを選べばよいですか？

方式は、チーム規模、必要な機能、運用人材に応じて選びます。

• OpenShift：複数チームで継続開発し、企業サポート、標準化、認証・権限を重視する場合
• Kubernetesなど：小規模な単一アプリで運用人材があり、必要機能を自社で組み合わせられる場合
• 比較条件：3〜5年のTCOと運用負荷

既存のVMやモノリスもOpenShiftへ移行できますか？

移行できる可能性はあります。まず、依存関係と移行方式を調べます。

• 依存関係：OS、ミドルウェア、ファイル、セッション、バッチ、外部接続、ライセンス
• 移行方式：VMのまま扱う、アプリをコンテナ化する、段階的に併用する
• 検証と切替：小規模PoCを行い、データ移行と切り戻しをリハーサルする

一括移行は避け、境界が明確で影響範囲の小さいAPIやバッチから、PoCを始めます。

OpenShiftのシステム開発費用はどのくらいですか？

費用は、構成と作業範囲に応じて変わります。

• PoC・小規模開発：300万〜800万円
• 本番基盤と業務アプリ1〜3本：1,000万〜3,000万円
• 基幹モダナイズ・多拠点移行：3,000万〜1億円超

公式の定価ではなく、基盤構築からテスト、運用設計までを含めて推定した金額です。

ROSAなどのサービス料金とAWSのインフラ料金は、別に見積もります。Red Hat契約や運用保守も、別枠で考えます。

開発会社へ相談する前に何を準備すればよいですか？

相談の前に、システムの前提と依頼したい範囲を整理しておきます。

• 現状と負荷：構成図、アプリ・VM、DB、外部連携、利用者数、ピーク負荷
• 運用・納期：停止可能時間、RTO・RPO、セキュリティ基準、希望時期、運用時間
• 依頼範囲：基盤構築、アプリ改修、移行、教育、24時間運用のどこまでか

情報が不足していても、相談はできます。現状調査とPoCの範囲を分けて提案してもらうと、比較しやすくなります。

まとめ

OpenShift基盤と業務アプリを切り分けたうえで、6つの工程を順番に進めます。

性能や可用性、RTO・RPOを初期に決めます。さらに、データ移行や認証、ログ、バックアップも、早い段階で決めておきます。

アップグレードと運用の責任の分け方も早めに合意しておくと、費用と納期を安定させやすくなります。

採用判断の基準：TCOと運用体制

採用の判断では、将来の機能と自社の必要性を照らし合わせます。

• 将来の機能：OpenShift 4.20のAI、仮想化、外部OIDC、External Secrets Operator
• 導入範囲：使わない機能は複雑性を増すため、必要な範囲から始める
• 比較材料：変更頻度、ハイブリッド環境、監査・セキュリティ要件、社内人材、3〜5年のTCO

この比較材料をもとに、導入の規模を決めます。

最初の一歩：現状調査と小さなPoC

最初に現状を調べ、対象アプリを一つに絞って小さく検証します。

• 短期PoC：コンテナ化、認証、CI/CD、監視、バックアップ、障害復旧を試す
• 実測値で再計算：本番ノード数、クラウド費用、移行期間、運用要員を見直す
• パートナー選定：複数社に同じ条件で見積もりを依頼し、設計・テスト・運用資料を引き継げる相手を選ぶ

こうした引き継ぎは、長期的なベンダーロックインの抑制につながります。

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

▼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を創業。