SharePoint Online ポータルの情報アーキテクチャ ガイダンス

  • [アーティクル]

適切に管理され、パフォーマンスに優れたポータルを実現するには、しっかりとした情報アーキテクチャが重要な前提条件となります。 最適な構造を設計するには詳細な計画が必要です。 適切な計画を行わない場合、ユーザーによる導入に悪影響を与えたり、パフォーマンスに重大な問題が発生したりする可能性が高くなります。 

次の要素を考慮します。

  • ビジネスの目標や組織の構造。
  • 扱うコンテンツの種類。 共同作業用のコンテンツまたは公開するコンテンツですか。
  • コンテンツの分類と機密性。
  • コンテンツのライフサイクルと、適用可能な保存/廃棄の戦略。 これは、サイトにも適用されます。 
  • コンテンツのユーザー、ユーザーの行動、一般的なタスクと要件。

ユーザー、コンテンツ、ポータルの用途について理解を深めることで、出発点となるしっかりとした基盤が築かれ、情報アーキテクチャでよく陥るいくつかの落とし穴を回避できます。

情報アーキテクチャは、1 回限りのプロセスではなく、継続的なプロセスです。 最適な情報アーキテクチャは、エンド ユーザーにとって常にわかりやすいわけではありませんが、設計や管理が不適切な情報アーキテクチャで嫌な経験をすると、そのことを忘れることはありません。 評価を続け、継続して発展させ、情報アーキテクチャを関連性の高い最新の状態に維持する必要があります。


実装 / ガバナンス / 評価 / 改善のプロセスを示す図


注:

このガイダンスは主に SharePoint Online を対象にしていますが、大部分はオンプレミスの SharePoint 環境でホストされているポータルにも適用されます。

この記事では、ガバナンスと情報アーキテクチャのすべての側面を詳細に掘り下げることはしません。 この記事の目的は、ユーザー導入やパフォーマンスに影響を与える一般的な問題に焦点を当てることです。

行うべきではないこと

以下の一覧に、ポータル情報アーキテクチャを設計するときに避けるべき主な事柄を記載します。

以下を行わないでください:

  • トップレベルの親ポータル サイト コレクションを多くしすぎる。 これは混乱を招き、管理、セキュリティ上の考慮事項、ユーザビリティ、ナビゲーション、導入の全般にわたって悪影響を及ぼす可能性があります。
  • 単一のサイト コレクションの階層を深くして、さまざまな固有のアクセス許可を割り当てる。 これは、パフォーマンスの問題の原因となる可能性があります。
  • 1 つのサイト コレクションにサブ サイトが多すぎます。 サイト コレクション内のすべてのサイトは、一緒に、同じ SQL データベースに格納されます。 これにより、サイト コレクションとサイトの構成方法、およびサイトの目的に応じて、サイトとサーバー (オンプレミス) のパフォーマンスに影響する可能性があります。
  • コンテンツを深く埋め込む。 コンテンツが深すぎると、検出可能性と導入に影響が及びます。 ユーザーがいくつかのレベルでコンテンツを検索しても見つからない場合、ユーザーは検索操作を諦め、ポータルが非効率的だと判断して導入を中止するかもしれません。 
  • 古いコンテンツを保持する。 古いコンテンツを好む人はいません。古いコンテンツを何回か見たユーザーはそのポータルに再びアクセスしなくなるでしょう。 
  • コンテンツの廃棄戦略を使用しない。 古いコンテンツをなくし、定義されたキャパシティの範囲内にとどめるには、コンテンツの破棄戦略が欠かせません。 
  • 不十分なエンタープライズ マスター データ管理に依存する。 これにより SharePoint Online 分類設計が不適切になってしまいます。   

以降のセクションでは、情報アーキテクチャを構築する際に考慮すべき主な分野について説明します。

サイトの編成パターン

情報アーキテクチャ内でトップ レベルのサイト コレクション ノードの数と、サブサイト レベルの数を最小限に抑えることを検討してください。

ディスカッションを重ねた結果、横方向/フラットのサイト コレクションと縦方向/階層の比較に変更を加えました。 これまでは、階層をいくつかの別個のサイト コレクションにフラット化することが勧められてきました。その理由としては、IA のベスト プラクティス、メニュー構造、コンテンツ データベース管理、キャパシティなどの要因が挙げられます。 キャパシティに関する限り、もはや SharePoint Online にはこれが該当しなくなりました。 しかし現在では、URL 制限などの別の考慮事項があります。

詳細については、「SharePoint Online の制限事項」を参照してください。

推奨されるパターンとしては、サイト コレクションとサイトをエンタープライズ レベルの発行サイトとして論理グループに分けることが含まれます。 たとえば、検索センター、レコード センター、電子情報開示センターにグループ化できます。 これらのグループをルート レベルまたは "/sites" 管理パスの下にすることができます。 また、イントラネット発行/ポータル サイトも、ルート レベルまたは "/sites" 管理パスの下にすることができます。 次に例を示します。

エンタープライズ レベルのサイトとして認識されるサイトは次のように構造化することができます。

  • /sites/
    • 検索
    • レコード センター
    • 電子情報開示センター
    • メディア
    • コンプライアンス ポリシー センター
    • BI ポータル
    • コンテンツ タイプのハブ

発行ポータル サイトとして認識されるサイトは次のように構造化することができます。

  • /sites/
    • イントラネット ホーム
    • 業務機能 A
    • 業務機能 B
    • ...
    • 部署 A
    • 部署 B
    • ...

通常は、すべてのものが一度にまとめてクラウドに移行されるわけではありません。したがって、ハイブリッド IA の計画を立て、必要に応じて発展させてください。 ハイブリッドのシナリオについて適切に計画を立ててください。

詳細については、「SharePoint ハイブリッド サイトと検索」を参照してください。

アクセス許可

アクセス許可の構造化は困難な作業であり、注意深く計画すべきもう 1 つの分野です。 ユーザー アカウント、SharePoint グループ、Active Directory グループ/Azure AD グループを使用してアクセス許可を設定するのが非常に難しくなる場合があります。 SharePoint Online では、次の 3 つの組み合わせを使用することができます。

  • 直接的なユーザー権限によるアプローチ
  • SharePoint グループによるアプローチ
  • Active Directory セキュリティ グループ (Azure AD セキュリティ グループ)

注:

SharePoint Online の場合は、グループを AD Connect と同期してください。

アクセス許可を計画する際には、以下のガイドラインに従います。

  • まず「最小限の特権」の原則に従い、その後、必要に応じて拡大していきます。
  • 最初は標準の既定のグループ (メンバー、閲覧者、所有者) を使用します。 当然のことですが、所有者グループに割り当てるユーザーの数を制限してください。
  • アクセス許可を付与する際には、アクセス許可の継承を使用し、個人よりもグループを使用します。
  • アクセス許可の継承を利用するようコンテンツを編成するか、可能な場合には固有のアクセス許可ごとにコンテンツを編成し、分類レベルごとにセグメント化します。

本来アクセスできるコンテンツにアクセスできないと、ストレスの原因になるだけでなく、最終的にはエンド ユーザーの導入の妨げになったり、検索結果の問題が発生したりします。

SharePoint Online では検索に固有な構成上の選択肢について設計上の考慮事項が多数あります。 特に高度な構成の場合、詳細な検索仕様を作成する必要があります。 パフォーマンスや関連性を向上させるために検索エクスペリエンスを調整したり、ユーザー向けにカスタマイズしたりできます。

これには以下が含まれます。

  • 検索可能な管理プロパティを定義する
  • 関連性を調整するために高品質のページを識別する 
  • クエリ ルールおよび検索先を管理する

コンテンツ集約は、ポータルとそのページのパフォーマンスに大きな影響を及ぼすことがあります。 コンテンツ集約の詳細については、「SharePoint Online ポータルのコンテンツ集約に関するガイダンス」を参照してください。

分類

分類では、サイトのナビゲーションとデータの両方を説明します。 ガバナンスの観点に加え、パフォーマンスの観点からも慎重に計画する必要があります。 これから開始するコア ビジネスの仕組みだけでなく、将来の成長や管理の容易性についても考慮してください。

コンテンツ タイプ

SharePoint で情報を整理、管理、分類、検出するためには、コンテンツ タイプおよび関連するメタデータの計画、構成、実装を適切に行う必要があります。

グローバル コンテンツ タイプからなる小さなセットを定義します。法律チームやレコード管理チームの要件、さらにタグ付けの作成要件などに基づいてこれを定義できます。

これらのコンテンツ タイプには、少なくとも次のようなフィールドが含まれている必要があります。

  • InformationClassification
  • BusinessFunction
  • CorporateFunction
  • ...

コンテンツ タイプ ハブでこれらを作成し、SharePoint CSOM で固有の ID を使用してコンテンツ タイプを作成します。 これらのコンテンツ タイプを引き続き手動で発行する必要があります。 サイト コレクションでコンテンツ タイプを変更する必要があると考えられる場合は、コンテンツ タイプ ハブを使用しないでください。

詳細については、「コンテンツ タイプとコンテンツ タイプ発行の概要」を参照してください。

管理されたメタデータ

これは大きなトピックであり、この記事では取り上げません。 円滑にスタートを切るための情報と詳細については、「管理されたメタデータの概要」を参照してください。

SharePoint のメタデータを使用することにより、管理された正式な分類の利点と、さまざまな情報の使用と管理シナリオにマッピングするカスタマイズされた方法でのソーシャル タグの動的なメリットを組み合わせることができます。

エンタープライズ メタデータの階層は、情報セキュリティの分類に基づいて指定することができます。 また、サイト列とコンテンツ タイプを使用して、管理されたメタデータをドキュメントやリスト アイテムにマッピングすることもできます。 管理者と共同作成者はこれらの管理されたメタデータ用語セットを管理することができ、用語セットに用語を追加する機能を制御することもできます。

エンタープライズの用語ストアの階層は通常、組織内の他のチームからの入力プロセスを通じて、ガバナンス運営委員会によって管理されます。

重要

計画や管理が適切でない場合、大規模な分類階層および詳細な並べ替えに関する問題が発生する可能性があります。 クライアント側でデータを並べ替える必要があるため、階層の潜在的な深さや、返される用語の数を慎重に検討することをお勧めします。 階層の深さや用語の数によっては、クライアント側のドキュメント オブジェクト モデル (DOM) 並べ替えに数秒かかる場合があります。

用語ストアのアイテムを削除したり、廃棄したりしないでください。 返されるデータの遅延の原因となるため、用語ストアにオブジェクトの欠落や誤ったアクセス許可の割り当てといった問題がないようにしてください。

用語はセキュリティ トリミングされないため、秘密度を考慮する必要があります

管理されたメタデータを計画する場合、次のワークシートを利用できます。

ナビゲーションのベスト プラクティスの詳細については、「SharePoint Online ポータル用のナビゲーション ソリューション」を参照してください。

大容量メディア

ビデオ、画像、PowerPoint ファイルなどの大容量ファイルの場合、これらを簡単に取得できると期待しているユーザーにとってストレスの原因となる可能性があります。 ビデオなどのファイルは特定の速度でストリーム配信される必要があります。また、一部のアプリでは、必要なファイルの取得が完了するまでレンダリングが行われない場合があります。 大容量メディア ファイルを外部化することを検討してください。 これにより、ユーザー導入が促されます。 

以下のオプションがあります。

CDN については、次を参照してください。

関連項目