あらゆる組織の Microsoft Power Platform の導入への道のりはユニークです。 テナント環境戦略は、管理しやすく安全な方法で使用を促進するための基盤を築きます。
この記事では、Power Platform のテナント環境戦略を製品の機能とビジョンに適合させる方法について説明します。 プラットフォームの最新機能を最大限に活用して、エンタープライズ規模に到達するために Power Platform の導入を可能にする戦略を実装する方法について学びます。
概要
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 ビルド環境に最適です。 |
| Developer | これらの特別な環境は、ローコード資産をユーザーや他のメーカーから分離する、メーカーの個人的な開発ワークスペースとして意図されています。 メーカーは最大 3 つの開発者環境を持つことができます。 これらはテナントの収容人数にはカウントされません。 90 日間使用されていない開発者環境は自動的にオフになり、所有者が通知に応答しない場合はテナントから削除されます。 Dynamics 365 アプリは開発者環境では利用できませんか ? |
| 試用版 | これらの環境は、短期間のテストと概念実証をサポートすることを目的としています。 ユーザーごとに 1 つに制限されます。 試用環境は、しばらくするとテナントから自動的に削除されます。 |
| Microsoft Dataverse for Teams | これらの環境は、Teams でアプリを作成するか、アプリ カタログからアプリをインストールすると自動的に作成されます。 これらの環境のセキュリティ モデルは、関連付けられているチームと一致します。 |
| サポート | これらは、エンジニアが問題をトラブルシューティングできるように Microsoft サポートによって作成された特別な環境です。 これらの環境はテナントの収容人数にはカウントされません。 |
全体的なテナント環境戦略を作成するときは、推奨事項をサポートするさまざまなタイプを検討してください。
マネージド環境
環境には、環境タイプに応じて基本的な機能と特性のセットがあります。 マネージド環境は、管理者がより細かい制御、より少ない手間で、より多くの分析情報を使用して Power Platform の大規模な管理を簡単に可能にするプレミアム機能のスイートを提供するための基本的な機能の上に拡大します。 これらの機能は、環境を管理対象として設定するとロック解除されます。
次の表は、この記事の執筆時点で利用可能な管理環境の機能を示しています。 新しい機能は頻繁に追加されるため、最新のリストについては ドキュメント を確認してください。 すべての機能は環境戦略の構築に役立ちますが、斜体で表記された機能は、この記事で概説されている戦略に特に関連しています。
| サイトの可視性 | その他のコントロール | 労力の削減 |
|---|---|---|
|
使用状況の分析情報 管理者ダイジェスト ライセンス レポート データ ポリシー ビュー Azure Application Insights へのデータのエクスポート すべてのアプリの説明を AI で生成する |
共有制限 デスクトップ フローのデータ損失防止ポリシー ソリューションのチェック 作成者を歓迎するコンテンツ IP ファイアウォール IP Cookie バインド カスタマー マネージド キー カスタマー ロックボックス 拡張バックアップ |
アクティブ化の簡素化 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 サービスも環境ルーティング機能をサポートするようになります。
作成者を歓迎するコンテンツ
Power Apps と Copilot Studio の使用を開始する作成者を支援するために、 カスタマイズされたウェルカム コンテンツ を提供します。 独自のヘルプ コンテンツを追加すると、作成者が初めてヘルプを利用するときにデフォルトの Power Apps が置き換えられます。 カスタムウェルカムメッセージは、会社のルールと、各環境または環境のグループでできることについて作成者に通知できます。
組織が各種類の環境でウェルカム メッセージを使用する方法に関する推奨事項をいくつか次に示します。 ユーザーの導入とエラー防止に役立つ環境の種類または所有者を識別するイメージを含めます。
既定の環境
多くの場合、既定の環境は、データ ポリシーと共有コントロールを使用して、最も制限されます。 制限事項と考えられる制限事項について作成者に警告するウェルカム メッセージを作成し、組織のポリシー Web サイトまたはドキュメントへのリンクを含めます。
たとえば、Microsoft 365 アプリケーションに関連するソリューションに対してのみ既定の環境を使用するように作成者に通知し、既定の環境では運用アプリケーションを使用しないようにし、キャンバス アプリを共有するユーザーの数が限られている場合があります。 次の例は、Managed Environments 設定でこのようなメッセージを作成する方法を示しています。
Markdown 入力の例:
## Welcome to Contoso Personal Productivity Environment
### Before you start, here are some considerations
Use this environment if you plan to build apps that integrate with Office 365.
Before you start, be aware of these limitations:
1. You can't share your apps with more than five users.
1. The data in Dataverse is shared with everyone in the organization.
1. You can only use Office 365 connectors.
If you're not sure you're in the right place, follow **[this guidance](#)**.
表示されるウェルカム メッセージを次に示します。
運用環境
運用環境は、通常、エンタープライズとチームの生産性をサポートするソリューションをデプロイするために使用されます。 アプリとデータが組織のポリシーに準拠することが重要です。 運用環境にアクセスできるユーザーを制御する必要があるため、アクセスを更新するポリシーがあるかどうかをユーザーに通知することをお勧めします。 より多くのコネクタを許可し、運用環境で共有の制限を増やすことがあります。 ウェルカム メッセージを使用して、適切なチームがサポートに連絡できるように作成者に通知することもできます。 次の例は、このようなメッセージを作成する方法を示しています。
## Welcome to HR Europe Environment
### Before you start, here are some considerations
Use this environment if you're on the HR team and your data is located in Europe.
Before you start, be aware of these limitations:
1. You can only share apps with security groups. [Follow this process](#) to share your apps.
1. The data in Dataverse is stored in Europe.
1. You can only use social media connectors with read actions.
1. If you need more connectors, [submit a request](#).
If you're not sure you're in the right place, follow **[this guidance](#)**.
出力例を次に示します。
開発者向け環境
開発者環境は、ほとんどの場合、開発者がソリューションを構築する場所です。 開発者はアプリケーションに取り組んでいるため、運用環境にないため、スケーラビリティは制限されます。 通常、開発環境では、作成者の性質により、より緩やかなデータ ポリシーが用意されています。 開発者が開発環境で運用資産を使用しないようにするには、共有機能を制限し、この種類の環境に特定のデータ ポリシーを使用します。 開発環境のウェルカム メッセージの例を次に示します。
## Welcome to a Developer Environment
### Before you start, here are some considerations
Use this environment if you're a developer and you're building solutions.
Before you start, be aware of these limitations:
1. You can only share resources with up to two members of your team. If you need to share with more people, [submit a change request](#).
1. Use resources only while you're developing a solution.
1. Be mindful of the connectors and data you're using.
1. If you need more connectors, [submit a request](#).
If you're not sure you're in the right place, follow **[this guidance](#)**.
開発環境の出力例を次に示します。
サンドボックス環境
通常、サンドボックス環境はソリューションのテストに使用されます。 一部のテストにはかなりの数のユーザーが含まれているため、これらの環境は 1 ポイントまでスケールアップされ、開発環境よりも多くの容量を持ちます。 サンドボックス環境は開発環境としても一般的に使用され、通常は複数の開発者によって共有されます。 このような環境のウェルカム メッセージの例を次に示します。
## Welcome to a Test Environment
### Before you start, here are some considerations
Use this environment only if you're testing solutions.
Before you start, be aware of these limitations:
1. You can only share resources with your team. If you need to share with more people, [submit a change request](#).
1. You're not allowed to edit or import solutions directly in this environment.
1. Be mindful of the test data and compliance.
1. If you need help from a security export or IT support, [submit a request](#).
If you're not sure you're in the right place, follow **[this guidance](#)**.
サンドボックスまたはテスト環境の出力例を次に示します。
共有制限
管理者は、 ユーザーがキャンバス アプリ、フロー、エージェントを共有できる範囲を制限できます。 ただし、この制限は今後の共有にのみ適用されます。 既に 20 人を超えるユーザーと共有されているリソースがある環境に共有制限 20 を適用した場合、それらのリソースは、リソースが共有されているすべてのユーザーに対して引き続き機能します。 新しい制限を超えて共有されているアプリ、フロー、エージェントを作成者に通知するプロセスを作成します。これにより、リソースが共有されるユーザーの数を減らすことができます。 場合によっては、ソリューションを別の環境に移動する場合があります。 共有の制限は、キャンバス アプリ、フロー、エージェントに適用されます。
管理者は通常、次の場合に作成者がアプリ、フロー、エージェントを共有する方法を制御する必要があります。
リソースは、個人の生産性環境で共有されます。 ユーザーが自分の仕事用のリソース、グローバルなビジネス価値のないリソース、または IT のサポートのないリソースを作成できる環境がある場合は、作成者が組織全体でリソースを共有できないようにすることが重要です。 リソースが個人の生産性として始まり、後で人気が高まり、広く使用される場合は、共有に設定した制限に注意してください。 一般的な制限は、5 ~ 50 人のユーザーです。
リソースは、セキュリティ グループまたはすべてのユーザーと共有されます。 セキュリティ グループと共有されるリソースは、グループのすべてのメンバーが実行できます。 開発者環境では、グループ メンバーシップに依存するのではなく、リソースの共有方法を開発者が制御できます。 他のシナリオでは、すべてのユーザーとの共有を許可することができます。 組織のポリシーで、リソースの実行が承認され、IT 部門によって管理されているすべてのユーザーを含むセキュリティ グループとリソースが共有されている場合は、作成者が他のセキュリティ グループと共有できないように制限できます。
環境の種類ごとに共通の共有制限を次に示します。
既定値: [ セキュリティ グループとの共有を除外する] を選択し、[ 共有できるユーザーの合計数を制限する] を選択し、値として 20 を選択します。
開発者: [ セキュリティ グループとの共有を除外する] を選択し、[ 共有できるユーザーの合計数を制限する] を選択し、値として 5 を選択します。
サンドボックス: [ セキュリティ グループとの共有を除外する ] を選択し、[ 共有できる個人の合計数 を選択しない] のままにします。 アプリケーションを実行する権限を持つユーザーを含む IT マネージド セキュリティ グループとアプリが共有されている場合は、このオプションを使用します。 メーカー、ユーザー、またはチームがソリューションのテストを許可されているユーザーを管理できる場合は、[ 制限を設定しない ] (既定) を選択します。
運用環境: [ 制限を設定しない ] (既定値) を選択します。 特定のセキュリティ グループに基づいて共有を制御するには、[ セキュリティ グループとの共有を除外する ] を選択し、[ 共有できる個人の合計数 を選択しない] のままにします。
マイクロソフト 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 が既定で管理するホスト環境に各パイプラインの定義を保存します。 ただし、管理するテナント内に複数のホスト環境を定義して、固有の要件に対応できます。
ソリューション チェッカー強制
センター オブ エクセレンス (CoE) チームは、ユーザーが非準拠ソリューションを環境にインポートするリスクを軽減するためにガードレールを設定するのが一般的です。 管理者は、問題のあるパターンを特定するために、一連のベスト プラクティス ルールに対して ソリューションの豊富な静的分析チェック を簡単に適用できます。 分散型 CoE を使用している組織では、多くの場合、ソリューション チェッカーの適用をアクティブ化し、サポートを提供するためにメールで作成者に積極的に連絡する必要があります。
ソリューション チェッカーの適用では、None、Warn、Block の 3 つのレベルの制御が提供されます。 管理者は、警告を提供するがインポートを許可するか、インポートを完全にブロックするかに関係なく、チェックの効果を構成すると同時に、インポートの結果を作成者に提供します。
この機能を使用する組織では、環境の種類に応じて構成が異なります。 通常は例外があり、このガイダンスは常にニーズに合わせて調整する必要があります。 ただし、各環境の種類でのソリューション チェッカーの適用に関する最も一般的な設定を次に示します。
- デフォルト: ブロック と メールを送信 を選択します。
- 開発者: [警告 ] を選択し、[ メールの送信] をオフのままにします。
- サンドボックス: [警告 ] を選択し、[ メールの送信] をオフのままにします。
- 運用環境: ブロック と 送信メール を選択します。
- Teams 環境: ブロック および メールを送信 を選択します。
Power Platform のカタログ
開発者や作成者がアプリ、フロー、テンプレートなどのコンポーネントを構築し、共有する組織は、先進的な出発点であり、Power Platform からより多くの価値を得る傾向があります。 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 生産性のカスタマイズをサポートする役割を担っています。 ただし、推奨される環境戦略の一環として、その使用を可能な限り最小限に抑えることが最善です。 代わりに、メーカーは独自の隔離された環境で構築する必要があります。 デフォルト環境へのアクセスをブロックすることはできませんが、その環境で実行できることを最小限に抑えることはできます。
まず、環境ルーティングを使用して、作成者を独自のワークスペースに誘導し、ローコード アセットを構築します。
デフォルトの環境への管理者アクセス権を持つユーザーを確認し、それを必要とするロールに制限します。
デフォルトの環境の名前を、"個人の生産性" などのよりわかりやすい名前に変更することを検討してください。
新しいコネクタをブロックし、作成者が基本的なブロック解除可能なコネクタのみを使用するように制限する既定の環境のデータ ポリシーを確立します。 ブロックできないすべてのコネクタをビジネス データ グループに移動します。 ブロック可能なすべてのコネクタをブロックされたデータ グループに移動します。
カスタム コネクタで使用されるすべての URL パターンをブロックするルールを作成します。
既定環境の安全確保は最優先事項です。 環境戦略の第一歩として、テナント レベルのセキュリティとともに導入してください。 これらの対策を行わないと、作成者は既定の環境に資産を追加できます。 これらの対策と環境ルーティングを実施することで、作成者は独自の環境を使用することをお勧めします。
詳細情報: 既定の環境を確保する
その他の環境の保護
ほとんどの組織と同様、デフォルトの環境に加えて複数の環境が存在します。 それぞれに必要なセキュリティのレベルは、含まれるアプリやデータによって異なります。 開発環境では通常、運用環境よりもルールが緩やかです。 一部の運用環境では、可能な限り最大限の保護が必要です。
環境戦略を確立する一環として、次の例のように、環境の一般的なセキュリティ レベルと各レベルを保護する機能を特定します。
図: 環境セキュリティの 3 つの層と、各層の環境に適用されるセキュリティ機能の例。
特定したセキュリティ レベルをグループ戦略に組み込み、可能な場合はルールを使用して環境内のセキュリティ機能を有効にします。 この例では、ルールによって、通常または中程度のセキュリティとして指定されているすべての環境での共有が制限されます。
環境をデータ ポリシー戦略に合わせる
データ ポリシーは、環境内のローコード リソースによって使用されるサービスを制御するための全体的なガバナンスの取り組みにおけるもう 1 つの重要な部分です。 環境グループには、環境にデータ ポリシーを適用する規則はありません。 ただし、データ ポリシー戦略は環境グループに合わせて調整できます。 たとえば、環境グループと同じまたは同じ名前のデータ ポリシーを作成し、そのグループ内の環境に適用できます。
データ ポリシー戦略を実装する方法の詳細について説明します。
図: この例では、Personal Dev グループ内の環境は、Microsoft 以外のすべてのコネクタをブロックするデータ損失防止 (DLP) ポリシーに従います。
自分の組織に対して環境戦略を調整する
前のセクションでは、組織が大規模な環境を管理する方法に関する当社のビジョンについて説明しました。 重要な機能、それが環境戦略にどのように貢献するか、そしてそれらを使用する基盤環境トポロジがどのようなものになるかを検討しました。 一般的なシナリオに対応するために、その基盤をどのように構築するかについて例を示しました。 組織はそれぞれ異なるため、次のステップでは、組織のニーズを満たす環境戦略をカスタマイズする必要があります。
今いるところから始める
あなたの組織が初めて Power Platform を使用する場合でも、何年も使用している場合でも、最初のステップは状況を評価することです。 デフォルト環境に何が含まれているか、他にどのような環境があり、それらが何に使用されているかを大まかに評価します。 多くの場合、環境戦略は、組織内の Power Platform のガバナンスを確立するための全体的な取り組みの一環として実行されます。 その場合は、組織に合わせた戦略を策定するために必要なガバナンス ビジョンの一部がすでに確立されている可能性があります。
知っておくべき組織情報には以下が含まれます。
- 組織内でどのように Power Platform が使用されるかについてのビジョンは何ですか?
- 組織内でローコード資産を構築するのは誰ですか?
いくつかの重要な決定を行う必要があります。
- メーカーはどのようにして新しい環境を手に入れるのでしょうか?
- 環境をグループ化しますか? グループ化する場合、どのようにグループ化しますか?
- さまざまな環境にはどのようなセキュリティ レベルが必要であり、環境はどのように分類されるのでしょうか。
- アプリ、自動化、または Copilot が既存の環境を使用するか、新しい環境を使用するかをどのように決定しますか?
- プラットフォームのベースライン機能と、カスタム ガバナンス プロセスを必要とする要件の間にギャップはありますか?
- デフォルト環境で既存のアセットをどのように処理しますか?
- テナントと環境のデータ ポリシー戦略はありますか。その場合、作成する環境戦略とどのように一致しますか?
Azure のクラウド導入フレームワークの一部であるクラウド運用モデルからインスピレーションを得られる可能性があります。
プラットフォームを使用してギャップを埋める
プラットフォームに組み込まれている機能では満たせない要件が必ず見つかります。 これらのギャップを評価する際には、次のような評価結果の可能性を考慮してください。
- ギャップは許容範囲です。
- このギャップは、Power Platform Center of Excellence スターター キットを使用して埋めることができます。
- このギャップは、API、コネクタ、カスタム アプリ、自動化などのプラットフォームの機能を使用して埋めることができます。
- このギャップは、サードパーティのツールまたはアプリを使用して埋めることができます。
CoE スターター キット
Power Platform Center of Excellence スターターキット は、組織が採用し、Power Platform の使用をサポートするのに役立つように設計されたコンポーネントとツールのコレクションです。 スタート キットの重要な側面は、環境全体のプラットフォームの使用状況に関するデータを収集する機能です。これは、環境戦略を開発および進化させる際に役立ちます。
例えば、環境 Power BI ダッシュボードには、テナント内にどのような環境が存在するか、誰が作成したか、どのような資産が含まれているかを把握するのに役立つ概要が表示されます。
図: Power BI の環境ダッシュボード。
キットには、作成者が 新しい環境を要求 したり、環境のデータ ポリシーを変更したりするためのプロセスなど、出発点やインスピレーションが含まれています。
図: CoE スターター キットの環境管理プロセスを示すフロー図。
プラットフォームの プログラミング性と拡張性
ローコード プラットフォームの優れた点の 1 つは、管理に役立つアプリ、自動化、ポータル、コパイロットを構築できることです。 また、環境戦略をサポートするためにギャップを埋めるために使用できる低レベルのツールにもアクセスできます。
次のコネクタを使用してアプリとフローを構築できます。
- Power Platform for Admins と Power Platform for Admins V2
- Power Apps for Admins と 作成者用 Power Apps
- Power Automate の管理
Power Platform コマンドラインインターフェース (CLI) を使用して、環境ライフサイクルや DevOps プラクティスに関連するその他のタスクの管理に役立つ自動化を開発できます。
Power Platform 作成者と管理者向けの PowerShell コマンドレット を使用すると、現在手動でしか実行できない監視および管理タスクの多くを自動化できます。
Power Platform DLP SDK は、テナントおよび環境レベルのデータ損失防止ポリシーを管理できます。
ベスト プラクティスのレコメンデーション
この記事のこのセクションでは、基礎セクションとシナリオ固有のセクションの推奨事項を基に説明します。
新しい環境
戦略を開発する一環として、ワークロードをサポートする環境をいつ作成するかを検討します。 評価では、セキュリティ強化のために特定の環境をロックダウンするなど、環境によって提供される分離の利点と、アプリ間でデータを共有するときにユーザーが直面する摩擦などの欠点とのバランスを取る必要があります。
アプリまたは自動化が独自の環境に属するかどうかを評価するときは、アプリのライフサイクルのさまざまな段階を個別に評価します。 開発中は、他のアプリからの分離が重要です。 複数のアプリを単一の環境で開発すると、アプリ間の依存関係が生じるリスクがあります。
一般的な推奨事項としては、可能であれば、開発環境は単一目的で、使い捨てで、簡単に再作成できるものにする必要があります。
複数のアプリを本番環境で一緒に実行する場合は、同じ環境で複数のアプリをテストするのが理にかなっています。 実際、運用環境で実行されるアプリでテストしないと、互換性の問題を発見できないリスクがあります。
アプリの運用環境を評価するときは、次の点に留意してください。
アプリは環境内の既存のアプリと互換性がありますか? たとえば、Dataverse Contact テーブルを異なる目的で使用する 2 つのアプリは互換性がない可能性があります。 アプリはデータ ポリシーの観点から互換性がありますか?
データの分離に関して特別なコンプライアンスまたは規制要件はありますか? たとえば、データの機密度を分離する必要がありますか? データを他のデータと一緒に含めることができないという要件はありますか?
データは機密性や機密性が高いものですか? 情報の流出により、組織に金銭的損害や評判上の損害が発生するでしょうか? 別の環境に分離することで、セキュリティをより細かく制御できるようになります。
アプリは他のアプリからのデータを必要とし、それらと一緒に配置する必要がありますか? たとえば、両方とも 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 は、ユーザーが Power Apps、Microsoft Copilot Studio、Power Automate を使用することで Microsoft Teams でカスタム アプリ、ボット、フローを構築できるようになります。 チームの所有者がこの機能をチームに追加すると、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 は開発タイプ、組織の所有権、およびリスク レベルに基づいてシナリオをグループ化することを計画しています。 会社全体で非常に多くのものが構築されているため、考えられるすべてのシナリオに焦点を当て、ユース ケースごとにカスタマイズすることは困難です。 イノベーションと変化の規模を考えると、自動化と、できるだけ多くのすぐに使用できる制御が必要です。
マイクロソフトは Power Platform 環境を 3 つの大カテゴリーに分類し、リスクとコントロールの度合いを反映した 7 つの使用用途 (個人の生産性、チームコラボレーション、企業開発) をカバーしています。
個人の生産性: 他のユーザーとラボレーションすることなく、自分のためだけにアプリやフローを構築したいユーザー向けです。 これらのユーザーは、個人の開発環境にルーティングされます。 これらのロックダウンされた環境では、共有の制限や他のアクションの制御など、マネージド 環境機能が使用されます。 これらの環境でのコネクタとアクションは厳しく制限されています。 これらの環境はリスクが最も低くなります。 ロックダウンされた個人用環境を使用すると、ユーザーは、個人の生産性向上アプリとフローを構築するために必要な、より厳格なコンプライアンス プロセスを回避できます。
チーム コラボレーション: チームのツール、自動化、およびプロセスを構築しているユーザー向けです。 このシナリオでは、Microsoft は Dataverse for Teams 環境の使用を推奨しています。 ライフサイクル、アクセス管理、データ ラベリングは Microsoft 365 グループ レベルで管理されるため、Power Platform ガバナンスの観点からこれらのユーザーの管理に時間を費やす必要はありません。 このレベルの使用は、リスク スペクトルの次のステップです。
全従業員で使用されるエンタープライズ開発/運用レベル: 会社全体でより広く使用されるツールまたはソリューションを構築するユーザー向けです。 これらの環境では、最も機密性の高いデータが保存され、より強力なコネクタが使用され、より多くのガバナンスが必要になる可能性があります。 このレベルは最も高いリスクを伴うため、ガバナンスに多大な労力が費やされます。 ALM が必要であり、実稼働前の作業はサンドボックス環境で行われ、運用環境では マネージド ソリューションのみが許可されます。 これらの環境は、セキュリティとプライバシーの定期的なレビューを実施する ServiceTree にリンクする必要があります。 環境グループ ルールは、ServiceTree メタデータとシグナルに基づいてカスタマイズされます。 これらの環境を管理および制御するために、多くの環境グループとルールが使用されます。
Microsoft のガバナンス戦略は静的なものではありません。 流動的であり、新たな課題に適応し、新しい Power Platform 機能を組み込むために変化します。
テナント環境戦略を革新する
この記事では、エンタープライズ規模のテナント環境戦略を確立する方法について説明しました。 戦略は、ジャーニーのどこから始めているかに関係なく、ビジネスとともに成長します。 私たちが提示する戦略は、あらゆる規模の組織にメリットをもたらしますが、すでに規模が大きい組織にとっては、より大きなメリットをもたらします。
テナント環境戦略の策定は、一度限りの活動ではありません。 これは体験です。 ニーズの変化に応じて、時間の経過とともに戦略を進化させます。 プラットフォームの新しい機能を採用し、新しい課題に対処するために、戦略も調整する必要があります。
すべての旅と同じように、さまざまな組織がさまざまな地点で合流しますが、目的地はすべて同じです。 以下は、組織の現在の状況を表す、考えられるオンランプです。
先頭
あなたの組織は Power Platform 導入への道のりの始まりにいます。 このステージはしばしば greenfield と呼ばれます。 既存の環境や、新しいポリシーが組織内のユーザーの Power Platform 使用方法に与える影響について心配する必要がないため、最適な場所から始めることができます。 これは、製品の機能とベスト プラクティスに沿ったエンタープライズ規模の環境戦略を実装するのに最適な時期です。
この記事で概説されている主要な環境機能と戦略を調べてください。 時間をかけて、要件に最適なテナント環境戦略を設計および実装するために必要な主要なテーマと考慮事項および決定事項を理解してください。
明確な戦略を持たずに始めると、後から制御不能な状況に陥る可能性が出てきますが、それを避けるためには、今しっかりとした基盤を確立することが不可欠です。 Power Platformの使用を急速に加速する計画を立てますが、必要のない複雑さを追加して環境戦略を過剰に設計しないようにしてください。 これは体験であり、ニーズの変化に応じて戦略を進化させ続けることができることを忘れないでください。
Align
組織には環境戦略があり、それを実行していますが、新しい Power Platform 機能やベスト プラクティスに合わせて変更する必要があります。 このステージはしばしば brownfield と呼ばれます。 立ち上げたばかりの組織とは異なり、環境戦略の変更が組織に与える影響を考慮する必要があります。
この記事で概説されている主要な環境機能と戦略を検討し、戦略をより一貫したものに進化させるために何が必要かを評価します。 通常、必要なのは段階的な調整だけです。 可能であれば、ユーザーへの影響を最小限に抑えるように変更の展開を計画してください。
以下の提案は、実装可能な一般的な増分変化です。
既存の環境に影響を与えずに調整を開始するには、新しい開発者環境を含む環境グループを作成し、管理するためのルールを確立します。 環境ルーティングをオンにして、すべての新しい開発者環境が指定されたグループ内に作成されるようにします。
グループ化戦略を評価し、必要に応じて既存の環境をサポートするグループを作成します。 既存の制限と例外に一致するグループに関するルールを確立します。 既存の環境をそれらのグループに移動します。
デフォルト環境で構築され、使用されている、広く普及しているアプリケーションを特定します。 パイプラインを使用して、組織内のユーザーが実行できる運用環境にパイプラインを公開します。 次に、それらのアプリの開発を個別の開発者環境または専用の開発環境に移行します。
デフォルト環境で使用されていない資産を識別、隔離、削除するための計画を作成します。
拡張
実行している環境戦略は、すでに最新の機能とベスト プラクティスに準拠していますが、組織ではさらに多くのコントロールや機能を追加したいと考えています。
環境戦略を組織とコミュニケーションさせる
Power Platform ユーザーが達成しようとしていることを理解し、それに同調すれば、テナント環境戦略をより効果的に実装できます。 コミュニケーションなしに戦略をただ実行するだけでは、ユーザーは変更を制限と見なし、回避策を探します。
戦略の開発または進化の一環として、ユーザーの Power Platform 使用に影響する戦略の主要要素をユーザーに通知する方法を決定します。 戦略の技術的な詳細をすべて必要とするわけではなく、生産性を維持するための基本的な情報のみが必要でとなります。 たとえば、次のようなことを伝えます。
- 既定環境の目的
- 新しいローコード資産を構築すべき場所
- 個人開発者環境をどのように活用すべきか
- 特定の部署またはプロジェクトのためにカスタム環境を要求する方法
- 一般的なコネクタの使用ポリシーと、環境に対してコネクタ権限をさらに要求する方法
- 作ったものを他の人と共有する方法
- 作成者の責任例:
- テナントをクリーンな状態に維持します。 環境、アプリ、フローは不要になった場合に削除します。 実験する場合は、テスト環境を使用してください。
- 賢く共有します。 環境、アプリ、フロー、共有接続の過剰共有に注意してください。
- 組織のデータを保護します。 極秘データ ソースまたは機密データ ソースから、保護されていないストレージまたは外部ストレージへのデータの移動を回避します。
- 戦略を変更したら、変更がユーザーにどのような影響を与えるかを共有して、ユーザーが何を変更すればよいかを知るようにします
良いスタートとしては、新しいメーカーが追加される環境グループで メーカーのウェルカム コンテンツをオンにする ことです。
図: ウェルカム コンテンツを使用して、新しい作成者が成功できるように支援します。
ユーザーとコミュニケーションをとるもう 1 つの効果的な方法は、内部 Power Platform ハブを確立することです。 このハブは、プロジェクトで人々が協力し、アイデアを共有し、テクノロジーを適用してより多くのことを達成するための新しい方法を発見する場所です。 ハブでは、ユーザーに関連する環境戦略に関する詳細情報を共有することもできます。 詳細については、内部 Power Platform ハブを作成する方法を参照してください。
結論
この記事では、組織がエンタープライズ規模で Power Platform 環境を管理し、それをテナント環境戦略に組み込むのに役立つように設計された機能について説明しました。
組織が Power Platform を採用し、使用が加速するにつれて、環境に対するニーズは急速に変化する可能性があります。 環境戦略が変化に対応し、組織の進化するガバナンス要件を継続的に満たすのに役立つ、俊敏なアプローチが必要です。
テナント環境戦略を成功させるための重要な要素は、作成者やユーザーとコミュニケーションを取り、彼らのサポートを得ることです。 ローコード アプリケーションと自動化を構築する担当者が、組織の環境戦略に従う方法と、ローコード アセットを構築する場所を把握していることを確認します。
各組織の Power Platform 採用への道のりはユニークです。 作業を開始するのに役立つアイデアをいくつか紹介しました。 Microsoft アカウント チームまたは Power Platform パートナーは、組織に合わせてよりカスタマイズされたテナント環境戦略の作成をお手伝いします。