(57)【要約】  職場の状態を評価するシステムであって、管理者の識別情報と、従業員の識別情報と、対面した識別情報とを記憶し、前記管理者の識別情報と前記従業員の識別情報にしたがって、前記対面した識別情報が管理者であるか従業員であるかの職位を判定し、前記管理者が対面した前記従業員の人数を算出し、前記算出した人数に基づいて職場の状態を判定する。
2016079827.tif 000002
【特許請求の範囲】
【請求項１】
職場の状態を評価するシステムであって、
管理者の識別情報と、従業員の識別情報と、対面した識別情報とを記憶し、
前記管理者の識別情報と前記従業員の識別情報にしたがって、前記対面した識別情報が管理者であるか従業員であるかの職位を判定し、前記管理者が対面した前記従業員の人数を算出し、前記算出した人数に基づいて職場の状態を判定すること
を特徴とする評価システム。
【請求項２】
前記対面した識別情報は、第１の識別情報に関して対面した１つまたは複数の第２の識別情報と、対面した第１の時刻とを含み、
前記職位の判定は、前記第１の識別情報が管理職であり、前記第２の識別情報が従業員であることを判定し、
前記人数の算出は、設定された期間に含まれる前記第１の時刻に対面した前記従業員と判定された人数に基づき、人数を算出すること
を特徴とする請求項１に記載の評価システム。
【請求項３】
前記対面した識別情報は、前記第１の識別情報を複数含み、
前記職位の判定は、前記複数の第１の識別情報の中から複数の管理職を判定し、
前記人数の算出は、前記判定された管理職毎に前記判定された従業員の人数を、前記管理者の数で平均して、人数を算出すること
を特徴とする請求項２に記載の評価システム。
【請求項４】
管理者の識別情報は、さらに管理者のデスクの配置情報を含み、
従業員の識別情報は、さらに従業員のデスクの配置情報を含み、
ビーコンの配置情報と対応する前記ビーコンの識別情報と、前記ビーコンに対面した識別情報とをさらに記憶し、
前記ビーコンに対面した識別情報は、第３の識別情報に関して対面した１つまたは複数のビーコンの識別情報と、対面した第２の時刻とを含み、
前記第３の識別情報に対応する前記デスクの配置情報を取得し、前記１つまたは複数のビーコンの識別情報に対応する前記ビーコンの配置情報と、前記取得したデスクの配置情報とが同一であるか場合、前記第３の識別情報の管理者あるいは従業員が休憩中であると判定し、
前記人数の算出は、前記第２の識別情報と前記第３の識別情報、および前記第１の時刻と前記第２の時刻とに基づき、前記判定された従業員の中で前記休憩中と判定された人数を算出すること
を特徴とする請求項３に記載の評価システム。
【請求項５】
ビーコンの配置場所が休憩スペースであるか否かの情報と対応する前記ビーコンの識別情報と、前記ビーコンに対面した識別情報とをさらに記憶し、
前記ビーコンに対面した識別情報は、第３の識別情報に関して対面した１つまたは複数のビーコンの識別情報と、対面した第２の時刻とを含み、
前記１つまたは複数のビーコンの識別情報に対応する前記ビーコンの配置場所が休憩スペースであるか否かの情報を取得し、前記取得した情報が休憩スペースである場合、前記第３の識別情報の管理者あるいは従業員が休憩中であると判定し、
前記人数の算出は、前記第２の識別情報と前記第３の識別情報、および前記第１の時刻と前記第２の時刻とに基づき、前記判定された従業員の中で前記休憩中と判定された人数を算出すること
を特徴とする請求項３に記載の評価システム。
【請求項６】
ビーコンの配置場所が休憩スペースであるか否かの情報と対応する前記ビーコンの識別情報と、前記ビーコンに対面した識別情報とをさらに記憶し、
前記ビーコンに対面した識別情報は、第３の識別情報に関して対面した１つまたは複数のビーコンの識別情報と、対面した第２の時刻とを含み、
前記第２の時刻以外の第３の時刻について、前記第３の時刻の前あるいは後の前記第２の時刻において、前記１つまたは複数のビーコンの識別情報に対応する前記ビーコンの配置場所が休憩スペースであるか否かの情報を取得し、前記取得した情報が休憩スペースである場合、前記第３の識別情報の管理者あるいは従業員が休憩中であると判定し、
前記人数の算出は、前記第２の識別情報と前記第３の識別情報、および前記第１の時刻と前記第３の時刻とに基づき、前記判定された従業員の中で前記休憩中と判定された人数を算出すること
を特徴とする請求項３に記載の評価システム。
【請求項７】
定期的に前記職場の状態を判定し、
前記判定した職場の状態に基づき、前記判定した職場の状態を表示させること
を特徴とする請求項３に記載の評価システム。
【請求項８】
前記設定された期間が入力され、
実行の指示に基づき、前記職場の状態を判定し、
前記判定した職場の状態を表示させること
を特徴とする請求項３に記載の評価システム。
【請求項９】
前記職位の判定は、前記第１の識別情報が従業員であり、前記第２の識別情報が管理者であることをさらに判定し、
前記従業員であると判定された第１の識別情報について、前記管理者と判定された第２の識別情報に対応する前記第１の時刻を累積して、対面時間を算出し、
前記算出した対面時間も、前記従業員であると判定された第１の識別情報に対応する従業員毎に、さらに表示させること
を特徴とする請求項８に記載の評価システム。
【請求項１０】
前記第１の時刻の累積は、前記管理者と判定された第２の識別情報毎に累積して、対面時間を算出し、
前記第１の識別情報に対応する従業員毎の表示の中の従業員が選択されると、
前記選択された従業員が判定された第１の識別情報について、前記第２の識別情報毎に累積して算出した対面時間も、前記管理者と判定された第２の識別情報に対応する管理者毎に、さらに表示させること
を特徴とする請求項９に記載の評価システム。
【請求項１１】
前記判定の結果に基づいて、前記職場に対する保険の掛金を算出することを特徴とする請求項１に記載の評価システム。
【請求項１２】
職場の状態を評価するシステムであって、
管理者の識別情報と、従業員の識別情報と、対面した識別情報および時刻とを記憶し、
前記管理者の識別情報と前記従業員の識別情報にしたがって、前記対面した識別情報が管理者であるか従業員であるかを判定し、前記従業員が対面した前記管理者の対面時間を、前記対面した時刻に基づき算出し、前記算出した対面時間を表示させること
を特徴とする評価システム。
【請求項１３】
職場の状態を管理するシステムであって、
管理者と従業員により着用され、識別情報を有し、他の名札型センサとの対面を検出して、対面した識別情報を送信する名札型センサと
評価システムと
を有し、
前記評価システムは、
前記名札型センサから前記対面した識別情報を受信し、
前記管理者の着用した前記名札型センサの識別情報と、前記従業員の着用した前記名札型センサの識別情報と、前記対面した識別情報とを記憶し、
前記管理者の着用した名札型センサの識別情報と前記従業員の着用した名札型センサの識別情報にしたがって、前記対面した識別情報が管理者であるか従業員であるかを判定し、前記管理者が対面した前記従業員の人数を算出し、前記算出した人数に基づいて職場の状態を判定すること
を特徴とする管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、評価システムおよび管理システムに関するものである。
【背景技術】
【０００２】
経営者にとって従業員の離職率が高いことは、人材募集や研修費用の増加につながり、大きな問題である。そこで、経営者はメンタルヘルス講習会や職場環境の改善など様々な施策を行っている。また、多くの企業では、管理者が従業員の行動を注視し、何か異常が見られればケアを行っている。この場合、管理者が多くの従業員の行動を注視し続けなればならず、管理者の負担が大きく、異常に気づくことができるかどうかは、管理者の能力に大きく依存している。【０００３】
このような従業員の管理に関して、特許文献１には、個々人の行動特性に基づいてメンタル面での健康状態を、早期に発見して対処可能とする従業員行動の管理方法及び管理システムを提供すると記載され、キーボードタイプや離席の頻度などの行動特性を基に、通常時での行動特性と比較して、異常な行動の従業員の対処を管理者に促す技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１１−１２３５７９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１に開示された技術によれば、従業員を管理するための管理者の負担を軽減することはできる。しかしながら、特許文献１に開示された技術は、個人の行動に依らず、職場全体を改善することができなかった。また、離職リスクまでは考慮されておらず、行動がおかしくない従業員を対象とすることができなかった。【０００６】
本発明は、上記に鑑みてなされたものであって、職場を改善し、従業員の定着率を向上させるために、職場全体の離職可能性を評価することを目的とする。
【課題を解決するための手段】
【０００７】
上述した課題を解決し、目的を達成するために、本発明にかかる代表的な評価システムは、職場の状態を評価するシステムであって、管理者の識別情報と、従業員の識別情報と、対面した識別情報とを記憶し、前記管理者の識別情報と前記従業員の識別情報にしたがって、前記対面した識別情報が管理者であるか従業員であるかの職位を判定し、前記管理者が対面した前記従業員の人数を算出し、前記算出した人数に基づいて職場の状態を判定することを特徴とする。
【発明の効果】
【０００８】
本発明によれば、職場全体の離職可能性を評価することが可能となる。これを基に職場改善の施策が可能となり、従業員の定着率を向上させることが可能となる。
【図面の簡単な説明】
【０００９】
【図１】管理システム全体の構成の例を示す図である。
【図２】休憩中に管理者が対面する従業員数と欠勤率との相関の例を示す図である。
【図３】対面情報データの例を示す図である。
【図４】ユーザ情報データの例を示す図である。
【図５】ビーコン情報データの例を示す図である。
【図６】ビーコン対面情報データの例を示す図である。
【図７】デスク以外の場所を休憩中と判定する処理フローの例を示す図である。
【図８】作業スペースでの検出以外を休憩中と判定する処理フローの例を示す図である。
【図９】対面従業員数と対面時間を集計する処理フローの例を示す図である。
【図１０】離職危険性の判定と危険順位付けする処理フローの例を示す図である。
【図１１】離職危険性を確認するための画面の例を示す図である。
【図１２】離職危険性を報告するための画面の例を示す図である。
【図１３】離職危険性を警告するための画面の例を示す図である。
【図１４】掛金を算出する処理フローの例を示す図である。
【発明を実施するための形態】
【００１０】
図１から図１３を用いて、本発明にかかる実施の形態を詳細に説明する。図１は管理システム全体の構成の例を示す図である。ユーザ（100a−100d）（以下、ユーザ（100a−100d）を個別に区別しない場合は、ユーザ（100）とする）は、赤外線センサを内蔵した名札型センサ（101a−101d）（以下、名札型センサ（101a−101d）を個別に区別しない場合は、名札型センサ（101）とする）をそれぞれ着用したユーザであって、職場の管理者あるいは従業員である。名札型センサ（101）が互いのIDの通信および時刻を記録することで、誰と誰がいつ対面しているか（以下、対面情報データ）を計測することが可能となる。
【００１１】
ここで、名札型センサ（101）は、赤外線センサを内蔵して対面を検出するものに限らず、対面情報データを測定可能であれば、他の種類のセンサによる対面の検出でも良い。例えば、名札型センサ（101a）と名札型センサ（101b）とが所定の距離内であり所定の角度範囲に存在することを互いに検出できるセンサであっても良い。また、センサは様々な場所に設置可能なビーコン（106）と通信することで、ビーコンのIDおよび通信時刻（以下、ビーコン対面情報データ）を記録する。センサにより取得された対面情報データおよびビーコン対面情報データは、ネットワーク（109）を介して、管理者が管理するデータサーバ（120）に格納される。
【００１２】
評価システム（110）は、データサーバ（120）と計算サーバ（130）を有し、対面情報データおよびビーコン対面情報データを蓄積して、解析処理を行うものである。データサーバ（120）は、一般的なコンピュータであっても良く、CPU（Central Processing Unit）（128）とメモリ（129）とネットワークI/F（Interface）（127）とデータベース（126）を有し、CPU（128）はメモリ（129）に格納されたプログラムにしたがって動作し、ネットワークI/F（127）とデータベース（126）との間でデータを転送する。また、ネットワークI/F（127）は、計算サーバ（130）との通信に用いられても良い。
【００１３】
データサーバ（120）は、名札型センサ（101）により収集された対面情報データ（121）およびビーコン対面情報データ（124）をデータサーバ（120）内のデータベース（126）に記録する。対面情報データ（121）およびビーコン対面情報データ（124）は、ネットワーク（109）を介してリアルタイムに通信を行い、情報を記録しても良いし、１時間毎や１日毎など一定時間ごとにまとめて通信を行い、情報を記録しても良い。
【００１４】
さらに、データサーバ（120）は、各ユーザー（100）が着用している名札型センサ（101）のノードIDとユーザ名などのユーザ情報データ（123）をサーバ内のデータベース（126）に記録する。また、ビーコンIDやビーコンの設置場所などのビーコン情報データ（124）を事前にデータベース（126）に記録する。以下では、上述した各データがHDD（Hard  Disk  Drive）内のデータベースに記憶されていることとして説明しているが、例えば、フラッシュメモリやSSD（Solid State Disk）などに記憶されてもよく、複数の記録装置に各種プログラム、各種データを分割して記録するようにしてもよい。以下に説明する計算サーバ（130）についても同様である。
【００１５】
計算サーバ（130）は、データサーバ（120）に蓄積されたデータから作業中か休憩中かを判定する休憩判定プログラム（135）、対面者の人数や対面時間を集計する対面者集計プログラム（136）、離職の危険性を判定する離職危険性判定プログラム（137）、保険などの掛金を算出する掛金算出プログラム（138）をストレージデバイス（134）に記憶し、これらのプログラムをメモリ（133）へ転送して、CPU（132）がこれらのプログラムを実行する。
【００１６】
このため、各プログラムを実行しているCPU（132）は処理部とみなしても良い。例えば、休憩判定プログラム（135）を実行しているCPU（132）は休憩判定処理部とみなしても良い。また、以下の説明においてプログラムが主語となる処理の主体はCPU（132）でも良く、主語をCPU（132）に置き換えても良い。
【００１７】
ネットワークI/F（131）は、図示を省略したネットワークあるいはネットワーク（109）経由でデータサーバ（120）と接続するためのインタフェースであり、データサーバ（120）のデータベース（126）を取得できる。データベース（139）は、休憩判定プログラム（135）、対面者集計プログラム（136）、離職危険性判定プログラム（137）の計算処理結果などが格納される。掛金算出プログラム（138）の計算処理結果が格納されてもよい。データベース（139）は、データベース（126）のデータの一部または全てがコピーされて、データベース（126）と同じデータが格納されてもよい。
【００１８】
ストレージデバイス（134）に格納された各プログラム群が実行される際は、計算サーバ（130）は、分析対象となるデータをデータサーバ（120）から読み出して、メモリ（133）へ一時的に格納し、CPU（132）で各プログラムをメモリ（133）に読み出して実行することにより、各種機能を実現する。
【００１９】
離職危険性判定プログラム（137）の実行結果などの情報は、図示を省略したネットワークI/FあるいはネットワークI/F（131）によりネットワーク（140）を介して、管理者（142）が使用するコンピュータ端末（141）に表示される。ここで、管理者（142）はユーザ（100）の中の管理者と同一であっても良い。また、ユーザ情報データ（123）とビーコン情報データ（124）の情報は、コンピュータ端末（141）により入力されても良い。さらに、コンピュータ端末（141）は、ネットワーク（140）を経由せずに、計算サーバ（130）へ直接に接続されても良い。
【００２０】
図１ではデータサーバ（120）と計算サーバ（130）が別のサーバである例を示したが、これら２つのサーバは１つのサーバであっても良いし、各データがそれぞれ別のサーバに格納され、各プログラムがそれぞれ別のサーバで実行されるシステムであっても良い。また、ネットワーク（109）とネットワーク（140）が別のネットワークである例を示したが、これら２つのネットワークは１つのネットワークであっても良い。
【００２１】
次に、発明者らが発見した休憩中における管理者が対面する従業員数と、翌日の従業員の欠勤率に相関について簡単に説明する。ここで、従業員とは、単純労働を行う作業従事者であり、管理者とは、従業員の離職低下に対して責任を負う者である。例えば、コールセンタにおけるテレマーケターが従業員であり、スーパーバイザーやチームリーダー、マネージャーが管理者である。また他の例として、飲食店や小売店舗におけるアルバイトが従業員であり、店長が管理者である。
【００２２】
また、休憩中における管理者が対面する従業員数と、従業員の翌日の欠勤率との間に相関があること、および、一般的に言われている欠勤率が増加すると離職する可能性が高くなることを利用することで、従業員へのケアの回数を抑えながらも、従業員の欠勤回数が増加する前に対策し、従業員の離職率を低下させることが可能となる。
【００２３】
図２は、あるコールセンタで実際に計測した管理者が休憩中に対面する1日の平均従業員数と、翌日の欠勤率との相関を示したグラフ（200）の例を示す図である。相関係数rが−0.35（p＜0.01）となっており、有意に相関があることが分かる。これは、休憩中に管理者が対面する従業員数が多いと、翌日の欠勤率が低くなることを示している。逆に、休憩中に管理者が対面する従業員数が少なくなると、翌日の欠勤率が高くなることを示している。
【００２４】
例えば、管理者へ警告を発する為に使用する閾値の計算は、休憩中に管理者が対面する従業員数と欠勤率の実データを基に計算する。実データから計算した１次関数（欠勤率＝相関係数r×休憩中に管理者が対面する従業員数＋切片）を用いて、平均的な欠勤率や管理者が許容できる欠勤率などを、１次関数の変数に代入することで、得られた解を閾値とする。ただし、この閾値の決定手順は一例であって、管理者が独自に指定するなどの手順でも良い。
【００２５】
図３は、データサーバ（120）内に格納される対面情報データ（121）の例を示す図である。図３に示す通り、対面情報データ（121）は１日毎に対面情報データ１（303）および対面情報データ２（310）の二つから構成され、例えば２０１４年９月２日のデータ（301）や２０１４年９月３日のデータ（320）などがある。対面情報データ１（303）にはノードID（304）、各時刻における対面人数の情報（305−309）が含まれている。ノードID（304）は名札型センサ（101）のIDであり、実質的にユーザ（100）を識別するためのIDとなる。
【００２６】
対面情報データ２（310）には、ノードID（311）と、対面したノードID（312−316）が対面時間の早いノードIDから順に含まれている。対面情報データ１（303）において時刻ｔの対面人数がk人の場合に、対面したノードIDが何番か知るためには、時刻ｔ−１までの対面人数の総和sを計算し、対面情報データ２（310）のs＋1番目からs＋k番目までを参照すれば良い。ノードID（304）とノードID（311）で共通する１つのIDに関する対面人数の情報（304−309）と対面したノードID（312−316）をレコードとする。
【００２７】
なお、図３に示した対面情報データ（121）はテーブルのデータ構造に見えるが、テーブルのデータ構造に限定されるものではなく、リスト等の他のデータ構造であっても良い。以下で説明する図４〜６のデータ構造についても、図示とは別のデータ構造であっても良い。
【００２８】
図４は、データサーバ（120）内に格納されるユーザ属性情報データ（123）の例を示す図である。図４に示す通り、ユーザ属性情報データ（123）は、各ユーザ（100）の着用する名札型センサ（101）のノードID（400）、ユーザ名（401）、各ユーザ（100）の職位（402）、各ユーザ（100）が利用しているデスク番号（403）などの情報が含まれる。ここで、便宜的に職位を管理者と従業員、システムを利用する人を管理者、管理者によって管理される人を従業員としている。システムを利用する管理者と従業員を区別可能であれば、他の職位でも良い。また、各ユーザ（100）に関する他の情報（404）が含まれても良い。
【００２９】
図５は、データサーバ（120）内に格納されるビーコン情報データ（124）の例を示す図である。図５に示す通り、ビーコン情報データ（124）は、ビーコンID（500）、配置場所（501）、配置座標（502）、作業判定（503）などの情報が含まれる。ビーコンID（500）はビーコン（106）を識別するためのIDである。
【００３０】
配置場所（501）は、ビーコン（106）を配置している場所を特定するものである。配置場所を特定できるのであれば、配置座標（502）のような形式でも良く、配置場所（501）と配置座標（502）のように複数の情報が含まれても良い。作業判定（503）は、管理者や従業員が作業中か休憩中かを判定するための情報であり、ビーコン（106）の設置される場所に応じて作業スペースか休憩スペースかが予め設定される。後で説明するように、作業判定（503）が休憩スペースであれば、休憩中と判定される。また、ビーコン（106）に関する他の情報（504）が含まれても良い。
【００３１】
図６は、データサーバ（120）内に格納されるビーコン対面情報データ（125）の例を示す図である。図６に示す通り、ビーコン対面情報データ（125）は、1日毎にビーコン対面情報データ１（602）とビーコン対面情報データ２（610）の二つから構成され、例えば２０１４年９月２日のデータ（601）や２０１４年９月３日のデータ（620）などがある。ビーコン対面情報データ１（602）にはノードID（603）、各時刻における対面したビーコンの数の情報（604−608）が含まれている。
【００３２】
ビーコン対面情報データ２（610）には、ノードID（612）と、対面したビーコンID（613−617）が対面時間の早いビーコンIDから順に含まれている。時刻ｔの対面ビーコン数がk個の場合に、対面したビーコンIDが何番か知るためには、時刻ｔ−１までの対面ビーコン数の総和sを計算し、ビーコン対面情報データ２のs＋1番目からs＋k番目までを参照すれば良い。ノードID（603）とノードID（612）で共通する１つのIDに関するビーコンの数の情報（604−608）とビーコンID（613−617）をレコードとする。
【００３３】
図７は、ユーザ情報データ（123）とビーコン情報データ（124）と指定された日付のビーコン対面情報データ（125）から、ユーザ（100）が作業中か休憩中かの判定結果をデータベース（139）に格納する処理フローの例を示す図である。この例は休憩判定プログラム（135）の処理フローの一例であり、ここでは休憩判定プログラム（135a）とし、別の例を休憩判定プログラム（135b）として図８を用いて説明する。
【００３４】
まず、計算サーバ（130）の休憩判定プログラム（135a）は、ユーザ情報データ（123）とビーコン情報データ（124）と指定された日付のビーコン対面情報データ（125）を読み込む（処理ステップ700）。既に説明したように、読み込まれたこれらのデータはメモリ（133）に格納されても良いし、データベース（139）に格納されても良い。次に、ユーザ（100）の中から１人のユーザを選択し、ビーコン対面情報データ（125）のユーザ１人分のレコードを読む（処理ステップ701）、すなわち、選択されたユーザの着用する名札型センサのノードIDと一致するノードID（603）とノードID（612）のレコードを読む。
【００３５】
読まれたレコードの各時刻に記録されたビーコンID（613−617）に対応するビーコン（106）の配置場所（501）と、選択されたユーザのデスク番号（403）とを比較する（処理ステップ702）。ある時刻でユーザのデスク番号（403）と一致している場合には、その時刻におけるユーザは作業中であったと判定し、不一致の場合には、その時刻におけるユーザは休憩中であったと判定する（処理ステップ703）。そして、これらの判定結果をデータベース（139）に格納する。以上の処理を最後のレコードに到達するまで、すなわちビーコン対面情報データ（125）に記録された全てのノードID（603、612）について判定するまで繰り返す（処理ステップ704）。レコードが最後の場合には処理を終了する（処理ステップ705）。
【００３６】
図８は、ユーザ情報データ（123）とビーコン情報データ（124）と指定された日付のビーコン対面情報データ（125）から、ユーザ（100）が作業中か休憩中かの判定結果をデータベース（139）に格納する処理フローの別の例を示す図である。図７を用いて説明した休憩判定プログラム（135a）の処理フローでは、ユーザ（100）が利用するデスクに設置したビーコン（106）のみで判定していたが、図８を用いて説明する休憩判定プログラム（135b）の処理フローでは、会議室などの作業スペースや、タバコ部屋などの休憩スペースにもビーコン（106）を設置し、ユーザ（100）が作業中か休憩中かを判定する。
【００３７】
まず、計算サーバ（130）の休憩判定プログラム（135b）は、ユーザ情報データ（123）とビーコン情報データ（124）と指定された日付のビーコン対面情報データ（125）を読み込む（処理ステップ800）。次に、ユーザ（100）の中から１人のユーザを選択し、ビーコン対面情報データ（125）のユーザ１人分のレコードを読む（処理ステップ801）。そして、読まれたレコードの各時刻でビーコンIDが記録されているかを判定する（処理ステップ802）。
【００３８】
各時刻でビーコンIDが記録され、ビーコン（106）の反応があった場合には、ビーコン情報データ（124）を基に、記録されていたビーコンIDに対応するビーコン（106）の配置場所の作業判定（503）が作業スペースか否かを確認する（処理ステップ803）。作業判定（503）が作業スペースの場合には、その時刻にユーザは作業中であったとして、データベース（139）に格納する（処理ステップ805）。また、作業判定（503）が休憩スペースの場合には、休憩中としてデータベース（139）に格納する（処理ステップ806）。
【００３９】
一方、特定の時刻でビーコン（106）の反応が無く、ビーコンIDの記録が無い場合には、その特定の時刻の前後に記録されたデータに基づき作業スペースか否かを確認する（処理ステップ804）。例えば、記録の無い時刻より前で最後に記録されたビーコンIDに対応する作業判定（503）が作業スペースであり、その記録の無い時刻より後で最初に記録されたビーコンIDに対応する作業判定（503）が作業スペースである場合には、すなわち前後の両方とも作業スペースの場合には、作業中としてデータベース（139）に格納する（処理ステップ807）。
【００４０】
また、記録の無い時刻より前で最後に記録されたビーコンIDに対応する作業判定（503）と、その記録の無い時刻より後で最初に記録されたビーコンIDに対応する作業判定（503）のいずれか一方あるいは両方が休憩スペースの場合には、休憩中としてデータベース（139）に格納する（処理ステップ808）。これらにより、ビーコン（106）の個数が少なく、職場全体を網羅するほど配置されていない場合であっても、ユーザ（100）が作業中か休憩中かを推定することができる。そして、読み込んだレコードが最後のレコードであった場合（処理ステップ809）には、処理を終了する（処理ステップ810）。
【００４１】
図９は、ユーザ情報データ（123）とビーコン情報データ（124）と指定された日付の対面情報データ（121）から管理者が休憩中に対面した従業員数と、従業員が休憩中に管理者と対面した時間を集計する対面者集計プログラム（136）の処理フローの例を示す図である。まず、計算サーバ（130）にある対面者集計プログラム（136）は、ユーザ情報データ（123）とビーコン情報データ（124）と指定された日付の対面情報データ（121）を読み込む（処理ステップ900）。次に、指定された日付に対して休憩判定プログラム（135）を実行する（処理ステップ901）。
【００４２】
ここで、休憩判定プログラム（135）の処理フローの例は、図７と図８を用いて説明したとおりであり、処理ステップ901で実行されるプログラムは休憩判定プログラム（135a）であっても良いし、休憩判定プログラム（135b）であっても良い。さらに、休憩判定プログラム（135a）を実行した後で、休憩判定プログラム（135b）を実行しても良い。ユーザ（100）の中から１人のユーザを選択し、対面情報データ（121）のユーザ１人分のレコードを読む（処理ステップ902）。
【００４３】
そして、選択されたユーザが管理者か従業員かを判定する（処理ステップ903）。すなわち、選択されたユーザの着用する携帯型センサのノードID（304、311）と一致するノードID（400）の職位（402）を判定する。選択されたユーザが管理者の場合、休憩判定プログラム（135）の実行結果である休憩中の情報を用いて、1日の間で休憩中に対面した従業員数を集計し、データベース（139）に格納する（処理ステップ904）。
【００４４】
例えば、ノードID（304）が管理者の着用する携帯型センサである場合、そのノードID（304）のレコードの各時刻における対面人数の情報（304-309）に対応するノードID（312-316）を取得し、取得したノードID（312−316）の中で、ノードID（400）と職位（402）の情報に基づき、従業員のノードIDに限定し、さらに休憩中の従業員のノードIDに限定して集計しても良い。この集計において、同じノードIDが複数記録されていても、１人と集計して、１人の従業員との複数回の対面の従業員数を１人と集計しても良い。
【００４５】
一方、選択されたユーザが従業員の場合には、休憩中に管理者と対面した時間を集計し、データベース（139）に格納する（処理ステップ905）。例えば、ノードID（304）が従業員の着用する携帯型センサである場合、そのノードID（304）のレコードの各時刻における対面人数の情報（304-309）に対応するノードID（312−316）を取得し、取得したノードID（312−318）の中で、ノードID（400）と職位（402）の情報に基づき、管理者のノードIDを特定し、管理者のノードIDに対応する時刻の中で休憩中の時刻を集計しても良い。
【００４６】
図３の例では、対面情報データ（121）へ１分ごとにデータが記録されているため、データが１つ記録されていた場合の対面時間を１分とし、データの記録されている数を累計しても良い。これらの処理をレコードが最後になるまで繰り返し、最後のレコードに到達した場合、処理を終了する（処理ステップ906）。
【００４７】
図１０は、離職危険性判定プログラム（137）の処理フローの例を示す図である。この処理フローの例は、離職危険性を判定するために利用するデータの期間が指定され、対面者集計プログラム（136）を実行することでデータを集計し、離職の危険性が高まっているか否かを判定し、さらに、管理者がケアした方が良い従業員に順位付けを行って、データベース（139）に格納する。まず、計算サーバ（130）にある離職危険性判定プログラム（137）は、離職危険性判定のために利用するデータの設定期間が入力される（処理ステップ1000）。
【００４８】
次に、対面者集計プログラム（136）を実行する（処理ステップ1001）。対面者集計プログラム（136）の実行結果に基づき、管理者の１人１日当たり平均対面人数を計算する（処理ステップ1002）。平均対面人数が事前に設定されている閾値より小さい場合、離職の危険性が高まっていると判断できる（処理ステップ1003）。そして、期間中における各従業員の１人または複数の管理者との対面時間の総和を計算し、総和が小さい順にソートする（処理ステップ1004）。ソート結果をデータベース（139）に格納し（処理ステップ1005）、処理を終了する（処理ステップ1006）。一方、平均対面人数が閾値より大きい場合、離職の危険性が高まってはいないと判断できるので、そのまま処理を終了する。
【００４９】
図１１は、管理者が従業員の離職危険性を確認するためのコンピュータ端末（141）の画面（1100）の例を示す図である。管理者（142）によりデータの判定期間（1101）の開始日（1102）と終了日（1103）が入力され、実行ボタン（1104）が押されることで、離職危険性判定プログラム（137）が実行される。この実行において、離職危険性判定プログラム（137）内で離職の危険性が高まっていると判断された場合には、判定結果（1110）として管理者（142）への警告（1111）と共に、管理者によってケアされる対象となる従業員のリスト（1112−1116）が順番に表示される。
【００５０】
表示の番号（1112）と従業員の名前（1113）毎に管理者との対面時間（1114）や欠勤率（1115）等が表示されても良い。また、ビーコン対面情報データ（125）がリアルタイムで収集されている場合には、従業員の所在（1116）を提示することで、管理者は従業員が休憩中であるところを見計らって会いに行くことも可能となる。なお、欠勤率（1115）は図示および説明を省略した一般的な出勤管理の情報が利用されても良い。また、１つの画面で全ての情報を表示できない場合、表示はスクロールバー1117によりスクロールが可能であっても良い。
【００５１】
図１２は、管理者へ従業員の離職危険性を報告するためのコンピュータ端末（141）の画面（1200）の例を示す図である。図１２は図１１と異なり、データ判定期間が事前に設定されており、確認のため管理者により実行ボタンが押されることなく、バックグラウンドジョブとして定期的に離職危険性判定プログラム（137）が実行され、離職の危険性が高まっていると判断された際にコンピュータ端末（141）に画面（1200）が表示される。画面の表示内容（1201-1207）は図１１を用いて説明した内容と同じである。
【００５２】
例えば、判定期間が事前に３日間と設定され、定期的な実行タイミングが毎日と設定されている場合、毎日その日を含めてその日より２日前までのデータを対象として離職危険性判定プログラム（137）を実行しても良い。なお、定期的なプログラムの実行は一般的に広く行われていることであるので、説明は省略する。また、名前（1204）がクリックされることにより、表示（1208）として順番（1209）を付けて管理者（1210）それぞれとの対面時間（1211）が提示され、対面時間の少ない管理者に積極的に対面を促すことが可能である。
【００５３】
図１３は、管理者へ従業員の離職危険性を警告するためのコンピュータ端末（141）の画面の例を示す図である。図１２と同様にデータ判定期間および閾値を事前に設定しておく。そして、離職の危険性が高まっていると判断された際に、図１２とは異なり、ポップアップ式にブラウザウィンドウ（1300）が自動的に開き警告する。なお、ポップアップ式のブラウザウィンドウは一般的に広く行われていることであるので、説明は省略する。
【００５４】
次に、本願発明の応用例の１つである、法人向けの保険について説明する。近年、上述した離職の問題や、従業員の気分障害、不安障害、統合失調症等の精神疾患が、企業において大きなリスクとなっている。そこで、離職や精神疾患による休業を補償する法人向けの保険が、従業員に安心を提供し、対外的に「安心して働ける環境を実現する企業である」というメッセージを発信する目的で、着目されている。
【００５５】
ここで、がん保険などの身体的疾患についての保険は、年齢を指標としてリスクを定量的に評価し、掛金を算出することが比較的容易である。これに対し、離職や精神疾患による休業は個人差が非常に大きいため、そのリスクを定量的に評価して、対象組織のアセスメントに基づく掛金の算出を適切に行うのが困難であった。
【００５６】
以上を踏まえ、図１４は、本発明による掛金算出プログラム(138) の処理フローの例を示す図である。ここで、離職率については、ここまで説明してきた考え方を適用する。また、欠勤率が増加すると、離職率同様に精神疾患の罹患率も高くなることが知られており、図２における知見は、精神疾患の休業補償における掛金算出にも適用することが可能である。この処理フローの例は、掛金を算出するために利用するデータの期間が指定され、対面者集計プログラム（136）を実行することでデータを集計し、保険の契約対象となる法人における職場の状態を判定し、離職リスク・精神疾病リスクを評価する。そして、当該評価を元に、保険の掛金を算出する。まず、計算サーバ（130）にある掛金算出プログラム（138）には、掛金算出のために利用するデータの設定期間が入力される（処理ステップ1000）。
【００５７】
次に、対面者集計プログラム（136）を実行する（処理ステップ1401）。対面者集計プログラム（136）の実行結果に基づき、管理者の１人１日当たり平均対面人数を計算する（処理ステップ1402）。そして、平均対面人数を用いて、対象組織のアセスメントに基づく掛金の算出を行い(処理ステップ1403)、処理を終了する（処理ステップ1404）。係る掛金算出プログラム(138)により、従業員の離職・精神疾患の罹患等のリスクを評価することがより容易となり、より適切に掛金を設定することが可能となる。なお、ここでは、平均対面人数と掛金の関係については詳述しないが、過去の事例から両者の関係をモデル化しておく等、平均対面人数を元に掛金を算出するノウハウが保険会社に蓄積されているものとしている。
【００５８】
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、実施例のある構成の一部を他の構成に置き換えることが可能であり、また、実施例のある構成に他の構成を加えることも可能である。また、実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【符号の説明】
【００５９】
１００…ユーザ、１０１…名札型センサ、１０６…ビーコン、１１０…評価システム、１２０…データサーバ、１２１…対面情報データ、１２３…ユーザ情報データ、１２４…ビーコン情報データ、１２５…ビーコン対面情報データ、１３０…計算サーバ、１３５…休憩判定プログラム、１３６…対面者集計プログラム、１３７…離職危険性判定プログラム、１３８…掛金算出プログラム、１４２…管理者、１４１…コンピュータ端末
【図１】
2016079827.tif 000003
【図２】
2016079827.tif 000004
【図３】
2016079827.tif 000005
【図４】
2016079827.tif 000006
【図５】
2016079827.tif 000007
【図６】
2016079827.tif 000008
【図７】
2016079827.tif 000009
【図８】
2016079827.tif 000010
【図９】
2016079827.tif 000011
【図１０】
2016079827.tif 000012
【図１１】
2016079827.tif 000013
【図１２】
2016079827.tif 000014
【図１３】
2016079827.tif 000015
【図１４】
2016079827.tif 000016
【国際調査報告】
2016079827.tif 000017
2016079827.tif 000018
2016079827.tif 000019
2016079827.tif 000020