SaaS への取り組み: Dynamics 365

多くの独立系ソフトウェア ベンダー (ISV) は、オンプレミスのソフトウェア配信からクラウドベースおよびサービスとしてのソフトウェア (SaaS) ベースの配信モデルへの移行を検討しています。 Microsoft では、多くの製品でこの取り組みを行ってきましたが、実際の経験と、その過程で学んだ重要な教訓を共有するように求められます。

この記事の目的は、Microsoft Dynamics 365 を構築したときのこの体験の概要を説明することです。 私たちは、私たちが行った思考プロセスと、私たちが行った主要な決定の主要な要因について説明します。 このドキュメントでは、オンプレミスソフトウェアの提供から、何千もの組織の何百万人ものユーザーが使用するハイパースケール SaaS 製品への移行に伴い、製品の進化の感覚を提供することを願っています。 このドキュメントを読むことで、Microsoft の経験から学び、SaaS への独自の旅を計画できることを願っています。 Dynamics 365 での Microsoft の取り組みはユニークかもしれませんが、学習した教訓と原則は、SaaS モデルへの独自の移行を計画しているあらゆる規模の組織に価値のある分析情報を提供できる可能性があると考えています。

私たちの旅の簡単な歴史

Microsoft Dynamics は、一連のオンプレミス製品として深い歴史を持っています。 提供される多くの利点すべてにクラウドを採用し、SaaS の提供に向けて移行するにつれて、テクノロジとビジネス モデルを適応させる必要があることを理解しました。

私たちが直面した最初の決定は、新しいものを構築するか、オンプレミスのアプリケーションをクラウド サービスに進化するかの選択でした。 Dynamics 365 では、2 つのことが考えられていました。 まず、データ モデルとビジネス ロジックに十分な価値があり、何千もの顧客と共に作成し、既存のソリューションを進化させる価値があることを検証しました。 2 つ目は、オンプレミス製品の階層型アーキテクチャとプラットフォーム フレームワークにより、ゼロから始めるよりも迅速に優れたクラウド アーキテクチャを採用できるようにするための適切なレバーを提供しました。 価値と速度の組み合わせと、クラウドネイティブの原則を採用できるという理解により、クラウドベースの SaaS に移行し、継続的な改善を Dynamics 365 に適した選択肢にしました。 他の組織では、優先順位が異なり、戦略が異なる場合があります。

早い段階で、Microsoft Azure プラットフォームで構築できる最適な製品の構築に集中することにしました。 クラウド プラットフォームは急速に改善され、複数のクラウドにリソースを分散するのではなく、1 つのプラットフォームの豊富さを活用したいと考えていました。 他の SaaS ベンダーは、独自の状況に基づいて異なる決定を行う場合があります。 たとえば、水平プラットフォーム プロバイダーは、顧客が複数のクラウドで使用するためのソフトウェアを構築する可能性があるため、それらの各クラウド プラットフォームにプレゼンスを持つことは理にかなっています。 ただし、SaaS アプリケーション開発者は、1 つのクラウドに集中し、その 1 つのクラウド プロバイダーとその進化に焦点を当てるという利点を得ることができます。 Dynamics 365 の場合、Microsoft Azure でオールインすると、堅牢なセキュリティと高いパフォーマンスを維持しながら、より統合されたシームレスなエクスペリエンスが得られます。

Azure プラットフォームを深く探索し、SaaS 体験を計画し始めたら、クラウドで大規模なエンタープライズ リソース プランニング (ERP) プラットフォームを運用およびスケーリングする方法を学習しました。 同時に、Azure は豊富で能力が高くなり、想像もできなかった新しい機能が導入されました。 クラウドが絶え間なく進化しているため、私たちの移行は一度だけでは終わらないことを理解していました。 代わりに、私たちは私たちの旅のすべてのステップで継続的な改善について考えた。 継続的な改善は、私たちが行うすべてのことに影響を与え、私たちの旅の初期段階では、全体的なアーキテクチャからデータベース クエリの処理方法まで、すべてを大幅に変更する必要がありました。 Microsoft は、クラウドで実現できる機能を最大限に活用するために、常にソリューションを進化させ続けています。 マイクロサービス アーキテクチャを採用しており、継続的な進化の一環としてジェネレーティブ AI を使用しています。 これらのアプローチとテクノロジは、Microsoft Azure などの強力なクラウド プラットフォームを使用すると、構築、デプロイ、運用が容易になります。

クラウドの継続的な改善に不可欠な要素は、テレメトリです。 効果的なテレメトリを使用すると、個々の機能レベルまで、アプリケーションがどのように使用され、どのように実行されるかを理解できます。 テレメトリは、問題の再現やデバッグなどの従来のオンプレミスのアプローチに従う代わりに、何が起こったかを把握することで問題を解決できる分析情報を提供します。 テレメトリを使用すると、実際のデータに基づいてエンジニアリング上の決定を行い、実験とデータを通じて製品の仮説を確認することもできます。 テレメトリ インフラストラクチャ と、保持されるデータとその期間、および管理方法に関する適切なポリシー を作成することは、できるだけ早く行う必要があります。

アプリケーションによって管理されるデータのデータ分類と保持ポリシーを理解するには、SaaS への取り組みの一環として特に注意が必要です。 SaaS プロバイダーとして、現在および新しいデータ プライバシーに関する法律に基づくお客様の責任は、顧客が展開して実行したソフトウェアを提供した場合とは異なります。 SaaS プロバイダーとして適用されるデータ プライバシー規制を理解することが不可欠です。 また、クラウド体験の開始時にデータ分類と保持プロセスを実施する必要もあります。

どのように私たちは旅のために準備しました

MVP のスコープ設定

当社の戦略では、可能な限り迅速にソリューションを顧客に提供し、SaaS の固有の課題と機会について学び始めることができるように、実行可能な最小限の製品 (MVP) を構築することに重点を置いていました。 この焦点は戦略的な選択でした。 クラウドでは迅速な学習と反復が不可欠であり、MVP の定義を開始する場所であると考えています。

実用最小限の製品という用語は、しばしば誤解される。 MVP の両方の属性が同様に重要であることを考慮することが重要です。

• 最小値: 顧客の価値の生成を最も迅速に開始する方法を見極めます。 顧客がソリューションを使用する時間が早ければ早いほど、ソリューションの使用方法と改善を続ける方法を学習し始めます。
• 実行可能: 製品のスコープを設定して、誰かが実際の価値を得られるのに十分な範囲にすることが重要です。 最初に、構築する予定の全体的な機能のサブセットを選択します。 適切なサブセットを選ぶことが重要です。最小限すぎて実行不可能であれば、顧客は製品を使用せず、進化するために必要なフィードバックを得ることができません。

Dynamics 365 では、お客様が発売からすぐに使用できる状態の製品を作成することに重点を置いていました。 その後、お客様がそこから価値を得る方法を学習し、大量のフィードバックとテレメトリを得ました。 そのデータを使用して、製品体験を通知し、反復処理を行い、進捗に合った改善を行いました。

私たちの戦略は、新しい顧客が好む製品を構築することでした。 既存のオンプレミスのお客様からの移行を容易にすることを意図的に行いましたが、移行は優れた最新製品の構築に比べて二次的な焦点でした。 この戦略は、新しい顧客が Dynamics 365 で最初から完全なエクスペリエンスを得ることを意味しました。 彼らはまた、新鮮な視点による貴重なフィードバックを提供してくれました。 オンプレミスの Dynamics 製品にまだ多額の投資を行っていないため、本当にクラウドネイティブで完全な SaaS オファリングである製品を構築するのに役立ちました。 機能の改善と拡張を続ける中で、最終的には、機能セットがオンプレミス製品のスーパーセットになった時点に達しました。 その時点で、既存のお客様のオンプレミス バージョンからより高度な Dynamics 365 への移行のサポートを開始できます。

この戦略は、ERP システムに適していることがわかっているため、意識的に選択しました。 他の製品では、最初に移動する製品の機能のサブセットを選択し、時間の経過に伴ってさらに機能を追加できる場合があります。 しかし、ERP では、コンポーネントは密に相互接続されています。 この製品は、これらすべてのコンポーネントに機能のスライスが存在するまで役に立ちません。これにより、エンド ツー エンドの便利なエクスペリエンスが顧客に提供されます。 MVP スコープは、各コンポーネントの機能の水平方向のスライスです。 新しい顧客のユース ケースをサポートする機能のクロスカット セットを選択することにしました。

他のソリューションでは、代わりに MVP をコンポーネント全体としてスコープ設定することが理にかなっている場合があります。 SaaS への独自の旅に着手するときに従う戦略について意識的に決定することが重要です。 重要なのは、市場への最初の成果物をできるだけ小さくする必要があることですが、それでも実際の使用に耐えるように十分に完成していることです。

計画と改善に合わせて、お客様の期待も継続的に進化していることを念頭に置きます。 製品を正確な現在の状態で移行するのではなく、製品を使用する準備ができた時点までに、お客様が必要とするものを計画しました。 クラウド移行と組み合わせて SaaS への移行は、多くの場合、数か月または数年かかる長期的な取り組みです。 この間、顧客の需要の変化を見失わない必要があります。 それ以外の場合は、最終的に顧客のニーズに完全に対応できないものを構築するために多大な労力を費やすことができます。

使用量、顧客満足度、コスト

通常、オンプレミスソフトウェアの収益は販売トランザクションが発生した時点で認識され、デプロイと導入を成功させる責任はお客様にかかっています。 クラウド SaaS サブスクリプション モデルでは、多くの場合、お客様は数シートのライセンスを取得することから始め、ソリューションが実証された後にのみサブスクリプションを拡張します。 購入しても使用しないシートは、次のサブスクリプションの記念日にキャンセルされる可能性があるため、リスクがあります。 その結果、SaaS への移行に伴い、ビジネスを推進するために使用した上位のメトリックが変更されました。

ライセンスが付与されたソフトウェアのオンプレミスの世界では、主な焦点は収益でした。 クラウドでは、使用量と顧客満足度に重点が置かれていました。 これらのメトリックは、収益と収益の増加の前方指標となりました。 デプロイの成功までの時間を最小限に抑え、購入済みで未使用のライセンスを可視化し、ユーザーとビジネス ロール間で高い満足度を維持することに努力しました。 最初から、私たちはお客様が好きな製品を作り出すことに重点を置いてきました。 私たちは、顧客が製品を使用して価値を得るとき、収益が続くという経験から知っています。 カスタマー エクスペリエンスと使用に優先順位を付けることで、ビジネス戦略を成功するための基盤を設定します。

SaaS を構築する場合、特にスケーリングしてコストが増加するにつれて、販売商品 (COGS) のコストが非常に重要になります。 ただし、まず満足度と使用状況に優先順位を付ける方が良いです。 優れたカスタマー エクスペリエンスを提供する場合は、リソースをより効率的に使用し、新しいプラットフォーム機能を利用することで、サービスの提供コストを最適化できます。 エクスペリエンスが十分でない場合は、使用率が低くなり、満足する顧客が少なくなります。 そのため、進捗状況を確認するときは、重要な順に次の 3 つの主要業績評価指標に焦点を当てます。

• 顧客満足度:お客様は製品を使用する経験が好きですか? フィードバックは何ですか?
• 使用法: ユーザーの数はいくつですか? サブスクリプションの数はいくつですか? 使用は加速していますか? 購入から使用までの時間は何時ですか? 購入したすべてのサブスクリプションを使用するようにお客様に勧める方法を説明します。
• COGS: お客様にサービスを提供するには、どのくらいのコストがかかりますか?

また、SaaS 製品が収益を生み出す方法についても考慮することが重要です。 顧客は、サービスの支払い方法を理解する必要があり、価格モデルはユーザーにとって理にかなっている必要があります。 多くの企業間 SaaS ソリューションでは、ユーザーが持っているユーザーの数は、ユーザーがシステムを使用するときに消費されるリソースの大きな指標です。 システムを積極的に使用するユーザーが多いほど、優れたエクスペリエンスを提供するために必要なシステム リソースが増えます。 顧客へのコストは、その事実を反映しています。 お客様は、ユーザーベースの価格構造を直感的に理解できます。

ただし、ユーザー数によって、顧客が消費するリソースが適切に示されない場合があります。 たとえば、顧客のマーケティング チームが電子メール キャンペーンに大量のメッセージを送信する場合、数百万の電子メール メッセージを送信するユーザーが 1 人しかいない可能性があります。 同様に、ユーザーではなくバックグラウンド プロセスで注文の詳細がインポートされます。 課金対象のメトリックを顧客が理解し、請求額を予測できるようにすることが重要です。 メール メッセージを送信する連絡先の数や、毎月処理する注文明細行の数などのメーターを使用することもできます。

Dynamics 365 のアーキテクチャ

ID、認証、および承認

Dynamics 365 などのビジネス アプリケーションは、価値の高いビジネス データを管理し、ミッション クリティカルなビジネス アクティビティを自動化します。 承認されたユーザーのみがデータとシステムのアクションにアクセスできるようにすることが不可欠です。 Microsoft Entra ID を使用することで、企業は、IT 資産全体で既に使用しているのと同じツールとプラットフォームを使用して Dynamics 365 へのアクセスを管理できます。 お客様は、条件付きアクセスなどの高度なセキュリティ機能を利用でき、さらに作業を行う必要はありません。 Dynamics システムをセキュリティで保護する機能は、Microsoft による Entra プラットフォームへの継続的な投資によって進化し続けています。

Dynamics 365 は、ユーザーをロールに割り当て、特定のデータとアクションのアクセス許可をそれらのロールに割り当てます。 この方法は、Entra によって提供されるユーザー認証以外の承認を管理するための一般的なパターンに従います。 このアプローチでは、Dynamics 365 が職務の分離などのベスト プラクティスのビジネス要件を適用する機能も提供されます。

賃貸モデル

Dynamics 365 を使用する各組織は、データがセキュリティで保護され、他の組織からのアクセスから分離されることを期待しています。 各組織を テナントとしてモデル化し、各テナントには、製品を使用して組織のデータを操作できる多くのユーザーがいます。 リソースを共有すると、サービスを実行するコスト コンポーネントが削減されますが、テナントの分離レベルを確実に確保するために、共有は要件とバランスを取る必要があります。 幸いなことに、Azure プラットフォームには、アプリケーション プロバイダーが必要な分離を実現するコストのバランスを取るために豊富な機能が用意されています。

たとえば、各テナントのビジネス データを個別の SQL データベースに保持することが重要であると感じました。 この分離により、他の機能の中でも、カスタマー マネージド キーを使用して Azure SQL Transparent Data Encryption (TDE) を実装できます。これは、データに関するエンタープライズ信頼の約束の重要なコンポーネントです。 Azure SQL (特にエラスティック プールを含む) を使用すると、コスト効率を高めながら、お客様ごとに個別のデータベースを使用できます。 インフラストラクチャ コストの増加に加えて、テナントごとに個別のデータベースを保持することを決定すると、管理の複雑さが増します。 Dynamics サービスの規模でデータベースを手動で管理するのに十分なデータベース管理者 (DBA) が存在せず、管理タスクの自動化に多大な投資を行いました。 大規模なデータベースでの Dynamics 365 の動作の詳細については、「 大規模な SaaS プロバイダー向けの Azure SQL での 1M データベースの実行: Microsoft Dynamics 365 と Power Platform」を参照してください。

ソリューションのすべてのレベルで、Microsoft の戦略は、ネイティブの Azure プラットフォーム機能を使用してテナントの分離を強制し、スケールと回復性を実現しながら、可能な場所でコスト効率を高める方法でした。 Microsoft では、テナントのセキュリティを優先し、優れたカスタマー エクスペリエンスを提供しながら、システムを最適化できる場所を常に検討しています。

デプロイ スタンプ

Dynamics 365 はハイパースケールで動作します。 当社の製品に応じて、何百万人ものユーザーを持つ数十万人の顧客がいます。 これらの数値は、時間の経過と同時に増加し続けます。 SaaS ソリューションは、通常、世界中の顧客をスケーリングし、サポートする必要がある設計が必要です。

クラウドでは、可能な限り スケールアップ から スケールアウト に移行することが重要です。 既存のノードをより強力に (スケールアップ) するのではなく、ノードを追加 (スケールアウト) することで追加の需要を満たすことができる場合、その関係は線形に近い場合、スケールアウトに基づくアプローチにより、さらに高いスケールを推進する可能性があります。 Dynamics 365 では、アプリケーション層でスケールアウト モデルが使用されます。 統合された監視は、特定のテナントの負荷の増加を検出し、需要に合わせてノードを追加します。

テナント モデルとスケールアウト アーキテクチャと組み合わせて、 デプロイ スタンプ パターンに従い、各スタンプで一連の顧客をサポートできます。 スタンプが最大容量に近づくと、新しいスタンプをプロビジョニングし、新しい顧客のデプロイを開始できます。 スタンプを使用すると、顧客の継続的な成長をサポートし、地域のプレゼンスを新しい地域に拡大できます。

デプロイ スタンプを使用すると、信頼性の利点も得られます。 更新プログラムは段階的にロールアウトできます。安全なデプロイ プロセスは、グローバルフリート間で徐々に変更をロールアウトするのに役立ちます。 各スタンプは他のスタンプとは独立しているため、スタンプに問題が発生した場合、そのスタンプに割り当てられた顧客のサブセットのみが影響を受けます。 スタンプは、問題または障害の 爆発半径 を減らし、全体的なディザスター リカバリー戦略に貢献するのに役立ちます。

アーキテクチャ上の決定と同様に、デプロイ スタンプの使用はビジネス ニーズに基づいて行います。 スタンプをデプロイするには、それをサポートするための一連のインフラストラクチャをデプロイする必要があります。 スタンプの最小サイズが大きすぎる場合は、最初に重要な顧客数に到達する必要があるため、新しいスタンプを新しい市場に展開することを正当化することは困難です。 また、顧客の成長が製品の使用に与える影響を理解することも重要です。これは、顧客が成長するにつれてスタンプのリソースを多く使用するためです。 これらの考慮事項は、Dynamics 365 などのハイパースケール プラットフォームの場合と同様に、小規模な ISV の場合と同じくらい重要です。

制御プレーンと設定

ISV がクラウドベースの SaaS 配信モデルに移行する場合、最も劇的な変更の 1 つは、サービスの運用に責任を負うということです。 ほとんどのオンプレミス ソフトウェアでは、お客様の IT 部門がシステムの展開、構成、管理を担当します。 お客様自身が監視システムを管理し、更新プログラムをロールアウトするタイミングを決定します。 また、関連するすべての手順を実行する責任もあります。 多くの場合、専門のサービス統合パートナーは、お客様が環境内で複雑な製品を運用するのに役立ちます。 ソフトウェア プロバイダーは、クラウドと SaaS モデルに移行することで、 すべての顧客の これらすべてのアクティビティを担当します。 SaaS への移行に伴い、ISV のサービスと コントロール プレーン を構築して、テナントのオンボードと管理の作業を自動化する必要があります。 コントロール プレーンとオートメーションは、比較的少数のお客様でも重要です。

回復力があり、信頼性が高く、高可用性のコントロール プレーンを設計することをお勧めします。 多くの場合、コントロール プレーンは、SaaS 製品を構築する過程で後入れとして扱われます。 ただし、コントロール プレーンが他の製品と同じ注意を払って設計されていない場合は、単一障害点になるリスクがあります。 コントロール プレーンの回復性に適切な注意を払わないと、コントロール プレーンの障害がすべての顧客に影響する可能性があります。

Dynamics 365 には、新しいテナントのオンボードなどの操作を処理するサービス レベルのコントロール プレーンがあります。 また、テナント レベルのコントロール プレーンもあります。これにより、お客様の管理チームは、サービスを通じてこれらの操作を実行できるため、メンテナンス アクティビティを開始し、構成を自分で変更できます。

カスタマイズと拡張性

SaaS モデルの主要な価値提案は、すべての顧客が 1 つのバージョンのサービス コードを実行することです。 お客様が 1 つのバージョンのサービス コードを実行すると、問題が特定され、1 回修正され、すべての顧客がそれらのソリューションの利点をすばやく得ることができます。 目標は、お客様が更新プログラムのテストとデプロイを計画しなくても、1 つのバージョンのサービスを継続的に進化させることが可能になることです。

この利点を実現するには、オンプレミスの世界でソフトウェアを実行する場合と比較して、多くの変更が必要です。 たとえば、回帰の可能性を減らすために、プロセスと手順を計画する必要があります。

Dynamics 365 の変革では、私たちが投資した領域の 1 つは、豊富なモデル駆動型拡張性の開発でした。 ERP アプリケーションでは、他の重要なビジネス システムとの統合をサポートし、特定の顧客の独自の機能ニーズを満たすための拡張性が必要です。 オンプレミス アプリケーションで一般的だったソース コード レベルでのカスタマイズではなく、テナント固有のメタデータを使用してデータ モデルを拡張し、システムで発生するイベントに基づいて拡張ロジックをトリガーする機能を導入しました。

サービスと他のテナントを別のテナントの拡張ロジックの問題から保護するための分離とガバナンス機能を追加しました。 このアプローチにより、お客様に必要なレベルの拡張性が提供されましたが、すべて同じ製品バージョンで引き続き実行できるようになりました。 さらに、お客様が変更をマージし、コードを再構築して拡張機能を新しいバージョンの製品と連携させなくても、更新プログラムを製品に配信できます。

カスタマイズはすべての製品の要件ではない可能性がありますが、製品に必要な場合は、カスタマイズが重要な設計要素になります。 SaaS モデルの主要な利点を損なうことなく、要件を満たす必要があります。 この要件は、Dynamics 365 にとって重要な焦点でした。 モデル駆動型の拡張性により、SaaS の価値提案が維持され、顧客が拡張機能を作成して維持する能力が向上しました。

回復性のために Dynamics 365 を設計した方法

Azure でのデプロイ モデルを検討する際に考慮すべき重要なコンポーネントは、依存サービス (ネットワークの問題、電源の問題、仮想マシンのメンテナンスなど) に問題がある場合の回復性です。 インフラストラクチャが 1 つの顧客テナントにサービスを提供するオンプレミスの世界では、多くのお客様がインフラストラクチャ コンポーネントごとに高可用性戦略に依存しています。 ただし、クラウド規模での回復性を検討する場合、高可用性は必要になることは多くありますが、十分ではありません。 十分な規模になると、障害が発生します。

現在の Dynamics 365 の中心となる領域は、障害がデータセンターまたは可用性ゾーン全体に影響を与えた場合でも、ミッション クリティカルな Dynamics サービスがシームレスに運用を継続できるように、Azure 可用性ゾーン全体の冗長性をターゲットにすることです。

この考え方を独自のソリューションに適用するには、いくつかの重要なプラクティスに従う必要があります。

• 問題をすばやく特定するための監視ツールに投資してください。 SaaS を使用すると、お客様は停止について知り、サービスの復元に迅速に取り組む必要があります。
• サービスに適している場合は、可用性ゾーンやゾーン冗長性などのプラットフォーム機能を使用します。
• すべてのレイヤーで回復性を確保するためにアプリケーションを設計します。 たとえば、 再試行、 サーキット ブレーカー、 バルクヘッドの使用、非同期通信プラクティスの採用など、他のクラウドのベスト プラクティスも考慮することが重要です。 これらのプラクティスは、依存している他のサービスがストレスを受けている場合でも、サービスを正常に保つことができます。
• 特に、インフラストラクチャ資産が影響を受けた場合にソリューションの復旧に役割があるため、コントロール プレーンの可用性を検討してください。
• 回復性の機能を実装したら、テストを実行します。 実際に使ってみるまで、計画や機能が完全かどうかはわからないものです。 通常のメンテナンス アクティビティの一環としてフェールオーバー プロセスを実行すると便利です。この方法では、ダウンタイムを発生させずにメンテナンスを行う方法と、フェールオーバー メカニズムの検証の両方を行うことができます。

Azure Well-Architected Framework の信頼性の柱は、これらのトピックに関する優れたガイダンスを提供します。

クラウド環境に適応する方法

Dynamics 365 は高度なクラウドネイティブ アーキテクチャに進化しましたが、ISV では、オンプレミス環境からクラウドへの リフト アンド シフト の移行が制限されるのが一般的です。 SaaS サービスを顧客の手にすばやく取り込む ための MVP を定義 するモデルについて説明しました。これは、学習と継続的な改善のサイクルを開始します。 しかし、バランスがあります。 "リフト アンド シフト" は、実際には "リフト、シフト、適応" にする必要があります。

この記事の前半では、 可用性ゾーンとその他のクラウドのベスト プラクティスを使用した回復性の設計について説明しました。 他にも、一般的なオンプレミスの設計パターンによって、クラウドでの課題やコストの増加につながる領域もあります。 たとえば、オンプレミス アプリケーションでは、バイナリ ラージ オブジェクトをリレーショナル データベースに格納するのが一般的です。 たとえば、販売注文に関連する PDF ドキュメントを、販売注文の一部として SQL データベースに格納できます。 オンプレミスの世界では、このアプローチにより、バックアップとポイントインタイム リストア機能全体の一貫性が簡素化されます。 ただし、クラウドでは、データベースに格納されている大きなオブジェクトにコストがかかる場合があります。 さらに、Azure Storage BLOB は、一貫性のあるバックアップを維持するために必要な単純なロジックを使用して、大きなバイナリ オブジェクトの格納を簡略化します。

クラウド変革の一環として行う必要がある事柄について考える 必要 があります。 より強力なクラウド製品を生み出すこれらのことを行う必要があります。 しかし、あなたはすぐに市場に出て、学習と継続的な改善の好循環を始める機会としても使用する必要があります。

また、クラウドは、オンプレミス環境では選択できないまったく新しいソリューションを実用的なものにすることもできます。 ERP システムで最もパフォーマンスが高いプロセスの 1 つは、製造リソース計画 ( MRP II) です。 MRP II は、手持在庫、予想される受注および出荷注文、および製造要件を確認します。 その後、予想される注文を満たすために、企業が何を購入または行う必要があるかを決定します。 オンプレミス Dynamics では、この機能は、リレーショナル ストアに対して直接機能するアプリケーション コードに実装されました。 計画機能は多くのシステム容量を消費し、長時間実行されました。 最初のクラウド バージョンでは、オンプレミスの機能は変更されずに機能していましたが、スケールとパフォーマンスの課題は同じです。 その後、数年前に、パフォーマンスに影響を与えることなく、同じ計画実行を短時間で完了できる新しいインメモリ マイクロサービスを導入しました。 重要なのは、マイクロサービスは製造システムの重要なコアであるため、お客様がサンドボックス環境で正しい結果を生成したことを確認した後にオプトインできる機能として導入しました。 より多くのお客様が新しいマイクロサービスにピボットしたので、以前の機能を非推奨にできるように、すべての顧客にマイクロサービスを使用してもらう作業を開始しました。 MRP II がいつでも数分で実行できるようになり、組織はより機敏になる可能性があります。 クラウドにより、インメモリ マイクロサービスの作成と接続が実用的になり、優れた SaaS エンジニアリング原則により、サービスのこの最も重要な部分であっても、顧客を混乱させることなく進化することができました。

既存の顧客をクラウドに移行する方法

既存の顧客ベースの移行は、クラウド サービスを拡張してスケーリングするための最速の方法になります。 しかし、Dynamics 365 をクラウドに導入したとき、最初は新しい顧客に焦点を当てていました。 主な理由は 2 つあります。

• このアプローチにより、単純なクラウド移行を求めるオンプレミスの顧客にアピールしただけでなく、独自のメリットで勝った SaaS ソリューションを提供したかどうかを評価する方法が得られます。
• MVP に重点を置き、既存の顧客を移行するためのツールの構築などのタスクを延期することができます。

新しい顧客との牽引力を見た後、既存のオンプレミス顧客の移行に集中することができました。

多くの場合、顧客は移動のコストと複雑さを恐れていることがわかりました。 コストを削減し、未知の要因を取り除くツールを提供することが重要でした。 Microsoft は、クラウド製品で進化した新しいスキーマへのデータの移行に伴う作業の分析に役立つツールを開発し、移行が顧客の拡張機能と統合に与える影響を理解しました。 また、移行する時間とコストの前後に境界を置く他のツールやプログラムを構築するのに役立つことがわかりました。

クラウドだけに移行すると、オンプレミス製品で直面するシステム管理の負担の多くを取り除くことで、お客様にとってメリットが得られますが、クラウド バージョンの利点を強調することも重要な動機となります。

Dynamics 365 を SaaS として運用する方法

MVP を定義し、リフト、シフト、適応するためのエンジニアリングを完了したら、顧客に代わって SaaS サービスの運用に集中する必要があります。 この変換は膨大です。 オンプレミスの世界では、ソフトウェア プロバイダーがソフトウェアを作成して出荷し、システム インテグレーターがソフトウェアを展開し、顧客の IT 組織または外部委託プロバイダーがソフトウェアを実行します。 SaaS では、SaaS プロバイダーが主にサービスの運用を担当するだけでなく、数百から数千人の顧客に対して同時にサービスを運用する責任もあります。

多くのお客様のためにクラウドで Dynamics 365 を運用することで、多くのことを学びました。

監視: サービスプロバイダーとして、顧客はサービスの健康状態の問題をあなたが彼らより先に検出し、すぐにその解決に取り組むことを期待しています。 健康上の問題は、サービスが停止している時だけではありません。 サービスが正常でないという顧客の見解には、サービスのパフォーマンスが遅いか、正しく動作しないかが含まれます。 適切な監視ツールを開発することが不可欠です。この開発は、オプションのアクセサリではなく、サービスの一部です。

コミュニケーション: オンプレミスの世界では、顧客は IT チームが問題に取り組んでいるのを見ることができます。 クラウドでは実行できません。 サービスの正常性の問題を検出したときに連絡を取り、解決に向けた進行状況を継続して伝え、問題が解決されたときに解決済みを確認することが不可欠です。 通信の性質は、問題の重大度によって異なります。 通信パイプラインは SaaS サービスの中核部分でもあります。また、SaaS サービスのインフラストラクチャのコア部分が侵害された場合でも、通信が成功するようにする必要があります。

スタック全体のビュー: オンプレミスの世界では、アプリケーション プロバイダーは一般にアプリケーション コンポーネントを担当し、顧客は基になるインフラストラクチャを所有しています。 クラウドでは、スタック全体を担当します。 サービスに正常性の問題がある場合、顧客は、問題がアプリケーションにあるか、それが実行されているクラウド プラットフォームにあるかにかかわらず、検出、通信、修復を行うことを確認します。

自動化: 人間がサービスの運用に手動で手順を実行する必要がある場合、間違いは必然的に発生します。 考えられるすべてのアクションを自動化してログに記録する必要があります。 十分なサービス ノードでアクションが必要な場合は、自動化が唯一のオプションです。 優れた例は、Dynamics 365 のデータベース管理です。 各テナントのデータを個別の Azure SQL データベースに保持することを決定したので、インデックスのメンテナンスやクエリの最適化など、DBA によって通常実行されるすべてのタスクを処理する自動化を開発する必要があります。 大規模なデータベースの管理方法の詳細については、 大規模な SaaS プロバイダーに対する Azure SQL での 1M データベースの実行に関するページを参照してください。

安全なデプロイ: 可能な限り、変更は安全なデプロイ プロセスに従う必要があります。 まず、リスクの低い環境 (たとえば、顧客の数が少ないクラウド リージョンや重要度の低いワークロード) に変更が導入されます。 次に進むのは、少し規模が大きく、より複雑な顧客のグループで、こうして全ての顧客が更新されるまで進んでいきます。 すべてのステップで、変更が成功したかどうかを評価するために監視する必要があります。 問題がある場合、プロセスは変更のロールアウトを停止して問題を軽減するか、既にデプロイされている場所にロールバックする必要があります。 安全なデプロイプラクティスは、コードと構成の両方の変更に適用されます。 詳細については、「 安全なデプロイプラクティスの推進」を参照してください。

ライブ サイト インシデント管理: ライブ サイト インシデント とは、お客様がエンジニアリングエンゲージメントを必要とする運用環境でのサービスに問題があることを意味します。 これは、Microsoft が検出した健康上の問題、またはお客様から報告されたもので、サポートチームが自力で解決できない問題である可能性があります。 ライブ サイトの卓越性は、SaaS の成功に不可欠です。 この経験からいくつかの重要なポイントを次に示します。

• エンジニアリング チームは、ライブ サイト インシデントを処理する必要があります。 以前は、多くの企業が別々の運用チームやサポート エンジニアリング チームを持っていました。 コア エンジニアリング チームがライブ サイト インシデントをカバーするように明示的に選択しました。 彼らは最高の専門知識を持っており、問題を直接見ることは、真の迅速な改善とより良い将来の設計を促進するために適切な創造性とエネルギーを刺激します。 これは、開発スケジュールを計画するときに考慮する必要がありますが、大きな結果を生み出します。
• ライブサイトインシデントのリーダーシップはスキルであり、それには多くの努力が必要です。認識し、トレーニングし、採用の方法を学び、報酬を与えましょう。
• 優先順位は、検出、分離、軽減です。 顧客をもう一度健康にした後、長期的な改善に注意を向けます。

学び、改善する:誰かが「決して良い危機を無駄にしない」と言いました。 すべてのライブ サイト インシデントは、改善の機会です。 軽減策が完了したら、同様の問題をより迅速に検出する方法、基になる問題を完全に解決する方法、同様の問題の影響を最小限に抑える方法、他の同様の問題がサービス内の他の場所に存在する可能性があるかどうか、および問題のクラス全体を防ぐ方法を確認してください。 これらの是正措置を優先すると、サービスの品質が向上し、将来のライブ サイト インシデントの需要が減少します。 サービス品質は時間の経過と同時に改善する必要があります。そうしないと、成長するにつれて、すべての問題の影響も高くなります。

左にシフト: ライブ サイト チームの関与を必要とする問題は高価です。 問題がチームに届くまでには時間がかかり、ライブサイトチームは最も深刻なサービス正常性の問題と管理タスクに専念できる必要のある貴重なリソースです。

可能な限り、最善の解決策は問題を完全に排除し、その後すぐに自動検出と自動化された軽減策を実行することです。 それが不可能な場合は、 左にシフトすることで 、現場のサポート チームが問題を検出して修正したり、タスクを実行したり、さらに優れたタスクを実行したり、顧客が自分でセルフサービスしてタスクを実行したりできるようになります。 次の図は、サポート ケースが顧客から始まり、現場のサポート チームに移動してから、エンジニアリング チームに移動する方法を示しています。 矢印は、インシデントの影響を軽減するために解決アクションを左に移動することを示します。

標準を維持する: 1 人の顧客に対して特別な取り決めを行うことで、問題を軽減したくなる可能性があります。 規模が大きくなると、特別な取り決めはすべて他の何かが失敗する原因となりかねません。 標準のコード、設定、構成を使用して、すべてのテナントを維持することを目指します。

継続的イノベーション

この記事では、製品をクラウドに移行し、継続的な学習と継続的な改善の好循環を開始する必要性について説明しました。 継続的イノベーションは、ほとんどの SaaS 製品に対する期待です。 しかし、SaaS 製品が長年のオンプレミス製品の後継製品である場合、顧客が継続的なイノベーションに備えるために大幅な変更管理が必要になる可能性があります。

Dynamics 365 変換の 3 つの主要な重点領域を次に示します。

ほぼダウンタイムのないメンテナンス: さまざまな企業や場所の顧客の数が増えるにつれて、普遍的に受け入れられるメンテナンスウィンドウを見つけることができなくなります。 システムがオンラインの間にメンテナンス アクティビティが発生できるように、エンジニアリングの成熟度を構築する必要があります。 特に、サービス更新プログラムのデプロイは、可能な限りゼロに近いダウンタイムで行う必要があります。

回帰を排除する: 継続的なイノベーション ポリシーを使用してミッション クリティカルなサービスに依存するには、顧客の信頼が必要です。 その信頼は、毎日の成功した運用と継続的なシームレスなサービス更新によって少しずつ築かれていきます。 しかし、回帰が生じると、それがどんなに小規模でも、信頼は大きく損なわれます。 特に安全なデプロイ プロセスを使用することで、エンジニアリング プロセスの回帰を排除するためにできることをすべて実行する価値があります。

機能フラグ: Dynamics 365 チームは 、機能フラグ フレームワークに幅広く投資してきました。 機能フラグは、サービス全体、テナントのサブセット、または単一のテナントに対して有効または無効にすることができます。 機能フラグを使用することで、Dynamics 365 がサポートするミッション クリティカルなビジネス プロセスの運用を中断することなく、新機能の導入を可能にします。

機能フラグが役立つ方法を次に示します。

• フラグが既定で有効になっていると、単純なパフォーマンスまたはセキュリティ修正プログラムを導入できます。 誰もがすぐに変更の利点を得る必要があります。
• ユーザーのエクスペリエンス、ビジネス プロセス、または外部から参照できる API の動作を変更するものは、既定でフラグがオフになっている状態で導入されます。
• 機能フラグを変更すると、実行されるコードが効果的に変更されるため、機能フラグの変更も安全なデプロイを通じて管理する必要があります。 たとえば、問題の修正プログラムを導入し、修正プログラムの機能フラグを既定でオフにするとします。 元のバグを報告した顧客に対してフラグを有効にすることができます。 その後、すべてのユーザーに対してフラグが有効になるまで、対象となる顧客の範囲を広げながら段階的に進めることができます。
• フラグが既定でオンになっているときに修正プログラムが導入され、修正に問題がある場合は、フラグをオフにすることで、論理的に即座にロールバックできます。
• 機能フラグを使用して、プレビューの機能を選択的に開示したり、非推奨プロセスの一環として新しい顧客から機能を選択的に非表示にしたりすることもできます。
• 新しい機能フラグとテナント固有の機能フラグ設定の可視性を、現場のサポートチームとライブ サイト チームに提供できます。 この情報は、チームが問題を調査するときに、新しい機能の変更をすばやくルールインまたは除外するのに役立ちます。 必要に応じて、チームは機能フラグの設定を調整して問題を軽減することもできます。
• 最後に、コード ベースをサポートできないようにするために、機能フラグのライフサイクルを管理する必要があります。 機能フラグが完全にデプロイされ、実証された後で、コードから機能フラグを削除するプロセスを確立します。

結論

オンプレミス製品から SaaS に移行するには、ソフトウェアを顧客に提供する方法のあらゆる部分と、ビジネスのあらゆる部分で大きな変更が必要です。 文化的な変化は技術的な変化と同じくらい重要です。時折オンプレミスのリリース周期から定期的なリリース周期に移行することは大きな変化であり、ライブサイトのカルチャとプロセスの採用には労力がかかります。 SaaS を大規模に運用する方法を知っている人がいられるように、チームが十分に準備され、エンジニアを超えて人材プールを拡張する必要があります。

多くの組織は、この規模の移行に耐えられません。特に、新しい競合他社が既にクラウドにネイティブに参加している場合に生き残ることはできません。 成功への準備を整えるためには、MVP のスコープを慎重に設定し、できるだけ早く運用環境に移行し、そして迅速に繰り返し改善する必要があります。 移行プロセスは多くの場合、最も困難な時期であるため、できるだけ早くクラウドに移行することをお勧めします。

ここでは、私たちの経験から学べる重要な考慮事項と、ご自身の道のために下す必要がある決定について示します。

• 独自のパスを決定します。 豊富な機能を備えた既存のアプリケーションと、確立されたオンプレミスの顧客ベースがある場合は、クラウドベースの SaaS モデルに移行することが理にかなっています。 すべての製品の体験は異なり、独自のニーズに基づいて決定と質問を個別に検討する必要があります。 他の旅からインスピレーションを得るが、あなた自身の道を築く。
• 戦略を決定します。 確立された顧客と製品を持つことは、優先順位を作成する方法を決定する必要があります。 新しい顧客に適した製品をすぐに構築することに集中できます。 既存の顧客ベースを可能な限り迅速に新しいサービスに移行することに重点を置く場合があります。 移動する理由と、大きな変更を加える能力は、取る方向に影響します。
• シングルクラウドとマルチクラウドのどちらを使用するかを決定します。 1 つのクラウドの上に構築するか、複数のクラウドにエンジニアリング作業を分散させる方が理にかなっているかを検討します。 プラットフォーム コンポーネントを構築する場合は、マルチクラウド戦略が理にかなっている可能性があります。 アプリケーションを構築する場合、単一クラウド戦略は、一貫性のある統合プラットフォームを使用するよりも利点を提供できます。
• クラウド専用の計画を立てる。 クラウドに移行するためのリフトアンドシフトアプローチでは不十分です。 クラウドの弾力性を利用する方法と、クラウド環境でサービスを運用する方法を計画する必要があります。 自動化、回復性、スケール、セキュリティ、パフォーマンス、可観測性はすべて重要な考慮事項です。 すべてを事前に行う必要はありませんが、ロードマップを計画できるように宛先を知る必要があります。
• SaaS 専用の計画を立てる。 SaaS ビジネス モデルは、オンプレミスのソフトウェア配信アプローチとは異なります。 お客様は、試用版アカウント、わかりやすい課金モデル、フル マネージド サービス、ニーズに基づく動的スケールを期待しています。
• 着陸し、学習し、反復する。 MVP スコープを計画し、達成できるベースラインの勝利を特定し、迅速にそこに到達します。 準備ができたら、継続的な改善にコミットします。
• クラウドに参加している場合は、それを利用します。 クラウドには、オンプレミス ソリューションにはない多くの機能が用意されています。 この機能には、大規模なスケール、弾力性、クラウド プラットフォーム コンポーネントを使用して、アイデアを迅速に作成して反復処理する機能が含まれます。 クラウド環境の外部では使いにくい、生成型 AI、マイクロサービス、その他のアプローチなどのテクノロジを使用する方法を検討します。
• 顧客の IT 部門になります。 エンド ツー エンドのサービスを提供する場合、顧客の期待は変化します。 左にシフトする方法を計画します。 包括的な監視機能と自己復旧機能があることを確認します。
• 顧客の使用状況から学習します。 サービスを実行すると、顧客による製品の使用方法に関する大量の有用なデータが収集されます。 データ カルチャを採用する。 あなたの顧客について、彼らが何をしているのか、そしてどのようにそれを行っているのかを学びましょう。 データが想定どおりにないことを示す場合は、実験を行い、アプローチを変更するのに十分なアジャイルを使用します。
• 更新プログラムを通じて継続的な価値を提供します。 更新プログラムを展開するタイミングと方法について考えてください。 問題をすばやく修正するか、以前のバージョンにフォールバックすることを計画します。 破壊的変更を処理する方法を決定します。 すべての違いは問題が発生する機会であるため、特定の顧客に対する 1 回限りの変更を避けます。

私たちが学んだ最大の教訓は、SaaS への旅が決して終わらないということです。 製品ロードマップは、絶えず進化している生きたドキュメントです。 バックログには、新しい機能を追加したり、製品の運用方法と配信方法を改善したりするために、製品を改善するために、常に多くの項目があります。 SaaS を提供するには、顧客に対して信頼性の高い、安全でパフォーマンスの高い、信頼できるサービスを確実に提供するために、プロセス、品質への投資、および警戒を継続的に改善する必要があります。 ジェネレーティブ AI などのテクノロジの進歩により、これまで想像もつかない機能を提供する大きな機会がもたらされます。

貢献者

この記事は Microsoft によって管理されています。 当初の寄稿者は以下のとおりです。

• Mike Ehrenberg |CTO、Microsoft Dynamics
• John Downs | プリンシパル ソフトウェア エンジニア
• アルセン・ウラジミルスキー |プリンシパル カスタマー エンジニア