サービス導入フレームワークでのガバナンスと意思決定

  • 10 分

コンテナーとコンテンツのガバナンスの柱

Microsoft 365 におけるコンテンツとコンテナーのガバナンスには、Microsoft Teams、SharePoint、およびメンバーシップ管理を Microsoft 365 グループに依存するその他のサービスのエクスペリエンスに直接影響する 4 つの戦略的な柱があります。 これらは次を実現するために必要なものです。

  • 根本的に従業員にパワーを与える
  • 価値のあるコンテンツを特定する
  • 企業の資産を保護する
  • アカウンタビリティを確保する

これらの戦略的な柱は、セキュリティに対するニーズとのバランスを取りながらユーザー エクスペリエンスを優先するガバナンス上の意思決定を行うことで達成できます。

次の決定を行います (この時点で、これらの決定はフェーズ 2 にのみ適用されます)。

決定 1: チームを作成できるユーザー フェーズ 2 では、チームを作成できるユーザーを早期導入者であるユーザーとコア プロジェクト チームに制限できます。 これにより、早期導入者が必要に応じて追加のチームを作成することができます。 この動作を監視することにより、幅広い展開に関する重要な情報を得ることができます。

決定 2: Teams の名前付け規則 Teams の幅広い展開のために、名前付け規則を実装し、重複する名前がないか確認したいかもしれません。 フェーズ 2 では、最初のプロジェクトに対して手動の名前付け規則を使用することをお勧めします。 ベスト プラクティスは、早期導入者のプロジェクト チームとの対話型オンボードを実施し、彼らが自分の名前を選択できるようにすることです。 これにより、従業員が自分の作業をどのように考えているかについての洞察を得られます。 この洞察は、後で大規模な名前付け規則を作成する場合に不可欠です。 この機能は、適切な P1 Microsoft Entra ID P1 または P2 ライセンスを持っている場合にのみ使用できます。 詳細については、「本拠地で Microsoft Teams をロールアウトするための鍵: 優れたガバナンス」を参照してください。

決定 3: ゲスト アクセス プロジェクトの範囲と種類、および業界の性質によっては、パートナーやベンダーとの保護された共同作業の有効化は、テストしたい重要な機能となる場合があります。 適切なテナントの制御を使用して、ゲストを Teams の実装に追加できるユーザーを制限できます。

決定 4: 承認済みアプリ Teams の最良のユース ケースとして、他のアプリをエクスペリエンスに統合することが挙げられます。 少なくとも、技術チームは、Teams のエクスペリエンスにおいて最初のパーティとおすすめのアプリを有効にする必要があります。 使用例や組織で使用されている他のアプリによっては、制御された実験の一環として、追加のアプリを含めることができます。 技術準備ワークストリームで IT パートナーと共同で作業して、Microsoft Teams や Planner などの "相乗効果" シナリオを提供したり、PowerPoint や Word などの Office ProPlus アプリで共同編集したりできるようにします。

決定 5: 会議はテストに含まれているか? Teams 会議のエクスペリエンスは、ビデオ通話をサポートし、従業員の共同作業の効率を向上させます。 環境に簡単な VoIP 会議を含める準備ができているかどうかを、技術チームに問い合わせください。 通常、電話会議や音声サービスの有効化は、実験のこのフェーズから除外します。ただし、これは、組織のコア プロジェクト チーム、技術の準備状況、および組織内の他の音声/会議サービスの状態によります。 Teams の実装からより多くの価値を得るために、ビデオ通話や VoIP 会議を実験に含めることをお勧めします。

決定 6: データ セキュリティ 幅広い展開の準備として、セキュリティ ラベルを使用して、環境内のチームの種類を分類することができます。 この実験では、「Teams でのガバナンスを計画する」のガイダンスに従って、組織内の Teams データに基本的なアイテム保持ポリシーが設定されていることを確認することをお勧めします。 この作業を完了するには管理者の権限が必要なため、技術チームとの調整が必要になる場合があります。

決定 7: 実験の長さ Teams の実装に成功すると、適切な勢い、フォーカス、学習を確保しながら正常なペースで進みます。 早期導入者が十分なビジネス サイクルを実現できるように、プロジェクトの実験フェーズを 60 日間にすることをお勧めします。 実験の期間を長くしすぎると、変更プログラムが失敗するリスクが高まります。 適切な期間は組織ごとに異なります。