特集
2004/05/21 16:52 更新

第十回
安易なポータル製品の導入に潜む落とし穴 (1/2)

いままで9回にわたり、EIPとしてのSPSのさまざまな機能を紹介してきた。中には、「自分が本当に必要なのはスケジュールやファイルの共有だけであり、それならば安価なWebグループウェアで十分だ」と考えるユーザーもいるだろう。しかし、その選択には大きな落とし穴が潜んでいる。

　昨今、各社からWebをインタフェースとした簡易なグループウェアがいくつか提供されている。こういったツールは、あらかじめ「スケジュール」「会議室予約」など一般的な情報共有のための仕組みを最初から備えているとともに、Webをベースとした平易なインタフェースを特徴としていることもあり、社内で必要最小限の情報を共有するには非常に安価で手軽に導入することができる。

　SPSはこれまでの連載の中で紹介してきたように、非常に豊富な機能をもった製品である。いまポータルの導入を考えているユーザの中には「なにもこんなにも機能は必要ではない」「自分たちに今必要ななのは、スケジューラとファイル共有だけでそれで充分である」と考え、その結果巷にあふれるこういった安価なWebグループウェア製品のほうを導入しようとしている人も多いのではないだろうか？

　果たして、それは本当に賢い選択なのだろうか？

グループウェア系製品とSPSはどう異なるのか？

　こういったWebグループウェア製品とMicrosoft Office SharePoint Portal Server 2003（以下、SPS）のようなポータル構築アプリケーション製品間には、それらの保有機能として根本的な違いがある。それは、コンテンツアグリゲーションの機能と、このアグリゲーションしたコンテンツ間での情報連携を行うWebパーツ間連携である。

　コンテンツアグリゲーションとは、社内（あるいは社外）にある各システム上のコンテンツをポータル画面上に個別フレームとして取り込み、あたかも新しい画面のような全体一覧画面を生成して表示する機能である。

　SPSをはじめとするポータル構築を専門とした基盤アプリケーションでは、この機能によってユーザーの目的に合わせた情報を一つの画面に表示することができる。一つのシーンを例として挙げてみよう、いま、ある営業担当者が今日のスケジュールデータを確認してA社に訪問する準備をしているとする。A社には先週の訪問で技術担当からすでにプロポーザルを提出済みである。彼は一つのポータル画面上で、このスケジュールを確認しつつ社内のファイルサーバのドキュメントディレクトリから先週提出した提案書の内容を引っ張ってきて確認をし、あわせて社内のCRMシステム上で顧客情報からA社との過去の取引経緯を確認することができる。ついでにいうとポータル画面の右隅には、提携している外部調査会社によるA社の信用情報も表示される。

fig01a.gif
fig01b.gif

　この例から分かるようにSPSでは、SPSの内部にある情報と、SPSとは別個に構築されたシステム上の情報を、区別することなくシームレスに統合して表示することが可能である。

　これに対して、前述したようなグループウェア機能をベースにインタフェースのWeb化でポータル製品を語るようになったツールは、通常このようなコンテンツアグリゲーションの機能を持っていないため、一つの画面上に表示できる情報（コンテンツ）の種類が限られてしまう。

制限される拡張性

　最近のポータル構築アプリケーションでは、「スケジュール」「会議室予約」「掲示板」といったグループウェア的な機能モジュールを予めパーツとして保有しているものも多い。ポータルの導入時には採用すべき製品の比較評価を行うことが一般的であるが、この際に単純に製品の持つこういった機能面について、「ある」「ない」式の比較だけをいってしまうと大きな罠に陥ることになってしまう。

　SPSなどのポータル構築アプリケーションの場合は、こういったグループウェア的機能はあくまでパーツに過ぎず、将来的にパーツを追加購入したり自己開発することでポータル上に表示するコンテンツを拡張していくことが可能である。これに対してWebグループウェア製品でのそれは、すなわち画面上に表示できるコンテンツそのもので機能限界を表す。したがって、最初の段階で組み込まれていないコンテンツを後から追加することは相当に困難となる。多大なコストをかけてそれを開発したとしても、あくまでそのツールの基盤上での開発となってしまうため、今度は技術継承や基盤部分のバージョンアップコストの増大、将来的なサポート不安という問題が発生してしまう。

　例えば営業部門での情報化の進展の場合、一般的に初期段階ではファイルサーバ上に提案書や見積書の雛形を共有することから始まる。この段階でポータルを導入した場合、SPSではファイルサーバ上ドキュメント共有用のコンポーネントをポータルに組み込むことになるが、Webグループウェア製品の場合は、その製品がもつドキュメント共有機能を転用しての実現となる。

　したがって将来的に、営業日報の活用を目指してSFAツールを入れたり、さらに高度なCRMを導入する展開となった際に、Webグループウェア製品ではSFAにあたる日報の報告や回覧機能、CRM用の顧客情報といった新しい情報項目を、どのように内部に取り込んでいくか改めて検討し、開発をやり直す必要が発生してしまう。これに対してSPSの場合は単純である、導入するSFAツールやCRMシステムとのインタフェース部分のパーツを追加開発すれば済むのである。導入するツールが著名な製品であった場合、このパーツがマイクロソフトから無償で提供される可能性も高い。

fig02a.gif
fig02b.gif

　　　　　 | 1 2 | 次のページ

[吉川　幸比古，ITmedia]

Copyright © ITmedia, Inc. All Rights Reserved.