ITmedia エンタープライズ

特集
2004/04/05 10:00 更新

第八回
SharePoint Portal Server導入の実際 (1/2)

EIPの基盤としてMicrosoft Office SharePoint Portal Server 2003（SPS）を選択することで、インフォメーション ワーカーに与えられるメリットは計り知れない。では、企業インフラを支える情報システム部門にとって歓迎すべき点とはどこか。

　企業内にSPSを導入することによって、それまで一方通行だったり、途切れ途切れだった情報が循環し始める。強力な検索機能やニュースなどの情報配信機能によって、ユーザーは自分が入手した情報だけでなく、同じ企業内の他のユーザーによって取り込まれた情報までも、手間や時間をかけずに利用できるようになる。さらに、シングルサインオンによるアプリケーション統合が可能になったことで、SPSのポータルサイトがまさしく企業内システムの入り口（＝ポータル）となる。

　これまでの連載中に述べたSPSの機能は、作業の生産性や業務効率を上げるという観点から見れば、ユーザーにとっては非常に魅力的だろう。しかし、ユーザーにとっての利便性は、すなわちそのシステムを構築する側である情報システム部門の人間にとって、導入時や運用中に負担をかけるものである可能性はないだろうか。それぞれの機能がいくら優れていようと、設計に長い期間を要したり、自由な拡張ができなかったり、管理が煩雑なシステムでは全社的なTCOの削減にはつながりにくい。

　SPSが優れていると考えられる点の一つに、導入のしやすさがある。

　まず、SPSのシステム要件を見てみよう。

必要なシステム環境

■サーバ側

日本語版オペレーティングシステム	Microsoft Windows Server 2003　Standard Edition/Enterprise Edition/Datacenter Edition/Web Editionおよび最新の Service Pack
オペレーティング システム コンポーネント	Internet Information Services (IIS) 6.0 ASP.NET、SMTPサービス
ドメイン	Windows NT4 ドメイン、Windows 2000 Server Active Directory、Windows Server 2003 Active Directory
データベース	SQL Server 2000 Standard Edition、SQL Server 2000 Enterprise Edition、SQL Server 2000 Desktop Engine (MSDE 2000)　および最新の Service Pack

■クライアント側

ブラウザ	Microsoft Internet Explorer 5.01 、Microsoft Internet Explorer 5.5 、Microsoft Internet Explorer 6.0 (最新のアップデートが適用された状態であること) Netscape Navigator 6.02以降

　SPSが動作するWebサーバには、Windows Server 2003に標準搭載されるIIS（Internet Information Service）6.0が必要となる。また、データストレージとしてSharePoint Portal Server 2001で使われていたWeb Strage Systemに代わって、SQL Server 2000が採用されている。SPSをホストするサーバとデータベースエンジンを搭載するサーバを分散せず、1台環境で構築する場合は、SQL Server 2000 Desktop Engineを選択することもできる。これはSPSをインストールする際に、同時にインストールすることが可能だ。

　さて、社内にSPSを導入することが決まったとすると、次に検討するべきは「どう」導入するかだ。

　SPSに限らず、一般的なEIPの導入プロセスは現状調査に始まり、設計、開発、配置を終えて晴れて運用となる。このうち開発フェーズにおいては、SPSが特別な開発を行わなくともインストール後すぐに使えるサイトを提供すること、また運用はサイト単位でユーザーが自由に管理・運営を行えることは、以前の第五回 なぜSharePoint Portal Server 2003を導入するのか（前編）で紹介した。今回はSPSでポータルサイトを設計する手法について考察する。

サイト構成設計のプロセス

　SPSポータルサイトおよびサブサイトであるチームサイト構成を設計するプロセスにおいて、SPSは2通りのアプローチを提供する。

　一つは、情報システム部門が先頭となって初めから全社的に導入することを計画し、綿密な設計の後、一斉に導入する方法だ。まず、大規模なサーバを用意し、トップレベルのSPSサイトを構築する。その後、部署やプロジェクト単位にWSSサイトを作成し、各部門に提供する。いわゆるトップダウン式のアプローチである。

　各部門は、提供されたWSSサイトを自ら管理・運営し、業務に合わせて随時カスタマイズを行い運用してゆく。一見、それぞれの部門が好き勝手に管理することで、社内にWSSサイトが乱立し、混乱を招くような構成に思えるかもしれない。しかし、その懸念には「ノー」と答えよう。

　SPSには、「サイトディレクトリ」という機能が用意されている。ここから、各部門やプロジェクトチーム単位で利用できるチームWebサイトを作成できる。サイトディレクトリで作成、登録されたサイトに含まれる情報は、水平・垂直双方の検索が可能となり、各部署のユーザーによる自由なWSSサイトの管理と情報システム部門による統合的な管理を実現する。

　全社で一斉にシステムやインフラを含めたネットワークの刷新を行う場合などは、こちらの方法で導入するのがベストだろう。

　もう一つは、チームやプロジェクトといった、共通の情報を共有する単位でWSSサイトを構築することだ。こちらは先述のトップダウンに対してボトムアップ方式と呼ぶ。設計、構築、運用から管理までをそれぞれの部門が行えるため、自由なサイト運営が可能だ。部門ごとに作成されたWSSサイトは、情報システム部門が社内全体を統括するSPSポータルサイトのサイトディレクトリに登録する。こうすることで、例え独立して構築したサイトでも、企業ポータルから一元的に検索することが可能となる。

　この方法は、例えば部門サーバなど、部署単位でのインフラが整備されている部門からまずWSSサイトを導入し、順次他の部署もサイトを構築してゆくケースが考えられる。社内システム全体の調査や分析、設計など、立ち上げまでにどうしても時間のかかるトップダウン方式と比較すると、環境の整った部署から導入を始められるので、ユーザーは必要な環境をすぐ手に入れることができる。一方、個別のサーバー単位での管理や運用までを考慮しなくてならないというリスクも残る。

　このように、SPSはトップダウン・ボトムアップ双方の展開方法によって、インフラの整備状況や社内での管理ポリシーにあわせてフレキシブルに導入することができる。とはいえ、通常は管理者による設計の後に全社一斉に展開されるトップダウン式の導入形式を選択するのが、セキュリティや運用のコスト削減という意味を含めても一般的だろう。

　　　　　 | 1 2 | 次のページ

[佐々木 優美子，ITmedia]

Copyright © ITmedia, Inc. All Rights Reserved.