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

Oracle Cloudのシステム開発は、対象と要件を定め、複数社の提案を同じ条件で比べてから契約すると、運用まで見通しやすくなります。

発注は、発注形態の選択、要件の整理、工程ごとの進め方、契約形態の決定の順で進みます。費用と委託先・見積の見方も、この順に沿って解説します。

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

Oracle Cloudのシステム発注で最初に整理する対象

Oracle Cloudの発注対象として、OCI基盤、Oracle Database、Fusion Cloud、新規業務アプリを並べた図解。
対象を分けると、必要な作業範囲を整理しやすくなります。

発注前には、製品名よりも「何をクラウド化し、どの業務成果を得たいか」を定義しておきます。基盤の移行だけにするか、業務アプリまで作り替えるかで、体制、契約、期間、費用が変わるためです。

OCI基盤を発注するケース

OCI(Oracle Cloud Infrastructure)は、コンピュート、ネットワーク、ストレージ、ロードバランサなどを組み合わせる基盤です。

  • 基盤の構成:コンテナ、監視、バックアップ、IAM(Identity and Access Management)も組み合わせる構成です。
  • 利用対象:新規WebアプリやAPIのほか、オンプレミスのOracle Database移行にも使います。
  • 発注・運用範囲:ネットワーク設計、可用性、権限、暗号鍵、監視、移行、障害対応の範囲を定めます。

仮想マシンを用意しただけでは、本番運用は始まりません。本番として動かすには、RTO(目標復旧時間)、RPO(目標復旧時点)、保守時間、問い合わせ窓口も決めておく必要があります。

Oracle DatabaseとFusion Cloudを発注するケース

Oracle Databaseの移行とFusion Cloudの導入では、発注前に確認する対象が違います。

  • Oracle Database:エディション、バージョン、ライセンス、性能、バックアップ、停止許容時間の確認が必要です。
  • Fusion Cloud:標準業務アプリケーションをSaaSとして導入する形です。
  • 機能の分担:標準業務はSaaSで短期導入し、独自業務はOCI上のアプリやAPIで拡張する方法もあります。

Oracle Fusion Cloud Applicationsには、ERP、EPM、SCM、CX、HCMなどの標準業務アプリケーションがあります。

発注対象には、業務標準化、設定、追加開発、移行、教育が含まれます。そのうえで、製品、基盤、移行、追加開発を一括で任せず、標準機能に合わせる層と自社固有の設計にする層を明確にします。

Oracle Cloudの発注形態の選び方

発注形態は、現行環境の複雑さ、社内人材、納期の確度、将来の内製化方針をもとに決めます。全社刷新を一括で発注する方法もあれば、調査やPOCを先に委託してから本開発へ進む段階方式も選べます。

既存Oracle Databaseの移行の外注

現行機能を大きく変えず、サーバーやデータベースをOCIへ移すなら、移行プロジェクトとして発注します。

  • 移行方式:リホスト、リプラットフォーム、データベース再設計では、作業内容とリスクが異なります。
  • 停止時間への備え:停止時間を短くする場合は、移行リハーサル、差分同期、切り戻し手順、性能試験を見積に含めます。
  • ライセンス方式:既存ライセンスを持ち込むBYOL(Bring Your Own License)か、クラウド側のライセンス込みかを比べる。

保守契約、対象エディション、コア数、待機環境の扱いも確認します。条件によっては、移行後の費用が想定を超える可能性があります。

OCI上の新規開発の外注

独自の業務フロー、顧客向けサービス、販売・在庫・生産のアプリを作るなら、新規開発として発注します。

  • 機能要件:画面数、業務ルール、API連携、帳票、権限、バッチ、監査ログを機能一覧に載せます。
  • 利用条件:データ保持期間とピーク時の同時接続数を、はっきりさせておく。
  • POC:重要業務で1〜3か月程度行い、処理性能、移行の難所、操作性、月額利用料を確かめる取り組みです。

POCで確認してから本番開発へ進めば、見積の精度を高められます。そのうえで、POCのコードや設計書を本番へ引き継ぐ扱いも、発注者と開発会社で合意しておきます。

Fusion Cloud・ハイブリッド構成の発注

標準業務を優先するか、独自業務を既存環境に残すかによって、構成を選びます。

  • Fusion Cloud:会計、購買、人事、サプライチェーンの導入と周辺連携を、まとめて委託できる形です。
  • ハイブリッド構成:独自業務や工場設備をOCIやオンプレミスに残し、APIや連携基盤でつなぐ構成です。

2025年6月、日本のGoogle Cloud東京リージョンでOracle Database@Google Cloudの提供が始まりました。

Exadata Database ServiceやAutonomous Databaseなども、Google Cloudのデータセンターで利用できます(出典: 日本オラクル「Oracle Database@Google Cloud、日本で提供開始」、2025年)。

既存のGoogle Cloud運用標準を維持したい場合は候補になります。その場合は、ネットワーク、契約窓口、障害時の責任分界を提案依頼書に明記します。

ポイント

発注形態は、移行、新規開発、Fusion Cloudやハイブリッド構成のどれに当たるかに加えて、現行環境の複雑さ、社内人材、納期の確度、将来の内製化方針から選びます。

RFPと要件整理の準備

RFPは、ベンダーに同じ前提で提案と見積を出してもらうための文書です。細部まで決め切らなくても、現状、目的、対象範囲、制約、希望時期、評価方法をそろえれば、比較しやすくなります。

現行環境と業務範囲の洗い出し

現行環境の洗い出しは、システムと業務の両方を対象に進めます。

  • データベース:Oracle Databaseのバージョン、データ容量、表やインデックスの構成を一覧にまとめる。
  • 処理と連携:月間・日次の処理件数、ピーク時間帯、連携先を整理する。
  • 業務の流れ:会計、販売、在庫、生産、顧客管理の流れを把握します。
  • 手作業の流れ:Excel、EDI、帳票、ファイルサーバー、認証基盤、工場設備も対象に含めます。
  • 対象外の資産:移行しないシステムやデータは、理由と将来方針を記載します。

たとえば、荏原製作所は、基幹業務を含む200以上のシステムをOCIへ移行したと、日本オラクルが公表しています(出典: 日本オラクル「荏原製作所、基幹業務を含む200以上のシステムをOCIへ移行」、2025年)。こうした大規模案件では、対象の一覧と依存関係が見積の精度を左右します。

機能要件と非機能要件の書き分け

要件は、機能とシステム品質・運用条件に分けて書き出します。

  • 機能要件:誰がどのデータを使い、何を処理して出力するかを、業務シナリオで示します。
  • 業務の詳細:入力、承認経路、締め処理、取消・訂正、権限別操作、帳票、外部API、バッチ頻度を記載します。
  • 非機能要件:可用性、性能、拡張性、セキュリティ、監視、バックアップ、災害対策、データ所在地、サポート時間を定める。
  • 停止範囲:平日何時から何時まで停止できるか、月何分まで停止を許容するかを、具体的な時間で定めます。
  • 復旧時間:障害発生から何時間以内に復旧するかを、数値で示します。

RFPに必ず含める項目

RFPには、提案と見積の前提をそろえるための情報を含めます。

  • 案件情報:背景と目的、対象業務、現行構成、データ量、連携一覧、希望スケジュールを記載する。
  • 提案条件:予算の考え方、納品物、体制、運用範囲、セキュリティ条件、契約希望、提出形式を含めます。
  • 見積内訳:要件定義、設計・構築、移行、テスト、教育、保守・運用、OCI利用料、ライセンス別に分けてもらう。
  • 評価基準:価格、Oracle Cloudの認定・実績、移行リハーサル、セキュリティ、障害対応、内製化支援、担当者の継続性を評価の観点とする。

ポイント

RFPは、現行環境と業務範囲を洗い出し、機能と非機能を書き分けてまとめます。細部まで決め切らなくても、目的、対象範囲、制約、希望時期、評価方法をそろえておけば、提案を同じ前提で比べられます。

Oracle Cloudの発注・外注の進め方

Oracle Cloudの発注工程を、企画・提案比較、要件定義・設計・開発、移行・テスト・リリース、運用定着と引き継ぎの順に示した図解。
各段階で成果物と意思決定者を決めて進めます。

要件定義と設計・開発の後は、移行・テストからリリース、運用定着へと工程が続きます。

  • 移行・テスト:データの移行と、単体から利用者受入までのテストを行います。
  • リリース:本番切替をリハーサルし、切り戻し条件を決めてから実施します。
  • 運用定着:リリース後の運用範囲と、担当者が代わっても運用できる引き継ぎを定めます。

工程ごとに成果物と意思決定者を決めておき、発注者側にも業務責任者とデータ責任者を置く必要があります。

企画・提案比較フェーズ

企画・提案比較では、まず目的を定めたうえで、同じ条件で各社の提案を確認します。

  • 目的の設定:経営課題と現場課題を分けて考えます。保守切れ、処理時間短縮、拠点追加、データ活用、災害対策などが例です。
  • 提案依頼:RFPをもとに2〜4社程度へ依頼し、同じ質問票と見積フォーマットで回答をそろえる。
  • 提案会での確認:移行中の業務継続、障害時の連絡経路、テストデータの作り方、運用チームへの引き継ぎを質問する。
  • 範囲の確認:提案書にない作業は追加費用になりやすいため、前提条件と対象外作業を一覧にします。

要件定義・設計・開発フェーズ

要件を具体化し、クラウドと業務システムの設計を一体として確認します。

  • 要件定義:RFPを業務、機能、非機能、移行、運用の各要件へ具体化する作業です。
  • 設計対象:VCN、サブネット、IAM、MFA、ログ、監視、暗号鍵、バックアップ、接続方式を扱い、アプリ・データベース設計とつなげます。
  • 設計レビュー:発注者が日程と承認者を決め、可用性、シェイプ、DB構成、バックアップ世代の理由をベンダーに尋ねます。

移行・テスト・リリースフェーズ

移行計画では、ベンダーが行う作業と、発注者が確認する作業を分けて書きます。

  1. データを抽出、変換、クレンジング、取り込み、照合する。
  2. 単体、結合、総合、性能、セキュリティ、障害復旧、利用者受入の順にテストします。
  3. 本番切替をリハーサルし、切り戻し条件を決めてから実施します。

マスタの重複や未使用コード、桁数、日付形式、過去データの保持範囲は、発注者側の業務知識を踏まえて確かめます。

テストでは、通常時の性能に加えて、バックアップから復元できるかを確かめます。特に、障害時に誰が何分以内に判断するのか、ピーク時の費用が予算内に収まるかも確認します。

運用定着と引き継ぎフェーズ

リリース後の運用範囲と、担当者が代わっても運用できる引き継ぎを定めます。

  • 運用業務:監視、パッチ適用、脆弱性対応、バックアップ確認、障害対応、性能改善、利用者問い合わせ、月額費用を確認する。
  • 対応時間:24時間365日監視か、営業時間内の一次対応かで、保守費用と契約内容が変わります。
  • 納品・引き継ぎ:必要な納品物を受け取り、担当者が変わっても運用できる状態を受入条件とする。
  • 定例会:課題、障害、利用率、月額費用を確認する場です。

納品物には、構成図、設計書、パラメータシート、IaC(Infrastructure as Code)、ソースコードを含めます。加えて、テスト結果、移行手順、障害対応手順、操作マニュアルも受け取ります。

Oracle Cloudの外注での契約形態の選び方

契約形態は、成果物と要件が固まっているか、一緒に要件を決めるかで選びます。要件が曖昧なまま全体を請負にすると、変更のたびに費用と納期の調整が必要になります。一方で、すべてを準委任にすると、成果や責任の境界が不明確になりやすくなります。

請負契約・準委任契約の使い分け

要件と成果物が固まっているか、進行中に判断が必要かによって、契約を使い分けます。

  • 請負契約:成果物の完成を重視します。環境構築、移行ツール、画面、帳票など、受入基準を明確にできる工程に向きます。
  • 請負で定める条件:成果物、納期、検収条件、瑕疵対応、変更管理を契約書と仕様書に記載します。
  • 準委任契約:現状調査、要件定義、構成検討、技術支援、運用改善など、専門知識を使いながら進め、途中で判断する業務です。
  • 準委任で定める条件:稼働時間だけでなく、担当業務、会議体、報告方法、責任者を明確にします。

契約書で決める責任分界と変更管理

責任分界と変更時の手続きは、契約書で明確にしておきます。

  • 担当範囲:Oracle、クラウド事業者、一次・二次請けSIer、発注者の役割を表にまとめる。
  • 障害の切り分け:OCI、Oracle Database、アプリ、ネットワーク、認証、データ品質ごとに、窓口と責任を定めます。
  • 変更管理:仕様変更、法改正、データ増加、連携先追加、Oracleのバージョンアップを扱います。
  • 変更手続き:受付、影響調査、追加費用、納期、承認者、見積に含む変更回数や範囲を明記する。

ライセンス、OCI利用料、サポート費用の値上げや為替変動について、どう扱うかも確かめます。

ポイント

契約形態は、成果物と要件が固まっているかどうかで選びます。受入基準を明確にできる工程は請負、進めながら判断する工程は準委任が向きます。

Oracle Cloudのシステム発注費用の相場

Oracle Cloudの費用は、OCI利用料に加えて、要件定義、設計・開発、ライセンスを含めて考えます。さらに、移行、連携、テスト、教育、保守・運用の費用も加わります。

この節の金額は、2025〜2026年時点の公開価格体系と業務システム案件の一般的な目安にもとづく推定レンジです。Oracleの個別見積や契約割引を反映した確定価格ではありません。

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

初期費用は、構築・移行の対象と規模で変わります。ここに挙げる金額は、中小〜中堅企業を想定した推定です。

  • 小規模環境:検証用環境や簡易Web業務システムは、100万〜500万円程度です。
  • DB移行:現状調査、ネットワーク設計、移行、性能試験、切替を含め、300万〜1,500万円程度です。
  • 部門システム:新規構築・連携は、1,000万〜5,000万円程度です。
  • 複数部門へのFusion Cloud導入:標準化、複数会社・拠点、移行、追加開発、教育を含め、5,000万〜3億円程度です。
  • 大規模刷新:基幹刷新やグローバル統合では、3億〜10億円超になる場合があります。

金額は、データ量、連携本数、利用者数、可用性、海外展開、ライセンスによって上下します。

OCI利用料と保守・運用費用の目安

OCIの月額利用料は、企画段階では環境の規模と構成を分けて試算します。

  • 検証・小規模環境:月額1万〜10万円が目安です。
  • 冗長化した中小業務システム:月額10万〜100万円が目安です。
  • 中堅〜大規模環境:複数の可用性構成、DB、監視、バックアップ、閉域接続を含み、月額100万〜1,000万円超です。
  • 上振れ要因:GPU、Exadata、Cloud@Customer、大量通信、24時間監視で費用が上がります。

上記の試算では、1ドル150円を仮定しています。

日本オラクルの価格表では、コンピュートなどの単価をvCPUとOCPUで示しています。さらに、サービスごとにコンピュート時間、メモリ、ストレージ、リクエスト、転送量などで課金されます(出典: 日本オラクル「OCI価格リスト」、2026年8月確認)。

見積には、インスタンスのサイズ、稼働時間、バックアップ世代、ログ保存期間、転送量を記載します。また、開発・検証環境の台数も提示してもらいます。

保守費用と見積内訳の分け方

保守・運用費や工程別の割合は、企画時の推定目安として見積を確認します。

  • 保守・運用費:初期開発費の年15〜20%が一般的な目安です。
  • 費用例:初期費用3,000万円なら年間450万〜600万円、月額37万〜50万円程度です。
  • 見積内訳:初期費用、OCI利用料、Oracleライセンス・サポート、移行・切替、保守・運用、追加改善に分けて示す。
  • 工程別割合:要件定義10〜15%、設計15〜20%、テスト15〜20%、移行・導入5〜10%が目安です。

保守費用は、人員、対応時間、SLA、監視範囲によって変わる推定です。Oracle Cloudでは、既存データの品質と連携の難しさで移行費用が大きく変わります。

ポイント

費用は、初期開発・移行、OCI利用料、保守・運用に分けて考え、推定レンジとして扱います。個別見積でライセンスや移行、可用性などの条件を反映させ、数年分の総額で比べます。

Oracle Cloudの委託先・発注先の選び方

Oracle Cloudの委託先選定で確認する、実績、技術者・体制、業務理解とコミュニケーションの3観点を示した図解。
構成や工程が近い実績かどうかも見比べます。

委託先は、知名度だけでなく、今回の構成と発注範囲に合うかで選びます。OCI基盤、Oracle Database移行、Fusion Cloud導入、アプリ開発、運用では、得意な会社が異なります。

委託先の実績は、似た製品を扱ったかだけでなく、似た課題に取り組んだかも確認します。

構成・規模・工程による実績の確認

自社と近い案件かどうかを、構成、規模、担当工程ごとに確かめます。

  • 構成・規模:移行元と移行先、データ量、利用者数、連携本数を比べます。
  • 工程・制約:停止許容時間、期間、担当工程を確認し、実際の責任者に苦労した点を聞く。
  • 条件別の実績:追加費用の発生点を聞き、国内データ保持、公共・金融のセキュリティ、24時間運用、グローバル展開などの実績を見ます。

Oracle公式のISMAPページでは、OCIとFusion Cloud Applicationsの登録範囲が示されています。2025年6月の更新では、OCI Alloy、Oracle Database@Azure、生成AIなどの追加が案内されています(出典: 日本オラクル「Oracle Cloud InfrastructureのISMAP対応」、2025年6月更新)。

登録対象のサービスであっても、自社の設定や運用が自動的に適合するわけではありません。

技術者・体制・サポート範囲の確認

提案では、担当者の体制と契約後のサポート範囲を具体的に確かめます。

  • 技術責任者:OCI、ネットワーク、Oracle Database、アプリ、セキュリティ、移行、運用それぞれの担当を確認する。
  • 体制:再委託の有無、担当者の稼働率、変更時の引き継ぎ、国内対応、問い合わせ窓口を見ます。
  • 技術支援:資格数だけでなく、設計レビューと障害対応を誰が行うかを確かめます。
  • 運用範囲:監視、アラート分類、一次切り分け、Oracleへの連絡、復旧、月次報告、パッチ、脆弱性対応、改善提案を一覧にまとめる。

夜間対応や障害復旧が別料金だと、運用費が安く見えても、TCO(総保有コスト)が高くなる可能性があります。

業務理解とコミュニケーションの評価

技術知識と業務理解の両方を、提案内容で評価します。

  • 業務理解:締め処理、例外承認、在庫評価、会計連携を把握できるかを確かめる。
  • 進め方:現場ヒアリング、業務フロー、プロトタイプやデモ、利用部門の教育計画を見ます。
  • 担当者が少ない場合:管理や要件整理を支援する会社が向いています。
  • 技術者がいる場合:構築だけを専門会社へ委託する方法もあります。

社内技術者が専門会社と設計・運用を共同で担うと、将来のベンダーロックインを抑えられます。

ポイント

委託先は、今回の構成と発注範囲に合う実績、体制、業務理解で比べます。実績は構成・規模・工程まで確かめ、運用範囲や追加費用の条件も見積に書かれているかを見ます。

Oracle Cloudの見積を比較するときのポイント

見積の比較では、総額だけでなく、同じ範囲と前提で計算されているかを確認します。作業範囲、環境数、テスト回数、移行対象が会社ごとに違うと、金額を並べても比べられません。そこで、RFPの項目順に見積をそろえ、差分の理由を質問します。

作業範囲と成果物の横並び比較

比較表では、各社の作業範囲と成果物を同じ行で確認します。

  • 作業範囲:要件定義、現状調査、基本・詳細設計、環境構築、アプリ開発、移行、連携、テスト、教育、切替、保守を並べる。
  • 各社の回答:「含む」「一部含む」「対象外」を示してもらい、成果物名と受入条件も併記します。
  • 漏れやすい作業:複数環境、監視・ログ保存、復元テスト、データクレンジング、帳票印刷検証、利用者教育、稼働後支援は、見落とされやすい作業です。

対象外の作業は、発注者が別途手配する費用も加えて比べます。見積に含まれない作業があると、金額が安く見えてしまうためです。

前提条件・単価・追加費用の確認

見積は、利用条件と追加作業の前提をそろえてから比較します。

  • 利用条件:利用者・同時接続数、データ容量・増加率、稼働時間、リージョン、可用性を含めます。
  • 費用前提:バックアップ世代、通信量、環境数、ライセンス、為替、税、契約期間を記載します。
  • 月次・年次試算:単価表に想定利用量を掛けた試算を提示してもらう。
  • 追加費用:連携先やリハーサルの追加、性能不足による構成変更、夜間切替、休日対応の条件を確かめる。

変更依頼の単価や見積回答の期限も決めておくと、途中で判断しやすくなります。

3年程度のTCOによる判断

初期費用が安くても、数年後の総額は高くなる場合があります。そのため、初年度だけでなく、3年程度の初期費用と運用費を並べて比較します。

  • 総額に含める費用:OCI利用料、保守、Oracleサポート、バックアップ、監視、回線、改修、教育、社内運用人件費を含めます。
  • 構成の判断軸:RTO・RPO、ピーク性能、法令、業務停止の損失から、冗長化や専用サービスの必要性を見ます。
  • 費用の見極め:削減できる費用と、削れない復旧・セキュリティ費用を分けて考えます。

Oracle Cloudの発注で起こりやすい失敗と対策

基盤を契約すれば業務システムが自動で移行できる、標準機能なら追加開発は要らない、といった誤解が起こりがちです。

小規模検証と本番で利用料が大きく変わることもあります。また、技術、データ、業務、契約、運用のリスクを、同じ計画で管理します。

データ移行のベンダー任せ

移行後に件数や金額が合わなければ、元データの品質が原因であっても、稼働延期につながります。

  • 発注者が決めること:正しい業務データ、不要データ、コード変換、過去履歴の保持範囲を定めたうえで、移行前後の照合方法を承認する。
  • 切替前の確認:本番相当データで少なくとも一度リハーサルし、所要時間、エラー件数、差分修正、停止・切り戻し時間を記録します。
  • 契約上の役割:マスタ整備や利用部門の確認を、発注者側のタスクとして残しておく。

セキュリティ設定の後回し

セキュリティ要件はRFPに含め、設計レビューと受入テストで確かめます。

  • 設計する設定:IAM権限、MFA、管理者アカウント、ネットワーク分離、WAFの設定を決めます。
  • 管理する情報:ログ、監査、脆弱性、暗号鍵、秘密情報の管理を含めます。
  • 登録とリージョン:ISMAP登録や国内リージョン利用の可否を確かめ、自社の運用設定とは分けて考える。
  • 運用責任:権限承認とログ確認を、誰が行うかを定めます。
  • 削除期限:退職・異動時に何時間以内に権限を削除するかを、運用手順に記す。

納品後の変更可能性の確保

特定の会社しか分からない手作業や独自ツールが残ると、契約更新やベンダー変更のたびに費用がかかります。

  • 納品物:設計書、ソースコード、IaC、テスト仕様、運用手順、アカウント一覧、ライセンス情報を契約に含め、発注者が保管します。
  • 契約終了時:データ返却、アカウント移管、バックアップ廃棄、秘密情報の返却、移行支援の条件を決めます。
  • 将来の変更:2026年時点では他クラウド連携やAI活用の選択肢も増えているため、API、データ形式、権限設計を検討しておく。

よくある質問(FAQ)

発注では、費用、社内準備、委託範囲、運用責任についての質問が多く寄せられます。初回相談の前に確かめたい疑問に、発注者の判断に役立つ形で答えます。

Oracle Cloudのシステム開発を外注するといくらかかりますか?

費用の目安は、発注する内容によって異なります。

  • 小規模POC・簡易Web業務システム:100万〜500万円程度
  • 既存Oracle Database移行:300万〜1,500万円程度
  • 部門業務システムの新規構築・連携:1,000万〜5,000万円程度

いずれも企画段階の推定レンジです。実際には、ライセンス、データ移行、連携、可用性、運用時間、利用量を含めて、個別見積を取ります。

社内にOracle Cloudの専門家がいなくても発注できますか?

発注はできますが、業務責任者とデータ責任者は社内に置く必要があります。

現状資料が少ない場合は、いきなり本開発を発注せず、現状調査や要件整理を準委任で依頼します。発注者とベンダーでRFPを作成してから本開発を比較すると、進めやすくなります。

BYOLとライセンス込みはどちらを選べばよいですか?

既存ライセンスの契約条件、データベースのエディション、利用規模、将来の増設を見て決めます。

保守の持ち方も比べます。BYOLが必ず安いとは限らず、ライセンス込みが必ず管理しやすいとも言えません。そのため、ライセンス費、サポート費、待機環境、開発・検証環境を含む数年分の総額で比較します。

委託先を選ぶときに最低限聞くべきことは何ですか?

似た規模・構成の実績、担当予定者、移行リハーサル、障害時の責任分界、運用時間を確かめます。加えて、見積の対象外、追加費用の条件、納品物、終了時の引き継ぎについても質問します。

認知度や初期費用だけで判断する前に、業務理解と運用を含む提案かどうかを比べます。

まとめ

発注するときは、OCI基盤、Oracle Database、Fusion Cloud Applications、新規業務アプリのうち、どれが対象かを整理します。

現行資産、業務フロー、データ、連携、非機能要件をRFPにまとめ、作業範囲をそろえて比べます。そのうえで、要件定義、設計、移行、テスト、運用までの対象を確認します。

発注成功の要点

費用は、初期開発・移行費、OCI利用料、ライセンス、保守・運用費に分けて、推定レンジとして扱います。また、請負と準委任は工程に応じて使い分け、責任分界、受入条件、変更管理、納品物、引き継ぎを定めます。さらに、見積では、金額だけでなく、対象外作業と3年程度のTCOまで確かめます。

最初に取るべき行動

まず、現状と希望条件をまとめて相談します。仕様書は、最初から完璧に作らなくても構いません。

  1. 現行システムの一覧、困っている業務、データ量、停止許容時間、希望時期を整理する。
  2. 現状調査やPOCを含む提案を、複数社に依頼します。
  3. Oracle Cloudと自社業務の両方を理解するパートナーと、成果、費用、運用責任を一つずつ合意する。

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

会社紹介

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

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

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

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

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

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