JP2021163233A - 勤務管理システム、勤務管理方法、及び勤務管理プログラム - Google Patents

Abstract

【課題】ユーザが１以上の端末等の使用予定及び／または使用後のデータを統合して、そのユーザの勤務時間を把握する勤怠管理システム、勤怠管理方法及び勤怠管理データを提供する。【解決手段】勤怠管理システムは、１以上の仮想端末、ＦＡＴ端末、及び／または任意の端末にインストールされたアプリケーションにおける、１以上の前記端末等の使用予定及び／または使用後に発生するログオンなどのデータの種別及び発生時間を、使用状況を管理するログ情報として前記１以上の端末等のＩＤごとに統合した統合ログ情報と、前記使用予定情報に含まれる勤務予定情報を記憶する勤務実績管理テーブル１０４（統合ログテーブル）に基づいて、ユーザＩＤに対応するユーザの勤怠を示す稼働実績情報を生成する稼働実績管理部１０５と、を備える。【選択図】図１

Description

本発明は、ユーザの勤怠を管理する勤怠管理システムに関する。

特許文献１に記載の技術において、ユーザが業務に使用する仮想デスクトップ上の操作を検知し、ログイン操作が実行された時点を始業時刻、ログアウト操作または仮想デスクトップの閉操作が実行された時点を終業時刻として、ユーザの勤務時間を算出することが記載されている。

特開２０１９−４０４７７号公報

上記従来技術においては、今般の働き方改革に伴い仮想端末を含む多数の端末を使用する場合、例えば、必ずしも端末を業務で使用するためにログオン・ログオフを必要としないスマートフォンやタブレットなどの端末や、上記端末にインストールされたアプリケーション、システム監視などＩｏＴ端末を使用した遠隔で使用する端末や、移動手段に備わる端末を並行して使用することや、ユーザが端末を使用する場所や時間により端末を使い分けることや、業務目的なのか私用目的なのかで使い分けることを想定しておらず、これらの使用状況を想定してユーザの勤務時間を把握することができない。

また、上記従来技術においては、各システム上へのログオン及びログオフや上記端末の操作ログが個別に管理されることから、従来技術におけるログオン及びログオフ時間に基づく管理では、一定時間ユーザの端末操作がない場合にも全て勤務扱いとなる一方、単に端末操作がない時間を勤務外とすると、業務上のイベントで電車や自動車・バスなどの交通手段を用いて移動する場合、移動先の端末を利用するまでの移動時間を勤務扱いにできず、また勤務予定外の時間や場所で端末を使用する制約や、端末が業務用・私用・公共用かの使用に関する区別や、業務用でも本業か副業かの区別もない状況下では、その種別を考慮してユーザの管理者側が抑制すべき長時間労働を制約することができず、ユーザの勤務時間を適切に把握し管理することができない。

そこで、本発明は、上述の課題を解決するために、ユーザが様々な端末や上記端末内のアプリケーションを使用した場合においても、ユーザＩＤと関連付けられた統合ログ情報に基づき、そのユーザの勤務時間を適切に把握することができる勤怠管理システム及び勤怠管理方法と、その構成物である勤怠管理データを提供することを目的とする。

本発明の請求項１及び６に係る勤怠管理システム及び勤怠管理方法では、ユーザＩＤに基づいて識別される少なくとも１以上の仮想端末、ＦＡＴ端末、及び／または前記仮想端末及び任意の端末にインストールされたアプリケーションの使用予定及び／または使用後に発生するログオンなどのデータの種別及び発生時間を、使用状況を管理するログ情報として、前記１以上の端末等のＩＤごとに統合した統合ログ情報を、前記ユーザＩＤと関連付けて統合ログ情報として記憶する統合ログテーブルと、前記統合ログテーブルに基づいて、前記ユーザＩＤに対応するユーザの勤怠を示す稼働実績情報を生成する生成部と、を備える。

また、本発明の請求項２及び7に係る勤怠管理システム及び勤怠管理方法の前記統合ログ情報には、前記使用予定情報として前記ユーザの勤務予定情報がユーザＩＤ毎に対応つけて記録され、前記勤務予定情報及び端末等の使用状況を管理する前記統合ログ情報に基づいて、前記ユーザＩＤに対応するユーザの勤怠を示す勤務実績情報を生成する機能、を備える。

また、本発明の請求項３及び８に係る勤怠管理システム及び勤怠管理方法では、前記使用予定情報及び／または前記統合ログ情報に基づいて、勤怠状態であるか否かを判断する機能、をさらに備える。

また、本発明の請求項４及び９に係る勤怠管理システム及び勤怠管理方法では、前記使用予定情報に含まれる勤務時間と、前記統合ログ情報に基づき勤務している、または勤務していないと判断した時間との間に所定の時間差がある場合に、勤怠適正化のための処理を行う機能、をさらに備える。

また、本発明の請求項５及び１０に係る勤怠管理システム及び勤怠管理方法では、前記使用予定情報に含まれる勤務予定時間と、前記統合ログ情報に基づき勤怠していると判断した時間とに所定の時間差がある場合に、直前のイベントの場所から直後のイベントに関する場所までの移動時間に基づき勤怠確認処理を行う機能、をさらに備える。

請求項１及び６に記載の発明によると、少なくとも１以上の端末等の使用予定及び／または使用後に発生するデータの種別及び発生時間を、ユーザの端末等の使用状況としてユーザＩＤと関連付けて統合ログ情報として記憶することから、様々な端末等の使用状況からユーザの勤務実態を俯瞰して把握することができる。

また、本発明の請求項２及び7に記載の発明によると、使用予定情報としてユーザの勤務予定情報が記録されることから、前記勤務予定情報及び前記統合ログ情報に基づいて、ユーザの勤怠をより正確に把握することができる。

また、本発明の請求項３及び８に記載の発明によると、前記統合ログ情報に基づいて勤怠状態であるか否かを判断することから、公私に利用される端末等の使用状況であっても、ユーザの勤怠をより正確に把握することができる。

また、本発明の請求項４及び９に記載の発明によると、前記統合ログ情報に基づき適正化のための勤怠確認処理を行うことから、前記使用予定情報に含まれる勤務予定時間と、前記統合ログ情報に基づき勤務していると判断した時間との間に所定の時間差がある場合でも、ユーザの勤怠をより正確に把握することができる。

また、本発明の請求項５及び１０に記載の発明によると、前記使用予定情報に含まれる直前のイベントの場所から直後のイベントに関する場所のデータから移動時間を算出し、勤怠確認処理を行うことから、勤怠していると判断した時間と勤務予定時間との間に所定の時間差がある場合でも、ユーザのスケジューラ情報に基づき、勤怠をより正確に把握することができる。

本開示の一態様における勤怠管理システムの機能構成を示すシステム構成図である。 ログ情報の具体例を示す図である。 勤怠管理システムの処理シーケンスを示す図である。 勤務管理データの具体例を示す図である。 勤務実績表の具体例を示す図である。 勤務開始日時とログオン送信実績との間に所定時間間隔が空いたときの勤務実績表を示す図である。 ログオン送信実績等のログ情報が全くない勤務実績表を示す図である。 適正でない勤務実績表が生成された時に上長に通知される情報の具体例を示す図である。 ログ情報取得処理を示すシーケンス図である。 各端末５０を独立してログオンをして管理する処理を示すシーケンス図である。 単一の端末のみにログオンを許可する管理のためのシーケンス図（その１）である。 単一の端末のみにログオンを許可する管理のためのシーケンス図（その２）である。 本開示における勤務管理サーバ１００のハードウェア構成図である。

添付図面を参照しながら本発明の実施形態を説明する。可能な場合には、同一の部分には同一の符号を付して、重複する説明を省略する。

図１は、本開示の一態様における勤怠管理システムの機能構成を示すシステム構成図である。図１に示されるとおり、この勤怠管理システムは、勤務管理サーバ１００、総合ログ管理サーバ２００、及びスケジュール管理サーバ３００を含んで構成されている。端末５０（ユーザ端末５１〜ユーザ端末５４）は、それぞれその形態を変えた通信端末であり、それぞれノートパソコン、デスクトップパソコン、タブレット端末、スマートフォンである。

端末５０は、ユーザＩＤに基づいてログオンして使用可能な少なくとも１以上の業務で利用する端末（例えば、ＯＡ業務での利用端末として管理される仮想端末、ＦＡＴ端末、及び／または携帯端末やスマートフォン、タブレット）のほか、図示はしていないが、必ずしもログオンが端末の使用可能条件とはならない任意の端末（主に私的に利用されるが、業務での利用が可能な携帯端末やスマートフォン、タブレット、その他ＯＡ業務としての利用を想定していないＩｏＴ（Internet of Thing）関連のセンサを含む電子機器、ドローンなどの遠隔制御装置や、自動車に搭載された電子制御機器などを、遠隔端末から制御して使用する業務用の端末を含む）や、それらの端末等にインストールされたアプリケーション自体を、各々異なる端末として使用しても良い。また、遠隔端末には、仮想端末やクライアントＰＣをユーザが遠隔で操作する場合はもちろん、ユーザが直接操作を行わなくても、アプリケーションに基づいて操作を行い、その結果を監視する業務など、ＦＡ(Factory Automation)やＲＰＡ（Robotic ProcessAutomation）、ＡＩ（Artificial Intelligence）の操作対象である電子制御機器や、ロボット、ドローン、空を飛行する自動車、飛行機など、電子制御されている任意の端末であっても良い。

なお、仮想端末は仮想サーバ内に論理的に構築されたクライアントＰＣ等の仮想マシンであり、ユーザごとに割り当てられた領域を用いて、仮想化に必要なアプリケーションを起動可能な構成をとっている。そして、これらプリケーションを起動した結果表示される画面情報が、遠隔から接続する端末等に表示される。

よって１つの仮想端末は、仮想サーバへのアクセスが可能な複数の端末等から使用したとしても同じ仮想端末が表示されることになり、ログオン・ログオフや仮想端末にインストールされたアプリケーションの操作や監視等のログは、基本的に仮想サーバ内に一時的に蓄積される。

一方、仮想端末にログオンすることにより発生した、仮想端末の操作や監視等のログと、遠隔から接続する端末等（以下、遠隔端末という。）自体へのログオン・ログオフや、遠隔端末にインストールされたアプリケーションの操作や監視等のログとは独立しているため区別して管理され、特にスマートフォンやタブレットを遠隔端末として利用する際の遠隔端末に関するログは、仮想端末のログと基本的に異なるシステムでログ管理されている。

また、ＦＡＴ端末は、それぞれの企業内に設けられたネットワークやＳＯＨＯなどの好況に設置された職場環境やネットカフェ等に接続され、一般的なクライアントＰＣと同様にアプリケーションがその端末内にインストールされ、ログオン時に使用可能に構成されている。

必ずしもログオンが端末の使用可能条件とはならない任意の端末は、その端末のオペレーションシステムに応じたアプリケーションと、業務上の使用目的に応じたアプリケーションがインストールされ、基本的に異なるシステムでアクセス制限やログ管理が、必要に応じてされていて、インターネット等を介して、端末等のログ情報が使用可能となるように構成されている。

以下、本願発明の態様を説明する際には、端末５０として表現するが、上述する端末等を含むことは言うまでもない。

本開示の一態様における勤怠管理システムでは、これらユーザ端末５１〜ユーザ端末５４を含む任意の端末から、ユーザが一のユーザＩＤを使ってログオンすることにより、勤怠管理システムにおいて、ユーザの一元管理を行うことができる。以下、各構成要素について説明する。

まず、勤務管理サーバ１００の機能構成について説明する。勤務管理サーバ１００は、統合制御部１０１，端末ログ情報集約部１０２、出退勤適正化処理部１０３、勤務実績管理テーブル１０４（統合ログテーブル）、稼働実績管理部１０５（生成部）、適正稼働判定部１０６（判断部）、稼働実績テーブル１０７、及び画面ロック制御部１０８を含んで構成されている。

統合制御部１０１は、ネットワークを介して総合ログ管理サーバ２００と通信することにより、総合ログ管理サーバ２００から端末５０のログ情報を収集する部分である。

端末ログ情報集約部１０２は、総合ログ管理サーバ２００のログオン状況管理テーブル２０２から、端末５０のログオン／ログオフの情報、及び端末５０に対しログオン後に一定時間間隔（例えば5分間隔）でサーバ側から端末等の使用状況を監視する監視ログ情報を、統合制御部１０１を介して取得し、日単位・時系列で並び替え、端末ＩＤを同じにするログ情報をひとまとまりとして統合ログ情報として一覧化するための処理を行う部分である。

この統合ログ情報は、端末５０に対するスリープ操作、後述する端末ロック操作、例えばメール送信などのアプリケーションの操作など、ユーザが端末５０の操作を示した操作ログ情報や、端末５０の位置情報、ユーザによる端末５０の使用予定情報、端末５０へのアクセス履歴を示す情報を含んでもよい。また、そのほか勤務予定情報に記述されるユーザの出張若しくは外出のイベント情報、並びに当該イベント情報に対応する端末５０の位置情報またはイベント日時を含む関連情報を含んでもよい。

この使用予定情報は、勤怠管理の対象である業務で使用する可能性のある端末５０が、スケジュール管理サーバ３００にユーザのスケジュール情報と共に登録されていて、ユーザのスケジュールデータである勤務予定情報や、端末５０の使用予定情報、個々の予定情報にある勤務場所や出張若しくは外出の日時や場所に関する情報を取得し、これらの情報から登録済の端末５０のＩＤが、勤務予定時間内で使用される予定であるという情報である。

なお、ユーザが利用する端末５０をスケジュール管理サーバとは別のサーバで管理して良いことは言うまでもない。

この使用予定情報の管理レベルは様々であるが、登録済の全ての端末５０からのログインによる業務使用を認める、最も柔軟な端末５０の使用を認める管理レベルのほか、より厳格な端末５０の使用に限定する管理レベルでは、勤務場所が会社であれば会社に設置されるクライアントＰＣ（ＦＡＴ端末）に限定したり、勤務場所が自宅であれば自宅に設置され、主にユーザが私用で使用するクライアントＰＣ（ＦＡＴ）端末に限定したり、出張等の場所や時間に応じて、搬出等が可能なノートＰＣ、スマートフォンや、タブレット等を使用可能な端末ＩＤを選択した上で、管理する方法を取っても良い。

これらの業務用の仮想端末、クライアントＰＣ（ＦＡＴ端末）、スマートフォンやタブレット、主に私用で利用され業務でも利用する、仮想端末、クライアントＰＣ（ＦＡＴ端末）、スマートフォンやタブレットの端末製造番号などの端末５０を識別可能なＩＤが予め登録されている。本実施形態では、後述する月間稼働申請及び時間外申請の承認により定まるユーザの勤務予定時間を含め、統合ログ情報に含まれるログの種別及び出張等のユーザのスケジュール情報を含めてイベント情報と称する。

出退勤適正化処理部１０３は、端末ログ情報集約部１０２により取得された統合ログ情報から、ユーザＩＤごとの使用予定情報と、前記端末ＩＤごとに統合されたログ情報を、前記ユーザＩＤで関連付けて統合ログテーブルとし、勤怠管理レベルに応じて前記ユーザＩＤに対応するユーザの勤怠を示す勤務実績情報を生成する。

具体的には、例えばデスクワークを中心とするＯＡ業務に対し、最も柔軟な端末使用管理を行うレベルでは、登録済の端末５０の何れからの使用も許可し、その端末５０のＩＤ毎に統合された使用実績（間欠的に分断される時間の使用を含む）のある時間は、少なくとも業務利用を行っていて勤務実績があるとして勤務実績テーブルに格納し、端末５０のＩＤ毎の使用実績を時系列的に並べ、同じ時間に複数の端末５０の使用実績がある情報は重畳し、ユーザＩＤ毎に統合化した勤務実績管理情報（勤怠管理データ）を生成して、勤務実績管理テーブル１０４に記憶する。

ここで、端末使用管理のレベルによっては、勤務場所で使用する端末５０と、自宅や公共の職場スペースやカフェテリア内の端末、出張先などへの移動中に使用する携帯端末、スマートフォン、タブレットなどの端末５０を区別し、ユーザのスケジュール情報に基づき、適切な端末使用の実績だけを勤務実績とする管理を行っても良いし、端末５１〜端末５４の使用場所や使用時間を統合的に判断して勤務実績としても良い。

なお、予め端末使用管理を行う端末５０のＩＤ等を登録していない端末を急遽使用する必要があるときでも、後述する時間外使用申請と同様に、ユーザの上長にその使用理由と端末５０のＩＤを記載した端末利用申請を行い、承認された後に端末使用が許可されることは言うまでもない。

また、例示したデスクワーク業務以外の業務を中心とする、患者やお客様、取引先の担当者などと対面で役務を提供する、医療業務やお客様対応業務に従事するユーザに対しては、クライアントＰＣの使用実績の他に、例えば、業務連絡に利用する携帯端末、スマートフォン、タブレットの使用、特に通話実績やメール、ＳＭＳ、チャットなどの送信実績を中心に管理しても良い。

この場合、ユーザ自ら端末５０を使用した実績がない時間帯でも、入退室管理センサが取り付けられた会議室や診察室のセンサ情報から取得されたプレゼンス情報を含む統合ログ情報に基づき、勤務実態があったものとして勤務実績管理情報を生成して、端末５０の使用実績と重畳しても良い。

また、システム監視業務などにおいても、システムに不具合等が発生すれば遠隔からシステムを操作・再起動を行い、不具合等の対処を行うシステム監視担当者が、遠隔からシステム状況を監視するための遠隔端末５０の監視アプリケーションに関する起動状態や操作状態を、監視アプリケーションからログとして収集しても良く、あるいはシステム上のアクセス管理サーバからログを収集しても良く、これらの統合ログ情報から、ユーザの勤務実績があったものとしても良い。

さて、ユーザＩＤ毎に統合化した勤務実績管理情報が記憶された後に、前記使用予定情報に含まれる勤務予定情報及び／または前記統合ログ情報に基づいて、勤怠状態であるか否かを判断する、具体的には、３つのケースである、（１）前記使用予定情報のみ、（２）前記総合ログ情報のみ、（３）使用予定情報及び統合ログ情報の両方、に基づく勤務実績管理に分類され、夫々の処理が異なる詳細を説明する。

まず、（１）のケースは、もともとユーザが端末５０の使用予定を登録していたところ、何らかの要因で統合ログ情報が収集できなかった場合や、ユーザが新型コロナウィルスやインフルエンザウィルスなどの感染や体調不良等により、急遽、休暇を余儀なくされたりして、実際に業務上の端末５０の使用実績がない場合などが該当する。

勤務実績表には対象日の統合ログ情報が存在しないため、システム的には勤怠状態でないと判断できる。但し、実際にはユーザは対象日に勤務をして端末５０を使用していた場合でも、端末５０やシステム側の不具合により、ログオン情報を含む一切の統合ログ情報が取得できないことも想定されることから、詳しくは図３の説明にて後述するが、勤怠適正化のための処理を行うために、ユーザの上長に稼働実績確認通知を行い、ユーザとユーザの上長との間でやり取りされる勤務実績の確認及びユーザの上長による承認により、勤務実績がゼロの記録から、勤務予定時間通り勤務したことを認めても良い。

また、（２）のケースは、もともと休日などユーザが端末５０の使用予定が未登録である対象日に、何らかの要因で統合ログ情報が収集された場合や、従来技術の様に（とは言っても、様々な端末５０からのログを統合していないのは言うまでもないが）、端末５０からのログオン・ログオフ情報を用いて、最小限の勤怠管理を行う管理レベルを選択した場合に、前記総合ログ情報の中から、実際に業務上の端末５０の少なくとも１以上の使用開始及び使用終了のログや、各種ログ情報に基づいて、ユーザの勤務実績があったものと取り扱う場合などが該当する。但し、ＯＡ業務に従事するユーザが休暇申請や振替休日申請を漏らしたなどは論外として（これはユーザが事後でも休暇申請を行い、ユーザの上長に承認を得る必要があるが）、システム監視業務やお客様対応業務においては、システム都合やお客様都合により、休日に急遽勤務を行う必要性が生じた場合もあるため、（１）のケースと同様に、勤怠適正化のための処理として、ユーザの上長に稼働実績確認通知を行い、ユーザとユーザの上長との間でやり取りされる勤務実績の確認及びユーザの上長による承認により、勤務扱い又は振替勤務日として、勤務したことを認めても良い。また、私用端末からのログなど、業務上の使用でないログ情報が収集される可能性もあるため、ユーザとユーザの上長とのやり取りで、勤務扱いとしない処理を行っても良い。

また、（３）のケースは、使用予定情報に含まれる勤務予定時間及び統合ログ情報の両方に基づく勤務実績管理であり、本願発明において最も一般的なケースに適用され、多種多様な勤怠管理を可能とするものである。もともとユーザが端末５０の使用予定に含まれる勤務予定情報が、後述する月間稼働申請や時間外予定申請の承認に基づき登録されていて、ユーザ毎にスケジュール情報や使用予定の端末５０の違いや、様々な企業の業務形態や採用する勤務形態の違いはあるものの、端末５０のログ情報が時々刻々とログオン状況管理テーブル２０２に格納され、ユーザＩＤ及び１日単位（0時〜24時）でバッチ処理された統合ログ情報に基づく勤務実績情報が日常的に生成されるケースである。

例えば、その勤務実績時間（例えば9時28分〜20時8分）と、勤務予定情報（例えば9時30分〜20時）を出退勤適正化処理部１０３が比較し、所定の時間差（例えば15分）を超えて差分がない場合は、略勤務予定時間通りに勤務した者として取り扱い、生成した勤務実績時間を正しいものとして、稼働実績時間として登録し、実際に給与の対象となる稼働実績時間となる。

なお、ＯＡ業務に従事するユーザは、勤務予定時間に登録された端末５０を使用することが一般的である（というか端末がないと仕事にならない）ことから、一義的に使用予定情報として取り扱うことも可能である。また、勤務予定時間は、企業・業種・業務毎に様々であり、例えば、一般的なＯＡ業務では、日勤であれば9時〜17時30分など、医療従事者やシステム管理担当者など、夜勤であれば23時30分〜翌朝9時など、交代制であれば、16時から24時と23時30分〜翌朝9時など、非常勤であれば、毎週月・水・金の12時〜17時など、区分に応じて定められた時間帯を勤務時間として、企業ごとに設定している。また、シフト勤務制を採用する企業では、日勤の開始及び終了時間を前後1時間シフト可能とする勤務形態であり、その他、フレックスタイム制であれば、１日の勤務可能時間内に予め設定されたコア時間、契約社員、正社員、アルバイト、パートのような区分を用いて、柔軟に勤務時間を設定しても良い。

一方で、何らかのユーザの行動により、所定時間を超えて端末５０の操作ログを収集できないことを検知すると端末５０の機能でスリープしたり、勤務予定時間（分断勤務を含む）を超えて監視ログが統合ログ情報に収集され、監視サーバ側から画面ロックした時間（以下、ロック時間）が存在する場合がある。

それぞれの目的で制御された時間帯は、共通してユーザが業務を継続できない時間となるため、各企業の勤務管理方針に沿って、判断基準を各々設定することになる。使用予定時間（勤務予定時間）との時間差がある場合に、勤退適正化判断部にて、勤務確認処理（時間外申請や承認）を行った後の最適化後の勤務実績時間が、実際に給与支給の対象となる稼働実績時間となる。なお、スリープ処理は端末５０の消費電力を抑制するための端末側の処理で説明し、画面ロック処理はユーザの長時間労働を抑制するための監視サーバ側の処理で説明しているが、必ずしもこの場合に限定されることはなく、いずれの処理も端末５０にインストールされたアプリケーションにより処理しても良く、サーバ側で操作ログや監視ログに基づき処理しても良い。以降は、ユーザが端末５０を使用継続する場合には、パスワード等の認証や上長の承認が必要となるように設定しても良い。

ここで重要な点は、前記使用予定情報に含まれる勤務予定時間と、前記統合ログ情報に基づき勤務として稼働しているまたは稼働していないと判断した時間と、の間に所定の時間差がある場合に、様々な企業・業種・業務が存在する働き方に対し、如何にシステム的に可能な範囲で、統合ログ情報から効率的な勤怠適正化のための処理を行うことができるか、ということである。

上述するロック時間の勤怠扱いについては、各企業の勤務管理方針に沿って、判断基準を各々設定することになると説明したが、働き方改革を推進する観点で、業務利用を許可する端末５０の多様性することによる弊害も生じうる。例えば、多様な端末５０の使用を許可すると、ユーザが勤務したと判断すべき対象の統合ログ情報が増え、実際に業務を行っていたことを一概に否定できないロック時間（例えば、打合せや出張で席を外していた、端末は使用せず、業務資料や書籍を読み業務の検討をしていたなど）については、企業側が労働基準法違反を避けるために、ロック時間全てを勤務扱いとして不払い労働の可能性を排除する、即ちコンプライアンス重視の方針に基づく判断もあり得る。一方で、勤務予定時間を厳格に関する方針を採用する企業の例でいえば、打合せや出張などで席を外していた時間や、ユーザが属する企業の複数の勤務場所を行き来する時間や、又はお客様や取引先等の出張場所に移動したりする時間は、例えば統合ログ情報のスケジュール情報にある場所情報や、端末５０の位置情報を活用して、直前のイベントの場所から直後のイベントに関する場所までの移動時間をシステムが自動で算出したり、会議場所に設置されたＩｏＴ機器の情報に基づくプレゼンス情報を活用して、勤務扱いとして算出しても良い。また、仮想端末の使用のみに限定し、勤務時間外のロック解除までの時間は勤務扱いとせず、基本的に仮想端末がアンロック状態の時間（ログオンからロック処理までの時間）を、勤務扱いとすることも可能である。

ここまで説明したケースはあくまで一例であり、前記使用予定情報に含まれる勤務予定時間と、前記統合ログ情報に基づき勤怠していると判断した時間とに所定の時間差がある場合には、企業・業態・業務・勤務形態など、様々な企業の勤怠管理方針に基づき、勤怠確認処理を行っても良いことは言うまでもない。

なお、本願発明の勤怠管理システム及び勤怠管理方法等における出張等のスケジュール情報については、スケジュール管理サーバ３００から、出張をしたこと及びその時間帯を示す情報を勤務予定情報として取得し、実際にユーザがイベント情報に記された日時や場所を確認するため、端末５０から取得した位置情報などを含め、ログ情報の時系列順に挿入する。

勤務実績管理テーブル１０４は、出退勤適正化処理部１０３により生成された勤務実績管理情報を記憶するテーブルである。

稼働実績管理部１０５は、勤務実績管理テーブル１０４に基づいて、勤務実績表を生成する部分である。

適正稼働判定部１０６は、スケジュール管理サーバ３００においてユーザのスケジュール（勤務予定時間）及び勤務実績管理テーブル１０４に基づいて、勤務実績管理情報が適正であるか否かを判断する部分である。適正稼働判定部１０６は、適性ではないと判断した場合には、ユーザの職務上の上長に対して所定の確認処理を行う。

稼働実績テーブル１０７は、稼働実績管理部１０５により生成された勤務実績表を記憶する部分である。

画面ロック制御部１０８は、勤務予定時間外にユーザが各端末５０を使用したログ情報を受信した際、使用中の端末画面をロック制御する部分である。上長未承認の時間外労働を社員が行わないよう、長時間労働を抑制するためである。

つぎに、総合ログ管理サーバ２００について説明する。総合ログ管理サーバ２００は、通信制御部２０１及びログオン状況管理テーブル２０２を含む。

通信制御部２０１は、ネットワークを介して端末５０及び勤務管理サーバ１００、その他図示しない、異なるシステムで管理される端末５０のログ情報サーバと通信接続する部分である。

ログオン状況管理テーブル２０２は、通信制御部２０１を介して取得された、端末５０のアクセス状況や操作ログ、監視ログなどのログ情報を記憶する部分である。

具体的には、ログオン状況管理テーブル２０２は、ログオン／ログオフ処理や、スリープ処理、ユーザによる端末５０の操作処理、サーバからの定期監視信号に対する応答処理などの処理種別と前記処理が発生した時間を、それぞれの端末５０のアクセス状況を管理する図示しないサーバ等から取得し、自ら管理する対象端末５０のログ種別及び発生時間が、ログを取得する都度、端末５０のＩＤ毎に統合する前のログ情報（以降、総合ログと称する）として刻々と記憶される。

操作ログ情報は、端末５０が操作されていることを示す情報であり、端末５０にインストールされているアプリケーション毎に必要なログ情報を収集できるようにしても良く、その場合は、予め端末５０に各種ログを収集可能とする監視用アプリケーションがインストールしておく。

なお、前記図示しないサーバ等から本ログ管理サーバの管理下にない端末５０のアクセス状況等のログを取得する際には、通信の秘密に抵触しないよう、ユーザのプライバシーに配慮する必要がある。

特に、ユーザが端末５０を使用してメールを送信したログを取得する場合には、予め端末５０の使用を許可する際に、業務利用か否かを判断するため、メール送信先がお客様や取引先などが使用する宛先アドレスなのか、もしくはそれ以外の宛先なのかを確認する目的で、ユーザの操作等のログと共に収集されることに同意を得ておくことが望ましい。

また、本来は操作ログには該当しない、端末５０において所定時間操作されておらずスリープ状態となる処理や、監視ログに基づき、勤務時間外の端末５０の利用を抑止するため、画面ロックとなる処理も、統合ログ情報として取得され記憶される。具体的には図２に示されるログ情報を記憶する。図２に示されるとおり、少なくともログ情報は、時間、ユーザＩＤ、端末ＩＤ、ログの種別（内容）を含む。

つぎにスケジュール管理サーバ３００について説明する。スケジュール管理サーバ３００は、月間稼働処理部３０１及びスケジュールデータ記憶部３０２を含む。

月間稼働処理部３０１は、ユーザの勤務形態（フレックス勤務または定時制など）に応じて勤務予定日時を設定して、スケジュールデータ記憶部３０２に記憶する部分である。この設定操作は、ユーザ、その上長またはオペレータなど管理者により行われる。

このように構成された勤怠管理システムの処理について説明する。図３は、勤怠管理システムにおける勤怠管理方法の処理シーケンスを示す図である。

端末５０において、ユーザにより月間稼働申請及び時間外申請が行われる（Ｓ１０１、Ｓ１０２）。これはユーザが端末５０を操作することにより、スケジュールデータがスケジュール管理サーバ３００に登録される（Ｓ１０３）。

ユーザの上長は、上長端末５００（パソコン等）を操作することにより、スケジュール管理サーバ３００のユーザのスケジュールデータを参照して、その承認を行う（Ｓ１０４）。この承認動作は、上長がパソコンに表示される承認ボタン等をクリックすることにより行われる。

勤務管理サーバ１００において、予め定めたタイミング（例えば１日に一回など）で、出退勤適正化処理部１０３は、スケジュール管理サーバ３００のスケジュールデータに記述されている勤務開始日時及び勤務終了日時に基づいて、ユーザごとに、勤務開始日時及び勤務終了日時を記述した勤務実績管理情報（勤務実績管理テーブル１０４）の雛形を生成する（Ｓ１０５）。図４（ａ）は、勤務実績管理情報の雛形を示す。図に示されるとおり、ユーザＩＤ及び稼働日（勤務日）ごとに勤務開始日時、及び勤務終了日時が記憶されている。勤務開始日時が記述されていない欄は、休日、勤務がない日または休暇予定日を示す。

一方で、総合ログ管理サーバ２００において、通信制御部２０１は端末５０からログ情報（ログオン／ログオフ、監視ログ情報）を収集し、ログオン状況管理テーブル２０２に記憶する（Ｓ１０６）。また、通信制御部２０１は、スケジュール管理サーバ３００からユーザのスケジュール（出張イベント等）を収集し、ログオン状況管理テーブル２０２に記憶する。

そして、勤務管理サーバ１００において、所定のタイミング（例えば、１日に一回、所定時刻）で、端末ログ情報集約部１０２は、総合ログ管理サーバ２００からログ情報を収集して統合する。出退勤適正化処理部１０３は、勤務実績管理情報の雛形に対して、収集されたログ情報を適正化処理して記憶する（Ｓ１０７）。

ここで適正化処理（再テーブル化）について詳細に説明する。勤務実績管理情報は、データ取得時間により時系列で蓄積された総合ログ管理テーブルに格納された生データから生成される。そして、各端末５０の使用状況を管理するログ情報として、１以上の端末５０等のＩＤごとに統合してテーブルに格納される。図４（ｂ）は、統合して適正化処理された勤務実績管理情報の一例である。図４（ｂ）に示されるとおり、この勤務実績管理情報は、ユーザＡ（ユーザＩＤ：Ａ）の同一の稼働日ごと（ここでは2019/12/1）のログ情報が、そのアクセスした端末ＩＤごとに集約された情報である。例えば、図４（ｂ）においては、レコードＲ１は、ログオン送信実績及びログオフ送信実績として、端末５０（端末ＩＤ：Ａ）から送信されたログオン時間及びログオフ時間が記憶されている。監視ログ記録には、ログオンしてから所定時間（ここでは５分）おきにユーザ操作の有無に基づいたログ監視情報が記憶される。レコードＲ１では、９：３３から５分おきに監視ログが記録されたことを示している。

勤務予定時間外に端末の監視ログ等が一定時間（例えば15分）検出されると、今現在使用している端末のほか、ログオフしていない他の端末も一括で画面ロック制御を行う。これは、業務未命令の時間に勤務することを抑止し、長時間労働を抑制するなどの勤怠適正化を図る機能である。

勤怠適正化の対象は以下の通りである。

（１）勤務予定時間内で勤務していないと判断した時間に、例えば1時間以上の差がある場合は、上長へデータが送信され、未稼働時間として表示される。上長がユーザに確認して、その時間の勤務実態を確認し、勤務でないのであれば時間休を、勤務であればその旨を記入し、承認する。その処理により勤務時間が適正化される。

（２）勤務予定時間外で勤務していると判断した時間に、例えば、5分おきの監視ログが計3回蓄積され、15分間の端末５０の使用実態が、休日や平日の勤務予定時間を超えて、統合ログ情報に基づき検出されると、業務未命令として現在利用している端末５０を画面ロック制御し、発生した時間を上長に連絡する。その連絡を受けた上長は、勤務実態をユーザに確認し、勤務であれば勤務予定時間の修正を指示し、勤務でなければ、監視ログ等により通知されたアラームの原因を確認し、勤務ではない旨の処理を登録する。これによりユーザの勤務時間が適正化される。 出退勤適正化処理部１０３は、ログオン送信実績及びログオフ送信実績の間に同じ端末から送信された監視ログ情報を一つのレコードとして集約する。

同様に、出退勤適正化処理部１０３は、ログオン時間のみ取得し、ログオフ時間を取得できなかった場合には、同じ端末において、ログオン時間以降における監視ログのうち、監視ログにおいてスリープ状態が確認された時間までの監視ログを、一つのレコードに集約する。レコードＲ２では、端末ＩＤ：Ｅの端末５０から送信されたログオン時間、１０：２５〜１３：３０の間に５分おきに監視ログが記録されたことを示し、１０：５０に一旦スリープ状態になったことを示す。レコードＲ２１では、その後、１０：５５に再度ログオンし、１３：３０に再度スリープ状態になったことを示す。よって、レコードＲ２及びレコードＲ２１をあわせて、ユーザの勤務時間は、１０：２５から１３：３０と判断できる。

レコードＲ３は、ログオフ時間及びスリープ時間のいずれも記憶されていない。これは、端末Ｂ（端末ＩＤ：Ｂ）を使用している最中にスマホＤからログオンしたためである。出退勤適正化処理部１０３は、ログオン時間からつぎのログオン時間までの間に、端末ＩＤを同じにするログオン時間及び監視ログを一つのレコードＲ３に集約する。レコードＲ３では、ログオン時間が１４：５８であり、その後５分おきに監視ログが記録されている。そして、端末Ｂ（端末ＩＤ：Ｂ）をログオフすることなく、スマホＤをログオンしたため、スマホＤのためのレコードＲ４が集約されている。ここでは、スリープ時間は１６：４５であることから、勤務時間は１６：１５〜１６：４５と判断できる。

レコードＲ５では、１７：０２に端末Ｃ（端末ＩＤ：Ｃ）からログオンされている。その後、５分おきに監視ログが記録されている。このとき、勤務予定時間が過ぎてログオン状態となったため、１８：０５に一旦、画面ロック（または端末ロック）状態となる。監視ログは、１７：０２〜２０：０２まで記録されている。よって、勤務時間は１７：０２〜２０：０２までと判断できる。

稼働実績管理部１０５は、勤務実績管理テーブル１０４の各レコードを参照して、勤務実績表を生成する（Ｓ１０８）。図５は、勤務実績表の具体例である。レコードＲ１１は、図４（ｂ）に示される勤務実績管理テーブル１０４のレコードＲ１〜レコードＲ５までの各レコードを集約して、稼働実績としてあらわした情報である。

具体的には、稼働実績管理部１０５は、勤務実績管理テーブル１０４の同一稼働日における複数のレコードを一つに集約するとともに、最早監視ログ時刻及び最遅監視ログ時刻を、勤務実績管理テーブル１０４のログオン送信実績及びそのほか監視ログから導出して、勤務実績表に記述する。また、稼働実績管理部１０５は、勤務実績管理テーブル１０４を参照して、端末ロック開始（時刻）、端末ロック終了（時刻）、スリープ最早時間、スリープ最遅時間を、勤務実績表に記述して生成する。

つぎに、図３において、適正稼働判定部１０６は、生成された勤務実績表は正当であるか否かを判断する（Ｓ１０９）。具体的には、適正稼働判定部１０６は、スケジュール管理サーバ３００の承認済のスケジュールデータに基づいて記述された勤務実績表における勤務開始日時及び勤務終了日時と、最早監視ログ時刻及び最遅監視ログ時刻とを比較することにより、前記勤務実績表が適性であるか否かを判断する。なお、勤務実績表にスケジュールデータが反映されていない場合には、スケジュールデータと比較する。

例えば、適正稼働判定部１０６は、勤務実績表におけるログオン送信実績（または最早監視ログ時刻）と勤務開始日時とを比較し、その時間差が所定時間以上であるか否かに基づいて適性であるか否かを判断する。同様に、ログオフ送信実績（または最遅監視ログ時刻）と、勤務終了日時とを比較する。

稼働実績管理部１０５は、適正稼働判定部１０６によりその勤務実績管理情報が適性であると判断されると、生成した勤務実績を給与支払い対象としての稼働実績として稼働実績テーブル１０７に記憶する（Ｓ１１１）。なお、稼働実績登録の時間単位は、勤怠管理方針で定める勤務時間単位や画面ロック処理までの監視時間、適正化の判断基準時間との相関性から15分単位で設定しても良く、また1分単位で設定しても良いが、給与支払の対象となる稼働時間は、上記単位御南の時間を切り上げとし、賃金不払いとならないよう設定することが望ましい。

一方で、適正稼働判定部１０６は、上記時間間隔が所定時間以上であると判断すると、この勤務実績は適性ではないと判断する（Ｓ１１０：Ｎｏ）。この場合、適正稼働判定部１０６は、勤務実績確認処理を行い、例えば、所定の上長端末５００（ユーザの上司の端末）に稼働実績確認通知を送信する。上長は、この通知を受け、ユーザの勤務実績の妥当性を判断する。

ところで、勤務実績表を生成する際に、勤務実績管理テーブル１０４の各レコードにおいて、ログオフ時間（またはスリープ時間）から、つぎのログオン時間までの間隔が所定時間未満である場合がある。上述の説明では、稼働実績管理部１０５は、これを無視して、ログオン送信実績、そのほか各種ログ情報を含んだ勤務実績表を生成したが、上記の通り各レコード間において、所定時間間隔が空いている場合がある。その場合も、スケジュール管理サーバ３００の勤務予定時間と比較の上、勤務実績表は適正なものではないと判断する場合には上長確認をとるよう、適正稼働判定部１０６は動作する。

例えば、適正稼働判定部１０６は、レコード間に所定の時間差があったとする。直前のレコードのログオフ時間またはスリープ時間（または監視ログ時間の最後の時間）と、その直後のレコードのログオン時間との間が所定時間以上空いているとする。

適正稼働判定部１０６は、スケジュール管理サーバ３００を参照して、該当する日時及びその時間帯に、外出または出張、若しくは時間休のスケジュールの有無を判断することで、勤務実績表が妥当であるか否かを判断する。

その際、出張先または外出先の位置情報に基づいて移動時間を考慮するようにしてもよい。例えば、スケジュールデータに記述される位置または場所を特定する情報と、ログ情報に記述されている場所情報との距離に基づいて、その空きは移動時間であると判断する。なお、ログ情報の位置は、ＧＰＳそのほかアクセスポイントの情報に基づく。

不適正である場合には、後述する稼働実績確認通知に、その時間帯に勤務実態無しの旨の情報を含める。

上長端末５００において、稼働実績確認通知を受領すると（Ｓ１１２）、上長は、その内容に基づいて修正が必要か否かを判断する（Ｓ１１３）。修正が必要であると上長が判断すると、上長の操作に従って上長端末５００は、端末５０に対して勤務時間の修正を求める為の通知を送る。これを受けた端末５０は、承認済み申請内容の再申請処理を行う（Ｓ１１４）。

スケジュール管理サーバ３００において、月間稼働処理部３０１はスケジュール情報を修正し（Ｓ１１５）、上長端末５００にその旨を通知する。上長端末５００において、スケジュール情報の修正の通知を受け、情報はその承認操作を行う（Ｓ１１６）。

勤務管理サーバ１００において、その承認操作に基づいて勤務実績表が生成されて記憶される（Ｓ１１０）。例えば、ユーザの再申請に応じて、勤務開始日時または／及び勤務終了日時が変更された勤務実績表が生成される。なお、ユーザが、勤務時間帯において、時間休をとった場合には、勤務実績表に別途欄に時間休の時間帯を設け、前記時間休欄にその時間を記録する。

つぎに、ステップＳ１０９における処理について具体例を用いて詳細に説明する。図６は、勤務開始日時とログオン送信実績との間に所定時間間隔があいたときの稼働実績テーブル１０７の具体例である。レコードＲ２１において、勤務開始日時とログオン送信実績との間に所定時間として５５分の時間間隔があいている。また勤務終了日時とスリープ最遅時間との間が１時間である。

この場合、適正稼働判定部１０６は、上長端末５００にその旨を通知する。上長は上記した通り上長端末５００を操作することにより、ユーザに確認を行う。ここでは、ユーザは、勤務開始日時を１０：００に、勤務終了日時を１６：３０に修正するか、時間休暇の遡及申請を行い、スケジュールデータを修正する。稼働実績管理部１０５は、スケジュールデータの修正に伴って、上記稼働表を修正する処理を行う。ここでは、勤務開始日時及び勤務終了日時を更新することになる。

図７は、ログオン送信実績等のログ情報が全くない勤務実績表を示す図である。図に示される通り、レコードＲ３１において、ログオン送信実績等が記憶されていない。これは、ユーザが急な休暇を取得したときに生ずる。適正稼働判定部１０６は、情報の欠落があった場合には、適性ではないと判断し、上長端末５００にその確認処理を行う。上長は、ユーザに確認し、休暇の遡及申請を行うよう対応する。

図８は、適正ではない勤務実績表が生成された時に上長に通知される情報の具体例を示す図である。

図８（ａ）は、勤務実績表を示す。適正稼働判定部１０６は、勤務開始日時と最早監視ログ時刻とを比較し、また勤務終了日時とスリープ最遅時間とを比較し、その時間差が所定時間以上である場合に、図７（ｂ）に示す情報が上長端末５００に送信される。この情報には、区分として未就業であることが示されている。区分を示す情報は、勤務管理サーバ１００において自動的に上記の通りの時間差があった場合に判断不能として付加される情報である。上長は、この情報をみて、必要に応じて承認し、またはユーザに確認をとる。

つぎに、図９〜図１２を用いて、総合ログ管理サーバ２００における各種ログ情報の取得処理について説明する。図９は、一般的なログ情報の取得処理を示すシーケンス図である。

仮想端末等において、ユーザはログオン操作を行うと、ログオン要求を認証サーバに対して送信する（Ｓ２０１）。認証サーバ４００は、各端末５０のログオンに対する認証を行うサーバである。認証サーバ４００は、ログオン要求時にユーザ入力されたパスワードに基づいて認証処理を行う（Ｓ２０２、Ｓ２０３）。ここでは所定のパスワードのほか、ワンタイムパスワード（ＯＴＰ）を用いた認証を行う。ワンタイムパスワードは、ユーザが勤務予定時間外に端末を使用する際に、ユーザの申請により上長により発行されるパスワードである。ここで認証が否認されると、再度Ｓ２０１に戻る。

認証が許可されると、端末５０は、ログオン状態となり、操作可能となる（Ｓ２０４）。また、総合ログ管理サーバ２００において、ログオン状況管理テーブル２０２に、ログオン時間がユーザＩＤ及び端末ＩＤに対応付けて記憶される（Ｓ２０５）。

端末５０は、所定時間、入力検知がされなくなると（Ｓ２０６：ＮＯ）、スリープ状態となる（Ｓ２０７）。一方で、端末５０は、所定時間内に入力検知をすると（Ｓ２０６：ＹＥＳ）、その操作ログをその時刻とともに保存し、またはスリープ状態をその時刻とともに保存する（Ｓ２０８）。そして、端末５０は、定期的に操作ログ及びスリープ状態を監視ログとして送信する（Ｓ２０９）。

総合ログ管理サーバ２００は、監視ログを受信し、監視ログをログオン状況管理テーブル２０２に記憶する（Ｓ２１０）。ステップＳ２０５〜ステップＳ２１５がログオン後処理として行われる。

総合ログ管理サーバ２００は、監視ログをチェックし、勤務予定時以外の使用であったり、勤務で使用する端末５０を１台に制限する管理レベルを採用した企業であれば、端末５１を使用である場合に（Ｓ２１１）、他の端末５２〜５４に対して端末ロック操作を行う（Ｓ２１２）。なお、勤務予定時間は、あらかじめスケジュール管理サーバ３００から取得してもよい。また、ユーザが使用する端末ＩＤを事前に登録しておき、それに基づいて他端末使用を判断してもよい。

端末５０は、端末ロックがなされると、ユーザ操作に従って、復帰処理するか（Ｓ２１３）、ログオフまたはシャットダウン処理を行い（Ｓ２１４）、ログオフ状態となる（Ｓ２１５）。復帰処理はワンタイムパスワードによる照合により行われる。

このようにして、総合ログ管理サーバ２００に、端末５０のログオン情報または監視ログがその時間とともに記憶される。

図１０は、各端末５０を独立してログオンをして管理する処理を示すシーケンス図である。ここでは、ユーザ端末５１〜ユーザ端末５３がそれぞれ独立してログオンしたときを示す。

ユーザ端末５１において、ログオン要求を行うと（Ｓ３０１）、認証サーバ４００に対して認証処理を行い（Ｓ３０２）、認証が許可されるとログオン状態となる（Ｓ３０３）。また、認証サーバ４００は、総合ログ管理サーバ２００に対して、ユーザ端末５１がログオン状態であることを通知する。

以降、上記したログオン後処理（Ｓ３０４）を行い、ログオフ等を検知すると（Ｓ３０５）、その旨を認証サーバ４００に送信する（Ｓ３０６）。認証サーバ４００では、ログオフの通知に基づいて、認証を解除する。また、ユーザ端末５１においてもログオフを行う（Ｓ３０７）。

ユーザ端末５２及びユーザ端末５３においても同様に独立してログオン及びログオフ処理が行われる（Ｓ３０１ａ〜Ｓ３０７ａ、Ｓ３０１ｂ〜Ｓ３０７ｂ）。

図１１は、単一の端末のみにログオンを許可する管理のためのシーケンス図である。ユーザ端末５１において、ログオン要求がなされると（Ｓ４０１）、ユーザはパスワードを入力することで、認証サーバ４００は、パスワードの照合及び認証がなされる（Ｓ４０２）。認証サーバ４００において、ユーザ端末５１からの認証が許可されると、ユーザ端末５１はログオン状態となる（Ｓ４０３）。その後、ユーザ端末５１において、上記したログオン後処理が行われる（Ｓ４０４）。

このとき、ユーザ操作によりユーザ端末５２においてログオン要求がされる（Ｓ４０５）。認証サーバ４００において、ログオン要求に対してパスワードの照合及び認証がなされる（Ｓ４０６）。ここで許可されると、ユーザ端末５１において、端末ロックがなされる（Ｓ４０７）。また、ユーザ端末５２においては、ログオン状態となる（Ｓ４０８）。また、総合ログ管理サーバ２００においては、ユーザ端末５１がロック状態であること、ユーザ端末５２がログオン状態であること、及びそれらの時間が記憶される（Ｓ４０９）。その後、ユーザ端末５２において、ログオン後処理が行われる（Ｓ４１０）。

また、ここでユーザ端末５３においてログオン要求がなされる（Ｓ４１１）。認証サーバ４００において、ユーザ端末５３からログオン要求で入力されたパスワードに対する照合及び認証が行われる（Ｓ４１２）。ここで認証が許可されると、ユーザ端末５２は、ロック状態となる。また、ユーザ端末５３はログオン状態となり（Ｓ４１４）、その後、ログオン後処理が行われる（Ｓ４１６）。また、総合ログ管理サーバ２００において、ユーザ端末５２がロック状態となり、ユーザ端末５３がログオン状態となる情報が記憶されるとともに、その時間が記憶される（Ｓ４１５）。

ここで、ユーザ端末５１において、ユーザ操作によりロック解除要求がなされると（Ｓ４１７）、認証サーバ４００において、再認証処理が行われる（Ｓ４１８）。これはログオン要求に対する照合及び認証処理と同じである。ここで許可されると、ユーザ端末５１はロック解除状態となり、ログオン状態となる（Ｓ４１９）。ユーザ端末５３において、ロック状態となる（Ｓ４２０）。総合ログ管理サーバ２００において、ユーザ端末５１がロック解除状態であり、ユーザ端末５３がロック状態となることが記憶されるとともに、その時間が記憶される（Ｓ４２１）。

ユーザ端末５１において、ログオフ操作によりログオフとなると（Ｓ４２２）、ユーザ端末５１はログオフ状態となる。そして、認証サーバ４００において認証が解除され（Ｓ４２４）、総合ログ管理サーバ２００において、ユーザ端末５１がログオフ状態であること及びその時間が記憶される（Ｓ４２５）。

図１２を用いて引き続き説明する。図１２は、図１１の処理シーケンスの引き継いだ処理シーケンスを示す。

ユーザ端末５２において、ロック解除要求がなされると（Ｓ５０１）、認証サーバ４００において再認証処理が行われる（Ｓ５０２）。ここで再認証処理が許可されると、ユーザ端末５２において、ロック解除状態となる（Ｓ５０３）。また、総合ログ管理サーバ２００において、ユーザ端末５２がロック解除したこと及びその時間が記憶される（Ｓ５０４）。

ユーザ端末５２において、ロック解除がされ、その後ユーザ操作によりログオフがされると（Ｓ５０５）、ユーザ端末５２は、ログオフ状態となる（Ｓ５０６）。認証サーバ４００において、ユーザ端末５２のログオフに応じて、認証が解除される（Ｓ５０７）。そして、総合ログ管理サーバ２００において、ユーザ端末５２がログオフ状態であること、及びその時間が記憶される（Ｓ５０８）。

ユーザ端末５３において、ユーザ操作によりロック解除要求がなされると（Ｓ５０９）、認証サーバ４００において再認証が行われ（Ｓ５１０）、ユーザ端末５３は、ロック解除状態となる（Ｓ５１２）。また、総合ログ管理サーバ２００において、ユーザ端末５３がロック解除状態となったこと及びその時間が記憶される（Ｓ５１１）。

ユーザ端末５３において、ロック解除後、ログオフがなされると（Ｓ５１３）、ユーザ端末５３は、ログオフ状態となる(Ｓ５１４)。また、認証サーバ４００において、認証解除がなされ（Ｓ５１５）、総合ログ管理サーバ２００において、ユーザ端末５３がログオフしたこと及びその時間が記憶される（Ｓ５１６）。

図１３は、本開示における勤務管理サーバ１００のハードウェア構成図である。図１３に示される勤務管理サーバ１００は、物理的には、図１３に示すように、一または複数のＣＰＵ１１、主記憶装置であるＲＡＭ１２及びＲＯＭ１３、入力デバイスであるキーボード及びマウス等の入力装置１４、ディスプレイ等の出力装置１５、ネットワークカード等のデータ送受信デバイスである通信モジュール１６、ハードディスクまたは半導体メモリ等の補助記憶装置１７などを含むコンピュータシステムとして構成されている。図１における各機能は、図１３に示すＣＰＵ１１、ＲＡＭ１２等のハードウェア上に所定のコンピュータソフトウェアを読み込ませることにより、ＣＰＵ１１の制御のもとで入力装置１４、出力装置１５、通信モジュール１６を動作させるとともに、ＲＡＭ１２や補助記憶装置１７におけるデータの読み出し及び書き込みを行うことで実現される。

つぎに、本開示における勤怠管理システムの作用効果について説明する。勤怠管理システムにおいて、ユーザＩＤに基づいてログオンして使用可能な少なくとも１以上の仮想端末、ＦＡＴ端末、及び／または仮想端末及びＦＡＴ端末以外の端末にインストールされた業務用アプリケーションの使用状況に基づき、前記ユーザの勤怠を管理するシステムである。

この勤怠管理システムは、１以上の仮想端末、ＦＡＴ端末、及び／または端末を使用したログオン以降に発生するイベントの発生時間を、前記１以上の端末それぞれの端末ＩＤごとに統合した統合ログ情報である勤務実績管理情報を記憶する勤務実績管理テーブル１０４（統合ログテーブル）と、勤務実績管理テーブル１０４に基づいて、ユーザＩＤに対応するユーザの勤怠を示す稼働実績情報を生成する稼働実績管理部１０５と、を備える。

この構成により、ユーザが、そのユーザＩＤを使用して、複数の端末５０（仮想端末、ＦＡＴ端末、それ以外の端末）を断続的に使用した場合においても、勤務管理サーバ１００は、一元的にユーザの使用状況を管理することができる。したがって、その使用状況に基づいてユーザの勤務状況を把握することができる。

ところで、本開示において、別システムで端末５０等の管理をされているデータ（スマホアプリ操作ログ、例えば他社携帯会社のサーバや、勤怠管理システムを利用企業内のＦＡＴ端末ログ管理システム）は、電気通信事業者に課せられる通信の秘密や法律により、ログ収集することが困難である。

そこで、本開示では、例えば勤怠管理システム又はそのアプリケーションが、ユーザによるアプリケーションインストール時（この際に、ユーザＩＤや端末ＩＤを一意に区別して一元管理ができるように、仕組まれています）のログ取得に関し、インストールすることにより同意したものとみなす、例えばシュリンクラップ契約などの、ログ取得及び利用に関する同意がなされることを前提とする。

また、業務目的で電話している時間（この間は端末操作がほぼない）も勤務扱いとするため、例えば携帯端末やスマートフォンのログ情報として、通話記録（例えば発信日時と発信先電話番号のマスク後のデータのみなど）や各種の個人情報を、法令違反とならない範囲で、取得することができるものとする。

これにより、ユーザまたはユーザの端末等を管理する企業ではない、当社が通信の秘密を侵すことなく、管理対象として登録された端末等からログデータを収集することができる。

こういった前提において、本開示において、収集データは、まずログの取得時間ごとに時系列で蓄積されるため、端末ＩＤやユーザＩＤに関係なく、生データとして順次、総合ログ管理サーバ２００のログオン状況管理テーブル２０２に蓄積される。

その総合ログ管理サーバ２００のログオン状況管理テーブル２０２から、統合制御部１０１がログデータを収集するが、ログオン状況管理テーブル２０２（後の勤務実績管理テーブル１０４）に格納する際に、端末ＩＤ毎に統合して（すなわち、端末５０共用であれば複数のユーザＩＤの使用状況を含んだ状態で）、後の勤務実績管理テーブル１０４（これはユーザＩＤ毎の勤務が必要）でテーブル化する前に、共通キーであるユーザＩＤや端末ＩＤから参照・取得しやすくする前処理がなされる。

一旦格納した後で、例えば１日単位などのバッチ処理にて、最終形態（最適化処理がなされた後の稼働実績テーブル）の１つ前段階である、勤務実績管理テーブル１０４として必要なデータを、ユーザＩＤ毎に、ログデータの種別及び発生時間、端末ＩＤ、位置情報、ユーザの勤め先・業種、勤務形態、ユーザの端末等使用予定情報やスケジュール情報など、ログオン状況管理テーブル２０２に格納された様々な情報に基づき定められた所定の条件に基づいて集約・分析・抽出することにより勤務実績管理テーブル１０４に格納（判断後に格納された情報は、システム的に判断した勤務実績情報となる）される。

その後、上記の所定の条件の１つである、使用予定情報に含まれる勤務予定情報と勤務実績情報との比較により、勤務時間であるのかいないのか、時間差があっても出張先への移動中（いわゆる勤務扱いとするなど）なのか、様々な企業形態や勤務形態に応じて、適切に判断する処理がなされる。それらの最適化処理がされた後に格納される最終形態である稼働実績データに基づき、給与支給などの処理がなされる。

また、この勤怠管理システムは、ユーザの勤務予定情報であるスケジュールデータをユーザＩＤ毎に対応つけて記憶するスケジュールデータ記憶部３０２（勤務予定情報テーブル）をさらに備える。

稼働実績管理部１０５は、スケジュールデータ及び勤務実績管理情報に基づいて、ユーザＩＤに対応するユーザの勤怠を示す稼働実績情報を生成する。

この構成により、スケジュールデータを含んだ稼働実績情報を生成することができ、ユーザの勤怠管理を容易にすることができる。

また、適正稼働判定部１０６（判断部）は、スケジュールデータ及び／または勤務実績管理情報に基づいて、勤務実績表における勤怠状態を判断する。すなわち、勤務実績表とスケジュールデータとの差が大きい場合、その勤務実績表は適性ではないと判断する。

これにより、ユーザの勤怠管理を正確に行うことができる。

勤務実績情報は、少なくとも１以上の端末からのユーザ操作によりログオン／ログオフ操作をしたログオン／ログオフ、ログオン時間から所定時間間隔で行う監視、前記勤務予定情報に基づいた使用を制御する端末ロック、一定時間、前記ユーザの端末操作がない時間が所定時間以上となった場合のスリープ状態、またはスケジュールデータに記述されるユーザの出張若しくは外出のイベントの少なくとも一つを含む。

適正稼働判定部１０６は、スケジュールデータ記憶部３０２のスケジュールデータ（勤務予定情報テーブルの勤務予定情報）で示される勤務時間と、勤務実績管理情報に基づき勤務していると判断した時間と、の間に所定の時間差がある場合に、適正化のための勤怠確認のための勤務実績確認処理（勤怠確認処理）を行う。例えば、適正稼働判定部１０６は、上長端末５００に対して、確認通知を行う。

これにより、スケジュールと異なった勤務実績があった場合に、そのチェックを可能にする。

また、適正稼働判定部１０６は、スケジュールデータで示される勤務時間と、勤務実績管理情報に基づき勤務していると判断した時間とに所定の時間差がある場合に、直前のイベントの場所から直後のイベントに関する場所までの移動時間に基づき勤務確認処理を行う。この構成により、ユーザのスケジュールを考慮して勤務実態を判断することができる。

１０１…統合制御部、１０２…端末ログ情報集約部、１０３…出退勤適正化処理部、１０４…勤務実績管理テーブル、１０５…稼働実績管理部、１０６…適正稼働判定部、１０７…稼働実績テーブル、１０８…画面ロック制御部、２００…総合ログ管理サーバ、２０１…通信制御部、２０２…ログオン状況管理テーブル、３００…スケジュール管理サーバ、３０１…月間稼働処理部、３０２…スケジュールデータ記憶部、５００…上長端末。

本発明は、ユーザの勤務を管理する勤務管理システムに関する。

そこで、本発明は、上述の課題を解決するために、ユーザが様々な端末や上記端末内のアプリケーションを使用した場合においても、ユーザＩＤと関連付けられた統合ログ情報に基づき、そのユーザの勤務時間を適切に把握することができる勤務管理システム、勤務管理方法、及び勤務管理プログラムを提供することを目的とする。

本発明の請求項１及び８に係る勤務管理システム及び勤務管理方法では、前記ユーザが使用する可能性のある、仮想端末、ＦＡＴ端末、及び異なるシステムで管理されている任意端末のうちの少なくとも２つ以上の端末及び／または前記端末にインストールされたアプリケーションの使用場所を含む使用予定情報と使用後に発生するデータの種別及び／または時間とを、前記ユーザの使用状況を管理するログ情報として前記端末の端末ＩＤごとに統合して取得するよう制御する制御部と、前記制御部により取得したデータを、前記ユーザＩＤと関連付けて統合ログ情報として記憶する統合ログテーブルと、前記統合ログテーブルに基づいて、前記ユーザＩＤに対応するユーザの勤務実績情報を生成する生成部と、を備える。

また、本発明の請求項２及び９に係る勤務管理システム及び勤務管理方法の前記統合ログ情報には、前記使用予定情報として前記ユーザの勤務予定情報がユーザＩＤ毎に対応つけて記録され、前記勤務予定情報及び端末等の使用状況を管理する前記統合ログ情報に基づいて、前記ユーザＩＤに対応するユーザの勤務実績情報を生成する機能、を備える。

また、本発明の請求項３及び１０に係る勤務管理システム及び勤務管理方法では、前記使用予定情報及び／または前記統合ログ情報に基づいて、勤務状態であるか否かを判断する機能、をさらに備える。

また、本発明の請求項４及び１１に係る勤務管理システム及び勤務管理方法では、記使用予定情報に含まれる勤務予定時間と前記統合ログ情報とに基づき、勤務予定時間ではないが勤務として稼働している、または勤務予定時間中でも勤務として稼働していないと判断した場合に、勤務適正化のための処理を行う機能、をさらに備える。

また、本発明の請求項５及び１２に係る勤務管理システム及び勤務管理方法では、前記使用予定情報に含まれる勤務予定時間と、前記統合ログ情報に基づき勤務していると判断した時間とに所定の時間差がある場合に、直前のイベントの場所から直後のイベントに関する場所までの移動時間に基づき勤務確認処理を行う機能、をさらに備える。

請求項１及び８に記載の発明によると、少なくとも２以上の端末及び／または前記端末にインストールされたアプリケーションの使用場所を含む使用予定情報と使用後に発生するデータの種別及び／または発生時間とを、ユーザの端末等の使用状況としてユーザＩＤと関連付けて統合ログ情報として記憶することから、様々な端末等の使用状況からユーザの勤務実態を俯瞰して把握することができる。

また、本発明の請求項２及び９に記載の発明によると、前記使用予定情報としてユーザの勤務予定情報が記録されることから、前記勤務予定情報及び前記統合ログ情報に基づいて、ユーザの勤務をより正確に把握することができる。

また、本発明の請求項３及び１０に記載の発明によると、前記使用予定情報及び／または前記統合ログ情報に基づいて勤務状態であるか否かを判断することから、公私に利用される端末等の使用状況であっても、ユーザの勤務をより正確に把握することができる。

また、本発明の請求項４及び１１に記載の発明によると、前記統合ログ情報に基づき適正化のための勤務確認処理を行うことから、前記使用予定情報に含まれる勤務予定時間と、前記統合ログ情報に基づき勤務していると判断した時間との間に所定の時間差がある場合でも、ユーザの勤務をより正確に把握することができる。

また、本発明の請求項５及び１２に記載の発明によると、前記使用予定情報に含まれる直前のイベントの場所から直後のイベントに関する場所のデータから移動時間を算出し、勤務確認処理を行うことから、勤務していると判断した時間と勤務予定時間との間に所定の時間差がある場合でも、ユーザのスケジューラ情報に基づき、勤務をより正確に把握することができる。

本開示の一態様における勤務管理システムの機能構成を示すシステム構成図である。 ログ情報の具体例を示す図である。 勤務管理システムの処理シーケンスを示す図である。 勤務管理データの具体例を示す図である。 勤務実績表の具体例を示す図である。 勤務開始日時とログオン送信実績との間に所定時間間隔が空いたときの勤務実績表を示す図である。 ログオン送信実績等のログ情報が全くない勤務実績表を示す図である。 適正でない勤務実績表が生成された時に上長に通知される情報の具体例を示す図である。 ログ情報取得処理を示すシーケンス図である。 各端末５０を独立してログオンをして管理する処理を示すシーケンス図である。 単一の端末のみにログオンを許可する管理のためのシーケンス図（その１）である。 単一の端末のみにログオンを許可する管理のためのシーケンス図（その２）である。 本開示における勤務管理サーバ１００のハードウェア構成図である。

図１は、本開示の一態様における勤務管理システムの機能構成を示すシステム構成図である。図１に示されるとおり、この勤務管理システムは、勤務管理サーバ１００、総合ログ管理サーバ２００、及びスケジュール管理サーバ３００を含んで構成されている。端末５０（ユーザ端末５１〜ユーザ端末５４）は、それぞれその形態を変えた通信端末であり、それぞれノートパソコン、デスクトップパソコン、タブレット端末、スマートフォンである。

また、ＦＡＴ端末は、それぞれの企業内に設けられたネットワークやＳＯＨＯなどの公共に設置された職場環境やネットカフェ等に接続され、一般的なクライアントＰＣと同様にアプリケーションがその端末内にインストールされ、ログオン時に使用可能に構成されている。

本開示の一態様における勤務管理システムでは、これらユーザ端末５１〜ユーザ端末５４を含む任意の端末から、ユーザが一のユーザＩＤを使ってログオンすることにより、勤務管理システムにおいて、ユーザの一元管理を行うことができる。以下、各構成要素について説明する。

この使用予定情報は、勤務管理の対象である業務で使用する可能性のある端末５０が、スケジュール管理サーバ３００にユーザのスケジュール情報と共に登録されていて、ユーザのスケジュールデータである勤務予定情報や、端末５０の使用予定情報、個々の予定情報にある勤務場所や出張若しくは外出の日時や場所に関する情報を取得し、これらの情報から登録済の端末５０のＩＤが、勤務予定時間内で使用される予定であるという情報である。

出退勤適正化処理部１０３は、端末ログ情報集約部１０２により取得された統合ログ情報から、ユーザＩＤごとの使用予定情報と、前記端末ＩＤごとに統合されたログ情報を、前記ユーザＩＤで関連付けて統合ログテーブルとし、勤務管理レベルに応じて前記ユーザＩＤに対応するユーザの勤務を示す勤務実績情報を生成する。

具体的には、例えばデスクワークを中心とするＯＡ業務に対し、最も柔軟な端末使用管理を行うレベルである、登録済の端末５０の何れからの使用も許可し、端末５０のＩＤ毎に統合された使用実績（間欠的に分断される時間の使用を含む）は、業務利用を行っていて勤務実績があるとして稼働実績テーブルに格納し、端末５０のＩＤ毎の使用実績を時系列的に並べ、同じ時間に複数の端末５０の使用実績がある情報は重畳し、ユーザＩＤ毎に統合化した勤務実績管理情報（勤務管理データ）を生成して、勤務実績管理テーブル１０４に記憶する。

さて、ユーザＩＤ毎に統合化した勤務実績管理情報が記憶された後に、前記使用予定情報に含まれる勤務予定情報及び／または前記統合ログ情報に基づいて、勤務状態であるか否かを判断する、具体的には、３つのケースである、（１）前記使用予定情報のみ、（２）前記総合ログ情報のみ、（３）使用予定情報及び統合ログ情報の両方、に基づく勤務実績管理に分類され、夫々の処理が異なる詳細を説明する。

勤務実績表には対象日の統合ログ情報が存在しないため、システム的には勤務状態でないと判断できる。但し、実際にはユーザは対象日に勤務をして端末５０を使用していた場合でも、端末５０やシステム側の不具合により、ログオン情報を含む一切の統合ログ情報が取得できないことも想定されることから、詳しくは図３の説明にて後述するが、勤務適正化のための処理を行うために、ユーザの上長に稼働実績確認通知を行い、ユーザとユーザの上長との間でやり取りされる勤務実績の確認及びユーザの上長による承認により、勤務実績がゼロの記録から、勤務予定時間通り勤務したことを認めても良い。

また、（２）のケースは、もともと休日などユーザが端末５０の使用予定が未登録である対象日に、何らかの要因で統合ログ情報が収集された場合や、従来技術の様に（とは言っても、様々な端末５０からのログを統合していないのは言うまでもないが）、端末５０からのログオン・ログオフ情報を用いて、最小限の勤務管理を行う管理レベルを選択した場合に、前記総合ログ情報の中から、実際に業務上の端末５０の少なくとも１以上の使用開始及び使用終了のログや、各種ログ情報に基づいて、ユーザの勤務実績があったものと取り扱う場合などが該当する。但し、ＯＡ業務に従事するユーザが休暇申請や振替休日申請を漏らしたなどは論外として（これはユーザが事後でも休暇申請を行い、ユーザの上長に承認を得る必要があるが）、システム監視業務やお客様対応業務においては、システム都合やお客様都合により、休日に急遽勤務を行う必要性が生じた場合もあるため、（１）のケースと同様に、勤務適正化のための処理として、ユーザの上長に稼働実績確認通知を行い、ユーザとユーザの上長との間でやり取りされる勤務実績の確認及びユーザの上長による承認により、勤務扱い又は振替勤務日として、勤務したことを認めても良い。また、私用端末からのログなど、業務上の使用でないログ情報が収集される可能性もあるため、ユーザとユーザの上長とのやり取りで、勤務扱いとしない処理を行っても良い。

また、（３）のケースは、使用予定情報に含まれる勤務予定時間及び統合ログ情報の両方に基づく勤務実績管理であり、本願発明において最も一般的なケースに適用され、多種多様な勤務管理を可能とするものである。もともとユーザが端末５０の使用予定に含まれる勤務予定情報が、後述する月間稼働申請や時間外予定申請の承認に基づき登録されていて、ユーザ毎にスケジュール情報や使用予定の端末５０の違いや、様々な企業の業務形態や採用する勤務形態の違いはあるものの、端末５０のログ情報が時々刻々とログオン状況管理テーブル２０２に格納され、ユーザＩＤ及び１日単位（0時〜24時）でバッチ処理された統合ログ情報に基づく勤務実績情報が日常的に生成されるケースである。

例えば、その勤務実績時間（例えば9時28分〜20時8分）と、勤務予定情報（例えば9時30分〜20時）を出退勤適正化処理部１０３にて比較し、所定の時間差（例えば15分）を超えて差分がない場合は、略勤務予定時間通りに勤務した者として取り扱い、生成した勤務実績時間を正しいものとして、稼働実績時間として登録し、実際に給与の対象となる稼働実績時間とする。

ここで重要な点は、前記使用予定情報に含まれる勤務予定時間と、前記統合ログ情報に基づき、勤務予定時間ではないが勤務として稼働している、または勤務予定時間中でも勤務として稼働していないと判断した時間と、の間に所定の時間差がある場合に、様々な企業・業種・業務が存在する働き方に対し、如何にシステム的に可能な範囲で、統合ログ情報から効率的な勤務適正化のための処理を行うことができるか、ということである。

上述するロック時間の勤務扱いについては、各企業の勤務管理方針に沿って、判断基準を各々設定することになると説明したが、働き方改革を推進する観点で、業務利用を許可する端末５０の多様性することによる弊害も生じうる。例えば、多様な端末５０の使用を許可すると、ユーザが勤務したと判断すべき対象の統合ログ情報が増え、実際に業務を行っていたことを否定できないロック時間（例えば、打合せや出張で席を外していた、端末は使用せず、業務資料や書籍を読み業務の検討をしていたなど）については、企業側が労働基準法違反を避けるために、ロック時間全てを勤務扱いとして不払い労働の可能性を排除する、即ちコンプライアンス重視の方針に基づく判断もあり得る。一方で、勤務実績時間を厳格に管理する方針を採用する企業の例でいえば、打合せや出張などで席を外していた時間や、ユーザが属する企業の複数の勤務場所を行き来する時間や、又はお客様や取引先等の出張場所に移動したりする時間は、例えば統合ログ情報のスケジュール情報にある場所情報や、端末５０の位置情報を活用して、直前のイベントの場所から直後のイベントに関する場所までの移動時間をシステムが自動で算出したり、会議場所に設置されたＩｏＴ機器の情報に基づくプレゼンス情報を活用して、勤務扱いとして算出しても良い。また、仮想端末の使用のみに限定し、勤務時間外のロック解除までの時間は勤務扱いとせず、基本的に仮想端末がアンロック状態の時間（ログオンからロック処理までの時間）を、勤務扱いとすることも可能である。

ここまで説明したケースはあくまで一例であり、前記使用予定情報に含まれる勤務予定時間と、前記統合ログ情報に基づき勤務していると判断した時間とに所定の時間差がある場合には、企業・業態・業務・勤務形態など、様々な企業の勤務管理方針に基づき、勤務確認処理を行っても良いことは言うまでもない。

なお、本願発明の勤務管理システム及び勤務管理方法等における出張等のスケジュール情報については、スケジュール管理サーバ３００から、出張をしたこと及びその時間帯を示す情報を勤務予定情報として取得し、実際にユーザがイベント情報に記された日時や場所を確認するため、端末５０から取得した位置情報などを含め、ログ情報の時系列順に挿入する。

操作ログ情報は、端末５０が操作されていることを示す情報であり、端末５０にインストールされているアプリケーション毎に必要なログ情報を収集できるようにしても良く、その場合は、予め端末５０に各種ログを収集可能とする監視用アプリケーションをインストールしておく。

このように構成された勤務管理システムの処理について説明する。図３は、勤務管理システムにおける勤務管理方法の処理シーケンスを示す図である。

勤務予定時間外に端末の監視ログ等が一定時間（例えば15分）検出されると、今現在使用している端末のほか、ログオフしていない他の端末も一括で画面ロック制御を行う。これは、業務未命令の時間に勤務することを抑止し、長時間労働を抑制するなどの勤務適正化を図る機能である。

勤務適正化の対象は以下の通りである。

レコードＲ３は、ログオフ時間及びスリープ時間のいずれも記憶されていない。これは、端末Ｂ（端末ＩＤ：Ｂ）を使用している最中にスマホＤからログオンしたためである。出退勤適正化処理部１０３は、ログオン時間からつぎのログオン時間までの間に、端末ＩＤを同じにするログオン時間及び監視ログを一つのレコードＲ３に集約する。レコードＲ３では、ログオン時間が１４：５８であり、その後５分おきに監視ログが記録されている。そして、端末Ｂ（端末ＩＤ：Ｂ）をログオフすることなく、スマホＤを使用したため、スマホＤのためのレコードＲ４が集約されている。ここでは、スリープ時間は１６：４５であることから、勤務時間は１６：１５〜１６：４５と判断できる。

稼働実績管理部１０５は、適正稼働判定部１０６によりその勤務実績管理情報が適性であると判断されると、生成した勤務実績を給与支払い対象としての稼働実績として稼働実績テーブル１０７に記憶する（Ｓ１１１）。なお、稼働実績登録の時間単位は、勤務管理方針で定める勤務時間単位や画面ロック処理までの監視時間、適正化の判断基準時間との相関性から15分単位で設定しても良く、また1分単位で設定しても良いが、給与支払の対象となる稼働時間は、上記単位御南の時間を切り上げとし、賃金不払いとならないよう設定することが望ましい。

つぎに、本開示における勤務管理システムの作用効果について説明する。勤務管理システムにおいて、前記ユーザが使用する可能性のある、仮想端末、ＦＡＴ端末、及び端末にインストールされたアプリケーションの少なくとも２つ以上の使用状況に基づき、前記ユーザの勤務を管理するシステムである。

この勤務管理システムは、少なくとも２つ以上の仮想端末、ＦＡＴ端末、及び異なるシステムで管理されている任意端末及び／または前記端末及び／または前記端末にインストールされたアプリケーションの使用場所を含む使用予定情報と使用後に発生するデータの種別及び／または時間とを、端末ＩＤごとに統合した統合ログ情報である勤務実績管理情報を記憶する勤務実績管理テーブル１０４（統合ログテーブル）と、勤務実績管理テーブル１０４に基づいて、ユーザＩＤに対応するユーザの勤務を示す稼働実績情報を生成する稼働実績管理部１０５と、を備える。

ところで、本開示において、別システムで端末５０等の管理をされているデータ（例えば他社が提供するスマホアプリの操作ログ、他社携帯会社のサーバで管理される通話履歴や位置情報などのログ情報や、他社勤務管理システムのログ情報や他社仮想端末のログ情報など、企業内のＦＡＴ端末のログとは異なるシステムで管理されている各種データ）は、電気通信事業者に課せられる通信の秘密や法律により、ログ収集することが困難である。

そこで、本開示では、例えば勤務管理システム又はそのアプリケーションが、ユーザによるアプリケーションインストール時（この際に、ユーザＩＤや端末ＩＤを一意に区別して一元管理ができるように、仕組まれています）のログ取得に関し、インストールすることにより同意したものとみなす、シュリンクラップ契約がなされることを前提とする。

また、この勤務管理システムは、ユーザの勤務予定情報であるスケジュールデータをユーザＩＤ毎に対応つけて記憶するスケジュールデータ記憶部３０２（勤務予定情報テーブル）をさらに備える。

稼働実績管理部１０５は、スケジュールデータ及び勤務実績管理情報に基づいて、ユーザＩＤに対応するユーザの勤務を示す稼働実績情報を生成する。

この構成により、スケジュールデータを含んだ稼働実績情報を生成することができ、ユーザの勤務管理を容易にすることができる。

また、適正稼働判定部１０６（判断部）は、スケジュールデータ及び／または勤務実績管理情報に基づいて、勤務実績表における勤務状態を判断する。すなわち、勤務実績表とスケジュールデータとの差が大きい場合、その勤務実績表は適性ではないと判断する。

これにより、ユーザの勤務管理を正確に行うことができる。

勤務実績情報は、少なくとも１以上の端末及び／または前記端末にインストールされたアプリケーションの使用場所として、スケジュールデータに記述されるユーザの出張若しくは外出のイベントなどの情報やユーザの勤務予定情報などの少なくとも１つ以上の使用予定情報と、使用後のデータである少なくとも１つ以上のユーザ操作によりログオン／ログオフ操作をしたログオン／ログオフ、ログオン時間から所定時間間隔で行う監視、前記勤務予定情報に基づいた使用を制御する端末ロック、一定時間、前記ユーザの端末操作がない時間が所定時間以上となった場合のスリープ状態、または端末の位置情報を併せて少なくとも２つ以上のデータを含む。

適正稼働判定部１０６は、スケジュールデータ記憶部３０２のスケジュールデータ（勤務予定情報テーブルの勤務予定情報）で示される勤務時間と、勤務実績管理情報に基づき勤務していると判断した時間と、の間に所定の時間差がある場合に、適正化のための勤務確認のための勤務実績確認処理（勤務確認処理）を行う。例えば、適正稼働判定部１０６は、上長端末５００に対して、確認通知を行う。

Claims (13)

1. ユーザＩＤに基づき識別される、少なくとも１以上の端末又はアプリケーションの使用状況に基づき、前記ユーザの勤怠を管理する管理サーバにおいて、
   前記ユーザが使用する、少なくとも１以上の仮想端末、ＦＡＴ端末、及び／または任意の端末にインストールされたアプリケーションにおける、１以上の前記端末の使用予定及び／または使用後に発生するログオンのデータの種別及び発生時間を、使用状況を管理するログ情報として前記１以上の端末のＩＤごとに統合して取得するよう制御する制御部と、
   前記制御部により取得したデータを、前記ユーザＩＤと関連付けて統合ログ情報として記憶する統合ログテーブルと、
   前記統合ログテーブルに基づいて、前記ユーザＩＤに対応するユーザの勤怠を示す勤務実績情報を生成する生成部と、
   を備える勤怠管理システム。
2. 前記使用予定を示す使用予定情報として前記ユーザの勤務予定情報をユーザＩＤ毎に対応つけて記憶する勤務予定情報テーブルをさらに備え、
   前記生成部は、前記勤務予定情報及び前記統合ログ情報に基づいて、前記ユーザＩＤに対応するユーザの勤怠を示す勤務実績情報を生成する、ことを特徴とする請求項１に記載の勤怠管理システム。
3. 少なくとも前記統合ログ情報に基づいて、勤怠状態であるか否かを判断する判断部をさらに備える、請求項１または２に記載の勤怠管理システム。
4. 前記制御部は、
   前記使用予定情報に含まれる勤務予定時間と、前記統合ログ情報に基づき勤務として稼働している、または稼働していないと判断した時間と、の間に所定の時間差がある場合に、勤怠適正化のための処理を行う、ことを特徴とする請求項２に記載の勤怠管理システム。
5. 前記制御部は、
   前記使用予定情報に含まれる勤務時間と、前記統合ログ情報に基づき勤怠していると判断した時間とに所定の時間差がある場合に、直前のイベントの場所から直後のイベントに関する場所までの移動時間に基づき勤怠確認処理を行う、請求項２または４に記載の勤怠管理システム。
6. ユーザＩＤに基づき識別される、少なくとも１以上の端末又はアプリケーションの使用状況に基づき、前記ユーザの勤怠を管理する勤怠管理方法において、
   前記ユーザＩＤに基づきログインされる、少なくとも１以上の仮想端末、ＦＡＴ端末、及び／または任意の端末にインストールされたアプリケーションにおける、使用予定及び／または使用後に発生するログオンの種別及び発生時間のデータを、使用状況を管理するログ情報として、前記１以上の端末ＩＤごとに統合して取得し、
   前記端末ＩＤごとに統合されたログ情報を、前記ユーザＩＤと関連付けて統合ログ情報として統合ログテーブルに記憶し、
   前記統合ログテーブルに基づいて、前記ユーザＩＤに対応するユーザの勤怠を示す勤務実績情報を生成する、
   ことを特徴とする勤怠管理方法。
7. 前記使用予定を示す使用予定情報として前記ユーザの勤務予定情報がユーザＩＤ毎に対応つけて勤務予定情報テーブルに記憶され、
   前記勤務予定情報及び端末の使用状況を管理する前記統合ログ情報に基づいて、前記ユーザＩＤに対応するユーザの勤怠を示す勤務実績情報を生成する、ことを特徴とする請求項６に記載の勤怠管理方法。
8. 少なくとも前記統合ログ情報に基づいて、勤怠状態であるか否かを判断する、ことを特徴とする請求項６または７に記載の勤怠管理方法。
9. 前記使用予定情報に含まれる勤務予定時間と、前記統合ログ情報に基づき勤務として稼働しているまたは稼働していないと判断した時間と、の間に所定の時間差がある場合に、勤怠適正化のための処理を行う、ことを特徴とする請求項７に記載の勤怠管理方法。
10. 前記使用予定情報に含まれる勤務予定時間と、前記統合ログ情報に基づき勤怠していると判断した時間とに所定の時間差がある場合に、直前のイベントの場所から直後のイベントに関する場所までの移動時間に基づき勤怠確認処理を行う、ことを特徴とする請求項７または９に記載の勤怠管理方法。
11. ユーザの勤怠を管理するための勤怠管理データにおいて、
    ユーザＩＤに基づいてログオンして使用可能な少なくとも１以上の仮想端末と、ＦＡＴ端末、及び／または任意の端末にインストールされたアプリケーションにおける、使用予定及び／または使用後に発生するログオンのデータの種別及び発生時間を、前記端末の使用状況を管理するログ情報として、前記１以上の端末のＩＤごとに統合してテーブルに格納され、
    端末のＩＤごとに統合した後に、前記ユーザＩＤ、データの種別及び発生時間に基づき、所定の条件でユーザの勤怠を示す勤務実績情報として再テーブル化されることを特徴とする、勤怠管理データ。
12. 前記ログ情報として、前記端末の使用予定情報、少なくとも１以上の端末からのユーザ操作によりログオン／ログオフ操作をしたログオン／ログオフ、ユーザ操作によりメール送信操作をしたメール送信ログ、ログオン時間から所定時間間隔で行う監視ログ、勤務予定情報に基づいた使用を制御する端末ロック、一定時間、前記ユーザの端末操作がない時間が所定時間以上となった場合のスリープ状態、または前記勤務予定情報に記述される前記ユーザの出張若しくは外出のイベント情報、イベント情報に対応する前記端末の位置情報またはイベント日時を含む関連情報、前記端末へのアクセスデータ、前記端末の移動履歴を構成するプローブデータの少なくとも一つを記憶する、
    請求項１１に記載の勤怠管理データ。
13. 請求項１１または請求項１２に記載の勤怠管理データに基づいて、一日単位で、ユーザのスケジュールに基づいた勤務開始日時および勤務終了日時、並びに前記ログオンの時間に基づいた最早ログオン時間および最遅ログオン時間が定められた稼働実績データ。
    

Images