JP2011165059A - ウェブアプリケーションのユーザビリティ評価方法、分析サーバ、及び、そのプログラム - Google Patents

Abstract

【課題】ページが遷移するウェブアプリケーションのユーザビリティを適切に評価する。
【解決手段】ウェブアプリケーションのユーザビリティ評価方法であって、ウェブアプリケーションのページ遷移ログと、ページ上での操作ログとを取得する第１の手順と、前記ページ遷移ログから特定のページ遷移パターンを持つ部分を抽出する第２の手順と、前記抽出したページ遷移パターンを構成するページ毎に、ページの出現順毎に操作ログを関連付けて管理する第３の手順と、前記関連付けて管理している操作ログを統計処理しページ利用状況を分析する第４の手順と、前記ページ遷移パターンと、前記ページ利用状況とを基に、ユーザビリティ評価する第５の手順と、を含む。
【選択図】図１

Description

本発明は、ウェブアプリケーションのユーザビリティ評価方法に関し、特に業務フローを基にページを遷移するウェブアプリケーションのユーザビリティを評価する技術に関する。

近年、様々なサービスや業務がウェブアプリケーションとして実現されている。また、クライアント端末やサーバ装置の高性能化やAjax(Asynchronous JavaScript + XML、JavaScriptは登録商標。以下同じ）等のウェブ技術の高度化に伴い、Google Mapsに代表される単純なページ遷移ではないウェブアプリケーションも実現されている。

さらには、手順に沿って業務を進める定型的な業務をウェブアプリケーションによって業務を支援することも試みられている。このウェブアプリケーションは、業務フローを示すフローチャート表示画面と、業務フローの各ステップでの作業を支援するガイド画面とからなる。ユーザはフローチャート表示画面上に表示された業務フローに従ってガイド画面上で作業するのみで、定型的な業務を遂行することができる。

ところで、ウェブアプリケーションはＩＴリテラシの低い人でも使いこなせることが要求されている。また、ウェブアプリケーションのユーザビリティの高低が業務の効率性に大きく影響するため、ユーザビリティの高いウェブアプリケーションであることが要求されている。

ウェブアプリケーションのユーザビリティを改善させるためには、まず現状の把握が必要である。次いで、把握した現状を分析し、分析結果に基づきウェブアプリケーションを改善する。ウェブアプリケーションの現状を把握する技術には、ページ遷移を把握する技術と、ページの利用状況を把握する技術がある。

ページ遷移を把握する技術としては、ユーザがページ遷移で迷っていることを把握する技術（特許文献１参照）、頻度の高いアクセスルートを把握する技術（特許文献２参照）、及び、製作者の意図通りにアクセスされているかを調査する技術（特許文献３参照）などがある。

特開２００３−２８１３１７号公報 特開２００４−１５２２０９号公報 特開２００２−１２３５１６号公報

上記特許文献１から３に開示された技術は、単純にページ遷移が繰り返されるウェブアプリケーションに適用されるものである。そのため、単にページの利用状況やページの遷移を把握すればよかった。一方、業務フローを基にページ遷移するウェブアプリケーションの場合、業務フローの効率性に直結するページの遷移と、業務フローの各業務ステップでの作業の効率性に直結するページの利用状況の相関関係を考慮する必要がある。

すなわち、ユーザビリティを改善させるためには、複数ユーザのページの利用状況ログやページの遷移ログから、（１）ページの遷移パターン（すなわち経路）から問題となりそうな遷移パターン（戻る、繰り返し、Ｊｕｍｐ、リルートなど）を抽出する、（２）問題になりそうなページを列挙する、（３）ページの利用状況（操作ログ）を統計処理などによって分析する、等の作業が必要となる。特にステップ（２）の作業では、遷移パターン毎にページの抽出を行う必要がある。また、同一のページが、遷移パターン内の複数箇所に現れる場合もあり、その場合、それぞれ別のページとして抽出する必要がある。これは例えばリルートのケースで発生し、分岐ページは一回目の分岐の際とリルート時の分岐の際の２回発生する。この２回の分岐をそれぞれ別のページとして出現順を考慮して管理し操作ログを分析する必要がある。そのため、例えば経験の浅い担当者が短時間で操作ログのみで分析することは困難であった。

本発明は、上述した課題を考慮したものであって、ページが遷移するウェブアプリケーションのユーザビリティを適切に評価できるウェブアプリケーションのユーザビリティ評価方法を提供することを目的とする。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、ウェブアプリケーションのユーザビリティ評価方法であって、ウェブアプリケーションのページ遷移ログと、ページ上での操作ログとを取得する第１の手順と、前記ページ遷移ログから特定のページ遷移パターンを持つ部分を抽出する第２の手順と、前記抽出したページ遷移パターンを構成するページ毎に、ページの出現順毎に操作ログを関連付けて管理する第３の手順と、前記関連付けて管理している操作ログを統計処理しページ利用状況を分析する第４の手順と、前記ページ遷移パターンと、前記ページ利用状況とを基に、ユーザビリティ評価する第５の手順と、を含むことを特徴とする。

本発明の代表的な実施の形態によれば、ページの遷移と、ページの利用状況の相関関係を考慮しているので、ウェブアプリケーションのユーザビリティを適切に評価することができる。

本発明の実施の形態の計算機システムのシステム構成例を示す図である。 本発明の実施の形態の業務フロー定義の一例を示す図である。 本発明の実施の形態の計算機システムの動作の概要を示す図である。 本発明の実施の形態のログ分析サーバ装置のモジュール構成例を示す図である。 本発明の実施の形態の計算機システムの動作の一例を示すフローチャートである。 本発明の実施の形態のカレントタスク終了処理の一例を示すフローチャートである。 本発明の実施の形態のカレントタスク操作ログ保存テーブルの一例を示す図である。 本発明の実施の形態のルート管理テーブルの一例を示す図である。 本発明の実施の形態の操作ログ管理テーブルの一例を示す図である。 本発明の実施の形態のページ遷移分析部による処理の一例を示すフローチャートである。 本発明の実施の形態の遷移パターン抽出ルールテーブルの一例を示す図である。 本発明の実施の形態の遷移パターン抽出ルールテーブルの他の例を示す図である。 本発明の実施の形態の抽出ルールの適応処理の一例を示すフローチャートである。 本発明の実施の形態の部分遷移ログを管理する遷移パターン管理テーブルの一例を示す図である。 本発明の実施の形態の遷移パターン毎操作ログ管理テーブルの一例を示す図である。 本発明の実施の形態の利用状況評価部による処理の一例を示すフローチャートである。 本発明の実施の形態の利用状況評価ポリシーテーブルの一例を示す図である。 本発明の実施の形態が適用されるページ遷移と操作ログの一例を示す図である。 本発明の実施の形態が適用される評価結果の一例を示す図である。 本発明の実施の形態の利用状況出力部による出力例を示す図である。 本発明の実施の形態のページ内操作分析部による処理の一例を示すフローチャートである。

以下、本発明の実施の形態について図面を参照して説明する。なお、本明細書においては、計算機（コンピュータ）システムのプロセッサによって実行される各プログラムによって実現される機能ブロックを、「モジュール」や「部」と表現する。

以下、図１から図１８を参照して、本発明の実施の形態について説明する。

（システム構成）
図１は、本発明の実施の形態の計算機システム１の構成例を示す図である。

図１に示す計算機システム１は、一台以上（図１では二台）のクライアント装置１００、一台以上（図１では一台）のウェブサーバ装置１２０、及び、一台以上（図１では一台）のログ分析サーバ装置１４０を備える。クライアント装置１００、ウェブサーバ装置１２０及びログ分析サーバ装置１４０はネットワーク１６０を介して相互に接続されている。なお、ウェブサーバ装置１２０とログ分析サーバ装置１４０とは、物理的に同一の装置に実装されてもよい。

クライアント装置１００は、ウェブサーバ装置１２０が提供するウェブアプリケーションを利用する計算機である。このクライアント装置１００は、入出力装置１０１、プロセッサ１０２、ネットワークインターフェイス１０３、及び、メモリ１０４を備える。

入出力装置１０１は、ユーザインターフェイスを提供する入力装置（例えば、キーボード、マウス等）及び出力装置（例えば、表示装置）である。プロセッサ１０２は、メモリ１０４に記憶されたウェブブラウザプログラム１０５、スクリプトプログラム１０６、及び、不図示のオペレーティングシステム（ＯＳ）などを実行する。ネットワークインターフェイス１０３は、クライアント装置１００がネットワーク１６０を介してデータを通信するための通信インターフェイスである。メモリ１０４は、プロセッサ１０２によって実行されるプログラム、及びこれらのプログラムによって使用されるデータを格納するなお、クライアント装置１００はさらに外部記憶装置（不図示）などを備えてもよい。

ウェブサーバ装置１２０は、クライアント装置１００にアプリケーションのサービスを提供する計算機である。ウェブサーバ装置１２０は、ネットワークインターフェイス１２１、プロセッサ１２２、ローカルディスク１２３、入出力装置１２５、及び、メモリ１２６を備える。

ネットワークインターフェイス１２１は、ウェブサーバ装置１２０がネットワーク１６０を介してデータを通信するための通信インターフェイスである。プロセッサ１２２は、メモリ１２６に記憶されたウェブサーバプログラム１２７、ウェブアプリケーションプログラム１２８、及び、機能挿入プログラム１２９を実行する。各プログラムの動作の詳細については後述する。なお、ここでウェブアプリケーションプログラム１２８とは、業務フローを基にページ遷移する業務フロー指向のウェブアプリケーションプログラムをいう。また、かかる業務フローを定義する情報である業務フロー定義１２４がローカルディスク１２３に格納されている。なお、業務フロー定義１２４は、業務フローの定義情報が含まれていればよく、データベースサーバなど別のサーバや別の記憶装置に格納されていても良い。

ローカルディスク１２３は、磁気ディスク装置、不揮発性半導体メモリなどによって構成される記憶装置である。ローカルディスク１２３は、ウェブサーバ装置１２０に内蔵されていても、ウェブサーバ装置１２０の外部に設けられる外部記憶装置であってもよい。

入出力装置１２５は、ユーザインターフェイスを提供する入力装置（例えば、キーボード、マウス等）及び出力装置（例えば、表示装置）である。なお、ウェブサーバ装置１２０が入出力装置１２５を備えなくてもよい。この場合、ウェブサーバ装置１２０は、クライアント装置１００によって操作される。メモリ１２６は、プロセッサ１２２によって実行されるプログラム、及びこれらのプログラムによって使用されるデータを格納する。

図２は、本発明の実施の形態の業務フロー定義１２４の一例を示す図である。業務フロー定義１２４は、図２に示す業務フロー定義データ１５００のような独自のＸＭＬ（eXtensible Markup Language）形式のデータである。この業務フロー定義データ１５００は、ｆｌｏｗ要素によって業務フローを定義している。具体的には、ｎｏｄｅ要素によって当該業務フローを構成する複数の業務ステップを定義し、ｃｏｎｎｅｃｔｓ要素によってこれら業務ステップ間の接続関係を定義する。また、各ｎｏｄｅ要素は、ｎｏｄｅの識別子を示すｉｄ属性、対応するウェブページのＵＲＬ（Universal Resource Location）を示すｕｒｌ属性によって構成される。ここで、ｉｄ属性が“start"及び"end"である各ｎｏｄｅ要素は、当該業務フローの開始ステップ及び終了ステップを示す、システム定義の特殊なｎｏｄｅである。一方、各ｃｏｎｎｅｃｔ要素は、どのｎｏｄｅから（ｆｒｏｍ）を示すｆｒｏｍ属性、どのｎｏｄｅへ(ｔｏ)接続するかを定義するｔｏ属性によって構成される。これらの要素によって、図２に示す業務フロー定義データ１５００は、業務フロー１５０１を定義する。なお、本実施の形態では、独自のＸＭＬ形式で業務フローを定義しているが、業務フローを構成する複数の業務ステップのＵＲＬ及び順序関係が分かれば、どのような表現形式でもよい。

ログ分析サーバ装置１４０は、クライアント装置１００のウェブブラウザ上で動作するウェブアプリケーションのページ遷移ログ及び各ページにおけるユーザの操作ログを分析する。ログ分析サーバ装置１４０は、ネットワークインターフェイス１４１、プロセッサ１４２、ローカルディスク１４３、入出力装置１４５、及び、メモリ１４６を備える。

ネットワークインターフェイス１４１は、ログ分析サーバ装置１４０がネットワーク１６０を介してデータを通信するための通信インターフェイスである。プロセッサ１４２は、メモリ１４６に記憶されたログサーバプログラム１４７、ログ分析プログラム１４８、及び、ログ可視化プログラム１４９を実行する。ローカルディスク１４３は、磁気ディスク装置、不揮発性半導体メモリなどによって構成される記憶装置であり、ルート管理テーブル７００、操作ログ管理テーブル７２０、遷移パターン毎ログ管理テーブル１０００、カレントタスク操作ログ保存テーブル１４４、遷移パターン抽出ルールテーブル９００、利用状況評価テーブル１２００を格納する。ローカルディスク１４３は、ログ分析サーバ装置１４０に内蔵されていても、ログ分析サーバ装置１４０の外部に設けられる外部記憶装置であってもよい。各々のプログラムの動作及び各テーブルの構成の詳細については後述する。

入出力装置１４５は、ユーザインターフェイスを提供する入力装置（例えば、キーボード、マウス等）及び出力装置（例えば、表示装置）である。なお、ログ分析サーバ装置１４０が入出力装置１４５を備えなくてもよい。この場合、ログ分析サーバ装置１４０は、クライアント装置１００によって操作される。メモリ１４６は、プロセッサ１４２によって実行されるプログラム、及びこれらのプログラムによって使用されるデータを格納する。

（計算機システム１の動作の概要）
図３は、本発明の実施の形態の計算機システム１の動作の概要を示す図である。なお、以下の説明では、各々の装置１００、１２０、１４０においてプログラムがメモリにロードされてプロセッサによって実行されている状態を「モジュール」と表現する。

まず、ウェブブラウザモジュール２００は、ウェブブラウザに対するユーザの操作を受け付けると、ウェブサーバモジュール２２０に対してユーザの操作に応じたリクエスト２０３を送信する。リクエスト２０３は、一般的なＨＴＴＰ（Hyper Text Transfer Protocol）プロトコルに従って送信される。なお、リクエスト２０３のプロトコルはＨＴＴＰプロトコルに限定されない。

ウェブサーバモジュール２２０は、リクエスト２０３を受信すると、受信したリクエスト２０３に対応するウェブアプリケーション２２１に処理を要求する。ウェブアプリケーション２２１は、リクエスト２０３に応じた処理を実行してレスポンス２２４を生成し、生成されたレスポンス２２４を機能挿入モジュール２２２に転送する。機能挿入モジュール２２２は、転送されたレスポンス２２４に操作ログ取得機能モジュール２２３を埋め込んだレスポンス２２５を生成し、生成されたレスポンス２２５をウェブブラウザモジュール２００に送信する。ここで、操作ログ取得機能モジュール２２３を埋め込む処理は、Ｊ２ＥＥのＳｅｒｖｌｅｔＦｉｌｔｅｒ機能、ＩＩＳ（Internet Information Services）のＩＳＡＰＩ（Internet Server Application Programming Interface）Ｆｉｌｔｅｒ機能など、ウェブサーバ装置１２０が備えるレスポンスのフィルタリング機能を利用して実現される。なお、本実施の形態では、機能挿入モジュール２２２により動的に操作ログ取得機能モジュール２３５を埋め込んでいるが、機能挿入モジュール２２２を利用せずにウェブアプリケーション２２１に操作ログ取得機能モジュール２２３を予め埋め込んでおいてもよい。

ウェブブラウザモジュール２００は、機能挿入モジュール２２２からレスポンス２２５を受信すると、受信したレスポンス２２５中のＨＴＭＬ（Hyper Text Markup Language）データを解釈して、ウェブブラウザ上に表示する。また、レスポンス２２５に埋め込まれた操作ログ取得機能モジュール２２３をスクリプトエンジンモジュール２０１に転送する（２０２）。その後、操作ログ取得機能モジュール２２３は、必要な初期化を実行した後、クライアント装置１００のウェブブラウザ上のユーザ操作を操作ログとして取得する。ウェブブラウザモジュール２００は、ウェブブラウザ上でページ遷移が発生した場合等に、操作ログ取得機能モジュール２２３によって取得された操作ログ２０５を、ログ分析サーバ装置１４０のログサーバモジュール２４０に送信する。なお、このページ遷移はネットワークを介した通信を伴うもの及び伴わないものを含む。後者の通信を伴わないケースは、ＤＯＭ（Document Object Model）やＪａｖａＳｃｒｉｐｔ技術などを用いてウェブブラウザ側でページを書き換える場合である。

ログサーバモジュール２４０は、ウェブブラウザモジュール２００から操作ログ２０５を受信した場合、受信した操作ログ２０５をカレントタスク操作ログ保存テーブル１４４に順次格納する（２４３）。カレントタスク操作ログ保存テーブル１４４とは、現にクライアント装置１００上で動作しているウェブアプリケーション２２１が定義している業務の単位（例えば、業務フローの開始から終了まで、ログインからログアウトまでなど、「カレントタスク」という）についての操作ログを一時的に保存するテーブルである。なお、カレントタスクが終了した場合、カレントタスク操作ログ保存テーブル１４４に保存された操作ログ２０５に基づき、ルート管理テーブル７００及び操作ログ管理テーブル７２０に格納する情報が生成され、生成された情報が各テーブルに追加される。

ログ分析モジュール２４１は、カレントタスク操作ログ保存テーブル１４４、ルート管理テーブル７００、及び、操作ログ管理テーブル７２０に格納されたデータに基づき、ページ遷移、及び各ページにおけるユーザ操作を統合的に分析する。ログ可視化モジュール２４２は、ログ分析モジュール２４１による分析結果に応じてユーザビリティの問題点等を可視化する。ログ分析モジュール２４１の処理は、管理者ユーザからの指示や、任意のタイミングでのバッチ処理などによって実行する。

（ログ分析サーバ装置１４０のモジュール構成例）
図４は、本発明の実施の形態のログ分析サーバ装置１４０のモジュール構成例を示す図である。また、図４には、カレントタスク操作ログ保存テーブル１４４に保存される操作ログ３０１、３０２、３０３を例示している。カレントタスク操作ログ保存テーブル１４４には、操作ログ３０１、３０２、３０３が保存されている。なお、操作ログ３０１、３０２、３０３を区別する必要がない場合、これらを総称して「操作ログ３００」と表現する。操作ログ３００は、図３に示す操作ログ２０５に対応する。操作ログ３００は、カレントタスクの識別子であるタスクＩＤ、このカレントタスクにおいて参照されたページの識別子であるページＩＤ、このページＩＤで特定されるページ上でユーザの操作がなされた時刻である操作時刻、ユーザの操作の対象である操作対象（オブジェクト名など）、ユーザの操作の内容である操作内容（クリック、入力など）、ユーザの操作の結果である操作結果（選択値、入力値など）によって構成される。このように、カレントタスク操作ログ保存テーブル１４４には複数の操作ログ３００が保存される。なお、前記ページ上でのユーザ操作は、ページ内の操作状況を分析できればよく、必ずしも全ての項目を記録しておく必要はない。例えば、クリック回数のみに着目した場合、操作内容としてクリックを記録しておくのみでも良い。

ログ分析モジュール２４１は、ページ遷移分析部３２０、ページ内操作分析部３２１、利用状況評価部３２２によって構成される。ページ遷移分析部３２０は、ページ遷移を分析する。具体的には、ページ遷移分析部３２０は、遷移パターン抽出ルール９００を参照し、ページの遷移パターンから問題となりそうな特定の遷移パターン（戻る、繰り返し、Ｊｕｍｐ、リルートなど）を抽出する。ページ内操作分析部３２１は、各ページに対するウェブブラウザ上のユーザの操作（マウスのクリックや、Ｆｏｒｍへの入力など）を分析する。このとき、遷移パターン毎かつ遷移パターン内のページ出現順毎にページの操作ログ３００を関連付けて管理し、ページ内操作分析を行う。利用状況評価部３２２は、ページ遷移分析部３２０及びページ内操作分析部３２１による分析の結果と、利用状況評価ポリシーテーブル１２００のポリシー定義とを参照し、各ページの利用状況を評価する。また、この利用状況評価部３２２は、ウェブページの利用状況の評価結果に基づいて、ウェブアプリケーションのユーザビリティの問題点を抽出する。ページ遷移分析部３２０、ページ内操作分析部３２１、利用状況評価部３２２は、ログ分析モジュール２３１実行時に、順に実行される。

ログ可視化モジュール２４２は、利用状況出力部３４０、閾値調整部３４１、ランキング計算部３４２によって構成される。利用状況出力部３４０は、利用状況評価部３２２による評価の結果を出力する。ここで出力とは、テーブル形式で出力したり、ウェブアプリケーションの画面にオーバーレイ表示形式で表示したりするためのデータを生成することである。閾値調整部３４１は、利用状況評価ポリシーテーブル１２００に定義される条件式の閾値（図１２の閾値１２０３、閾値１２１２参照）を分析対象のウェブアプリケーションに最適となるよう調整する。ランキング計算部３４２は、利用状況評価部３２２の評価結果に基づき、利用状況評価ポリシーテーブル１２００に定義された各ポリシー定義の条件式への適合度を定量的に評価し、複数の問題点がある場合にそのランキング（その問題点に対応する優先度）を計算する。例えば、条件が“以下”の場合、値が小さいほど適応度が高い、条件が“以上”の場合、値が大きいほど適応度が高いとし、適応度を定量的に評価する。

（システム動作例）
図５は、本発明の実施の形態の計算機システム１の動作の一例を示すフローチャートである。

はじめに、ウェブブラウザモジュール２００は、ウェブページのページ表示リクエストをウェブサーバ装置１２０に送信する（Ｓ４２１）。ウェブサーバモジュール２２０は、クライアント装置１００からページ表示リクエストを受信すると（Ｓ４４１）、ページ表示リクエストに対応するウェブアプリケーション２２１を呼び出す（Ｓ４４２）。次に、ウェブアプリケーション２２１は、ステップＳ４４１で受信したページ表示リクエストに応じた処理を実行してレスポンスを生成し、生成したレスポンスを機能挿入モジュール２２２に転送する（Ｓ４４３）。

その後、機能挿入モジュール２２２は、転送されたレスポンスに操作ログ取得機能モジュール２２３を挿入する（Ｓ４４４）。なお、ステップＳ４４４の処理は、Ｊ２ＥＥ（ＴＭ）のＳｅｒｖｌｅｔＦｉｌｔｅｒなどウェブサーバ装置１２０が備えるレスポンスのフィルタリング機能を利用することで実現することができる。

次に、ステップＳ４４１で受信したページ表示リクエストがタスクの開始を示す場合には（Ｓ４４５で”ＹＥＳ”）、ステップＳ４４６に進んで、機能挿入モジュール２２２は、タスクＩＤを新規採番し、レスポンスのＣｏｏｋｉｅにタスクＩＤを設定する（Ｓ４４６）。一方、ページ表示リクエストがタスクの終了を示す場合には（Ｓ４４５で”ＮＯ”かつＳ４４７で”ＹＥＳ”）、ステップＳ４４８に進んで、機能挿入モジュール２２２は、レスポンスにタスクの終了を示すフラグを挿入する（Ｓ４４８）。その後、機能挿入モジュール２２２は、レスポンスをクライアント装置１００に送信する（Ｓ４４９）。

なお、ステップＳ４４５及びＳ４４７に示すタスクの開始又は終了は、タスクの開始や終了を示すリクエストや、特定のボタンの押下のイベントなどを基に判定する。以上、ステップＳ４４１からＳ４４９に係るウェブサーバ装置１２０の処理は、ウェブサーバ装置１２０が動作を停止するまで続けられる（Ｓ４５０）。

ステップ４４３からステップ４４９の処理は、ウェブサーバ装置１２０が備えるレスポンスのフィルタリング機能を利用しているが、上記機能を実現するプログラム断片をウェブアプリケーション２２１に予め組み込んでおいてもよい。

ウェブブラウザモジュール２００は、ウェブサーバ装置１２０からレスポンスを受信すると（Ｓ４２２）、スクリプトエンジンモジュール２０１を呼び出し、操作ログ取得機能モジュール２２３を初期化する（Ｓ４２３）。また、ステップＳ４２３の初期化処理では、ウェブブラウザモジュール２００上でのユーザの操作のイベントを監視するイベントリスナーを設定する。続いて、操作ログ取得機能モジュール２２３は、ウェブブラウザモジュール２００上でのユーザの操作を操作ログとして取得し、操作ログをウェブブラウザモジュール２００上で一次記録する配列に追加する（Ｓ４２４）。ステップＳ４２４の処理は、ページ遷移のイベントが発生するまで繰り返される（Ｓ４２５）。

ページ遷移のイベントが発生した場合には（Ｓ４２５）、ウェブブラウザモジュール２００は、タスクＩＤ、ページＩＤ、操作ログ３００、及びタスク終了フラグの値をログ分析サーバ装置１４０に送信する（Ｓ４２６）。以上のステップＳ４２１からＳ４２６のクライアント装置１００による処理は、クライアント装置１００上で動作するウェブアプリケーションが終了するまで続けられる（Ｓ４２７）。なお、本実施の形態では、ページ単位で操作ログをまとめて、まとめられたログをログ分析サーバ装置１４０に送信しているが、ログを取得する毎に送信したり、別の単位で操作ログをまとめて送信したりしてもよい。

ログ分析サーバ装置１４０のログサーバモジュール２４０は、クライアント装置１００から操作ログを受信し、受信した操作ログをカレントタスク操作ログ保存テーブル１４４に保存する（Ｓ４０１）。続いて、タスク終了フラグの値を参照することによって、カレントタスクが終了したか否かを判定する（Ｓ４０２）。カレントタスクが終了した場合（Ｓ４０２で”ＹＥＳ”）、カレントタスクの終了処理を実行する（Ｓ４０３）。ステップＳ４０３の処理の詳細は後述する。一方、カレントタスクが終了していない場合（Ｓ４０２で”ＮＯ”）、ステップＳ４０１に戻り、ログ分析サーバ装置１４０が動作を終了するまで処理が続けられる（Ｓ４０４）。

（カレントタスク終了処理）
カレントタスク終了処理の説明の前に、カレントタスク操作ログ保存テーブル１４４、ルート管理テーブル７００及び操作ログ管理テーブル７２０の構成について説明する。図７は、本発明の実施の形態のカレントタスク操作ログ保存テーブル１４４の一例を示す図であり、図８Ａは、本発明の実施の形態のルート管理テーブル７００の一例を示す図であり、図８Ｂは、本発明の実施の形態の操作ログ管理テーブル７２０の一例を示す図である。

図７に示すカレントタスク操作ログ保存テーブル１４４は、前述のように、クライアント装置１００のウェブブラウザに対するユーザの操作ログを保存するテーブルである。カレントタスク操作ログ保存テーブル１４４には、タスクＩＤ６０１と、ページＩＤ６０２と、操作ログ６０３とが対応付けられて保存される。

タスクＩＤ６０１は、タスクを一意に識別するための識別子である。ページＩＤ６０２は、ページを一意に識別するための識別子である。操作ログ６０３は、ページＩＤ６０２で識別されるページにおける操作を示す。

図８Ａに示すルート管理テーブル７００は、ウェブページの遷移を示すルート（経路）情報を管理するテーブルである。ルート管理テーブル７００には、ルートＩＤ７０１と、ウェブページの遷移を示すルート（経路）情報７０２と、が対応付けられて管理される。

ルートＩＤ７０１は、ウェブページの遷移を示すルートを一意に識別するための識別子である。ルート情報７０２は、ルートＩＤ７０１で識別されるルートにおけるウェブページの遷移を示す。

図８Ｂに示す操作ログ管理テーブル７２０は、ルート管理テーブル７００で管理されたルート情報の各々のページに操作ログを対応付けて管理するためのテーブルである。操作ログ管理テーブル７２０には、ルートＩＤ７２１と、ページＩＤ７２２と、操作ログ７２３とが対応付けられて管理される。

ルートＩＤ７２１は、ルートを一意に識別するための識別子であり、ルート管理テーブル７００のルートＩＤ７０１と共通の識別子が使用される。ページＩＤ７２２は、ページを一意に識別するための識別子であり、カレントタスク操作ログ保存テーブル１４４のページＩＤ６０２と共通の識別子が使用される。操作ログ７２３は、ページＩＤ６０２で識別されるページにおける操作を示す。

なお、一つのルート中に同一のページが複数回現れる場合、別のページとして区別して操作ログを管理する。図８ＡのルートＩＤがｒ３のときＵＲＬ１が２回現れているが、図８Ｂでは２回目のＵＲＬ１はＵＲＬ１−２と区別される。本例は前述したリルートのケースを示している。なお、図７のページＩＤ６０２、図８Ａのルート情報７０２、図８ＢのページＩＤ７２２として管理される各データはネットワークを介した通信を伴うもの又は伴わないもののいずれであってもよい。

次に、カレントタスク終了処理について説明する。

図６は、本発明の実施の形態のカレントタスク終了処理（図５のＳ４０３）の一例を示すフローチャートである。

まず、ログサーバモジュール２４０は、カレントタスク操作ログ保存テーブル１４４から、タスクＩＤをキーに、全てのページＩＤ及び操作ログを取得する（Ｓ５０１）。次に、ログサーバモジュール２４０は、ステップＳ５０１で取得したページＩＤに基づき導き出されるページ遷移（ルート）と同一のルートを持つルート情報をルート管理テーブル７００から検索し、ルート情報が存在する場合にはそのルートＩＤを取得する（Ｓ５０２）。

次に、ログサーバモジュール２４０は、同一のルートがあるか否か、すなわちステップＳ５０２でルートＩＤを取得できたか否かを判定する（Ｓ５０３）。判定の結果、同一のルートがあると判定された場合（Ｓ５０３で”ＹＥＳ”）、全てのページＩＤについて、ルートＩＤ、ページＩＤが一致する操作ログ（操作ログ管理テーブル７２０のレコード）を更新する（Ｓ５０４）。

一方、ステップＳ５０３において、同一のルートがないと判定された場合（Ｓ５０３で”ＮＯ”）、ログサーバモジュール２４０は、ルートＩＤを新規に採番する（Ｓ５０５）。次に、ログサーバモジュール２４０は、ルートＩＤ、及び、ページＩＤのリストをルート管理テーブル７００に追加する（Ｓ５０６）。その後、ルート管理テーブル７００に追加したページＩＤの全てについて、ルートＩＤ、ページＩＤ、及び、操作ログを対応付けたデータを操作ログ管理テーブル７２０に追加する（Ｓ５０７）。

以上説明したように、ログサーバモジュール２４０は、ステップＳ５０４の処理によって操作ログ管理テーブル７２０の操作ログを更新するとともに、ステップＳ５０５からＳ５０７の処理によってルート管理テーブル７００及び操作ログ管理テーブル７２０に新規にルート情報を追加する。

（ページ遷移分析処理）
ページ遷移分析部３２０の処理の説明の前に、遷移パターン抽出ルールテーブル９００について説明する。図１０Ａは、本発明の実施の形態の遷移パターン抽出ルールテーブル９００の一例を示す図であり、図１０Ｂは、本発明の実施の形態の遷移パターン抽出ルールテーブル９００の他の例を示す図である。

図１０Ａに示す遷移パターン抽出ルールテーブル９００は、遷移パターン抽出ルール９０２及び名称９０３を含む。また、図１０Ｂに示す遷移パターン抽出ルールテーブル９００は、遷移パターン抽出ルール９１２及び名称９１３を含む。遷移パターンの名称９０３及び９１３は、後述する利用状況評価ポリシーテーブル１２００を用いた評価時に参照（１２１１、１２２１）する。

図１０Ａに示す遷移パターン抽出ルール９０２は、業務フロー定義を考慮せずにウェブページの遷移にのみ着目している。一方、図１０Ｂに示す遷移パターン抽出ルール９１２は、業務フロー定義を考慮して、ウェブページ遷移と、そのウェブページ遷移が業務フロー定義に沿っているか否かを示す情報と、の組み合わせからなる。遷移パターン抽出ルール９１２に示す記号「順」は業務フロー定義に沿った順方向の遷移、記号「逆」は業務フロー定義とは逆方向の遷移、記号「未」は業務フロー定義には定義されていない遷移を示す。図１０Ｂでは、ページをａ、ｂ、ｃと表現しているが、それぞれにラベルを付けても良い。例えば、リルート時のルールにおいて、ａは“分岐ステップ”、ｂは“戻りステップ”、ｃは“リルート先ステップ”といったラベル付けを行う。このラベル付けは、後述する利用状況評価ポリシーテーブル１２００を用いた評価時に参照（１２１１、１２２１）する。

本実施の形態のページ遷移分析部３２０は、このような遷移パターン抽出ルールテーブル９００を参照し、正規表現ベースの抽出ルールを用いて特定の遷移パターンを抽出する。なお、抽出ルールの定義方法、抽出の処理方式は、正規表現に限定されるものではなく、他の遷移パターンの抽出ルール定義、抽出処理であってもよい。

図９は、本発明の実施の形態のページ遷移分析部３２０の処理の一例を示すフローチャートである。

ページ遷移分析部３２０は、前述したように、遷移パターン抽出ルールテーブル９００を参照し、ページの遷移パターンから特定の遷移パターンを抽出するものである。

はじめに、ページ遷移分析部３２０は、図１０に示す遷移パターン抽出ルールテーブル９００から抽出ルールを一つ取得する（Ｓ８０１）。次に、ページ遷移分析部３２０は、抽出ルールがあるか否か、すなわち抽出ルールを取得できたか否かを判定する（Ｓ８０２）。

判定の結果、抽出ルールがある場合（Ｓ８０２で”ＹＥＳ”）、ステップ８０３に進む。一方、抽出ルールがない場合（Ｓ８０２で”ＮＯ”）、このページ分析処理を終了する。なお、このステップＳ８０２の処理は、遷移パターン抽出ルールテーブル９００に格納された全ての抽出ルールについて実行される。

ステップＳ８０３において、ページ遷移分析部３２０は、ルート管理テーブル７００から１レコードのページ遷移ログ（図８Ａに示すルート情報７０２）を取得する。次に、ページ遷移分析部３２０は、ページ遷移ログがあるか否か、すなわちルート情報を取得できたか否かを判定する（Ｓ８０４）。

判定の結果、ページ遷移ログのレコードがある場合（Ｓ８０４で”ＹＥＳ”）、ステップ８０５に進む。一方、ページ遷移ログのレコードがない場合（Ｓ８０４で”ＮＯ”）、ステップ８０１に戻って次の抽出ルールを一つ取得する。なお、このステップＳ８０３の処理は、ルート管理テーブル７００に管理された全てのページ遷移ログについて実行される。

ステップＳ８０５では、ステップ８０３で取得されたページ遷移ログにステップ８０１で取得した抽出ルールを適応し、マッチした部分のページ遷移ログの一覧を取得する（Ｓ８０５）。ここで部分遷移ログとは、抽出ルールとマッチした遷移パターンを有するページ遷移ログである。ステップＳ８０５の処理については、図１１を用いて具体的に説明する。

その後、ページ遷移分析部３２０は、マッチした部分遷移ログがあるか否かを判定する（Ｓ８０６）。判定の結果、マッチした部分遷移ログがある場合（Ｓ８０６で”ＹＥＳ”）、ステップ８０７に進む。一方、マッチした部分遷移ログがない場合（Ｓ８０６で”ＮＯ”）、ステップ８０３に戻って次のページ遷移ログのレコードを取得する。

ステップＳ８０７では、ステップ８０５で取得した部分遷移ログを構成する各ページにおける操作ログを管理している操作ログ管理テーブル７２０（図８Ｂ参照）に対するリンクを、遷移パターン毎に対応付けて、遷移パターン毎ログ管理テーブル（図１２Ｂ参照）に格納する（Ｓ８０７）。なお、前述したように、一つの遷移パターン中に同一のページが複数回現れる場合、出現順を考慮して別のページとして区別して操作ログを管理する。

以上説明した処理によって、ページ遷移分析部３２０は、抽出ルールにマッチした部分遷移ログと、この部分遷移ログを構成する各ページにおける操作ログとを抽出する。

図１１は、本発明の実施の形態の抽出ルールの適応処理の一例を示すフローチャートである。本実施の形態では、正規表現ベースの抽出ルールの適応処理の一例を示す。抽出ルールから有限オートマトンを作成し、適応対象のページ遷移ログのＵＲＬリストに適応することによって、抽出ルールに一致する部分遷移ログの一覧を取得する、一般的な抽出ルールの適応処理である。

はじめに、ページ遷移分析部３２０は、図９のステップＳ８０１で取得した抽出ルールから有限オートマトンを生成する（Ｓ１６０１）。次に、ページ遷移分析部３２０は、図９のステップＳ８０３で取得したページ遷移ログ中のＵＲＬリストの先頭からＵＲＬを一つ取得する（Ｓ１６０２）。次に、ページ遷移分析部３２０は、ステップ１６０１で生成された有限オートマトンにステップ１６０２で取得したＵＲＬを入力する（Ｓ１６０３）。

次に、有限オートマトンの状態が有効であるか否かを判定する（Ｓ１６０４）。有限オートマトンの状態が有効であると判定された場合（Ｓ１６０４で”ＹＥＳ”）、ステップＳ１６０５に進む。

一方、ステップＳ１６０４において有限オートマトンの状態が無効であると判定された場合（Ｓ１６０４で”ＮＯ”）、ステップＳ１６０９に進んで有限オートマトンの状態をリセットし（Ｓ１６０９）、次のＵＲＬがある場合には（Ｓ１６０８で”ＹＥＳ”）、ＵＲＬリストから次のＵＲＬを取得して（Ｓ１６１０）、ステップＳ１６０３に進み、マッチング処理を再開する。

ステップＳ１６０５において、有限オートマトンの状態が受理となった場合（Ｓ１６０５で”ＹＥＳ”）、マッチしたＵＲＬリストを部分遷移ログとして記録し（Ｓ１６０６）、有限オートマトンをリセットして（Ｓ１６０７）、次のＵＲＬがある場合には（Ｓ１６０８で”ＹＥＳ”）、ＵＲＬリストから次のＵＲＬを取得して（Ｓ１６１０）、ステップS１６０３に進み、マッチング処理を再開する。

（遷移パターン毎ログ管理テーブル１０００）
図１２Ａ及び図１２Ｂは、本発明の実施の形態の遷移パターン毎ログ管理テーブル１０００の一例を示す図である。遷移パターン毎ログ管理テーブル１０００は、遷移パターンテーブル１０１０（図１２Ａ）と、遷移パターン毎操作ログ管理テーブル１０２０（図１２Ｂ）とによって構成される。

遷移パターンテーブル１０１０（図１２Ａ）は、ページ遷移分析部３２０が図８に示すページ遷移分析処理によって抽出した部分遷移ログのルート情報を管理する。遷移パターンテーブル１０１０には、部分遷移パターンを一意に識別するための識別子であるパターンＩＤ１００１と、ページの部分遷移を示すルート情報１００２とが対応付けられて管理される。

遷移パターン毎操作ログ管理テーブル１０２０（図１２Ｂ）は、部分遷移ルートにウェブページの操作ログを対応付けて管理するテーブルであり、パターンＩＤ１００１に相当するパターンＩＤ１０２１と、ページＩＤ１０２２と、各々のページＩＤ１０２２における操作ログ１０２３とが対応付けられたデータを管理する。例えば、パターンＩＤ１００１がｐ３の部分遷移ルート（ＵＲＬ１→ＵＲＬ３→ＵＲＬ１→ＵＲＬ２）の場合、図１２Ｂに示す通り、ＵＲＬ１（１回目）、ＵＲＬ３、ＵＲＬ１（２回目）、ＵＲＬ２の操作ログ１０２３が対応付けて管理される。

（ページ内操作分析処理）
図１８は、本発明の実施の形態のページ内操作分析部３２１による処理の一例を示すフローチャートである。はじめに遷移パターン毎操作ログ管理テーブル１０２０から、１レコード取得する（１８０１）。本レコードは、ある遷移パターンの、あるページの、ログの一覧に相当する。レコードがある場合（Ｓ１８０２で”ＹＥＳ”）にはステップ１８０３に進み、レコードがない場合（Ｓ１８０２で”ＮＯ”）には処理を完了する。レコードがある場合、レコードからページ内の操作ログ１０２３を全て取り出す（Ｓ１８０３）。操作ログがない場合（Ｓ１８０４で”ＮＯ”）は次のレコードの処理にうつる。操作ログがある場合（Ｓ１８０４で”ＹＥＳ”）、操作ログに対して統計処理を行い、その結果であるページ内操作分析結果を、ページ利用状況カラム１０２４に記録する（Ｓ１８０５）。ここで、ページ内操作分析のための統計処理は、ページの滞留時間（例えばページ表示時間から無操作時間を引いた時間）、コンテンツ熟読割合（例えばページスクロール情報から算出したページの表示割合）など、ページ内の操作ログから求まる情報である。

（利用状況評価処理）
図１３は、本発明の実施の形態の利用状況評価部３２２による処理の一例を示すフローチャートである。はじめに、ステップＳ１１０１において、利用状況評価部３２２は、遷移パターンテーブル１０１０からレコードを一つ取得する（Ｓ１１０１）。次に、前記取得した遷移パターン中の各ページに関する利用状況を、遷移パターン毎操作ログ管理テーブル１０２０から取り出す（Ｓ１１０２）。次に、利用状況評価部３２２は、取得した一つのレコード中の遷移パターン及び操作ログが利用状況評価ポリシーテーブル１２００（図１４参照）の評価条件に該当するかを検索する（Ｓ１１０３）。

判定の結果、取得したレコードが利用状況評価ポリシーテーブル１２００の評価条件に該当する場合（Ｓ１１０３で”ＹＥＳ”）、評価結果の内容を取得し、取得した評価結果の内容を評価結果リストに追加する（Ｓ１１０４）。

その後、遷移パターンテーブル１０１０に未処理のレコードがあるか否かを判定する（Ｓ１１０５）。その結果、遷移パターンテーブル１０１０に未処理のレコードがあれば（Ｓ１１０５で”ＹＥＳ”）、処理が終了していないレコードがあるので、ステップＳ１１０１に戻り、次のレコードを処理する。

ステップＳ１１０１からＳ１１０５の処理の繰り返しによって、遷移パターンテーブル１０１０の全てのレコードに対して利用状況評価処理が実行され、問題点のリストが抽出される。

図１４は、本発明の実施の形態の利用状況評価ポリシーテーブル１２００の一例を示す図である。

図１４に示す利用状況評価ポリシーテーブル１２００は、遷移パターン１２０１と、ページ利用状況１２１０と、評価結果１２２０とが対応付けられたデータを管理する。遷移パターン１２０１及びページ利用状況１２１０は、問題があると判定される条件式が含まれる。具体的には、遷移パターン１２０１は、評価メトリックス１２０２、デフォルト閾値１２０３及び条件１２０４によって構成され、ページ利用状況１２１０は、評価メトリックス１２１１、デフォルト閾値１２１２及び条件１２１３によって構成される。また、評価結果１２２０は、改善対象１２２１及び改善内容１２２２によって構成される。

例えば、利用状況評価ポリシーテーブル１２００の１行目によると、リルートの割合が３０％以上であり、戻りステップの滞留時間が３秒以下の条件を満たす場合、分岐ステップ（ｂ）は改善対象であり、改善内容１２２２に記載された改善が望まれる。

例えば、図１５に示すページ間の遷移の場合、ＵＲＬ３のページの利用状況についてリルート発生率が４０％で、リルート発生時の平均滞留時間が５秒なので、利用状況評価ポリシーテーブル１２００の１行目の条件にマッチし、図１６に示すような改善が提案される。

図１７は、本発明の実施の形態の利用状況出力部３４０による出力例を示す図である。

図１７に示す出力例では、ウェブアプリケーションのページ遷移の表示ページに重ねて改善内容が表示されることによって、開発者は問題点を容易に把握することができる。

以上説明したように、本発明の実施の形態によると、評価メトリックスが膨大で、問題点を列挙することが困難だった分析作業について、問題点を自動的に列挙することで、分析作業の時間を大幅に削減することが可能となる。

上記実施の形態では業務フロー定義の存在するウェブアプリケーションについての一例を説明したが、業務フロー定義が明示的に存在しないウェブアプリケーションについても同様に分析することが可能である。一つの方法としては、図１０Ａに示したようにページの遷移情報について着目した方法である。この方法ではフロー定義との差異については考慮しない。もう一つの方法としては、各ユーザのルート情報（図８Ａ）に対して統計処理を行い、出現頻度の高いルートを、仮想的に業務フロー定義として利用する方法である。本方法では、頻度の高いルートから外れたルートに対して分析を行うこととなる。

１００ クライアント装置
１２０ ウェブサーバ装置
１４０ ログ分析サーバ装置
２００ ウェブブラウザモジュール
２０１ スクリプトエンジンモジュール
２２０ ウェブサーバモジュール
２２１ ウェブアプリケーション
２２２ 機能挿入モジュール
２２３ 操作ログ取得機能モジュール
２４０ ログサーバモジュール
２４１ ログ分析モジュール
２４２ ログ可視化モジュール
３２０ ページ遷移分析部
３２１ ページ内操作分析部
３２２ 利用状況評価部
３４０ 利用状況出力部
３４１ 閾値調整部
３４２ ランキング計算部
６００ カレントタスク操作ログ保存テーブル
７００ ルート管理テーブル
７２０ 操作ログ管理テーブル
９００ 遷移パターン抽出ルールテーブル
１０００ 遷移パターン毎ログ管理テーブル
１２００ 利用状況評価ポリシーテーブル

Claims (11)

1. ウェブアプリケーションのユーザビリティ評価方法であって、
   ウェブアプリケーションのページ遷移ログと、ページ上での操作ログとを取得する第１の手順と、
   前記ページ遷移ログから特定のページ遷移パターンを持つ部分を抽出する第２の手順と、
   前記抽出したページ遷移パターンを構成するページ毎に、ページの出現順毎に操作ログを関連付けて管理する第３の手順と、
   前記関連付けて管理している操作ログを統計処理しページ利用状況を分析する第４の手順と、
   前記ページ遷移パターンと、前記ページ利用状況とを基に、ユーザビリティ評価する第５の手順と、
   を含むことを特徴とするウェブアプリケーションのユーザビリティ評価方法。
2. 前記第５の手順は、
   画面遷移パターンに関する第１条件と、画面利用状況に関する第２条件とを含む利用状況評価のためのポリシー定義からユーザビリティを分析することを特徴とする請求項１記載の評価方法。
3. 前記第１の手順は、ウェブアプリケーションによって提供される業務の手順を定義する業務フロー定義を取得する手順を含み、
   前記第２の手順は、前記業務フロー定義に従った画面の遷移パターンと異なるパターンで画面が遷移している場合に、前記画面遷移ログから特定の遷移パターンを抽出することを特徴とする請求項１に記載の評価方法。
4. 前記評価方法は、前記ポリシー定義に従って、前記評価の結果の優先度を定める手順を含み、
   前記定められた優先度に基づいて、前記評価結果の表示順序を制御して評価結果を出力することを特徴とする請求項２に記載の評価方法。
5. 前記ポリシー定義の第１条件は、前記画面が元の画面に戻る割合が所定の閾値以上であることであり、
   前記ポリシー定義の第２条件は、前記画面の滞留時間が所定の閾値以下又は前記画面の熟読割合が所定の閾値以下であることを特徴とする請求項１に記載の評価方法。
6. 前記第２の手順は、抽出ルールを元に処理し、前記抽出ルールは、前記業務フロー定義に従った画面の遷移と逆方向の遷移であることを示す情報を含むことを特徴とする請求項１に記載の評価方法。
7. クライアント装置に提供されたウェブアプリケーションのユーザビリティを評価する分析サーバであって、
   前記クライアント装置で動作するウェブブラウザに表示されるページの遷移と照合される抽出ルールを管理し、
   前記分析サーバは、ページ遷移ログを前記抽出ルールと照合することによって、前記ページ遷移ログから特定の遷移パターンを抽出し、
   前記抽出したページ遷移パターンを構成するページ毎に、ページの出現順毎に操作ログを関連付けて、ログ管理情報に記録し、
   前記関連付けて管理している操作ログを統計処理しページ利用状況を分析し、
   前記ページ遷移パターンと、前記ページ利用状況とを基に、前記ウェブアプリケーションを評価することを特徴とする分析サーバ。
8. 前記分析サーバは、前記クライアント装置にウェブアプリケーションを提供するウェブサーバを含むことを特徴とする請求項７に記載の分析サーバ。
9. クライアント装置に提供されたウェブアプリケーションのユーザビリティを評価する分析サーバにおいて実行されるプログラムであって、
   ウェブアプリケーションのページ遷移ログと、ページ上での操作ログとを取得する第１の手順と、
   前記ページ遷移ログから特定のページ遷移パターンを持つ部分を抽出する第２の手順と、
   前記抽出したページ遷移パターンを構成するページ毎に、ページの出現順毎に操作ログを関連付けて管理する第３の手順と、
   前記関連付けて管理している操作ログを統計処理しページ利用状況を分析する第４の手順と、
   前記ページ遷移パターンと、前記ページ利用状況とを基に、ユーザビリティ評価する第５の手順と、
   を前記分析サーバに実行させることを特徴とするプログラム。
10. 前記分析サーバは、
    画面遷移パターンに関する第１条件と、画面利用状況に関する第２条件を含む利用状況評価のためのポリシー定義を管理し、
    前記第５の手順は、画面遷移パターンに関する第１条件と、画面利用状況に関する第２条件を含む利用状況評価のためのポリシー定義からユーザビリティを分析することを特徴とする請求項９記載のプログラム。
11. 前記分析サーバは、
    前記ウェブアプリケーションによって提供される業務の手順を定義する業務フロー定義を管理し、
    前記抽出ルールは、前記業務フロー定義に従ったページの遷移パターンと異なる遷移パターンを含み、
    前記第２の手順は、前記業務フロー定義に従ったページの遷移パターンと異なるパターンでページが遷移している場合に、前記ページ遷移ログから特定の遷移パターンを抽出することを特徴とする請求項９に記載のプログラム。