大規模エンタープライズクラウド移行における4つの重要な問題と解決策

著者  |尹大偉

今日では、クラウド コンピューティングによって提供されるリソースとホスティング サービスの柔軟なスケーリング機能をタイムリーに活用することが業界のコンセンサスとなっています。クラウドを導入して使用するかどうかは、もはやオプションの問題ではなく、企業にとって必須の問題です。ビジネスをクラウドに移行できるかどうか、つまり、企業がクラウドとそのエコシステムが提供する新しいテクノロジーとプラットフォームを真に効果的に活用して、ビジネスを強化し、デジタル変革を加速し、企業の競争力を強化できるかどうかは、多くの企業にとって依然として大きな課題です。

多くの企業にとって、ビジネスをクラウドに移行する道のりはスムーズではなく、特にクラウドベースのシステムの規模が比較的大きい場合（システムの数が数百または数千に及ぶ場合）、および多くのビジネスラインが関係する場合は、非常に困難であるとさえ言えることが観察されています。課題は技術レベルからだけではなく、組織構造、チーム能力、研究開発システムからも生じます。また、クラウド移行を自社の業務をクラウドに移行することが目的であると考えている企業もありますが、業務のクラウド移行はデータセンターからクラウドへのシステムの移転と同一視されやすいため、明らかに不合理です。結局、コスト削減や効率化、応答性の向上、ビジネスの強化など、企業が期待するクラウドへのビジネス移行の価値目標を達成することは困難です。

この記事では、企業のビジネス クラウド移行の原動力と課題について詳しく検討するほか、独自のシナリオに適したビジネス クラウド移行戦略を効果的に計画し、リスクをできるだけ早く特定し、部門間およびチーム間のコラボレーション メカニズムを確立してビジネス クラウド移行を加速する方法についても説明します。

クラウドへのビジネス移行を推進する原動力

企業がビジネスをクラウドに移行する要因は数多くありますが、一般的な要因としては、コストの削減と効率性の向上、ビジネスの応答性の向上、新しいテクノロジー、ポリシー、コンプライアンスによるデジタル変革の実現などがあります。一部の企業では、クラウド移行プロセス中にビジネス アーキテクチャを再設計することもあります。このプロセスには通常、今後数年間のビジネス ビジョンと目標が伴います。

これらの原動力を注意深く分析すると、隠れた前提が明らかになります。それは、現状を維持するだけでは、会社のビジネスや競争力が向上するわけではないということです。変化しないか、さらに悪化する可能性もあります。システムをクラウドに移行するだけでは、企業のビジネス クラウド移行にはつながらないと前述したのは、この場合、データ センターからクラウドへのインフラストラクチャの変更以外、ビジネス モデルや競争力は根本的に変わっていないためです。したがって、企業がクラウドへの移行を選択する場合、その背後にある隠れた原動力は、ビジネスモデルとテクノロジーの変更を通じて企業を再構築するプロセスである競争力の再構築です。

「6R」の観点から見たクラウドへのサービス移行の課題

6R は通常、企業がクラウドへの移行を計画する際に推奨される戦略です。 6Rについてはインターネット上にすでに多くの説明があるので、この記事では詳しく説明しません。詳細については、「アプリケーションをクラウドに移行するための 6 つの戦略」を参照してください。 6R はアプリケーションをクラウドに移行するための戦略を分類できますが、いくつかの問題を引き起こす可能性もあります。たとえば、企業は通常、スピードのためにリフト アンド シフト、つまり仮想マシンをイメージにパッケージ化してクラウドに移行することを採用します。クラウドベンダーにとって、これは自社の収益モデルに最も適したアプローチですが、企業にとってそのメリットは非常に限られており、予想よりも低いものになることもあります。

さらに、6R はクラウド移行プロセス中に価値ギャップの問題を引き起こす可能性があります。あなたのクラウドジャーニーは価値のギャップで行き詰まっていませんか?これは、Thoughtworksの元主任コンサルタントであるGregor Hohpeによって造られたものです。

たとえば、高い価値を迅速に生み出すために、技術的な製品やソリューションを購入したいとします。しかし、組織構造、プロセス、能力、研究開発システムが新しいテクノロジーにうまく適合できないため（組織変更）、実際の利害関係者（ビジネス側など）が認識する実際の価値は、期待される価値よりもはるかに低くなります（価値ギャップ）。 6R を導入する場合、テクノロジーに焦点が当てられるのが早すぎる傾向があり、必要な組織の変更がさまざまな理由で遅れたり無視されたりして、価値のギャップが浮き彫りになります。

さらに、規模も注意を払う必要がある課題です。ビジネスのクラウドへの移行は、通常、企業の IT 部門の責任です。 IT チームは、ビジネスの継続性を可能な限り確保し、既存のビジネスへの影響を軽減する必要があります。クラウド移行計画と戦略を策定する場合、アプリケーションとシステムの数が多いため、IT チームはビジネス コンテキストを習得し、多数の関係者を管理する必要があります。

そのため、ビジネス確保を前提に、ビジネスをクラウドに移行する戦略を策定する際には、テクノロジーがもたらす課題に加え、多くの参加者が一貫した目標を維持できるようにする方法、チーム間で効果的にコミュニケーションをとる方法、リスクをできるだけ早く特定して管理する方法など、考慮すべき点も多くあります。

クラウドコンピューティングにおける4つの重要な問題

そこで、ビジネスをクラウドに移行する際に対処する必要がある 4 つの重要な問題、つまり、構築方法、推進方法、移行方法、進化方法をまとめました。

どうやって構築するのですか?

構築の重要なポイントは、業界の製品やソリューションの調達と企業自身のニーズとのバランスをどのように取るかにあります。業界の製品やソリューションがいくつかの共通の問題を解決できることは否定できませんが、各企業には独自の特殊性があり、製品は企業のニーズに応じてカスタマイズされるだけでなく、上流および下流のシステムやプロセスと統合できることも求められます。購入する製品やソリューションが多数ある場合、製品プロバイダーによって効率性、機能、さらにはカスタマイズされたニーズへの対応意欲が異なるため、これらのカスタマイズと統合をどのように管理し、独自のクラウド計画や戦略とどのように一致させるかが重要な問題になります。

したがって、どのように構築するかという質問に答えるためには、企業は自社のビジネスビジョン、ニーズ、シナリオに立ち返り、これを出発点として将来のビジネスとデジタル機能に対する要求を逆に構築し、次に市場にあるさまざまな製品とソリューションを評価し、最終的にどれを購入する必要があり、どれを自社で構築する必要があるかを決定する必要があります。これは、将来のテクノロジー プラットフォーム、さらにはビジネス ミドル プラットフォームを構築するための基盤でもあります。たとえば、クラウドベンダーや関連テクノロジー製品（関連するDevOpsやマイクロサービスプラットフォームなど）を選択する際には、さまざまなオプションの機能や価格を比較するだけでなく、価値の高いニーズやシナリオ、自社の機能要件を整理して代替オプションを検証・評価する必要があります。

どのように宣伝するのですか?

ビジネスをクラウドに移行するときに、なぜプロモーションを考慮する必要があるのか​​疑問に思うかもしれません。何を宣伝しますか?誰を昇進させるか?これらの問題は、実際には、デジタル変革の時代における企業の従来の IT の位置付けの変化によって引き起こされています。これまで、IT は主にデータ センターに依存して、ビジネス パーティや研究開発チームにリソースのサポートと運用および保守を提供してきました。そのため、チームの規模は限られており、ほとんどの時間が大量のチケットの処理に費やされていました。この位置付けの結果、IT 自体はビジネスから比較的遠く離れており、企業の研究開発システムにおいても比較的低いレベルまたは周辺的な位置にあります。そのため、IT は企業のコスト センターであると言われることがよくあります。企業がビジネスをクラウドに移行することを決定した後、IT自体の位置づけも大きく変化しました。 IT 自体は多くの新しいテクノロジーや課題に対処する必要があるだけでなく、新しいテクノロジーを実現する責任も負わなければなりません。ここでの権限付与は、ビジネスに権限を与えるだけでなく、R&D チームにも権限を与えます。 R&D システムの観点から見ると、IT は R&D システムのエッジから R&D システムのコアへと移行しています。

エンパワーメントを図りたいのであれば、新しいテクノロジーを自社のニーズに合った機能やサービスとしてパッケージ化し、提供することが最善の方法です。このため、多くの企業が多数の技術プラットフォームと技術サービス製品を形成し、それらを異なるチーム（インフラストラクチャ チーム、プラットフォーム チームなど）に分割していることがわかります。彼らの責任は、新しいテクノロジーをパッケージ化し、R&D チームの学習コストと使用コストを削減することで、エンパワーメントの目的を達成することです。 IT自体の位置づけも、リソースの提供、運用・保守、チケットへの対応から、社内技術プラットフォームや製品の提供へと変化しています。

何を宣伝しますか?プロモーションの主体は、企業の内部技術プラットフォームと製品です。誰を昇進させるか?ビジネスサイドのR&Dチーム。プロモーションの成功を測る方法も、ユーザーがいるかどうか、使いやすいかどうか、エクスペリエンスはどうか、先進的かどうか、SLAはどうか、効果はどうかなど、一連の重要な指標になっています。したがって、プロモーションの背後にある根本的な原因は、ITがサービス指向のチームから製品指向のチームに転換することであり、そのためにはITが特定の製品設計思考を持ち、ビジネスを常に理解し、開発者のエクスペリエンスの観点を最適化し、高度にカスタマイズされたサービスを設計する必要があります。

移行方法は？

移行を単独で見ると、それは単なるアプリケーションの再配置です。しかし、前述したプロダクトチームの位置づけと合わせると、移行の意味は全く異なります。それは、製品トラフィックとサービスを引き付ける方法です。効率的で、標準化され、繰り返し可能でなければなりません。

移行サービスを、一連の操作と組み立てを通じてアプリケーションを変換できる移行工場や生産ラインとして説明している企業もあります。しかし、この方法の実現可能性には前提条件があります。生産ラインでは、原材料の処理方法が明確で、繰り返し可能である必要があります。企業内で移行する必要があるアプリケーションのほとんどは、レガシー システムです。これらは互いに異なっており、古いアーキテクチャを使用している可能性があり、そのテクノロジは最新のアプリケーションとは大きく異なります。これらは長年にわたって修正されており、ビジネスコンテキストの欠如と相まって、変更によってビジネスに制御不能なリスクが生じる可能性があります。そのため、古いシステムの変革は非常に困難であり、完了するまでに数年かかる場合も少なくありません。さらに、IT チームは以前はビジネスから遠く離れており、既存のビジネス アプリケーションを包括的に理解していなかったため、ターゲットを絞った移行計画を設計できず、ビジネス側と IT の間で対立が生じやすく、移行プロセスが困難になっていました。

したがって、効果的な移行計画をどのように設計するかは、アプリケーション自体に関する知識のレベルに依存し、プロセス全体を一夜にして完了することは困難です。しかし、トラフィック生成の観点から考え、移行サービスを製品に、アプリケーションをユーザーと比較すると、マーケティングアプローチを使用して移行戦略と計画全体を設計できます。

まず、アプリケーション自体の保守と管理は主に IT 側で行われるため、データの埋め込みを通じてユーザー データを取得するのと同じように、アプリケーションを記述するための一連の機能ライブラリを確立できます。これらの機能は、プログラミング言語、データベース、統合関係、ミドルウェアなど、静的なものである場合があります。また、上流と下流のビジネス間の呼び出し関係や、アプリケーション間の依存関係など、動的なものもあります。機能を確立することで、いくつかのルールに従ってアプリケーションを分類することができます。分類の目的は、アプリケーションをすばやく理解し、アプリケーション間の類似点を見つけることです。類似性により、分類用に設計された移行計画をある程度再利用できるようになります。アプリケーション機能のキャプチャを自動化し、いくつかの視覚化ツールや分類アルゴリズムと組み合わせると、IT 部門が適切な移行計画を迅速に策定するのに大いに役立ちます。

どのように進化するのでしょうか?

ビジネスは市場の変化に応じて絶えず調整されるため、技術の反復のペースも加速しており、企業の内部プラットフォームとテクノロジー製品を継続的に更新およびアップグレードする必要があります。進化の鍵は、ユーザー中心（ビジネスチームと研究開発チーム）になり、プロダクト思考とデザイン思考を適用し、ビジネスとともに進化できるかどうかにあります。

まず、事業ビジョンに基づいて開発段階を開発します。ビジネスとの協力を通じて、ビジネスへの理解を深め、ビジネスニーズをプラットフォームや製品の戦略的ニーズに変換し、製品のイテレーション計画に参加します。第二に、独自のデジタル運用システムを徐々に確立します。指標システムの設計は、IaaS、PaaS、SaaS の側面から実行でき、この目標を念頭に置いて継続的に最適化できます。 3 番目に、チーム トポロジを通じてチーム間のコラボレーションを最適化します。プラットフォームチームとエンパワーメントチームを設立し、R&D活動に積極的に参加します。 R&D チームの問題点を最前線から観察・理解し、現在のサービスの機能、経験、有効性が R&D チームの要件を満たせるかどうかを評価し、開発者の経験を製品の進化に取り入れます。

ビジネス移行のためのクラウドベースのシステムの全体像

上記の 4 つの主要な問題をビジネス クラウド移行のシステム パノラマにまとめ、それを使用してエンタープライズ ビジネス クラウド移行の戦略とロードマップをガイドおよび計画します。

このシステムは、実際のアプリケーション機能データから開始し、アプリケーションを分類し、移行プロセス、ツール、方法を標準化し、企業のデジタル化プロセスを加速することで、アプリケーション移行の複雑さを軽減します。同時に、IT が独自のデジタル運用システムを確立し、製品思考とデザイン思考を適用してビジネスとの共進化を実現するのにも役立ちます。

データ駆動型アプリケーション機能ライブラリ

アプリケーション機能は、アプリケーションの静的機能と動的機能に分けられます。静的機能とは、ビジネス ドメイン、プログラミング言語、依存ライブラリ、データベース、ミドルウェア、送信記録、ビルド頻度など、開発状態からのデータです。動的機能とは、上流と下流の呼び出し関係、呼び出しリンク、呼び出し頻度、結合度、ログなど、ランタイムからのデータです。同時に、アプリケーションの運用と保守、および生成されるデータは主に IT チームによって管理されるため、IT チームが自動化されたアプリケーション機能データ収集システムを確立して、アプリケーション機能のリアルタイム収集と更新を実現すると便利です。アプリケーション機能ライブラリを確立することで、IT チームはビジネスおよびアプリケーションのコンテキストの不足を効果的に補い、ターゲットを絞った方法で移行および変換計画を設計できるようになります。

アプリケーション分類が移行戦略を推進

アプリケーション機能ライブラリを使用すると、neo4j などのグラフ データベースを使用して、クラスタリング アルゴリズムを通じてアプリケーション間の関係を見つけて視覚化できます。アプリケーションの類似性を識別して分類することは、ユーザー特性を分類することと似ています。類似した特性を持つアプリケーションは、類似した移行戦略と方法を採用できることを意味し、つまり、このタイプのアプリケーションに基づく移行方法を、このタイプのアプリケーションで再利用できることを意味します。さらに、異なる分類は移行の難しさやリスクも表すため、アプリケーション移行のコストを迅速に見積もったり、対応計画の策定を容易にしたりすることができます。

このカテゴリのサンプル ルームとして、最も複雑なアプリケーションやビジネスにおける主要なアプリケーションなど、特定の特性を持つアプリケーションを選択することをお勧めします。移行の初期段階では、IT チームはモデル ルームの移行が成功するようにリソースを投資し、移行の実践と経験を要約して改善する必要があります。一方で、これらの実践と経験は、このカテゴリの他のアプリケーションで再利用できます。一方、最終的には全体的な移行戦略のプラクティスとツールをアップグレードし、プラットフォーム サービスの形で提供することもできます。

デジタルオペレーションインデックスシステム

ますます多くのアプリケーションがクラウドに移行されるにつれて、IT チームはクラウド プラットフォームのデジタル運用インジケーター システムの確立を徐々に検討する必要があります。デジタル運用指標システムを確立する方法は、クラウド プラットフォームを企業の内部製品として扱い、製品の観点からプラットフォームのサービス品質と成功基準を定義することです。特定の指標を確立する際には、複数の側面を考慮することができ、プラットフォームのさまざまな段階に応じて策定することもできます。移行の初期段階であれば、サービスアプリケーションの数やリソースの使用率などを指標として活用できます。ほとんどのアプリケーションが正常に移行された場合は、開発者の満足度、サービスの可用性などの指標に応じて調整することを検討できます。

デジタル運用指標システムの構築は、思考パターンの全面的な変革であり、チームはユーザー価値から始めて製品思考を適用し、プラットフォームとサービスの製品力と競争力を継続的に改善・強化し、最終的に自らの価値を反映する必要があります。

要約する

大規模ビジネスをクラウドに移行することは、大規模なシステムプロジェクトです。課題は、テクノロジーだけでなく、企業内の多くの関係者を調整し、独自のプラットフォームの構築と将来の進化も考慮することです。 IT チームは、これまでの優位性を最大限に活用し、アプリケーション データを収集および分析することで、企業のニーズを満たすビジネス クラウド戦略とプラットフォームを確立し、企業のデジタル変革におけるイネーブラーの価値を実証できます。