本文へ

ここから本文です

CMS Watch:ポータル製品の比較 /エンタープライズ・ポータル:どの氷山の一角か?

2007年10月19日 掲載

Janus Boye /ジャニス・ボイエ

今日の企業は、コンテンツとサービスの統合に対して、野心的な目標を立てることが多い。業界紙からカンファレンスまで、ほとんどユービキタスに語られているアドバイスに従って、IT部門や業務部門はたいてい、ポータル・ソフトを用いてこの目標を達成しようとする。しかし、多くの顧客は、ポータル・パッケージが思ったほどすぐに使えるものではないことを知って、いらいらを募らせることになる。

一方、「ポータル」という言葉は、しばしば間違って使われていて、まるで共通点のない様々なビジネスニーズのソリューションを指すことがある。ワークグループ・プロジェクト・コラボレーションから、セルフサービス型のカスタマーサービス・エクストラネットなどまでだ。

このように、ポータル・ソフトがプロジェクトの氷山の一角にすぎないのだとすれば、顧客やベンダーは、「自分はどの氷山の一角に立っているのか?」という点も問いかけるべきだろう。世界中から集まった数十人という顧客やインテグレータを前に、リリースされたばかりのEnterprise Portals Reportについて話す機会を得た後、私たちは、ポータルというカテゴリーに存在するいくつかのタイプを認識するようになった。そして、すべての点で他を寄せ付けない決定的なポータル・ソフトが1つ存在する、というわけではないことも分かってきた。

ポータル:長所

ポータルに重要な長所があることは、以前の記事でも指摘した。特に、伝統的なCMSや単純なウェブアプリケーションと比較すると、それは明らかだ。ポータルは、既存のアプリケーションや情報ストアを統合するためのフレームワークを提供し、絶え間なく変化する企業の要件に適応できる柔軟なインフラストラクチャを作ることによって、業務プロセスを向上するというニーズに対応できる。

高いレベルでは、ポータルは、次のことを実現することによって、広範な戦略プロジェクトで重要な役割を果たせる。

より具体的に言うと、ポータル技術は次のことができる。

当然ながら、ポータル・ソフトがこれらすべてを独力でできるわけではない。ポータル製品とは、通常、エンタープライズ・ソフトやドキュメント管理、検索、データウェアハウス・ツールといった、既存のサービスを強化するものなのだ。

ポータル:短所(見苦しい点)

そしてここに、ポータル製品が抱える最初の問題となり得る病原菌が潜むことになる。ポータル・パッケージ自体が提供してくれるのはどのサービスなのか、あるいは、既存の(そしておそらくは見苦しい)エンタープライズ・ツールやレポジトリに対して、プラットフォームが単に入口を提供するだけなのはどの範囲なのか、これらを理解するのが場合によっては難しいからだ。

ポータルは、ビルトイン・アプリケーションの便利なセットを提供し、短期間での立ち上げを助けてくれるかもしれない。しかし現実には、多くの場合、ポータルは氷山の一角にすぎず、たいていの顧客が思っている以上に、様々なレイヤーをカスタマイズしたり統合したりするたくさんの作業が必要となる。この種の技術ではたいていそうだが、ポータルの購入者も、導入にかかる時間とコストを過小評価し、一方で、ユーザが適応し、ビジネス上の見返りが生まれるまでの期間を過剰に期待している。

もちろん、若い市場セグメントでは、いつだって物事が刻々と変化し、成長の痛みがあるのは事実だ。大手のソフトウェア・インフラ・ベンダーはすべて、今ではポータル製品を扱うようになった。しかし、この技術は、まだ今でも比較的未成熟で、ベンダーも顧客も、慢性的なパフォーマンス問題、ユーザビリティの欠点、使用率の低さなどを解決するのに苦心している。

私たちのリサーチの結果、パフォーマンスの問題は特に深刻だということが分かってきた。ポータル製品の顧客の多くは、ソフトばかり購入してハードが足りていないことを、自ら認識している。高度なキャッシュ技術や、そのほかすばらしい関連技術をもってしても、ポータルは、なおもリソースを食い荒らす獣で、その恐るべき食欲は、ユーザ・テスティングの最終段階になって、システムの遅さを白日の下にさらす傾向がある。

このことから、ビジネス・コントロールと真の統合の期待を本当に満たそうと思ったら、ほとんど必ずと言っていいほど、大変な努力が必要となる。多くの企業では、当初のポータル・プロジェクトが1年以上にわたることはないが、フル導入は数年がかりとなる。これでは、短期間で達成する「ウェブ2.0」プロジェクトという夢にはほど遠く、むしろ大変なERP導入のようだ。複雑さを過小評価しているという点は、なぜCMSが予算を超えてしまうのかを説明する一般的な理由のひとつだが、残念ながら、ポータル・プロジェクトにも同じことが当てはまる。

与えられた選択肢

ただし、このように一般化して語るのには、注意も必要だ。ポータルの導入は、多くの場合、その範囲という点で違いがあるからだ。ポータルのなかには、会社全体を視野に設計されたものもあれば、特定の業務ミッション、多くの場合は開発レベルのミッションを満たすことを目指しているものもある。当然、ベンダーが違えば、ターゲットとしているシナリオも違う。Enterprise Portals Reportで紹介したベンダーはすべて、自らの製品を「エンタープライズ・ポータル」と位置付けているが、現実には、用途によって製品ごとの甲乙があり、複雑さやコストの面でも大きな違いがある。

人気のMicrosoftのSharePoint Portal Serverを例にしてみよう。このポータルは、ワークグループのドキュメント共有には適しているかもしれないが、Eビジネスや社外の参加者が介入するセルフサービス型のシナリオでは、かなり弱点がある。

様々なポータル・ベンダーをよく理解するには、典型的な使用例をよく検討してみるといいだろう。使用例には、次のようなものがある。

ベンダーのなかには、複数のシナリオで強みを発揮するところもある。しかし、前述したように、現在のところ、すべてのシナリオで他を圧倒するベンダーはいない(Enterprise Portals Reportでは、これらの具体的なシナリオごとに各ベンダーの優位性を考察している)。

また、2006年時点で市場に出回っているシステムは、ITアーキテクチャの点でも、かなり違いがある。選択肢は、.NET、Java、Pythonをベースとしたシステムだ。なかには、統合にサービス志向のアーキテクチャを用いており、他のシステムとの相互運用性を確立できるようになっているものもある。また、明らかにスタンドアローンのポータル・ソリューションと見られるものもある。

現実を見失わず、自分でリサーチを

ポータル購入の意思決定にあたっては、様々な条件や状況の間でバランスを取ることが必要になる。そのタイミングは、社内的な問題や予算承認のプロセスにも影響されるが、理想的には、かなりの戦略が介在しているべきだ。野心的なポータル・プロジェクトを始めたいという気持ちは、理解できないでもない。が、実際には、投資やビルド、テスティングを控えめにして、この旅路を一歩一歩進んでいったほうが、利があるかもしれない。

このやり方であれば、必然的に起きてくるエンジニアリング上の問題や、もしかすると相当困難になるかもしれない状況に、効果的に対処できるだけでなく、会社が抱える特定のシナリオに合ったプラットフォームを導入しているかどうかを、随時確認していける。野心的な目標は持っていたほうがいい。けれども、個々のポータル・ソリューションの限界には、現実的な態度で臨むことだ。みなさんのプロジェクトがどう進んだか、ぜひ私に教えてほしい。グッド・ラック!

ジャニス・ボイエは、Boye ITのマネージングディレクターを務めている。Boye ITは、デンマークにあるコンサルティング企業で、コンテンツマネジメントとポータルを専門としており、どのベンダーにも寄らない中立的な立場をポリシーとしている。ボイエは、前職では、企業ソフトのベンダーで様々な職務とヨーロッパ全域の顧客を担当していた。また、CMS WatchのEnterprise Portals Reportも執筆している。

この記事の原文「Enterprise Portals: Tip of Which Iceberg?」は、2006年4月6日、「cmswatch.com」に掲載された。

本サイトに掲載している CMS Watch の記事は、CMSWatch.com より許可を得て、翻訳・転載しているものです。

CMSWatch.com は、ウェブ・コンテンツマネジメントおよびエンタープライズ・コンテンツマネジメント・ソリューションについて、ベンダーから完全に経済的独立をした形で、利用者の立場に立って、独自の情報やトレンド、意見、評価を提供しているサイトです。

CMS Watch はまた、最新の CMS 関連の製品分析やアドバイスが掲載されている The CMS Report の販売(無料サンプルあり)もしています。
The CMS Report について


トラックバック

このページのトラックバックURL
http://www.designit.jp/mt/mt-tb.cgi/1040