次の方法で共有


Microsoft Fabric でのドメインの計画と作成に関するベスト プラクティス

Fabric のドメインは、組織のニーズと目標に従ってビジネス データを整理し、利用を促進するのに役立ちます。

また、各ドメインに適切な制御を設定できるドメイン管理者にテナント設定を委ねられるようにすることで、分散ガバナンスを促進します。

計画

ドメインを実装する場合は、次の点について考慮する必要があります。

まず、ドメイン設計フェーズで次の役割の担当者を関与させることを検討します。

  • センター オブ エクセレンス、ビジネス アーキテクト、テクニカル アーキテクト。

  • センター オブ エクセレンス、ビジネス リード、テクニカル リード、および所有者。

  • セキュリティ責任者とコンプライアンス責任者。

次の質問に対する答えを明確にし、整理します。

  • データに対して誰が責任を持ちますか?

  • 組織のデータに最適なのはどのような構造ですか?

  • 階層にレベルを追加する必要はありますか? (この考慮事項は、各ドメイン内にサブドメインを作成すべきかどうか、またその方法を決定するのに役立ちます)。

業界における一般的な組織構造

次のセクションでは、業界で最も一般的な組織構造について説明します。

  • 機能別構造

    機能別構造では、財務、人事、営業などの役割や業務機能に基づいて部門に分けられます。 この構造には、明確な階層、一元化されたリーダーシップ、明確に定義された責任と権限があります。

    機能別構造により、専門ごとの分業化、スケーラビリティ、責任の明確化が可能になります。 また、明確な期待値を設定し、直接的な指揮系統が確立されます。

    機能ベースの組織構造の例を示す図。

  • 製品/プロジェクト構造

    製品/プロジェクト ベースの構造は、複数の製品ラインを持つ企業や、異なるチームとリソースを必要とするプロジェクトに適しています。

    製品/プロジェクト構造により、会社は各製品またはプロジェクトに専用チームを割り当て、イノベーションとコラボレーションを促進できます。

    製品/プロジェクト ベースの構造の欠点は、機能の重複、リソースの競争、チーム間の調整の欠如を生み出す可能性があるということです。

    製品/プロジェクト ベースの組織構造の例を示す図。

  • プロセス ベースの構造

    プロセス ベースの構造は、さまざまな製品や市場にまたがる標準化されたプロセスや反復的なプロセスを持つ企業に適しています。 プロセス ベースの構造により、会社は各プロセスの効率、品質、一貫性を最適化し、プロセス チームの専門知識とスキルを活用できます。 ただし、プロセス ベースの構造では、縦割り構造やチーム間でのコミュニケーション不足、さらには顧客志向の低下を招く可能性もあります。

    プロセス ベースの組織構造を示す図。

  • 地域ベースの構造

    地域ベースの構造は、異なる地域または国で事業を行っており、地域の環境、文化、規制に適応する必要がある企業に適しています。 地域ベースの構造では、地域のマネージャーに意思決定の権限を委ねることで、その地域の顧客のニーズや好みに合わせて製品とサービスを調整することができます。

    地理ベースの組織構造を示す図。

  • 混合構造

    混合構造は、機能、製品、市場などの 2 つ以上の組織構造を組み合わせたものです。 混合構造は、各構造の長所と短所のバランスを取りながら、効率と柔軟性を高めることができます。 たとえば、ある企業には、財務、人事、研究開発のグローバルな機能部門を持ちながら、特定の部署やセグメントに対応する製品部門や市場部門を設置する場合があります。

サブドメイン構造

サブドメインは、親ドメインと同じロジックに従うことも、組織のニーズに基づいて独自の構造を持たせることもできます。 たとえば、組織のドメインを機能ベースの構造に従って構築し、サブドメインを地域ベースの構造で構築するといったこともできます。

ワークスペースの割り当て

ドメインとサブドメインの構造を作成した後、次の手順では、各ドメインまたはサブドメインにワークスペースを割り当てます。 ドメインとサブドメインの作成に使用される名前付け規則や条件に応じて、さまざまな方法でドメインにワークスペースを割り当てることができます。 考えられる方法は次のとおりです。

  • ワークスペース名ごと: この方法は、ワークスペースに対して一貫性のある明確な名前付けパターンを設け、それに従う組織に適しています。ワークスペースの名前には、関係するドメインやサブドメインを反映させるか、それらに関連付けることができます。 たとえば、ドメインが Finance で、サブドメインが Accounting の場合、Finance-Accounting-Report という名前のワークスペースを Accounting サブドメインに割り当てることができます。

  • ワークスペース所有者ごと: この方法は、ワークスペースに対して明確で安定した所有権構造を持ち、ドメインまたはサブドメインに対応する所有者を設けている組織に適しています。 たとえば、ドメインが Product で、サブドメインが Fabric の場合、Product Manager-Fabric が所有するワークスペースは、その Fabric サブドメインに割り当てられます。

  • 容量ごと: この方法は、容量を含むデータ メッシュ アーキテクチャを採用し、ドメインまたはサブドメインに合わせて容量を確保している組織に適しています。 たとえば、ドメインが Marketing で、サブドメインが Analytics の場合、容量 Marketing-Analytics に割り当てられたワークスペースは、その Analytics サブドメインに割り当てられます。