環境と分散を計画する

  • 12 分

環境の設計は、組織の設計に大きく依存します。 導入に関する考慮事項には、規模、場所、規制環境、選好度などがあります。 環境の設計は組織に依存しますが、次のレコメンデーションは、組織に適したランドスケープを設計する際に役立ちます。

注

「Power Automate のセキュリティとガバナンスの概要」モジュールで、既定の環境について説明しました。 テナント内のすべてのユーザーには、この環境へのアクセス権が自動的に付与されることを思い出してください。 この環境へのアクセス権を取り消す方法は存在しないので、この環境が一般に使用されていることを示すために、この環境の名前を個人の生産性に変更するのが一般的です。 また、管理者は、データのプライバシーの観点から問題が発生しないように、この環境の場所についても知っておく必要があります。

もう 1 つの重要な考慮事項は、集中管理の側面です。 たとえば、組織に集中管理された IT 部門があるかどうかを考慮してください。 また、組織が Microsoft Power Platform 環境の管理とガバナンスに対する責任を負っているかどうかも確認する必要もあります。 また、テクノロジーの一部の側面が IT 部門の外部で管理され、管理が分散化されている組織もあります。 環境の設計を確立する際には、考慮する必要がある追加の重要なパラメーターがあります。

構成の例

以下のセクションでは、組織の設計と目標に基づいて使用できる構成例の概要を説明します。

単一リージョンの組織 (集中型)

単一リージョンの組織 (集中型) では、環境は集中管理され、個人の生産性、開発、テスト、運用のための分離が含まれます。 個人の生産性環境は、メール通知、チームベースの承認、即席のデータ収集、Office 365 サービスとの統合などのシナリオをサポートするために使用できます。 環境を管理する中央チームは、既定以外の環境へのアクセス権も提供します。

この組織は単一リージョンで運営されているため、データ所在地に関する懸念事項は存在せず、他のリージョンからの分離を必要としません。

集中型の単一リージョンの組織のスクリーンショット。

単一リージョンの組織 (分散型)

単一リージョンの組織 (分散型) では、環境が独立して管理され、管理者の責任が個々の事業単位に割り当てられています。 この組織は単一リージョン内で運営されており、既定の環境の名前は個人の生産性に変更されています。 人事、財務、運用、IT などの各事業単位に対して、追加の環境が作成されています。

分散型の単一リージョンの組織のスクリーンショット。

複数リージョンの組織 (集中型)

複数リージョンの組織 (集中型) では、環境を中央で管理することができます。 これらの環境は、個人の生産性、開発、テスト、運用など、さまざまな目的で使用されます。 個人の生産性環境は、メール通知、チームの承認、迅速なデータ収集、Office 365 サービスとのリンクなどを行うのに便利です。 これらの環境を監督する中央チームは、既定以外の環境に対するアクセス権も付与します。

組織はグローバルに事業を展開しているので、事業を展開している特定のリージョンに環境を作成します。 このニーズを満たすために、組織が設立されたリージョンに既定の環境を設定しました。 この既定の環境には "個人の生産性 (既定)" という名前が付いています。また、このホーム リージョン (北米) には開発、テスト、運用の環境があります。 一貫性を維持するために、アジアとヨーロッパの各リージョンに同じ環境をレプリケートしました。

既定の環境では、ライセンスされているすべてのユーザーがアプリ開発者と見なされ、この環境から削除することはできません。 ただし、データが自分のホーム リージョンから流出することを心配せずにアプリやフローをすばやく作成できる場所をユーザーに与えるために、アジアとヨーロッパにも個人の生産性環境を作成しました。

各リージョンのチームは、IT 変更管理プラクティスを使用して、重要なアプリやフローが環境内を移動する際に必要なルールに準拠させることができます。 重要なのは、ベスト プラクティスに従いながら、複数のリージョンにわたってシームレスに業務を行えることです。

集中型の複数リージョンの組織のスクリーンショット。

複数リージョンの組織 (分散型)

複数リージョンの組織 (分散型) では、各リージョンで専用の環境が独立して管理されます。 管理の責任は個々の事業単位が負います。

具体的な方法は次のとおりです。メイン リージョン (北米) で、既定の環境の名前を "個人の生産性" に変更しました。この環境は本社と同じリージョンにあります。 このリージョン内に、人事、財務、運用、IT などのさまざまな事業単位向けに追加の環境を作成しました。 こうすることで、各事業単位が独自の方法で業務を運営できます。

既定の環境ではすべてのユーザーがアプリ開発者となり、この設定を取り消すことはできません。 しかし、対処方法はあります。 アジアとヨーロッパにも個人の生産性環境を作成したため、 自宅から離れた場所にいる場合でも、データが行方不明になることを心配せずにアプリやフローを構築することができます。

それだけではありません。 アジアとヨーロッパの事業単位向けにも環境を作成しようとしています。 各事業単位が独自のアプリやフローを独立して構築でき、中央チームを待つ必要はありません。 重要なのは、仕事をする上で必要な自由をすべてのユーザーに与えることです。

分散型の複数リージョンの組織のスクリーンショット。

例外を管理する

前述の例では、組織が生産性とガバナンスのバランスを取るために利用できるさまざまな設定を示しました。 ただし、どの組織も固有であるため、例外をサポートしなければならない状況も出てきます。

たとえば、アプリやフローで SharePoint コネクタと Twitter コネクタが一緒に使用されることを防ぐルールがあるとします。 通常、SharePoint から Twitter へのデータ共有は必要なタスクではないため、ほとんどの役割にとってこのルールは妥当です。 しかし、コーポレート コミュニケーションのようなグループでは、合理的なユース ケースである可能性もあります。

そこで、Twitter を使用する必要がある場合に、Twitter を使用できるユーザーを制限するには、既定のルールにガバナンス ツールを追加します。 Twitter コネクタを SharePoint と同じグループに入れた上で、Twitter コネクタの使用を制御することができます。

その仕組みは次のとおりです。ユーザーがこのコネクタの組み合わせを使用してフローを作成または編集すると、システムでフラグが設定されます。 その場合は、管理者が介入して、ガバナンスを適用することができます。 特定のグループに対する Twitter コネクタのアクセスを制限する方法や、承認ステップをフローに追加する方法があります。 フローを拒否する場合は、フロー管理コネクタの一部であるフローを管理者として無効にするアクションを使用して、フローが実行されないようにすることもできます。 また、フローの作成者にメールを送信して、フローが停止された理由を知らせることができます。 重要なのは、必要に応じて柔軟性を持たせながら、コントロールを維持することです。 類似するガバナンスのシナリオの詳細説明については、Microsoft Power Automate によるガバナンスの自動化に関するブログ記事を参照してください。