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

Abstract

【課題】従業員の働き方の多様化及び生産性向上を図るための業務管理システム、業務管理方法及び業務管理プログラムを提供する。【解決手段】ユーザに付与された社内通貨額を記録するユーザ情報記憶部２２と、部署に付与された社内通貨額を記録する通貨情報記憶部２４と、制御部２１を備える。そして、制御部２１は、各部署の繁忙状況を取得し、繁忙状況に応じて繁忙部署を特定し、繁忙部署に対して、繁忙状況に応じて付与した社内通貨額を通貨情報記憶部２４に記録し、通貨情報記憶部２４に記録された社内通貨額により、繁忙部署を応援できるユーザを公募し、公募により応援したユーザに対して付与する社内通貨額をユーザ情報記憶部２２に記録する。【選択図】図１

Description

本発明は、企業内の業務の効率化を図るための業務管理システム、業務管理方法及び業務管理プログラムに関する。

生産年齢人口の減少や働くスタイルの多様化等に対応するため、生産性の向上や労働環境の改善が求められている。この労働環境の改善を目的として、超過勤務時間の管理が着目されている。

例えば、労働者の時間外労働や長時間労働を、強制力を持って抑止するための技術も検討されている（例えば、特許文献１参照）。特許文献１に記載された技術では、労働時間管理サーバは、労働者の個人別の勤務状況を把握し、労働者の個人別の勤務状況に基づいて、労働者の個人別の労働時間を把握する。そして、上限閾値を超える状態である労働者について、抑止対象者として、抑止対象者が設備またはエリアを利用して業務を行なうことを不可能とする。

また、企業と従業員の活動をポイントで数値化するための社内通貨システムも検討されている（例えば、特許文献２参照）。特許文献２に記載された技術では、従業員毎の社内通貨としての通貨ポイントの付与、蓄積、加算、減算処理する通貨ポイント用の管理サーバと社内通貨ポイント用のデータベースとを用いる。従業員に業績評価に見合った評価ポイントを付与して管理するとともに、評価ポイント等を社内通貨データに変換する。

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

しかしながら、繁忙部署が存在する場合、従業員の自発的な協力関係を作る仕組みでなければ、生産性向上や負荷分散を図った労働環境を実現できない。また、企業においても、コストパフォーマンスに見合った仕組みが必要である。

上記課題を解決する業務管理システムは、ユーザに付与された社内通貨額を記録するユーザ情報記憶部と、部署に付与された社内通貨額を記録する通貨情報記憶部と、制御部とを備える。そして、前記制御部が、各部署の繁忙状況を取得し、前記繁忙状況に応じて繁忙部署を特定し、前記繁忙部署に対して、前記繁忙状況に応じて付与した社内通貨額を前記通貨情報記憶部に記録し、前記通貨情報記憶部に記録された社内通貨額により、前記繁忙部署を応援できるユーザを公募し、前記公募により応援したユーザに対して付与する社内通貨額を前記ユーザ情報記憶部に記録する。

本発明によれば、従業員の働き方の多様化及び生産性向上を図ることができる。

本実施形態の業務管理システムの説明図。 本実施形態のハードウェア構成の説明図。 本実施形態の情報記憶部の説明図であって、（ａ）はユーザ情報記憶部、（ｂ）は勤怠情報記憶部、（ｃ）は通貨情報記憶部、（ｄ）は公募情報記憶部、（ｅ）はエントリー情報記憶部、（ｆ）は評価情報記憶部の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図であって、（ａ）は制度評価処理、（ｂ）は部署評価処理の説明図。 本実施形態の社内通貨制度の概要の説明図。

以下、図１〜図８に従って、業務管理システム、業務管理方法及び業務管理プログラムを具体化した実施形態を説明する。本実施形態では、社内通貨を利用して、繁忙部署の業務を応援することにより、従業員の働き方の多様化及び生産性向上を図る業務管理を説明する。

図８に示す社内通貨制度の仕組みにより、従業員の働き方の多様化及び生産性向上を図る。
まず、超過勤務費用を算出する（ステップＳ１）。超過勤務費用には、繁忙部署において実際に発生している残業費や、将来発生する可能性がある残業費等がある。

次に、この超過人件費を社内通貨に変換する（ステップＳ２）。この社内通貨は、企業内で現金と同様に利用できる価値である。そして、この社内通貨を原資として、超過人件費が生じる業務を応援できる従業員を募集する（ステップＳ３）。
次に、社内通貨を、繁忙部署の応援者に提供する（ステップＳ４）。
更に、応援者に提供した社内通貨により、応援者を拠出した拠出元部署を評価する（ステップＳ５）。これにより、所属部署の本来業務の生産性の向上を図る。

図１に示すように、このような社内制度を管理するために、ユーザ端末１０、管理サーバ２０を用いる。

（ハードウェア構成の説明）
図２を用いて、ユーザ端末１０、管理サーバ２０を構成する情報処理装置Ｈ１０のハードウェア構成を説明する。情報処理装置Ｈ１０は、通信装置Ｈ１１、入力装置Ｈ１２、表示装置Ｈ１３、記憶部Ｈ１４、プロセッサＨ１５を備える。なお、このハードウェア構成は一例であり、他のハードウェアにより実現することも可能である。

通信装置Ｈ１１は、他の装置との間で通信経路を確立して、データの送受信を実行するインタフェースであり、例えばネットワークインタフェースカードや無線インタフェース等である。

入力装置Ｈ１２は、利用者等からの入力を受け付ける装置であり、例えばマウスやキーボード等である。表示装置Ｈ１３は、各種情報を表示するディスプレイ等である。
記憶部Ｈ１４は、ユーザ端末１０、管理サーバ２０の各種機能を実行するためのデータや各種プログラムを格納する記憶装置である。記憶部Ｈ１４の一例としては、ＲＯＭ、ＲＡＭ、ハードディスク等がある。

プロセッサＨ１５は、記憶部Ｈ１４に記憶されるプログラムやデータを用いて、ユーザ端末１０、管理サーバ２０における各処理を制御する。プロセッサＨ１５の一例としては、例えばＣＰＵやＭＰＵ等がある。このプロセッサＨ１５は、ＲＯＭ等に記憶されるプログラムをＲＡＭに展開して、各サービスのための各種プロセスを実行する。

プロセッサＨ１５は、自身が実行するすべての処理についてソフトウェア処理を行なうものに限られない。例えば、プロセッサＨ１５は、自身が実行する処理の少なくとも一部についてハードウェア処理を行なう専用のハードウェア回路（例えば、特定用途向け集積回路：ＡＳＩＣ）を備えてもよい。すなわち、プロセッサＨ１５は、（１）コンピュータプログラム（ソフトウェア）に従って動作する１つ以上のプロセッサ、（２）各種処理のうち少なくとも一部の処理を実行する１つ以上の専用のハードウェア回路、或いは（３）それらの組み合わせ、を含む回路（circuitry）として構成し得る。プロセッサは、ＣＰＵ並びに、ＲＡＭ及びＲＯＭ等のメモリを含み、メモリは、処理をＣＰＵに実行させるように構成されたプログラムコード又は指令を格納している。メモリすなわちコンピュータ可読媒体は、汎用又は専用のコンピュータでアクセスできるあらゆる利用可能な媒体を含む。

（各機能部の説明）
ユーザ端末１０は、各部署に所属する従業員や管理者が用いるコンピュータ端末である。従業員は、このユーザ端末１０を用いて、公募に対するエントリーを行なう。

管理サーバ２０は、社内通貨を利用した業務管理を支援するコンピュータシステムである。この管理サーバ２０は、制御部２１、ユーザ情報記憶部２２、勤怠情報記憶部２３、通貨情報記憶部２４、公募情報記憶部２５、エントリー情報記憶部２６、評価情報記憶部２７を備える。

制御部２１は、勤怠管理段階、通貨管理段階、募集段階、評価段階等の各処理等を行なう。このため、管理サーバ２０には、業務管理アプリケーション（サーバ用）が格納されている。業務管理アプリケーションを起動することにより、制御部２１は、勤怠管理部２１１、通貨管理部２１２、募集部２１３、評価部２１４として機能する。

勤怠管理部２１１は、従業員の勤怠を管理する処理を実行する。
通貨管理部２１２は、従業員に提供する社内通貨を管理する処理を実行する。この通貨管理部２１２は、超過勤務時間から超過勤務費用を算出する費用算出情報を保持している。例えば、超過勤務費用は、超過勤務時間の単位時間当たりの人件費等を用いて算出することができる。
募集部２１３は、社内通貨をインセンティブとして、繁忙部署の業務を応援できる従業員を公募する処理を実行する。
評価部２１４は、社内通貨による業務の効率化を評価する処理を実行する。

図３（ａ）に示すように、ユーザ情報記憶部２２には、各ユーザ（従業員）についてのユーザ管理レコード２２０が記録される。このユーザ管理レコード２２０は、ユーザ登録が行なわれた場合に記録される。ユーザ管理レコード２２０には、ユーザＩＤ、所属部署、連絡先、業務履歴、スキル、業務評価、通貨残高等に関するデータが記録される。

ユーザＩＤデータ領域には、各従業員を特定するための識別子に関するデータが記録される。
所属部署データ領域には、この従業員の所属部署を特定するための識別子に関するデータが記録される。

連絡先データ領域には、この従業員の連絡先（例えば、メールアドレス）に関するデータが記録される。
業務履歴データ領域には、この従業員が経験した業務の履歴に関するデータが記録される。

スキルデータ領域には、この従業員の業務のレベルを特定するための識別子に関するデータが記録される。
業務評価データ領域には、この従業員に対する業務における評価結果に関するデータが記録される。この業務評価には、本来の業務における評価結果（本来業務評価）だけではなく、応援における評価結果（応援業務評価）も含まれる。

通貨残高データ領域には、この従業員が保有する社内通貨の残高に関するデータが記録される。このデータ領域には、履歴情報として、社内通貨が付与された応援を特定するための公募ＩＤ、付与額が記録される。

図３（ｂ）に示すように、勤怠情報記憶部２３には、各ユーザ（従業員）の勤怠についての勤怠管理レコード２３０が記録される。この勤怠管理レコード２３０は、勤怠情報が登録された場合に記録される。勤怠管理レコード２３０には、ユーザＩＤ、勤怠状況等に関するデータが記録される。

ユーザＩＤデータ領域には、各従業員を特定するための識別子に関するデータが記録される。
勤怠状況データ領域には、この従業員の勤怠状況に関するデータが記録される。勤怠状況としては、年月日に対して出勤時刻や退勤時刻、超過勤務の業務内容を用いる。応援業務を行なった場合には、業務内容として応援を行なった公募ＩＤ、拠出先部署の部署ＩＤが記録される。

図３（ｃ）に示すように、通貨情報記憶部２４には、企業内で社内公募に用いる社内通貨についての通貨管理レコード２４０が記録される。この通貨管理レコード２４０は、公募を行なう場合に記録される。通貨管理レコード２４０には、提供日、提供先部署、繁忙度、提供額、公募ＩＤ等に関するデータが記録される。

提供日データ領域には、社内公募のために、繁忙部署に社内通貨を提供した年月日に関するデータが記録される。
提供先部署データ領域には、社内通貨を提供した繁忙部署を特定するための識別子に関するデータが記録される。

繁忙度データ領域には、繁忙部署において予測される繁忙度に関するデータが記録される。本実施形態では、この繁忙度は、予測した超過勤務時間を用いる。
提供額データ領域には、この部署に提供した社内通貨額に関するデータが記録される。
公募ＩＤデータ領域には、この社内通貨額を用いる公募を特定するための識別子に関するデータが記録される。

図３（ｄ）に示すように、公募情報記憶部２５には、各ユーザ（従業員）の社内公募についての公募管理レコード２５０が記録される。この公募管理レコード２５０は、社内公募の登録が行なわれた場合に記録される。公募管理レコード２５０には、公募ＩＤ、募集部署、募集内容、公募人数、単位提供額、応募期限、付与総額等に関するデータが記録される。

公募ＩＤデータ領域には、各公募を特定するための識別子に関するデータが記録される。
募集部署データ領域には、この公募を行なう部署（拠出先部署）を特定するための識別子に関するデータが記録される。

募集内容データ領域には、この公募において行なう業務内容を特定するための識別子に関するデータが記録される。
公募人数データ領域には、この公募における募集人数を特定するための識別子に関するデータが記録される。

単位提供額データ領域には、この公募における応援時の単位時間当たりに提供する社内通貨額に関するデータが記録される。
応募期限データ領域には、この公募を締め切る年月日及び時刻に関するデータが記録される。
付与総額データ領域には、この公募における応援で、応援者に付与した社内通貨の総額に関するデータが記録される。

図３（ｅ）に示すように、エントリー情報記憶部２６には、公募に対する応募を管理するためのエントリー管理レコード２６０が記録される。このエントリー管理レコード２６０は、社内公募の登録が行なわれた場合に記録される。エントリー管理レコード２６０には、公募ＩＤ、エントリー者、応援者等に関するデータが記録される。

公募ＩＤデータ領域には、各公募を特定するための識別子に関するデータが記録される。
エントリー者データ領域には、この公募に対するエントリー者（従業員）を特定するための識別子（ユーザＩＤ）に関するデータが記録される。
応援者データ領域には、エントリー者の中で決定した応援者（従業員）を特定するための識別子（ユーザＩＤ）に関するデータが記録される。

図３（ｆ）に示すように、評価情報記憶部２７には、各公募を評価するための評価管理レコード２７０が記録される。この評価管理レコード２７０は、評価処理が行なわれた場合に記録される。評価管理レコード２７０には、拠出元部署、拠出先部署、拠出者、評価結果等に関するデータが記録される。

拠出元部署データ領域には、各部署（拠出元）を特定するための識別子に関するデータが記録される。
拠出先部署データ領域には、この拠出元部署に所属する従業員を拠出した拠出先部署を特定するための識別子に関するデータが記録される。

拠出者データ領域には、拠出した従業員を特定するための識別子に関するデータが記録される。
評価結果データ領域には、この部署（拠出元）における拠出のための業務の効率化を評価した結果に関するデータが記録される。

（募集管理処理）
次に、図４を用いて、募集管理処理を説明する。
まず、管理サーバ２０の制御部２１は、繁忙部署の特定処理を実行する（ステップＳ１−１）。具体的には、制御部２１の勤怠管理部２１１は、勤怠情報記憶部２３を用いて、各部署の繁忙度を評価する。例えば、勤怠状況において、各部署の従業員毎に、直近所定期間の時間外労働による超過勤務時間を特定する。そして、勤怠管理部２１１は、繁忙度として、超過勤務の統計値（例えば、総時間）を算出する。また、各部署において新規プロジェクトが計画されている場合、勤怠管理部２１１は、この新規プロジェクトに想定される超過勤務の統計値を、管理者のユーザ端末１０から取得してもよい。そして、勤怠管理部２１１は、繁忙度が第１基準値以上の部署を繁忙部署として特定する。勤怠管理部２１１は、提供日データ領域に現在年月日を記録した通貨管理レコード２４０を生成し、通貨情報記憶部２４に記録する。更に、通貨管理部２１２は、通貨管理レコード２４０において、提供先部署として繁忙部署、繁忙度に関するデータを記録する。

次に、管理サーバ２０の制御部２１は、拠出する社内通貨額の算出処理を実行する（ステップＳ１−２）。具体的には、制御部２１の通貨管理部２１２は、特定した繁忙部署において、削減対象の超過勤務時間を算出する。例えば、超過勤務時間が第２基準値以下になるように、両者の差分時間を算出する。通貨管理部２１２は、超過勤務の費用算出情報を用いて、差分時間の超過勤務時間を行なった場合の超過勤務費用を算出する。そして、通貨管理部２１２は、この超過勤務費用に対応する社内通貨額を算出する。

次に、管理サーバ２０の制御部２１は、繁忙部署への社内通貨の付与処理を実行する（ステップＳ１−３）。具体的には、制御部２１の通貨管理部２１２は、通貨管理レコード２４０の提供額データ領域に、算出した社内通貨額に関するデータを記録する。更に、通貨管理部２１２は、この社内通貨額を用いる公募ＩＤを付与し、通貨管理レコード２４０に記録する。

次に、管理サーバ２０の制御部２１は、繁忙部署において公募する業務内容の特定処理を実行する（ステップＳ１−４）。具体的には、制御部２１の通貨管理部２１２は、繁忙部署に所属する従業員の中で、勤怠情報記憶部２３に記録された勤怠状況を用いて、超過勤務時間が長い従業員（被応援者）を特定する。そして、通貨管理部２１２は、この被応援者の勤怠状況を用いて、超過勤務の業務内容を特定する。ここで、通貨管理部２１２は、特定した超過勤務時間が長い被応援者の人数を、公募人数として特定する。

次に、管理サーバ２０の制御部２１は、超過勤務費用を基準にして社内通貨の設定処理を実行する（ステップＳ１−５）。具体的には、制御部２１の通貨管理部２１２は、超過勤務時間の単位時間当たりの超過勤務費用に対応する社内通貨額を単位提供額として算出する。

次に、管理サーバ２０の制御部２１は、社内通貨を用いた社内公募の設定処理を実行する（ステップＳ１−６）。具体的には、制御部２１の募集部２１３は、社内通貨額を用いる公募ＩＤを付与した公募管理レコード２５０を生成し、公募情報記憶部２５に記録する。更に、募集部２１３は、募集部署（繁忙部署）、募集内容、公募人数、単位提供額を公募管理レコード２５０に記録する。そして、募集部２１３は、現在日から所定期間を加算した応募期限を公募管理レコード２５０に記録する。更に、募集部２１３は、公募ＩＤを記録したエントリー管理レコード２６０を生成し、エントリー情報記憶部２６に記録する。この段階では、エントリー者、応援者の各データ領域は空欄である。

次に、管理サーバ２０の制御部２１は、社内公開処理を実行する（ステップＳ１−７）。具体的には、制御部２１の募集部２１３は、公募画面を生成し、従業員のユーザ端末１０で閲覧できるように公開する。この公募画面には、公募情報記憶部２５に記録された公募管理レコード２５０の各データを含める。

（応募時処理）
次に、図５を用いて、応募時処理を説明する。
まず、管理サーバ２０の制御部２１は、エントリー処理を実行する（ステップＳ２−１）。具体的には、公募画面を閲覧した従業員が応募を行なう場合には、ユーザ端末１０を用いて、エントリー依頼を送信する。このエントリー依頼には、応募希望の従業員のユーザＩＤ、公募ＩＤに関するデータを含める。エントリー依頼を受信した制御部２１の募集部２１３は、公募ＩＤが記録されたエントリー管理レコード２６０のエントリー者データ領域に、この従業員のユーザＩＤを記録する。

次に、エントリー管理処理を説明する。
ここでは、管理サーバ２０の制御部２１は、エントリー状況の監視処理を実行する（ステップＳ２−２）。具体的には、制御部２１の募集部２１３は、各エントリー管理レコード２６０に記録されたエントリー者のユーザＩＤ数をカウントすることによりエントリー数を算出する。

次に、管理サーバ２０の制御部２１は、エントリー状況において、アンバランスが生じているかどうかについての判定処理を実行する（ステップＳ２−３）。具体的には、制御部２１の募集部２１３は、公募情報記憶部２５に記録された公募人数を取得する。次に、募集部２１３は、応募期限までの残り時間に応じて、許容範囲を特定する。ここでは、残り時間が少ない程、許容範囲を狭く設定する。次に、募集部２１３は、募集人数に対するエントリー数の割合を算出し、この割合が許容範囲を逸脱している場合にはアンバランスが生じていると判定する。
ここで、アンバランスが生じていないと判定した場合（ステップＳ２−３において「ＮＯ」の場合）、制御部２１の募集部２１３は、エントリー状況の監視処理を継続する（ステップＳ２−２）。

エントリー状況において、アンバランスが生じていると判定した場合（ステップＳ２−３において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、単位提供額は基準額かどうかについての判定処理を実行する（ステップＳ２−４）。具体的には、制御部２１の通貨管理部２１２は、単位提供額と、単位時間当たりの超過勤務費用に対応する社内通貨額とを比較する。両者が一致する場合には、単位提供額は基準額と判定する。

単位提供額は基準額と判定した場合（ステップＳ２−４において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、エントリー状況に応じて単位提供額の変更処理を実行する（ステップＳ２−５）。具体的には、制御部２１の通貨管理部２１２は、エントリー数に応じて、公募情報記憶部２５に記録された単位提供額を変更する。ここで、エントリー数が募集人数よりも多い場合には、公募情報記憶部２５に記録された単位提供額を減らし、少ない場合には単位提供額を増やす。

一方、既に、エントリー状況に応じて単位提供額の変更処理（ステップＳ２−５）を実行済みの場合、単位提供額と、単位時間当たりの超過勤務費用に対応する社内通貨額とが異なる。そして、単位提供額は調整済と判定した場合（ステップＳ２−４において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、エントリー過多かどうかについての判定処理を実行する（ステップＳ２−６）。具体的には、制御部２１の通貨管理部２１２は、エントリー数の割合が許容範囲よりも高い場合には、エントリー過多と判定する。

エントリー過多と判定した場合（ステップＳ２−６において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、エントリー者に対して変更提案処理を実行する（ステップＳ２−７）。具体的には、制御部２１の募集部２１３は、アンバランスと判定したエントリー管理レコード２６０に記録されたエントリー者のユーザＩＤを特定する。次に、募集部２１３は、ユーザＩＤに関連付けられた連絡先を、ユーザ情報記憶部２２から取得する。そして、募集部２１３は、取得した連絡先に対して、エントリー数が少ない公募への変更を提案する。

一方、エントリー数の割合が許容範囲よりも低く、エントリー過少と判定した場合（ステップＳ２−６において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、エントリー状況に応じて単位提供額の変更処理を実行する（ステップＳ２−５）。具体的には、制御部２１の通貨管理部２１２は、公募情報記憶部２５に記録された単位提供額を、再度、増やす。

（応援時処理）
次に、図６を用いて、応援時処理を説明する。
まず、管理サーバ２０の制御部２１は、締め切り処理を実行する（ステップＳ３−１）。具体的には、制御部２１の募集部２１３は、公募情報記憶部２５の公募管理レコード２５０に記録された応募期限が到来した場合、この公募管理レコード２５０についての公募画面の公開を終了する。

次に、管理サーバ２０の制御部２１は、応援者の決定処理を実行する（ステップＳ３−２）。具体的には、制御部２１の募集部２１３は、公募管理レコード２５０に記録されたエントリー者の中から応援者を特定する。本実施形態では、募集部２１３は、ユーザ情報記憶部２２から、すべてのエントリー者のユーザ管理レコード２２０を取得し、業務評価が高い順番に公募人数分の応援者を特定する。そして、募集部２１３は、特定した応援者のユーザＩＤをエントリー管理レコード２６０に記録する。更に、募集部２１３は、ユーザ情報記憶部２２から、応援者の連絡先を取得し、応援者の決定通知を送信する。

そして、応援者は拠出先部署の指示に従って応援業務を行なう。この場合、応援者は、応援時間を、勤怠情報記憶部２３の勤怠管理レコード２３０に記録する。
拠出先部署において、応援業務を完了した場合、拠出先部署の管理者は、ユーザ端末１０を用いて応援完了情報を管理サーバ２０に送信する。この応援完了情報には、公募ＩＤ、拠出先部署の部署ＩＤ、応援者のユーザＩＤ、応援業務の評価結果を含める。

応援完了情報を受信した管理サーバ２０の制御部２１は、応援時間の特定処理を実行する（ステップＳ３−３）。具体的には、制御部２１の勤怠管理部２１１は、勤怠情報記憶部２３から、応援者のユーザＩＤが記録された勤怠管理レコード２３０において、公募ＩＤに関連付けられた勤務時間（応援時間）を特定する。

次に、管理サーバ２０の制御部２１は、応援者に社内通貨の付与処理を実行する（ステップＳ３−４）。具体的には、制御部２１の通貨管理部２１２は、公募情報記憶部２５の公募管理レコード２５０に記録された単位提供額に対して、応援時間を乗算することにより、応援者に提供する社内通貨額を算出する。そして、通貨管理部２１２は、応援者のユーザ管理レコード２２０の通貨残高に、付与した社内通貨額を加算する。更に、通貨管理部２１２は、公募管理レコード２５０の付与総額に、付与した社内通貨額を加算する。

次に、管理サーバ２０の制御部２１は、応援内容の評価処理を実行する（ステップＳ３−５）。具体的には、制御部２１の評価部２１４は、応援完了情報に含まれる応援業務の評価結果を、ユーザ管理レコード２２０の業務評価データ領域に追加記録する。

次に、管理サーバ２０の制御部２１は、人事評価支援処理を実行する（ステップＳ３−６）。具体的には、制御部２１の評価部２１４は、拠出元部署の管理者のユーザ端末１０に、応援者の本来業務評価及び応援業務評価を含めた総合評価情報を出力する。管理者は、この総合評価情報を用いて、応援者の人事評価を行なう。

（制度評価処理）
次に、図７（ａ）を用いて、制度評価処理を説明する。この処理は、応援業務の完了時に、拠出先部署毎に評価対象部署を特定して実行される。

まず、管理サーバ２０の制御部２１は、社内通貨の拠出額の算出処理を実行する（ステップＳ４−１）。具体的には、制御部２１の評価部２１４は、公募情報記憶部２５から、評価対象の公募ＩＤが記録された公募管理レコード２５０の付与総額を取得する。

次に、管理サーバ２０の制御部２１は、超過勤務費用の算出処理を実行する（ステップＳ４−２）。具体的には、制御部２１の評価部２１４は、通貨情報記憶部２４から、評価対象の公募ＩＤが記録された通貨管理レコード２４０の提供額を取得する。

次に、管理サーバ２０の制御部２１は、費用の比較処理を実行する（ステップＳ４−３）。具体的には、制御部２１の評価部２１４は、応援者への付与総額と、繁忙部署への提供額とを比較する。繁忙部署への提供額が、応援者への付与総額よりも高い場合には、社内通貨を利用した社内制度の有効性が高いと判定する。一方、繁忙部署への提供額が、応援者への付与総額以下の場合には、社内通貨を利用した社内制度の有効性が低いと判定する。

次に、管理サーバ２０の制御部２１は、社内通貨制度の調整処理を実行する（ステップＳ４−４）。具体的には、制御部２１の評価部２１４は、社内通貨を利用した社内制度の有効性が高いと判定した場合、社内通貨の利用を促進するように調整する。例えば、繁忙度の評価処理（ステップＳ１−１）に用いる第１基準値を低くする。一方、社内通貨を利用した社内制度の有効性が低いと判定した場合、社内通貨の利用を抑制するように調整する。例えば、繁忙度の評価処理（ステップＳ１−１）に用いる第１基準値を高くする。

（部署評価処理）
次に、図７（ｂ）を用いて、部署評価処理を説明する。この処理は、応援業務の完了時に、拠出元部署毎に評価対象部署を特定して実行される。

まず、管理サーバ２０の制御部２１は、応援者に対する付与額の特定処理を実行する（ステップＳ５−１）。具体的には、制御部２１の評価部２１４は、ユーザ情報記憶部２２を用いて、評価対象の拠出元部署の従業員の中で、応援により社内通貨を取得した応援者を特定する。次に、評価部２１４は、応援者に付与された社内通貨額を合計した社内通貨総額を算出する。

次に、管理サーバ２０の制御部２１は、超過勤務費用の算出処理を実行する（ステップＳ５−２）。具体的には、制御部２１の評価部２１４は、勤怠情報記憶部２３を用いて、応援者の超過勤務時間を特定する。そして、評価部２１４は、超過勤務時間に応じて、超過勤務費用を算出する。

次に、管理サーバ２０の制御部２１は、費用の比較処理を実行する（ステップＳ５−３）。具体的には、制御部２１の評価部２１４は、社内通貨総額と超過勤務費用とを比較する。社内通貨総額が、超過勤務費用よりも高い場合には、拠出元部署において、社内通貨を利用した社内制度の有効性が高いと判定する。一方、超過勤務費用が、社内通貨総額以下の場合には、社内通貨を利用した社内制度の有効性が低いと判定する。

次に、管理サーバ２０の制御部２１は、エントリー者の社内貢献の判定処理を実行する（ステップＳ５−４）。具体的には、制御部２１の評価部２１４は、ユーザ情報記憶部２２を用いて、応援者の評価結果、応援により付与された社内通貨額を取得し、評価結果の統計値、社内通貨額の総額を算出する。

次に、管理サーバ２０の制御部２１は、拠出元部署毎に評価処理を実行する（ステップＳ５−５）。具体的には、制御部２１の評価部２１４は、拠出元部署のユーザ端末１０に、社内制度の有効性の評価結果及び応援者の評価結果の統計値、社内通貨総額を出力する。

以上、本実施形態によれば、以下に示す効果を得ることができる。
（１）本実施形態では、管理サーバ２０の制御部２１は、繁忙部署の特定処理を実行する（ステップＳ１−１）。ここでは、勤怠情報記憶部２３を用いて、各部署の繁忙度を評価する。また、各部署において計画されている新規プロジェクトに想定される超過勤務の統計値を取得する。これにより、応援対象の繁忙部署を特定することができる。

（２）本実施形態では、管理サーバ２０の制御部２１は、拠出する社内通貨額の算出処理（ステップＳ１−２）、繁忙部署に社内通貨の付与処理（ステップＳ１−３）を実行する。これにより、繁忙部署は、社内通貨を用いて、応援者を公募することができる。

（３）本実施形態では、管理サーバ２０の制御部２１は、繁忙部署で公募する業務内容の特定処理を実行する（ステップＳ１−４）。これにより、超過勤務が多い従業員が所属する繁忙部署に対する応援者を公募することができる。

（４）本実施形態では、管理サーバ２０の制御部２１は、超過勤務費用を基準にして社内通貨の設定処理を実行する（ステップＳ１−５）。これにより、超過勤務費用に基づいて設定した社内通貨を、自発的にエントリーした応募者に付与することができる。

（５）本実施形態では、管理サーバ２０の制御部２１は、社内通貨を用いての社内公募の設定処理（ステップＳ１−６）、社内公開処理（ステップＳ１−７）を実行する。これにより、付与される社内通貨額を参照して、エントリーを行なうことができる。

（６）本実施形態では、管理サーバ２０の制御部２１は、エントリー状況の監視処理を実行する（ステップＳ２−２）。エントリー状況において、アンバランスが生じていると判定した場合（ステップＳ２−３において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、エントリー状況に応じて単位提供額の変更処理を実行する（ステップＳ２−５）。これにより、付与される社内通貨に応じて、エントリー数を均一化することができる。

（７）本実施形態では、単位提供額は調整済と判定した場合（ステップＳ２−４において「ＮＯ」の場合）、エントリー過多と判定した場合（ステップＳ２−６において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、エントリー者に対して変更提案処理を実行する（ステップＳ２−７）。これにより、エントリー数が多い公募のエントリー者を分散させることができる。

（８）本実施形態では、エントリー過少と判定した場合（ステップＳ２−６において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、エントリー状況に応じて単位提供額の変更処理を実行する（ステップＳ２−５）。これにより、エントリー数が少ない公募に対するエントリーを促進することができる。

（９）本実施形態では、管理サーバ２０の制御部２１は、応援者の決定処理を実行する（ステップＳ３−２）。ここでは、すべてのエントリー者のユーザ管理レコード２２０を取得し、業務評価が高い順番に公募人数の応援者を特定する。これにより、評価が高いエントリー者を優先することができる。また、エントリー者においても、よりよい応援へのモチベーションとすることができる。

（１０）本実施形態では、管理サーバ２０の制御部２１は、応援時間の特定処理（ステップＳ３−３）、応援者に社内通貨の付与処理（ステップＳ３−４）を実行する。これにより、応援による特典を取得することができる。更に、応援時間を確保するために、拠出元部署での本来業務の効率化のインセンティブとなる。

（１１）本実施形態では、管理サーバ２０の制御部２１は、応援内容の評価処理（ステップＳ３−５）、人事評価支援処理（ステップＳ３−６）を実行する。これにより、社内における応援業務を含めて、従業員の人事評価を行なうことができる。また、業務の効率化により応援を行ない、その結果、付与された社内通貨額により、応援を行なった各従業員を評価することができる。

（１２）本実施形態では、管理サーバ２０の制御部２１は、制度評価処理、部署評価処理を実行する。これにより、社内通貨の有効性や、拠出元部署での効果を把握することができる。

本実施形態は、以下のように変更して実施することができる。本実施形態及び以下の変更例は、技術的に矛盾しない範囲で互いに組み合わせて実施することができる。
・上記実施形態では、管理サーバ２０の制御部２１は、繁忙部署の特定処理を実行する（ステップＳ１−１）。ここで、繁忙部署の特定方法は、勤怠情報やプロジェクト情報を用いる場合に限定されるものではない。例えば、前年度等の繁忙状況に基づいて、繁忙度を評価するようにしてもよい。

・上記実施形態では、管理サーバ２０の制御部２１は、拠出する社内通貨額の算出処理を実行する（ステップＳ１−２）。拠出する社内通貨額は、超過勤務費用に応じて算出できればよく、同額である必要はない。例えば、超過勤務費用に所定割合を乗算することにより割り引いてもよい。

・上記実施形態では、管理サーバ２０の制御部２１は、超過勤務費用を基準にして社内通貨の設定処理を実行する（ステップＳ１−５）。従業員に付与する社内通貨の単位提供額は、超過勤務費用に基づく場合に限定されるものではない。例えば、繁忙部署において公募する業務内容に応じて、単位提供額を変更してもよい。例えば、過去の公募における業務内容毎のエントリー状況を考慮して、単位提供額を決定する。この場合、エントリー数が少ない業務内容については、基準額に対して単位提供額を高く設定し、エントリー数が多い業務内容については、単位提供額を低く設定する。

また、超過勤務費用に単位提供額の許容範囲を設定しておき、オークション形式でエントリー者により単位提供額を入札させるようにしてもよい。この場合、応援者の決定処理（ステップＳ３−２）において、管理サーバ２０の制御部２１は、入札額が低いエントリー者を優先して応援者を決定する。これにより、人件費を抑制するとともに、低額でも応援を希望するエントリー者を優先することができる。

・上記実施形態では、管理サーバ２０の制御部２１は、締め切り処理（ステップＳ３−１）、応援者の決定処理（ステップＳ３−２）を実行する。応援者の決定方法は、これに限定されるものではない。例えば、公募人数分のエントリーが行なわれた場合に、公募を締め切り、応援者を決定するようにしてもよい。

・上記実施形態では、管理サーバ２０の制御部２１は、人事評価支援処理を実行する（ステップＳ３−６）。ここで、制御部２１が、応援者の応募業務の履歴及び評価を取得し、この評価を応援者のスキルとして特定して、ユーザ情報記憶部２２に記録するようにしてもよい。

・上記実施形態では、管理サーバ２０の制御部２１は、社内通貨制度の調整処理を実行する（ステップＳ４−４）。ここでは、第１基準値を変更する。社内通貨制度の調整方法は、これに限定されるものではない。例えば、社内通貨制度の利用状況を、管理者のユーザ端末１０に出力し、調整を促すようにしてもよい。

・上記実施形態では、管理サーバ２０の制御部２１は、拠出元部署毎に評価処理を実行する（ステップＳ５−５）。ここでは、拠出元部署のユーザ端末１０に、社内制度の有効性の評価結果及び応援者の評価結果の統計値を出力する。拠出元部署の評価方法は、これに限定されるものではない。例えば、拠出元部署の超過勤務時間の統計値と応援時間の統計値との比較結果を出力するようにしてもよい。

１０…ユーザ端末、２０…支援サーバ、２１…制御部、２１１…勤怠管理部、２１２…通貨管理部、２１３…募集部、２１４…評価部、２２…ユーザ情報記憶部、２３…勤怠情報記憶部、２４…通貨情報記憶部、２５…公募情報記憶部、２６…エントリー情報記憶部、２７…評価情報記憶部。

Claims (10)

1. ユーザに付与された社内通貨額を記録するユーザ情報記憶部と、
   部署に付与された社内通貨額を記録する通貨情報記憶部と、
   制御部とを備えた業務管理システムであって、
   前記制御部が、
   各部署の繁忙状況を取得し、前記繁忙状況に応じて繁忙部署を特定し、
   前記繁忙部署に対して、前記繁忙状況に応じて付与した社内通貨額を前記通貨情報記憶部に記録し、
   前記通貨情報記憶部に記録された社内通貨額により、前記繁忙部署を応援できるユーザを公募し、
   前記公募により応援したユーザに対して付与する社内通貨額を前記ユーザ情報記憶部に記録することを特徴とする業務管理システム。
2. 各部署に属するユーザの勤怠情報を記録する勤怠情報記憶部を更に備え、
   前記制御部が、前記勤怠情報記憶部に記録された労働時間に応じて、前記繁忙状況を特定することを特徴とする請求項１に記載の業務管理システム。
3. 前記制御部が、前記勤怠情報記憶部に記録された労働時間の中で超過勤務時間を用いて、前記繁忙状況を特定することを特徴とする請求項２に記載の業務管理システム。
4. 前記制御部が、部署の業務において予測される将来負荷を取得し、前記将来負荷に応じて、前記繁忙状況を特定することを特徴とする請求項１〜３の何れか一項に記載の業務管理システム。
5. 前記制御部が、前記公募に対するエントリー状況を特定し、前記エントリー状況により前記応援により付与する社内通貨額を変更することを特徴とする請求項１〜４の何れか一項に記載の業務管理システム。
6. 前記制御部が、
   前記応援後の前記繁忙部署の超過勤務時間を取得し、
   前記応援後の超過勤務時間と前記公募前の超過勤務時間とを比較して、超過勤務時間の削減効果を算出することを特徴とする請求項１〜５の何れか一項に記載の業務管理システム。
7. 前記制御部が、前記応援するユーザを拠出した拠出元部署に属するユーザに付与した社内通貨額の統計値を算出し、前記統計値により前記拠出元部署の評価結果を生成することを特徴とする請求項１〜６の何れか一項に記載の業務管理システム。
8. 前記制御部が、前記繁忙部署において公募する業務内容に応じて、応援によりユーザに付与する社内通貨額を変更することを特徴とする請求項１〜７の何れか一項に記載の業務管理システム。
9. ユーザに付与された社内通貨額を記録するユーザ情報記憶部と、
   部署に付与された社内通貨額を記録する通貨情報記憶部と、
   制御部とを備えた業務管理システムを用いて、業務管理を行なうための方法であって、
   前記制御部が、
   各部署の繁忙状況を取得し、前記繁忙状況に応じて繁忙部署を特定し、
   前記繁忙部署に対して、前記繁忙状況に応じて付与した社内通貨額を前記通貨情報記憶部に記録し、
   前記通貨情報記憶部に記録された社内通貨額により、前記繁忙部署を応援できるユーザを公募し、
   前記公募により応援したユーザに対して付与する社内通貨額を前記ユーザ情報記憶部に記録することを特徴とする業務管理方法。
10. ユーザに付与された社内通貨額を記録するユーザ情報記憶部と、
    部署に付与された社内通貨額を記録する通貨情報記憶部と、
    制御部とを備えた業務管理システムを用いて、業務管理を行なうためのプログラムであって、
    前記制御部を、
    各部署の繁忙状況を取得し、前記繁忙状況に応じて繁忙部署を特定し、
    前記繁忙部署に対して、前記繁忙状況に応じて付与した社内通貨額を前記通貨情報記憶部に記録し、
    前記通貨情報記憶部に記録された社内通貨額により、前記繁忙部署を応援できるユーザを公募し、
    前記公募により応援したユーザに対して付与する社内通貨額を前記ユーザ情報記憶部に記録する手段として機能させることを特徴とする業務管理プログラム。

Images