JP7336424B2 - アラート発出方法、アラート発出プログラム及びアラート発出システム - Google Patents

Description

本発明は、労務に関する知識が十分でない中小企業や個人事業主その他の事業者の労務管理を支援するためのシステム、同システムを動作させるための方法及びプログラムなどに関する。

事業者にとって、雇用する労働者の労務管理の重要性が日々高まっている。働き方改革の名の下で進められてきた各種の法制度の改定、柔軟な勤務形態の広まりを背景とした労働者ごとの非画一的な労務管理の必要性などがその理由である。

事業者は変化する環境に適合した労務管理手法を適宜取り入れ、運用することが求められるとともに、そのような手法が適切に運用されているかを随時確認し、必要に応じて変化させなければならない。そして労務管理が不十分な事業者は、監督官庁や労働者を相手とする各種の労務リスクを負うだけでなく、「ブラック企業」「硬直的な企業」といった評価を受け、これが市場においてマイナスに作用するリスクをも負っている。

そこで従来から、コンピュータを用いて効率的かつ客観的な労務管理をするためのシステムに関する種々の技術が開示されている。例えば特許文献１には、就業時間中における従業者の端末の操作履歴及び操作時間の情報を分析し、真に就業していた時間を算出するための装置に関する技術が開示されている。

特開２０１４－１７８９０７

しかしながら、特許文献１に記載されている先行技術は、端末の操作時間が把握できる環境下で、端末を操作することのみが業務内容である労働者にした対応することができない技術であり、適用できる職種や業態、働きかたに偏りがあった。また、業務に従事していたか否かを監視することを目的とする技術のため、労働者の反発も予想され、広く受け入れられうる技術とも言い難かった。

以上のような課題を解決すべく、本発明は、一の事業者ＩＤと紐づけて一又は複数の従業者ＩＤを保持する従業者ＩＤ保持部を有するサーバを用いた労務管理アラート発出方法であって、一の従業者ＩＤと紐づけて所定就業期間の就業時間を含む勤怠情報の入力を受け付ける勤怠情報入力受付ステップと、受け付けた勤怠情報を当該従業者ＩＤと紐づけて記録する勤怠情報記録ステップと、記録された複数の従業者ＩＤと紐づけられた勤怠情報に基づいて前記一の事業者ＩＤにて特定される事業者の労務管理に関連したアラート発出要否を判断するアラート判断ステップと、アラート判断ステップの判断内容に応じてアラートを発出するアラート発出ステップと、をコンピュータを用いて実現するアラート発出方法などを提案する。

なお前記方法に関連して、従業者ＩＤ保持部は、従業者の雇用条件をも当該従業者の従業者ＩＤと紐づけて保持し、アラート判断ステップは、従業者の雇用条件をも用いてアラート発出要否を判断する雇用条件利用判断サブステップをさらに有するアラート発出方法なども提案する。

また、前記各方法に関連して、労務管理に関連したインシデント情報である労務管理インシデント情報を記録するインシデント記録ステップをさらに有し、アラート判断ステップは、労務管理インシデント情報をも用いてアラート発出要否を判断するインシデント利用判断サブステップをさらに有するアラート発出方法なども提案する。

さらに前記各方法に関連して、アラート判断ステップは、勤怠情報と事業者ＩＤと学習済の学習済モデルとを用いてアラート発出要否を判断する学習済モデル利用サブステップをさらに有するアラート発出方法なども提案する。

なおここで用いられる学習済モデルの生成方法として、事業者ＩＤと、一又は複数の従業者の就業時間と、労務管理インシデント情報と、を含む訓練データを取得する情報取得ステップと、前記訓練データに基づき、事業者ＩＤ及び複数の勤怠情報の入力を受け付ける情報入力受付ステップと、当該事業者ＩＤにて識別される事業者に対応する労務管理インシデント情報を識別した識別結果を出力することを内容とする学習済モデルを生成するモデル生成ステップと、を処理をコンピュータにて実現することを特徴とする方法についても提案する。

さらに前記各方法に関連して、アラート発出ステップは、アラート判断ステップの判断内容に応じて、異なる態様のアラートを発出するアラート発出方法なども提案する。

アラート発出ステップにて発出されたアラートの内容及び発出の事実を含む情報であるアラート実績情報を事業者ＩＤと関連付けて記録するアラート実績記録ステップをさらに有し、アラート判断ステップは、記録されたアラート実績情報をも用いてアラート発出要否を判断する実績利用サブステップをさらに有するアラート発出方法なども提案する。

そして、ここまで掲げてきた各方法をコンピュータで実現するためのプログラムや当該方法を用いたシステムなどについても提案する。

主に以上のような構成をとる本発明によって、職種や業態、労働者の働きかたに応じた労務管理を行いやすくするだけでなく、労働者にとっても、自身が気付かなかったような労務リスクをいち早く事業者に察知してもらうことが可能になる。

本発明のアラート発出システムの概要を示す図 実施形態１のアラート発出システムの機能ブロックの一例を示す図 実施形態１のアラート発出システムの機能ブロックの別の一例を示す図 実施形態１のアラート発出システムの機能ブロックの更に別の一例を示す図 実施形態１のアラート発出システムの機能的な各構成をまとめて一のハードウェアとして実現した際の構成の一例を示す概略図 実施形態１のアラート発出システムにおける処理の流れの一例を示す図 実施形態１のアラート発出システムにおける処理の別の流れの一例を示す図 実施形態１のアラート発出システムにおける処理の更に別の流れの一例を示す図 実施形態２のアラート発出システムの機能ブロックの一例を示す図 実施形態２のアラート発出システムで用いられる学習済モデルの生成に関する処理の流れの一例を示す図 実施形態２のアラート発出システムにおける処理の流れの一例を示す図

まず図１を示す。図１は本発明の概要を示す図で、Ａ社の事業所内部で働く労働者の操作する端末Ａ２ないしＡ６とそれらを管理するサーバＡ１が内部ネットワークで接続されるとともに、事業所外で働く労働者の操作する端末Ｂ１ないしＢ４がネットワークで接続される様子を表している。事業所内外で働く労働者はいずれも、就業時間を開始する際には各自が管理する端末を操作することで各自の業務の開始を記録する。なおサーバＡ１では、各労働者の勤怠情報を管理しており、就業時間をはじめとする各種の情報を取得することによって、所定のルールに基づいてアラートを発出することができる。このような仕組みを採用することにより、個々の労働者の労務管理にとどまらず、Ａ社として回避したい労務リスクを事前に把握管理するだけでなく、適切な対処のための方策を事前に検討することが容易になる。

なお、本発明はこれらの実施形態に何ら限定されるものではなく、技術常識に従って特許請求の範囲の各請求項に記載の技術的思想を有し、その要旨を逸脱しない範囲内において、様々な態様で実施し得る。

＜＜実施形態１＞＞
＜概要＞
図２Ａは、本実施形態の契約締結方法を一のシステムにて実現する場合の機能ブロックの一例を示す図である。同図において示されているように、本実施形態の「アラート発出システム」０２００は、「従業者ＩＤ保持部」０２０１と、「勤怠情報入力受付部」０２０２と、「勤怠情報記録部」０２０３と、「アラート判断部」０２０４と、「アラート発出部」０２０５と、を有する。

なお、以下で詳しく説明するアラート発出システムは、その機能の一又は複数の機能を複数の装置にて実現するようにも構成され得るものであって、その機能ブロックは、いずれもハードウェア又はソフトウェアとして実現され得る。コンピュータを用いるものを例にすれば、ＣＰＵやメインメモリ、ＧＰＵ、ＴＰＵ、画像メモリ、バス、二次記憶装置（ハードディスクや不揮発性メモリ）、キーボードや操作ボタン、タッチパネル、タッチパネルをタッチするための電子ペン、マイク、体温計、タイムレコーダなどの各種入力デバイス、スピーカ、ディスプレイその他各種出力デバイス、その他の外部周辺装置などのハードウェア構成部、またその外部周辺装置用のインターフェース、通信用インターフェース、それらのハードウェアを制御するためのドライバプログラムやその他のアプリケーションプログラムなどが挙げられる。

これらの装置は、一の事業所内部でのみ用いられる場合もあれば、複数の事業所間を横断的に用いられる場合や、従業者が使用する携帯端末を用いる場合もある。すなわち、一の事業者が管理する複数の事業所ではたらく従業者や営業担当者、リモートワーク従業者などのように、事業所外で就業する者の就業状況を把握する必要も少なくなく、本発明はそのような状況への適用も可能である。

そして各々の装置のメインメモリ上に展開したプログラムに従った演算処理によって、入力デバイスやその他インターフェースなどから入力されメモリやハードウェア上に保持されているデータなどが加工、蓄積されたり、前記各ハードウェアやソフトウェアを制御するための命令が生成されたりする。ここで、上記プログラムは、モジュール化された複数のプログラムとして実現されてもよいし、２以上のプログラムを組み合わせて一のプログラムとして実現されても良い。クラウドコンピューティングの形式にて分散処理されてももちろんよいし、ＡＰＩ連携の形式にて複数の事業者間にまたがって提供される複数のプログラムによって実行処理されてもよい。

＜機能的構成＞
「従業者ＩＤ保持部」０２０１は、一の事業者ＩＤと紐づけて一又は複数の従業者ＩＤを保持するように構成されている。従業者ＩＤは、業務委託先のように特別な管理をしていない場合には従業者の氏名など固有の情報である場合が考えられるが、、正社員のようにあらかじめ労務その他の観点から当該従業者を管理しているような場合には、当該管理に際して付与されるＩＤ（社員番号等）をもって従業者ＩＤとすることが考えられる。

従業者ＩＤは、一の事業者ＩＤを紐づけて保持されるのであって、一の事業者が複数の事業所を有する場合や実質的に特定の事業所を有さないような場合には、当該事業者の稼働状況に応じた事業場所ＩＤなどを別途付与してもよい。本発明は一の事業者と紐づく個々の従業者の労務管理を通じて、事業者としての労務リスクの把握を容易にすることを効用の一つとして備えており、上記のような事業場所ＩＤをも保持する構成を採用しておけば、事業場所単位での労務リスクをも把握するためのアラートを受け取ることが可能になるため、当該アラートをタイムリーに受け取ることで、実効性ある対処策を講じることがより容易になることになる。

なお、従業者の雇用条件をも当該従業者の従業者ＩＤと紐づけて保持するように構成されてもよい。具体的には、正社員・非正規社員・派遣労働者・パート・アルバイト・業務委託その他事業者との契約関係の別を保持する構成や、職位・役職などの情報、勤務時間、法定休日、有給休暇の付与日数及び取得日数及びその日付、賞罰、勤務評価と給与・賞与、勤続年数（部署所属年数）など、従業者と事業者との労務提供に関する契約関係に基づく種々の条件及び当該条件に紐づく情報を保持することが考えられる。より具体的には、事業者内部の人事部門において管理される人事データベースが該当しうるものであり、当該構成を採用することにより、人事と労務との総合管理を容易にすることができる。

「勤怠情報入力受付部」０２０２は、一の従業者ＩＤと紐づけて所定就業期間を含む勤怠情報の入力を受け付けるように構成されている。具体的には、該当する従業者から、その操作する端末を通じて出勤時間や休憩時間、退勤時間の打刻に関する情報を受け付ける構成が考えられるが、それ以外にもたとえば、事業所内外の人感センサその他の装置を通じて所定就業時間を取得し、その入力を受け付ける構成などが考えられる。

勤怠情報は、該当する情報については適宜その入力を受け付ける構成としておくことが望ましく、事後の加除修正にも対応できるに構成可能である。ただし、加除修正をする際には、当該処理のログを格納しておき、当該処理に改ざんのおそれがないかを事後的に検証可能にしておく必要がある。

ちなみに、入力を受け付ける勤怠情報は、所定就業時間に関する情報以外の従業者の勤怠に関する情報をも含みうる。具体的には、就業時間のうち深夜・早朝に勤務していた時間の有無及びその時間数、休日勤務の有無及びその時間数、有給取得の有無及びその取得修又は未消化日数、早退・欠勤の有無及びその日数などのように、勤怠に直接関連する情報もあれば、出勤時又は勤務開始時の体温、休憩時や退勤時の体温、病欠の有無など勤怠に関連して取得可能な情報などもここでいう勤怠情報に含まれうる。これらの情報をも組み合わせて取得する構成を採用することにより、いち従業者の勤怠の時間だけでは推し量ることのできない事業者としての労務リスクを総合的に判断することができるようになる。

なお、勤怠に関連して取得可能な情報などの取得態様は特に限定はされない。例えば、デジタル体温計などの外部装置からネットワークを介して情報の入力を受け付けてもよいし、社内の有給取得や欠勤の申請のためのワークフローシステムへの申請処理などを通じて取得してもよい。

ここで勤務情報取得のタイミングについては、所定就業時間の情報を取得するのは終業時や休憩取得時、退勤時などのタイミングであることが考えられるが、有給取得や欠勤などの情報については特段のタイミングでの入力が期待されるわけではないので、リアルタイム以外のタイミング、すなわち一定程度の範囲であればバックデートでの入力を受け付ける構成であることが望ましい。厳密な構成ではなく柔軟な情報入力が可能な当該構成を採用することで、結果として、より実態に即した勤怠情報の分析を踏まえたアラート発出を可能にすることが可能になる。

「勤怠情報記録部」０２０３は、受け付けた勤怠情報を当該従業者ＩＤと紐づけて記録するように構成されている。ここではまず、特定の従業者と勤怠情報とを紐づけて記録することにより、勤怠情報記録部を勤怠管理のための構成として位置付けることが可能になる。

ただしここでは、取得した勤怠情報は、従業者ＩＤと紐づけられるとともに当該従業者の属性のその他の情報と関連付けて検索可能に記録されることが好ましい。具体的には、「正社員、２０代、男性」「営業部門、外勤、女性」「Ｘ支店、管理職」などの従業者ＩＤと紐づきうる情報がそれぞれ勤怠情報と紐づいて記録されることが考えられる。当該構成を採用することにより、例えば、「２０代男性全従業者の勤怠情報」「Ｘ支店に勤務する全従業者の勤怠情報」「まだ１日も有給を消化していない従業者の勤怠情報」などの条件に従った勤怠情報を抽出することが可能になる。

「アラート判断部」０２０４は、記録された複数の従業者ＩＤと紐づけられた勤怠情報に基づいて前記一の事業者ＩＤにて特定される事業者の労務管理に関連したアラート発出要否を判断するように構成されている。

「勤怠情報に基づいて」とは、例えば、記録された勤怠情報を数値化した場合に、当該数値が所定の閾値を超過していないかを判断するような構成が考えられる。例えば、「残業時間が月あたり４００時間を超過するか否か」を閾値とした場合、当該事業者ＩＤと紐づけられた従業者全員の残業時間（所定労働時間を超過する時間数）が所定歴月あたり４００時間を超過するかどうかを、アラート発出判断のためのルールとして位置付けておくとともに、勤怠情報が記録される都度当該ルールに則り判断し、超過している場合又は超過しそうな場合に、アラートを発出するような構成が考えられる。

ここで超過している場合と、超過しそうな場合といずれの場合にアラートを発出するかについては事業者が適宜定めてもよいが、事前の対策のためのアラート発出という側面からすると、超過しそうな場合にアラート発出することが望ましい。そしてどのような場合に「超過しそう」と判断するかについては種々の構成が考えられうるところであって、適宜定めることが可能である。

ここで上記態様に関連して、閾値の設定は事業者によって任意に設定することも可能であるし、特定の閾値をあらかじめ設定しておく構成も考えられる。具体的な構成については、後記労務管理インシデント情報と関連づけて詳述する。

また、「勤怠情報に基づいて」とは、一の従業者の勤怠情報のみに基づいてアラート発出の要否を判断しない。一の従業者の勤怠情報に基づいて発出されるアラートとはそもそも、当該従業者の労務管理のためのシステムとしてしか機能しない。ただ、複数の従業者の勤怠情報を用いることを当初より想定する本発明の構成を採用することにより、個別の労務管理という枠組みではなく、事業所単位や事業者全体としての労務リスクの顕在化に資することができるようになる。

このため、ここでいう「複数の従業者ＩＤと紐づけられた勤怠情報」という場合の複数の従業者ＩＤの選択又は特定については、特に限定を付す必要はない。例えば、特定の事業所内の複数の従業者を対象としてもよいし、特定の勤務形態（外勤者やリモートワーカーのみ）の従業者を対象としてもよい。その他勤続年数や職位、欠勤が所定日数を超える従業者といった様々な集団を母集団とする勤怠情報を用いてアラート発出の要否を判断する構成を採用することが可能である。

具体的には、アラート発出要否判断に先立ち、母集団となる従業者を限定するための条件の入力を受け付け、当該条件に合致する従業者ＩＤと紐づけて記録されている勤怠情報を抽出したうえでアラート発出の要否を判断することになる。

なお、労務管理に関連したインシデント情報である労務管理インシデント情報を記録する構成として、インシデント記録部を設ける構成を採用することも可能である。ここでいう「労務管理に関連したインシデント情報」とは例えば、勤務間インターバル制度（終業時刻から次の始業時刻までの間に一定の休息時間を設ける制度）や医師の面接指導（疲労の蓄積が認められる等の要件を満たす従業者が医師の面接指導を受けたいと申し出られる制度）、有給取得の義務化、男性従業者の育児休暇取得などの法令やガイドライン等であらかじめ閾値とすべき数値が定められている場合もある。

労務関連の数値には、法令やガイドラインにおいて上限その他の閾値が定められているものが少なくない。それらの情報に基づく閾値については、あらかじめ記録しておくことが事業者にとっては便宜である。また、法令改正などの事情に応じて、外部サーバからネットワークを介して改正後の情報に変更するような構成が好ましく、こういった構成を採用することにより、事業者が逐次自ら情報収集をして入力を余儀なくされることなくスムーズな情報のアップデートが図られるだけでなく、最新の法令に則った閾値設定ができることから、事業者の労務リスクの低減にも寄与することができるようになる。

ここで、閾値の設定又はアップデートに関する一例について説明する。例えば、いち事業所における従業者の時間外労働時間の平均値が、月あたり４５時間を超えると、事業者に対し、労働基準法に定める罰則が適用される可能性が高まる。そのため、当該平均値が４５時間を超えないような値（例えば３８時間や４０時間、４２時間など）を閾値として設定しておき、勤怠情報を取得した結果当該閾値を超過したと判断される場合にアラートを発出すべきと判断するようなルールを設ける構成が考えられる。

また例えば、近隣の類似事業を営む事業者において、ある従業者の月あたりの時間外労働時間が４６時間のケースで労働基準監督署の調査を受けた、といった他事業者の情報や、とある事業者が、慢性的に時間外労働が月あたり４４時間だった従業者の健康管理を怠ったとして損害賠償の支払いを命じられた裁判の判決が出たといった裁判例情報などを取得するような場合も考えられる。これらの情報を外部端末からネットワークを介してであったり、専門家による入力であったりを通じて取得することで、すでに設定されているルールにおける閾値の値を変更したり、新たなアラート発出のための閾値を設定したりする子も可能である。

なおインシデント情報は、すべての事業者において画一的な閾値が機械的に適用される場合もあれば、業種業態・事業規模に応じて複数の閾値の一が適用される場合もある。また、３６協定で定める時間外労働時間数などのように、事業所単位で異なる閾値が設けられる場合もあるし、特段の法令上の根拠なく、事業者が独自の指標として閾値を設けることもある。これらのいずれのケースにも対応可能なように、閾値については適宜設定変更することが可能である。

ここまでは一の事業者ＩＤにより特定される事業者のもとで働く従業者ＩＤと紐づけられた勤怠情報を用いてアラート発出の要否が判断される構成について説明した。このような構成に加え、アラート発出先となりうる事業者ＩＤと直接紐づかない勤怠情報をも用いてアラート発出の要否を判断する構成を採用することも考えられる。具体的には、事業者と業種、業態、地域又は事業規模を同じくする事業者ＩＤにて識別される他の事業者と紐づけられている従業者の勤怠情報をも用いてアラート発出の要否を判断する構成が考えられる。例えば、利用する事業者が中小規模のスーパーマーケットを経営している場合、当該事業者のもとで働く従業者の勤怠情報に加え、近傍の地域で同じく中小規模のスーパーマーケットを営む他の事業者の勤怠情報をも用いてアラート発出の要否を判断する。当該構成を採用することにより、自らが他の事業者との間で乖離した労務管理を行っていないことを確認し、もって労務リスクが相対的に高くないことを確認できるような形態で発出されるアラートを捉えることができるようになる。

また、事業者ではなく監督官庁や専門家その他の第三者機関によって記録された勤怠情報をも用いてアラート発出の要否を判断する構成が考えられる。例えば、労働基準監督署やハローワーク、産業労働局のような労働行政の相談窓口の管理する端末からは、ガイドラインや通達、その他強制力の有無を問わず種々の形式で労務リスクを低減するためのいわばモデルとなる勤怠情報のような情報が出力されていることが多い。また、社会保険労務士や弁護士などの専門家もまた、それぞれの知見に基づき事業者の労務リスクを低減するためのモデルとなる勤怠情報等を出力することがある。これらの情報を取得してアラート発出の要否判断を行うことも可能である。当該構成を採用することにより、オーソドックスな基準をもとに労務リスクを把握しやすくなり、より実効性のあるアラート発出を行うことができる。

そしてアラート判断部においては、ここまで説明した労務管理インシデント情報をも用いてアラート発出要否を判断するような構成を採用することが考えられる。具体的には、アラート発出要否判断に先立ち、所定の労務管理インシデント情報との関係において設定される閾値が超過しているか、超過しそうかを予測し、すでに超過しているあるいは超過しそうな場合には、アラートを発出する構成が考えられる。当該構成を採用することにより、法令に抵触するという比較的労務リスクの高い状況に追い込まれる前に、そのリスクを回避するための措置を事前に講じることができやすくなる。

「アラート発出部」０２０５は、アラート判断部の判断内容に応じてアラートを発出するように構成されている。ここでいうアラート発出の具体的な態様は様々なものが考えられ、事業者の管理部門（役員・代表者・人事部門責任者）などに、当該アラート発出の根拠となる事実とともに、メールや社内ネットワークシステム上のメッセージその他の情報出力態様により実現されうる。アラート発出先としては先に掲げた管理部門該当者の一又は複数の者が管理する端末に対して出力する場合が考えられるが、他にも、事業者の顧問先の社会保険労務士の管理する端末や産業医が管理する端末にあててアラートを発出する構成を採用してもよい。これらの発出先は、発出されるアラートの内容に応じて適宜設定変更することが可能であることが望ましい。当該構成を採用することで、アラート発出を迅速かつ実効性をもって行うことができるようになる。

なおアラート発出部では、アラート判断部の判断内容に応じて、異なる態様のアラートを発出することが考えられる。例えば、アラート発出の判断に用いる閾値のうち、一又は複数の閾値を超過しそうと判断される場合には、当該超過しそうと判断される閾値の数に応じてアラート発出の態様を変更する構成（例えば、超過しそうな閾値の数が多ければ多いほど社内の職位が高い者を含むアラート発出を行う）が考えられる。

また、アラート判断部での判断結果がアラート不要との内容であった場合には、アラートを発出しないだけでなく、特段の処理を行わないように構成されることが望ましい。本発明を通じて労務管理のコストを圧縮できる一方、無限定に何らかの情報が事業者に出力されるような構成を採用すると、事業者が受領する情報量が不必要に多くなり却って労務管理の時間的業務量的コストが増えるといった本末転倒的な事態も招来しかねないからである（なお、月１回などの所定期間以上の間隔をあけて定期的な労務管理レポートのような情報を出力することまでを排除する趣旨ではない）。

なお、「超過しそう」との判断内容の程度に応じて異なる態様のアラート発出を行う構成も考えられる。この場合には、閾値を超過しそうな危険性が高まるほど社内の職位が高い者を含むアラート発出を行う構成が考えられ、別途定めることで、顧問の社労士や弁護士などに対してアラートを発出する構成をも組み合わせることができ、当該構成を採用することで、事業者では専門知識の欠如により見過ごされがちな労務リスクについて、専門家にタイムリーに情報共有を行うことができ、結果として事業者全体の労務リスクを低減する対策を講じることが容易になる。

ここで、アラート発出部にて発出されたアラートの内容及び発出の事実を含む情報であるアラート実績情報を事業者ＩＤと関連付けて記録するアラート実績記録部をさらに有する構成も考えられる。その場合、アラート判断において、記録されたアラート実績情報をも用いてアラート発出要否を判断する実績利用手段を設けるような構成を採用することも考えられる。

すなわち、すでに説明したように、閾値を超過しそうな場合に段階的にアラート発出をするような構成を採用する場合もあれば、同一又は別の閾値に関連して複数回のアラート発出がなされる場合も想定されうる。このような場合には、あらかじめアラート発出の事実及びその内容を記録しておき、再度のアラート発出時には当該実績をも踏まえたアラート発出を行うことが望ましい。というのも、何度もアラートが発出されることは、それだけ労務リスクが顕在化しつつあることの証左とも判断することができ、そのような状況下にあること自体を事業者として理解把握することにより、より総合的な対策を講じるための準備ができるからである。

ここで、発出されるアラートの態様について説明を補足する。まずは勤怠情報として従業者の体温を取得する場合を例に挙げる。一定の事業所内における従業者の体温が、通常の平均値よりも所定割合以上高くなっていると判断される場合には、当該事業所内で発熱している従業者が一定割合以上いる可能性が懸念され、ひいては風邪やインフルエンザ、その他の感染症が伝染する可能性が懸念されうる。したがって当該事業所の管理者に対してアラートを発出することが考えられる。

そして他の従業者の体温変化に比べ、同じ事業所内にいる一の従業員の体温変化がより所定割合以上上振れしているような場合にも同様のアラートを発出するように構成されてもよい。そしてこれらの場合においては、上記所定割合からの超過度合いに応じて、従業者に在宅勤務を促すメッセージを発信すべきとの内容のアラートを発出したり、事業所内の換気を行うべきとの内容のアラートを発出したりすることが考えられる。このようなアラート発出の仕組みを提供することにより、事業所内の衛生管理を適切に行い、もって安全配慮義務違反の責任を問われるような労務リスクを事前に回避することが可能になる。

その他の例としては、事業所内における全従業者の時間外労働時間の総和が所定の閾値を超過しそうな場合にアラートを発出することが考えられる。従来技術であれば、当該事業所の従業者の時間外労働時間を個別に解析することで労働環境改善のためのアラートを発出するような構成がとられていたと思われる。しかしながら本発明においては複数の従業者の勤怠情報を用いてアラートを発出することになるので、上記例の場合には、当該事業所における業務遂行のやり方ないしは責任者のマネジメントに課題があるのではないか、との仮説が成り立ちうる。そこで発出するアラートも、メンタルヘルスに関するものはもちろん、責任者に対する業務改善検討のためのアラートであったり、業務遂行状況の報告のためのアラートであったりすることも考えられる。

このように本発明においては、単に定量的な情報を取得・解析することによってのみアラートを発出するのではなく、管理者や役職者が定性的な評価を行うためにもアラートを発出することができる点に特徴がある。

なお、ここまで種々説明してきたアラート発出要否の判断については、あらかじめルールを保持しておき、当該ルールを用いて判断する場合のほか、所定の機械学習を通じて得られた特徴量を用いてアラート発出を行う場合も考えられ、いずれの手段を採用することをも排除されない。機械学習を用いる場合については、実施形態２において詳述する。

＜具体的な構成＞
ここで図３を示す。同図は本実施形態のアラート発出システムの機能的な各構成をまとめて一のハードウェアとして実現した際の構成の一例を示す概略図である。各装置はいずれも、それぞれ各種演算処理を実行するための「ＣＰＵ」０３０１と、「記憶装置（記憶媒体）」０３０２と、「メインメモリ」０３０３と、「入力インターフェース」０３０４、「出力インターフェース」０３０５、「ネットワークインターフェース」０３０６と、を備え、入出力インターフェースを介して、例えば「タッチパネル」０３０７や「ディスプレイ」０３０８などの外部周辺装置と情報の送受信を行う。また、ネットワークインターフェースを介して「従業者管理端末」０３０９や他の「電子体温計」０３１０などの外部装置と情報の送受信を行う。このネットワークインターフェースの具体的な態様は有線、無線を問わず、また、通信方法も直接、間接を問わない。よって特定の外部装置ないし同装置の利用者と紐づけられた第三者の管理するサーバとの間で情報の送受信を行ういわゆるクラウドコンピューティングの形式を採用することも可能である。

記憶装置には以下で説明するような各種プログラムが格納されており、ＣＰＵはこれら各種プログラムをメインメモリのワーク領域内に読み出して展開、実行する。なお、これらの構成は、「システムバス」０３９９などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う（以上の構成の基本的な構成は、以下で説明する他の装置のいずれについても同様である。

（従業者ＩＤ保持部の具体的な構成）
従業者ＩＤ保持部は、コンピュータプログラムとコンピュータハードウェアにより構成される。具体的には、ＣＰＵが記憶装置から「従業者ＩＤ記録プログラム」０３０１をメインメモリに読み出して実行し、ネットワークを介してだったり、記憶媒体を介してだったり、キーボードその他の入力インターフェースを介してだったり種々の方法により、一の事業者ＩＤと紐づけて一又は複数の従業者ＩＤの情報の入力を受け付けて、コンピュータの記憶領域に記録する。

従業者ＩＤ保持部においては、いちど入力を受け付けた従業者ＩＤの加除修正も受け付ける場合があり、従業員ＩＤは、それらのログとともにメインメモリの所定のアドレスに格納されることになる。

（勤怠情報入力受付部の具体的な構成）
勤怠情報入力受付部は、コンピュータプログラムとコンピュータハードウェア、より具体的には種々の入力インターフェースにより構成される。具体的には、ＣＰＵが記憶装置から「勤怠情報入力受付プログラム」０３０２をメインメモリに読み出して実行し、一の従業者ＩＤと紐づけて所定就業期間の就業時間を含む勤怠情報の入力を受け付けるように構成されている。

（勤怠情報記録部の具体的な構成）
勤怠情報記録部は、コンピュータプログラムとコンピュータハードウェアにより構成される。具体的には、ＣＰＵが記憶装置から「勤怠情報記録プログラム」０３０３をメインメモリに読み出して実行し、勤怠情報入力受付プログラムの実行により得られた勤怠情報と、当該勤怠情報と紐づけられている従業者ＩＤを従業者ＩＤ保持部から読み出して、ともにメインメモリの所定のアドレスに格納するように構成されている。

（アラート判断部の具体的な構成）
アラート判断部は、具体的にはコンピュータプログラムとコンピュータハードウェアにより構成されている。具体的には、ＣＰＵが記憶装置から「アラート判断プログラム」０３０４をメインメモリに読み出して実行し、勤怠情報記録プログラムの実行により得られた複数の従業員ＩＤと紐づけられた勤怠情報を読み出し、前記一の事業者ＩＤにて特定される事業者の労務管理に関連したアラート発出要否を判断する処理を行い、判断結果をメインメモリの所定のアドレスに格納する。

（アラート発出部の具体的な構成）
アラート発出部は、具体的にはコンピュータプログラムとコンピュータハードウェアにより構成されている。具体的には、ＣＰＵが記憶装置から「アラート発出プログラム」０３０５をメインメモリに読み出して実行し、アラート判断プログラムの実行により得られた判断結果を読み出して当該判断結果に応じてアラートを発出する。具体的には電子メールプログラムを用いて所定の管理者に対しメールの形式にてアラートを発出する方法や、所定の社内ＳＮＳプログラムを実行して所定の管理者に対しショートメッセージその他の形式にてアラートを発出する方法などが考えられる。

＜処理の流れ＞
図４は、本実施形態のアラート発出システムにおける処理の流れの一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップＳ０４０１では、従業者から一の従業者ＩＤと紐づけて所定就業期間の就業時間を含む勤怠情報の入力を受け付ける（勤怠情報入力受付ステップ）。その後、ステップＳ０４０２で 受け付けた勤怠情報を当該従業者ＩＤと紐づけて記録する（勤怠情報記録ステップ）。そしてステップＳ０４０３では、記録された複数の従業者ＩＤと紐づけられた勤怠情報に基づいて前記一の事業者ＩＤにて特定される事業者の労務管理に関連したアラート発出要否を判断（アラート判断ステップ）し、ここでの判断結果がアラートを発出する必要がないとの内容であれば、その後の処理は行わない。いっぽうアラートを発出する必要があるとの内容であれば、ステップＳ０４０４の処理に移行する。つまりステップＳ０４０４においては、アラート判断ステップの判断内容に応じてアラートを発出する（アラート発出ステップ）。

図５は、本実施形態のアラート発出システムにおける処理の別の流れの一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップＳ０５０１では、従業者から一の従業者ＩＤと紐づけて所定就業期間の就業時間を含む勤怠情報の入力を受け付ける（勤怠情報入力受付ステップ）。その後、ステップＳ０５０２で 受け付けた勤怠情報を当該従業者ＩＤと紐づけて記録する（勤怠情報記録ステップ）。そしてステップＳ０５０３では、記録された複数の従業者ＩＤと紐づけられた勤怠情報に基づいて前記一の事業者ＩＤにて特定される事業者の労務管理に関連したアラート発出要否を判断（アラート判断ステップ）する。ここでは、従業者の雇用条件をも用いてアラート発出要否を判断するように構成されてもよいし（条件利用サブステップ）、労務管理インシデント情報をも用いてアラート発出要否を判断してもよい（インシデント利用サブステップ）。そしてここでの判断結果がアラートを発出する必要がないとの内容であれば、その後の処理は行わない。いっぽうアラートを発出する必要があるとの内容であれば、ステップＳ０５０４の処理、すなわち、アラート判断ステップの判断内容に応じてアラートを発出する（アラート発出ステップ）。

図６は、本実施形態のアラート発出システムにおける処理のさらに別の流れの一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップＳ０６０１では、従業者から一の従業者ＩＤと紐づけて所定就業期間の就業時間を含む勤怠情報の入力を受け付ける（勤怠情報入力受付ステップ）。その後、ステップＳ０６０２で 受け付けた勤怠情報を当該従業者ＩＤと紐づけて記録する（勤怠情報記録ステップ）。そしてステップＳ０６０３では、記録された複数の従業者ＩＤと紐づけられた勤怠情報と、かつて記録されたアラート実績情報をも用いてに基づいて前記一の事業者ＩＤにて特定される事業者の労務管理に関連したアラート発出要否を判断（実績利用サブステップ）し、ここでの判断結果がアラートを発出する必要がないとの内容であれば、その後の処理は行わない。いっぽうアラートを発出する必要があるとの内容であれば、ステップＳ０６０４の処理、すなわち、アラート判断ステップの判断内容に応じてアラートを発出する（アラート発出ステップ）する。その後ステップＳ０６０５では、発出されたアラートの内容及び発出の事実（発出の有無を含む）を含む情報であるアラート実績情報を事業者ＩＤと関連付けて記録する（アラート実績記録ステップ）。

＜効果＞
以上の構成を採用するアラート発出システムを利用することにより、職種や業態、労働者の働きかたに応じた労務管理を行いやすくするだけでなく、事業者が気付かなかったような事業所全体、事業者全体といったマクロレベルの労務リスクをいち早く察知させることが可能になる。

＜＜実施形態２＞＞
＜概要＞
本実施形態のアラート発出システムは、基本的には実施形態１に記載のアラート発出システムの技術的特徴と同様であるが、勤怠情報と事業者ＩＤと学習済の学習済モデルとを用いてアラート発出要否を判断することを更なる技術的特徴として備えている。以下では、実施形態１で言及した点とは異なる上記特徴について詳しく説明をする。

＜機能的構成＞
図７は、本実施形態のアラート発出方法を一のシステムにて実現する場合の機能ブロックの一例を示す図である。同図において示されているように、本実施形態の「アラート発出システム」０７００は、「従業者ＩＤ保持部」０７０１と、「勤怠情報入力受付部」０７０２と、「勤怠情報記録部」０７０３と、「アラート判断部」０７０４と、「アラート発出部」０７０５と、を有し、アラート判断部は、「学習済モデル利用手段」０７１４をさらに有する。基本的な構成は、実施形態１の図２を用いて説明したアラート発出システムと共通するため、以下では相違点である「学習済モデル利用手段」０７１４の機能について説明する。

「学習済モデル利用手段」０７１４は、アラート判断部にて、勤怠情報と事業者ＩＤと学習済の学習済モデルとを用いてアラート発出要否を判断するように構成されている。具体的には、学習済モデルに対して事業者ＩＤと紐づいた勤怠情報を入力することにより、所定の労務管理インシデント情報に対応したアラート発出の要否を判断するように構成されている。

なおここで、ここまで説明してきた学習済モデルの生成方法についても説明する。

＜学習済モデルの生成方法＞
本実施形態で説明する学習済モデルは、例えば、事業者ＩＤと、一又は複数の従業者の勤怠情報と、労務管理インシデント情報と、を含む訓練データを取得する情報取得ステップと、前記訓練データに基づき、事業者ＩＤ及び複数の勤怠情報の入力を受け付ける情報入力受付ステップと、当該事業者ＩＤにて識別される事業者に対応する労務管理インシデント情報を識別した識別結果を出力することを内容とする学習済モデルを生成するモデル生成ステップと、をコンピュータにて処理することによって生成することが考えられる。

ここで図８を示す。同図は本実施形態で用いる学習済モデルの生成方法の流れの一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップＳ０８０１では、事業者ＩＤと、一又は複数の従業者の勤怠情報と、労務管理インシデント情報と、を含む訓練データを取得する（情報取得ステップ）。ここで勤怠情報と労務管理インシデント情報とはそれぞれ別個の入力受付手段により取得することが可能である。例えば勤怠情報については事業者の管理する労務管理のための情報が格納されているサーバから取得し、労務管理インシデント情報については、労務専門家の管理するサーバから取得する、といった具合である。

訓練データとは所定の労務管理インシデントに対応したアラート発出の要否を判断するために用いられる。そのため訓練データを構成する勤怠情報もまた、労務管理インシデントに対応した内容の情報を含んでいることが必要である。具体的には、いち事業所内における従業者の所定時間労働時間数や欠勤日数、休日出勤数などの情報などが該当し、これらの情報が学習用データとして用いられることになる。

より具体的にいえば、勤怠情報を構成する種々の情報に対してそれぞれ労務管理インシデントに対応するラベルを付与する処理が行われ、全体として訓練データとして取得し保持されることになる。

「情報入力受ステップ」Ｓ０８０２は、前記訓練データに基づき、事業者ＩＤ及び複数の勤怠情報の入力を受け付ける。特定の事業者に紐づけられるように事業者ＩＤを取得する構成を採用することで、本発明において生成される学習済モデルを、一の事業者の事業実態に即したアラート発出の要否判断に資するものにすることができる。

「モデル生成ステップ」Ｓ０８０３は、当該事業者ＩＤにて識別される事業者に対応する労務管理インシデント情報を識別した識別結果を出力することを内容とする学習済モデルを生成する。具体的な一例としては、所定の労務管理インシデント情報に関連して、ＧｏｏｇＬｅＮｅｔその他の所与の事前学習済みの畳み込みニューラルネットワークに対して事業者ＩＤと紐づいて入力された勤怠情報を入力することで、当該労務管理インシデント情報に対応した学習済モデルを生成することができる。

より具体的にいうと、畳み込みニューラルネットワークの出力層では前記種々の勤怠情報に対応した情報に関する出力値が出力されるものとし、所定のクロスエントロピー誤差関数等を通じてチューニングされる。

なお、この学習済モデルは、例えば、外部の管理端末からの入力により適宜更新されるものであってもよい。具体的には、すでに説明したアラート実績情報であったり、外部専門家等の管理する端末から適宜の情報を取得し、チューニング等更新のための処理を施すことでその内容を改訂したりすることが可能である。当該構成を採用することにより、当該時点の内部及び外部情勢をより反映させた実効性あるアラート発出の要否判断の用に供する学習済モデルの提供が可能になる。

ちなみにここまでは、学習済モデル利用手段に関連して、一の事業者ＩＤと関連付けて生成された学習済モデルを用いてアラート発出の要否を判断する構成について説明してきた。これにさらに加えて、他の事業者ＩＤを関連付けられていたり、特定の業種・業態に関連付けられていたりする学習済モデルをも用いてアラート発出の要否を判断することも可能である。具体的には、自らの事業者ＩＤと関連付けられた学習済モデルを用いて得られた判断結果と、それ以外の学習済モデルを用いて得られた判断結果とを比べて判断を行う。例えば、当該判断結果においてよりリスクの高いと判断される判断結果に従ってアラート発出の要否を判断することが考えられる。また別の例としては、両判断結果の平均値をとりその結果をもってアラート発出の要否を判断することも考えられる。いずれにしても、複数の判断結果を複合的に用いる構成を採用することによって、事業者の特性に留意しつつも、より社会実態に即したアラート発出の要否判断ができるようになる。

＜具体的な構成＞
本実施形態のアラート発出システムを構成する各装置のハードウェア構成は、基本的には、図３を用いて説明した実施形態１のアラート発出システムにおけるハードウェア構成と同様である。そこで以下については、これまで説明していない「学習済モデル利用手段」の具体的な処理について説明する。

（学習済モデル利用手段の具体的な構成）
学習済モデル利用手段は、コンピュータプログラムとコンピュータハードウェアにより構成される。具体的には、ＣＰＵが記憶装置からアラート判断プログラムをメインメモリに読み出して実行するに際し、学習済モデル利用サブプログラムを読み出して実行し、記憶装置に格納されている学習済モデルに勤怠情報と事業者ＩＤとを入力して得られる出力結果に応じてアラート発出要否を判断する処理を行い、判断結果をメインメモリの所定のアドレスに格納する。

＜処理の流れ＞
図９は、本実施形態のアラート発出システムにおける処理の別の流れの一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップＳ０９０１では、従業者から一の従業者ＩＤと紐づけて所定就業期間の就業時間を含む勤怠情報の入力を受け付ける（勤怠情報入力受付ステップ）。その後、ステップＳ０９０２で 受け付けた勤怠情報を当該従業者ＩＤと紐づけて記録する（勤怠情報記録ステップ）。そしてステップＳ０９０３では、記録された複数の従業者ＩＤと紐づけられた勤怠情報に基づいて前記一の事業者ＩＤにて特定される事業者の労務管理に関連したアラート発出要否を判断（アラート判断ステップ）する。ここでは、勤怠情報と事業者ＩＤと学習済の学習済モデルとを用いてアラート発出要否を判断してもよい（学習済モデル利用サブステップ）。そしてここでの判断結果がアラートを発出する必要がないとの内容であれば、その後の処理は行わない。いっぽうアラートを発出する必要があるとの内容であれば、ステップＳ０９０４の処理、すなわち、アラート判断ステップの判断内容に応じてアラートを発出する（アラート発出ステップ）。

０２００・・・アラート発出システム、０２０１・・・従業者ＩＤ保持部、０２０２・・・勤怠情報入力受付部、０２０３・・・勤怠情報記録部、０２０４・・・アラート判断部、０２０５・・・アラート発出部

Claims (7)

1. 一の事業者ＩＤと紐づけて複数の従業者ＩＤを保持する従業者ＩＤ保持部を有するサーバを用いた労務管理アラート発出方法であって、
   一の従業者ＩＤと紐づけて所定就業期間の就業時間を含む勤怠情報の入力を受け付ける勤怠情報入力受付ステップと、
   受け付けた勤怠情報を当該従業者ＩＤと紐づけて記録する勤怠情報記録ステップと、
   記録された複数の従業者ＩＤと紐づけられた勤怠情報に基づいて前記一の事業者ＩＤにて特定される事業者の労務管理に関連したアラート発出要否を判断するアラート判断ステップと、
   アラート判断ステップの判断内容に応じてアラートを発出するアラート発出ステップと、
   をコンピュータに実行させるアラート発出方法。
2. 従業者ＩＤ保持部は、従業者の雇用条件をも当該従業者の従業者ＩＤと紐づけて保持し、
   アラート判断ステップは、従業者の雇用条件をも用いてアラート発出要否を判断する条件利用サブステップをさらに有する請求項１に記載のアラート発出方法。
3. 労務管理に関連したインシデント情報である労務管理インシデント情報を記録するインシデント記録ステップをさらにコンピュータに実行させ、
   アラート判断ステップは、労務管理インシデント情報との関係において設定される閾値をも用いてアラート発出要否を判断するインシデント利用サブステップをさらに有する請求項１又は２に記載のアラート発出方法。
4. アラート発出ステップは、アラート判断ステップの判断内容に応じて、異なる態様のアラートを発出する請求項１から３のいずれか一に記載のアラート発出方法。
5. アラート発出ステップにて発出されたアラートの内容及び発出の事実を含む情報であるアラート実績情報を事業者ＩＤと関連付けて記録するアラート実績記録ステップをさらにコンピュータに実行させ、
   アラート判断ステップは、記録されたアラート実績情報をも用いてアラート発出要否を判断する実績利用サブステップをさらに有する請求項１から４のいずれか一に記載のアラート発出方法。
6. 一の事業者ＩＤと紐づけて複数の従業者ＩＤを保持する従業者ＩＤ保持部を含むサーバと情報を送受信するコンピュータにて実行可能な労務管理アラート発出プログラムであって、
   一の従業者ＩＤと紐づけて所定就業期間の就業時間を含む勤怠情報の入力を受け付ける勤怠情報入力受付ステップと、
   受け付けた勤怠情報を当該従業者ＩＤと紐づけて記録する勤怠情報記録ステップと、
   記録された複数の従業者ＩＤと紐づけられた勤怠情報に基づいて前記一の事業者ＩＤにて特定される事業者の労務管理に関連したアラート発出要否を判断するアラート判断ステップと、
   アラート判断ステップの判断内容に応じてアラートを発出するアラート発出ステップと、
   を備えるアラート発出プログラム。
7. 一の事業者ＩＤと紐づけて複数の従業者ＩＤを保持する従業者ＩＤ保持部と、
   一の従業者ＩＤと紐づけて所定就業期間の就業時間を含む勤怠情報の入力を受け付ける勤怠情報入力受付部と、
   受け付けた勤怠情報を当該従業者ＩＤと紐づけて記録する勤怠情報記録部と、
   記録された複数の従業者ＩＤと紐づけられた勤怠情報に基づいて前記一の事業者ＩＤにて特定される事業者の労務管理に関連したアラート発出要否を判断するアラート判断部と、
   アラート判断ステップの判断内容に応じてアラートを発出するアラート発出部と、
   を備えるアラート発出システム。

Images