SharePoint のレコード管理の概要

  • Article

SharePoint のレコード管理の概要

こんにちは。私は SharePoint のドキュメント/レコード管理の構想と機能を担当しているエンジニアリング チームの一員です。SharePoint 2007 recman ブログ (英語) の執筆者として私のことを覚えていらっしゃる方も多いでしょう。recman ブログは、私たちのチームと、レコード管理者、IT プロフェッショナル、およびインフォメーション アーキテクトとのすばらしい接点になりました。これからもエンタープライズ コンテンツ管理 (ECM) チームのブログを通じて SharePoint 2010 の準拠機能に関する話を続けていく予定です。

レコード管理を ECM の他の側面と結び付けて 1 つの中心的なブログで論じることは理に適っていると思います。Jim が書いているように (英語)、レコード管理は私たちの
ECM 戦略の重要なコンポーネントです。だれもが ECM プロセスに参加すべきであるという考え方は、SharePoint 2010 のレコード管理が対象とする範囲を拡大するうえで指針になりました。ブログを読む過程で、ECM の他の側面を学べることは、レコード管理者のみなさんにとっても大きな利点となるでしょう。

まずはじめに、SharePoint 2010 のレコード管理について知っておく必要のある重要なことが 3 つあります。

レコード センター - メタデータに基づく階層構造

レコード センターは、従来のレコード アーカイブの役割を果たす SharePoint サイトとして SharePoint 2007 で導入されました。企業全体にわたって存在するコンテンツをレコード センターに送信し、それを適切な場所に転送できます。転送先では、期限や監査など、適切な権限やポリシーがコンテンツに割り当てられます。
私たちは、SharePoint 2010 でも、引き続きこの機能の充実を図り、「従来型」のアーカイブ機能を追加することも重要だと考えました。幅広い機能の選択肢を目の前にして、私たちは、アーカイブから最大限の価値を引き出し、必要とするデータを検索する機能に的を絞りました。たとえば、以下に示す SharePoint 2010 レコード センターの新機能がそれです。

  • ドキュメント ID: すべてのドキュメントに一意の ID を割り当てることができます。ドキュメントがアーカイブされてもドキュメントの ID は変わりません。そのため、ドキュメントがどこに移動しても、ID でレコードを簡単に参照できます。
  • 複数ステージ保持: 保持ポリシーに複数のステージを持たせて、ドキュメントのライフサイクル全体を 1 つのポリシーとして指定できます (たとえば、1 年ごとに契約を再検討し、7 年後に削除するなど)。
  • アイテムごとの監査レポート: 個別のレコードに関するカスタマイズされた監査レポートを生成できます。
  • 階層型ファイル計画: 深い階層型フォルダー構造を作成し、階層上の各フォルダーで保持を管理する (または親フォルダーから継承する) ことができます。
  • ファイル計画レポート: ファイル計画の各ステージにあるアイテムの数と計画内の各ノード上の保持ポリシーのロールアップを示す進捗レポートを生成できます。

 図 1 - レコード センター

これは架空の政府機関 Joint Task Foruce が運用している SharePoint 2010 のレコード センターのホーム ページです。ホーム ページは、レコード管理者が組織の人々に準拠ポリシーを伝える場であり、ドキュメント ID に基づいてレコードを検索する場でもあります。

これらの従来のレコード管理機能をアーカイブに追加したことに加えて、私たちは、製品設計者として、21 世紀の電子レコード管理の中心となるメタデータの力に大きな期待を賭けました。その構想は、さまざまな形で SharePoint アーカイブに反映されています。

  • 分類と集中コンテンツ タイプ: アーカイブが全社規模の分類とコンテンツ タイプを利用することで、コラボレーション空間とアーカイブの間の一貫性とコンテキストの移転が保証されます。将来の投稿で、2010 の分類の背後にある設計構想について説明する予定です。
  • コンテンツ オーガナイザー: レコード ルーターはメタデータを使用して、受信したドキュメントを階層型ファイル計画内の適切な場所に転送できます。たとえば、「購入契約に "プロジェクト アルファ" というタグが付いていれば、[アルファ契約] サブフォルダーに転送し、そのフォルダーの保持ポリシーをアイテムに適用する」など、送信されたコンテンツに自動的にルールを適用できます。
  • 仮想フォルダー: ファイル計画はリポジトリを管理する優れた手段ですが、フォルダー間を移動し、目的のコンテンツを探す用途にはあまり向いていません。SharePoint 2010 レコード センターでは、重要なメタデータを仮想フォルダーとして表示できる「メタデータに基づくナビゲーション」と呼ばれる新機能を利用します。

図 2 - メタデータに基づくナビゲーション 

エンド ユーザーは、レコードのメタデータ プロパティに基づいて仮想フォルダーに移動することによって、このレコード センター内のコンテンツを見つける点に注目してください。

私たちがメタデータに期待している役割は、エンド ユーザーに力を持たせて、RM システムがうまく導入される確率を高めることです。送信者は、ファイル計画内の複雑なノードを選択する代わりに、役に立つメタデータをいくつか入力するだけで済み、再びコンテンツを検索する必要が生じたときは、そのメタデータを利用できます。

インプレース レコード管理 - コンテンツ作成にレコード管理機能を持たせる

私のチームが関係しているお客様とのやり取りでよく聞かされるのは、次の言葉です。レコード管理はアーカイブからは始まらない (またはアーカイブでは終わらない)。コンテンツはアーカイブで作られるわけではないし、コンテンツが本領を発揮するのはアーカイブの中に存在するときではない。

2010 の開発にあたっては、コラボレーション空間での効率的なレコード管理を目指して多大な努力を払いました。監査、保持、期限、レポート、レコード ワークフロー、電子情報開示、法的情報保留、およびレコード化は、どれも、エンド ユーザーにとっての SharePoint の価値と情報管理のニーズのバランスを図りながらコラボレーション空間で利用できる機能です。

これらすべてを兼ね備えているのがインプレース レコード管理と呼ばれる SharePoint 2010 の新機能です。この機能を利用すれば、特定の SharePoint ドキュメント (またはブログ、Wiki、Web ページ、リスト アイテム) をレコードと宣言できます。必要に応じて、組織が決定したレコードの定義に従って、そのようなレコードの削除や編集を禁止できます。

 図 3 - インプレース レコード管理

一部のドキュメントに鍵がかかっている点に注目してください。この鍵は、ユーザーに対して、そのドキュメントがレコードであることを知らせる役割を果たしています。ユーザーがレコードを選択すると、アイテムの編集と削除に使われるユーザー インターフェイスは無効になります。

このレコード化処理は、ワークフロー内の大きな処理の一部として手動で実行することも、ドキュメントの保持のスケジュールされた部分 (たとえば 2 年後) として実行することもできます。ここで重要なのは、レコードと宣言されると、コンテンツがアーカイブに移動しないことです。レコードになったコンテンツは現在の場所にとどまり、エンド ユーザーはコンテンツを見つけて、コンテンツに対する作業を行うことができます。

アイテムがレコードと宣言されると、システムはアイテムのレコード状態を認識するので、レコードに対して異なる保持ポリシーを作成したり、SharePoint Designer でワークフローを定義するときにレコード状態を使用したりできます。プログラミング モデルも有効になるので、特殊な準拠のニーズを満たすために、レコード化の時点でカスタム プロセスやカスタム ポリシーを実行できます。

インプレース レコードは従来のアーカイブに取って代わるものでしょうか。当然、「場合による」というのがその答えです。一部のお客様はインプレース方式に全面的に切り替えるでしょう。お客様によっては、アーカイブのもたらす従来の階層と集中管理を望むでしょう。多くのお客様は、両方を使用するでしょう。それについては、このブログでこれから頻繁に話題になるでしょう。このドキュメントで、既に両方の方式の利害得失が論じてられています。

規模: 大規模環境を目指す

電子情報が猛烈な勢いで増大しており、企業が毎年何十億ドルもの資金を電子情報開示に注ぎ込んでいる現在、レコード管理者は多忙な日々を過ごしています。レコード/コンテンツ管理システムの規模の拡張がレコード管理者の新たな悩みの種になることは望ましくありません。

私たちは、レコード管理エンジニアリング チームとして、この負荷を真剣に受け止め、このリリースでは、巨大なアーカイブへの拡張を容易にする機能を追加することに開発の努力を集中させました。リモート Blob ストレージ、データベース クエリの最適化、内部タイマー ジョブ処理の改良、新しいデータベース インデックス作成戦略、その他のエンジニアリング構想によって、このリリースは機能が飛躍的に向上しており、以下の拡張が実現しました。

  • 1 つのレコード センターに何千万ものレコードを保存できる
  • 1 つの分散アーカイブに何億ものレコードを保存できる: 将来の投稿で詳しく説明しますが、これら多くの機能のおかげで、多数のレコード センターを束ねて 1 つの論理リポジトリとして運用できます。

これから数か月にわたって、私たちはパートナーと共に SharePoint ブログ (英語) で、新しい拡張性の目標や大規模な展開でのパフォーマンス プロファイルについて詳しく解説していきます。

まとめ

21 世紀のレコード管理の構想を実現することは、チームにとって膨大な作業でした。それが Exchange 2010 の統合電子メール アーカイブ機能、保持機能、検索機能と結び付くことによって、2010 のリリースは、マイクロソフトのレコード管理戦略に飛躍的な前進をもたらすでしょう。

私たちのチームは、この成果に誇りを持っており、みなさんにそれを伝えて、みなさんからご意見を聞くことを楽しみにしています。コメントを通じて将来のブログ投稿のテーマに関する提案をお寄せください。

ブログをお読みいただき、ありがとうございました。
Adam Harmetz
リード プログラム マネージャー

追伸: SharePoint 2010 のレコード管理の詳細については、私へのインタビューが記載されている Don Lueder のブログ (英語) をお読みください。

これはローカライズされたブログ投稿です。原文の記事は、「Introducing Records Management in SharePoint 2010」をご覧ください。