ここから本文です

CMS Watch：ポータルのユーザビリティ /ポータルのユーザビリティを向上するには

2007年11月30日 掲載

Janus Boye /ジャニス・ボイエ

世界規模の組織では、従業員やビジネスパートナーが相互にデジタルなコミュニケーションを行うにあたって、エンタープライズ・ポータルがデフォルトのインターフェースとして使われることが増えている。従業員名簿、経営情報、ドキュメントの共有など、有用なサービスがたくさんあり、ポータルから簡単にアクセスできるようになってきているためだ。結果として企業は、このまだ若い（そして未成熟な）テクノロジーに多額の投資をしている。

しかし、残念ながら、ポータルのユーザーエクスペリエンスは、しばしば従業員にとって苦痛の種になっている。ユーザビリティ上の問題が非常に多いためだ。あまりにも多くのケースで、ポータル・プロジェクトの最後の段階になるまで、重要なインターフェースとプロセスの懸念が対応されないまま放置されている。そして、その段階になっても、企業がユーザビリティに対して十分な配慮を施すことは、ほとんどない。ポータルへの投資が本当に見返りを生むというのであれば、この点を正すべき時に来ている。

妥当性のあるユーザーインターフェースの要件

ポータル・プロジェクトに着手する前に、ほとんどの企業では、要件を集めてドキュメント化する作業にかなりの時間を割いている。これには一般に、事業計画から技術的詳細までのあらゆることをカバーする長々しいドキュメントを作る過程が含まれる。しかし、ポータルのインターフェースに関しては、あまり多くを含んでいないことがほとんどだ。

そこで一歩引いて、適切なユーザビリティの要件を特定するにはどうすればいいかを考えてみることにしよう。それには、まず第一に、計画中のポータルのユーザーを理解することが大切だ。そのポータルのオーディエンス（対象者、使い手）は会社の全社員なのか、経営陣だけなのか、はたまた主に顧客が使うことを想定しているのか。オーディエンスのタイプに基づいて、ユーザーがポータル上で行うタスクに的を絞っていく必要がある。いわばシナリオベースのこの分析を成功させるコツは、具体的なタスクを簡潔明瞭な文章で定義し、そのうえで、それらの業務を最も簡単にサポートするにはどうすればいいかを考えることだ。

少なければ少ないほど、またシンプルであればあるほど良いということを、忘れないでほしい（iPodやレゴと同じ要領だ）。そして、技術や機能にはあまりとらわれず、むしろ単純に「仕事の遂行」だけを考えるようにしよう。特にポータルの開発者は、あればあったで良いけれどもインターフェースを複雑化してしまうような機能をなるべく排除するよう、努力することだ。

基本的かつ妥当性のあるユーザーインターフェース（UI）の要件を満たすうえで、ポータルには、次のことが求められる。

標準に準拠したマークアップを用い、どんなブラウザからでもアクセスできるようにすること

業界標準をサポートすることによって、ポータルは、視覚や聴覚に障害がある従業員にもアクセスしやすいものになる。このことを忘れず認識しておかなければならない。

標準的なサイズのモニターで使いやすいようにすること

縦にスクロールしなければならないだけでもユーザーには苦痛だが、横のスクロールはさらに劣悪だ。ポータルを作ったことで、会社がユーザーやシステムアドミニストレータのための大型モニターに投資しなければならなくなるようであってはならない。

短くて意味があり、ユーザーフレンドリーなURLを使うこと

実際のURL（例えばwww.cmswatch.com/portal[cmswatch.com]）は、ユーザーエクスペリエンスの要素として過小評価されている。けれども、恒常的に通用しないURL、またはテクノロジーに依存した長くて複雑なURLは、避けなければならない。どんなに優れたシステムでも、5〜10年後に会社が同じポータルを使っている可能性は低い。このことからも、リンク切れや使えないブックマーク、またはEメールで送れないURLを作ってしまわないよう、気を付ける必要がある。

負荷がかかった時でも迅速なパフォーマンスを提供すること

ポータルとは、そもそも動的なものだ。つまり、その構成要素はすべて、リアルタイムで構築されなければならない。このため、パフォーマンスはすべてにかかわる課題であり、重要な課題だ。なぜなら、従業員はスピードを尺度としてポータルの良し悪しをある程度判断するだろう。ストレスや負荷テストを早い段階から頻繁に行うことによって、高価なインフラを最後の最後で慌てて追加したり、応急処置で済まそうとしたりするのを防止しなければならない。

頑強で簡単にカスタマイズできるインターフェースを提供すること

ブランディングの要件や全社内の様々な人からの様々なニーズに応えるため、ポータルのデザインは、簡単に変更できるものでなければならない。技術畑でないビジネスサイドのユーザーでも変更できるものであれば理想的だ。インターフェースに会社のロゴを足すといった初歩的な変更を加えるだけでも、ユーザー浸透度に明らかに影響を与えることができる。さらに調整を加えれば、もっと価値をもたらすことができるだろう。UIの一部が機能しない場合は、暗号じみたテクニカルなエラーメッセージではなく、分かりやすいメッセージを提示すること。これは、配慮すべき基本的な要件だ。

The Enterprise Portals Report[cmswatch.com]で私たちが行った比較評価では、残念ながら、この基本的な要件をきちんと満たしているポータルが、今日市販されている製品のなかにはほとんど見られなかった。

ダッシュボードを再検討する

ほとんどの企業は、今日のエンタープライズ・ポータルでデフォルトとされているレイアウトをそのままやみくもに使っており、そのレイアウトは、一般に「ポートレット」や「ウェブパーツ」と呼ばれる複数の構成要素から成り立っている。この結果が、トランプカードやダッシュボードのようなデザインのインターフェースだ。

このようなページレイアウトのアプローチは、AOL、Lycos、MyYahoo!といった初期のパブリックポータルの名残だ。これらのサイトでは、ビジターが個人のプロフィールを作って、それに合うようにインターフェースを変えることができた。今日、ポータル市場で競っているソフトウェアベンダーのほとんどは、インターネットバブルが最高潮に達した1999〜2000年前後の時期にソリューションのバージョン1をリリースした。パーツ式のレイアウトを使うというのは、当時は有効なアプローチに見えた。このおかげで、インターネット業界におけるたくさんの新興企業が、ベンダーの提供する「ポータルビルダー・モジュール」を介して独自のポータルを作れるようになった。

しかし現在、このデファクトスタンダードのせいで企業におけるユーザビリティの進歩が減速させられている可能性がある。ポータルは、ビジネス上の様々なシナリオで使うことができる。けれども、現在のダッシュボードのアプローチは、ビジネスインテリジェンスとレポーティングに関係したきわめて限定的な場面でしか合理的とは言えないからだ。今求められているのは、新しいソリューションだ。これを「ポータル2.0」と呼んでもいいかもしれない。すなわち、より良いユーザーエクスペリエンスを提供するか、少なくともユーザーエクスペリエンスのトピックを、プロジェクトの早い段階から高い優先度の課題として扱えるポータルが必要なのだ。

ベンダーの側からは、ダッシュボードがレイアウトのデフォルトにすぎず、単なるサンプルサイトなのだという反論が出るかもしれない。しかし、私たちがリサーチしたところでは、ライセンスを購入した企業のなかで、意味あるUIを作るために包括的な変更を計画する企業は5％足らずだった。これは、ポータル開発者やプロジェクトマネジャー、そしてビジネスユーザーの全員が、通常はUIを「想定」して作業している、あるいはパッケージに入ってくるデザインが何であれそれを単に受容していることに原因がある。

しかしながら、ポータルを浸透させ、ひいては事業を成功させるうえで、効果的な見た目は不可欠な要素だ。では、ポータルがUIをどのように作成するかを見ていこう。

ユーザーエクスペリエンスを正しく理解する

最もベーシックなレベルで言うならば、ポータルのUIとは、（X）HTML、JSP、ASP、CSSなどの標準プロトコルを使ってウェブページを表示するものだ。ポータル・ソフトのこのレイヤーでは、次の項目が管理される。

• 一貫したレイアウトのために使われるページテンプレート
• ユーザーに特定のサービスを提供するポートレット
• ポータル開発者に表現のためのサービスを提供するポートレット

アーキテクチャの観点から言うと、UIは、ポータル内で一緒に機能する様々なアプリケーションのインプットとアウトプットを司る。例えば、ビジネスインテリジェンス・サービス、最新のプロジェクトファイルのリスト、最近のニュースを整理したリスト、重要なビジネストランザクションの最新状況などを確認するための「ビュー」に対して、1つのポータルがインターフェースを提供することがあるだろう。これらのビューは、それぞれが独自の要件、インターフェース、そして複雑さを備えた既存のアプリケーションに基づいているかもしれない。

すでに説明したポータルの構成要素、つまりポートレットやウェブパーツなどは、土台となっているアプリケーションが持つ特定機能を包みこんだコンポーネントであり、そのサービスをポータルに統合するために共通のインターフェースを提供している。そして、そのコンポーネントは、2つの要素から成り立っている。ひとつは、UIレイヤーにおける機能、もうひとつは、アプリケーションサービス・レイヤーにおける機能だ。そして、ポートレットが、ポータルのアーキテクチャのなかでこの2つのレイヤーの橋渡しをする。

アプリケーションサービス・レイヤーは、一般に、中核となる機能を提供する。データベースのクエリー、ドキュメントの抽出、リストの作成、ユーザーの認証などだ。一方、UIレイヤーは、検索語をはじめとするユーザーのインプットを受け付け、それに対する結果、例えば該当する検索結果のリストなどを表示する。

ポートレットやウェブパーツは、一般に、UIとアプリケーションサービスの両方を提供することから、片方に集中してしまい、もう一方を無視するという落とし穴に陥るのは容易だ。特に開発チームは、アプリケーションサービスに専念してしまい、UIの適切さに害を与える傾向がある。その結果として何が起きるだろうか。それは、様々なポートレットの寄せ集めとしか言いようがないテンプレート、あるいは「スキン」だ。これらのコンポーネントは、各々の機能仕様に対しては適切に動作しているが、全体としては、レイアウトでユーザーを圧倒してしまうか、特定タスクを簡単な操作で達成する能力という点でユーザーをがっかりさせるかのどちらかという結果を招いている。

ウェブサイトとは違うだって？

こう考えると、ほとんどのポータルがウェブサイトやイントラネットから分離された「孤島」として機能しているという事実も、まったく驚きではない。実際、これは技術的には理にかなっているかもしれない。しかし、ユーザーにしてみれば、ポータルとウェブサイトまたはイントラネットの間を行き来するにあたって、慣習に従ったナビゲーションがないというのは、なかなか理解しがたい現実だ。

早くからポータルを導入してきた企業の担当者などから聞いた意見に基づいて、私がお勧めしたいのは、ウェブサイトの大々的な改訂の際と同様に、プロジェクトの早い段階からGUIに時間をかけることだ。ポータル・ソフトのベンダーと契約を交わすより前に、シナリオ分析、ペルソナ分析、そして情報アーキテクチャに対処しておき、テスティングの段階では使い勝手のいいインターフェースを確保することを目指すべきだろう。

実装プロセスがどうなるのか、カスタマイズにどれだけの労力が必要になるのかをよく理解するには、ベンダー評価の一環として、「プルーフ・オブ・コンセプト（proof-of-concept）」となるドキュメントやプロトタイプを入手する必要もある。これには、双方の歩み寄りが必要だ。しかし、たいていの場合、この段階に数週間をかけることによって、後に必要となる数カ月、数年の時間が節約できるはずだ。また、これにより、会社はユーザーを巻き込むチャンスも得る。プロトタイプを開放して自由に遊んでもらい、実践的な提案をしてもらうことで、手遅れになる前に、開発チームが技術的な調整をできるようにするといいだろう。

こうしたプロセスから、驚くべき発見があるかもしれない。私たちが行ったテストとリサーチでは、例えばレイアウトにテーブルを使っていたり、CSSを使える場所と状況に制限を設けているポータル製品があることも分かっている。

今からでも遅くはない

すでにポータルを開設している企業でも、ユーザーエクスペリエンスを向上するのに遅すぎるということはない。ライセンスを購入した他の企業と情報交換することから、多くが学べるだろう。しかも、実践的な改良点のインスピレーションを得ることが目的なのであれば、まったく同じポータル製品やバージョンを使っている企業を探す必要はない。

実際、あまり使われていない機能を無効にするだけでも、ユーザーの間で好評を得ることはある。とはいえ、大幅な変更を加えるのならば、標準に準拠し、サプライヤーにも確認するほうが良いだろう。ベンダーが新しいアップグレード製品をリリースしたために、変更を加えた箇所が失われてしまう確率を減らすことが大切だ。

ポータルの人気を高め、効果を増大するには、ユーザーエクスペリエンスの向上が必要だ。直観的なポータルを実現する道のりは長い。けれども、ベンダーを責めることはできない。現在のポータル市場にはたくさんの選択肢があるが、ユーザビリティの問題を解決する負担は、結局のところ、企業内でポータルを実装する人の肩にかかってくる。サプライヤーと自分自身に対して高い要求水準を突きつけていくのは、実践者、つまり製品を購入した人たちの仕事なのだ。

この記事の原文「Improving portal usability[cmswatch.com]」は、「Knowledge Management Review[melcrum.com]」の2006年7・8月版に掲載されたオリジナルの記事に手を加えて執筆され、2006年9月7日、「cmswatch.com」に掲載された。

トラックバック

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