(57)【特許請求の範囲】
【請求項１】
オンラインで提供される手続きサービスに関し、ネットワークにそれぞれ接続されるクライアント端末と手続サーバの間で通信される電子情報を、手続サーバ内に設けられる計測評価機能部が受信し、計測評価機能部は、クライアント端末からのオンライン手続きの要求を受けたときに、該計測評価機能部内で決定した時刻と当該要求が属する手続群を識別する識別情報とを含む計測用のCookieを作成し、又は手続き群毎にそれらの時刻と識別情報をCookieに付加し、次のステップによりオンライン手続きの所要時間を計測することを特徴とするオンライン手続きにおける計測方法。
計測評価機能部の受信手段が、クライアント端末からのオンライン手続きの要求を受けたのち、計測評価機能部のCookie有無判定手段が当該要求にCookieが含まれているか、否かを判定するステップ
計測評価機能部のCookie有無判定手段が、前記Cookieがあると判定した場合、計測評価機能部の書込手段に対し、当該Cookieを計測評価機能部の一時記憶手段に書き込むよう指示を行うステップ
計測評価機能部の要求内容判定手段が、前記クライアント端末からのオンライン手続きの要求が、計測評価機能部に設けられるデータベースに予め定義された計測対象画面の一つに対して行われたものであるか否かを前記要求の対象となる画面のURLに基づいて判定するステップ
前記要求内容判定手段が、当該要求が計測対象画面の一つに対して行われたものであると判定した場合、Cookie内容判定手段に対し、前記一時記憶手段に記憶されているCookie内に当該要求が属する手続き群と同一の手続き群を示す識別情報が含まれているか否かを判定するよう指示するステップ
上記指示を受けた前記Cookie内容判定手段が、前記同一の手続き群を示す識別情報が無いと判定した場合、計測評価機能部のCookie作成手段に対し、当該要求のあった時刻と当該要求が属する手続群を識別する識別情報とを前記一時記憶手段に記憶されているCookieに付加することでCookieの更新を行うよう指示を行い、又は、前記Cookieそのものが無いと判定した場合、計測評価機能部のCookie作成手段に対し、当該要求のあった時刻と当該要求が属する手続群を識別する識別情報とが含まれるCookieを新たに作成するよう指示を行うステップ
上記指示を受けた前記Cookie作成手段が更新した又は新たに作成したCookieを、前記書込手段に対して前記一時記憶手段に保存するよう指示を行うステップ
前記受信手段が手続サーバーから応答を受信した後に、計測評価機能部の応答内容判定手段が、前記手続サーバからの応答の中に予め定義された手続きの完了を示す情報があるか、否かを判定するステップ
前記応答内容判定手段が、完了情報があると判定した場合、計測評価機能部の読取手段に対し、前記一時記憶手段に一時記憶していたCookieを読取るよう指示を行うステップ
前記応答内容判定手段が、完了情報があると判定した場合、計測評価機能部の手続き種別判定手段が、完了した手続き種別を判定するステップ
計測評価機能部の計測データ抽出手段が前記一時記憶手段から読み出されたCookieの中から前記完了したものと判定された手続き種別と同一の手続き群に属する時刻情報を手続き群を示す識別情報に基づいて抽出したのち、計測評価機能部の所要時間算出手段に対し、当該時刻と手続きが完了した時刻との差を計算するよう指示を行うステップ
上記指示を受けた所要時間算定手段が、計測評価機能部のデータベース書込手段に対し、上記の計算結果に基づく情報をオンライン手続きの所要時間に対応するものとして計測評価機能部の記憶手段に保存するよう指示を行うステップ
【請求項２】
オンラインで提供される手続きサービスに関し、ネットワークにそれぞれ接続されるクライアント端末と手続サーバの間で通信される電子情報を、手続サーバとは別に設けられ該手続サーバに対するプロキシ型サーバとして作動するネットワークに接続されている評価サーバ内に設けられる計測評価機能部が受信し、計測評価機能部は、クライアント端末からのオンライン手続きの要求を受けたときに、該計測評価機能部内で決定した時刻と当該要求が属する手続群を識別する識別情報とを含む計測用のCookieを作成し、又は手続き群毎にそれらの時刻と識別情報をCookieに付加し、次のステップによりオンライン手続きの所要時間を計測することを特徴とするオンライン手続きにおける計測方法。
計測評価機能部の受信手段が、クライアント端末からのオンライン手続きの要求を受けたのち、計測評価機能部のCookie有無判定手段が当該要求にCookieが含まれているか、否かを判定するステップ
計測評価機能部のCookie有無判定手段が、前記Cookieがあると判定した場合、計測評価機能部の書込手段に対し、当該Cookieを計測評価機能部の一時記憶手段に書き込むよう指示を行うステップ
計測評価機能部の要求内容判定手段が、前記クライアント端末からのオンライン手続きの要求が、計測評価機能部に設けられるデータベースに予め定義された計測対象画面の一つに対して行われたものであるか否かを前記要求の対象となる画面のURLに基づいて判定するステップ
前記要求内容判定手段が、当該要求が計測対象画面の一つに対して行われたものであると判定した場合、Cookie内容判定手段に対し、前記一時記憶手段に記憶されているCookie内に当該要求が属する手続き群と同一の手続き群を示す識別情報が含まれているか否かを判定するよう指示するステップ
上記指示を受けた前記Cookie内容判定手段が、前記同一の手続き群を示す識別情報が無いと判定した場合、計測評価機能部のCookie作成手段に対し、当該要求のあった時刻と当該要求が属する手続群を識別する識別情報とを前記一時記憶手段に記憶されているCookieに付加することでCookieの更新を行うよう指示を行い、又は、前記Cookieそのものが無いと判定した場合、計測評価機能部のCookie作成手段に対し、当該要求のあった時刻と当該要求が属する手続群を識別する識別情報とが含まれるCookieを新たに作成するよう指示を行うステップ
上記指示を受けた前記Cookie作成手段が更新した又は新たに作成したCookieを、前記書込手段に対して前記一時記憶手段に保存するよう指示を行うステップ
前記受信手段が手続サーバーから応答を受信した後に、計測評価機能部の応答内容判定手段が、前記手続サーバからの応答の中に予め定義された手続きの完了を示す情報があるか、否かを判定するステップ
前記応答内容判定手段が、完了情報があると判定した場合、計測評価機能部の読取手段に対し、前記一時記憶手段に一時記憶していたCookieを読取るよう指示を行うステップ
前記応答内容判定手段が、完了情報があると判定した場合、計測評価機能部の手続き種別判定手段が、完了した手続き種別を判定するステップ
計測評価機能部の計測データ抽出手段が前記一時記憶手段から読み出されたCookieの中から前記完了したものと判定された手続き種別と同一の手続き群に属する時刻情報を手続き群を示す識別情報に基づいて抽出したのち、計測評価機能部の所要時間算出手段に対し、当該時刻と手続きが完了した時刻との差を計算するよう指示を行うステップ
上記指示を受けた所要時間算定手段が、計測評価機能部のデータベース書込手段に対し、上記の計算結果に基づく情報をオンライン手続きの所要時間に対応するものとして計測評価機能部の記憶手段に保存するよう指示を行うステップ
【請求項３】
オンラインで提供される手続きサービスに関し、ネットワークにそれぞれ接続されるクライアント端末と手続サーバの間で通信される電子情報を、手続サーバ内に設けられる計測評価機能部が受信し、計測評価機能部は、クライアント端末からのオンライン手続きの要求を受けたときに、該計測評価機能部内で決定した時刻と当該要求が属する手続群を識別する識別情報とを含むCookieを作成し、又は手続き群毎にそられの時刻と識別情報をCookieに付加し、次のステップによりオンライン手続きの所要時間を計測することを特徴とするオンライン手続きにおける計測方法。
計測評価機能部の受信手段が、クライアント端末からのオンライン手続きの要求を受けたのち、計測評価機能部のCookie有無判定手段が当該要求にCookieが含まれているか、否かを判定するステップ
前記Cookie有無判定手段が、計測用Cookieがあると判定した場合、計測評価機能部の書込手段に対し、当該Cookieを計測評価機能部の一時記憶手段に書き込むよう指示を行うステップ
計測評価機能部の要求内容判定手段が、前記クライアント端末からのオンライン手続きの要求が、計測評価機能部に設けられるデータベースに予め定義された計測対象画面の一つに対して行われたものであるか否かを前記要求の対象となる画面のURLに基づいて判定するステップ
前記要求内容判定手段が、当該要求が計測対象画面の一つに対して行われたものであると判定した場合、Cookie内容判定手段に対し、前記一時記憶手段に記憶されているCookie内に当該要求が属する手続き群と同一の手続き群を示す識別情報が含まれているか否かを判定するよう指示するステップ
上記指示を受けた前記Cookie内容判定手段が、前記同一の手続き群を示す識別情報が無いと判定した場合、計測評価機能部のCookie作成手段に対し、当該要求のあった時刻と当該要求が属する手続群を識別する識別情報とを前記一時記憶手段に記憶されているCookieに付加することでCookieの更新を行うよう指示を行い、又は、前記Cookieそのものが無いと判定した場合、計測評価機能部のCookie作成手段に対し、当該要求のあった時刻と当該要求が属する手続群を識別する識別情報とが含まれるCookieを新たに作成するよう指示を行うステップ
上記指示を受けた前記Cookie作成手段が更新した又は新たに作成したCookieを、前記書込手段に対して前記一時記憶手段に保存するよう指示を行うステップ
前記受信手段が手続サーバからの応答を受信した後に、計測評価機能部の応答内容判定手段が、前記手続サーバからの応答の中に予め定義された手続きエラーの発生を示すエラー発生情報があるか、否かを判定するステップ
前記応答内容判定手段が、エラー発生情報があると判定した場合、計測評価機能部の読取手段に対し、前記一時記憶手段に一時記憶していたCookieを読取らせたのち、計測評価機能部のエラーカウント手段に対し、当該Cookieのエラー回数情報に「１」を加算するか、エラー回数情報が無い場合は「１」を作成するよう指示を行うステップ
上記指示を受けたエラーカウント手段が、エラー回数情報を作成したのち、前記Cookie作成手段に対し、当該エラー回数情報を含むCookieを作成するよう指示を行うステップ
上記指示を受けたCookie作成手段がCookieを作成したのち、前記書込手段に対し、当該Cookieを前記一時記憶手段に保存するよう指示を行うステップ
前記受信手段が手続サーバから応答を受信した後に、前記応答内容判定手段に対し、当該応答の中に予め定義された手続きの完了を示す情報があるか、否かを判定するよう指示を行うステップ
前記応答内容判定手段が、完了情報があると判定した場合、前記読取手段に対し、一時記憶していたCookieを読取るよう指示を行うステップ
前記応答内容判定手段が、完了情報があると判定した場合、計測評価機能部の手続き種別判定手段が、完了した手続き種別を判定するステップ
計測評価機能部の計測データ抽出手段が一時記憶手段から読み出されたCookieの中から判定された手続き種別と同一の手続き群に属する時刻情報を手続き群を示す識別情報に基づいて抽出するとともに、エラー回数情報を取り出したのち、計測評価機能部の所要時間算出手段に対し、当該時刻と手続きが完了した時刻との差をオンライン手続きの所要時間に対応したものとして計算するよう指示を行うステップ
上記指示を受けた所要時間算定手段が、計測評価機能部のデータベース書込手段に対し、上記の所要時間とエラー回数情報を含む情報を前記記憶手段に保存するよう指示を行うステップ
【請求項４】
オンラインで提供される手続きサービスに関し、ネットワークにそれぞれ接続されるクライアント端末と手続サーバの間で通信される電子情報を、手続サーバとは別に設けられ該手続サーバに対するプロキシ型サーバとして作動するネットワークに接続されている評価サーバ内に設けられる計測評価機能部が受信し、計測評価機能部は、クライアント端末からのオンライン手続きの要求を受けたときに、該計測評価機能部内で決定した時刻と当該要求が属する手続群を識別する識別情報とを含むCookieを作成し、又は手続き群毎にそられの時刻と識別情報をCookieに付加し、次のステップによりオンライン手続きの所要時間を計測することを特徴とするオンライン手続きにおける計測方法。
計測評価機能部の受信手段が、クライアント端末からのオンライン手続きの要求を受けたのち、計測評価機能部のCookie有無判定手段が当該要求にCookieが含まれているか、否かを判定するステップ
前記Cookie有無判定手段が、計測用Cookieがあると判定した場合、計測評価機能部の書込手段に対し、当該Cookieを計測評価機能部の一時記憶手段に書き込むよう指示を行うステップ
計測評価機能部の要求内容判定手段が、前記クライアント端末からのオンライン手続きの要求が、計測評価機能部に設けられるデータベースに予め定義された計測対象画面の一つに対して行われたものであるか否かを前記要求の対象となる画面のURLに基づいて判定するステップ
前記要求内容判定手段が、当該要求が計測対象画面の一つに対して行われたものであると判定した場合、Cookie内容判定手段に対し、前記一時記憶手段に記憶されているCookie内に当該要求が属する手続き群と同一の手続き群を示す識別情報が含まれているか否かを判定するよう指示するステップ
上記指示を受けた前記Cookie内容判定手段が、前記同一の手続き群を示す識別情報が無いと判定した場合、計測評価機能部のCookie作成手段に対し、当該要求のあった時刻と当該要求が属する手続群を識別する識別情報とを前記一時記憶手段に記憶されているCookieに付加することでCookieの更新を行うよう指示を行い、又は、前記Cookieそのものが無いと判定した場合、計測評価機能部のCookie作成手段に対し、当該要求のあった時刻と当該要求が属する手続群を識別する識別情報とが含まれるCookieを新たに作成するよう指示を行うステップ
上記指示を受けた前記Cookie作成手段が更新した又は新たに作成したCookieを、前記書込手段に対して前記一時記憶手段に保存するよう指示を行うステップ
前記受信手段が手続サーバからの応答を受信した後に、計測評価機能部の応答内容判定手段が、前記手続サーバからの応答の中に予め定義された手続きエラーの発生を示すエラー発生情報があるか、否かを判定するステップ
前記応答内容判定手段が、エラー発生情報があると判定した場合、計測評価機能部の読取手段に対し、前記一時記憶手段に一時記憶していたCookieを読取らせたのち、計測評価機能部のエラーカウント手段に対し、当該Cookieのエラー回数情報に「１」を加算するか、エラー回数情報が無い場合は「１」を作成するよう指示を行うステップ
上記指示を受けたエラーカウント手段が、エラー回数情報を作成したのち、前記Cookie作成手段に対し、当該エラー回数情報を含むCookieを作成するよう指示を行うステップ
上記指示を受けたCookie作成手段がCookieを作成したのち、前記書込手段に対し、当該Cookieを前記一時記憶手段に保存するよう指示を行うステップ
前記受信手段が手続サーバから応答を受信した後に、前記応答内容判定手段に対し、当該応答の中に予め定義された手続きの完了を示す情報があるか、否かを判定するよう指示を行うステップ
前記応答内容判定手段が、完了情報があると判定した場合、前記読取手段に対し、一時記憶していたCookieを読取るよう指示を行うステップ
前記応答内容判定手段が、完了情報があると判定した場合、計測評価機能部の手続き種別判定手段が、完了した手続き種別を判定するステップ
計測評価機能部の計測データ抽出手段が一時記憶手段から読み出されたCookieの中から判定された手続き種別と同一の手続き群に属する時刻情報を手続き群を示す識別情報に基づいて抽出するとともに、エラー回数情報を取り出したのち、計測評価機能部の所要時間算出手段に対し、当該時刻と手続きが完了した時刻との差をオンライン手続きの所要時間に対応したものとして計算するよう指示を行うステップ
上記指示を受けた所要時間算定手段が、計測評価機能部のデータベース書込手段に対し、上記の所要時間とエラー回数情報を含む情報を前記記憶手段に保存するよう指示を行うステップ
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、利用者が体感するオンライン手続きの操作性について、これを測定し、評価する方法に関するものである。
【背景技術】
【０００２】
オンライン手続きにおける操作性の良否は、実際に手続きに要した時間や手続きの成功率等に反映されることが知られている。（例えば、非特許文献１参照）
しかし、現在、所要時間や手続き成功率などソフトウエア等の操作性を評価するにあたって用いられる方法は、少人数によるモニターを用いた方式によるものであり、例えば、複数名集められた習熟度の異なる被験者の平均時間、平均エラー回数等を計測し、最も習熟した被験者の平均時間や平均エラー回数等のスコア（以下、「熟練者スコア」という）と比較することによって、システムの操作性を評価している。（例えば、特許文献１〜３参照）
一方、事業者（発注者）が、オンライン手続きサービスを外部委託者にアウトソーシングするにあたって、一般に発注者と受託者の間にサービス水準協定が締結されるが、その水準を構成する指標は、システム稼働率やレスポンスタイムなどに止まっており、発注者や利用者にとって最も重要な、システムそのもの操作性や使いやすさ、サービス品質そのものを問う指標はいまだない。
【非特許文献１】"Usability Engineering"Jakob Nielsen
【特許文献１】特開平7-325802号  「ユーザビリティ測定方法」
【特許文献２】特開平10-341号  「ユーザインターフェイス評価装置」
【特許文献３】特開平2001-44094号  「サービス管理システム」
【発明の開示】
【発明が解決しようとする課題】
【０００３】
情報システムのアウトソーシングにあたっては、従来、システム稼働率やレスポンスタイムなど機械的な性能をもってサービス水準を定義し、システムの品質を評価してきた。しかし、この方法では、システムを受託した者の努力と関心は、例えば「稼働率を９９，９９％にする」とか「レスポンスタイムを３％向上させる。」といった技術性能の向上に払われてしまい、システムの発注者、あるいはシステムの利用者が究極的に求めるサービスそのものを総合的に向上させるものではない。特に利用者にとっての「使いやすさ」や「わかりやすさ」、「快適さ」といった操作性にとって、最も重要な要素が省みられない傾向にある。
【０００４】
このような発注者と受託者の情報サービスに対する認識、目的意識の格差は、例えば、「システムの稼働率は極めて高いが、ユーザからは、わかりづらい、時間がかかるといった苦情が絶えない。」、「ユーザの登録エラーが頻繁に起こるため、ユーザ個々に修正の連絡や確認を頻繁に行う作業コストがかかり過ぎる。」、「あまりにユーザインターフェイスがひどいので、その改良を指示したところ、契約外と言われ、多額の追加費用を請求された。」などといったトラブル発生の原因となっている。
【０００５】
特に急速に進む電子行政サービスの分野では、行政の硬直的な調達制度や行政職員の経験不足などが相まって、このようなトラブルが多発するとともに、ややもすればユーザの使い勝手を無視したシステムが提供される傾向が見られる。
【０００６】
このように、情報システムのアウトソーシングにおいて最も重要なユーザにとってのサービス品質を確保、向上させるには、発注者と受託者の責任分担を明確にするとともに、システム操作性を評価する数値目標を設定し、サービス水準協定の主要指標と位置付けるなどの措置をとる必要がある。
【０００７】
そこで最大の問題となるのが、システムの操作性、具体的にはシステムの操作性を示すにあたって必要となる「所要時間」や「エラー回数」といった指標データをいかに計測し、数値化するか、ということになる。（当然ながら、操作性が優れていれば、手続きは短時間に終了し、かつ登録ミスが少ない。操作性を示す指標には、そのほかに「問い合わせ件数が少ない」、「ユーザの作業ストレスが少ない」などの指標が考えられるが、本発明では一般に計測評価困難と言われている上記２指標に着目した。）
しかし、従来、システム操作性の計測や評価は現実的には不可能とされてきた。それには次の２つの理由がある。
【０００８】
１  従来のモニター方式では、統計学的な信頼性を欠けるため。
【０００９】
従来、システムの操作性を評価するには、モニターによる観察、検証が行われてきた。これは、商品開発過程において、人間工学的な試験、分析により、問題点の発見とプロトタイプを改良することを目的として行われるものであるため、大量のデータを取得する必要がない。しかしながら、サービス水準協定等に求められる所要時間やエラー回数データは、そのデータが支払額を決定する場合があることから、統計学的な信頼性の高さが必要となる。かといって、大量のデータをモニター方式で集めるには膨大なコストが必要となり、例えば、５種類の手続きからなる10種類の手続き群を、モニター100 人が各３回テストを行うとすると、のべ１万5000回のテストが必要となる。テスト環境の設定も考え合わせると、これは現実的な数字とは言えない。
【００１０】
２  数値データを評価するために必要な基準値設定が困難なため。
【００１１】
一方、例え、所要時間やエラー回数を計測することができても、適切な比較基準を設定することができなければ目標値の設定や実績値との相対比較を行うことができない。つまり、アウトソーシング契約にあたって、あらかじめ発注者と受託者がサービス水準を合意することができないことになる。
【００１２】
例えば、行政の電子申請システムは数万種類あると言われているが、当然ながら、目標とする手続き所要時間も数万種類あることになる。通常、モニター方式では、基準値に熟練者の平均スコアを用いることが多いが、このような行政手続きに対し、そもそも数万種類ものモニター試験を行うこと自体が現実的ではない。このような熟練者スコアを用いるもう一つの問題点は、一般ユーザが熟練者レヴェルまで習熟する必要が全くないにも関わらず、発注者も受注者も、ユーザのスコアを高めるために、つい不必要な投資を行いがちになる、という点である。例えば、熟練者スコアを100 秒と設定した場合、もし、一般ユーザが150 秒で「十分満足できるインターフェイスだ」と判断したとしても、システム運営者はスコアを上げるため、言い換えればボーナスポイントを獲得するために、少しでも100 秒に近づけるためのありとあらゆる改良・工夫を行い、受益額の限界まで投資することとなろう。確かに、サービス品質は、ほぼ無限に向上し続けることとなるが、果たしてボーナス額に値するものかどうかは何人にとっても不明である。つまり過剰なる投資、過剰なるボーナスとなっても、無限に投資し続けることとなりかねない。
【００１３】
本発明は、以上の問題点の解決を図るものである。
【００１４】
すなわち、本発明の第１の目的は、モニター方式を用いることなく、原則、全ユーザの手続き所要時間や手続きエラー回数等を低コスト、低リスクで収集すること、さらに第２の目的は、過剰水準とならない適切な基準値を設定することである。
【００１５】
また、通常、上記仕組みを導入するには、手続きシステムそのものを改良するか、あるいは特別なアプリケーションをインストールする必要があるため、手続きシステムを管理する側に、改良コストや不具合リスクといった新たな負担をかけてしまうこととなる。したがって、本発明の第３の目的は、既存システムや運営者に新たな負担やリスクをかけることなく、上記目的を達成することにある。
【課題を解決するための手段】
【００１６】
上記目的を達成するため、本発明は、次の解決手段を有する。
【００１７】
（１）ネットワークで接続されたユーザ端末クライアントと手続きサーバの間で通信される電子情報を用いて、手続き開始時刻を記録する方法であり、その候補となる時刻情報を手続き群毎にCookieを用いて記録する点を特徴としている。
【００１８】
なお、ここで言う手続きとは、単に１画面で完結する手続きではなく、手続き画面（データ送信画面又はデータダウンロード画面）とそこに至るまでに必要なトップ画面、ナビゲーション画面、ヘルプ画面など手続きを誘導する画面群（以下「誘導画面」）から構成されるものである。したがって、計測を行う時間は、単なる１画面から１画面への遷移時間や応答時間ではなく、予め定義された複数の計測対象画面の一つを利用者が要求してから、０ないし複数の画面遷移を経て、利用者がデータを送信するか、データをダウンロードするなど所定の目的が達成されるまでに要する時間となる。ただし、データをダウンロードする場合は、手続きサーバからデータが送信され、クライアントに達するまでの時間、一般にダウンロード時間と呼ばれる時間は計測されない。しかし、当該時間はユーザ環境に大きく左右されるため、これを対象外とすることは適切と考えられよう
上記のような複雑に構成された画面群を複雑に遷移するユーザの動きに対応するとともに、評価を行うサーバの負荷を減らすため、以下の方策をとる。
【００１９】
１  全ての手続き画面を体系的に定義する。
【００２０】
計測対象画面は、手続き画面と誘導画面に大別され、誘導画面はトップ画面とナビゲーション画面、ヘルプ画面等からなる（図６）。
【００２１】
２  記録する時刻情報は、当初計測対象の要求時刻だけではなく、ユーザが複数の手続き群に跨って遷移することを前提とし、手続き群毎に最初にアクセスした時刻をすべて記録する。
【００２２】
３  評価に必要な計測データ（時刻情報、手続き群識別情報）はCookieに記録し、評価サーバとクライアント端末で管理することで手続きサーバには一切の負担をかけない。
【００２３】
４  上記のCookieに必要なデータを全て書き込むため、評価サーバは、常に最新Cookieだけを一時記憶すればよい。したがって、評価サーバには最小限の負担しかかからない。
【００２４】
本発明における「Cookie」とは、クライアント端末が手続きサーバに接続したときに手続きサーバのプログラムにより決められた情報であって、サーバ毎にクライアント端末に記憶される情報をいう。本発明においては、呼び名にかかわらず、上記の機能を持つ情報をすべて「Cookie」と定義する。典型的には、この「Cookie」に関する機能は、Internet Explorer(登録商標) やNetscape Navigator( 登録商標) のブラウザ( インターネットのWeb ページ閲覧ソフト) に標準的に設けられている。
【００２５】
なお、上記に定義したCookieのうち、典型的「Cookie」の特徴の一つは個体識別が要らない点である。すなわち、クライアントとサーバ間の一つの画面についての通信が終わった後、計測データ（時刻情報、手続き群識別情報）を保存したCookieはクライアントのブラウザに保存されるため、次の画面に対してクライアント- サーバ間通信が再び行なわれる際には、サーバは、単純にクライアントから送付されてくるCookie情報を利用するだけとなる。したがって、ひとつの通信内（一度の画面遷移内）では、クライアント、つまりCookieを送る相手が特定できるため、個体識別は不要となる。そのため、以下に述べる方法においては、個体識別方法を省略している。
【００２６】
（２）また、本発明の方法は、上記の（１）の方法に引き続き、手続き完了情報の受信を合図に、所要時間を算出する方法であり、Cookieと応答の内容をチェックすることで完了したかどうかを判断するとともに、refer を用いて、１又は複数の手続き開始時刻情報から最も適切な開始時刻を選択し、所要時間を算出する点を特徴としている
なお、本発明における「refer 」とは、要求又は応答情報の中に含まれる補助情報の一種であり、前画面情報を指す。クライアントのブラウザは、要求時にCookieとrefer をサーバに送る。したがって、サーバでは、クライアントから取得したCookieを参照することで、複数の計測データを知ることが出来、refer を参照することで、前記複数の計測データの中から、適切な計測データ、つまり、適切な開始時刻を抽出することができる。
【００２７】
（３）また、本発明の方法は、ネットワークで接続された端末クライアントと手続きサービスを行うサーバ間で通信される電子情報を用いて、手続き開始時刻とともに、操作性を示すもう一つの主要指標である入力エラー回数を同時期に計測する方法であり、Cookieを用いて開始時刻の候補となる時刻情報とエラー発生回数を記録する点を特徴としている。
【００２８】
（４）また、本発明の方法は、上記（３）に引き続き、手続きの完了を合図に、所要時間とエラー回数を決定する方法であり、Cookieを用いて、所要時間とエラー回数を同時に決定する点を特徴としている。
【００２９】
（５）また、本発明の方法は、上記（１）から（４）の方法、あるいはその他の方法を用いて収集された計測データとシステム操作性に関する満足度アンケートの調査結果を用いて評価基準値を作成する方法であり、計測データとは異なるタイミングで実施されたアンケート調査結果を同一の案件識別情報を用いて自動的に合成する点を特徴としている。
【００３０】
まず、時間やエラー回数等の指標は、その数値自体で操作性を評価することはできないため、比較対象となる基準値を設定し、実績値との対比を行う必要がある。
【００３１】
本方法では、上記データベースをもとに、利用者評価結果が存在する中から肯定的である案件の操作性指標を抽出し、例えばその平均値を求めることで、「操作性に対し肯定的と評価する利用者の平均スコア」を求める。この数値は、逆に言えば、「利用者個々が肯定的と評価できうる平均水準」であり、事業者や発注者にとって、過剰投資とならない、最適な水準と見なすことできるからである。これにより、事業者や発注者は何ら負担なく、最適な評価基準を自動的に決定することが可能となる。
【発明の効果】
【００３２】
本発明の効果は、あらゆる経済活動、国民生活に浸透しつつあるオンラインサービスの品質を利用者の視点に立って可視化、定量化することで、ユーザビリティの高いシステムサービスの提供を促すものである。
【００３３】
例えば、行政がシステム開発を発注する段階におけるシステムベンダー選びは、従来は金額や実績、システム稼働率等をもってしか評価できなかった。しかし、本発明に基づく指標を評価指標の一部に加えることで、システムベンダーを総合的かつ合理的に評価、選択できるようになるとともに、かつ運営段階においては、サービス水準協定に新たに当該指標を加えることで、受託者側が主体的にサービス品質向上努力を払うよう、強いインセンティブを働かせることができる。
【００３４】
さらに、情報サービス本来の品質を巡り、システムベンダー間の健全な競争を促し、情報システム産業の健全な発展に寄与することが期待できる。
【００３５】
特に、今後急速な進展が見こまれながらも、ユーザにサービスの利用選択権がほとんど無い電子行政サービス分野においては、本方法の導入により、サービス品質の劇的な向上とシステム予算の削減、引いては国民の利便性向上に大きく寄与するものと予想する。
【発明を実施するための最良の形態】
【００３６】
以下、本発明の実施にあたって、Web ブラウザを用いた最良の形態について図表を用いて説明する。
【００３７】
（０）
はじめにネットワーク構成について説明する。（図１）
本発明は、ネットワーク（101 ）で接続されたクライアント端末（102 ）とオンラインによる電子手続きサービスを提供するサーバ（以下、手続きサーバという。）（103 ）において、クライアント側と手続きサーバ側の間で通信されるデータをもとにプロキシ型評価サーバ（104 ）が操作性データを計測し、評価する方法である。
【００３８】
当該評価サーバは、手続きサーバとクライアント端末の間で通信されるデータを中継するいわゆるプロキシ機能部分（104-1 ）とそのデータをもとに所定の指標値を計測し、計算し、記憶する計測評価機能部分（104-2 ）からなる。このプロキシ型サーバを用いることで、多数のオンライン手続きサービスを１ケ所にて評価するASP サービスを可能とすることができる。
【００３９】
なお、上記のようにプロキシサーバを用いる方式のほかに、手続きサーバと共同動作する共同動作型評価サーバ（201 ）を設置する方式（図２）、直接、手続きサーバ内に計測評価機能を組み込み、評価機能埋め込み型手続きサーバ（301 ）とする方式（図３）も考えられる。
【００４０】
次に評価サーバにおける計測評価機能について説明する。（図４）
上記計測評価機能は、まず、プロキシ機能部分を介してデータを受信する受信手段（411 ）、そしてデータをプロキシ機能部分に送信する送信手段（412 ）を有する。
【００４１】
次に、予め計測に必要な定義を行うための定義手段（420 ）を有する。
【００４２】
次に、クライアントからの要求内容が予め定義された内容か否かを判定する要求内容判定手段（431 ）、上記要求に計測対象となるCookieが付いているか否かを判定するCookie有無判定手段（432 ）、上記Cookieの中に要求内容と同じ手続き群を示す識別情報があるか否かを判定するCookie内容判定手段（433 ）、新たにCookieを作成し、あるいは既存のCookieに新しい情報を追加・修正するためのCookie作成手段（434 ）、既存のCookieの中のエラー回数情報を取出し、１を加えるエラーカウント手段（435 ）、手続きサーバからの応答の中に、予め定義された手続き完了情報又はエラー発生情報等の情報があるか否かを判定する応答内容判定手段（436 ）、refer から、手続き画面情報を読取り、完了した手続き種別を判定する手続き種別判定手段（437 ）、一時記憶させたCookieから完了した手続きと同一手続き群に属する時刻情報を選択し、取り出すとともに、同じCookieからエラー回数情報を取り出す計測データ抽出手段（438 ）、上記の時刻と手続き完了時刻の差を計算する所要時間算出手段（439 ）を有する。
【００４３】
次に、一時記憶手段にCookie等を書き込む書込手段（441 ）、一時記憶手段からCookie等を読込む読取手段（442 ）、一時記憶手段に記憶されているCookie及びCookieそのものを削除する削除手段（443 ）、一時的に情報を記憶する一時記憶手段（444 ）を有する。なお、一時記憶手段に書きこむ、あるいは読み出すCookieとは、計測データ（時刻情報、エラー回数情報）及び識別情報（手続き識別情報、手続き群識別情報）を含む計測用Cookie指す。
【００４４】
次に、所定の時期に、操作性を示す計測データと、それとは異なる方法で収集されたアンケート結果を同一テーブルに合成する計測データ・アンケート結果合成手段（451 ）、上記アンケート結果が所定の定義により、肯定的か否かを判定し、同一の案件識別情報を有する計測データを抽出する肯定的計測データ抽出手段（452 ）、抽出された計測データの平均値（評価基準値）を計算する評価基準値計算手段（453 ）、上記評価基準値と全データの平均値の対比値を計算する評価値算定手段（454 ）を有する。
【００４５】
次に、記憶手段（データベース）に計測データ、計算データ、評価結果、定義内容等を書き込むデータベース書込手段（461 ）、記憶手段から上記情報を読込むデータベース読取手段（462 ）、情報を恒久的に記憶する記憶手段（データベース）（463 ）を有する。
【００４６】
さらに、処理案件を個別に識別するための情報を作成する案件識別情報作成手段（471 ）、完了メッセージとアンケートを同時に送信するため、完了メッセージデータとアンケートデータを合成する完了メッセージ・アンケート合成手段（472 ）を有する。
【００４７】
以上は、プロキシ型評価サーバが有する手段であるが、共同動作型サーバにおいては、全ての情報が手続きサーバと送受信することになり、計測評価機能内の構成はプロキシ型と同じである。しかしながら、手続きサーバ側に新たな改良、機能を追加する場合で、例えば、手続きの完了やエラーの発生を示す情報を評価サーバ側に送信する独自の手段を加えた場合は完了判定やエラー判定の定義がより簡素となる。また、完了した手続きを識別する情報を送信する独自の手段を加えた場合は、手続き種別判定手段（437 ）及び当該判定手段を伴うステップは不要となる。埋め込み型手続きサーバにおいても、同様である。
【００４８】
次に、具体的な画面構成例の上での遷移例を仮定し、どのような計測データとなるかについて説明する。（図５）
本事例は三段階の階層からなるWeb サイトである。
【００４９】
本図の右端列に位置する画面群は、ユーザが最終的にデータ登録等を行う画面、すなわち手続き画面（502 ）であり、左端及び中間に位置する画面がトップ画面、ナビゲーション画面、ヘルプ画面等のユーザを手続き画面に正確に導くための誘導画面（501 ）である。
【００５０】
さらに、本事例では、手続きを大きく３つに分類している。各々、手続き群A （510 ）、手続き群B （520 ）、手続き群C （530 ）とし、２〜5 種類の手続き画面で構成されている。
【００５１】
このWeb サイトにおいて、ユーザは次のように画面遷移したと仮定する。
【００５２】
まず、ユーザは、手続き群Ａのトップ画面A001（511 ）に10時25分に遷移し、A009を経て、A104で手続きを行うかに見えたが、いったん手続きを中断し、10時30分に手続き群B のトップ画面B001（521 ）に遷移した。その後、さらにA007、計測対象外画面と遷移し、最終的には、B103にて２度の入力エラーののち10時40分に手続きを完了（522 ）したとする。
【００５３】
遷移画面は、A001→A004→A104→B001→A007→計測対象外画面→B001→B005→B103→エラー画面→B103→エラー画面→B103→手続き完了メッセージ画面、である。
【００５４】
このような複雑な事例の場合、どの時点を手続き開始時刻とするかが問題となるが、最終的な手続きがB103である以上、B 群にはじめて遷移した時刻を手続き開始時刻と見なすのが妥当である。したがって、開始時刻はA001画面に遷移した「10時25分」ではなく、B001に遷移した「10時30分」（521 ）としなければならない。
【００５５】
したがって、本事例の場合、手続き完了時刻が「10時40分」であるから、所要時間は、その差10分となる。つまり、本事例の計測データは、「B103」の手続きに所要時間「10分」、エラー回数「２回」という結果になる。
【００５６】
続いて、定義内容について説明する。
【００５７】
本定義は、手続き全体の定義（例図６）と個別手続きの定義（例図７）からなる。
【００５８】
まず、手続き全体の定義については、関連性がある個々の手続き画面（613 ）を一つにまとめ、手続き群として識別情報（611 ）を付与する。当該手続き群には、開始時刻の計測対象とする計測対象画面（612 ）を定義しておく。なお、本計測対象には、手続き画面を含む。
【００５９】
次に、個別の手続き（画面）毎に、手続きの完了を判定するために必要な情報、例えば完了通知を示すURL やファイル名又は文字列（721 ）と、エラー発生を判定するために必要な情報、例えばエラー発生を示すURL やファイル名又は文字列（722 ）と、ユーザ評価判定手段がユーザからのアンケート回答結果を肯定的傾向と判定するための論理式（723 ）を定義する。（図７）
図７では、利用者満足度を−２から＋２の５段階で評価しており、「肯定的評価」については、プラス以上、すなわち「ＣＳ（利用者満足度）＞０」と定義している。
【００６０】
以上の前提に立って、具体的な計測評価方法について説明する。
【００６１】
（１）
図８は、手続き開始時刻を記録する方法であり、その候補となる時刻情報を手続き群毎にCookieを用いて記録する点を特徴としている。
【００６２】
まず、受信手段（411 ）がクライアントからの要求を受信（801 ）すると、Cookie有無判定手段（432 ）が、当該要求に計測用のCookieが含まれているか、否かを判定（802 ）する。計測用Cookieがあれば、書込手段（441 ）に対し、当該Cookieを一時記憶手段（444 ）に書き込む（803 ）よう指示を行う。
【００６３】
次に、要求内容判定手段（431 ）が、当該要求が計測対象画面の一つか否かを判断するため、あらかじめ定義されたものか否かを判定（804 ）する。計測対象ならば、Cookie内容判定手段（433 ）に対し、当該Cookie内に当該要求が属する手続き群と同一の識別情報が含まれているかどうかを判定する（805 ）よう指示を行う。
【００６４】
なお、上記では、受信後に、まずCookieの有無を判定したが、さらなる方法として、まず、計測対象か否かを判定したのち、Cookieの有無を判定する方法、各々平行処理する方法などが考えられる。
【００６５】
次に、Cookie内容判定手段（433 ）により、同一の識別情報が無かった場合（計測用Cookieそのものが無かった場合を含む）、その手続き群に遷移したのは初めてと判断されるため、新たな開始時刻を記録する必要がある。つまり、Cookie作成手段（434 ）に対し、サーバ内時計で決定した時刻と当該要求が属する手続き群を識別する情報（手続き群識別情報や手続き識別情報等の手続き群を識別可能な情報）をCookieに付加することによりCookieを更新する（計測用Cookieそのものが無かった場合はそれらの時刻と識別情報とを含むCookieを新たに作成する）（806 ）よう指示を行う。なお、上記の決定した時刻とは、クライアントからの要求を受信した時刻から、まさにCookieに時刻情報を作成する際の時刻まで考えられる。受信時刻を用いる場合は、計測対象の有無に関わらず、全ての受信時刻を記録しておく必要があるのは言うまでもない。
【００６６】
図５の事例では、手続き群A に初めて遷移したA001（511 ）の時点で、「A10 ：25：00」という情報がCookieで新規に作成され、さらにB001（521 ）に遷移した時点で、新たに「B10 ：30：00」が作成、追加されることになる。この時点では、ユーザが実施したい手続きは手続き群A なのか手続き群Ｂなのか明らかではない。なお、上記「A 」、「B 」は手続き群を識別するコードを示す。
【００６７】
Cookie作成手段（434 ）にて、新規か否かに関わらず、Cookieに時刻情報と識別情報を作成したあと、書込手段（441 ）に対して、上記Cookieを一時記憶手段（444 ）に書込み、記憶する（807 ）よう指示を行う。なお、Cookieは手続きが完了すると削除手段（443 ）によって削除される。また、ユーザがブラウザを閉じる、あるいは一定時間を経過するなどにより自動的に削除することも可能である。
【００６８】
このように作成されたCookieは評価サーバ（104 ）内に一時記憶されるため、手続きサーバ（103 ）に送られる（808 ）情報には上記Cookieは含まれない。
【００６９】
なお、手続きサーバ（103 ）からの応答があると、当該Cookieは読出され、当該応答に付けられて、クライアント（102 ）に返信される。これらのプロセスは、手続きが完了するまで繰り返される。
【００７０】
以上の方法により、手続き開始時刻となる候補情報をCookieで記録するわけだが、この方法の最大のメリットは、手続きサーバ（103 ）側への負荷がまったく無く、システムの改良も必要ない、という点とCookieに全ての情報を保有させるため、評価サーバ（104 ）側で一時記憶するデータは必要最小限となる点にある。
【００７１】
なお、以上は最も理想的なプロキシ型評価サーバ（104 ）による処理方法であるが、共同動作型サーバ（201 ）においては、全ての情報が手続きサーバ（103 ）と送受信されるだけで、処理方法はプロキシ型と同じである。同様に、埋め込み型手続きサーバ（301 ）においても同じである。但し、手続きサーバ（103 ）側に新たな改良、機能を追加する場合で、例えば、計測対象画面であることを示す情報を評価サーバ（104 ）側に送信する独自の手段を加えた場合は、実質的には要求内容判定手段が手続きサーバ（103 ）側にあることとなり、評価サーバ（104 ）内に当該手段を持たさないようにするなど、両者の中間的方法もある。   また、以上は、定義したCookieの中の「典型的なCookie」を用いた方法であるが、時刻情報とクライアントの個体識別情報をサーバ側に記憶し、Cookieにクライアント個体識別情報を保存するようにしても良い。このような構成であると、一つの画面の通信毎に、どのクライアントとの通信であるかをCookieから取得した個体識別情報とサーバに記憶した個体識別情報とにより認識することになる。
【００７２】
（２）
次に手続きの完了にともない、所要時間を算出する方法である。
【００７３】
図９は、（１） の方法に引き続き、手続きの完了を合図に、所要時間を決定する方法であり、Cookieと応答、refer を用いて、適切な手続き開始時刻を決定し、所要時間を算出する点を特徴としている。
【００７４】
受信手段（411 ）が手続きサーバ（103 ）から応答を受信する（901 ）と、応答内容判定手段（436 ）に対し、当該応答の中に予め定義された手続き完了情報があるか、否かを判定する（902 ）よう指示を行う。手続き完了情報とは、「手続きが無事終了しました。」といった完了しなければ表示されない手続き完了メッセージのファイル名やURL 、当該メッセージに含まれる「終了」という文字列などである。その定義方法については、手続き毎に定義する方法、手続き群毎に定義する方法、全手続き群に共通して定義する方法などケースバイケースで使い分けることが可能だが、本事例では手続き毎に定義する方法を想定した。
【００７５】
このような完了情報が無ければ、当該応答に計測用Cookieを付けて、あるいはCookieが無ければ、そのままでクライアント（102 ）側に応答を送信（909 ）することになる。しかし、応答内容判定手段（436 ）が、当該応答に完了情報を認めた場合、手続き種別判定手段（437 ）に対して、refer から手続き画面情報を読取り、手続き体系の定義（図６）に照らし、どの手続き種別かを判定する（903 ）よう指示を行う。
【００７６】
手続き種別判定手段（437 ）において、完了した手続きの種別及び識別情報が判定されたあとは、読取手段（442 ）に対して、一時記憶手段（444 ）から当該案件の計測用Cookieを読取（904 ）り、さらに計測データ抽出手段（439 ）に対して、読み取ったCookieから完了手続きと同一手続き群に属する時刻情報を選択し、取り出す（905 ）よう指示を行う。
【００７７】
図５の事例では、Cookieに記録された二つの時刻情報「A10 ：25：00」「B10 ：30：00」の中から、完了手続き「B103」と同じ手続き群識別情報を有する後者を選択することになる。なお、詳しい選択方法については、事例のように識別情報に一定の規則性（例では、前１文字は手続き群コード、後ろ３文字は個別コードと定義）をもたせ、特定の文字列（例では「Ｂ」）を有する時刻情報を選択する方法、あるいは予め定義された手続きコード体系（図6 ）を読み出し、完了手続き「Ｂ103 」がどの手続き群に属しているかを特定したのち、同一の手続き群コードを有する時刻情報を選択する、という方法などが考えられる。
【００７８】
計測データ抽出手段（438 ）において、開始時刻が抽出されたのちは、所要時間算手段（439 ）に対して、完了時刻との差を計算し、所要時間を算出する（906 ）よう指示を行う。事例では、開始時刻10：30：00と完了時刻10:40:00の差、すなわち所要時間は10分である。なお、ここで言う完了時刻とは、応答の受信時刻、応答内容判定手段（436 ）にて完了情報を検知した時刻、計測データ抽出手段（438 ）にて開始時刻を決定した時刻、まさに差引き計算を行う時刻などが考えられる。なお、応答の受信時刻を用いる場合は、手続きの完了、未完了に関わらず、全ての受信時刻を記録しておく必要があるのは言うまでもない。
【００７９】
所要時間を算出したのちは、データベース書込手段（461 ）に対して、当該所要時間、手続き種別コードのほか、案件識別情報作成手段（471 ）が作成した個々の処理案件を識別する情報（以下、「案件識別情報」という。）を記憶手段（463 ）に保存する（907 ）よう指示を行う。
【００８０】
手続き完了と同時に、あるいその後に、案件識別情報作成手段（471 ）は、上記の計測データに付与する案件識別情報を作成するとともに、操作性に関するユーザの満足度を調査するアンケート情報に付与する。付与する方法は、Cookieで行っても良いし、通常の情報形式でも良く、いづれにしても、回答結果に付随して当該案件識別情報が返信されることができれば良い。この案件識別情報が計測データとアンケート結果で共有されることにより、本来は不連続な行為であるデータ計測行為とアンケート行為を連続的に実施し、かつその計測結果とアンケート結果を関係させることができる。これによりのちに述べる評価基準値を作成することが可能となるほか、ユーザのスコアに応じたアンケートの選択、計測データと操作性満足度の関係性分析などが可能となる。
【００８１】
なお、案件識別情報は、評価サーバ（104 ）側で独自に作成、発行する方法以外に、手続きサーバ（103 ）から別途識別情報を得る方法などが考えられる。
【００８２】
記憶手段（463 ）への書込みが終了したのちは、削除手段（443 ）に対して、当該Cookieを削除する（908 ）よう指示し、これを削除する。なお、Cookieの削除は記憶手段に書き込むと同時であってもよい。
【００８３】
最後に完了メッセージ等の応答をクライアント側に送信（909 ）する。なお、応答のクライアント送信は、本事例では最後の段階であるが、完了情報が有ると判定したのちであっても良い。
【００８４】
また、上記のアンケート調査は、データ計測の直後に実施し、上記完了メッセージにアンケート調査情報と案件識別情報を加えたものを送信することが望ましい。そのため、完了メッセージ・アンケート合成手段（472 ）が、手続きサーバ（103 ）から手続き完了メッセージを受信したのち、当該完了メッセージにアンケート内容をメッセージ内容のあとに合成する。
【００８５】
こうすることで、１画面短縮することができるため、ユーザの時間コストを短縮し、結果、アンケートへの回答率を高めることができる効果がある。なお、案件識別情報は、先ほど述べたように当該アンケート情報の一部に加えても良いし、Cookieで送信しても良い。Cookieで送信する場合は、計測用Cookieを削除せず、これに案件識別情報を加えて利用し、削除行為はアンケート送信後としても良い。無論、新たなCookieを作成してもよい。なお、所定の時期に一斉にアンケート調査を実施しても良い。
【００８６】
以上は、電子申請手続きのように、ユーザがデータを送信する場合の手続き完了判定方法であるが、逆にユーザが電子申請書様式などのデータをダウンロードする場合の完了判定方法はというと、予め当該データファイル名を完了情報として１ないし複数定義しておき、これを応答内容判定手段（436 ）が検知する方法、あるいは別途、手続きサーバからの独自の完了メッセージを受信する方法が考えられる。その他の手順は同じである。
【００８７】
以上の方法により、手続き開始時刻となる候補情報をCookieで記録するわけだが、この方法の最大のメリットは、手続きサーバ側への負荷がまったく無く、システムの改良も必要ない、という点とCookieに全ての情報を保有させるため、評価サーバ側で一時記憶するデータは必要最小限となる点にある。
【００８８】
なお、以上は最も理想的なプロキシ型評価サーバ（104 ）による処理方法であるが、共同動作型サーバ（201 ）においては、全ての情報が手続きサーバ（103 ）と送受信されるだけで、処理方法はプロキシ型と同じである。同様に、埋め込み型手続きサーバ（301 ）においても同じである。但し、手続きサーバ（103 ）側に新たな改良、機能を追加する場合で、例えば、手続き完了を示す情報や完了手続き種別を示す情報を評価サーバ（104 ）側に送信する独自の手段を加えた場合は、実質的には応答内容判定手段や手続き種別判定手段が手続きサーバ側（103 ）にあることとなり、評価サーバ（104 ）内に当該手段を持たさないようにするなど、両者の中間的方法もある。
【００８９】
（３）
別の実施形態として、Cookieを用いて手続き開始時刻の候補となる時刻情報とエラー発生回数情報を記録する方法がある。この方法は、Cookieを用いて開始時刻の候補となる時刻情報とエラー発生回数を同時期に記録する点を特徴としている。したがって、フローチャートは図８と図９に相当するため、（１）との相違点のみを記述する。
【００９０】
第1 の違いは、Cookie作成手段（434 ）にて、新たなCookieに時刻情報と識別情報を作成する際にあわせて、エラー回数を示す初期値（例えば「０」や文字情報）を作成する（806 ）ことである。しかし、当該エラー回数初期値を作成することなく、エラー回数情報がCookie内に無いことをもって、別途手段がエラー回数を０回と判定する方法、あるいは計測データの集計時にエラー回数情報が空欄等である場合、これを０回と見なす方法などがある。
【００９１】
第２の違いは、以下に述べるエラー回数をカウント、記録する方法が付加される点である。（図10）
受信手段（411 ）が手続きサーバ（103 ）からの応答を受信（1001）したのち、応答内容判定手段（436 ）が、エラーが発生したかどうかを判断するため、応答中に予め定義されたエラー発生を示す情報（例えばURL やファイル名又は文字列）があるかどうかを判定する（1002）。ある場合、読取手段（442 ）に対して一時記憶手段（444 ）に一時記憶した当該案件の計測用Cookieを読み出す（1003）よう指示を行う。
【００９２】
次に、エラーカウント手段（435 ）が上記Cookieのエラー回数情報を取りだし、「１」を加算（1004）する。なお、エラー回数情報が数値でない初期値の場合はこれを「１」にする。続いて、Cookie作成手段（434 ）が新たなエラー回数情報をCookieに作成する（1005）。
【００９３】
なお、上記の作成されたCookieは、応答とともに、クライアント側に送信される。
【００９４】
（４）
次に手続きの完了にともない、所要時間とエラー回数を決定する方法がある。
【００９５】
この方法は、上記（３）の方法に引き続き、手続きの完了を合図に、所要時間とエラー回数を決定する方法であり、Cookieを用いて、所要時間とエラー回数を同時期に決定する点を特徴としている。したがって、フローチャートは図８、図９、図10に該当するため、（２）との相違点は、（３）の説明内容に加え、以下のとおりである。
【００９６】
計測データ抽出手段（438 ）がCookieから適切な時刻情報を選択、取出す際に、あわせて同一Cookieからエラー回数情報を取出す（905 ）こと、及びデータベース書込手段（461 ）が記憶手段（463 ）に所要時間を書きこむ際、あわせて取出されたエラー回数情報を記憶手段（463 ）に書き込む（907 ）ことである。
【００９７】
（５）
また、別の実施形態として、上記（１）から（４）の方法、あるいはその他の方法を用いて収集された計測データとシステム操作性に関するユーザの満足度アンケートの調査結果を用いて評価基準値を作成する方法がある。この方法は、異なるタイミングで作成される上記両データを合成するため、同一の案件識別情報を用いる点を特徴としている（図11の1101〜1105に対応）。あるいは、同一テーブルを合成せずに、別のテーブルとして作成・管理し、上記の案件識別情報を用いて、回答結果が満足傾向にある案件と同一の案件識別情報を有する計測データを抽出する点を特徴としている。
【００９８】
なお、ここで言う評価基準値とは、「操作性に肯定的なユーザの平均スコア」であり、従来の専門家等を用いた基準値に比較し、ユーザやシステム発注者にとって最も合理的水準であることは既述のとおりである。
【００９９】
受信手段（411 ）が案件識別情報を有するユーザからのシステム操作性に関するアンケート調査に対する回答データを受信（1101）すると、計測データ・アンケート結果合成手段（451 ）に対し、受信した回答データと同一の案件識別情報を記憶手段（463 ）から検索し、検索結果の案件に当該回答データをつけ加える（1102）よう指示を行う。なお、当該アンケート調査は、手続き完了メッセージとともに、あるいは手続き完了メッセージを送信する前又は後、あるいは同時にユーザに送信されたものであり、案件識別情報は評価サーバ側において、手続き完了時に付与されたものである。また、合成されたテーブル事例は図12のとおりである。
【０１００】
なお、この段階で同一の案件識別情報を検索せずに、異なるテーブルを別途作成し、評価基準値作成データを抽出する際に案件識別情報を検索し、同一識別情報を有する計測データを抽出する方法もある。
【０１０１】
次に、所定の時期（例えば、案件が発生する度でも良いし、月に１度でも良いし、年に１度でも良い）に、データベース読取手段（462 ）が、記憶手段（463 ）からユーザの評価結果を読取り（1103）、肯定的計測データ抽出手段（452 ）に対して、当該評価結果が予め定められた定義に照らして肯定的か否か判定し、肯定的案件の計測データを記憶手段（463 ）から抽出する（1104）よう指示を行う。例えば、図７のように「−２、−１、０、＋１、＋２」のような５段階評価で、肯定的であることの定義がCS（利用者満足度）＞０である場合、「＋１、＋２」が肯定的評価となり、当該評価の計測データを抽出することとなる。
【０１０２】
次に評価基準値計算手段（453 ）に対して、当該計測データの平均値を算出（1105）するよう指示を行う。なお、平均値の計算方法は、肯定的な案件の計測データ（時間又は回数等）を合計し、当該件数で除するだけでなく、上下一定率の値を排除するなど、標準的な統計処理方法を加えることを含む。
【０１０３】
あるいは、単純な平均値を求める方法以外に、アンケート結果に応じて計測データの件数比率やデータそのものに一定の重み付けを行う方法もある。例えば、最高評価である＋２が100 件あり、その平均値が120 秒で、次点評価である＋１が200 件あり、その平均値が140 秒であった場合を想定すると、
単純な平均値は、（120 ×100 ＋140 ×200 ）÷（100 ＋200 ）＝133 秒である。
【０１０４】
次に、評価に重み付けを行うため、次点評価に件数比率0.5 を乗じて補正した場合、
（120 ×100 ＋140 ×200 ×0.5 ）÷（100 ＋200 ×0.5 ）＝130 秒となる。
【０１０５】
また、同様に計測データの差に0.5 を乗じ、これを補正した場合、
[120×100 ＋｛140 −（140 ―120 ）×0.5 ｝×200]÷（100 ＋200 ）＝127 秒となる。無論、最高評価者のみの平均値（120 秒）を評価基準値とする方法もある。
【０１０６】
このように、補正率、補正のための計算式は多様であり、手続きの特徴やサービス水準協定締結にあたっての交渉経過により変化することとなる。
【０１０７】
（６）
また、他の実施形態として、（５）の方法で算出された評価基準値を用い、評価値を算出する方法がある。この方法は、平均実績値との対比値を求めることで、評価基準値からの乖離度を数値化する点に特徴がある。したがって、フローチャートは図11全てに相当する。
【０１０８】
評価基準値を求めたあと、評価値算定手段（454 ）が全体の平均スコア（全ユーザの合計値を当該件数で除した値）と評価基準値との対比値を求める(1106)。無論、全体平均スコアを求めるのは評価基準値を求めた（1105）後である必要はなく、その前でも構わない。なお、平均値の算定にあたっては、上下一定率の値を排除するなど、標準的な統計処理方法を加えることを含む。
【０１０９】
最後に、データベース書込手段（461 ）が、上記計算結果を記憶手段（463 ）に書込み、保存（1107）する。なお、評価値の事例は図13を参照。
【産業上の利用可能性】
【０１１０】
本発明は、国内外を問わず、顧客が存在するあらゆる情報システムサービスに適用可能である。
【０１１１】
その提供形態は、専用アプリケーションによる提供、専用アプリケーションを搭載した専用サーバの提供、プロキシサーバによるＡＳＰサービスによる展開等が想定され、さらには集約したデータを活用したアウトソーシングコンサルティングへの展開も期待できる。
【図面の簡単な説明】
【０１１２】
【図１】プロキシ型ネットワーク構成図である。
【図２】共同動作型ネットワーク構成図である。
【図３】埋込み型ネットワーク構成図である。
【図４】計測評価機能の構成である。
【図５】画面構成例と遷移例である。
【図６】手続き体系定義画面例である。
【図７】手続き詳細定義画面例である。
【図８】手続き開始時刻を記録する方法に関するフローチャートである。
【図９】手続きの完了を合図に計測データを決定する方法に関するフローチャートである。
【図１０】エラー発生回数を記録する方法に関するフローチャートである。
【図１１】評価基準値又は評価値を作成する方法に関するフローチャートである。
【図１２】計測データとユーザ評価データが合成されたテーブル例である。
【図１３】評価値例である。
【図１】
0004087410.tif 000002
【図２】
0004087410.tif 000003
【図３】
0004087410.tif 000004
【図４】
0004087410.tif 000005
【図５】
0004087410.tif 000006
【図６】
0004087410.tif 000007
【図７】
0004087410.tif 000008
【図８】
0004087410.tif 000009
【図９】
0004087410.tif 000010
【図１０】
0004087410.tif 000011
【図１１】
0004087410.tif 000012
【図１２】
0004087410.tif 000013
【図１３】
0004087410.tif 000014