(57)【要約】【課題】  本発明では、分析結果の性質に左右されることなく、ユーザの分析に対してより有用な次の分析操作を提案することを目的とする。【解決手段】  分析データを読み込む分析データ接続インタフェース部と、前記分析データのデータ項目毎にそれぞれの前記データ項目がどの属性であるかを分類するデータ分類判定ロジック部と、前記属性の情報と、次の分析操作と、次の分析操作をどの属性に対しておこなうかを特定する情報と、採点情報とを対応づけて記憶するユーザ分析採点データベースと、  ユーザの分析している属性の情報を前記ユーザ分析採点データベースに照合して、前記採点のより高い前記次の分析操作とその属性の情報を特定して、前記属性の情報に対応する前記データ項目と、前記次の分析操作を、次の分析操作の候補として表示するデータ分析実行部とを有する。【選択図】  図１
2015165352.tif 000002
【特許請求の範囲】
【請求項１】
分析操作をどの属性のデータ項目に行うかを特定する第一の属性の情報と、次の分析操作と、次の分析操作をどの属性のデータ項目に行うかを特定する第二の属性の情報と、採点情報とを対応づけて記憶するユーザ分析採点データベースと、
ユーザの分析しているデータ項目の属性の情報を前記ユーザ分析採点データベースに照合して、前記分析している属性の情報と一致する前記第一の属性情報に対応する前記採点情報が、より高い前記次の分析操作と前記第二の属性の情報を特定して、前記特定された次の分析操作と第二の属性情報に対応するデータ項目を、当該ユーザの次の分析操作の候補として表示するデータ分析実行部と
を有することを特徴とする分析候補表示装置。
【請求項２】
請求項１に記載する分析候補表示装置であって、
前記ユーザ分析採点データベースの前記第一の属性の情報が、
分析対象を特定のデータ項目で限定する場合のデータ項目の属性の情報である抽出軸の属性の情報と、グラフ化する場合に分析軸となるデータ項目の属性の情報である分析軸の属性の情報であり、
前記データ分析実行部が、
ユーザが分析している抽出軸の属性の情報と分析軸の属性の情報とを、前記ユーザ分析採点データベースに照合して、前記採点情報がより高い前記次の分析操作と前記第二の属性の情報を特定して、前記特定された次の分析操作と第二の属性情報に対応するデータ項目を、当該ユーザの次の分析操作の候補として表示する
ことを特徴とする分析候補表示装置。
【請求項３】
請求項１乃至請求項２のそのいずれか一項に記載の分析候補表示装置であって、
更に、
前記前記データ項目がどの属性であるかを分類するデータ分類データベースを有し、
前記データ分析実行部が、
前記第二の属性の情報を前記データ分類データベースに照合して、データ項目を特定することを
特徴とする分析候補表示装置。
【請求項４】
請求項１乃至請求項３のそのいずれか一項に記載の分析候補表示装置であって、
前記分析採点データベースが、
ユーザの分析の度に記録され採点されて記憶される
ことを特徴とする分析候補表示装置。
【請求項５】
分析操作をどの属性のデータ項目に行うかを特定する第一の属性の情報と、次の分析操作と、次の分析操作をどの属性のデータ項目に行うかを特定する第二の属性の情報と、採点情報とを対応づけてユーザ分析採点データベースに記憶するステップと、
ユーザの分析しているデータ項目の属性の情報を前記ユーザ分析採点データベースに照合して、前記分析している属性の情報と一致する前記第一の属性情報に対応する前記採点情報が、より高い前記次の分析操作と前記第二の属性の情報を特定して、前記特定された次の分析操作と第二の属性情報に対応するデータ項目を、当該ユーザの次の分析操作の候補として表示するステップと
を有することを特徴とする分析候補表示方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データを分析する場合に、分析手段の候補を提案する技術に関する。
【背景技術】
【０００２】
IT技術の発達に伴い、企業等において大量のデータを収集し分析する事で、潜在的な業務上の課題や改善点を可視化し、業務に活用する手法が一般化している。
【０００３】
データ分析の実行者は、収集したデータや外部から入手したデータを活用し、様々な分析軸や観点でデータの母集団を絞り込み、クロス集計やグラフ化を実施する。例えば、地域別の商品の売上傾向を分析する際は、初めは地方別の売上高を集計し、その中で売上高が高い地方において、店舗別、商品種別毎の売上高を集計する等と分析を進めていく。この分析を効率的に進める手法として、例えば特許文献１では、分析を自動的にシステムから提案する技術がある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１２−２３８２０７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１では、分析結果について評価し特徴量をもうけて、特徴量が所定条件を満たす分析結果を新たな分析処理の生成元の候補として選択する旨について開示されている。ここで特徴量とは、突出した値を有するような分析結果に対して高くつけられるものをいい、分析結果が特異な性質を示す場合に、その分析をより意味のある分析として判断する。それ故、本技術は、分析結果として特異な性質を示さない場合に分析候補を絞るには有用ではない。
【０００６】
本発明では、分析結果の性質に左右されることなく、ユーザの分析に対してより有用な次の分析操作を提案することを目的とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明は、分析データを読み込む分析データ接続インタフェース部と、前記分析データのデータ項目毎にそれぞれの前記データ項目がどの属性であるかを分類するデータ分類判定ロジック部と、前記属性の情報と、次の分析操作と、次の分析操作をどの属性に対しておこなうかを特定する情報と、採点情報とを対応づけて記憶するユーザ分析採点データベースと、ユーザの分析している属性の情報を前記ユーザ分析採点データベースに照合して、前記採点のより高い前記次の分析操作とその属性の情報を特定して、前記属性の情報に対応する前記データ項目と、前記次の分析操作を、次の分析操作の候補として表示するデータ分析実行部とを有する。
【発明の効果】
【０００８】
本発明によれば、ユーザの分析状況に合わせて、次に実施すべき分析操作を提案できる。
【図面の簡単な説明】
【０００９】
【図１】本発明の一実施形態に係る、分析候補表示装置の全体構成ブロック図である。
【図２】本発明の一実施形態に係る、分析システムサーバの機能構成の一例を示すブロック図である。
【図３】本発明の一実施形態に係る、ユーザ端末の構成の一例を示す図である。
【図４】本発明の一実施形態に係る、分析データの一例を示す図である。
【図５】本発明の一実施形態に係る、データ読込履歴データベースの一例を示す図である。
【図６】本発明の一実施形態に係る、データ分類データベースの一例を示す図である。
【図７】本発明の一実施形態に係る、データ分類判定データベースの一例を示す図である。
【図８】本発明の一実施形態に係る、ユーザ分析状況データベースの一例を示す図である。
【図９】本発明の一実施形態に係る、ユーザ分析採点データベースの一例を示す図である。
【図１０】本発明の一実施形態に係る、分析結果格納データベースの一例を示す図である。
【図１１】本発明の一実施形態に係る分析システムの、データ分類判定の処理フローの一例である。
【図１２】本発明の一実施形態に係る分析システムの、分析状態評価の処理フローの一例である。
【図１３】本発明の一実施形態に係る分析システムの、ユーザ分析提案実行の処理フローの一例である。
【発明を実施するための形態】
【００１０】
以下、本発明をその一実施形態に即して添付図面を参照しつつ説明する。
《分析候補表示装置の構成》
本発明の一実施形態に係る、分析候補表示装置（以下、適宜「本システム」と呼称する）の全体構成ブロック図を図１に示す。分析候補表示装置１０００は、データ分析を実行するユーザ端末２００とネットワークＮＷ/Ｉｎｔｅｒｎｅｔを介して接続可能に設けられて、情報処理システムのユーザ３００は各々の目的に基づきデータ分析業務を実施する際に分析候補表示装置１０００に接続する。この分析候補表示装置１０００は、データ分析を実行する企業や個人が設置、又は分析システムのサービスプロバイダからＮＷを介して提供を受けるものである。
【００１１】
本システムの構成については前述の図１及び図２〜図１０を参照して説明する。図２は本システムのシステムサーバの構成ブロック図、図３はシステムを利用するユーザ端末の構成ブロック図、図４〜図１０はシステムのデータベースの構成例を示す図である。
【００１２】
分析システムサーバ１００は、図２に示す様に、演算処理を行うＣＰＵ１１０と、処理プログラムや処理データの一時記憶、ユーザ端末２００から送信された分析２０００を格納する際に用いられるメモリ１２０と、ネットワークを介してユーザ端末２００、後述のデータ分類ＤＢ３０００、データ分類判定ＤＢ４０００、ユーザ分析状況ＤＢ５０００、ユーザ分析採点ＤＢ６０００、分析結果格納ＤＢ７０００とのデータ送受信機能等を備えたＩ／Ｏインタフェース１３０を備えるサーバコンピューターである。図示は略すが、分析システムサーバ１００には、適宜キーボードやマウス等の入力装置、ディスプレイ等の出力装置が接続される。
【００１３】
分析システムサーバ１００は、前述の処理プログラムを実行することによって実現される機能ブロックとして、ユーザ端末送受信部１４０、データ分析実行部１５０、グラフ生成部１６０、データベース制御部１７０、データ分析判定ロジック１８０、分析データ接続インタフェース部１９０を有する。
【００１４】
ユーザ端末送受信部１４０は、ネットワークＮＷを介して接続可能とされているユーザ端末２００との間でデータ送受信を行う。より具体的には、ユーザがユーザ端末２００にキーボード等の入力機器を通じて入力            したデータを受信し、他の機能ブロックへの転送処理などを行うと共に、他の機能ブロックからの処理結果をユーザ端末２００に対し送信する処理を行う。また、ユーザが分析データ２０００を分析対象として利用する際、ユーザ端末２００から分析システムサーバ１００にデータを転送する際の処理も行う。
【００１５】
データ分析実行部１５０、分析データ接続インタフェース部１６０は、本システムにおいてデータ分析を実行する機能ブロックである。分析データ接続インタフェース部１６０は、前述の処理によって分析システムサーバ１００に格納又は一時的に記憶された分析データ２０００とデータ分析実行部１５０とを接続し、データ集計等の分析を実行することを可能とする。データ分析実行部１５０は、ユーザ端末２００からの命令に基づき、分析データ接続インタフェース部１６０を介して分析データ２０００のデータを読み込み、データ集計等の分析を処理として実行する。
【００１６】
グラフ生成部１７０は、データ分析実行部１５０の分析結果を元に、折れ線や棒等のグラフを描画し、Ｉ／Ｏインタフェース１３０を介しユーザ端末２００に表示させる。
【００１７】
データ分類判定ロジック部１８０は、分析データ接続インタフェース部１６０を介して読み込まれたデータの各項目が、如何なる分類の情報の集合体であるかを判定し、必要に応じユーザに対しその分類を確認するものである。
【００１８】
データ項目の分類は、体系的かつ網羅的であるものとし、本システムにおいては一例として、６Ｗ２Ｈ又はＫｅｙ情報の９種の分類を用いる。６Ｗ２Ｈは「When（いつ）/Where（どこでどこに）/Who（誰が何が）/Whom（誰に何に）/What（何を）/Why（何故）/How to（どのように）/How much（どれくらい）」を意味する。例えば、読み込んだデータが「日付」に関するものであれば、その項目は「When」の分類とされる。分類を判定する処理の詳細については、図１１の処理フローで後述する。
【００１９】
データ分析状況判定・採点ロジック１８１は、ユーザがユーザ端末２００を通じて分析したデータ分析実行部１５０の状況を監視し、データベースの処理状況を判定するものである。
【００２０】
データベース制御部１９０は、データ分析実行部１５０、データ分類判定ロジック部１８０の結果、データ分類判定ロジック部１８０がデータ分類を判定した結果、データ分析状況判定・採点ロジック１８１がデータ分析状況を判定した結果、採点した結果等を各ＤＢに記憶させる処理を実行する。また、必要に応じロジックの分岐判定に利用するために各ＤＢからデータを読み込む。
【００２１】
次に、図３を参照して、本データ分析システム１００に接続可能とされているユーザ端末２００の構成について説明する。図３は、各ユーザ端末２００の構成ブロック図である。各ユーザ端末２００は、演算処理を行うＣＰＵ２１０と、処理プログラムや処理データの一時記憶に用いられるメモリ２２０と、ネットワークＮＷを介した分析候補表示装置との通信機能、通信に利用されるソフトウェアやウェブブラウザとのデータ送受信機能等を備えたＩ/Ｏインタフェース２３０を備えているコンピュータである。このユーザ端末２００には、適宜キーボードやマウス等の入力装置、ディスプレイ等の出力装置が接続される。
【００２２】
ユーザ３００は、何らかの目的を持ち本分析候補表示装置にユーザ端末２００を利用してアクセスし、分析対象のデータを分析システムサーバ１００にデータ転送を実施し、分析作業を実行する。ユーザ３００は特定の人物ではなく、企業の様々な部署の人物、また分析システム１０００がクラウドの形態を取って不特定多数のユーザに開放されている場合は、互いに認識する事の無い不特定多数のユーザを指す。
【００２３】
次に、図４を参照して、分析データ２０００について説明する。分析データ２０００は、ユーザ３００が分析対象として分析システムサーバ１００に転送するデータである。例えば、システム障害の発生状況について分析するユーザは、図４での例の様に２００１〜２００４の様な項目に障害情報が格納されたデータを、分析データ２０００として分析システムサーバ１００に転送する。この際、データ形式に特に指定は無く、また分析データ２０００が何らかのデータベースの形態をとっており、分析システム１０００と接続可能であったり、データ自体はユーザ端末２００上に存在しており、必要に応じ分析候補表示装置１０００がユーザ端末２００にアクセスする形態を取っていてもよい。ただし、分析データ２０００についての最低限必要な条件として、ヘッダー情報（図４では”障害番号”“発生日付”などのラベル）を有する事、表の形態で分析システム１０００が認識可能である様に、データ内に何らかのセパレータや改行コード、特定のデータフォーマットにより記録されている事が挙げられる。
【００２４】
図４で示す分析データ２０００の一例を詳細に説明する。この分析データは障害管理システム上に記録される、障害についてのデータであり、データカラム２００１「障害番号」には一意のキーとなるＩＤがシステムにより自動で付与されている。カラム２００２「発生日付」は障害が発生した日付として、障害管理データを記録したオペレータが入力する情報であり、同様にカラム２００３「発生元システム」２００４「原因」についても、オペレータにより障害情報が入力されたものをイメージしている。その他項目として、障害情報の詳細な内容や解決日時、起票から解決にかかった時間等の情報がデータとして記録されており、本分析候補表示装置においてデータ分析対象として読み込まれることが想定されるが、割愛する。
【００２５】
次に、図５を参照して、データ読込履歴データベース２１００について説明する。データ読込履歴データベース２１００は、図４で示した分析データ２０００を本システムが読み込んだ際に、読み込んだデータの概要を記録し、次回読み込んだ際に既知のデータであるか否かを識別するための履歴管理領域である。例えば「C:Proglam Files\IT-Cost\11」に格納されていた３００KBの分析データ「TroubleData.xlsx」を読み込んだ際は、図５の１レコード目の情報が格納される。データが本システムに読み込まれた際、システムは一意のIDを採番し、データID２１０１に格納する。データ種別２１０２には、読み込んだデータの種別を格納する。読込データがExcelファイルの場合は、ここには“Excel”が格納されることとなる。データサイズ２０１３、データ格納場所/接続先２０１４、データ(テーブル)名２０１５には、それぞれ読み込んだデータの容量、データの所在、データの名称が格納されることとなる。
【００２６】
次に、図６を参照して、データ分類データベース３０００について説明する。データ分類データベース３０００は、分析データ２０００の各項目が、それぞれどの様な属性か判定した結果を蓄積したものである。格納されるレコードは、分析データ２０００の各項目（例：項目２００１“障害番号”や項目２００２“発生日付”等）1件に対し1レコードが作成され、それら項目が何の属性か、特定の体系に基づき分類されている。本事例では、各項目を６Ｗ２Ｈ又はＫｅｙ情報の９種に分類しているが、これは他の分類体系であっても問題ない。尚、６Ｗ２Ｈは「When（いつ）/Where（どこでどこに）/Who（誰が何が）/Whom（誰に何に）/What（何を）/Why（何故）/How to（どのように）/How much（どれくらい）」を意味する。分類の目的は、例えば、データ分析の過程を「障害発生日付と発生元システムで集計する」といった生データでの分析と捉えるのでなく、「ＷＨＥＮ分類の項目とＷＨＥＲＥ分類の項目で集計する」等一般化する事により、ユーザがどの様な分析を実施したのかを統計するためである。データ分類データベース３０００が他に有する項目については、分析データ２０００を読み込んだ際に付与したＩＤ（データＩＤ３００１）や、そのデータ名称（データ名３００２）、データ上の項目の順番（項目ＩＤ３００３）が挙げられる。データID３００１、データ名３００２は、それぞれ図５のデータID２１０１、データ（テーブル）名２１０５と同一の項目を指す。図４の分析データが本システムに読み込まれた場合を例に各項目を説明する。図４の分析データが読み込まれると、図５の１レコード目に示す様にデータID”Dt00001”が付与され、データ（テーブル）名”障害情報”が読み込まれる。図４に示す様に、この障害データは１つ目に”障害番号”、２つ目に”発生日付”、3つ目に”発生元システム”という項目を有している。この「何のデータが、何項目にどの様な情報を有しているか」という情報が、図６のデータ分類データベース３０００に、１レコードずつ登録されることとなる。よって、図６の１レコード目に示す様に、データID”Dt00001”、データ名”障害情報”、項目ID（項目の表示順番が）”1”には、項目名”障害番号”という項目が存在し、そのデータ分類は”Key”情報である、と記録される。同様に、２レコード目にはデータID”Dt00001”、データ名”障害情報”、項目ID（項目の表示順番が）”2”に、項目名”発生日付”という項目が存在し、そのデータ分類は”Date”情報である、と記録される。データ分類を判定する処理の詳細については、図１１データ分類判定処理フローの説明で後述する。尚、このデータ分類データベース３０００の記録項目の配列は前期の順に従う必要は無く、また管理の必要に応じて記録項目を加除することが可能である。
【００２７】
次に、図７を参照して、データ分類判定データベース４０００について説明する。データ分類判定データベースは、分析データ２０００の各項目が、どのデータ分類に属するかを分析候補表示装置１０００が自動判定するためのキーワードデータベースである。分析データとして利用される情報について、事前に想定されるデータパターンやデータの集合をデータベースとして保持しておくことで、分析候補表示装置１０００が自らデータ分類の判定を行う事が可能となる。データ分類の判定手法としては、分析データ２０００のデータパターンを調査するパターン検索や、含まれるデータをサンプル抽出し、突合せする事により判定するサンプル調査がある。データ分類判定データベース４０００は、図７に示す様に、それらデータの判定手法やデータのパターン、そのパターンに該当した際のデータ分類を記録項目として保持している。判定ID４００１は、データ分類判定データの一意のIDである。判定手法４００２は、データ分類判定を実行する手法の種別を格納しておく。判定手法詳細４００３は、判定手法の詳細を格納しておく。内容４００４は、判定を実際に実行する場合のデータパターンやサンプルデータを格納しておく。データ分類４００４は、このデータ分類判定に合致した際、判定対象のデータ項目のデータ分類が何であるかを格納しておく。これらデータは、本システムの提供者が予め登録しておき、どの様な判定処理を実行するかプログラミングする前提となる。実際の利用例を示すと、例えば図４に示した分析データ２０００の「発生日付」に記録されているデータは、「2013/4/1、」「2013/4/11」といった日付データの集合である。そこからサンプル抽出されたデータ「2013/4/1 2013/4/11 2013/4/21」というデータ群を、図７のデータ分類判定データベースと突合せするとする。図7の１レコード目で示す判定ID「pTime0001」のデータ分類判定データは、判定手法４００２に示す様にデータ分類をパターンで判定する。pTime001は、内容４００４、データ分類４００５に示されている通り”XXXX/XX/XX”と、「３つの数字データがセパレータ”/”で区切られている」場合、データ分類が”WHEN”であると判定するデータ分類判定パターンである。サンプル抽出されたデータ群「2013/4/1 2013/4/11 2013/4/21」はこの条件に該当するため、データ分類は”WHEN”であると判定されるに至ることとなる。一方、仮に図７の５レコード目に示されるTime001_1で判定が実行されたとする。その場合、このデータ分類判定手法は”サンプル”であるため、サンプル抽出されたデータ群「2013/4/1,2013/4/11,2013/4/21」に、データ分類判定データが含まれるか突合せを実施する。Time001_1の内容は”1月”なので、データ群に該当のデータは存在しない。次のTime001_2の”2月”で突合せを実行しても存在しない。連番であるTime001_1からTime001_12までを実行しても、「XX月」というデータは存在しないため、このデータ分類判定は失敗した事となる。この様に、データ分類判定データベースに含まれるパターンを順番に、合致するまで突合せ処理を実行する。分類判定手法は任意でその他のパターンや突合せ手法を用いてもよいものとする。
【００２８】
次に、図８を参照してユーザ分析状況データベース５０００について説明する。ユーザ分析状況データベースは、ユーザ３００が何のデータを、どのデータ分類の項目を軸に集計・分析しているかという状態を蓄積するデータベースである。ID５００１は、ユーザ分析状況の一意のIDであり、本分析システムにより自動的に付与される項番である。データID５００２は、分析対象データ２０００に対し、システムが付与したデータIDであり、２１０１、３００１と同一の項目を指す。抽出軸１(５００３)は、データ集計の際の抽出軸の項目の、データ分類種別を格納する。抽出軸２(５００４)も同様である。例えば、図４で例として示した障害情報を分析対象として、「障害が発生した年度毎、発生元システム毎」にデータを集計するとする。その場合、抽出軸１は「障害が発生した年度」の分類種別”ＷＨＥＮ”が、抽出軸２には「発生元システム」のデータ種別”ＷＨＥＲＥ”が記録されることとなる。X軸６００４、Y軸６００５はデータ集計の軸のデータ分類が格納される。例えば、「原因別の障害件数」を集計する場合、X軸には「原因」のデータ分類である”ＷＨＹ”が、Y軸には「障害件数数」のデータ分類である”Ｈｏｗ Ｍｕｃｈ”が記録されることとなる。また、これらのデータ分析(集計)は実際には一度に実行されるのではなく、１アクション毎に実行される。例えば上記の分析の例を１アクション毎に説明すると、まず障害情報を「年度毎」で抽出し、次に「発生元システム毎」で抽出、「X軸として原因」を指定、「Ｙ軸として障害の件数」を指定し、最後に「分析結果を記録」する事とする。その場合のデータ分析状況の登録の過程を示したのが、図８に例として示されている１〜４レコードである。上記に示した障害情報を「年度毎」で抽出のアクションの段階では、図５のデータレコードはまだ1つしか登録されておらず、記録されている情報も５００１〜５００７までのデータ項目である。「発生元システム毎」で抽出のアクションを実行した際、障害情報を「年度毎」で抽出のアクションから「発生元システム毎」で抽出のアクションを実行するまでにかかった時間60sが、「次のアクションまでの時間（５００８）に登録され、「次のアクション（５００９）」に、”抽出軸２を追加した”事を示す”Add Ex2”が登録される。「発生元システム毎」で抽出の処理で抽出字句２に追加された「発生元システム」の分類は“ＷＨＥＲＥ”なので、「分類（５０１０）」には”ＷＨＥＲＥ”が登録される。また、「発生元システム毎」で抽出の処理と同時に、図５の「発生元システム毎」で抽出レコード目のデータも登録される。これも障害情報を「年度毎」で抽出のアクションの際と同様、この時点ではデータ項目５００１〜５００７までの情報しか登録されていない。以降、「Ｙ軸として障害の件数」を指定の処理まで同様に、アクションが進む毎にデータの書き換えと新規登録が実行される。そして「分析結果を記録」で「分析結果が保存」された場合は、一連のデータ分析状況データに対し、「保存フラグ(５０１１)」に”1”が保存される。この様にデータ管理を実行する事により、逐一実行されるユーザの操作を、分析の進捗の観点で体系的に保存する事が可能である。尚、これらの記録項目の配列は前期��順に従う必要は無く、また管理の必要に応じて記録項目を加除することが可能である。
【００２９】
次に、図９を参照してユーザ分析採点データベース６０００について説明する。ユーザ分析採点データベースは、ユーザ分析状況データベース５０００に記録されたデータを元に、ある分析状況下において、ユーザによって実行された次のアクションが有効であったかどうかを採点した結果を蓄積するデータベースである。例えば、図９のＩＤ１のデータでは、「ＷＨＥＮ」項目毎にデータを集計する際、「ＷＨＥＲＥ」項目をＸ軸において分析する事は採点３（有効である）と記録されている。また、アクション６００６にはAdd XつまりＸ軸において、分類６００７のＷＨＥＲＥ項目で分析をすることを意味している。本実施例ではアクション６００６としてＸ軸や、Ｙ軸で分析することを示す情報を記憶しているが、これに限定されるものではなく、次の分析のアクション（分析操作）を示す情報であれば何でもよい。例えば、抽出軸を選択するアクション等のアクションを記憶することが考えられる。採点の基準については後述の処理フローにて説明するが、採点の基準及び採点の尺度（１/２/３等の定量値、又は高中低等の定性値）については前述の通りでなくてもよいものとする。
【００３０】
ここで抽出軸とは、分析するデータをある年度にしぼるような、分析対象となるデータの範囲を決めることをいう。また、Ｘ軸、Ｙ軸とは、絞られたデータをグラフ化して分析する場合の軸をいう。本実施例ではまず、抽出軸を設定してから、Ｘ軸、Ｙ軸を設定して分析しているがこれに限定されるものではなく、抽出軸の設定なしに、Ｘ軸、Ｙ軸を設定して分析することも考えられる。その場合、ユーザ分析状況データベースの抽出軸には何も記録されないことになる。
【００３１】
次に、図１０を参照して分析結果格納データベース７０００について説明する。分析結果格納データベースは、ユーザが分析した結果を蓄積するデータベースである。図１０の２行目に示されている例を取り上げて説明する。この例では、保存ユーザ（７００８）“田中正”は、保存日付（７００７）“2013/10/1”に、データＩＤ（７００２）“a0001”を対象に分析を実施した事を示す。抽出軸１（７００３）〜Ｙ軸（７００６）に示される数値は、対象となるデータの記録項目内、何番目の項目を分析に利用したかを示す。
＜本実施形態による分析候補表示装置１０００の処理内容  データ分類判定＞
次に、本システムでデータ分類判定を実施する際の処理内容の例を、図１１を参照して説明する。図１１は本システム１０００によるデータ分類判定の処理フローを示す図である。
【００３２】
図１１を参照すると、ユーザ３００により分析対象のデータ２０００を指定された本システム１０００は、そのデータ内容を読み込み、データ種別、データサイズ、データ格納場所/接続先、データ(テーブル)名を読み込み、データ読込履歴データベースを検索する（ステップ８０００）。検索結果が存在せず、過去に読み込んだ事が無いデータの場合（ステップ８０００でＮｏ）、読み込んだデータに対し一意のデータＩＤを付与しデータ履歴データベースに読み込んだ情報を記録する（ステップ８００１）。その後、データが有する記録項目の数をカウントする（ステップ８００２）。以後は、読み込んだデータのデータ(記録)項目の１番目から最大項目数まで、データ分類の判定処理を繰り返す。
【００３３】
まず、データ分類判定ロジック部１８０は、データ名とデータ項目名をキーに、データ分類データベース３０００を検索する（ステップ８００３）。例えば、読み込んだ分析データのデータ名が障害情報となっており、項目名に相当する分析データのカラム（ヘッダー情報）が障害番号、発生日時、発生元システム、原因といった場合を想定しており、その場合、データ名とヘッダー情報をキーとしてデータ分類データベースのデータ名、項目名を検索し、合致するデータが存在する場合は（ステップ８００４でＹｅｓ）、そのデータ分類は既に登録済であるため、データ分類の登録は不用である。一方、検索に合致するデータが存在しない場合（ステップ８００４でＮｏ）は、項目名をキーにデータ分類データベース３０００を検索する(ステップ８００６)。同名の項目が存在し（ステップ８００７でＹｅｓ）、かつ同名の項目が１データ存在する場合（ステップ８００８でＹｅｓ）、先述の処理と同様過去と同様の分類を付与し、データ分類データベース３０００に登録する（ステップ８００５）。合致するデータが複数存在する場合（ステップ８００８でＮｏ）は、その中で最も件数が高い分類を付与し登録する(ステップ８００９)。一方、同名項目のデータが全く存在しない場合（ステップ８００７でＮｏ）は、データを詳細に確認しその分類分けを実施する。該当項目が保有するデータのパターン検索、サンプル抽出しデータ分類ＤＢ４０００との突合せ処理を実施する（ステップ８０１０）。パターンの一致が見られる場合（ステップ８０１１）、該当パターンの分類を付与し、データ分類データベース３０００に登録する（ステップ８０１２）。パターンの一致が見られなかった場合（ステップ８０１１でＮｏ）、ユーザ３００に対し該当項目のデータ分類が何であるか確認させる画面を表示させる（ステップ８０１３）。ユーザは質問に対しデータ分類を選択回答し（ステップ８０１４）、データ分類判定ロジック部１８０は、回答の分類を以ってデータ分類データベースを登録する（ステップ８０１５）。
【００３４】
以上でデータ分類判定の処理は完了し、データ項目数分の判定が完了した場合（ステップ８０１６でＹｅｓ）は、処理終了となる。まだ未判定のデータ項目が存在する場合（ステップ８０１６でＮｏ）、判定対象の項目を一つずらし（ステップ８０１７）、再度判定ロジックを繰り返す。データ分類データベース３０００は蓄積され、被参照データの増加に伴い、データ分類判定ロジック部の精度も向上することとなる。また、上記でデータ分類判定ロジック部についての一実施例を説明したが、例えばデータ読込元がDBであれば、Dateタイプの項目については「When」項目である事が自明であり、判定可能である等、その他状況に合わせ判定ロジックについて適宜調整が可能である。
【００３５】
実際の例を用いて、例えば、図４で示される障害情報が読み込まれた際の一連のフローを説明する。図４のデータを読み込むと、データが「Ｅｘｃｅｌ」形式であり、データサイズが「５００ＫＢ」、データ格納場所が「C:Proglam Files\IT-Cost\15」、データファイル名が「エラー情報.xlsx」であったとする。この情報で図５のデータ読込履歴データベースを検索すると、合致する情報は見つからない（ステップ８０００でＮｏ）。そのため、本システムはデータＩＤ「Ｄｔ００００４」を付与し、図５の４レコード目にデータを登録する（ステップ８００１）。次にデータ項目数をカウントし、この場合例えば２００１〜２００４の4項目が存在したとする(ステップ８００２)。よってその後８００３〜８０１６の処理を4回繰り返すこととなる。データ名「エラー情報」1項目目の項目名「障害番号」で図６のデータ分類データベース３０００を検索する（ステップ８００３）この時、検索に一致するデータは無いため（ステップ８００４でNo）、項目名「障害番号」でデータ検索を実施する。すると、図６の1レコード目、９レコード目のデータが一致する（ステップ８００７でYes）（ステップ８００８でNo）。データのデータ分類は共に「Key」であるため、「データID：Dt00004、データ名：エラー情報、項目ID：１、項目名：障害番号、データ分類：WHEN」で図６にデータ分類を登録する（ステップ８００９）。現在の処理は(x=1)であり、全項目数の4と異なるため（ステップ８０１６No）、xに1を加算し（ステップ８０１７）、2項目目の処理を以後進める（ステップ８００３〜ステップ８０１６）。上記の通り、処理を進める。
＜本実施形態による分析候補表示装置１０００の処理内容  データ分析状況評価＞
次に、本システムでデータ分析状況評価を実施する際の処理内容の例を、図１２を参照して説明する。図１２は本システム１０００によるデータ分類判定の処理フローを示す図である。ここでは分析状況の判定および採点について説明する。
【００３６】
図１２を参照の通り、本システムのデータ分類状況判定・採点ロジック部１８１は、まずユーザがデータ集計の軸を追加すると(ステップ９０００)、その前に登録した分析状況データが存在する場合は、「次のアクション」情報を追記すると共に、新しくデータ分析状況データベースに現在の分析状況データを登録する（ステップ９００１）。ここで、ユーザが（ステップ９０００）で追加したデータ集計の軸を取り消す場合（ステップ９００２でＹｅｓ）、かつ軸の追加から取り消すまでの時間が一定の時間以内である場合（ステップ９００３でＹｅｓ）は、（ステップ９００１）で新規登録されたデータ分析状況を削除し、追記した「次のアクション」情報も削除する（ステップ９００４）。これは、一定時間以内にアクションを取り消す場合は誤操作である可能性が高く、分析の評価判定に対し不要な操作とみなせるためである。一方、軸の追加から取り消すまでの時間が一定の時間以上である場合（ステップ９００３でＮｏ）は、何らかの意図を持って分析を実行したが、無意味な結果しか得られなかったという事のため、（ステップ９０００）で実施したデータ集計軸の追加を実施する事について採点「１」としてユーザ分析採点データベースにデータを登録する（ステップ９００５）。
【００３７】
ユーザが（ステップ９０００）での分析軸の追加を取り消さず（ステップ９００２でＮｏ）、更に分析を終了せずに（ステップ９００６でＮｏ）データ集計の軸を追加した場合（ステップ９０００）は、上記までの説明したフローを再度繰り返す（ステップ９０００〜ステップ９００６）。一方、分析を終了する場合（ステップ９００６でＹｅｓ）、かつ分析結果を登録して終了する場合（ステップ９００７でＹｅｓ）は、有益なデータ分析が実行できたと見なし、それまでに登録したデータ分析状況データに対し「保存フラグ」を付与し採点「３」としてユーザ分析採点ＤＢに登録を実行する（ステップ９００８）。分析結果を保存せず終了する場合（ステップ９００７でＮｏ）は、分析から何らかの示唆を受け分析を進めたものの、結果については有効でなかったとみなせるため、採点「２」としてユーザ分析採点ＤＢに登録を実行する（ステップ９００９）。
【００３８】
上記で説明したフローに沿い、ユーザのデータ分析状況を蓄積、かつその時々でのアクションの有効性に対し評価した結果を蓄積する事により、如何なる状況下でどの様な分析を実行する事が有用性が高いのか、というデータを収集する。尚、採点の評価軸や処理の流れについてはあくまで一例であり、必ずしも前述の通りである必要は無く、適宜調整可能である。
【００３９】
実際の例を用いて、例えば、図４で示される障害情報(データＩＤはDt00001であるとする)の読込/データ分類判定が終了した後の、データ分析の一連のフローを説明する。ユーザ３００がまず図４の「発生日付」を用いてデータを抽出する事とする（ステップ９０００）。障害情報のデータから２０１３年４月について、データ分析したい場合に、ユーザは障害情報データ全体から２０１３年４月のデータだけを抽出する。本装置ではユーザの分析操作を逐次監視しているので、２０１３年４月という発生日付のデータ項目でデータ抽出をしたことを検知する。その場合、２０１３年４月はデータ項目「発生日時」の情報なので、「発生日付」のデータ分類（データの属性の情報）を、データ分類データベースに照合して特定する。データ分類データベースにない場合は、先に説明したようにデータ分類判定データベースにより判定する。「発生日付」のデータ分類は”ＷＨＥＮ”であるため、ＷＨＥＮ項目でデータ抽出を実行したとしてデータ分析状況はユーザ分析状況データベースの1レコード目の通り登録される（ステップ９００１）。
【００４０】
ここで、データの抽出の操作をおこなった場合には、ユーザ分析状況データベース５０００の抽出軸のカラムにデータ分類が記憶される。また、分析データからグラフを作成する場合、例えば、発生元システムをＸ軸、原因をＹ軸としてグラフを作成した場合は、ユーザ分析状況データベースのＸ軸のカラム５００５に発生元システムのデータ種別、Ｙ軸のカラム５００６に原因のデータ種別が記憶される。
【００４１】
但し、その時点では５００８〜５０１０の項目はまだデータ記録がされていない。その後、軸の追加の削除は実施せず（ステップ９００２でＮｏ）、分析を続け（ステップ９００６でＮｏ）、更に項目「発生元システム」でデータを抽出すると（ステップ９０００）、図８の2レコード目の通り(５００１〜５００７項目までの)データが登録され、更に1レコード目のデータの５００８〜５００９の項目についても、「次のアクションとして60秒後に抽出軸2にＷＨＥＲＥ項目を追加した」事が追記される（ステップ９００１）。この処理を取り消さず（ステップ９００２でＮｏ）、更にX軸に項目「原因」を追加する（ステップ９０００）。すると、図８の３レコード目の通り(５００１〜５００７項目までの)データが登録され、更に２レコード目のデータの５００８〜５００９の項目についても、「次のアクションとして60秒後にX軸ＷＨＹ項目を追加した」事が追記される（ステップ９００１）。その後、軸の削除は実施せず（ステップ９００２でＮｏ）、分析を終了することとし（ステップ９００６でＹｅｓ）、分析結果を登録する（ステップ９００７でＹｅｓ）。その場合、図８の１〜３レコード目のデータに対し、保存フラグ５０１１に”1”が追記保存され、図８の１〜３レコード目のデータは図９の１〜３レコード目に示すデータとして登録されることとなる（ステップ９００８）。
【００４２】
ここで、次のアクションとは、分析操作を特定する情報のことをいい、例えばグラフ作成の分析操作によりＸ軸に発生原因システムとして特定する操作をすると、Ｘ軸を特定した操作を意味するAdd Xという情報と、その操作の対象となるデータ項目のデータ種別の情報、ここでは発生原因システムのデータ種別のＷＨＥＲＥの情報が記憶されることになる。この分析操作を特定する情報は、Ｘ軸の追加ならadd X、Ｙ軸の追加ならadd Yといった対応表をもたせて判断させるような構成としてもよい。また、データ分析において、分析操作として入力されるコマンドの情報を記憶させるように制御してもよく、分析操作を特定できる情報であるならば何でもよい。
＜本実施形態による分析候補表示装置１０００の処理内容  ユーザ分析提案実行＞
次に、本システムでユーザに対して、最適なデータ分析を提案する処理内容の例を、図１３を参照して説明する。図１３は本システム１０００によるデータ分析提案の処理フローを示す図である。
【００４３】
図１３を参照すると、まずユーザ３００は何らかのデータ分析の軸を追加し、データ分析を開始する（ステップ０００１）。そこで分析候補表示装置１０００は、その時点のユーザ分析状況をキーにユーザ分析採点データベース６０００を検索し、現在の状態からのアクションとして、採点が高いアクションを順位表示する。（ステップ０００２）ユーザはシステムからの提案に対して、それに沿った分析を実行してもよいし、しなくてもよい。分析候補表示装置は、ユーザのデータ分析状況に合わせて過去の実績を元に最適なデータ分析軸を提案し続けるものとする。
【００４４】
例えば、ユーザが障害情報のデータ分析を開始し、Ｘ軸に「発生元システム（ＷＨＥＲＥ）」を設定したとする。その状況下では、本システムはユーザ分析採点データベースを「抽出軸１：空、抽出軸２：空、Ｘ軸：ＷＨＥＲＥ、Ｙ軸：空」で検索し、採点が高い次のアクション、分類を集計する。例えば、「次のアクション：Ａｄｄ  Ｙ、分類：Ｗｈｏ」のデータの採点の合計が３０であり、「次のアクション：Ａｄｄ  Ｅｘ1、分類：ＷＨＥＮ」のデータの採点の合計が６０であった場合、後者の「抽出軸１に「Ｗｈｅｎ」項目を追加する」処理の方が評価が高いと見なされる。そして、最も過去の実績から評価の高いアクションが、「抽出軸１に「Ｗｈｅｎ」項目を追加する」事だった場合、本システムはユーザに対し「Ｗｈｅｎ」項目での抽出を提案する事とする。その際、まず現在利用中の分析データ２０００の内、「Ｗｈｅｎ」項目として何が存在するかを検索する。現在分析中のデータＩＤ（今回の例ではＤｔ０００１とする）と、データ分類が「Ｗｈｅｎ」の項目という条件でデータ分類データベース３０００を検索すると、図６の２レコード目の「発生日付」が検索に該当する。また、仮にその他に「解決日付」等の項目も同時に該当したとすると、本システムはユーザに対し、「発生日付」又は「解決日付」を、「抽出軸１に追加する」事が有効的だ、と提案する事を決定する。その際のユーザに対しての提案の仕方の例としては、例えばユーザに対し、文章の形で「過去に評価の高い次のアクション：抽出軸１に対し、発生日付、 解決日付のどれかを追加」の様に表示してもよいし、データ項目の一覧やデータ抽出軸の一覧が画面上に表示されているのであれば、発生日付、解決日付、抽出軸１の画面上の部分を色彩的に強調表示（色をかえる、明度を変える）する等で提案してもよく、次の分析操作の候補を表示する。
【００４５】
ここで、次のアクションのＡｄｄ  Ｅｘ1とは抽出軸１を追加、つまり特定のデータ項目でデータを抽出する分析操作を意味している。先にも述べたが、Ａｄｄ  Ｅｘ1はデータを抽出する分析操作である旨別途、表等で定義して、その対応表にＡｄｄ  Ｅｘ1をてらしあわせて、データを抽出する分析操作を次の分析操作の候補としてユーザへ表示する。以上、本発明について、その一実施形態に基づき具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
【符号の説明】
【００４６】
１００：分析システムサーバ、１１０、２１０：ＣＰＵ、１２０、２２０：メモリ、１３０、２３０：Ｉ／Ｏインタフェース、１４０、２４０：ユーザ端末送受信部、１５０：データ分析実行部、１６０：分析データ接続インタフェース部、１７０：グラフ生成部、１８０：データ分類判定ロジック部、１８１：データ分析状況判定・採点ロジック、１９０：データベース制御部、２００：ユーザ端末、３００：ユーザ、１０００：分析システム、２０００：分析データ、３０００：データ分類ＤＢ、４０００：データ分類判定ＤＢ、５０００：ユーザ分析状況ＤＢ、６０００：ユーザ分析採点ＤＢ、７０００：分析結果格納ＤＢ
【図１】
2015165352.tif 000003
【図２】
2015165352.tif 000004
【図３】
2015165352.tif 000005
【図４】
2015165352.tif 000006
【図５】
2015165352.tif 000007
【図６】
2015165352.tif 000008
【図７】
2015165352.tif 000009
【図８】
2015165352.tif 000010
【図９】
2015165352.tif 000011
【図１０】
2015165352.tif 000012
【図１１】
2015165352.tif 000013
【図１２】
2015165352.tif 000014
【図１３】
2015165352.tif 000015