大規模に Power Platform を採用するテナント環境戦略を策定する
あらゆる組織の Microsoft Power Platform の導入への道のりはユニークです。 テナント環境戦略は、管理しやすく安全な方法で使用を促進するための基盤を築きます。
このホワイトペーパーでは、Power Platform テナント環境戦略を製品の機能とビジョンと位置を合わせる方法について示します。 プラットフォームの最新機能を最大限に活用して、エンタープライズ規模に到達するために Power Platform の導入を可能にする戦略を実装する方法について学びます。
注意Note
ブラウザーで 印刷 を選択して PDF として保存 を選択することで、このホワイト ペーパーを保存または印刷できます。
概要
Power Platform は、組織が迅速なイノベーションを実現するローコード ソリューションを構築できるようにします。 これらのソリューションは、個人や小規模チームの生産性に重点を置くことも、組織全体に適用することもできます。 また、外部の顧客やパートナーを含むビジネス プロセスに拡張することもできます。 これらのソリューションをサポートするのは、ローコード リソースが構築、テスト、使用される Power Platform 環境です。 組織が Power Platform の採用を増やすにつれて、環境の数が増えても管理しやすく、安全にするためには、適切なテナント環境戦略を実装することが不可欠です。
さらなる成功を実現するために、この記事では、最初の環境戦略を確立したり、現在の計画を発展させたりするために利用できる機能を最大限に活用する方法について説明します。 また、これらの機能がどのように連携し、大規模な Power Platform の管理に向けてどのように進化していくかについてのビジョンも概説します。 このガイダンスでは、ガバナンス、セキュリティ ルール、およびテナント環境戦略のその他の重要な側面を一貫して適用するために、新しいユーザーを環境およびグループ環境に適切にルーティングする方法を確立します。 また、環境戦略を実装するための重要な最初のステップである、デフォルト環境を保護するための詳細な手順も提供します。
多くの パースペクティブ が環境の管理に使用できますが、この記事のアプローチは、 Power Platform の最新の製品方向性と一致しており、現在の機能と近い将来に計画されている機能強化を使用しています。 Microsoft この更新されたガイダンスは、大規模な環境を管理するために意図されている方法に戦略的に適した 環境 機能とオプションのみを使用するようにするのに役立ちます。 Microsoft
Microsoftのテナント 環境 戦略ビジョン
多くの組織は、 デフォルト環境 と呼ばれる共有の中央環境で構築および実行される個人の生産性向上アプリと自動化から自分たちの Power Platform 体験を始めます。 これらのリソースは、多くの場合、Microsoft 365 に含まれる基本機能のみを使用し、Power Platform の完全な機能は使用しません。 この初期の導入が加速するにつれて、 Microsoft 組織は、全機能をエンタープライズ規模で導入するための 環境 戦略への入り口を得ることができます Power Platform 。 これらのプレミアム ガバナンス機能は、ユーザーがプレミアム Power Platform (Power Apps、Power Automate、Microsoft Copilot Studio、Dynamics 365) ライセンスを所有している場合に利用可能になります。 Power Platform 導入成熟度モデル は、組織が環境戦略を超えてエンタープライズ規模の導入を実現するためのロードマップを定義するのに役立つ、より多くの洞察を提供します。 このアプローチは、組織が基本的な個人の生産性からエンタープライズ規模の Power Platform 導入へと成熟するのに役立ちます。
Power Platform 管理、ガバナンス、セキュリティ機能により、組織は企業の生産性と企業アプリの使用を大規模に Power Platform 導入および管理できます。 マネージド環境を使用すると、可視性と制御性が向上し、環境の管理とセキュリティ保護にかかる手作業の労力が軽減されるプレミアム機能のセットが有効になります。 これらの機能を使用することで、ガバナンスとセキュリティ ポリシーの一貫した適用を実現できます。 管理者はこれらの機能を使用して、エンタープライズ規模の環境戦略に移行できます。 管理に費やす時間と労力を削減することで、組織の使用量が拡大してもプラットフォームの全体的な総所有コスト (TCO) を削減できます。
エンタープライズ規模への移行における重要な要素は、個人の開発環境をより簡単に使用できるようにすることで、メーカー向けの共有の中央環境戦略を強化することです。 共有された中央環境戦略では、作成者はデフォルトの環境でアプリを構築、使用、共有します。 この戦略は、孤立の欠如とメーカー同士の侵害につながる可能性があります。 社内の全員がすべてのドキュメントを 1 つの OneDrive フォルダーに保存していると想像してみてください。 代わりに、環境機能を使用して、作成者を独自の個人環境に誘導し、管理者のガバナンスを簡素化しながら、関連のないアセットで作業する作成者から保護された状態でアプリを安全に構築できるようにすることができます。 これらの環境に同僚をさらに多くのメーカーとして追加し、ソリューションの構築で協力することができます。
図: 共有された中央の 環境 (左) と 環境 ルーティング戦略 (右) の図。
新しく作成されたメーカー環境は、環境に一貫したガバナンスとセキュリティ ポリシーが確保されるようにルールを適用するグループに自動的に追加できます。 管理者は、メーカーの環境をルールが緩和されたグループに移動することで例外を処理できます。
メーカーによって作成されたローコード リソースは、リソースのアプリケーション ライフサイクル管理 (ALM) プロセスの初期段階を表します。 この初期段階の一部として、リソースの各バージョンをキャプチャし、必要に応じて再作成できるようにすることが重要です。 リソースを共有する準備ができたら、作成者は開発環境に付属する継続的インテグレーションを使用してリソースを運用環境に昇格させることができます。運用環境では、ユーザーは継続的な作成者のアクティビティから分離してリソースを実行できます。
可能な場合は、独自のツールを構築するのではなく、環境を管理するためのプラットフォームの組み込み機能を優先する必要があります。 組み込み機能が組織の固有の要件を満たさない場合は、プラットフォーム管理ツールを使用してカスタム ツールを作成できます。 新しい機能が利用可能になったら、カスタム ツールをそれに対して評価する必要があります。 Microsoftのプラットフォーム ロードマップに注目し、独自のロードマップを維持することで、この作業が容易になります。
組織の固有のニーズに合わせて調整された推奨環境機能を使用して、環境戦略を確立する必要があります。 環境戦略の作成を一度限りの活動と考えないでください。 新しい環境機能が利用可能になると、それを組み込むように時間の経過とともに進化する必要があります。
エンタープライズ規模の環境戦略をサポートする機能
環境は、管理、ガバナンス、セキュリティのためのものです。 Power Platform 完全な機能の概要は、このホワイト ペーパーの範囲外ですが、このセクションでは、エンタープライズ規模での環境戦略の実装をサポートする機能について説明します。
環境の種類 では、戦略の一環として環境をさまざまな方法で使用する方法について説明します。
レポート パーツ は、大規模な環境の管理を容易にするプレミアム機能のセットを提供します。
ライセンスの自動請求 により、管理者が事前にライセンスを必要とするユーザーを特定する必要がなくなり、ユーザーが必要なときにユーザーごとのライセンスを請求 Power Apps できるため、ライセンスの割り当てが簡素化されます。
環境 グループとルール では、環境をグループとして管理し、グループにルールを適用して一貫したガバナンス ポリシーを自動化する方法について説明します。
デフォルトの 環境 ルーティング により、メーカーはデフォルトの 環境 でのリソース作成から、独自の個人用 環境 に自動的に移動します。
Microsoft Dataverse 強化されたセキュリティとALMを提供します。
推奨ソリューション は、作成者が構築するすべてのアセットが Dataverse ソリューション内にあることを保証し、他の環境に レベル上げ しやすくするのに役立ちます。
Power Platform のパイプラインは、開発環境からテスト環境および本番環境に資産を促進するための簡素化されたプロセスを提供し、継続的インテグレーションとデプロイメント (CI/CD) をすべての作成者に提供します。
カタログを使用すると、作成者はアプリやフローなどのコンポーネントや、テンプレートなどのより高度な開始点を 共有 できます。 Power Platform
環境の種類
次の表では、作成できる環境の種類、その特性、および目的の用途について説明します。
| 型 | 特徴と用途 |
|---|---|
| 既定 | すべての入居者に付随する環境。 多くの Microsoft 365 エクスペリエンスでは、カスタマイズと自動化のためにこの環境を使用します。 この環境は、個人的な Microsoft 365 生産性シナリオを超えた長期的または永続的な作業を対象としていません。 |
| 運用 | この環境は、組織での恒久的な作業に使用することを目的とします。 実稼働環境では、7 日から最大 28 日までの延長されたバックアップ保持がサポートされます。 |
| サンドボックス | これらの非運用環境はコピーやリセットなどの環境アクションを機能をサポートします。 サンドボックスは、テストおよび ALM ビルド環境に最適です。 |
| 開発者 | これらの特別な環境は、ローコード資産をユーザーや他のメーカーから分離する、メーカーの個人的な開発ワークスペースとして意図されています。 メーカーは最大 3 つの開発者環境を持つことができます。 これらはテナントの収容人数にはカウントされません。 90 日間使用されていない開発者環境は自動的にオフになり、所有者が通知に応答しない場合はテナントから削除されます。 Dynamics 365 アプリは開発者環境では利用できませんか ? |
| 試用版 | これらの環境は、短期間のテストと概念実証をサポートすることを目的としています。 ユーザーごとに 1 つに制限されます。 試用環境は、しばらくするとテナントから自動的に削除されます。 |
| Microsoft Dataverse for Teams | これらの環境は、Teams でアプリを作成するか、アプリ カタログからアプリをインストールすると自動的に作成されます。 これらの環境のセキュリティ モデルは、関連付けられているチームと一致します。 |
| サポート | これらは、エンジニアが問題をトラブルシューティングできるようにするためにサポートによって作成された特別な環境です。 Microsoft これらの環境はテナントの収容人数にはカウントされません。 |
全体的なテナント環境戦略をまとめる際には、さまざまなタイプが戦略の推奨事項をサポートするために重要になります。
マネージド環境
環境には、環境タイプに応じて基本的な機能と特性のセットがあります。 マネージド環境は、管理者がより細かい制御、より少ない手間で、より多くの分析情報を使用して Power Platform の大規模な管理を簡単に可能にするプレミアム機能のスイートを提供するための基本的な機能の上に拡大します。 これらの機能は、環境を管理対象として設定するとロック解除されます。
次の表は、この記事の執筆時点で利用可能な管理環境の機能を示しています。 新しい機能は頻繁に追加されるため、最新のリストについては ドキュメント を確認してください。 すべての機能は環境戦略の構築に役立ちますが、斜体で表記された機能は、この記事で概説されている戦略に特に関連しています。
| 可視性の向上 | よりコントロール | 労力が減る |
|---|---|---|
| 使用状況の分析 管理者ダイジェスト ライセンスレポート データ ポリシー ビュー Azureへのデータのエクスポート Application Insights すべてのアプリの説明をAIが生成 |
共有制限 デスクトップ フローのデータ ポリシー ソリューションチェッカー メーカー歓迎コンテンツ IPファイアウォール IPクッキーバインディング 顧客管理キー 顧客ロックボックス 拡張バックアップ |
簡単に起動 Power Platform パイプライン 環境 ルーティング 環境 グループとルール Power Platform アドバイザー |
ライセンスの自動請求
自動請求ポリシー は、特定のアプリや機能を使用するためにライセンスが必要な場合に、ユーザーへのライセンスの割り当て Power Apps と Power Automate を自動化します。 自動化により、消費されるライセンスの数を削減し、ライセンスを手動で割り当てるオーバーヘッドを回避できます。
ポリシーが設定されると、組織内で個別のライセンスを必要とするすべてのユーザーに、次の条件に従って Power Apps ライセンスが自動的に付与されます。
もしスタンドアロンの Power Apps ライセンスを持たないユーザーがプレミアム ライセンスを要求するアプリを開くと、そのシステムに Power Apps のユーザーごとのライセンスが自動的に割り当てられます。
もしスタンドアロンの Power Apps ライセンスを持たないユーザーがマネージド環境でアプリを開くと、そのシステムに Power Apps のユーザーごとのライセンスが自動的に割り当てられます。
同様に、ポリシーが設定された後、組織内で個別のライセンスを必要とするすべてのユーザーに、次の条件に従って Power Automate ライセンスが自動的に付与されます。
ユーザーは、有人 RPA (ロボティック プロセス オートメーション) を使用してプレミアム クラウド フローをトリガー、保存、またはオンにします。
そのユーザーは、Power Automate プレミアム ライセンスを要求します。
環境戦略に管理対象環境が含まれている場合は、ライセンスの自動請求を構成することをお勧めします。 アプリとフローのユーザーはライセンスの摩擦を最小限に抑えられ、アプリをアクティブに実行しているユーザーや Power Automateを使用しているユーザーのライセンスのみが消費されます。
環境グループとルール
テナントでの Power Platform 採用が増えるにつれて、管理とガバナンスを必要とする環境の数も増える可能性があります。 環境の数が増えるにつれて、環境に一貫した設定とガバナンス ポリシーを適用していることを確認することが難しくなります。 環境グループ機能 を使用すると、名前付きグループを作成し、関連するドキュメントをファイル フォルダーに配置するなど、環境を関連付けることができるため、この作業が容易になります。
環境グループの使用を検討する際には、次の点に留意してください。
環境をグループに含めるには管理する必要があります。
環境は、一度に 1 つのグループにのみ存在できます。
1 つの環境から別の組織に環境を再割り当てします。
グループ内の環境は、複数の地理的領域から構成されます。
グループに他のグループを含めることはできません。
一貫した設定とガバナンスを適用できるように、環境グループでは次のルールを 1 つ以上構成して有効にすることができます。
キャンバス アプリのコントロールを共有する
使用状況の分析情報
作成者を歓迎するコンテンツ
ソリューション チェッカー強制
バックアップの保持
AI で生成される説明
ルールは公開されるとアクティブになります。 アクティブなルールは、グループに関連付けられているすべての環境に適用されます。
グループ ルールが設定を管理している場合、個々の環境設定はロックされます。 それらを変更する唯一の方法は、ルールを変更することです。 環境がグループから削除された場合、グループ設定は保持されますが、環境管理者がそれらを変更できるようになります。 これは、環境管理者がグループに設定されたポリシーを上書きできないようにするため、環境戦略にとって重要です。
環境グループを使用すると、組織構造、製品サービス階層、または後で説明するその他のフレームワークと同様に、環境を論理的な方法で整理できます。 次の図は、Contoso 組織が環境グループの編成についてどのように考えているかを示す概念的な例です。
図: Contosoテナントの 環境 戦略の概念化。
構成するルールを計画するときは、概念階層の各レベルで何を適用できるかを検討してください。 グループ階層をまだ構成することはできませんが、命名規則とルール構成を組み合わせて使用して概念設計を実装できます。 たとえば、前に示した Contoso テナントの概念化を前提とすると、次の図は組織が設計を実装するために使用できる環境グループを表しています。
図: 概念的な 環境 グループを実際のテナントに実装する例
この記事の後半では、テナント環境戦略の一環として環境グループを使用する方法についてさらに詳しく説明します。
既定の環境ルーティング
この記事で概説する環境戦略の重要な部分は、メーカーがデフォルトの環境でリソースを作成しないようにすることです。 環境ルーティング機能 は、メーカーを独自の開発環境にリダイレクトし、必要に応じて新しい開発者環境を作成します。
図: アプリを構築するときに、メーカーはデフォルトの 環境 ではなく、個人の 開発環境 に自動的にリダイレクトされます。
ルーティングによって作成された開発者環境はデフォルトで管理されます。 開発者プラン ライセンスを持つユーザーは、環境内でのリソースの作成とプレビューのみに制限されます。 ユーザーとしてリソースを実行するには、適切な ライセンス が必要です。
環境ルーティングは単独でも使用できますが、環境グループと一緒に使用することをお勧めします。 このように使用すると、作成された環境はすべての新しい開発者環境を含めるように指定したグループに関連付けられ、ガバナンス ポリシーによってすぐにカバーされるようになります。
メーカーには セキュリティ ロール が自動的に割り当てられ、開発者環境の環境管理者になります。 環境が環境グループの一部である場合、環境設定は環境グループ ルールによって管理されるため、作成者 (環境管理者) は環境設定を変更できません。 グループ ルールを変更できる管理者だけが変更を加えることができます。
2 つの方法でさらに制御を強化することができます。 まず、管理者は、テナント設定内の開発環境の手動作成を禁止できます。 このオプションを設定すると、作成者は管理ポータルで自分で環境を作成できなくなります。 また、ルーティング ポリシーによって自動的に作成されるものも取得されません。 次に、ルーティング ポリシーでセキュリティ グループを指定して、環境を自動的に作成できるユーザーを制限できます。
当初、環境ルーティングは、make.powerapps.com を使用する際に、新規および既存のメーカーをデフォルトの環境からルーティングすることをサポートします。 時間が経つにつれて、他の Power Platform サービスも環境ルーティング機能をサポートするようになります。
Microsoft Dataverse
Dataverse はアプリケーションによって使用されるデータを安全に保存および管理します。 環境戦略のコンテキストでは、Dataverse ソリューション機能 は、アプリとコンポーネントをある環境から別の環境に転送するために使用します。 メーカーは、構築したものを追跡するコンテナ (ソリューション) 内に資産を構築します。 ソリューションは他の環境に簡単に移行できます。 このアプローチを使用すると、作成者がリソースを構築する開発環境と、リソースが使用される運用環境を分離できます。 メーカーとユーザーの両方が恩恵を受けます。 メーカーはリソースを継続的に進化させることができ、ユーザーは突然の変化に驚くことはありません。 作成者が変更を公開する準備ができたら、更新されたリソースを運用環境にプロモートするようにリクエストできます。
Dataverse ソリューションとは、Power Apps および Power Automate のような Power Platform 製品で ALM を実装するためのメカニズムです。 Power Platform のパイプラインは、メーカーが構築するアセットの CI/CD を自動化するソリューションを使用します。 ソリューションは、Dataverse からエクスポートされ Azure DevOps または GitHub などのソース管理ツールに保存できます。 開発環境を再作成する必要がある場合、ソース管理のソリューションが信頼できる情報源になります。 たとえば、開発者が人気のあるアプリを構築し、その後開発環境を削除した場合、ソース管理に保存されているエクスポートされたソリューションを使用して、実行可能な開発環境を再作成できます。
Dataverse を使用して環境を作成するときのもう 1 つの重要な考慮事項は、Dynamics 365 アプリケーションを環境に展開するかどうかです。 可能性がある場合は、環境を作成するときに Dynamics 365 を有効にする必要があります。そうしないと、後で Dynamics 365 アプリをインストールできなくなります。
メーカーが他のユーザーと共有するアセットを作成する環境では、プロビジョニング Dataverse することをお勧めします。 これにより、資産を ALM 対応にすることが容易になります。
優先するソリューション
作成者が Dataverse 環境に Dataverse 資産を作成し、カスタム ソリューションから開始しない場合、その資産は既定のソリューションに関連付けられ、場合によっては Common Data Service 既定のソリューションにも関連付けられます。 デフォルトのソリューションは、環境内でアセットを作成するすべてのメーカーによって共有されます。 どのメーカーがどのコンポーネントを作成したか、どのアセットがどのアプリに属しているかを識別する簡単な方法はありません。 これにより、人気のあるアプリを別の環境に宣伝して、より大きな 対象者 で共有することが難しくなる可能性があります。 デフォルトのソリューション内のすべてのアセットをプロモートする必要がありますが、これは理想的なシナリオではありません。
環境戦略をサポートし、作業を容易にするために、メーカーは開発環境でカスタム ソリューションを作成し、それを環境内の 推奨ソリューション として設定する必要があります。 作成者は、環境内で優先ソリューションを設定し、作成したアセットをどのソリューションに関連付けるかを示します。 優先ソリューションは、メーカーがパイプラインを使用してリソースを他の環境にプロモートするときに、プロモートされたソリューションに必要なアセットがすべて含まれていることを保証するのに役立ちます。 これは、資産を ALM 対応に準備することと考えてください。
Power Platform のパイプライン
これまで見てきたように、適切な環境戦略の重要な原則は、資産が構築される場所と、それが展開および使用される場所を分離することです。 この分離により、アセットを使用しようとしているユーザーが、作成者がアセットを更新しているためにダウンタイムに遭遇することがなくなります。 ただし、アセットを使用するには、その前に、理想的には Dataverse ソリューションの一部として、運用環境に昇格する必要があります。
Dataverseソリューションは環境間で手動で移行できます。 ただし、パイプラインを使用すると、プロセスを自動化し、適切な変更管理が行われるようにポリシーを導入することができます。 ソリューション チェッカー で設定した環境ルールに応じて、パイプラインはソリューションがデプロイされる前にすべてのルールを自動的に適用し、それ以上のデプロイ エラーを防止します。 次の図は、パイプラインが開発から本番へのアセットのプロモーションを自動化する方法を示しています。
図: パイプラインは、ソース管理に保存されている 資産 を開発からテスト、そして本番へと自動的に昇格します。
パイプラインに含める必要がある環境とプロセス (承認など) の数を構成できます。
パイプラインは環境グループと連携して動作します。 開発環境用に事前構成できるため、作成者はアセットを他のユーザーと共有しようとするときにプロンプトに応答するだけで、プロモーション プロセスを簡単に開始できます。 パイプラインを使用したデプロイメント リクエストの一環として、メーカーはアセットを共有する相手と必要なセキュリティ ロールを提案できます。 パイプライン管理者は、リクエストを発信した作成者に最小限の権限を与えることで、デプロイ前にリクエストを承認または拒否できます。
パイプラインは、デフォルトで管理されるホスト 環境 に各パイプラインの定義を保存します。 Power Platform Microsoft ただし、管理するテナント内に複数のホスト環境を定義して、固有の要件に対応できます。
Power Platform のカタログ
開発者やメーカーがアプリやフロー、テンプレートなどのコンポーネントを構築して共有する組織は、Power Platform より高度な出発点となることからより多くの価値を得る傾向があります。 Power Platform カタログ を使用すると、メーカーは環境間でコンポーネントとテンプレートをより効率的に 共有 できるようになります。
カタログは環境にインストールされ、同じ環境内のパイプライン ホストとともにインストールできます。 カタログがインストールされている複数の環境を用意することで、固有のリソース セグメンテーション要件を処理することもできます。
機能ロードマップ
ガバナンスと管理をサポートする機能が進化し続けるので、追従する で一緒に進んでください。 Microsoft リリース プランナー Power Platform 何が計画されているか、今後のリリース ウェーブには何が含まれているか、そして今何を試すことができるかがわかります。 フォローしたい項目を保存して、独自のリリース プランを作成することもできます。
エンタープライズ規模の環境戦略の基盤
エンタープライズ規模のテナント環境戦略に関する当社のビジョンと、それをサポートする主要な環境機能について説明しました。 ここでは、環境戦略の一環としてこれらの機能をどのように組み合わせて使用できるかを見ていきます。 戦略は組織固有の要件に基づいて策定する必要があります。まずは基本的な例から始めて、ニーズに合わせて戦略をカスタマイズする方法を見てみましょう。
この例では、Contosoの経営陣は従業員が Power Platform そして、次のような高レベルの要件を特定しました。
従業員は、自動化された文書承認プロセスやその他のMicrosoft 365 による Power Platform カスタマイズをビルドできる必要があります。
従業員は Power Apps そして Power Automate 自動化をビルドし、個人の生産性を向上させることができるべきです。
同社のコンプライアンス トラッカー アプリを開発する開発者は、アプリの開発と保守ができる必要があります。
これらの要件をサポートするために、Contoso の管理およびガバナンス チームは、次の環境トポロジを考案しました。
図: Contosoの Power Platform 大規模プロジェクト向けに提案された 環境 トポロジ。
この環境トポロジー図を詳しく見てみましょう。
デフォルト環境は、Microsoft 365 生産性カスタマイズを構築するために使用されます。 データ損失防止ポリシーと共有の制限により、他の種類のメーカーのアクティビティが制限され、メーカーがこの環境で構築できる内容にガードレールが設けられます。
試用版、サンドボックス、運用環境を作成できるのは管理者のみです。 メーカーはカスタム Microsoft フォームまたは別のプロセスを使用して、新しい 環境 をリクエストします。 使用できる 環境リクエスト を含む Microsoft Power Platform センターオブエクセレンス (CoE) スターターキット。
開発、共有開発、UAT (ユーザー受け入れテスト)、本番の 4 つの環境グループが作成されます。
開発グループに設定された環境ルーティング ポリシーは、作成者を既定の環境から独自の開発者環境にルーティングします。 新しい開発環境が作成されると、それらは自動的に開発グループに関連付けられ、そのルールが適用されます。
共有開発グループは、複数の作成者がいるプロジェクトを含む環境をサポートします。
UAT グループには、リソースを本番環境に昇格する前にテストするために使用される環境が含まれています。
運用グループには、運用環境で使用するアプリ、フロー、その他の成果物をホストする環境が含まれます。
この提案されたトポロジに欠けているのは、開発環境、テスト環境、および運用環境間のプロモーションを自動化するパイプラインです。 今すぐ追加してみましょう。
図: パイプライン ホスト 環境 を開発、テスト、および運用環境に接続するパイプラインを含む同じ 環境 トポロジ。
改訂された環境トポロジ図では、パイプライン ホスト環境と 2 つのパイプラインが追加されました。 1 つのパイプラインが、リソースを開発環境からテスト環境へ、そして運用環境へと移動します。 開発グループのパイプライン ルールは、このパイプラインを使用するように変更されます。 もうひとつのパイプラインが、リソースを共有開発環境からテスト環境へ、そして運用環境へと移動します。 共有開発グループのパイプライン ルールは、このパイプラインを使用するように変更されます。
この基本的な環境戦略は、次に説明する他のユースケースを構築するための基盤を提供します。
特定のシナリオに対する環境戦略
ここでは、基盤テナント環境戦略に組み込む必要がある可能性のある一般的なユースケースをいくつか示します。
開発者環境を作成できるメーカーを制御する
デフォルトでは、Power Platform Premium ライセンス、Developer Plan ライセンス、または Power Platform テナント管理者ロールを持つユーザーは誰でも、管理ポータルから開発者環境を作成できます。
基盤環境戦略では、環境ルーティングによって、作成者がデフォルトの環境から、指定されたグループで作成された新しい開発者環境に誘導されることが保証されます。 ただし、作成者は、環境グループに配置されず、そのルールが適用されない開発者環境を手動で作成することもできます。
環境ルーティングの対象となるメーカーを絞り込むには、ルーティング構成でセキュリティ グループを指定します。 セキュリティ グループが構成されている場合、セキュリティ グループのメンバーのみがルーティングされます。 その他はすべてデフォルトの環境にフォールバックします。
高度なメーカーにさらなる柔軟性を提供
基盤環境戦略では、すべての新しいメーカー環境は指定された開発者環境グループにルーティングされます。 通常、この環境グループには、かなり制限されたガバナンス ルール セットが適用されます。
メーカーがさらに上達するにつれて、より多くの機能へのアクセスをリクエストできるようにすることができます。 元の環境グループから削除して例外を手動で管理する代わりに、別の環境グループを使用してこれらの高度なメーカーを追跡できます。
図: ガバナンス ルールが緩和された 環境 に、より有能なメーカーを追加します。
地域や事業部門ごとに開発環境を整理する
環境ルーティングの現在の実装では、すべての新しい開発者環境が単一の環境グループに作成されます。 たとえば、メーカーの開発環境を地域別または事業部門別に整理したい場合はどうすればよいでしょうか?
ルーティングを使用して、指定されたグループに作成された新しい開発者環境に作成者を誘導します。 その後、地域、組織単位、またはその他の基準に基づいて別のグループに移動し、より詳細なガバナンス ルールを適用できます。
図: 環境 ルーティングによって指定されたグループ内に開発者環境が作成された後、それらをより構造的に特定のグループに移動します。
環境の移動は現時点では手動で行う必要がありますが、今後のアップデートで Power Platform 管理コネクタがグループ機能をサポートするようになると、自動化できるようになります。
企業向けアプリの開発
組織内のチームが、企業全体で使用するためのアプリを開発している場合があります。 チームは IT 主導の場合もあれば、IT ユーザーとビジネス ユーザーの両方が含まれる場合もあります (フュージョン チームと呼ばれる)。
最も単純な環境戦略では、プロジェクト チームはサンドボックスまたは運用環境のいずれかの共有環境で構築します。 開発者環境タイプは、リソース上で共同作業を行う複数の作成者をサポートする最適な方法ではありません。 ただし、共有環境内での衝突や競合を避けるために、メーカーは互いに通信する必要があります。
専用のテスト環境や運用環境は必要ありません。 アプリは、複数のアプリケーションをホストする組織全体のテスト環境と運用環境でテストおよび展開できます。
図: 専用環境で開発中の2つのエンタープライズ アプリ。その後、他のアプリと共有される環境でテストおよび展開されます。
より高度なバリエーションでは、各メーカーが個別の開発環境を備えています。 これには、作成者にとっての分離性が高まるという利点がありますが、統合環境での個々の作業の結合がより複雑になる可能性があります。 大規模で高度なチームにとっては、個別に作業することは有益ですが、共有開発環境での共同作業の方が成功する可能性のある小規模チームにとっては、不必要なオーバーヘッドが追加される可能性があります。
図: 個別の開発環境で同じアプリに取り組んでいる2人の開発者は、テストと本番環境に移行する前に、共有統合 環境 で作業を結合する必要があります。
このバリエーションには通常、ソース管理戦略が組み込まれており、各開発環境はソース管理内のブランチとして表され、変更をプロモートする準備ができたときにマージされます。 最初のリリース後にアプリケーションがどのように保守されるかを考慮することが重要です。
たとえば、チームがバージョン 2.0 の構築に移行している間、アプリのバージョン 1.0 が運用中である可能性があります。 環境戦略では、バージョン 2.0 の開発が進行中でも、バージョン 1.0 の問題の修正をサポートする必要があります。
図: バージョン2.0の開発、テスト、展開中に、バージョン1.0にパッチを適用し、テストし、展開する必要があります。
環境グループは、このエンタープライズ アプリのシナリオを処理するための複数のアプローチを提供します。 たとえば、単一のアプリ グループにすることも、開発段階ごとに個別のグループを作成することもできます。 ベスト プラクティスのセクションでは、オプションを評価する方法について説明します。
開発環境の使用を最小化する
個別の開発者環境は、開発者にローコード ソリューションを構築するためのワークスペースを提供するための推奨される方法です。 他のメーカーに比べて最高レベルの遮音性を提供します。 ただし、組織が開発者環境の数を最小限に抑えたい場合は、作成者にデフォルト環境でアセットを構築するよう促すよりも、複数の共有環境を使用する方が適しています。
このシナリオでは、開発者環境の作成を制限し、共有の運用型開発環境を作成します。 これらの共有環境は、組織構造、地域、その他の基準で整理できます。 環境グループにそれらを含めることで、一貫したガバナンス ルールが適用されることが保証されます。 割り当てられた環境でローコード アセットを作成する権限をメーカーに付与します。
環境戦略の一環としてのセキュリティ
環境は Power Platform を安全に使用することの重要な要素です。 これらは、アプリとデータの保護に役立つテナント内のセキュリティ境界を表します。 環境戦略の一環として、セキュリティ要件がテナント内の環境の数と目的にどのように影響するかを考慮する必要があります。
環境を使用すると、テナント内に複数のセキュリティ境界を作成して、アプリとデータを保護できます。 環境によって提供される保護は、構成可能な一連のセキュリティ機能を環境に適用することで、必要なセキュリティ保護を満たすように調整できます。 個々の環境のセキュリティ機能の詳細な説明は、この記事の範囲外です。 ただし、このセクションでは、テナント環境戦略の一部としてセキュリティをどのように考えるかについての推奨事項を示します。
テナントレベルのセキュリティ
環境に影響するセキュリティ設定のほとんどは、環境ごとに個別に構成されます。 ただし、環境戦略をサポートするために、テナント レベルでいくつかの変更を加えることができます。
- Power Platform の全員と共有機能を無効にする ことを検討してください。 管理者だけがアセットを全員と共有できるようになります。
- Exchange との統合を保護する ことを考慮してください。
- テナント間の分離 を適用して、テナント間のデータ流出のリスクを最小限に抑えます。
- 新しい運用環境の作成を管理者に制限します。 環境 の作成を制限すると 、予期せぬ容量消費を防ぎ、管理する環境の数を減らすことができるため、一般的に制御を維持するのに役立ちます。 ユーザーが中央 IT に環境を要求する必要がある場合、管理者がゲートキーパーであれば、ユーザーがどんな作業をしているかを簡単に確認できます。
既定の環境のセキュリティ保護
デフォルト環境は、Microsoft 365 生産性のカスタマイズをサポートする役割を担っています。 ただし、推奨される環境戦略の一環として、その使用を可能な限り最小限に抑えることが最善です。 代わりに、メーカーは独自の隔離された環境で構築する必要があります。 デフォルト環境へのアクセスをブロックすることはできませんが、その環境で実行できることを最小限に抑えることはできます。
まず、環境ルーティングを使用して、作成者を独自のワークスペースに誘導し、ローコード アセットを構築します。
デフォルトの環境への管理者アクセス権を持つユーザーを確認し、それを必要とするロールに制限します。
デフォルトの環境の名前を、"個人の生産性" などのよりわかりやすい名前に変更することを検討してください。
新しいコネクタをブロックし、作成者が基本的なブロックできないコネクタのみを使用するように制限する、デフォルト環境のデータ損失防止 (DLP) ポリシーを確立します。 ブロックできないすべてのコネクタをビジネス データ グループに移動します。 ブロック可能なすべてのコネクタをブロックされたデータ グループに移動します。
デフォルト環境のセキュリティ保護を優先する必要があります。 環境戦略を実装する最初のステップの一部として、テナント レベルのセキュリティとともに実行します。 これらが実装されていない場合、メーカーはデフォルトにアセットを追加する機会が増えます。 これらを環境ルーティングとともに導入することで、メーカーは独自の環境を使用することが推奨されます。
その他の環境の保護
ほとんどの組織と同様、デフォルトの環境に加えて複数の環境が存在します。 それぞれに必要なセキュリティのレベルは、含まれるアプリやデータによって異なります。 開発環境では通常、運用環境よりもルールが緩やかです。 一部の運用環境では、可能な限り最大限の保護が必要です。
環境戦略を確立する一環として、次の例のように、環境の一般的なセキュリティ レベルと各レベルを保護する機能を特定します。
図: 環境 セキュリティの3つの層と、各層の環境に適用されるセキュリティ機能の例。
特定したセキュリティ レベルをグループ戦略に組み込み、可能な場合はルールを使用して環境内のセキュリティ機能を有効にします。 この例では、ルールによって、通常または中程度のセキュリティとして指定されているすべての環境での共有が制限されます。
データ損失防止戦略に合わせて環境を調整する
データ ポリシーは、環境内のローコード リソースによって使用されるサービスを制御するための全体的なガバナンスの取り組みにおけるもう 1 つの重要な部分です。 環境グループには、環境に DLP ポリシーを適用するルールがありません。 ただし、DLP 戦略を環境グループに合わせて調整することは可能です。 たとえば、環境グループと同じまたは類似の名前を持つ DLP ポリシーを作成し、そのグループ内の環境に適用することができます。
図: この例では、Personal Devグループの環境は、すべての非コネクタをブロックするDLPポリシーを 追従する します。Microsoft
自分の組織に対して環境戦略を調整する
前のセクションでは、組織が大規模な環境を管理する方法に関する当社のビジョンについて説明しました。 重要な機能、それが環境戦略にどのように貢献するか、そしてそれらを使用する基盤環境トポロジがどのようなものになるかを検討しました。 一般的なシナリオに対応するために、その基盤をどのように構築するかについて例を示しました。 組織はそれぞれ異なるため、次のステップでは、組織のニーズを満たす環境戦略をカスタマイズする必要があります。
今いるところから始める
あなたの組織が初めて Power Platform を使用する場合でも、何年も使用している場合でも、最初のステップは状況を評価することです。 デフォルト環境に何が含まれているか、他にどのような環境があり、それらが何に使用されているかを大まかに評価します。 多くの場合、環境戦略は、組織内の Power Platform のガバナンスを確立するための全体的な取り組みの一環として実行されます。 その場合は、組織に合わせた戦略を策定するために必要なガバナンス ビジョンの一部がすでに確立されている可能性があります。
知っておくべき組織情報には以下が含まれます。
組織内でどのように Power Platform が使用されるかについてのビジョンは何ですか?
組織内でローコード資産を構築するのは誰ですか?
いくつかの重要な決定を行う必要があります。
メーカーはどのようにして新しい環境を手に入れるのでしょうか?
環境をグループ化しますか? グループ化する場合、どのようにグループ化しますか?
さまざまな環境にはどのようなセキュリティ レベルが必要であり、環境はどのように分類されるのでしょうか。
アプリ、自動化、または Copilot が既存の環境を使用するか、新しい環境を使用するかをどのように決定しますか?
プラットフォームのベースライン機能と、カスタム ガバナンス プロセスを必要とする要件の間にギャップはありますか?
デフォルト環境で既存のアセットをどのように処理しますか?
テナントおよび環境の DLP ポリシー戦略はありますか? ある場合、それは作成している環境戦略とどのように整合していますか?
また、インスピレーションは、Azure のクラウド導入フレームワークの一部である クラウド運用モデル でも得られます。
プラットフォームを使用してギャップを埋める
プラットフォームに組み込まれている機能では満たせない要件が必ず見つかります。 これらのギャップを評価する際には、次のような評価結果の可能性を考慮してください。
ギャップは許容範囲です。
このギャップは、Power Platform Center of Excellence スターター キットを使用して埋めることができます。
このギャップは、API、コネクタ、カスタム アプリ、自動化などのプラットフォームの機能を使用して埋めることができます。
このギャップは、サードパーティのツールまたはアプリを使用して埋めることができます。
CoE スターター キット
Power Platform Center of Excellence スターターキット は、組織が採用し、Power Platform の使用をサポートするのに役立つように設計されたコンポーネントとツールのコレクションです。 スターター キットの重要な側面は、環境全体のプラットフォームの使用状況に関するデータを収集できることです。これは、環境戦略を開発および進化させる際に役立ちます。
例えば、環境 Power BI ダッシュボードには、テナント内にどのような環境が存在するか、誰が作成したか、どのような資産が含まれているかを把握するのに役立つ概要が表示されます。
図: 環境ダッシュボード Power BI。
このキットには、メーカーが使用して 新しい環境を要求 するために使用でき、環境に応じた DLP ポリシーの変更をするプロセスなどの出発点やインスピレーションが含まれています。
図: CoEスターター キットの アイデア 管理プロセスを示すフロー図。
プラットフォームの プログラミング性と拡張性
ローコード プラットフォームの優れた点の 1 つは、管理に役立つアプリ、自動化、ポータル、コパイロットを構築できることです。 また、環境戦略をサポートするためにギャップを埋めるために使用できる低レベルのツールにもアクセスできます。
次のコネクタを使用してアプリとフローを構築できます。
Power Platform コマンドラインインターフェース (CLI) を使用して、環境ライフサイクルや DevOps プラクティスに関連するその他のタスクの管理に役立つ自動化を開発できます。
Power Platform 作成者と管理者向けの PowerShell コマンドレット を使用すると、現在手動でしか実行できない監視および管理タスクの多くを自動化できます。
Power Platform DLP SDK は、テナントおよび環境レベルのデータ損失防止ポリシーを管理できます。
ベスト プラクティスのレコメンデーション
この記事のこのセクションでは、基礎セクションとシナリオ固有のセクションの推奨事項を基に説明します。
新しい環境
戦略策定の一環として、ワークロードをサポートする環境をいつ作成するかを検討します。 評価では、環境が提供する分離の利点 (たとえば、特定の環境を他の環境よりもロックダウンできることは、セキュリティの観点から役立ちます) と、分離によってアプリ間でデータを共有しようとするユーザーに摩擦が生じるなどの欠点とのバランスを取る必要があります。
アプリまたは自動化が独自の環境に属するかどうかを評価するときは、アプリのライフサイクルのさまざまな段階を個別に評価します。 開発中は、他のアプリからの分離が重要です。 複数のアプリを単一の環境で開発すると、アプリ間の依存関係が生じるリスクがあります。
一般的な推奨事項としては、可能であれば、開発環境は単一目的で、使い捨てで、簡単に再作成できるものにする必要があります。
複数のアプリを本番環境で一緒に実行する場合は、同じ環境で複数のアプリをテストするのが理にかなっています。 実際、運用環境で実行されるアプリでテストしないと、互換性の問題を発見できないリスクがあります。
アプリの運用環境を評価するときは、次の点に留意してください。
アプリは環境内の既存のアプリと互換性がありますか? たとえば、Dataverse Contact テーブルを異なる目的で使用する 2 つのアプリは互換性がない可能性があります。 DLP ポリシーの観点から、アプリは互換性がありますか?
データの分離に関して特別なコンプライアンスまたは規制要件はありますか? たとえば、データの機密度を分離する必要がありますか? データを他のデータと一緒に含めることができないという要件はありますか?
データは機密性や機密性が高いものですか? 情報の流出により、組織に金銭的損害や評判上の損害が発生するでしょうか? 別の環境に分離することで、セキュリティをより細かく制御できるようになります。
アプリは他のアプリからのデータを必要とし、それらと一緒に配置する必要がありますか? たとえば、両方とも Customer テーブルを使用する 2 つのアプリは一緒にホストする必要があります。 これらを分離すると、冗長なデータのコピーが作成され、データの維持に問題が発生します。
データには地域データ保存が必要ですか? シナリオによっては、同じアプリまたは自動化を地域環境に展開して、適切なデータの分離と保存を確保できます。
ほとんどのユーザーは環境と同じリージョンにいますか? 環境が EMEA にあるが、アプリのユーザーのほとんどが米国を拠点としている場合、環境を共有しても最高のパフォーマンスが得られない可能性があります。
新しい管理者が必要になりますか、それとも既存の管理者で十分でしょうか? 新しいアプリにさらに多くの管理者が必要な場合、すべての管理者が環境内のすべてのアプリに対する管理者権限を持つため、既存の管理者と互換性がありますか?
アプリの寿命はどのくらいですか? アプリまたは自動化が一時的または短期間である場合は、より永続的なアプリがある環境にインストールすることはお勧めできません。
ユーザーは、異なるアプリごとに複数の環境を使用する必要があるため、困難を感じるでしょうか? これは、モバイル デバイスでのアプリの検索から、複数の環境からデータを取得する必要があるセルフサービス レポートまで、あらゆることに影響を及ぼす可能性があります。
キャパシティ
各環境 (試用版環境と開発者環境を除く) は、最初のプロビジョニングに 1 GB を消費します。 容量はテナント全体で共有されるため、それを必要とするユーザーに割り当てる必要があります。
次の方法で容量を節約します。
- 共有環境と運用環境を管理します。 共有開発環境とは異なり、テスト環境と運用環境でのアクセス許可は、テスト用のユーザー アクセス権に制限する必要があります。
- 一時的な開発環境のクリーンアップを自動化し、テストまたは概念実証作業のための試用環境を使用することをお勧めします。
環境グループ
環境グループは柔軟性があり、組織固有のさまざまなユースケースに対応できます。 環境戦略の一環として環境をグループ化することを検討できるいくつかの方法を次に示します。
サービスまたはコンポーネント別。例: ServiceNow サービスツリー
開発、テスト、生産
部門、ビジネスグループ、またはコストセンター
プロジェクト別
場所別、ある場所のほとんどの環境が同様のガバナンスニーズを持っている場合、これは同様の地域の規制や法的コンプライアンスを満たすのにも役立ちます
図: 2つの異なる部門の 環境 グループには異なるルールがあります。
環境とグループの命名
戦略の一環として、環境とグループの名づけ方法を検討してください。
環境名は管理者、作成者、ユーザーに表示されます。 通常、環境グループを使用するのは管理者のみですが、環境を作成する権限を持つ作成者も環境グループに遭遇する可能性があります。
自動的に作成される開発者環境は、パターン <ユーザー名>の環境 に従います。たとえば、"Avery Howard の環境" などです。環境グループの名前は自動的には付けられません。
環境名と環境グループ名は一意である必要はありません。 ただし、混乱を避けるために、重複した名前を避けるのがベストプラクティスです。
名前は 100 文字に制限されています。 名前が短いほど使いやすくなります。
一貫した命名規則を確立します。
一貫した名前を使用すると、管理者はグループの目的と管理する環境を把握しやすくなり、自動化とレポート作成が容易になります。
一般的な方法としては、環境の名前にライフサイクル ステージを含めます (例: Contoso Dev、Contoso Test、Contoso Prod)。目的は、コンテンツは同じでも目的が異なる環境を明確に区別することです。
もう 1 つの一般的な方法は、環境が特定のユーザー グループ専用である場合に、名前に部門または部署を含めることです。
たとえば、すべての環境名または環境グループ名が、<ライフサイクル ステージ>-<リージョン>-<ビジネス ユニット>-<目的> (Prod-US-Finance-Payroll) というパターンに従う必要があると決定する場合があります。
名前は短く、意味があり、説明的な内容にしてください。
グループが時間の経過とともにどのように進化し、成長するかを考え、命名規則がこれらの進化するニーズに対応できることを確認してください。
名前に機密情報を含めないようにしてください。 管理センターにアクセスできるすべてのユーザーに表示されます。
既定の環境のアセット
環境戦略では、デフォルトの環境で作成されるものを減らすために、個人用の開発環境の使用を奨励 (または強制) する必要があります。 ただし、メーカーがデフォルト環境ですでに作成しているものを確認し、各ユースケースの処理方法を評価する必要があります。 デフォルトの環境のままにしておくのが適切でしょうか、それとも別の環境に移行する必要がありますか?
この衛生管理作業を実行する上で重要な部分は、組織内で広く使用され、運用環境とは別の独自の保護された開発環境を持つ必要があるアプリケーションを特定することです。
次の表に、ユースケースと移行アクションの例を示します。 最終的には、組織は、資産をデフォルト環境に残すことに関連する独自のユースケースとリスク要因を特定する必要があります。 デフォルトの 環境 からアセットを移動するタイミングについて詳しくは、こちらをご覧ください。
| デフォルト 環境 | 移住活動 |
|---|---|
| Microsoft 365 個人の生産性 | 既定の環境に留まります。 |
| 最近使用されたが共有されていない、単一のメーカーを持つアセット | 所有者の個別の開発環境に移動します。 |
| 最近使用されて共有された、単一のメーカーを持つアセット | 所有者の個別の開発環境に移動し、共有の本番環境から実行します。 |
| 最近使用されて共有された、複数のメーカーを持つアセット | 共有開発者環境に移動し、共有の運用環境から実行します。 |
| 最近使用されていないアセット | 所有者に通知し、応答がない場合は隔離します。 |
Dataverse for Teams 環境のアセット
Microsoft Dataverse for Teams ユーザーは、 Microsoft Teams Power Apps、 Microsoft Copilot Studio、 Power Automate を使用して、カスタム アプリ、ボット、フローを構築できます。 チームの所有者がこの機能をチームに追加すると、Dataverse for Teams データベースのある Microsoft Power Platform 環境が作成され、チームにリンクされます。 環境を管理するためのガバナンス ポリシーを確立する方法を学びます。 Microsoft Dataverse for Teams
環境戦略は内部的に Microsoft
Microsoft 同社は、従業員の間で自動化と効率化を推進するために社内で Power Platform を採用しているため、自らを「カスタマー ゼロ」とみなしています。 次の数値は、内部テナント全体の使用規模の概略を示しています。 Microsoft
毎月のアクティブメーカー数 50,000-60,000
250,000 以上のアプリケーションと 300,000 以上のフロー
20,000 以上の環境
Microsoft 以前の 環境 戦略から、環境, 環境 グループやルールなどの最新の Power Platform ガバナンス機能を使用する戦略に移行しています。
強化された戦略の一環として、開発タイプ、組織の所有権、およびリスク レベルに基づいてシナリオをグループ化することを計画しています。 Microsoft 会社全体で非常に多くのものが構築されているため、考えられるすべてのシナリオに焦点を当て、各ユースケースに合わせてカスタマイズするのは非常に困難です。 発生する処理が多すぎるため、自動化し、すぐに使用できるコントロールを可能な限り多く活用する必要があります。
Microsoft は、個人の生産性、チームのコラボレーション、エンタープライズ開発という、リスクと制御の程度が異なる7つのユース ケースをカバーする3つの広範なカテゴリに環境を構築しています。 Power Platform
個人の生産性 – これは、自分用のアプリやフローを構築したい人向けです。 たとえば、彼らは他の人と協力していません。 これらのユーザーは、ロックダウンされた個人開発環境にルーティングされます。 これらの環境では、共有の制限や、環境内で実行できるその他の操作の制御など、管理対象環境の機能が使用されます。 この環境グループでは、使用可能なコネクタとアクションは大幅に制限されています。 これらの環境はリスクが最も低くなります。 ロックダウンされた個人環境を使用すると、ユーザーは個人の生産性向上アプリやフローを構築するためだけに、より厳格なコンプライアンス プロセスを回避できます。
チームコラボレーション – これは、チーム用のツール、自動化、プロセスを構築しているユーザー向けです。 このシナリオでは、 Microsoft 環境の使用を推奨します Dataverse for Teams 。 ライフサイクル、アクセス管理、データラベル付けは、Microsoft 365 グループレベルで管理できるので、Power Platform ガバナンスの観点からはこれらのユーザーを一元的に管理する手間が省けます。 このレベルの使用は、リスク スペクトルの次のステップです。
すべての従業員が使用するエンタープライズ開発/生産レベル – 会社全体で広く使用されるツールやソリューションを構築する人々です。 これらの環境では、最も機密性の高いデータが保存され、より強力なコネクタが使用され、より多くのガバナンスが必要になる可能性があります。 これは最も高いリスクであると考えられており、ガバナンスに最も多くの労力が費やされます。 ALM は必須であり、サンドボックス環境で実稼働前の作業が行われ、実稼働環境では管理されたソリューションのみが許可されます。 これらの環境は、セキュリティとプライバシーの定期的なレビューを実施する ServiceTree にリンクする必要があります。 環境グループ ルールは、ServiceTree メタデータとシグナルに基づいてカスタマイズされます。 これらの環境を管理および制御するために、多くの環境グループとルールが使用されます。
Microsoftのガバナンス戦略は静的なものではありません。 流動的であり、新たな課題に適応し、新しい Power Platform 機能を組み込むために変化します。
テナント環境戦略を革新する
この記事では、エンタープライズ規模のテナント環境戦略を確立する方法について説明しました。 この体験をどこから始めるかに関係なく、戦略はビジネスとともに成長することができます。 私たちが提示する戦略は、あらゆる規模の組織にメリットをもたらしますが、すでに規模が大きい組織にとっては、より大きなメリットをもたらします。
テナント環境戦略の策定は、一度限りの活動ではありません。 これは体験です。 ニーズの変化に応じて、戦略を進化させる必要があります。 プラットフォームの新しい機能を採用し、新しい課題に対処するために、戦略も調整する必要があります。
すべての旅と同じように、さまざまな組織がさまざまな地点で合流しますが、目的地はすべて同じです。 以下は、組織の現在の状況を表す、考えられるオンランプです。
先頭
あなたの組織は Power Platform 導入への道のりの始まりにいます。 これは、グリーンフィールド と呼ばれます。 既存の環境や、新しいポリシーが組織内のユーザーの Power Platform 使用方法に与える影響について心配する必要がないため、最適な場所から始めることができます。 これは、製品の機能とベスト プラクティスに沿ったエンタープライズ規模の環境戦略を実装するのに最適な時期です。
この記事で概説されている主要な環境機能と戦略を調べてください。 要件に最適なテナント環境戦略を設計および実装するために必要な主要なテーマと考慮事項および決定を理解するために時間を取ってください。
明確な戦略を持たずに始めると、後から制御不能な状況に陥る可能性が出てきますが、それを避けるためには、今しっかりとした基盤を確立することが不可欠です。 Power Platformの使用を急速に加速する計画を立てますが、必要のない複雑さを追加して環境戦略を過剰に設計しないようにしてください。 これは体験であり、ニーズの変化に応じて戦略を進化させ続けることができることを忘れないでください。
Align
組織には環境戦略があり、それを実行していますが、新しい Power Platform 機能やベスト プラクティスに合わせて変更する必要があります。 これは、ブラウンフィールド と呼ばれます。 立ち上げたばかりの組織とは異なり、環境戦略の変更が組織に与える影響を考慮する必要があります。
この記事で概説されている主要な環境機能と戦略を検討し、戦略をより一貫したものに進化させるために何が必要かを評価します。 通常、必要なのは段階的な調整だけです。 可能であれば、ユーザーへの影響を最小限に抑えるように変更の展開を計画してください。
以下の提案は、実装可能な一般的な増分変化です。
既存の環境に影響を与えずに調整を開始するには、新しい開発者環境を含む環境グループを作成し、それらを管理するためのルールを確立します。 環境ルーティングをオンにして、すべての新しい開発者環境が指定されたグループ内に作成されるようにします。
グループ化戦略を評価し、必要に応じて既存の環境をサポートするグループを作成します。 既存の制限と例外に一致するグループに関するルールを確立します。 既存の環境をそれらのグループに移動します。
デフォルト環境で構築され、使用されている、広く普及しているアプリケーションを特定します。 パイプラインを使用して、組織内のユーザーが実行できる運用環境にパイプラインを公開します。 次に、それらのアプリの開発を個別の開発者環境または専用の開発環境に移行します。
デフォルト環境で使用されていない資産を識別、隔離、削除するための計画を作成します。
拡張
実行している環境戦略は、すでに最新の機能とベスト プラクティスに準拠していますが、組織ではさらに多くのコントロールや機能を追加したいと考えています。
環境戦略を組織とコミュニケーションさせる
Power Platform ユーザーが達成しようとしていることを理解し、それに同調すれば、テナント環境戦略をより効果的に実装できます。 コミュニケーションなしに戦略をただ実行するだけでは、ユーザーは変更を制限と見なし、回避策を探します。
戦略の開発または進化の一環として、ユーザーの Power Platform 使用に影響する戦略の主要要素をユーザーに通知する方法を決定します。 彼らに必要なのは、戦略の技術的な詳細すべてではなく、生産性の維持に役立つ次のような基本的な情報だけです。
既定環境の目的
新しいローコード資産を構築すべき場所
個人開発者環境をどのように活用すべきか
特定の部署またはプロジェクトのためにカスタム環境を要求する方法
一般的なコネクタの使用ポリシーと、環境に対してコネクタ権限をさらに要求する方法
作ったものを他の人と共有する方法
作成者の責任例:
テナントをクリーンな状態に維持します。 環境、アプリ、フローは不要になった場合に削除します。 実験する場合は、テスト環境を使用してください。
賢く共有します。 環境、アプリ、フロー、共有接続の過剰共有に注意してください。
組織のデータを保護します。 極秘データ ソースまたは機密データ ソースから、保護されていないストレージまたは外部ストレージへのデータの移動を回避します。
戦略を変更したら、変更がユーザーにどのような影響を与えるかを共有して、ユーザーが何を変更すればよいかを知るようにします
良いスタートとしては、新しいメーカーが追加される環境グループで メーカーのウェルカム コンテンツをオンにする ことです。
図: ウェルカム コンテンツを使用して、新しいメーカーが成功できるように支援します。
ユーザーとコミュニケーションをとるもう 1 つの効果的な方法は、内部 Power Platform ハブを確立することです。 このハブは、プロジェクトで人々が協力し、アイデアを共有し、テクノロジーを適用してより多くのことを達成するための新しい方法を発見する場所です。 ハブは、ユーザーに関連する環境戦略に関するより詳細な情報を共有する場所になります。 内部 Power Platform ハブを作成する方法を学習します。
結論
この記事では、組織がエンタープライズ規模で Power Platform 環境を管理し、それをテナント環境戦略に組み込むのに役立つように設計された機能について説明しました。
組織が Power Platform を採用し、使用が加速するにつれて、環境に対するニーズは急速に変化する可能性があります。 環境戦略が変化に対応し、組織の進化するガバナンス要件を継続的に満たすのに役立つ、俊敏なアプローチが必要です。
テナント環境戦略を成功させるための重要な要素は、作成者やユーザーとコミュニケーションを取り、彼らのサポートを得ることです。 ローコード アプリケーションと自動化を構築する担当者が、組織の環境戦略に従う方法と、ローコード アセットを構築する場所を把握していることを確認します。
各組織の Power Platform 採用への道のりはユニークです。 正しいスタートを切るために役立つアイデアをいくつかご紹介しました。 貴社の Microsoft アカウント チームまたは Power Platform パートナーは、組織向けにさらにカスタマイズされたテナント 環境 戦略の作成をお手伝いします。