JP6573187B1 - データ処理プログラム、データ出力装置、データ統合方法、出力プログラム、データ出力方法及びデータ処理システム - Google Patents

Abstract

【課題】有益なデータ項目のみを抽出し、抽出したデータ項目を種別毎の統合データベースに統合して記憶するデータ処理プログラム等を提供すること。【解決手段】データ処理プログラムは、各複数のデータ項目を含む複数種別のデータを各複数のデータベースから取得し、種別毎に予め定めた有益なデータ項目のみを抽出し、抽出したデータ項目を種別毎の統合データベースに統合して記憶する。【選択図】図１２

Description

本発明は、データを統合した統合データベースに対する処理を行うデータ処理プログラム等に関する。

データ分析において、正しい分析は正しいデータに基づく。元データからデータ分析可能なデータセットを生成するデータクレンジング技術が提案されている（例えば、特許文献１）。また、正しいデータを得るため、同種種別のデータを扱う複数のデータベースを1つに統合した統合データベースも提案されている（例えば、特許文献２）。

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

従来のデータクレンジング技術では、不正なデータの排除が目的である。また、統合データベースは、複数のデータベースを統合することにより、１レコード当たりの項目数（カラム数）が増加する。データクレンジングをした統合データベースは多数項目の多数レコードを含む。

そのため、統合データベースのデータを活用して分析を行う場合、すべての項目から、有益な項目を選び出すのは困難である。本発明はこのような事情に鑑みてなされたものである。その目的は、有益なデータ項目のみを抽出し、抽出したデータ項目を種別毎の統合データベースに統合して記憶するデータ処理プログラム等の提供である。

本発明に係るデータ処理プログラムは、各複数のデータ項目を含む複数種別のデータを各複数のデータベースから取得し、種別毎に予め定めたデータ項目のみを抽出し、抽出したデータ項目を種別毎の統合データベースに統合して記憶するとともに、第一種別のデータに含まれるデータ項目の信頼度を、第二種別のデータに含まれる同種データ項目とのデータ整合性に基づき算出し、算出した信頼度を第一種別のデータ項目に対応付けて統合データベースに記憶する処理をコンピュータに実行させる。

本発明にあっては、抽出したデータ項目を種別毎の統合データベースに統合して記憶するとともに、データ項目の信頼度を算出し、算出した信頼度をデータ項目に対応付けて記憶するので、ユーザがデータ分析を行う際に分析結果の信頼度を見積もることが可能となる。

業績プラットホームの構成例を示す説明図である。 データ提供サーバのハードウェア構成例を示すブロック図である。 データ統合機能を示す説明図である。 統合データベースの例を示す説明図である。 データ提供機能を示す説明図である。 収集方式ＤＢの例を示す説明図である。 変換規則ＤＢの例を示す説明図である。 算出式ＤＢの例を示す説明図である。 評価規則ＤＢの例を示す説明図である。 警告先ＤＢの例を示す説明図である。 提供規則ＤＢの例を示す説明図である。 データ収集処理の手順例を示すフローチャートである。 変換記憶処理の手順例を示すフローチャートである。 データ提供処理の手順例を示すフローチャートである。 評価処理の手順例を示すフローチャートである。 警告処理の手順例を示すフローチャートである。 サービス提供基盤の構成を示す説明図である。 ポータルサーバのハードウェア構成例を示すブロック図である。 バッチサーバのハードウェア構成例を示すブロック図である。 ロボＤＢの例を示す説明図である。 利用ロボＤＢの例を示す説明図である。 設定ＤＢの例を示す説明図である。 ロボ一覧画面の例を示す説明図である。 ロボ設定画面の例を示す説明図である。 ロボ設定処理の手順例を示すフローチャートである。 ログＤＢの例を示す説明図である。 評価値調整処理の手順例を示すフローチャートである。 通報ＤＢの例を示す説明図である。 通報集計処理の手順例を示すフローチャートである。 アプリサーバのハードウェア構成例を示すブロック図である。 ユーザ異表記ＤＢの例を示す説明図である。 変換ＤＢの例を示す説明図である。 検索処理の手順例を示すフローチャートである。 調達先検索処理の手順例を示すフローチャートである。 調達先検索処理の例を示す説明図である。

以下、実施の形態を、図面を用いて説明する。

実施の形態１
図１は業績プラットホームの構成例を示す説明図である。業績プラットホーム１００はデータ提供サーバ（データ出力装置）１、統合データベース２、ユーザ端末３及び各種クラウドサービス４を含む。データ提供サーバ１、統合データベース２、ユーザ端末３及び各種クラウドサービス４はインターネットや電話公衆網などのネットワークＮにより、互いに通信可能に接続されている。各種クラウドサービス４は、予約システム、ＰＯＳシステム、勤怠システム、会計システム、給与システム、受発注システム、反社情報システム、ＨＲシステム、信用情報システム等の様々なシステムを含む。

統合データベース２は、各種クラウドサービス４に含まれる複数システムそれぞれが管理するデータベースから収集した複数種別のデータを、フォーマット、項目を統一し、種別毎に記憶するデータベースである。統合データベース２は、ＰＯＳ（Ｐｏｉｎｔ ｏｆ ｓａｌｅ）データ、勤怠データ、予約データ、会計データ、ＨＲ（Ｈｕｍａｎ Ｒｅｓｏｕｒｃｅｓ）データ、及び反社データ等を記憶する。ＰＯＳデータは店頭等に設置されたＰＯＳレジスタから収集される商品名や価格、数量、販売日時などを含む販売実績データである。勤怠データは各従業員の出退勤時刻、勤怠時間、休憩時間、残業時間等を含む。予約データは店舗毎、時間帯毎の予約数、予約人数、予約メニュー、売上見込額等を含む。会計データは貸借対照表、損益計算書、キャッシュフロー計算書等を含む。また、会計データには貸借対照表、損益計算書、キャッシュフロー計算書を作成する際に必要となる売上・売掛表、仕入データ、棚卸データ、現金出納データ等を含む。ＨＲデータは従業員毎の給与、職位、配属、所定期間毎の業績及び人事評価等の人材に関するデータを含む。反社データは、経営層に反社会勢力の関係者が含まれているか否か、反社会勢力と取引関係があるか否か、過去に反社会的活動を行った否かなどの情報を含む。統合データベース２が記憶するデータはデータ発生源であり、データ保有者であるユーザのユーザＩＤと対応付けてある。例えば、ＡＢＣ株式会社は甲社の会計システムを利用しており、当該システムを介して、統合データベース２に会計データを提供している場合、当該会計データの保有者は甲社であり、甲社のユーザＩＤが対応付けてある。

統合データベース２が記憶するデータは、最新データでなく過去データも記憶する。例えば、会計データに含まれる賃借貸借対照表は、更新頻度が異なるデータを含む。すなわち、１日毎の日次データ、１週間毎の週次データ、１月毎の月次データ、１年毎の年次データも含む。例えば、ＰＯＳデータのように略リアルタイムに更新されるデータも含むし、決算時に作成される会計データである貸借対照表、損益計算書、キャッシュフロー計算書などの年次データも含む。また、異なる種別間で重なる項目を含んでもよい。例えば、会計データに日次売上高を含み、ＰＯＳデータに日毎に売上高を集計した日次売上高を含んでもよい。

図２はデータ提供サーバ１のハードウェア構成例を示すブロック図である。データ提供サーバ１はサーバコンピュータ等で構成する。データ提供サーバ１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３、大容量記憶部１４、通信部１５、及び読み取り部１６を含む。各構成はバスＢで接続されている。なお、データ提供サーバ１は複数台のコンピュータで構成してもよい。また、データ提供サーバ１は仮想マシンであってもよい。更に、データ提供サーバ１の機能をクラウドサービスにより提供してもよい。

ＣＰＵ１１はＲＯＭ１２に記憶された制御プログラム１Ｐにしたがい、ハードウェア各部を制御する。ＲＡＭ１３は例えばＳＲＡＭ（Ｓｔａｔｉｃ ＲＡＭ）、ＤＲＡＭ（Ｄｙｎａｍｉｃ ＲＡＭ）又はフラッシュメモリである。ＲＡＭ１３はＣＰＵ１１によるプログラムの実行時に発生するデータを一時的に記憶する。

大容量記憶部１４は、例えばハードディスク又はＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などである。大容量記憶部１４は各種データベース（ＤＢ：ＤａｔａＢａｓｅ）を記憶する。大容量記憶部１４は収集方式ＤＢ１４１、変換規則ＤＢ１４２、算出式ＤＢ１４３、評価規則ＤＢ１４４、警告先ＤＢ１４５、及び提供規則ＤＢ１４６を記憶する。また、制御プログラム１Ｐを大容量記憶部１４に記憶してもよい。収集方式ＤＢ１４１から提供規則ＤＢ１４６は、データ提供サーバ１以外に記憶してもよい。例えばデータベースサーバやクラウドストレージに記憶してもよい。

通信部１５はネットワークＮを介して、統合データベース２、ユーザ端末３、各種クラウドサービス４と通信を行う。また、ＣＰＵ１１が通信部１５を用い、ネットワークＮ等を介して他のコンピュータから制御プログラム１Ｐをダウンロードし、大容量記憶部１４に記憶してもよい。

読み取り部１６はＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）−ＲＯＭ及びＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）−ＲＯＭを含む可搬型記憶媒体１ａを読み取る。ＣＰＵ１１が読み取り部１６を介して、制御プログラム１Ｐを可搬型記憶媒体１ａより読み取り、大容量記憶部１４に記憶してもよい。また、半導体メモリ１ｂから、ＣＰＵ１１が制御プログラム１Ｐを読み込んでもよい。

業績プラットホーム１００が提供する機能には、データ統合機能及びデータ提供機能を含む。データ統合機能は、複数種別のデータを複数のデータベースから収集し、フォーマット、項目を統一し、種別毎に統合データベース２に記憶する機能である。データ提供機能は統合データベース２に記憶しているデータを提供する機能である。

図３はデータ統合機能を示す説明図である。データ提供サーバ１はデータ統合機能を実現する機能部として、収集部１１１、変換部１１２、算出部１１３、評価部１１４、警告部１１５及び記憶部１１６を備える。収集部１１１は複数種別のデータを複数のデータベースからデータを収集する。図３に示す例では、ＰＯＳデータはＡ社・ＰＯＳシステム、Ｂ社・ＰＯＳシステム等が管理するデータベースから収集する。勤怠データはα社・勤怠システム、β社・勤怠システム等が管理するデータベースから収集する。会計データは甲社・会計システム、乙社・会計システム等が管理するデータベースから収集する。予約データはい社・予約システム、ろ社・予約システム等が管理するデータベースから収集する。ＨＲデータはア社・ＨＲシステム、イ社・ＨＲシステム等が管理するデータベースから収集する。ここで、Ａ社、Ｂ社、α社、β社、甲社、乙社、い社、ろ社、ア社、イ社はサービス提供会社を想定している。すなわち、Ａ社・ＰＯＳシステムは複数の企業がユーザとして利用している。その他のシステムも同様である。また、同一企業が複数種別のサービスを提供してもよい。例えば、甲社は会計サービスに加えて、ＨＲサービスを提供してもよい。一方、同一企業が複数のサービスを利用してもよい。例えば、同一企業がＡ社・ＰＯＳシステム、β社・勤怠システム、ろ社・予約システム等を利用してもよい。

変換部１１２は収集部１１１が収集したデータのフォーマット変換を行う。フォーマット変換は有益な項目の抽出、単位の変換やデータ項目の並び順の変更等である。算出部１１３は収集したデータから新たな項目のデータを求める。例えば、店舗毎の売上高及び坪数より、坪当たり売上高を算出する。評価部１１４はデータ項目毎の信頼性を示す評価値を付与する。記憶部１１６は有益な項目のデータと新たな項目のデータと評価値とを対応付けて、統合データベース２に記憶する。統合データベース２では同一種別のデータは同一のデータベースに記憶する。例えば、ＰＯＳデータはＡ社・ＰＯＳシステムから収集したデータも、Ｂ社・ＰＯＳシステムから収集したデータも、同一のＰＯＳ−ＤＢに記憶する。Ａ社・ＰＯＳシステムから収集したデータも、Ｂ社・ＰＯＳシステムから収集したデータも、データ項目、値の単位が揃えられて記憶される。警告部１１５は評価値が所定の閾値より低いデータ項目がある場合、警告を行う。

図４は統合データベース２の例を示す説明図である。統合データベース２はＰＯＳ−ＤＢ２１、勤怠ＤＢ２２、会計ＤＢ２３、予約ＤＢ２４、ＨＲ−ＤＢ２５、口コミＤＢ２６、反社情報ＤＢ２７及び口座情報ＤＢ２８を含む。ＰＯＳ−ＤＢ２１はＰＯＳシステムから収集したＰＯＳデータを記憶する。勤怠ＤＢ２２は勤怠システムから収集した勤怠データを記憶する。会計ＤＢ２３は会計システムから収集した会計データを記憶する。予約ＤＢ２４は予約システムから収集した予約データを記憶する。ＨＲ−ＤＢ２５はＨＲシステムから収集したデータを記憶する。口コミＤＢ２６は口コミシステムから収集した口コミデータを記憶する。反社情報ＤＢ２７は反社情報システムから収集した反社データを記憶する。口座情報ＤＢ２８はインターネットバンキングシステムから収集した口座情報（口座データ）を記憶する。口座情報には入出金履歴や残高等を含む。上述したように、統合データベース２は、複数のＰＯＳシステムから収集したデータを同一のＰＯＳ−ＤＢ２１記憶する。それにより、ＰＯＳデータに含まれる項目や項目毎と値が統一化されている。また、統合データベース２が収集するデータは、データ保有者であるユーザの了解のもとに、データ提供サーバ１が各種クラウドサービス４から提供を受けるものである。

図５はデータ提供機能を示す説明図である。データ提供サーバ１はデータ提供機能を実現する機能部として、受付部１１７、取得部１１８、出力変換部１１９及び応答部１１Ａを備える。受付部１１７は通信部１５を介して各種アプリケーションソフトウェア（以下、「アプリ」とも呼ぶ。）からデータ要求を受付ける。例えば、受付部１１７はＷｅｂ ＡＰＩ（Ｗｅｂ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を提供する。ａ社アプリ（ａ社アプリケーションプログラム）、ｂ社アプリ（ｂ社アプリケーションプログラム）、ｃ社アプリ（ｃ社アプリケーションプログラム）はそれぞれ、Ｗｅｂ ＡＰＩによりデータ要求をデータ提供サーバ１に行う。ａ社アプリ、ｂ社アプリ及びｃ社アプリは予めＷｅｂ ＡＰＩの利用権限を得ており、それを示すアプリケーションＩＤ等が付与されている。取得部１１８は受付けたデータ要求に対応するデータを統合データベース２から読み出す。出力変換部１１９は必要に応じて、読み出したデータの形式を出力する形式に変換する。応答部１１Ａは出力するデータを含む応答メッセージを生成する。生成した応答メッセージは通信部１５を介して、データ要求を行ったアプリに返送される。

次に、データ統合機能及びデータ提供機能を実現する処理において使用されるデータベースについて説明する。図６は収集方式ＤＢの例を示す説明図である。収集方式ＤＢ１４１は各種クラウドサービス４が管理するデータベースからデータを収集する際の収集方法を記憶する。収集方式ＤＢ１４１はシステム列、タイプ列、種別列及び変換規則列を含む。システム列はデータ収集先の識別情報、例えばシステム名称を記憶する。タイプ列は収集方法を記憶する。例えば、ファイルはファイル取り込みによる収集を意味する。例えば、各種クラウドサービス４はファイルをネットワーク共有フォルダに書き込む。データ提供サーバ１はネットワーク共有フォルダを監視し、ファイルが書き込まれたら取り込みを行う。種別列は収集するデータの種別を記憶する。例えば種別ＰＯＳ、会計、勤怠、予約、ＨＲ等である。変換規則列は変換規則のＩＤを記憶する。ＩＤは収集したデータを変換する際の変換規則を特定するＩＤである。

図７は変換規則ＤＢの例を示す説明図である。変換規則ＤＢ１４２は収集したデータを統合データベース２に記憶する形式に変換するための変換規則を記憶する。変換規則ＤＢ１４２はＩＤ列、項番列、項目列、処理列及び出力項番列を含む。ＩＤ列は変換規則を一意に特定するＩＤを記憶する。項番列は収集したデータに含まれる項目の順番号を記憶する。項目列は項目内容を示す項目名を記憶する。処理列は各項目に対して行う処理を記憶する。破棄は当該項目を破棄し、統合データベース２には記憶しないことを示す。項番変更は項目の並び順を変更することを示す。算出は複数項目から算出して求める項目であることを示す。出力項番列は出力データにおける各項目の並び順を示す。

図８は算出式ＤＢの例を示す説明図である。算出式ＤＢ１４３は収集したデータを変換する際に算出して求める項目についての算出式を記憶する。算出式ＤＢ１４３は算出値列及び式列を含む。算出値列は算出する項目を識別する情報、例えば項目名を記憶する。式列は算出するための式を記憶する。図８に示す例では坪当たり売上高は売上高を坪数で割って求めることを示している。坪数は静的データであるため、売上高と坪数とが同一データに含まれない場合もある。このような場合は、坪数データは店舗情報を記憶する図示しない店舗マスタデータベースから取得する。

図９は評価規則ＤＢの例を示す説明図である。評価規則ＤＢ１４４はデータ項目の信頼性を示す評価値を求める規則を記憶する。評価規則ＤＢ１４４は種別列、項目列、既定列、評価法列及び処理列を含む。種別列はデータ種別を記憶する。データ種別はＰＯＳ、勤怠、予約、会計、ＨＲ等である。項目列は項目名を記憶する。既定列は既定の評価値を記憶する。既定の評価値は、他の種別データ等がないなどの理由により信頼性評価が行えない場合に設定する値である。評価法列は信頼性評価を行う方法を記憶する。処理列は評価値を求めるための処理を記憶する。図９に示す例では会計データに含まれる売上高の信頼性評価の方法が示されている。評価の値は１から５で、５が最も信頼性が高いことを示す。評価の既定値は３である。評価方法はＰＯＳとの対比である。ここで、処理対象となっている企業について会計データだけでなく、ＰＯＳデータもＰＯＳ−ＤＢ２１に記憶されていることが前提となる。会計データに含む月次の売上高を取得した場合、ＰＯＳデータから月次に対応する期間における売上データを取得し、取得した売上データを集計し、ＰＯＳデータに基づく月次の売上高を算出する。そして、会計データに含む月次の売上高とＰＯＳデータに基づく月次の売上高との乖離率を求める。例えば、乖離率＝（２つの売上高の差分）／（会計データ売上高）×１００で求める。そして、乖離率が５％未満であれば、評価値を５とする。乖離率が１０％未満であれば、評価値を４とする。乖離率が１０％以上であれば、評価値を２とする。乖離率が１５％以下であれば評価値を１とする。そして、警告を行う。ここでは評価が行えない場合のみ評価値が既定値となるが、評価値が３となる乖離率を定義してもよい。既定値は３としたが、データ項目毎に変えてもよい。データ発生の成り立ちや管理方法、監査対象になるか否か等により、一般的な評価として信頼性が高いと考えられているデータ項目、信頼性が低いと考えられているデータ項目が存在するからである。このような、一般評価を考慮して既定値を定めてもよい。さらに、一般評価を加味して、評価値を定めてもよい。

図１０は警告先ＤＢの例を示す説明図である。警告先ＤＢ１４５は警告を発する場合の警告先の情報を記憶する。警告は電子メールで行う。警告先ＤＢ１４５はユーザＩＤ列及びメールアドレス列を含む。ユーザＩＤ列はユーザを一意に特定するユーザＩＤを記憶する。ここでいうユーザとは各種クラウドサービス４を利用している企業である。すなわち、統合データベース２に何らかのデータが記憶されている企業である。メールアドレス列は警告をメールの送信先となる電子メールのアドレスを記憶してもよい。警告は、アプリを起動したときにポップアップ表示してもよい。プッシュ通知を用いて警告を送信してもよい。警告先はユーザに加えて、業績プラットホームの管理者や関係する各種クラウドサービス４の管理者に送信してもよい。又はユーザには送信せず、業績プラットホームの管理者や関係する各種クラウドサービス４の管理者に送信してもよい。例えば、システム異常によりＰＯＳデータが異常値となっていたことに起因して、会計データの売上高の信頼性が低いと判断された場合は、ユーザに通知するのではなく、ＰＯＳシステムの管理者に通知することが適当だからである。もし、ＰＯＳデータ異常の原因がシステム異常でなければ、ＰＯＳシステムの管理者がユーザに通知すればよい。

図１１は提供規則ＤＢの例を示す説明図である。提供規則ＤＢ１４６は統合データベース２に記憶しているデータの提供機能を定義した規則を記憶する。提供規則ＤＢ１４６は機能列、方式列、名称列、引数列及び返却列を含む。機能列は提供機能の名称を記憶する。方式列はデータの提供方式を記憶する。提供方式はＡＰＩ、ファイル、電子メール等である。提供方式のＡＰＩは、ユーザは提供規則ＤＢ１４６で定義されている関数を呼び出し、その返却値としてデータを受け取る。例えば、ＡＰＩはＨＴＴＰ（Hypertext Transfer Protocol）を使用するＷｅｂＡＰＩである。提供方式のファイルは共有フォルダにファイルを出力し、当該ファイルユーザが読み出す方式である。例えば、リモートシェルによりコマンドを実行する。提供方式の電子メールの場合、ユーザは読み出したいデータを指定するコマンドが書かれた電子メールを送信する。読み出されたデータは、電子メールの本文又は添付ファイルとして返信される。電子メール方式の場合、業績プラットホームでメールの受送信を行うのは、データ提供サーバ１でもよいし、他のサーバでもよい。名称列は関数名やコマンド名を記憶する。引数列は関数やコマンドの引数を記憶する。返却列は返却される値の内容を記憶する。図１１の例では、売上高を取得するＡＰＩの関数として、ｇｅｔＡｍｎｔＯｆＳａｌｓｅＭが用意されていることを示す。当該ＡＰＩ関数の引数は会社コード、種別、年月であることを示す。種別とは例えば全社の値か、特定の事業部の値などを指定する。当該ＡＰＩ関数の返却値は会社コード、年月、売上高、評価値であることを示す。評価値はデータの信頼度を示す値である。例えば、評価値は５段階の値である。信頼度がもっと高い場合、評価値は５である。信頼度がもっとも低い場合、評価値は１となる。

続いて、業績プラットホーム１００が行うデータ処理について、フローチャートを用いて説明する。

（データ収集処理）
図１２はデータ収集処理の手順例を示すフローチャートである。データ収集処理は収集方法に適したタイミングで呼び出される。また、データ収集処理が呼び出される場合、収集方式を特定する情報が渡されるものとする。データ提供サーバ１のＣＰＵ１１は、収集方式がファイル方式か否かを判定する（ステップＳ１）。ＣＰＵ１１は、ファイル方式と判定した場合（ステップＳ１でＹＥＳ）、ファイルを取り込む（ステップＳ２）。ＣＰＵ１１を取り込んだファイルのデータに対して、変換記憶処理を行う（ステップＳ３）。ＣＰＵ１１は変換記憶処理が終わったファイルを削除する（ステップＳ４）。ＣＰＵ１１は未処理のファイルがあるか否かを判定する（ステップＳ５）。ＣＰＵ１１は未処理のファイルがあると判定した場合（ステップＳ５でＹＥＳ）、処理をステップＳ２に戻し、未処理ファイルに対する処理を行う。ＣＰＵ１１は未処理のファイルがないと判定した場合（ステップＳ５でＮＯ）、処理を終了する。ＣＰＵ１１は、ファイル方式でないと判定した場合（ステップＳ１でＮＯ）、収集方式がメール方式か否かを判定する（ステップＳ６）。ＣＰＵ１１は収集方式がメール方式であると判定した場合（ステップＳ６でＹＥＳ）、受信しているメールを取り込む（ステップＳ７）。ＣＰＵ１１は取り込んだメールのデータに対して、変換記憶処理を行う（ステップＳ８）。ＣＰＵ１１は変換記憶処理が終わったメールを削除する（ステップＳ９）。ＣＰＵ１１は未処理のメールがあるか否かを判定する（ステップＳ１０）。ＣＰＵ１１は未処理のメールがあると判定した場合（ステップＳ１０でＹＥＳ）、処理をステップＳ７へ戻し、未処理メールに対する処理を行う。ＣＰＵ１１は未処理のメールがないと判定した場合（ステップＳ１０でＮＯ）、処理を終了する。ＣＰＵ１１は収集方式がメール方式でないと判定した場合（ステップＳ６でＮＯ）、ＡＰＩ呼出方式であるか否かを判定する（ステップＳ１１）。ＡＰＩ呼出方式はデータを収集される側の各種クラウドサービス４が、データの準備が整った時点で、データ提供サーバ１のＡＰＩを呼び出し、収集処理実行させる方式である。ＣＰＵ１１は収集方式がＡＰＩ呼出方式であると判定した場合（ステップＳ１１でＹＥＳ）、各種クラウドサービス４よりデータを取り込む（ステップＳ１２）。取り込むデータは、共有フォルダに記憶されている。または、ＡＰＩの引数等に含まれている。ＣＰＵ１１は取り込んだデータに対して、変換記憶処理を行う（ステップＳ１３）。ＣＰＵ１１は変換の完了を返却する（ステップＳ１４）。ＣＰＵ１１は収集方式がＡＰＩ呼出方式でないと判定した場合（ステップＳ１１でＮＯ）、ＡＰＩを実行する（ステップＳ１５）。実行するＡＰＩは引数として渡す。または、大容量記憶部１４に記憶しておく。ＣＰＵ１１はＡＰＩの実行結果としてデータを取得する（ステップＳ１６）。データは返却値に含まれている。ＣＰＵ１１は取得したデータに対して、変換記憶処理を行う（ステップＳ１７）。ＣＰＵ１１は処理を終了する。なお、収集方式の判定は以下のようにしてもよい。データ収集処理を起動する際の引数を収集先のシステム名称とする。ＣＰＵ１１はシステム名称を用いて、収集方式ＤＢ１４１を検索し、タイプ列に記憶してある収集方式を取得し、判定を行う。

図１３は変換記憶処理の手順例を示すフローチャートである。図１３に示すのは、図１２のステップＳ３、ステップＳ８、ステップＳ１３及びステップＳ１７で行う処理の詳細を示している。ＣＰＵ１１は処理対象のデータを作成したシステムの名称を取得する（ステップＳ３１）。システム名称は、収集方式に適した方法で取得される。例えば、取得したデータの先頭や末尾にシステム名称が含まれている。また、ファイル取り込み時のファイル名や、データを取り込むＡＰＩが呼び出された際の引数としてシステム名称が渡される。Ｓ３１で取得する情報はシステムを特定するものであれば、名称に限らない。英数字の組み合わせからなるＩＤでもよい。ＣＰＵ１１は取得したシステム名称に対応した変換規則を取得する（ステップＳ３２）。ＣＰＵ１１はシステム名称を用いて、収集方式ＤＢ１４１から変換規則のＩＤを取得し、取得したＩＤを用いて変換規則ＤＢ１４２を検索して変換規則を得る。ＣＰＵ１１は変換・算出を行う（ステップＳ３３）。ＣＰＵ１１は取得した変換規則に基づいて取得したデータのフォーマットの変換を行う。ここでは、取得したデータから求まる指標値の算出も含む。ＣＰＵ１１は指標値の算出も含むフォーマット変換が完了したデータを、統合データベース２に記憶する（ステップＳ３４）。ＣＰＵ１１は変換記憶処理を終了し、処理を呼び出し元に戻す。

データ収集処理の具体例について説明する。Ａ社・ＰＯＳシステムからのデータ収集を例とする。収集方式ＤＢ１４１（図６）に定義されているように、Ａ社・ＰＯＳシステムからはファイル方式でデータが収集される。変換規則はＣＮＶ００１である。変換規則ＣＮＶ００１の内容は、変換規則ＤＢ１４２に定義されている。Ａ社・ＰＯＳシステムから収集される取得データの項番１は売上高である。当該売上高は出力項番も１である。取得データの項番の２は、売上値引きであり、これは破棄される。項番の３は売上差引であり、これも破棄される。項番４は売上原価であり、出力項番は変更され、２番となる。また、坪当たり売上高は算出する指標値であり、出力項番１０である。坪当たり売上高の算出方法は算出式ＤＢ１４３（図８）に定義されている。坪当たり単価は売上高を坪数で割ったものである。坪数は図示しない店舗ＤＢに記憶されている。変換規則に従った処理が変換、算出が完了したら、統合データベース２に記憶される。

（データ提供処理）
図１４はデータ提供処理の手順例を示すフローチャートである。データ提供処理は、ユーザ端末３のアプリケーションソフトウェア（以下、「アプリ」と記す。）からのデータ要求により、起動される処理である。ここでの処理はＡＰＩを用いたデータ提供である。データ提供サーバ１のＣＰＵ１１はＡＰＩで呼び出された関数の関数名を取得する（ステップＳ５１）。ＣＰＵ１１は関数名に対応した提供規則を提供規則ＤＢ１４６から取得する（ステップＳ５２）。ＣＰＵ１１は取得した提供規則の引数列の内容に従って、引数の解釈を行う（ステップＳ５３）。ここで、解釈とは要求されているデータ内容の判定である。ＣＰＵ１１は解釈に基づいて、統合データベース２からデータを取得する（ステップＳ５４）。ＣＰＵ１１は提供規則の返却列の内容に従って、返却値を作成する（ステップＳ５５）。ＣＰＵ１１は返却値を返却し（ステップＳ５６）、処理を終了する。

上述の説明では省略しているが、ユーザ端末３のアプリがデータ要求するには、認証が必要である。ユーザがＩＤとパスワードにより、データ提供サーバ１にログインしておくか、アプリがＩＤとパスワードを記憶しており、データ要求する際に、ログイン処理をする。または、アプリは予め付与された認証情報を記憶しており、当該認証情報をデータ提供サーバ１に送信することにより、認証を得られる仕組みでもよい。これらに限らず他の認証の仕組みを採用してもよい。

データ提供処理の具体例について説明する。ユーザのアプリからＡＰＩ関数ｇｅｔＡｍｎｔＯｆＳａｌｓｅＭが呼ばれた場合である。この関数は月間の売上高を取得するための関数である。提供規則ＤＢ１４６（図１１）に定義されているように、引数として、会社コード、種別、年月を取る。これに基づいて、統合データベース２から指定された会社の、指定された種別（全社又は特定事業所や、会計ＤＢが有する売上高か、ＰＯＳ−ＤＢが有する売上高かなどの指定）の、指定された年月の売上高が取得される。その際、信頼度を示す評価値も取得される。そして、返却値として、会社コード、年月、売上高、評価値の並び順で値が生成され、返却される。

（データ収集、提供機能の奏する効果）
業績プラットホーム１００のデータ収集機能では、勤怠データ、予約データ、会計データ、ＨＲデータ、及び反社データ等の複数種別のデータを各複数のデータベースから収集する。その際、データ分析には有用でない項目は破棄する。加えて、収集したデータに含まれていないが、算出可能でデータ分に有用な指標値を算出する。したがって、業績プラットホーム１００の統合データベース２は、様々な分析が可能な多様で有用なデータを記憶している。また、データ提供機能では、統合データベース２からＡＰＩ等のインタフェースでデータを読み出せるので、ユーザは統合データベース２が提供するデータを用いたアプリを容易に開発可能である。

（評価処理）
評価値の付加する評価処理ついて説明する。評価処理は、統合データベース２が記憶するデータに信頼度を示す評価値を付加する処理である。図１５は評価処理の手順例を示すフローチャートである。データ提供サーバ１のＣＰＵ１１は評価対象となるデータの種別、項目及び値を取得する（ステップＳ７１）。ＣＰＵ１１は評価規則ＤＢ１４４を検索し、評価対象を評価するための評価規則があるか否かを判定する（ステップＳ７２）。ＣＰＵ１１は評価規則があると判定した場合（ステップＳ７２でＹＥＳ）、評価規則に基づいて、評価を行うための評価用データの取得を試みる（ステップＳ７３）。ＣＰＵ１１は評価用データが取得できた否かを判定する（ステップＳ７４）。ＣＰＵ１１は評価用データが取得できたと判定した場合（ステップＳ７４でＹＥＳ）、評価規則に基づいて評価値を設定する（ステップＳ７５）。ＣＰＵ１１は警告が必要か否かを判定する（ステップＳ７６）。例えば、評価値が最低値の場合、警告が必要と判定する。警告を行う判定基準は、評価規則ＤＢ１４４の処理列に定義しておいてもよい。ＣＰＵ１１は警告が必要と判定した場合（ステップＳ７６でＹＥＳ）、警告処理を行い（ステップＳ７７）、処理を終了する。ＣＰＵ１１は警告が必要でないと判定した場合（ステップＳ７６でＮＯ）、処理を終了する。ＣＰＵ１１は評価規則がないと判定した場合（ステップＳ７２でＮＯ）、又はＣＰＵ１１は評価用データが取得できなかったと判定した場合（ステップＳ７４でＮＯ）、評価値に既定値を設定し（ステップＳ７８）、処理を終了する。既定値は例えば中間値である。５段階評価であれば３である。評価処理はデータ収集時に行うこと望ましい。図１３の変換・算出（ステップＳ３３）において、評価値を付与する。

（警告処理）
図１６は警告処理の手順例を示すフローチャートである。ＣＰＵ１１は警告を知らせるメッセージを作成する（ステップＳ９１）。例えば、メッセージには、データの種別及びデータ項目名並びに評価値を含める。ＣＰＵ１１は警告対象のデータに紐付いたユーザＩＤを検索キーにして、警告先ＤＢ１４５を検索し、警告の宛先となるユーザのメールアドレスを取得する（ステップＳ９２）。ＣＰＵ１１は取得したメールアドレス宛に警告メッセージを送信する（ステップＳ９３）。警告メッセージは業績プラットホームの管理者宛にも送信してもよい。また、ユーザには直接送信せず、管理者にユーザのメールアドレスと警告メッセージとを送り、管理者がシステム障害でないことを確認した上で、ユーザに警告メッセージを送信してもよい。一方、ユーザ側で警告メッセージを受け取る部署には、コンプライアンスを担当する部署を含めることが望ましい。データを不正の目的で意図的に改ざんしている可能性もあるからである。当該観点から、業績プラットホーム１００は警告メッセージの送信履歴は所定期間すべて保存しておくことが望ましい。

評価処理の例を説明する。会計データ（第一種別のデータ）に含まれる売上高の評価を例とする。飲食店の月間の売上高を収集したとする。評価規則ＤＢ１４４(図９)において、種別＝会計、項目＝売上高のレコードは存在する。当該レコードの評価法列にはＰＯＳ対比とある。すなわち、ＰＯＳデータ（第二種別のデータ）に基づく、売上高を評価用データとして取得する。対象である飲食店のＰＯＳデータから対象月における時間毎又は日毎の売上高を取得合算し、月間の売上高を計算する。そして、評価規則の処理列の内容によって、評価値を定める。会計データの売上高は、ＰＯＳデータに含まれる売上高（同種データ項目）とのデータ整合性を確認することで信頼度を求めることが可能である。

業績プラットホーム１００の統合データベース２が保有するデータには、評価処理によりデータの信頼度を示す評価値を付与するので、ユーザがデータ分析を行う際に分析結果の信頼度を見積もることが可能となる。信頼度が極端に低いデータに関しては、管理者及びデータ発生源のユーザに警告し、改善を促す。それによって、統合データベース２全体に対する信頼度を向上させることが可能となる。そして、信頼度の向上が、ユーザの増加に繋がり、データベースとしての優位性を高めることが可能となる。

（サービス提供基盤）
上述のように、業績プラットホーム１００は経営に関するデータポータルであるので、多様なサービスの提供が可能となる。次に、データを活用したサービス提供基盤について説明する。図１７はサービス提供基盤の構成を示す説明図である。サービス提供基盤はポータルサーバ５及びバッチサーバ６を含む。バッチサーバ６は設けずに、その機能をポータルサーバ５に持たせてもよい。バッチサーバ６が複数となるのは、異なる複数の運営者がサービスを提供する場合を想定している。

図１８はポータルサーバのハードウェア構成例を示すブロック図である。ポータルサーバ５は、サーバコンピュータ等で構成する。ポータルサーバ５は、ＣＰＵ５１、ＲＯＭ５２、ＲＡＭ５３、大容量記憶部５４、通信部５５、及び読み取り部５６を含む。各構成はバスＢで接続されている。以下において、データ提供サーバ１と同様な構成については、説明を省略する。

図１９はバッチサーバのハードウェア構成例を示すブロック図である。バッチサーバ６は、サーバコンピュータ等で構成する。バッチサーバ６は、ＣＰＵ６１、ＲＯＭ６２、ＲＡＭ６３、大容量記憶部６４、通信部６５、及び読み取り部６６を含む。各構成はバスＢで接続されている。以下において、データ提供サーバ１と同様な構成については、説明を省略する。

続いて、サービス提供基盤が用いるデータベースについて説明する。図２０はロボＤＢ５４１の例を示す説明図である。ロボＤＢ５４１はバッチサーバ６で動作するバッチプログラムに関する情報を記憶する。ロボＤＢ５４１はポータルサーバ５が管理する。例えば、ロボＤＢ５４１は大容量記憶部５４に記憶する。ロボＤＢ５４１はロボＩＤ列、役割列、名称列、アイコン列、提供列、説明列、実行頻度列及び必要データ列を含む。ロボＩＤ列はバッチプログラムを一意に特定可能なロボＩＤを記憶する。役割列はバッチプログラムが提供する機能を役割として表現した文字列を記憶する。名称列はバッチプログラムの名称を記憶する。アイコン列はバッチプログラムのアイコンを記憶する。提供列はバッチプログラムを提供する事業者を記憶する。説明列はバッチプログラムの機能についての説明文を記憶する。実行頻度列はバッチプログラムの推奨される実行頻度を記憶する。必要データ列はバッチプログラムを実行する場合において、必要とするデータを記憶する。

図２１は利用ロボＤＢの例を示す説明図である。利用ロボＤＢ５４２はユーザが利用する全バッチプログラムの情報を記憶する。利用ロボＤＢ５４２はポータルサーバ５が管理する。例えば、利用ロボＤＢ５４２は大容量記憶部５４に記憶する。利用ロボＤＢ５４２はユーザＩＤ列及びロボＩＤ列を含む。ユーザＩＤ列はユーザＩＤを記憶する。ロボＩＤ列はユーザが利用しているバッチプログラムのロボＩＤを記憶する。

図２２は設定ＤＢの例を示す説明図である。設定ＤＢ６４１はバッチプログラムの実行設定を記憶する。設定ＤＢ６４１はバッチプログラムを提供する各社のバッチサーバ６が管理する。設定ＤＢ６４１は例えば、バッチサーバ６の大容量記憶部６４が記憶する。設定ＤＢ６４１はロボＩＤ列、ユーザＩＤ列、実行頻度列、前回列及び次回列を含む。ロボＩＤ列はロボＩＤを記憶する。ユーザＩＤ列はバッチプログラムを利用しているユーザのユーザＩＤを記憶する。実行頻度列はユーザが設定した実行頻度を記憶する。前回列は前回実行日を記憶する。次回列は次回の実行日を記憶する。

続いて、バッチプログラムの利用手順について説明する。ユーザはユーザ端末３より、ポータルサーバにログインする。ユーザはログイン完了後に表示されるメニュー画面でロボ一覧を選ぶ。図２３はロボ一覧画面の例を示す説明図である。ロボ一覧画面ｄ０１はロボ一覧ｄ０１１、選択ボックスｄ０１２、決定ボタンｄ０１３及びキャンセルボタンｄ０１４を含む。ロボ一覧ｄ０１１は提供されているバッチプログラムを一覧表示する。選択ボックスｄ０１２は利用するバッチプログラムを選択するためのチェックボックスである。選択ボックスｄ０１２は各バッチプログラムに対応して表示される。決定ボタンｄ０１３を選択すると、選択結果がポータルサーバ５へ送信される。キャンセルボタンｄ０１４を選択すると、操作はキャンセルされ、メニュー画面に戻る。

図２４はロボ設定画面の例を示す説明図である。ロボ設定画面ｄ０２はロボ表示ｄ０２１、実行設定ｄ０２２、通知先設定ｄ０２３、決定ボタンｄ０２４、キャンセルボタンｄ０２５及びカスタマイズボタンｄ０２６を含む。ロボ表示ｄ０２１はロボ一覧画面ｄ０１で選択されたバッチプログラムを表示する。実行設定ｄ０２２は実行頻度を設定する。第１メニューｄ０２２１で日次、週次又は月次を選択する。第２メニューｄ０２２２に実行日を設定する。日次の場合は設定不要である。週次の場合は曜日を指定する。月次の場合は日付を指定する。通知先設定ｄ０２３はバッチプログラムからの通知先を設定する。既定は登録済みのメールアドレスである。他のメールアドレスやＳＮＳへの通知を希望する場合は、通知先種別メニューｄ０２３１を変更する。そして、通知先指定ボックスｄ０２３２にメールアドレスやＳＮＳのアカウントを入力する。決定ボタンｄ０２４を選択すると、設定内容がポータルサーバ５へ送信される。キャンセルボタンｄ０２５を選択すると、操作はキャンセルされ、メニュー画面に戻る。カスタマイズボタンｄ０２６を選択すると、カスタマイズ画面が表示され、バッチプログラムの動作をカスタマイズすることが可能となる。

図２５はロボ設定処理の手順例を示すフローチャートである。ユーザがメニュー画面でロボ一覧を選ぶと、ユーザ端末３は一覧請求をポータルサーバ５へ送信する（ステップＳ１１１）。ポータルサーバ５のＣＰＵ５１はロボＤＢ５４１を参照してロボ一覧画面を作成する（ステップＳ１１２）。ＣＰＵ５１はロボ一覧画面をユーザ端末３へ送信する（ステップＳ１１３）。ユーザ端末３はロボ一覧画面を受信し、表示する（ステップＳ１１４）。ユーザは利用したいバッチプログラムを選択し、決定ボタンを操作する。ユーザ端末３は選択情報を取得し（ステップＳ１１５）、取得した選択情報をポータルサーバ５へ送信する（ステップＳ１１６）。ポータルサーバ５のＣＰＵ５１は選択情報を受信する（ステップＳ１１７）。ＣＰＵ５１は選択されたバッチプログラムを実行するのに必要なデータがあるかを確認する（ステップＳ１１８）。ＣＰＵ５１はロボＤＢ５４１の必要データ列が記憶する必要データの種別を取得し、種別に対応したデータベースに該当ユーザのデータが記憶されているか否かを確認する。例えば、ＰＯＳ、勤怠が必要であれば、統合データベース２のＰＯＳ−ＤＢ２１及び勤怠ＤＢ２２に、該当ユーザのデータが記憶されているかを確認する。ＣＰＵ５１は必要データに不足がある否かを判定する（ステップＳ１１９）。ＣＰＵ５１は必要データに不足がないと判定した場合（ステップＳ１１９でＮＯ）、処理をステップＳ１２２に進める。ＣＰＵ５１は必要データに不足があると判定した場合（ステップＳ１１９でＹＥＳ）、データ不足で実行できないバッチプログラムの選択を解除する（ステップＳ１２０）。ＣＰＵ５１は選択を解除した旨のメッセージを生成する（ステップＳ１２１）。ＣＰＵ５１はロボ設定画面を生成する（ステップＳ１２２）。ステップＳ１２１が実行されていた場合、生成したメッセージをロボ設定画面に含める。ＣＰＵ５１は生成したロボ設定画面をユーザ端末３へ送信する（ステップＳ１２３）。ユーザ端末３はロボ設定画面を受信し、表示する（ステップＳ１２４）。ユーザはロボ設定画面で設定を行い、決定ボタンを操作する。ユーザ端末３は設定を取得し（ステップＳ１２５）、設定をポータルサーバ５へ送信する（ステップＳ１２６）。ポータルサーバ５は設定を受信し、バッチプログラム毎に、対応するバッチサーバ６へ設定を転送し（ステップＳ１２７）、処理を終了する。設定を転送されたバッチサーバ６は設定を、設定ＤＢ６４１に記憶する。

（バッチプログラムの例）
バッチプログラムの一例として、融資提案ロボについて説明する。融資提案ロボは融資を行う金融機関が想定ユーザである。融資提案ロボは融資先となる有望な企業を抽出し、提案を行う。以下では融資先の業種を飲食業として設定した場合の融資提案ロボの動作を説明する。融資提案ロボは、ＰＯＳ−ＤＢ２１から処理対象企業の直近、例えば３ヶ月の売上高を取得する。また、ＰＯＳ−ＤＢ２１から今月分の確定した売上高を取得する。予約ＤＢ２４から予約状況を取得し、今月の未確定分の売上高、来月の売上高の推定値を求める。また、口座情報ＤＢ２８から処理対象企業の口座情報を取得し、それに基づき今月の資金状況を予測する。例えば、月末まで運転資金が足りるか否かの予測（資金予測）を行う。また、融資提案ロボは口コミＤＢ２６から処理対象企業の評価を取得する。融資提案ロボは、直近の月間売上高、今月及び来月の売上高、口コミ評価より、金融機関が定めたスコアリングモデルにより、企業の信用度を算出する。金融機関により、信用度に対応して融資枠が設定されているので、融資提案ロボは、信用度に対応した融資枠（与信枠）を取得する。直近の月間売上高、今月及び来月の売上高、口コミ評価と、可能な融資枠については、予めデータベースに記憶されているものとする。融資提案ロボは、融資枠（利率１．２％、上限額３００万円）と資金状況（２５０万円ショートの見込み）とを対照し、マッチすると判断したら、処理対象企業へ融資することの提案メッセージを金融機関に通知する。金融機関は通知を確認し、妥当であれば、融資の提案を企業に行う。

サービス提供基盤では、各種バッチプログラム（ロボ）を利用することより、種々の業務の効率化を図ることが可能となる。

（ログによる評価処理）
アプリ提供基盤から読み出されたデータについてはログ（利用履歴）を取る。ログにより、信頼度を示す評価値を調整する。図２６はログＤＢの例を示す説明図である。ログＤＢ１４７は例えばデータ提供サーバ１の大容量記憶部１４に記憶する。ログＤＢ１４７が記憶する各ログは統合データベース２が記憶するデータが読み出されるごとに生成される。ログＤＢ１４７は日付列、時刻列、種別列、項目列、ユーザ列、方式列及び参照ユーザ列を含む。日付列はデータが読み出された日付を記憶する。時刻列はデータが読み出された時刻を記憶する。種別列は読み出されたデータの種別を記憶する。項目列は読み出されたデータの項目を記憶する。ユーザ列は読み出されたデータを保有するユーザのユーザＩＤを記憶する。方式列はデータを読みだした方式を記憶する。参照ユーザ列はデータを読み出したユーザのユーザＩＤを記憶する。データを読み出したユーザを特定できない場合は、データを読み出したバッチプログラムのロボＩＤを記憶する。

図２７は評価値調整処理の手順例を示すフローチャートである。評価値調整処理は所定期間毎、例えば、週次や月次で実行する。データ提供サーバ１のＣＰＵ１１は集計期間に含まれるログをログＤＢ１４７から取得する（ステップＳ１３１）。評価値調整処理が週次に実行であれば、未処理の直近１週間分のログを取得する。ＣＰＵ１１は保有するユーザ毎並びに、データの種別毎及び項目毎に読み出し回数を集計する（ステップＳ１３２）。ＣＰＵ１１は読み出し回数でランキングを行う（ステップＳ１３３）。ＣＰＵ１１はランキングにしたがって評価値を調整し（ステップＳ１３４）、処理を終了する。評価値の調整は、例えば以下のように行う。読み出し回数のランキングの上位５位のデータは評価値を０．１加算し、下位５位のデータは評価値を０．１減算する。同様に、データの種別毎及び項目毎のランキングで、評価値を調整してもよい。

図２８は通報ＤＢの例を示す説明図である。通報ＤＢ１４８はユーザからデータ内容に疑義がある旨の通報を受けた場合、それをログとして記録する。通報ＤＢ１４８はデータ提供サーバ１の大容量記憶部１４に記憶する。通報ＤＢ１４８は日付列、時刻列、種別列、項目列、ユーザ列及び通報ユーザ列を含む。日付列は通報を受けた日付を記憶する。時刻列は通報を受けた時刻を記録する。種別列は通報を受けたデータの種別を記録する。項目列は通報を受けたデータの項目を記録する。ユーザ列は通報を受けたデータを保有するユーザのユーザＩＤを記憶する。通報ユーザ列は通報を行ったユーザのユーザＩＤを記憶する。

図２９は通報集計処理の手順例を示すフローチャートである。通報集計処理は所定期間毎、例えば、週次や月次で実行する。データ提供サーバ１のＣＰＵ１１は集計期間に含まれる通報ログを通報ＤＢ１４８から取得する（ステップＳ１５１）。通報集計処理が週次に実行であれば、未処理の直近１週間分の通報ログを取得する。ＣＰＵ１１は保有するユーザ毎並びに、データの種別毎及び項目毎に通報回数を集計する（ステップＳ１５２）。ＣＰＵ１１は集計されたデータの１つを選択する（ステップＳ１５３）。ＣＰＵ１１は選択したデータの通報回数が閾値以上であるか否かを判定する（ステップＳ１５４）。ＣＰＵ１１は選択したデータの通報回数が閾値以上であると判定した場合（ステップＳ１５４でＹＥＳ）、該当データの評価値を更新する（ステップＳ１５５）。例えば、通常では付与しない０又は−１などの値を設定する。ＣＰＵ１１は警告を行う（ステップＳ１５６）。警告処理は図１６に示した警告処理と同様である。ＣＰＵ１１は選択したデータの通報回数が閾値未満であると判定した場合（ステップＳ１５４でＮＯ）、処理をステップＳ１５７へ進める。ＣＰＵ１１は未処理のデータがあるか否かを判定する（ステップＳ１５７）。ＣＰＵ１１は未処理のデータがあると判定した場合（ステップＳ１５７でＹＥＳ）、処理をステップＳ１５３に戻し、未処理のデータに対する処理を行う。ＣＰＵ１１は未処理のデータがないと判定した場合（ステップＳ１５７でＮＯ）、処理を終了する。なお、通報回数を集計する際、同一の通報ユーザより、同一ユーザの同一種別、同一項目に対して、複数回通報されている場合であっても通報回数は１回としてもよい。同一の通報ユーザのみからの通報は、通報自体の信頼性が低い可能性があるからである。

以上のように、各データに対する読み出し回数や内容に疑義がある旨の通報回数（ユーザ評価）により、信頼度を変更する。それによって、信頼度の精度を向上することが可能となる。

（対話型提供機能）
業績プラットホーム１００のデータ提供機能を利用例として、上述ではバッチプログラムを示した。以下では対話型提供機能について例示する。対話型提供機能はアプリサーバにより提供される。図３０はアプリサーバのハードウェア構成例を示すブロック図である。アプリサーバ７は対話型のアプリケーションプログラムを提供する。アプリサーバ７はサーバコンピュータ等で構成する。アプリサーバ７は、ＣＰＵ７１、ＲＯＭ７２、ＲＡＭ７３、大容量記憶部７４、通信部７５、及び読み取り部７６を含む。各構成はバスＢで接続されている。以下において、データ提供サーバ１と同様な構成については、説明を省略する。

（検索機能）
対話型提供機能の一例として検索機能について説明する。検索機能は業績に関する検索キーワード、例えば「Ａ社 ２０１７年 売上高」に対して、統合データベース２に記憶した会計ＤＢ２３を検索し、Ａ社の２０１７年度の売上高を抽出し、検索結果として返却する機能である。

まず、検索機能で用いるデータベースについて説明する。図３１はユーザ異表記ＤＢ７４１の例を示す説明図である。ユーザ異表記ＤＢ７４１はアプリサーバ７の大容量記憶部７４に記憶する。ユーザ異表記ＤＢ７４１はユーザの種々の表記をユーザＩＤと対応付けて記憶する。ユーザ異表記ＤＢ７４１はユーザＩＤ列、名称列、略称・通称列、証券コード列及び法人番号列を含む。ユーザＩＤ列はユーザＩＤを記憶する。名称列はユーザの正式名称を記憶する。略称・通称列はユーザの略称、通称を記憶する。証券コード列はユーザの証券コードを記憶する。証券コードが振られていないユーザについては空白となる。法人番号列はユーザの法人番号を記憶する。法人番号はいわゆる番号法に基づく番号であり、国税庁長官が指定する。法人番号以外に、東京商工リサーチか発行するＴＳＲ企業コードや帝国データバンクが発行するＴＤＢ企業コードを、ユーザ異表記ＤＢ７４１に記憶してもよい。

図３２は変換ＤＢの例を示す説明図である。変換ＤＢ７４２はアプリサーバ７の大容量記憶部７４に記憶する。変換ＤＢ７４２は使用が想定される検索語を検索に適した表記に変換するための用語を記憶する。変換ＤＢ７４２は検索語列、種別列、項目列及び既定期間列を含む。検索語列は使用が想定される検索語を記憶する。種別列は検索語に対応させるデータの種別を記憶する。項目列は検索語に対応させる項目を記憶する。既定期間列は検索語に期間が指定されていない場合に、補う期間条件を記憶する。変換ＤＢ７４２を用いることにより、「Ａ社 売上」との入力は、「Ａ社 会計 売上高 ２０１７年度」（現在が２０１８年度の場合）に変換される。

検索機能は次のように提供される。ユーザはユーザ端末３からアプリサーバ７に検索機能の要求を行う。アプリサーバ７は検索語の入力画面をユーザ端末３に送信する。ユーザは入力画面に検索語を入力し、検索ボタン等を操作する。ユーザ端末３は検索語をアプリサーバ７に送信する。アプリサーバ７は受信した検索語に基づき検索を行い、検索結果をユーザ端末３に送信する。

図３３は検索処理の手順例を示すフローチャートである。アプリサーバ７のＣＰＵ７１はユーザ端末３から送信された検索語を取得する（ステップＳ１７１）。ＣＰＵ７１は取得した検索語の変換を行う（ステップＳ１７２）。ＣＰＵ７１は取得した検索語と、変換ＤＢ７４２の検索語列とを対照し、一致するものがあれば、変換を行う。変換の例は上述のとおりである。ＣＰＵ７１は検索語により、検索対象となるデータの種別及び項目が特定できたか否かを判定する（ステップＳ１７３）。ＣＰＵ７１は種別及び項目が特定できたと判定した場合（ステップＳ１７３でＹＥＳ）、統合データベース２に対する検索を行う（ステップＳ１７４）。ＣＰＵ７１は取得した検索結果をユーザ端末３へ送信し（ステップＳ１７５）、処理を終了する。ＣＰＵ７１は種別及び項目が特定できていないと判定した場合（ステップＳ１７３でＮＯ）、検索結果が０件であることをユーザ端末３へ送信し（ステップＳ１７６）、処理を終了する。

以上のように、検索機能により、インターネットの検索エンジンのようなユーザインタフェースにより、統合データベース２が記憶した種々のデータを抽出可能である。なお、当該検索機能は業績プラットホームの登録ユーザのみが利用可能とするが、それに限らない。所定の制限をつけて、未登録ユーザも利用できるようにしてもよい。

検索機能においては、検索語の内容によっては、検索結果に含まれる数値に演算処理を行い、その結果を出力してもよい。例えば、「２０１８年 恵比寿 飲食店 粗利益率」が検索条件と入力された場合、恵比寿エリアにある飲食店の各々について、２０１８年の粗利益率を取得し、各飲食店の粗利益率を検索結果として出力するのが、処理としては通常に考えうる処理である。そうではなく、恵比寿エリアにある飲食店の２０１８年における平均粗利益率を出力する。演算処理を行うか否かは例えば検索対象で判断する。ここでの例のように、粗利益率が検索された場合、個々の企業や店舗毎の値は出力せず、検索でヒットした値の平均値を出力する。

（資金調達支援機能）
上述の融資提案ロボは融資先として的確な企業を、金融機関に提案するものであったが、資金調達支援機能は、融資を受けたいユーザに対する機能である。前段階として、融資を行う金融機関は、融資先としての適格性を評価するためのスコアリングモデルを業績プラットホームに登録する。当該スコアリングモデルは、処理プログラムを含めて、アプリサーバ７の大容量記憶部７４に記憶される。また、各金融機関は、スコアリングモデルによる評価機能の使用をアプリサーバ７に許可する。

図３４は調達先検索処理の手順例を示すフローチャートである。融資を受けたいユーザはメニュー画面で資金調達支援機能を選択する。ユーザ端末３は機能の利用要求をアプリサーバ７へ送信する（ステップＳ１９１）。アプリサーバ７のＣＰＵ７１は利用要求を受信する（ステップＳ１９２）。ＣＰＵ７１は希望の融資条件を入力する入力画面をユーザ端末３へ送信する（ステップＳ１９３）。ユーザ端末３は入力画面を受信し、表示する（ステップＳ１９４）。ユーザは入力画面に希望の融資条件を入力し、送信を指示する。ユーザ端末３は入力された希望条件を取得し、アプリサーバ７へ送信する（ステップＳ１９５）。アプリサーバ７は希望条件を受信する（ステップＳ１９６）。アプリサーバ７のＣＰＵ７１はユーザの業績情報を統合データベース２より取得する（ステップＳ１９７）。ＣＰＵ７１は金融機関を選択する（ステップＳ１９８）。ＣＰＵ７１はユーザの業績情報を入力とし、選択した金融機関のスコアリングモデルを用いて、ユーザのスコアリングを行う（ステップＳ１９９）。ＣＰＵ７１はスコアリングの結果、ユーザが選択した金融機関から融資を受けられるか否かを判定する（ステップＳ２００）。例えば、ＣＰＵ７１は、スコアリングで得た評価点が閾値を超えているか否かで判定する。ＣＰＵ７１はユーザが融資を受けらないと判定した場合（ステップＳ２００でＮＯ）、処理をステップＳ２０４へ移す。ＣＰＵ７１はユーザが融資を受けられると判定した場合（ステップＳ２００でＹＥＳ）、評価点に対応した融資枠を取得する（ステップＳ２０１）。評価点が融資可能な点数であっても、点数の大小により融資枠が異なる場合があるからである。ＣＰＵ７１は取得した融資枠がユーザの希望条件と適合するか否かを判定する（ステップＳ２０２）。ＣＰＵ７１は融資枠が希望条件と適合しないと判定した場合（ステップＳ２０２でＮＯ）、処理をステップＳ２０４へ移す。ＣＰＵ７１は融資枠が希望条件と適合すると判定した場合（ステップＳ２０２でＹＥＳ）、選択した金融機関及び融資枠の情報を記憶する（ステップＳ２０３）。ＣＰＵ７１は未処理の金融機関があるか否かを判定する（ステップＳ２０４）。ＣＰＵ７１は未処理の金融機関があると判定した場合（ステップＳ２０４でＹＥＳ）、処理をステップＳ１９８へ戻し、未処理の金融機関についての処理を行う。ＣＰＵ７１は未処理の金融機関がないと判定した場合（ステップＳ２０４でＮＯ）、結果をユーザ端末３へ送信する（ステップＳ２０５）。ユーザ端末３は結果を受信し、表示する（ステップＳ２０６）。

調達先検索処理の例を説明する。図３５は調達先検索処理の例を示す説明図である。図３５では、融資を希望しているユーザはＡ社である。金融機関はａ銀行、ｂ銀行及びｃ銀行である。Ａ社は融資の希望条件３５１を入力する。アプリサーバ７は統合データベース２を検索して、スコアリングに必要なＡ社の業績情報３５２を取得する。必要な項目であるが統合データベース２が記憶していない情報の場合、アプリサーバ７はユーザに入力を求めるか、統合データベース２から取得した複数の項目から求める。例えば、借入金残高が年間売上の範囲内であるか否かは、例えば、前年度決算データの借入金と売上高とを比較すれば、判定可能である。アプリサーバ７は取得したＡ社の業績情報３５２をａ銀行、ｂ銀行及びｃ銀行それぞれのスコアリングモデルでスコアリングする。アプリサーバ７は項目毎の評点３５３を求める。そして、アプリサーバ７は評点に基づき評価点３５４１を求める。アプリサーバ７は評価点３５４１に基づいて、融資の可否３５４２が判定する。さらに、アプリサーバ７は融資可能の場合、融資枠とユーザの希望条件とマッチング結果３５４３を求める。評価点３５４１、融資の可否３５４２及びマッチング結果３５４３は、判定結果３５４として、ユーザ端末３に表示される。さらに、業績プラットホームはユーザが融資の申し込みを行える機能を備えており、判定結果３５４の表示画面から申し込みが行える。その際、判定結果が金融機関に送信される。

以上のように、資金調達支援機能より、資金調達したいユーザは一括して融資が受けられる資金調達先を調べることが可能となる。そして、ユーザが融資の申し込みをする際、判定結果が資金調達先に送られるので、資金調達先は改めて審査を行うことなく、融資の決定が行える。したがって、ユーザは確実に迅速に融資を受けることが可能となる。

なお、資金調達先として、金融機関からの融資としたが、それに限らない。ベンチャーキャピタルからの資金調達でもよい。また、ビジネスプランコンテストや助成金の検索機能を含めてもよい。この場合、ビジネスプランコンテストの応募条件や助成金の申請条件をユーザが満たすか否かが判定される。

各実施の形態で記載されている技術的特徴（構成要件）はお互いに組み合わせ可能であり、組み合わせすることにより、新しい技術的特徴を形成することができる。
今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。

１００ 業績プラットホーム
１ データ提供サーバ
１１ ＣＰＵ
１１１ 収集部
１１２ 変換部
１１３ 算出部
１１４ 評価部
１１５ 警告部
１１６ 記憶部
１１７ 受付部
１１８ 取得部
１１９ 出力変換部
１１Ａ 応答部
１４ 大容量記憶部
１４１ 収集方式ＤＢ
１４２ 変換規則ＤＢ
１４３ 算出式ＤＢ
１４４ 評価規則ＤＢ
１４５ 警告先ＤＢ
１４６ 提供規則ＤＢ
１４７ ログＤＢ
１４８ 通報ＤＢ
１５ 通信部
１６ 読み取り部
１Ｐ 制御プログラム
１ａ 可搬型記憶媒体
１ｂ 半導体メモリ
２ 統合データベース
２１ ＰＯＳ−ＤＢ
２２ 勤怠ＤＢ
２３ 会計ＤＢ
２４ 予約ＤＢ
２５ ＨＲ−ＤＢ
２６ 口コミＤＢ
２７ 反社情報ＤＢ
２８ 口座情報ＤＢ
３ ユーザ端末
４ クラウドサービス
５ ポータルサーバ
５１ ＣＰＵ
５４ 大容量記憶部
５４１ ロボＤＢ
５４２ 利用ロボＤＢ
６ バッチサーバ
６１ ＣＰＵ
６４ 大容量記憶部
６４１ 設定ＤＢ
７ アプリサーバ
７１ ＣＰＵ
７４ 大容量記憶部
７４１ ユーザ異表記ＤＢ
７４２ 変換ＤＢ
Ｎ ネットワーク

Claims (10)

1. 各複数のデータ項目を含む複数種別のデータを各複数のデータベースから取得し、
   前記種別毎に予め定めたデータ項目のみを抽出し、
   抽出したデータ項目を前記種別毎の統合データベースに統合して記憶するとともに、
   第一種別のデータに含まれるデータ項目の信頼度を、第二種別のデータに含まれる同種データ項目とのデータ整合性に基づき算出し、
   算出した前記信頼度を前記第一種別のデータ項目に対応付けて統合データベースに記憶する
   処理をコンピュータに実行させるデータ処理プログラム。
2. 前記抽出したデータ項目より新たなデータ項目を生成し、
   生成した新たな項目を前記統合データベースに記憶する
   請求項１に記載のデータ処理プログラム。
3. 前記信頼度を各データ項目の利用履歴により変更する
   請求項１又は請求項２に記載のデータ処理プログラム。
4. 各データに対するユーザ評価を取得し、
   取得したユーザ評価に基づき、前記信頼度を更新する
   請求項１から請求項３のいずれか１項に記載のデータ処理プログラム。
5. データ毎の前記信頼度が閾値を下回った場合、データ項目名、データ内容及び前記信頼度を含む警告情報を出力する
   請求項１から請求項４のいずれか１項に記載のデータ処理プログラム。
6. 各複数のデータ項目を含む複数種別のデータを各複数のデータベースから取得し、前記種別毎に予め定めたデータ項目のみを抽出し、抽出したデータ項目を前記種別毎に統合するとともに、第一種別のデータに含まれるデータ項目の信頼度を、第二種別のデータに含まれる同種データ項目とのデータ整合性に基づき算出し、算出した前記信頼度を前記第一種別のデータ項目に対応付けて統合データベースに記憶する統合部と、
   前記種別及び前記データ項目を含む要求情報を受け付ける受付部と、
   受け付けた要求情報に対応するデータを前記統合データベースから抽出し、抽出したデータを、データ項目毎又はデータ毎の信頼度と対応付けて出力する出力部と
   を備えるデータ出力装置。
7. 統合データベースにアクセス可能なコンピュータが、
   各複数のデータ項目を含む複数種別のデータを各複数のデータベースから取得し、
   前記種別毎に予め定めたデータ項目のみを抽出し、
   抽出したデータ項目を前記種別毎の統合データベースに統合して記憶するとともに、
   第一種別のデータに含まれるデータ項目の信頼度を、第二種別のデータに含まれる同種データ項目とのデータ整合性に基づき算出し、
   算出した前記信頼度を前記第一種別のデータ項目に対応付けて統合データベースに記憶する
   データ統合方法。
8. 各複数のデータ項目を含み、ＰＯＳデータ、商品又はサービスに関する予約データ、銀行口座を含む口座データ、及び口コミサイトの口コミデータを含む複数種別のデータを各複数のデータベースから取得し、前記種別毎に予め定めたデータ項目のみを抽出し、抽出したデータ項目を前記種別毎に統合して記憶する統合データベースと、前記種別及び前記データ項目を含む要求情報を受け付ける受付部と、受け付けた要求情報に対応するデータを前記統合データベースから抽出し、抽出したデータを出力する出力部とを備えるデータ出力装置に対して、
   予め設定した複数の前記要求情報を送信し、
   前記データ出力装置から受信した前記ＰＯＳデータから算出した売上実績、前記予約データから算出した売上見込み、前記口座データから算出した資金予測、及び前記口コミデータから算出した評価値に基づいて、信用度を算出し、
   算出した信用度を出力する
   処理をコンピュータに実行させる出力プログラム。
9. 前記信用度と、利率及び上限額を含む与信枠情報とを対応付けて記憶するデータベースから、算出した信用度に対応付いた与信枠情報を取得し、
   取得した与信枠情報を出力する
   請求項８に記載の出力プログラム。
10. 各複数のデータ項目を含む複数種別のデータを各複数のデータベースから取得し、前記種別毎に予め定めたデータ項目のみを抽出し、抽出したデータ項目を前記種別毎に統合して記憶するとともに、第一種別のデータに含まれるデータ項目の信頼度を、第二種別のデータに含まれる同種データ項目とのデータ整合性に基づき算出し、算出した前記信頼度を前記第一種別のデータ項目に対応付けて記憶する統合データベースと、前記種別及び前記データ項目を含む要求情報を受け付ける受付部と、受け付けた要求情報に対応するデータを前記統合データベースから抽出し、抽出したデータ、及びデータ項目毎又はデータ毎の信頼度と対応付けて出力する出力部とを有するデータ出力装置、及び、
    予め設定した複数の前記要求情報を送信する送信部と、前記データ出力装置から受信した前記要求情報毎のデータに基づき、指標値を算出する算出部と、算出した指標値を出力する出力部と
    を備えることを特徴とするデータ処理システム。

Images