JP4479343B2 - システム有用性調査の支援のためのプログラム、装置 - Google Patents

Description

本発明は、システムの有用性の調査のための技術に関し、特に調査のためのアンケート質問票の自動作成に関する。

利用者（ユーザ）が利用するシステムは、小は単一の機器・ソフトウエアから大は多くの機器やソフトウエアから構成される大規模システムに至るまでのどのようなシステムでも、利用者が利用する以上、利用者にとって使いやすいかどうかが重要な問題となる。また、個々の機能が使いやすくても、利用者達が必要とする機能が足りなければ、システム全体としての使いやすさは減じられるし、利用者達が使わない機能があれば、それは無駄であるばかりか、その機能が使う資源のために必要な機能のための資源が圧迫されるという問題も出てくる。このように、システム全体の有用性は、システムの使い勝手やシステムの機能の過不足性の面から評価することができる。

従来、システムの有用性の評価を行うには、ユーザモデリング、利用者の操作やそれに対するシステム側の応答などのログの分析、利用者に対するアンケート調査などを、多大な工数を掛けて実施しなければならなかった。

このようなシステム有用性の調査の一部としてのログの分析を支援するための技術として、特許文献１に示されるものが知られている。この従来装置では、対話型システムに対する入力を入力モニター部により監視して入力履歴を記録し、この入力に関連する対話型システムの出力を出力モニター部で監視して出力履歴に記録している。そして、この装置では、履歴参照指示部からの指示により所望の入力履歴を指示して画面表示させると共に、表示させた入力履歴に関連づけられた出力履歴を表示させることができる。

また、システム有用性の評価に関するものではないが、特許文献２には、対話型システムの入出力の監視を利用した装置として、特許文献２に示すものがある。この装置は、利用者に的確なタイミングでヘルプ情報を提示するアクティブ・ヘルプ装置を目指すものである。この装置では、対話モニタ部が利用者とシステムの間の入出力信号を監視、記録して対話履歴を更新し、画面停留実測・判定部が、対話履歴の更新のたびに、その対話履歴に基づいて、表示画面ごとの連続的な表示時間を算出し、表示画面毎の標準表示時間と比較することによって、利用者とシステムとの対話に異常な遅延や膠着が生じているか否かを評価する。そして、異常な遅延等が生じている場合、ヘルプ情報格納部からヘルプ情報を選択し、そのヘルプ情報をヘルプ画面出力部を介して利用者に提示する。

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

このように、システムの入力や出力のログを自動的に収集したり、利用者がそのログの分析しやすくするために対応する入力と出力を関連づけて表示したりする技術は従来から存在する。

しかしながら、システムの有用性評価は、ログ分析だけでは十分でない場合が多く、アンケート調査も併用される。ところが、従来、システム有用性評価のためのアンケート調査は、ログ分析等の他の情報収集・分析とは独立して行われていたので、いきおい無駄な質問項目や適切な選択肢のない質問項目を少なからず含んだアンケートが行われる傾向にあった。無駄な項目が多く含まれているとアンケート回答者の取組意欲を殺ぐことになり、また適切な選択肢がない項目が含まれていると回答者は無理に回答することになり、いずれにしてもアンケート結果の信頼性を低下させることに繋がりかねない。調査者がログ分析等の情報を見てアンケートの質問項目を絞り込んだり、回答の選択肢を調整したりするようにすれば、このような問題はかなり解消されるが、調査者の負担が大きいという問題がある。

本発明は、コンピュータシステムを、調査対象システムが提供する機能に対し利用者が行った操作を検知して、当該操作を行った利用者と特定する情報と当該操作の行われた時刻の情報とを少なくとも含む、当該操作についてのログデータを記録するログ記録手段、前記ログ記録手段により記録されたログデータを解析し、前記機能の利用状況を示す利用状況指標を求めるログ解析手段であって、前記機能の利用状況指標が所定の条件を満足する場合に、更に前記ログ記録手段に記録された各ログデータに含まれる、当該ログデータに係る操作を行った利用者を特定する情報と当該操作の行われた時刻の情報とに基づき、同一の利用者が行った当該機能の利用のための一連の操作における各操作の行われた時刻から、当該利用者が行った当該機能の利用のための前記一連の操作に要した操作時間を計算し、計算した各利用者による当該機能の利用のための当該一連の操作に要した操作時間の分散を計算し、計算した分散が分散しきい値より大きい場合に、前記機能の利用のための前記一連の操作に要した操作時間が操作時間しきい値より大きい利用者を特定するログ解析手段、前記調査対象システムの有用性に関するアンケート質問票データを生成する質問票生成手段であって、前記ログ解析手段により求められた前記機能の利用状況指標に基づきアンケート質問票データに組み込む質問項目を選択する質問票生成手段、前記ログ解析手段が計算した各利用者による当該機能の利用のための当該一連の操作に要した操作時間の分散が分散しきい値より大きい場合に、前記質問票生成手段が生成したアンケート質問票データを、前記機能の利用のための前記一連の操作に要した操作時間が操作時間しきい値より大きい利用者に提供する質問票提供手段、として機能させるためのプログラムを提供する。

本発明の好適な態様では、前記コンピュータシステムを、前記調査対象システムが提供する機能の利用状況指標についての条件ごとに該条件に対応する質問項目の情報を示した質問条件情報が登録されたデータベース、として更に機能させ、前記質問票生成手段は、前記ログ解析手段により求められた前記機能の利用状況指標が満たす条件が前記データベースにあれば、該条件に対応する質問項目をアンケート質問票データに組み込む質問項目として選択する。

更に好適な態様では、前記質問条件情報には、前記条件ごとに該条件に対応する質問項目の対象とする利用者を特定するための対象者情報が含まれ、前記質問票生成手段は、前記ログ解析手段により求められた前記機能の利用状況指標が満たす条件が前記データベースにあれば、該条件に対応する対象者情報に基づき、該条件に対応する質問項目の対象とする利用者を特定し、特定した利用者に対するアンケート質問票データとして該質問項目を含んだアンケート質問票データを生成する。

更に好適な態様では、前記データベースには、前記調査対象システムが提供する機能ごとに前記質問条件情報が登録され、前記ログ解析手段は、前記調査対象システムが提供する機能ごとにその利用状況指標を求め、前記質問票生成手段は、前記ログ解析手段が求めた各機能の利用状況指標と各機能についての質問条件情報とに基づき、利用者ごとに、該利用者を対象とする質問項目を集めたアンケート質問票データを生成する。

また本発明の別の好適な態様では、前記機能の利用状況指標は、該機能の利用者数及び利用頻度を含む。

また本発明の別の好適な態様では、前記質問票提供手段は、前記ログ解析手段が計算した前記分散が前記分散しきい値以下である場合には、前記質問票生成手段が生成したアンケート質問票データを、前記ログ記録手段に記録された前記ログデータから求められる前記機能を利用した利用者全員に提供する。

また本発明の別の好適な態様では、前記ログ解析手段は、前記機能の利用状況指標が所定の条件を満足する場合に、更に利用者のプロファイル情報により区別される利用者のグループごとに前記ログから該グループの該機能の利用状況を求め、前記質問票生成手段は、グループごとの利用状況の差の程度に応じ、質問項目の対象とする利用者を限定する。

以下、図面を参照して、本発明を実施するための最良の形態（以下「実施形態」と呼ぶ）について説明する。

図１は、本発明に係るシステム有用性調査支援装置の概略構成を説明するための図である。

図１において、調査支援装置１０は、調査対象システム２０の有用性を調査する際の支援を行う装置である。

ここで調査対象システム２０は、利用者に対して所定のサービスを提供するシステムであり、利用者が利用可能な１以上の機能を提供する。図示の例では、調査対象システム２０は、インターネット等のネットワーク３０を介し、利用者ＰＣ（パーソナルコンピュータ）４０を操作する各利用者にサービスを提供するサービス形態のシステムを示している。例えば、基幹業務システムはグループウエアなどがそのようなシステムの一例である。しかし、これは一例であり、調査支援装置１０が適用可能な調査対象システム２０の形態は特に限定されない。調査対象システム２０は、ハードウエアのシステムで、ソフトウエアのシステムでも、それら両者の組合せでもよいし、規模も問わない。

調査支援装置１０において、ログ記録部１０２は、調査対象システム２０に対する利用者からの操作及びその操作に対するシステム２０からの応答を監視し、操作指示や応答を検知すると、それを示すログデータを作成し、操作・応答ログ格納部１０４に格納する。操作及び応答の内容は、調査対象システム２０に対する入力及び出力の信号又はデータを監視することにより検知することができる。

個々の操作・応答のログデータには、当該操作・応答が行われた日時、当該操作を行った（したがって応答の対象である）利用者の識別情報、当該操作と応答の内容を示す識別情報が含まれる。例えば、「1/1 10:00 19415 Press B, Page B Open」が１つの操作・応答ログデータであり、これは１月１日１０時０分に("1/1 10:00")、利用者ＩＤ１９４１５の利用者が("19415")、調査対象システム２０の機能Ｂにアクセスし("Press B")、これに対して調査対象システム２０が機能Ｂの画面を利用者に提供（すなわち利用者ＰＣに画面表示）したこと("Page B Open")を示している。もちろんこれは一例であり、この他のデータ項目を含んでもよい。また、以上の例では操作とこれに対する応答とを１つのログデータに記述したが、これらを分けて記述してももちろんよい。

このようなログ記録部１０２の操作・応答の監視、及びログの記録の動作は、特許文献１に示される従来装置の場合と同様の仕組みで実現できる。

ログ解析部１０６は、操作ログ格納部１０４に格納されたログデータ群の解析を行う。ログ解析では、調査対象システム２０が提供する各機能の利用状況を示す利用状況指標を求める。利用状況指標には、例えば利用者達がその機能を利用した総回数（利用頻度）や、その機能を利用した利用者の総数（利用者数）などがある。解析により求められた利用状況指標は、アンケート質問票の作成に利用される。ここに示したのはあくまで一例であり、ログ解析の詳細な内容は後で改めて説明する。

利用者ＤＢ（データベース）１０８は、各利用者のプロファイル情報を登録したデータベースである。プロファイル情報には、例えば、利用者ＩＤ、氏名、性別、年齢、役職、利き手などの個人の特徴情報が含まれる。

質問ＤＢ１１４は、アンケート質問票に組み込む質問項目のデータが登録されるデータベースである。個々の質問項目のデータは、その質問項目が質問票に採用されるべき条件に対応づけて登録される。この条件は、調査対象システム２０の各機能に対する利用者達の利用状況についての条件として表現される。

図２に、質問ＤＢ１１４に登録されるデータ内容の一例を示す。図示例では、質問ＤＢ１１４の１つのレコードは、「機能」、「利用状況条件」、「質問項目情報」、「付随表示情報」、「対象者情報」を含んでいる。「機能」は、調査対象システム２０が提供する１以上の機能のうち、当該レコードに該当する機能を示す識別情報である。「利用状況条件」は、当該レコードに該当する利用状況指標についての条件を示すデータである。例えば図の１行目のレコードでは、利用状況条件が、利用頻度と利用者数に関する条件の形で規定されている。「質問項目情報」は、当該レコードに該当する質問項目の情報である。質問項目の情報は、質問文やそれに対する回答を受け付けるためのオブジェクトの情報などを含む。例えば、回答のためのオブジェクトは、例えば、回答の選択肢の選択を受け付けるチェックボックスやラジオボタン、或いは自由記入のための入力欄などである。アンケート質問票をウェブページのかたちで作成する場合、質問項目の情報は、例えば、ＨＴＭＬ(HyperText Markup Language)の記述、或いはそのようなＨＴＭＬ記述を生成するメソッドなどとなる。なお、図示のテーブルには、質問項目の情報としてそのような質問項目の情報の名称を示している。「付随表示情報」は、「質問項目情報」が示す質問項目に付随してアンケート質問票に示すべき情報である。例えば、機能についての説明を示したマニュアル情報などが、付随表示情報の一例である。付随表示情報には、いくつかの種類が存在するが、そのうちの機能の説明を示したマニュアル情報は、マニュアルＤＢ１１６に登録されている。また、操作・応答ログ格納部１０４に格納されたログデータから、ある個人のある機能の利用履歴の情報を付随表示情報として作成することもできる。「対象者情報」は、「質問項目情報」が示す質問項目を提示する対象となる利用者を特定するための情報である。言い換えれば、その質問項目の提示対象の利用者が満たすべき条件を規定した情報である。

図には、１つの機能についてのレコード群しか示していないが、質問ＤＢ１１４には、調査対象システム２０が提供する各機能について同様のレコードが登録されている。

すなわちこの装置１０では、システム２０の「機能」と、その「機能」についての利用状況指標が満足する「利用状況条件」との組合せにより、アンケート質問票に載せるべき「質問項目情報」及び「付随表示情報」が選択される。ある機能についての利用状況指標が、質問ＤＢ１１４に登録されている当該機能のどの「利用状況条件」にも該当しない場合は、アンケート質問票にはその機能についての質問項目が組み込まれないことになる。また、利用者ＤＢ１０８に登録された利用者のうち、その組合せに対応する「対象者情報」を満足する利用者が、その質問項目の対象として選ばれることになる。

アンケート処理部１１０は、アンケート処理のための各種処理を実行する手段であり、アンケート質問票を生成するための質問票生成部１１２を備えている。

この質問票生成部１１２は、ログ解析部１０６の解析により求められた各機能についての利用状況指標に該当する質問項目を質問ＤＢ１１４から求め、求められた１以上の質問項目を組み込んだアンケート質問票のデータを作成する。このとき、アンケート質問票に組み込む質問項目に付随する付随表示情報が質問ＤＢ１１４に登録されていれば、その付随表示情報をマニュアルＤＢ１１６のマニュアル情報や操作・応答ログ格納部１０４に格納されたログ情報から作成し、アンケート質問票に組み込む。アンケート質問票のデータは、例えばＨＴＭＬで記述されたウェブページとして作成することができる。ここで、複数の機能についての質問項目をまとめたアンケート質問票を作成する場合、各利用者ごとに、その利用者に対する質問項目をまとめた、カスタマイズされたアンケート質問票が作成される。これには「機能」と「利用状況条件」の組合せにより選択された各「質問項目」がそれぞれどの利用者向けのものなのかを「対象者情報」から判定し、この結果求められた質問項目と対象の利用者との組合せを、利用者ごとに整理することで、各利用者宛のアンケート質問票に組み込むべき質問項目群が特定できる。

アンケート処理部１１０は、質問票生成部１１２で作成されたアンケート質問票のデータを用いてアンケート調査を実行する。ウェブページを利用してアンケート調査を行う場合、アンケート処理部１１０は、質問票生成部１１２が生成したアンケート質問票のウェブページをウェブサーバに登録し、それらアンケート調査票のＵＲＬ(Uniform Resource Locator)を、例えば電子メールなどの形で、対象となる利用者宛に送信する。利用者は、そのＵＲＬを用いて利用者ＰＣ４０にてそのアンケート質問票のページを取得し、各質問項目に対する回答を入力した上で、入力結果をウェブサーバ宛に送信する。アンケート処理部１１０は、この入力結果を集計することで、アンケート結果をまとめる。

調査支援装置１０は、まとめたアンケート結果やログ解析の結果を画面表示することができ、その画面表示は、調査者が各機能の有用性、すなわち各機能の使い勝手や各機能が必要なのか否か、を判断する際の判断材料となる。

また、調査支援装置１０に、ログ解析結果やアンケート回答の集計結果に基づき、機能についての施策を提案する機能を設けることも好適である。例えば、ログ解析の結果、ある機能が余り使われていないことが分かり、アンケートの結果、利用者のほとんどがその機能を余り使いたいと思っていないことが分かれば、その機能は不要であると判断できる。そこで、調査支援装置１０は、ログ解析で利用頻度が所定のしきい値より少ないと判定した機能につき、その機能を使いたいかどうかを問うアンケートを利用者ＤＢ１０８に登録された全利用者に行い、その結果使いたいと回答した利用者が所定のしきい値より少なければ、その機能は不要である可能性が高いので削除した方がよい、等の施策を示すメッセージをアンケート結果などに加え表示する。なお、このような施策提案のためには、質問ＤＢ１１４と同様、施策内容と、その施策内容を提案に採用するための条件をデータベース化しておけばよい。施策内容を採用するための条件は、アンケートの集計結果に関する条件、或いはアンケート集計結果とログ解析結果についての条件として記述することができる。

次に、具体例を挙げて、本実施形態の調査支援装置１０の処理動作を説明する。

本実施形態の調査支援装置１０では、ログ記録部１０２が、調査対象システム２０に対する操作及び応答を常にモニタし、そのログを操作・応答ログ格納部１０４に記録している。そして、調査者が装置１０に対して調査の開始を指示すると、ログ解析部１０６が、まず操作・応答ログ格納部１０４のデータを解析して、各機能ごと、利用状況指標として、全体の利用頻度と利用者数を求める。機能の利用頻度は、その機能を含んだログデータの数を合計すればよい。これにより利用者全体における当該機能の利用頻度が求められる。また機能の利用者数は、その機能を示したログデータに現れる異なる利用者の数を合計すればよい。この合計では、同じ利用者が当該機能を複数回利用していたとしても、その利用者は１回のみカウントする。各機能の利用頻度と利用者数の組合せは、図３のチャート２００のように、利用頻度と利用者数をそれぞれ座標軸とした２次元座標にプロットすることができる。

典型的な例では、機能ごとの利用頻度と利用者数の組合せに従い、質問票生成部１１２がアンケート質問票を作成する。利用頻度と利用者数との組合せに応じて作成される質問票の例を図３〜図５に示す。

図３は、利用者数も利用頻度も共に少ない機能Ａ（図ではこの機能の名称を「タスクレポート」としてる）についての質問項目を示すアンケート質問票３００を示す図である。これは、図２に例示した質問ＤＢ１１４のデータ内容のうちの第１行目のレコードに対応する。「少ない」か否かを判定するためのしきい値として、利用者数及び利用頻度に対してそれぞれしきい値ｔ１，Ｔ１が定められている。利用者数がｔ１より少なく、かつ利用頻度がＴ１より少ない場合、このレコードの利用状況条件が満足されるので、このレコードが検索されることになる。図３では、チャート２００において斜線ハッチングを施した部分がその条件を満足する部分である。

しきい値の値は、調査者が決めればよい。以降の例で述べる他のしきい値も同様である。

この例のように機能の利用者数も利用頻度も共に少ない場合、それは機能自体が利用者達にあまり知られていないからかも知れないし、また利用者達はその機能を知っているが必要性を感じないからかもしれない。そこで、質問票生成部１１２は、その機能を知っているかどうかを確認するために、「認知度・期待度調査」（図２参照）のための質問項目３１０を組み込んだアンケート質問票３００を作成する。組み込むべき質問項目の情報は、機能とこの機能についての利用状況指標とに該当するレコードを質問ＤＢ１１４から検索することにより特定される。

質問票３００中の質問項目欄３１０には、質問文３１２と、その質問文に対する回答欄３１４とが示される。図示例では、回答欄３１４は、複数の選択肢から該当するものを１つ選択する形式のものであり、各選択肢に対しラジオボタン３１６が設けられている。質問票をウェブページとして作成する場合、この回答欄３１４の情報は、ＨＴＭＬにおける選択肢リストの記述方式に従って記述しておけばよい。複数選択可能な選択肢や、自由記入欄も、同様にＨＴＭＬに従って記述することができる。

この質問項目欄３１０には、複数の質問文３１２を組み込むこともできる。図示例では、質問項目欄３１０のなかに、当該機能を知っているかを問う質問Ｑ１（認知度の質問）に加え、知らない人に対する付加的な質問としてその機能に対する期待を尋ねる質問Ｑ２も含まれている。これら複数の質問からなる集合が、「利用者数がｔ１より少なく、かつ利用頻度がＴ１より少ない」という１つの利用状況条件に対する１つの質問項目を構成している。なお、１つの質問項目を構成する複数の質問は、例示のような主たる質問と付随する質問といった組合せだけでなく、独立した複数の質問の組合せでもよい。

また、質問ＤＢ１１４から検索されたレコードに「付随表示情報」が登録されている場合には、その付随表示情報３２０が質問票３００に組み込まれる。図示例では、対象である「タスクレポート」機能の説明用マニュアル文書がマニュアルＤＢ１１６から読み出され、質問票３００に組み込まれる。

このように図３に例示した質問票３００は、機能が利用者達に周知されていない可能性を調べるものなので、図２の例の第１行目のレコードの「対象者情報」に規定されるように、対象者は利用者全員となる。

図３に例示した質問票３００によるアンケートによれば、まず、当該機能Ａが余り使われていない理由が、利用者達がその機能Ａを知らないからなのかどうかを判断することができる。利用者達の多くが質問Ｑ１に対し「知っている」と回答した場合、機能Ａを知っているのに使っていない人が多いということになる。この場合、機能Ａがそもそも必要とされていない可能性が高くなる。したがって、調査支援装置１０は、機能Ａを削除するという施策を提案する。また、利用者達の多くが質問Ｑ１に「知らない」と回答した場合は、それら利用者達の期待度の質問Ｑ２に対する回答の分析が問題となる。質問Ｑ２に対し、「使いたい」と回答した人が多ければ、機能Ａの利用実績が少ないのは、単に機能Ａが知られていなかったからだということが分かる。この場合、機能Ａの便利な利用法を利用者達に紹介するという施策を装置１０から提案することもできる。また、質問Ｑ２に対し、「使いたくない」と回答した人が多い場合は、機能Ａがそもそも必要とされていない可能性が高いので、機能Ａを削除するという施策を装置１０から提案することが考えられる。

次に図４は、利用頻度は多いが利用者数は少ない機能Ｂ（図ではその機能名を「タスクレポート」としている）についての質問項目を示すアンケート質問票４００の例を示す。これは、図２に例示したデータのうち、第２行目のレコードに対応する。このレコードに示されるように、利用頻度がしきい値Ｔ２より多く、利用者数がしきい値ｔ２より小さいという条件が満足される場合、図４に示すようなアンケート質問票４００が作成される。

この例のように利用頻度は多いが利用者数は少ない機能は、少数の利用者が頻繁に使用している機能と捉えることができる。このような機能については、１つの方向として、頻繁に使っている利用者の利用目的や頻繁に利用する理由などを調べることで、この機能のセールスポイントを見つけて未利用者への宣伝に利用したり、この機能の改良の方向性を定めたりするのに役立てることが考えられる。そこで、このような場合、質問票生成部１１２は、「利用実態調査」のための質問項目欄４１０を含んだアンケート質問票４００を作成する。この例では、質問項目欄４１０には、当該機能の利用目的を尋ねる質問Ｑ１や当該機能の良い点（便利な点）を尋ねる質問Ｑ２など、当該機能の利用実態を問う１以上の質問４１２が含まれる。この例では、各質問４１２の回答欄には複数の選択肢が示されており、複数の選択肢を選択可能とするため、ラジオボタンではなくチェックボックス４１４が設けられている。また、選択肢に挙げられていない回答を記入するための自由記入欄４１６も設けられている。このように質問項目４１０に挙げるべき質問４１２と各選択肢の情報は、質問ＤＢ１１４に登録されており、これが読み出されて質問票４００に組み込まれる。

図４の例では、質問項目欄４１０に組み込む質問文や質問文の回答欄の内容（選択肢など）は、該質問項目の対象である機能の内容に関連したものなので、機能ごとに異なったものとなることが多い。利用目的や良い点を聞く質問など、機能に依らず共通した質問もあるが、選択肢については、機能ごとに個別内容となることが多い。例えば、「タスクレポート」という機能については図４に示したような選択肢になるのに対し、別の「文書登録」という機能については別の選択肢になるであろう。したがって、質問項目の内容は、図２に例示したごとく、機能ごとに別々に登録しておくことが望ましい。

なお、これに対し、図３の例のように機能を知っているかどうかを問う質問の場合、『「＊＊＊」機能を知っていますか』というように、機能名を示す「＊＊＊」の部分以外は機能に依らず共通の文章となり、選択肢の方も「知っている」及び「知らない」というように機能に依存しない。したがって、このようなものについては、質問ＤＢ１１４には、機能に依らず共通の質問文テンプレート及び選択肢情報を登録しておき、質問文テンプレートに当該機能の機能名を差し込むことで個別の質問文を生成するようにすることもできる。この場合、図２の質問ＤＢ１１４のデータ内容における「質問項目情報」には、共通の質問文テンプレート及び選択肢情報を指す情報を登録すればよい。

また、図２の例では、利用頻度がＴ２より多く利用者数がｔ２より少ない場合には、「利用者自身の利用履歴」を付随表示情報として質問票に組み込むことが規定されている。そこで、質問票生成部１１２は、操作・応答ログ格納部１０４のログデータを解析し、この質問票４００の対象である利用者の利用履歴チャート４２２を求め、このチャートを含んだ付随表示情報４２０を質問票４００に組み込む。利用履歴チャート４２２は、当該利用者が当該機能の利用回数の時系列変化を所定期間にわたって（図示例では過去６ヶ月）表示したものである。

利用者は、この利用履歴チャートを参照することで、自分の当該機能Ｂ「タスクレポート」の利用状況を知ることができる。これは、例えば質問項目欄４１０の各質問への回答に生かすことができる。例えば、質問Ｑ１は、機能「タスクレポート」の利用目的を問うものであるが、その選択肢の一つである「グループ月報作成」が利用者自身の目的に該当するかどうかを判断する際、利用履歴チャート４２２の利用パターンは参考になる。例えば、利用履歴チャート４２２から、ほぼ月末にこの機能の利用が多いことが分かれば、利用者はこの機能を月報作成に利用している可能性を考慮することができる。

このように、質問票４００は利用者個別の情報である利用履歴チャート４２２を含むので、質問票４００は利用者ごとの個別に生成することになる。質問票４００の対象とする利用者は、質問ＤＢ１１４の「対象者情報」に示されるように、当該機能Ｂを高い頻度で利用している利用者であり、これは各利用者の当該機能Ｂの利用頻度をしきい値と比較することで判別すればよい。この判別しきい値は、調査者が本装置１０に登録しておけばよい。

なお、１つの態様では、利用者の利用履歴のパターンに応じ、その利用者に対する質問票４００の質問項目欄４１０に載せる質問文を切り替えたり、質問文自体は同じでもその回答欄に載せる選択肢を切り替えたりすることも可能である。例えば、機能の利用目的を問う質問の選択肢としてどのようなものを回答欄に組み込むかを、利用履歴パターンに応じて自動決定することができる。すなわち、例えば、当該機能の利用が各月末に多いことが利用履歴のパターンから分かれば「月報作成」を選択肢に入れ、各週末に多ければ「週報作成」を選択肢に入れる、等といった切替を行う等である。

図４に例示した質問票４００によるアンケートによれば、機能Ｂを使う目的やその機能Ｂのセールスポイントを求めることができる。したがって、利用目的やセールスポイントを広く利用者達に宣伝する等の施策を提案することができる。

次に、図５の例を説明する。これは、利用者数が多く、利用頻度が少なくも多くもない場合のアンケート質問票５００の例である。これは、図２に例示したデータのうち第３行目のレコードに対応する。ここでの利用状況条件は、このレコードに示されるように、利用者数がｔ３より多く、利用頻度がＴ３〜Ｔ４の範囲にある、という条件である。

このように、利用者は多いのだが全体の利用頻度は伸び悩んでいる状況は、かなりの利用者達が当該機能を使ったことがあるにもかかわらず、その後その機能が利用者全体で見てそれほど頻繁に使われていないことであり、その原因としてその機能の使い勝手（使いやすさ）が悪いのではないかという可能性が考えられる。そこで、この場合には、図５に示すように、使い勝手についての質問を並べた質問項目欄５１０を含むアンケート質問票５００を作成する。この例では、対象である機能Ｃ「文書登録」が使いやすいかどうかを問う質問Ｑ１と、この質問で使いにくいと答えた人に対する追加の質問として、その機能の使い勝手の問題点を尋ねる質問Ｑ２が示されている。質問Ｑ１については、回答欄５１２は、使いやすいかどうかを「はい」か「いいえ」かで答える形式となっている。一方、質問Ｑ２の回答欄５１４には、この機能Ｃの使い勝手について想定される問題点が選択肢として列挙され、該当するものを選択（複数選択も可能）できるようになっている。

これら質問のうち、質問Ｑ１は、機能が使いやすいか否かを問うだけのものなので、機能名以外の質問文の文章と、選択肢は、機能に依らず共通化できる。一方、質問Ｑ２については、回答欄５１４に挙げる選択肢は機能に依るので、機能ごとに別途作成し、質問ＤＢ１１４に登録しておく。

また、質問票５００には、付随表示情報５２０として、当該機能Ｃのマニュアル情報が示される。これは、機能Ｃを余り多くは使っていない人が、その機能を余り使用していない原因がどこにあるかを考える際の参考のために提供したものである。図２のデータ内容例の第３行目も参照されたい。

このような質問票５００は、当該機能Ｃを使ったことのない人に送っても余り意味がないので、対象は機能Ｃの利用経験者に限定する（図２のデータ内容例の第３行目のレコード参照）。利用経験者は、操作・応答ログ格納部１０４のログデータの解析により求めることができる。

なお、このような使い勝手の問題は、慣れると使いやすくなってくる場合もあれば、何度使っても使いにくい場合もある。後者の場合、利用経験者皆が問題を感じていると考えられるので、上述のように利用経験者全員に質問票５００に回答してもらうことが好適である。一方前者の場合は、使い慣れたベテランは余り当該機能の使い勝手に問題を感じていない可能性が高い。したがって、機能Ｃの使い勝手を改善し、初心者段階でのつまずきを少なくするには、初心者段階で当該機能を利用しなくなった人の回答が重要である。そこで、前者の場合には、質問票５００の対象を当該機能Ｃの初心者に限定することも考えられる。

このように質問の対象範囲を利用経験者全員にするか初心者のみに限定するかは、各利用者が当該機能を利用するための操作に要した時間（操作時間と呼ぶ）のばらつきにより判定することができる。１つの機能を利用するには、一般に複数の操作を順にこなす必要がある。例えば「文書登録」機能の場合、メニューの選択等で「文書登録」機能を呼び出し、登録する文書を指定し、登録先のフォルダ等のような登録のためのパラメータを指定し、指定した文書を指定したパラメータに従って登録する旨の登録ボタンを押下する、という一連の操作が必要となる。機能を利用するためのユーザインタフェースが使いやすければ、それら一連の操作に要する操作時間は短くなると考えられる。このように、操作時間は、当該機能が使いやすいかどうかの判断指標となる。

そして、操作時間のばらつきが大きい場合、ベテランと初心者の分化が生じていると考えられるので、質問対象を初心者のみに限定する。一方、各人の機能Ｃの利用回数に差があるにもかかわらず操作時間のばらつきが小さい場合は、慣れてもそれほど使いやすくなっていないことを意味すると考えられるので、利用経験者全員に質問を行う。

このような判定のため、ログ解析部１０６は、ログデータから、各利用者が当該機能Ｃを利用した都度、その利用のための一連の操作に要した操作時間を計算する。そして、利用ごとの操作時間を、操作時間ごとに集計することで、操作時間ごとの利用の頻度を求める。図５のチャート２５０はこれを図式化したものである。図示の例では、操作時間のばらつきが大きく、操作時間ごとに整理した利用の回数の分布に２つのピークが現れている。操作時間が短い方のピーク近傍がベテランのものであり、長い方のピーク近傍が初心者のものと考えられる。このように明確にピークが分離する場合でなくても、操作時間のばらつきが大きければ、初心者とベテランの差があると考えることができる。

操作時間のばらつきの度合いは、各利用ごとの操作時間の分散で示すことができる。したがって、ログ解析部１０６は、操作時間の分散を計算し、その分散が所定のしきい値（これは調査者等が予め登録しておく）より小さければ、ベテランと初心者の差がないので、利用経験者全員に質問票５００を提供する。また、分散がしきい値より大きい場合には、初心者のみに質問票５００を提供する。この場合、例えば操作時間の平均値を求め、その平均値よりも平均操作時間が長い利用者を初心者と判定すればよい。利用者の平均操作時間は、その利用者が当該機能Ｃを利用した際の操作時間の平均である。なお、この例では、初心者を判定するしきい値として全利用者についての操作時間の平均値を用いたが、これは一例に過ぎない。操作時間が長い方から３０％をしきい値とするなど、他の決め方でしきい値を決めることもできる。

図５の質問票５００を用いてアンケートを行えば、機能Ｃを利用する上で利用者がつまずいている点を求め、それを調査者に提示することができる。

以上、図３〜図５を参照して、利用状況条件とそれに該当した場合のアンケート質問票の具体例を説明した。ただし、当該機能が提供され始めた当初は利用頻度自体が少なく、上に例示したようなログ解析及び質問票生成の処理を行っても意味がない場合が多い。したがって、上記の処理は、利用者達に提供され始めてからある程度の期間が経過した機能（これを判別するための期間のしきい値を本装置１０に登録しておけばよい）についてのみ行うようにすることも好適である。

図３〜図５の例では、１つの機能に関するアンケート質問票３００、４００、５００を例示したが、前述のように、各機能についての質問項目を列挙して１つのアンケート質問票を作成することもできる。この場合、各利用者ごとに、その利用者が該当する質問項目が選択され、アンケート質問票に組み込まれる。

以上説明したように、調査支援装置１０によれば、ログ解析により求めた調査対象システム２０の利用状況に基づき、アンケート質問票に組み込むべき質問項目を切り替えることができ、無駄な質問を減らすことができる。また、利用者ごとに、その利用者が該当する質問項目のみからなる質問票を作成できるので、この点からも無駄な質問を減らすことができる。このように無駄な質問の少ないアンケートにより、より信頼性の高いアンケート結果が得られるものと期待できる。

また、調査支援装置１０は、ログデータから機能の利用頻度と利用者数を求めるという大まかな解析を行い、その後、その結果に基づきアンケートを行ったり、あるいは更なるログ解析により操作時間の分布を求めたりなどという具合に、段階的に調査を進めていく。したがって、調査のための処理に無駄が少ない。

以上の実施形態は例示的なものであり、本発明の範囲内で様々な変形が可能である。

例えば、利用者数及び利用頻度の解析の後に、更に利用者のプロファイル情報を利用した解析を加え、それを反映したアンケートを行うことも可能である。この例を以下に示す。

この例では、ログ解析部１０６の解析で、ある機能の利用者数は多いが利用頻度はそれほど多くない（図５のケースに類似）ことが判明した場合、更にログ解析部１０６がログデータを解析して利用者の利き手別に利用頻度を集計する。そしてログ解析部１０６は、の集計結果から、右利きと左利きとで利用者１人当たりの利用回数に有意な差がないかを調べる。これには、右利きと左利きの間での１人当たりの利用回数の差を、所定のしきい値と比較すればよい。しきい値より多ければ、当該機能が一方の利き手の人にとって使いにくくなっている可能性がある。そこで、その利き手の人に、図５に示したのと同様の質問票を用いて使い勝手のアンケートを行えば、本当にその利き手の人に使いにくくなっているかどうかが確認できる。

ここでは、利き手に着目した解析を行ったが、この他にも年齢層別など、プロファイル情報から利用者達を様々にグループ分けすることができ、ログデータからそれらグループごとの利用状況（上述の利用回数に限らず、例えば操作時間など他のものでももちろんよい）を解析し、それらからグループごとでの差がないかを求めることができる。グループ間で差があれば、グループの特性によって当該機能の使い勝手に差がある可能性があるので、それを確認するアンケート質問票を作成すればよい。

以上の例では、ウェブを利用したオンラインでのアンケート調査を例にとって説明したが、本実施形態の仕組みは、紙のアンケート質問票でアンケート調査を行う場合にも、アンケート質問票をカスタマイズするのに利用できる。

以上に説明した調査支援装置１０は、典型的には、以上に説明した各機能モジュールの動作・処理を記述したプログラムを、コンピュータシステムに実行させることにより、実現することができる。

本発明に係るシステム調査支援装置の概略構成を説明するための図である。 質問ＤＢのデータ内容の一例を示す図である。 アンケート質問票の例を示す図である。 アンケート質問票の別の例を示す図である。 アンケート質問票の更に別の例を示す図である。

符号の説明

１０ 調査支援装置、２０ 調査対象システム、３０ ネットワーク、４０ 利用者ＰＣ、１０２ ログ記録部、１０４ 操作・応答ログ格納部、１０６ ログ解析部、１０８利用者ＤＢ、１１０ アンケート処理部、１１２ 質問票生成部、１１４ 質問ＤＢ、１１６ マニュアルＤＢ。

Claims (9)

1. コンピュータシステムを、
   調査対象システムが提供する機能に対し利用者が行った操作を検知して、当該操作を行った利用者と特定する情報と当該操作の行われた時刻の情報とを少なくとも含む、当該操作についてのログデータを記録するログ記録手段、
   前記ログ記録手段により記録されたログデータを解析し、前記機能の利用状況を示す利用状況指標を求めるログ解析手段であって、前記機能の利用状況指標が所定の条件を満足する場合に、更に前記ログ記録手段に記録された各ログデータに含まれる、当該ログデータに係る操作を行った利用者を特定する情報と当該操作の行われた時刻の情報とに基づき、同一の利用者が行った当該機能の利用のための一連の操作における各操作の行われた時刻から、当該利用者が行った当該機能の利用のための前記一連の操作に要した操作時間を計算し、計算した各利用者による当該機能の利用のための当該一連の操作に要した操作時間の分散を計算し、計算した分散が分散しきい値より大きい場合に、前記機能の利用のための前記一連の操作に要した操作時間が操作時間しきい値より大きい利用者を特定するログ解析手段、
   前記調査対象システムの有用性に関するアンケート質問票データを生成する質問票生成手段であって、前記ログ解析手段により求められた前記機能の利用状況指標に基づきアンケート質問票データに組み込む質問項目を選択する質問票生成手段、
   前記ログ解析手段が計算した各利用者による当該機能の利用のための当該一連の操作に要した操作時間の分散が分散しきい値より大きい場合に、前記質問票生成手段が生成したアンケート質問票データを、前記機能の利用のための前記一連の操作に要した操作時間が操作時間しきい値より大きい利用者に提供する質問票提供手段、
   として機能させるためのプログラム。
2. 前記コンピュータシステムを、
   前記調査対象システムが提供する機能の利用状況指標についての条件ごとに該条件に対応する質問項目の情報を示した質問条件情報が登録されたデータベース、
   として更に機能させ、
   前記質問票生成手段は、前記ログ解析手段により求められた前記機能の利用状況指標が満たす条件が前記データベースにあれば、該条件に対応する質問項目をアンケート質問票データに組み込む質問項目として選択する、
   ことを特徴とする請求項１記載のプログラム。
3. 前記質問条件情報には、前記条件ごとに該条件に対応する質問項目の対象とする利用者を特定するための対象者情報が含まれ、
   前記質問票生成手段は、前記ログ解析手段により求められた前記機能の利用状況指標が満たす条件が前記データベースにあれば、該条件に対応する対象者情報に基づき、該条件に対応する質問項目の対象とする利用者を特定し、特定した利用者に対するアンケート質問票データとして該質問項目を含んだアンケート質問票データを生成する、
   ことを特徴とする請求項２記載のプログラム。
4. 前記データベースには、前記調査対象システムが提供する機能ごとに前記質問条件情報が登録され、
   前記ログ解析手段は、前記調査対象システムが提供する機能ごとにその利用状況指標を求め、
   前記質問票生成手段は、前記ログ解析手段が求めた各機能の利用状況指標と各機能についての質問条件情報とに基づき、利用者ごとに、該利用者を対象とする質問項目を集めたアンケート質問票データを生成する、
   ことを特徴とする請求項３記載のプログラム。
5. 前記機能の利用状況指標は、該機能の利用者数及び利用頻度を含むことを特徴とする請求項１記載のプログラム。
6. 前記質問票提供手段は、前記ログ解析手段が計算した前記分散が前記分散しきい値以下である場合には、前記質問票生成手段が生成したアンケート質問票データを、前記ログ記録手段に記録された前記ログデータから求められる前記機能を利用した利用者全員に提供する、ことを特徴とする請求項１記載のプログラム。
7. 前記ログ解析手段は、前記機能の利用状況指標が所定の条件を満足する場合に、更に利用者のプロファイル情報により区別される利用者のグループごとに前記ログから該グループの該機能の利用状況を求め、
   前記質問票生成手段は、グループごとの利用状況の差の程度に応じ、質問項目の対象とする利用者を限定する、
   ことを特徴とする請求項１記載のプログラム。
8. 調査対象システムが提供する機能に対し利用者が行った操作を検知して、当該操作を行った利用者と特定する情報と当該操作の行われた時刻の情報とを少なくとも含む、当該操作についてのログデータを記録するログ記録手段と、
   前記ログ記録手段により記録されたログデータを解析し、前記機能の利用状況を示す利用状況指標を求めるログ解析手段であって、前記機能の利用状況指標が所定の条件を満足する場合に、更に前記ログ記録手段に記録された各ログデータに含まれる、当該ログデータに係る操作を行った利用者を特定する情報と当該操作の行われた時刻の情報とに基づき、同一の利用者が行った当該機能の利用のための一連の操作における各操作の行われた時刻から、当該利用者が行った当該機能の利用のための前記一連の操作に要した操作時間を計算し、計算した各利用者による当該機能の利用のための当該一連の操作に要した操作時間の分散を計算し、計算した分散が分散しきい値より大きい場合に、前記機能の利用のための前記一連の操作に要した操作時間が操作時間しきい値より大きい利用者を特定する、ログ解析手段と、
   前記調査対象システムの有用性に関するアンケート質問票データを生成する質問票生成手段であって、前記ログ解析手段により求められた前記機能の利用状況指標に基づきアンケート質問票データに組み込む質問項目を選択する質問票生成手段と、
   前記ログ解析手段が計算した各利用者による当該機能の利用のための当該一連の操作に要した操作時間の分散が分散しきい値より大きい場合に、前記質問票生成手段が生成したアンケート質問票データを、前記機能の利用のための前記一連の操作に要した操作時間が操作時間しきい値より大きい利用者に提供する質問票提供手段と、
   を備えるシステム有用性調査支援装置。
9. 前記質問票提供手段は、前記ログ解析手段が計算した前記分散が前記分散しきい値以下である場合には、前記質問票生成手段が生成したアンケート質問票データを、前記ログ記録手段に記録された前記ログデータから求められる前記機能を利用した利用者全員に提供する、ことを特徴とする請求項８記載のシステム有用性調査支援装置。

Images