クラウドに向けた取組みの紹介

アプリケーションの移行を伴うクラウド変革のプロセスは複雑になるものです。しかし、この複雑さの中には、クラウドへの移行の過程で明確に定義される目標がいくつかあります。そのような目標の1つには、ターゲット・アプリケーションをどの程度「クラウド対応」にするか、ということが含まれます。希望の時間枠内にクラウドに移行するには、アプリケーションをどの程度クラウド対応にする必要があるでしょうか。本書では、こうした目標のいくつかを概説し、当社が移行の過程で学んだベスト・プラクティスと教訓に焦点を当てます。成功の秘訣は、移行の目標をあらかじめ明確に定義して、目標を達成する方法について最適な決定を下せるようにすることです。取りうる道はたくさんあることがわかります。移行の過程で、開発者、デリバリ・チーム、経営陣は、どのように進めるかを評価し、それについて多くの選択を行わなければなりません。

ビジネス目標を達成するために下す必要のある決定の枠組みを定める上で、以下に挙げる技術面、ビジネス面の推進要因に注目することをお薦めします。

スケーラビリティ

クラウド・サービスは、マネージド・インフラストラクチャで可能なレベルをはるかに超える大規模な計算能力を提供し、市場機会に対応できる規模へのビジネスの拡大を可能にします。クラウドベースのInfrastructure as a Service (IaaS)とPlatform as-a-Service (PaaS)により、ISVは最新のコンポーネントを利用したスケーラブルなアーキテクチャの構築に集中できます。移行の付随的なメリットとして、社内の開発チームがIT運用の管理とスケーリングから解放され、パフォーマンスの調整と最適化に集中できるようになることも挙げられます。

モダナイゼーション

ツールセット、サービス、アーキテクチャを最新化すると、コンポーネント間の統合が容易になり、アプリケーションがクラウドで利用可能なツールとテクノロジの価値を最大限に引き出せるようになります。このようなツールは、インフラストラクチャのアップグレードから自動化された導入パイプライン、アプリケーションのパフォーマンスを高める統合された機械学習モデルまで多岐にわたります。市場で急速かつ着実な変化が起きている今、この変化に対応するためにアプリケーションは動的であることが求められるため、モダナイゼーションが最も重要です。サービスを完全に再構築してリブランディングし、最新のテクノロジ・スタックを活用することで、コストの削減や合理化されたサービス・オプションの提供が可能になる場合もあります。こうした変化によって、老朽化した製品が刷新され、ライセンス製品が標準となっている確立した市場に激変がもたらされる可能性があります。また、新しいアプローチで製品を見直すことで、ブランドの認知度と顧客のロイヤルティを維持しながらサービスを改善できる場合もあります。そのために製品スイートの全面的な変更が必要になるとは限りません。

クラウドへの移行は、広範囲にわたってモダナイゼーションを推進するきっかけとなります。クラウドでは、これまで組織で利用できなかったサービス、テクノロジ、専門知識にお客様もチームもアクセスできるため、新しい目標を達成し、新しい機能を提供することが可能になります。お客様のチームは、別々の顧客の特定の導入に結び付いたカスタム・コードではなく、広く適用可能な新しい製品機能に集中できるようになります。サービスのプロビジョニング、製品のアップデート、カスタマ・サポートのすべてがかつてないスピードで行われるため、改めて新しい機能の開発にリソースを向けることができます。このように、クラウド移行をきっかけに、幅広いモダナイゼーション活動が次々と展開され、製品アップグレードの実行から顧客サービスの品質に至るまで、あらゆるものを変革します。

---

「Gen2 Cloudに移行したことで、オラクルは、堅牢なDevSecOpsモデルを介してサービスを確実に提供し、お客様のビジネス変革をサポートできるようになりました。今では、ソフトウェアを毎日リリースし、プロビジョニング時間を98%以上短縮しています」 — Oracle Global Business Units、シニア・プリンシパル製品戦略マネージャ、Karthic Murali

---

標準化

IaaSとPaaS全体にわたって標準化することで、オーバーヘッドを削減し、チームの柔軟性と代替可能性を高めることができます。組織が成長するにつれて、チームは様々な成熟度レベルのツールを採用します。こうしたツールセットをクラウド・サービス内で統合すると、このIT管理レイヤーに関連する複雑さの多くが抽象化されます。その結果、ポートフォリオ全体に適用できるタスクの標準的な運用手法を策定して使用することが可能になります。また、標準化することで、日常業務が簡素化されて予測可能になり、基本的なタスクに必要な労力が減少します。これまでは、アプリケーション間で互換性がないこともある多様なプロセスに対処するだけで精一杯だったリソースが解放され、顧客向けの次世代製品やサービスの開発など、重要度の高い問題に専念できるようになります。

特に、標準化によって、チームが既存の製品と新製品に簡単に適用できる、セキュリティ、リスク、コンプライアンスやその他の運用業務に関連したグローバルなポリシーとプラクティスを実施しやすくなります。実際に、正式な認可を受けたコンプライアンス認証など、IaaSプラットフォームに固有の機能の多くは、アプリケーションに継承できます。

収益の最適化

収益の最適化は、主に2つの方法で実現できます。第一の最も明白な方法は、コスト削減です。IaaSを利用してデータ・センターをなくせば、財務モデルをCapExからOpExに移行できるだけでなく、通常は大幅なTCOの節約につながります。クラウドに移行されたアプリケーションのポートフォリオ全体で使用されるテクノロジ・スタックを合理化することで得られるコスト削減は、それほど明白でないかもしれません。一般的なツールセットを使用すれば、体系的な知識が培われ、非標準のツールの場当たり的なトレーニングにかかる費用が不要になります。それに加えて、インフラストラクチャをコードとして扱う一般的なツールセットは、最終的に時間と人件費の節約につながる自動化を実現します。最後に、セキュリティなど、ポートフォリオ全体に適用される基本分野を専門とするチームがあれば、個々の製品チーム内でエキスパートを育成する必要がなくなります。

第二に、アプリケーションがクラウド対応またはクラウド・ネイティブになると、製品開発のタイムラインが短縮されるのが一般的であるため、クラウドへの移行によって市場投入を迅速化し、最終的には収益を最適化することができます。市場投入が迅速化されれば、収益の実現も早まります。アプリケーションがクラウド対応になると、世界中のあらゆる場所にものの数分でアプリケーションを導入できます。

前述の原則を組み合せることで、製品とサービスのアーキテクチャが標準化されるとともに、導入のスピードと品質が向上します。繰り返しのパターンに対応した設計から、収益の最適化と価値実現までの時間の短縮につながるスケールが得られます。また、顧客向けのサービスの品質と整合性の向上に改めてリソースを集中させることも可能になります。

---

WorkForce Softwareは、ワークフォース管理ソリューションをOracle Cloud Infrastructureに移行し、パフォーマンスの30%向上を実現しています。

「移行直後から30～35%の設備投資削減を可能にする財務実績が得られました。また、OCIの優れたパフォーマンスにより、当社のスイートがもたらすROIは向上し続けています」 — WorkForce Software、最高経営責任者、Mike Morini氏

続きを読む

---

クラウドでの価値に通じる道

クラウド・コンピューティングには、IaaSおよびPaaSの様々なリソースと、ベア・メタル・インスタンスへのアクセスからコンテナ化された統合環境、完全に機能するサービス・スタックに至るまで、複数のソフトウェア導入モデルが含まれます。最も基本的なレベルでは、クラウド・コンピューティングとは、物理的なインフラストラクチャ・コンポーネントをコアIaaSリソースに置き換えることを指します。

ほとんどのエンタープライズ・アプリケーションは、もともとクラウド用に構築されていません。多くのアプリケーションにとって、クラウド・パターンへの転換または準拠は時間がかかり、困難な作業です。リプラットフォームには、時間と労力のどちらの面から見てもコストがかかるため、クラウド・ネイティブなプリンシパルを最初から設計する方が簡単な場合があるのも当然です。この点を考慮すると、通常、企業がクラウド移行を検討する際の状況は、3つの主なシナリオのいずれかに当てはまります。

• レガシー・データ・センターの廃止: データ・センターの運営にはコストがかかります。建物、人員、電力、冷却、メンテナンス、アップグレードなどは、日々の責務のごく一部です。多くの企業は、オンプレミスからの移行の候補となるアプリケーション・ポートフォリオを評価することにより、データ・センターへの依存を軽減または解消しようと積極的に取り組んでいます。最優先となるのは、資本支出を削減または排除する取組みの一環として、コロケーション型のマネージド・ホスティングやオンプレミスのデータ・センターからアプリケーションを移動することです。リフト＆シフト戦略がよく利用されますが、その場合、アプリケーションはそのままクラウド内のベア・メタル・サーバーや仮想マシンに移行されます。
• テクノロジ・スタックの進化: この場合、企業はアプリケーションに少しずつ変更を加え始めます。これには追加の投資が必要になりますが、長期的に見るとより多くの価値をもたらすことが期待されます。たとえば、オンプレミス・バージョンのOracle DatabaseをクラウドベースのOracle Autonomous Databaseに置き換えて、アプリケーション自体は大きく変更しないようなケースです。これは、移行＆向上戦略と呼ばれることもあります。
• すべてをクラウド・ネイティブに実現: アプリケーションを完全に再構築してクラウド対応にする場合のメリットは、成熟度の低いアプリケーションをそのまま維持しながら前述のシナリオのいずれかを実行する場合のコストを上回る可能性があります。クラウド・ネイティブなアプリケーションは本質的に高度に分散されており、多くの場合、12要素の原則を利用して構築されるため、基盤となるアーキテクチャから独立するように設計されています。つまり、その下にあるインフラストラクチャが壊れた場合でもアプリケーションは動作を続けます。簡単に言えば、この方法がターゲット・アプリケーションにとって意味があるかどうかを評価する価値はあります。クラウドへの移行は、基盤となるインフラストラクチャと緊密に結合されたアプリケーションを移行するよりも確実に容易であるためです。

オラクルによるクラウド・ネイティブの定義、クラウド・ネイティブ・アプリケーションの起源、クラウド・ネイティブ・アプリケーションの構築時に従うべきベスト・プラクティスについては、このeBookをお読みください。

---

これらのシナリオを想定するもう1つの方法は、エンタープライズ・アプリケーションをOracle Cloud Infrastructureに移行しながら、クラウド・ネイティブなアーキテクチャに近づけるために取ることのできる様々な手段を検討することです。下の図1を参照してください。

図1: クラウド移行における変化と投資レベル

図1の左側は、変化の量が最も少なく、価値実現までの時間が最も短く、初期投資が最も少ないことを表しています。変化、投資、時間のレベルは、右に移動するにつれて全体的に増加しますが、実現される価値も大きくなります。このモデルは、移行フェーズでどのような種類の投資を検討すべきかを予測する方法の枠組み作りに役立ちます。アプリケーションの構築方法は無数にあるため、各シナリオは必ずしも独立しておらず、多少重複していることに注意してください。

前述のシナリオは、既存の成熟度レベルとクラウド移行の目標を評価する上で重要な基準点となります。現在の状態と目標とする状態のギャップから、クラウド移行に必要な技術面の変更とプロセス上の変更の範囲を大まかに見積もることができます。クラウド移行の結果、すべてのアプリケーションがクラウド・ネイティブな提供モデルに移行するのが理想です。しかし、リソースと時間の制約から、1回のプロセスでポートフォリオ全体をクラウド・ネイティブ・モデルに移行できる組織はほとんどありません。シンプルなリプラットフォーム作業でさえ、リソースを大量に消費し、レガシー機能を複製するためだけに多額の投資を必要とする可能性があります。

したがって、クラウド移行では、最適なクラウド成熟度レベル(上に示したクラウド・ホスティングからクラウド・ネイティブまでの帯の中でアプリケーションがどこに位置するか)と、製品とそれに関連するビジネス・プロセスの再構築に必要なエンジニアリング投資とのトレードオフを特定できるかどうかが問題になります。この段階での重要なステップは、各アプリケーションの現在の成熟度レベルと目標とする成熟度レベルを特定し、このギャップを埋めるために必要な開発投資を大まかに見積もることです。

移行中にアプリケーションの成熟度レベルを変更した場合は、運用パターンと期待値も変更する必要があります。成熟度レベルの変更は、サービスをサポートするチーム、プロセス、ポリシーに影響します。

 

クラウドへの技術的準備状況の評価

ターゲット・アプリケーション(またはSaaSベースの複数のアプリケーションを提供する企業のアプリケーション・ポートフォリオ全体)の技術的な理解は、移行の要件と依存関係を理解する上できわめて重要です。この段階では主に、アプリケーションに必要な機能と、その機能がアプリケーションの依存関係にどのように関連しているかを特定することに重点を置く必要があります。これにより、移行活動の相対的な時期が早まり、主な重点分野を特定できます。評価の際には、3つの重要な側面に目を向ける必要があります。

1. インフラストラクチャの要件: クラウドは、基盤となるハードウェア環境または運用環境からソフトウェアを切り離します。成熟度の高いアプリケーションは、基本的に環境から独立しており、クラウドで簡単に拡張できる一般的なインフラストラクチャ・リソース(CPUやKubernetesクラスタなど)にのみ依存しています。成熟度の低いアプリケーションは、マネージド・インフラストラクチャやその他の専用システムなど、提供されている特定の機器、コンポーネント、環境に依存しています。アプリケーションがクラウド内のインフラストラクチャ・コンポーネントや構成にどの程度強く依存するかを最初に文書化し、最終的にはそのような依存関係を解消する必要があります。基盤となるインフラストラクチャに結び付いた、あるいは結合されている(お客様またはお客様の顧客が作成した)カスタマイズが見つかるのは珍しいことではありません。
2. サービス・コンポーネント クラウドは、アプリケーションから独立して運用および提供されるスタンドアロン・サービスとして、サポート機能を提供します。成熟度の高いアプリケーションは、スタック全体の依存関係を最小限に抑えた別々のコンポーネントを中心に設計されているため、対象を絞った変更とアップグレードが可能になり、アップタイムを最大化できます。成熟度の低いアプリケーションは、緊密に結合された大規模なコンポーネントで設計されています。こうしたコンポーネントは相互依存性が高く、単一のエンティティとして管理する必要があります。こうしたサービスの関係は、アプリケーションごとに文書化する必要があります。
3. 運用の準備状況: クラウドは、技術アーキテクチャだけでなく、作業プロセス、スキル・セット、利用可能なツール、運用モデルを変更します。成熟度の高いアプリケーションは、すでにクラウド・アプリケーションのように動作し、クラウドで問題なく機能するプロセス、標準およびツールセットを使用しています。成熟度の低いアプリケーションの場合、重要なサポート・サービスがクラウドにない、アプリケーションをサポートするチームのスキル・セットがクラウド作業に適していない、使用しているプロセスがクラウドへの移行によって中断されるといったことが起こります。

これらの要因についてアプリケーションの成熟度を評価することから移行を開始すると、適切な計画を立てるとともに、遅延を引き起こし、コストを増加させ、目標を達成できない原因となるような予期しない事態が下流で発生するのを回避することができます。現在の本番環境、サポート・サービスのスイート、および目標とするクラウド環境はプロセスを通じて進化し続けるため、移行の複雑さを控えめに言うことは困難です。サービスとアプリケーションの結び付きを明らかにすることで、事前のインテリジェントな計画が可能になるだけでなく、移行中に必ず発生する変更にその計画が柔軟に対応できるようになります。この評価を効果的に文書化すれば、移行プロセスのTo-Doリストが明確になります。これにより、予想される移行スケジュールを、絶えず変化するロードマップと一致させ続けることができます。

---

Zoomは、同時に発生する数百万の会議をOracle Cloud Infrastructure上ですばやくスケーリングし、アクティブ化しています。

「最近、当社のビジネスはかつてないほど大きく成長しており、サービスのキャパシティを大幅に増強する必要がありました。複数のプラットフォームを検討しましたが、キャパシティをすばやくスケーリングして新しいユーザーのニーズを満たすにはOracle Cloud Infrastructureが有効でした」 — Zoom、CEO、Eric S. Yuan氏

続きを読む

---

財務目標

どのようなITイニシアティブにも言えることですが、クラウド移行には、ターゲット・アプリケーションがオンプレミスのホスティング・モデル用に構築されている場合は特に、その価値を最大限に引き出すための一連の投資が必要になります。クラウドに移行する価値があると見なされるアプリケーションは、いずれ時間の経過とともにクラウド・ネイティブになるか、廃止されます。ただし、通常はアプリケーションをクラウドリリース状態にすることが最初の目標です。

アプリケーションを現在の状態からクラウドリリース状態に移行するために必要なのは、一連の決定と初期投資の成果です。単純にアプリケーションをベアメタル・サーバーにリフト＆シフトする計画ですか(この場合、投資の大部分はクラウド・インフラストラクチャに向けられます)。それとも、移行前にアプリケーションをクラウド対応にする計画がありますか(この場合、アプリケーション・スタックの一部をクラウドベースのモデルに移行する(たとえば、データベースをオンプレミスからDBaaSまたはOracle Autonomous Databaseに移行する)ための投資が必要になります)。顧客固有の機能を有効にするためにハードコードされたカスタマイズを作成している場合、プラットフォーム・コンポーネントがカプセル化されて、製品化された機能としてAPI経由で提供されるモデル用に、そのカスタマイズをリファクタリングする必要があります。高度に分散されたアプリケーションをクラウドでスケーリングするには、ハードウェアまたはプラットフォームの依存関係を解消する必要があります。このような投資を理解することは、クラウドへの移行に関連する財務目標を計画し、達成する上で重要な要素です。

初期投資には、先ほど説明したクラウド移行の段階に関連して必要になる製品の変更に必要な開発時間と労力が含まれます。ただし、その他の費用も把握しておかなければなりません。移行中に発生する可能性のある各種費用には、次のものが含まれます。

• 開発投資: データベースの移行やアプリケーションのプロビジョニングなどの活動をサポートする自動化も含め、製品の再構築や移行作業用のアクセラレータの作成に必要な開発作業
• 移行の実施: 新しい資産のプロビジョニング、既存の環境とデータの移行、およびレガシー・インベントリの廃止に必要な労働資源
• インフラストラクチャの採用: IaaSランプによって発生するサブスクリプション料金。これは、定常状態に移行しますが、移行期間を通して新たな増加となります
• 残存するインフラストラクチャ: 移行作業によって発生し、除却または償却できるまで残る、データ・センターと設備投資の減価償却費
• 従業員の移行: 既存のチームのトレーニング、教育、再構築に関連する費用や、必要なクラウド・スキル・セットを備えた新しいリソースの獲得に関連する費用
• 顧客の移行: 新しい開発、インセンティブ、契約項目の再交渉、顧客離れなど、新しいモデルではサポートできない環境特性やサービス条件の変更に関連するコスト

程度の差こそあれ、これらのコストはどれもIaaSへの移行に必要な要素です。それぞれが異なる方法でコスト・プロファイルに影響を与えます。たとえば、開発投資と移行実施の費用は、この作業に関連するリソースが固定されている場合でも、1回限りのバケットに収まる可能性があります。新しいインフラストラクチャを採用した結果、残存するインフラストラクチャの費用がなくなるまで、一定期間は費用の純増加が発生します。トレーニングや移行のインセンティブなど、従業員と顧客の移行費用の中には、1回限りの費用になるものもあります。従業員の増加や顧客契約の変更といったその他の事項は、新たな継続的費用につながる可能性があります。

これらのダイナミクスが時間の経過とともにどのように展開するかを理解することは、組織がクラウド移行の準備を進め、期待値を設定する上で不可欠です。組織がクラウドの劇的なメリットに熱心であっても、移行のリスクを明確に理解していないと、移行と重複するインフラストラクチャのコストを事前に負担する場合は特に、初期段階の費用の増加に驚かされることになります。適切な期待値を設定し、段階的な進展があるたびにそれを可視化することは、組織が移行を進める中で整合性と統制を維持するために不可欠な要素です。

クラウド移行インベントリ

クラウドへの移行には、クラウド移行インベントリが欠かせません。クラウド移行インベントリとは何でしょうか。簡単に言えば、フリート内のすべての資産と、各資産を説明する重要な関連データ要素のリストです。このリストには、移行の対象となるアプリケーションとその依存関係のすべてが含まれています。そのデータを取得するために使用される媒体は無関係であり、データは企業内の複数の部門にまたがることが多いため、いくつものツールを利用することは珍しくありません。通常、必要な情報は様々な生産、販売、運用データベースに分散しています。たとえば、構成管理データベースでは、技術的な依存関係や資産の場所を、物理サーバーやラックの場所に至るまで詳細に追跡する場合があります。ただし、移行について顧客に通知する時期と方法を決定する上できわめて重要な、ビジネスおよび顧客についての考慮事項は含まれません。その情報は、多くの場合、運用とサポートの関係者向けに設計されたリポジトリに含まれています。さらに、買収、特別なユース・ケース、製品のサイロ化により、情報が複数のリポジトリにわたってさらに断片化している場合もあります。

移行インベントリの主な目的は、クラウドへの移行を管理するために必要な要素を一元的に把握できるようにすることです。たとえば、資産とは何か。資産はどこにあるか。どの製品をサポートしているか。どのような機能があるか。どの顧客をサポートしているか、などです。

最初から認識しておかなければならないのは、このブループリントが生きたドキュメントであることです。時間の経過とともに進化するため、特に複数のアプリケーションや複数のバージョンのアプリケーションを使用する企業の場合は、柔軟性が必要です。新しい問題が表面化したり、新しいニーズが発見されたりすると、インベントリは進化します。基盤となるクラウド・インフラストラクチャでさえ、移行中に変化する可能性があり、それに伴ってインベントリはさらに進化します。移行インベントリには、初期計画を開始できるように利用可能なデータをできるだけ多く取り込み、その後は、移行の過程で新しい要件が判明するたびに詳細のレイヤーを追加していきます。

移行インベントリの管理は、それ自体が機能横断的なプロジェクトであり、詳細なデータの必要性と収集作業のバランスを取る必要があります。また、詳細な技術仕様、アーキテクチャ的アプローチ、顧客要件、データ転送経路など、時期とスピードに影響を与える依存関係、制約およびリソースを示す要素も含まれています。情報が少なすぎると、インベントリは役に立ちません。多すぎると、メンテナンスが負担になり、すぐに古くなって使用されなくなる可能性があります。

クラウド移行の出発点として、次の移行インベントリ・フレームワークをお薦めします。

移行インベントリから運用インベントリへ

ここまで移行インベントリに焦点を当ててきましたが、クラウド移行には最終的に2つの課題があります。最も直接的には、移行活動を計画し、優先順位を付けて、追跡する必要が生じます。ところが、移行自体が原因となり、日々の運用の追跡に必要なデータは変化します。たとえば、物理サーバーとラックに関する移行後の構成の詳細は意味がなくなり、個々のインスタンスの情報でさえ、重要性が低下します。それと同時に、組織がセルフサービス・モデルを採用した場合は特に、全体的な使用状況やデータ・エグレスなどのメトリックが重要になる可能性があります。

移行インベントリを作成することで、こうしたクラウド中心の新しいデータ・スキーマやプロセスへの移行が始まります。インベントリの作成とアプリケーションの移行という対をなす課題は別々のプロジェクトですが、それぞれを単独で進めないでください。一番に行うべきなのは移行作業であり、組織が資産の詳細な一元的ビューを作成したのはこれが初めてかもしれません。移行後の新しいインベントリ・ビューのテンプレートが形成される変革の瞬間です。前述のように、移行インベントリには柔軟性と適応性が必要です。適切に管理すれば、移行インベントリは移行後の貴重なインベントリ管理ツールへと進化します。

クラウドへの道を先導

SaaSアプリケーションをホストするためのインフラストラクチャの設計

SaaSベースのアプリケーションを提供するISVには、サービスをホストし、顧客を分離して管理するための、安全でスケーラブルなエンタープライズ・グレードのインフラストラクチャが必要です。下の図3に示すリファレンス・アーキテクチャは、ベスト・プラクティスが組み込まれた検証済のフレームワークを提供し、Oracle Cloud InfrastructureでSaaSアプリケーションをホストできるようにします。

このリファレンス・アーキテクチャでは、複数の分離されたアプリケーション・インスタンスを導入して管理します。各導入は特定のテナント用であり、これらの個々のテナント・アプリケーション・インスタンスは共通の管理レイヤーを介して管理されます。

1つのコード・ベースからすべてのテナント・アプリケーション・インスタンスを構築するか、アプリケーションのカスタマイズされたバージョンを各テナントに提供するかを選択できます。このパターンは、アプリケーション環境を完全に分離する必要があるSaaSの顧客に最適です。

図3: OCI上のSaaSアプリケーション向けベスト・プラクティス・リファレンス・アーキテクチャ

上のリファレンス・アーキテクチャの詳細は、Oracle Architecture Centerを参照してください。さらに、4つのテナントのアーキテクチャの導入を支援するTerraformベースのツールとステップバイステップ・ガイドを作成しました。最後に、Oracle Cloud Infrastructureベスト・プラクティス・ガイドに従うことを常にお薦めします。このガイドでは、セキュリティとコンプライアンス、信頼性と回復力、パフォーマンスとコストの最適化、運用効率という4つの一般的なビジネス目標に関するガイダンスが得られます。

アーキテクチャの変更に加えて、サービス・スタックがクラウドでどのように変化するかを考える必要があります。オンプレミスのアーキテクチャ用に開発されたレガシー環境に導入されているモニタリング、ネットワーク管理またはセキュリティに使用されるコア・ツールセットは、クラウド向けに進化します。クラウドへの移行は、これらのツールが対応する範囲を拡大するオポチュニティとなります。クラウドベースのツールは、主にエンド・ポイントをモニタリングするのではなく、スタック全体をモニタリングします。クラウド・サービス・プロバイダが、コア機能に加えて、クラウドベースまたはハイブリッドベースのモニタリング・ツールを提供することもあります。Oracle Cloud Infrastructureの場合、ネイティブのモニタリング、タグ付け、監査機能を組み合せることで、サービス・スタック全体をモニタリングできます。また、指定の基準値を外れた異常は、通常、自動的に修正されます。現在サードパーティのモニタリング・ツールをオンプレミスで使用している場合、そのベンダーはハイブリッドベースまたはクラウドベースのツールも提供している可能性があります。

---

Cisco Tetrationは、コア・アプリケーションをOracle Cloud Infrastructureに移行し、60倍のパフォーマンス向上を実現しています。

「オラクルとのパートナーシップは素晴らしいものでした。Cisco Tetrationでこのように大きな変化が起きているのはそのためです」 — Cisco Tetration、創設者、Navindra Yadav氏

---

パイロット・プログラムの立上げ

どのようなエンジニアリング作業にも言えることですが、小さなパイロット・プログラムやプロトタイプから始めると、パイロット・チームと組織は何ができるか、どのように進めればよいかを理解できるため、成功の可能性が最大限に高まります。パイロット・プログラムと概念実証プログラムでは、組織規模の全面的な変更に伴う時間的、金銭的な圧力を受けずに、課題を特定してトラブルシューティングできます。ゆっくりと作業を進めて、新しい運用環境に慣れることができるので、パイロット・プログラムは変化のスピードに対処するために有効です。

パイロットは、開発者と運用スタッフからなるコア・グループがターゲット・クラウド環境を調査して、アーキテクチャ、サービス、運用モデルを学ぶことのできるオポチュニティです。このチームは、実践的な知識、便利なツール、ベスト・プラクティスや、自信、専門知識、経験の種となるものを築きます。チームは、この知識を構築すると同時に、クラウドベースの環境におけるチーム間コラボレーションへの道のルールを整備しているのです。クラウド移行の際には、アプリケーション・チームが、直接のリソース・マネージャから他のチームが提供するサービスの利用者へと進化する必要があります。アプリケーション・チームは、パイロットを通じて、サービスの境界がどのように変化するかを理解し、使用予定のサービスを提供する運用チームとの関係を構築して、運用チームと一緒に自身のニーズを主張する方法を学ぶことができます。

パイロットでは次のようなメリットが得られます。

• テクノロジの移植性についての仮定を検証する(または疑う)際のコンテキスト。特に、テクノロジが常に同じ環境で実行されている場合に有効です。これにより、チームは移行の準備ができているかどうかを理解し、移行のために何を変更する必要があるかを特定することができます。
• ターゲット環境のサービスと統合するためのアプリケーション/データベースの準備状況を確認するオポチュニティ。これにより、チームは、どのような変更が必要か、アプリケーションとターゲット・サービス環境の両方で移行を実行する準備がいつ整うかを知ることができます。
• ターゲット環境向けに構築し、足場を作る能力。これは、新しいサービスや新しい環境に移行する際に、残りのポートフォリオの出発点になります。これにより、チームはポートフォリオの戦略的目標を得ることができます。

---

Manhattan Associatesは、サプライ・チェーン・ソリューションをOracle Cloud Infrastructureに移行し、以前のクラウド・ソリューションと比べてコストを50%削減しています。

「Oracle Cloudはアプリケーション・レイヤーとデータベース・レイヤーのどちらにおいても多様性と柔軟性に富んでいるため、以前のクラウド・ソリューションと比べて、インフラストラクチャ面で約50%のコスト削減が実現しました」 — Manhattan Associates、バイス・プレジデント、Jeff Demenkow氏

---

パイロット・プログラムの管理

パイロットは、技術スタッフと運用スタッフにとっても、経営陣と管理チームにとっても、学びの多い経験となります。経営陣と管理チームは、パイロット・チームと絶えずコミュニケーションを取ることで、組織的な障害を取り除き、組織がパイロット・プロジェクトから最大限の知識(何がうまくいったか、何が失敗したか、ベスト・プラクティス、学んだ教訓、特定された標準的なパターンやアンチパターンなど)を得られるようにする必要があります。この貴重な情報を収集して組織の他のメンバーと共有することで、その後のクラウド・プロジェクトの有効性と効率性が高まれば理想的です。パイロットにより、経営陣は、計画の作成に使用された仮定を試し、不確実な部分をなくすことができます。この仮定は組織によって異なりますが、どのような移行においても、パイロットで表面化する重要な課題がいくつかあります。

• トレーニング: パイロットでは、既存のスキルが試され、技術的な移行作業への準備がどの程度整っているかが明らかになります。経営陣は、パイロットを使用して、技術的な習熟度を評価し、学習すべき最も重要なツールと機能を理解して、これらの重要な領域のスキルを短時間で伸ばす(または、そのために雇用する)方法を計画する必要があります。
• コラボレーション: パイロットでは、開発、運用、サポートの各チームが異なる方法でどのように協力するかが明らかになります。経営陣は、これらのチームがパイロット中に実際に協力していることを確認する必要があります。これにより、新しい要件を明確化し、この新しい環境での運用方法について理解を深めることができます。
• 変化への欲求: パイロットは、広範な移行に影響を与える文化的障壁に気付くチャンスです。パイロットで苦労するグループは、規模が大きくなっても同じ反応を示します。パイロットは、経営陣が問題を特定して、トレーニングを導入し、特定の組織の現実に対応できるように計画を調整するチャンスとなります。

スムーズな移行の鍵は、強固な基盤を構築することです。移行の最初のフェーズでは、サービスとプラットフォームのコア・セットの開発が促進され、移行が進むにつれて徐々に拡大します。最終的に、これらのコア機能は、移行ポートフォリオ全体をサポートできる規模まで拡張する必要があります。そのため、クラウドの初期リリースでは、成功を収めるだけでなく、その後のリリースやアップグレードのすべてに対応できる助走路を作ることが重要です。

組織の変化への適応

SaaSアプリケーションをホストするためのインフラストラクチャの設計

組織の提供モデルや顧客との関係が変化するのに伴い、新しいスキルや知識、ビジネス・プロセス、考え方が求められることがあります。こうした変化は、組織全体に大きな影響を与える可能性があります。クラウド移行の最も難しい側面は文化の変化であると言われることが多いのはそのためです。

こうした変化の範囲だけでも、クラウドに移行するためには大規模な再編成やクラウドの経験と専門知識を備えた従業員の補充が必要になるという印象を与える可能性があります。社内の職能分化の変化や、クラウドのスキル・セットに重点を置いた新規雇用はクラウド移行の主要な要素ですが、これまでの成功の鍵である確立されたプロセス、ダイナミクス、貢献者を失うことは許されません。組織の変化のスピードと、進行中のビジネスや顧客体験に混乱が生じる可能性とのバランスを取ることが不可欠です。このバランスを維持するには、キャリア開発能力の構造上の変化を再調整して、既存の従業員が新しい運用モデルに移行できるようにする必要があります。

長年続いているソフトウェア・ビジネスをクラウド提供モデルに移行するには、多くの主要ビジネス分野で前提条件、技術的ノウハウ、標準的な運用プロセスを大幅に変える必要があります。必要な変更の量を考えると気が遠くなるかもしれませんが、当社の経験によると、クラウドのエキスパートを全面的に入れ替えようとするよりも、一般的には既存のチームを維持して投資する方が賢明です。組織で同様の移行を計画している場合は、当社のGBU組織が手始めに、変更のニーズに関する分散型のボトムアップ評価をどのように行い(この評価では、各チームがそれぞれの移行インベントリとサービス・スタックのロードマップを作成できました)、それぞれが管理できる範囲で必要なステップをどのように特定したかを確認してください。このアプローチにより、チームは、何が必要になるかを大まかに推測することは避けながら、プログラムと具体的な変更要因との整合性を取ることができます。

---

8x8は、Oracle Cloud Infrastructureに移行することで、世界のつながりを維持し、コストを80%削減し、サービスを向上させています。

「ビデオ会議が今日の新しい世界をつなぐ手段へと急速な変貌を遂げるにつれて、当社のユーザー数も急増しました。この急激な成長をサポートするため、当社ではいくつかのプラットフォームを検討し、オラクルのGen 2 Cloudインフラストラクチャを選択しました。強力なセキュリティ、卓越したコスト・パフォーマンス、この新たなユーザー急増に対応する世界レベルのサポートがその理由です」 — 8x8、CEO、Vik Verma氏

ビデオを見る

---

ビジネスへの影響

クラウドへの移行が成功すると、組織全体の変化が可能になり、組織全体の変化は可能性をもたらします。基本的にホスティング型かオンプレミスのポートフォリオからクラウドベースのビジネスに移行するには、組織が顧客と関わる方法を根本的に変える必要があります。ただし、確立されたビジネス慣行と前提条件がどの程度変化するかは、クラウド移行の際に行われる製品変更の範囲に大きく左右されます。

変化の少ないシナリオでも、IaaSへの移行ではビジネス・プロセスの変化を余儀なくされます。当社のGBUは、この状況における変化の重要なオポチュニティを2つ特定しました。

1. 多額の設備投資を要する物理インフラストラクチャ管理を、短期的な変動と長期的な期待値の根拠となる事業運営費指向の予測モデルに置き換える
2. 従来の責務から解放されたセキュリティ・チームとコンプライアンス・チームを進化させ、サービス・コンポーネントの提供に集中させる

こうした変化とアプリケーションの技術的変更に対処した組織は、クラウド移行の潜在能力を最大限に発揮できるようになります。

顧客の連携

「シュリンクラップ」製品の提供からの移行や、ホスティング製品から実際のクラウド・サービスへの移行には、お客様とお客様の顧客が一緒に取り組むことになります。実際のところ、これまでのあらゆるホスティング方式からクラウドを差別化するのは、このas-a-Serviceモデルへの変更です。クラウド・サービスに加えるどの変更も、スケーラビリティからアップタイム、回復力に至るまで、顧客のエクスペリエンスに影響を与えます。顧客が新しい提供モデルへの変更を依頼したり、要求したりする場合もあります。また、特長、機能、コストへの期待が、クラウドベースの提供でなければサポートできないような方法で進化している場合もあります。

お客様のクラウド戦略に顧客を取り込み始めるにあたり、ロードマップへの期待と慣れ親しんだものから離れることへの抵抗という2つの視点に備える必要があります。こうした視点に対応するには、技術的な詳細にとらわれたり、危険を警告したりすることなく、取組みの方向性を示す、明確で計画的なコミュニケーションが求められます。これは、組織内の顧客対応チームの関与を得て、進行中の取組み、ビジネスによって行われている投資、および製品と提供に期待される成果をチームに確実に理解してもらうための重要な時期です。その際、顧客対応チームは、この変化をサービスへの顧客の信頼を強化する言葉に変換できるよう、積極的に協力する必要があります。

クラウド・サービスを利用する顧客にとっては、シナリオはもう少し複雑になる可能性があります。クラウド・サービスを必要とする顧客セグメントがあります。これは、効率性と敏捷性の点でSaaSから得られるメリットを理解している人たちです。ところが、クラウドまたはSaaSのオプションが重要視されるようになったため、顧客は、クラウド自体の価値よりも、ベンダーのサービスを特徴付ける機能とサービス・レベル合意について知る必要があります。

ただし、すべての顧客がクラウド・サービスを熱望しているわけではありません。特に、ホスティング型やマネージド型のサービス・モデルを使用している既存の顧客は、現状に満足している可能性があります。特注のサービス・コンポーネントや非標準の環境を使用していて、クラウド提供に合わないモデルにアクセスしている場合はなおさらです。クラウド・サービスに移行するメリットを理解している顧客でさえ、提供条件の変更や環境の移行に必要なサービスの中断に不安を覚える場合があります。

顧客を安心させるには、マーケティング、販売、サポート、カスタマ・サクセスの各チーム間の調整と一貫したコミュニケーションが必要になります。ワークロードが移行されたことを顧客がまったく知らず、ある日パフォーマンスの向上に気付くものの、起こった変化には気付かないというのが理想です。現実には、サービスをクラウドに移行するには、アップグレードとダウンタイムの期間が必要になることが多く、場合によっては、サービス条件や利用可能な機能の変更も必要になります。こうしたイベントを通じて顧客を導きながら、移行のタイムライン全般への整合性を維持するのは大変なことであり、変化のメリットを理解する以上のことが求められます。生じる変化を受け入れ、顧客のビジネスに影響を与える可能性のある移行ステップと足並みを揃える必要があります。

---

CMICは、建設エンタープライズ・ソフトウェアをOracle Cloud Infrastructureに移行し、導入スピードを10倍に高速化しています。

「他のクラウド・プロバイダをしのぐOCIのコスト・メリットに加えて、俊敏性も向上しています。OCIにより、新たなレベルの技術的柔軟性が得られました。利用可能な最高の建設ERPソフトウェアを提供することに引き続き集中できるよう、Oracle Container ServicesやOracle Autonomous Databaseなどのテクノロジとともに将来に向かって進んでいます」 — CMIC、ITおよびクラウド・インフラストラクチャ担当ディレクタ、Vince Di Piazza氏

ビデオを見る

---

顧客がクラウドの移行に伴うメリットと変化を支持した後、お客様が実行しなければならない最後のステップは、顧客のワークロードを新しい環境へと実際に移行することです。これは、新しい環境の移行と検証テストに最適な時間を決定するという課題になります。ダウンタイムが発生することを受け入れている顧客でも、そのダウンタイムがいつ発生するかについては、依然として強固な意見を持っていることがよくあります。

顧客の希望は重要ですが、他の多くの懸念のバランスを取る必要があります。移行の計画には、製品またはサービスの技術的属性、すべての顧客の希望の調整、社内リソースの制限、既存のレガシー・データ・センターの統合/廃止や非推奨の製品ラインの終了といったビジネス目標など、多数の要因のトレードオフが関係しています。このような相反する優先事項のバランスを取るために、顧客対応チームを移行計画活動に参加させてください。顧客対応チームは、市場の期待を表す上で重要な声になるからです。

お客様の組織は、投資と移行の期間だけでなく、クラウド提供モデルの技術面、ビジネス・プロセス面での継続的な変化にも備える必要があるように、移行に関して顧客の関与を得る方法と、製品と顧客の関係における新たな現状の両方にも備える必要があります。

当社のGBUは、これらのニーズに応えるために、まず移行が技術面と運用面、および提供コミットメントの観点から顧客にどのように影響するかを確認し、特別な注意や関与を必要とするもの、および商取引関係の変化を要する可能性があるものを分離しました。顧客対応チームの準備に向けた取組みも同様の観点に基づいて行われます。その中で、製品、運用、戦略、その他のチームが協力して一般的なクラウド・リテラシを提供すると同時に、特定の製品や顧客の変化に対処しています。

この取組みは、単に顧客対応チームが顧客と関わりを持つ準備をすることだけが目的ではありませんでした。部門を超えた核となるリーダーシップを結集して顧客エンゲージメントの足並みを揃えることで、主に技術的に主導されていたプログラムを、ソリューションのコア・バリューの再検討、製品の差別化要因の再明確化、および市場内でその価値を維持し、成長させる最善の方法の計画に関する幅広いイニシアティブに拡大することのできる貴重なオポチュニティも生まれました。

事前の準備

SaaSアプリケーションをホストするためのインフラストラクチャの設計

このプレイブック全体を通して、数千のインスタンスでホストされている60を超えるGBUアプリケーションの移行を通じて学んだ教訓に基づき、ベスト・プラクティスのガイダンスを提供しました。移行の過程で当社が直面した課題トップ5を以下に要約します。これらは、アプリケーションをクラウドに移行するすべての組織に当てはまるはずです。

1. 移行前の開発作業の決定
   クラウドのリリース用に確立されたアプリケーションを準備するには、特に製品をクラウド・ネイティブな状態にするために、多額の投資が必要になる場合があります。クラウド・ネイティブ・アプリケーションの原則への投資は、クラウドから得ることのできる最大のメリットをもたらす一方で、最終状態に達するまでに多くの時間と開発リソースを消費します。製品をクラウドに対応させるのにかかる時間が長くなればなるほど、クラウドに移行することで本来得られる段階的なメリットの実現が遅れるとともに、通常はレガシー環境に関連するリスクにさらされる期間が長引く可能性があります。それと同時に、製品のライフサイクル・フェーズと顧客の態勢によっては、すべての製品から同じようにメリットが得られるわけではありません。移行を成功させるには、移行前に行う開発作業の量を十分に理解して文書化することが重要です。
   
   GBUのアプリケーション・フリートは多様で、あらゆるクラウド成熟度レベルとライフサイクル・フェーズの製品が含まれています。すべてのアプリケーションをクラウドに移行する必要がありましたが、クラウドのリリース前にどの程度の製品変更を行うべきかという問題で苦労しました。正しいバランスを見つけるには、各製品のライフサイクル・ステージ、成長の可能性、製品をクラウドに移行するために必要な労力を評価する必要がありました。GBUはこうした評価を組み合せて基準とし、各製品に与える優先度と費用のレベルを決定しました。
2. 開発の配分の決定
   クラウド投資への準備と市場の要求に応じた新機能の開発を比較したときに、それぞれにどれだけのエンジニアリング労力を割くかは、GBUにとってバランスを取るのが難しい問題となりました。
   
   GBUがクラウド移行の優先順位に関する調整を十分に行っていなかったわけではではありませんが、顧客のエクスペリエンスとパフォーマンスを向上させるものの、顧客が要求する機能の代わりにはならないクラウド機能にどれだけの労力を割くべきなのか、製品チームにはよくわかりませんでした。クラウド開発のためには、基盤となる運用機能に投資する必要がありますが、その結果、新機能に対する顧客の要求に応えられなくなる可能性があります。こうしたトレードオフにより、クラウドへの準備と製品の強化という2つのイニシアティブの間で時間をどのように配分するかを見極めるのが難しくなります。
   
   この課題に対応するために、GBUは、第1章で説明したクラウド成熟度フレームワークを基に、それぞれの道筋に要する相対的な開発投資についてのインサイトを得ました。次に、考えられるクラウド移行段階ごとのROIを調査し、その結果と、新機能の開発で期待される潜在的な利益貢献度を比較検討しました。これにより、労力の正しい配分を決定するために使用できる共通の評価フレームワークが得られ、目標とするビジネス成果の可視性を維持できるようになりました。

   ---

   Altairは、Oracle Cloud Infrastructureでの高パフォーマンス・コンピューティングを選択し、コスト・パフォーマンスを20%向上させています。

   「世の中のクラウド・ベンダーをすべて調べたところ、オラクルはHPCに非常に注力していることがわかりました。同社のベア・メタル・サービスは業界初だったと思いますが、高速で低レイテンシのネットワーキング機能を備えていました。これは当社にとって非常に重要です」 — Altair、戦略的関係担当シニア・バイス・プレジデント、Piush Patel氏

   ---

3. フリートの理解
   会社のアプリケーションが1つだけであろうと大規模なポートフォリオであろうと、クラウド移行中に追跡し、洗い出す必要のある要因が多数存在します。どのような変更を加える必要があるかを完全に把握するには、既存のアプリケーション・リポジトリを網羅した最新のインベントリと、クラウドで何を利用する予定であるかを完全に理解しなければなりません。移行するアプリケーションが多い場合は、既存のインベントリが存在しなかったり、特定のアプリケーションの状態に関する文書化されていない知識に依存していたりする可能性があります。顧客向けアプリケーションを1つしか持たない企業でも、アプリケーション・スタック全体のインベントリを作成し、クラウドへの移行時にどの側面を変更する必要があるかを判断する必要があります。クラウドではどの要件が変化するか、設計がどのように見える必要があるかを理解することは、移行に必要な作業を文書化するための重要な側面です。
   
   アプリケーション・インスタンスの特性(バージョン、ハードウェア/プラットフォームの依存関係、カスタマイズ、顧客のアクセス・モデルなど)に応じ、各インスタンスに関して様々な種類と量の作業が必要になります。さらに、アプリケーション・データは複数の記録システムに分散している可能性があります。
   
   Oracle GBUは、買収された30社を超える企業の統合により生まれた組織で、80のデータ・センターと12,000を超えるアプリケーション・インスタンスにまたがるフリートを擁しています。これらのインスタンスに関連する重要なデータは非常に細かく断片化されており、必ずしもコンポーネント製品チーム全体で一貫した方法で管理されていません。この情報がなければ、移行作業を効果的に体系化し、計画することはできませんでした。何を移行する必要があるかを明確に理解するために、GBUは熱心なデータ収集と統合の取組みに乗り出す必要がありました。

   ---

   「OCIに移行することで、Oracle GBUチームは設備投資を80%低減し、インフラストラクチャのコストを64%削減することができました」 — GBU Cloud Architecture、バイス・プレジデント、Mike Prindle
   

   ---

4. 移行作業の優先順位付けと体系化
   ワークロードを実際に移行するには、既存のVMのイメージのコピーから、新しいインスタンスのインストールやデータのレプリケートまで、様々な経路をたどることができますが、そのすべてを完了するために、ある程度の技術投資または労力のコミットメントが必要になります。移行に伴う作業の量と多岐にわたる種類は、組織のフリート内の製品環境ごとに増加し、すぐに圧倒的な規模となります。作業を完了するために利用できるリソースは有限であり、多くの場合、日常業務の管理も担当しています。

   ---

   OceanXは、ビジネス・インテリジェンス・システムをAmazon Web Services (AWS)からOracle Cloud Infrastructureに移行して、3倍のパフォーマンス向上を実現しています。

   「当社では、データ・プラットフォームを拡張して、高いパフォーマンスを低コストで提供する必要がありました。AWSからOracleへのデータ・プラットフォームの移行は、OceanXで最も成功した移行の1つであり、大幅なパフォーマンス向上と多額のコスト削減が相まって、プログラム全体が大きな成果を上げました。その結果、最終的には、より多くの情報に基づいた意思決定をより迅速に行えるプラットフォームをクライアントに提供できるようになっています」 — OceanX、データおよび分析担当バイス・プレジデント、Vijay Manickam氏

   ---

   GBUのクラウド移行には、3,000を超える個別の移行プロジェクトが必要でした。これらのプロジェクトには当初、顧客の希望(統合された顧客フィードバックに基づく移行時間枠の優先順位付け)や特定の環境の移行準備状況に基づいて優先順位が付けられていました。最終的に、このアプローチはうまくいかず、移行の過程でビジネス上のメリットを徐々に増やしていくことはできませんでした。優先順位付けや調整のための共通のフレームワークがなかったため、移行活動の量には一貫性がありませんでした。その結果、リソースの競合が多い期間とリソースの可用性が無駄になる期間が交互に発生し、移行作業を完了する責任のあるチームに負担がかかりました。
   
   こうした課題を解決するために、GBUは、移行専門の中央プログラム管理オフィスと、目標とするビジネス成果に照らした移行作業の優先順位付けと移行のオポチュニティの特定を担当するエグゼクティブ監督委員会の両方を設立しました。
5. 組織変更の管理
   クラウド移行に伴う変化により、新たな知識、スキル・セット、プロセスの領域に加えて、その他の文化的変化の領域が必要になります。こうした人的資源に関する課題の管理は、クラウド移行の技術的要素よりも難しい場合があります。これに対処するために、Oracle GBUは、既存のチームがクラウド・チームに進化できるようトレーニングに重点を置きました。新しい人材をいつ投入するのか、それとも他の方法で組織を進化させるメカニズムをいつ見つけるのかという問題をなんとか解決するため、GBUでは、主要な機能領域と製品グループに対する労働力評価を実施し、各ユース・ケースに対して適切な改善イニシアティブをマッピングする必要がありました。移行するアプリケーションが社内に複数ある場合は、セキュリティや一般的なIaaSなど、すべての製品にまたがる基本的なクラウド知識をどこに培うことができるかを検討してください。

結果を受け入れる

このプレイブックは、Oracle GBUチームが60を超えるSaaSベースのアプリケーションをOracle Cloud Infrastructureに移行する中で蓄積した知識に基づいています。これらのアプリケーションは、8つの業種のコア・エンタープライズ機能と、世界中の199,000を超える顧客をサポートしています。計画を立てて適切に実行した入念な移行は、大きなメリットをもたらしました。

• 80のデータ・センターを11に統合
• 設備投資を80%削減
• インフラストラクチャのコストを64%削減
• ソフトウェア・ベンダーを28から10に削減
• ソフトウェアの費用を42%削減
• 毎日のソフトウェア・リリースに移行
• プロビジョニング時間を98%以上短縮
• 計画的ダウンタイムを98%以上短縮

このISVプレイブックは、GBUチームが学んだ知識に基づいていますが、チームの努力は、Oracle Cloud Infrastructureへの数ある大規模な移行の1つにすぎませんでした。SaaSアプリケーション全体の収益と顧客数を考えれば、オラクルは世界最大のISVの1つであると言うことができ、当社は移行プロセスを理解しています。実際に、Oracle Fusion Cloud ERP、Oracle Fusion Cloud EPM、Oracle Fusion Cloud HCM、Oracle Advertising and CX、Oracle Fusion Cloud SCMを含む製品ポートフォリオ全体をOracle Cloud Infrastructureに移行しました。こうした移行は、Oracle@Oracleと呼ばれる当社の変革イニシアティブの一部です。これは、数十のデータ・センターに散在する数万のアプリケーションを対象とした、何年にも及ぶプロジェクトでした。

こうした努力の結果として得られたいくつかのメリットを以下に示します。

• インフラストラクチャ – アプリケーション・ポートフォリオ全体で99.99%の可用性を実現し、30%のコスト削減と2～10倍のパフォーマンス向上を達成
• 財務 – 10日以内に決算を終了して収益を報告することが可能に
• 人事 – タレント・レビューのサイクル時間を70%短縮
• サプライ・チェーン – サプライ・チェーンの計画サイクルを1週間から48時間に短縮—71%の改善
• CX – キャンペーンのリード・タイムを4週間から5日に短縮—82%の改善
• サステナビリティ – 2019年度にオラクルで回収された、使用しなくなった機器の99.4%を再利用またはリサイクル

オラクルとのパートナーシップ

当社は、ISVが対応可能な市場を拡大し、総収入増大の可能性を高めることができるよう支援しています。詳細は、oraclecloud-isv_ww@oracle.comまで電子メールでお問い合せください。

ISVがOracle Cloudを選択する理由の詳細は、次のリソースを参照してください。

• isv.oracle.com
• ISV向けOracle@Oracleプログラム
• クラウド・ホスティングに関する考慮事項とパターンのマイクロサイトを見る

---

Körberは、倉庫管理システムをOracle Cloud Infrastructureに統合し、実行スピードを40%高速化しています。

「様々な意思決定ポイントを評価したとき、OCIは、当社がGo-to-Market戦略の観点から目指していたことに対して非常に戦略的でした」 — Körberö、北米セールスおよびアライアンス担当シニア・バイス・プレジデント、Rick Schrader氏

ビデオを見る

---