(57)【要約】【課題】企業の労働生産性向上のためには従業員に対する適切な評価が不可欠である。【解決手段】この評価支援システム１０は、ネットワーク１６によって接続された複数のユーザ端末１２と管理サーバ１４によって構成される。ユーザ端末１２ではファイルへのデータ書込があったときにそのデータ量を検出し、その検出結果を管理サーバ１４へ転送する。管理サーバ１４では、ユーザ別に書込データ量を保持し、その大小や頻度などに基づいてその従業員の成果を評価する。【選択図】  図１
2004164344.tif 000002
【特許請求の範囲】
【請求項１】
業務の成果に着目した人事評価に用いる客観的な材料として、前記成果を示唆するファイルへの書込を複数の端末のそれぞれについて監視する工程と、
前記複数の端末から前記書込を行うユーザ名を取得する工程と、
前記監視によって取得される書込データ量をユーザ別に蓄積する工程と、
管理者による指示に基づいて評価対象とすべき期間を設定する工程と、
前記期間における前記書込データ量の累計を算出する工程と、
複数のユーザ間において前記累計を比較する工程と、
前記累計の大小に基づいてユーザごとに相対評価値を決定する工程と、
を有することを特徴とする評価支援方法。
【請求項２】
業務の成果に着目した人事評価に用いる客観的な材料として、前記成果を示唆するファイルへの書込データ量とその書込を行ったユーザ名を複数の端末から取得する書込監視部と、
前記複数の端末から取得した書込データ量をユーザ別に分類して蓄積するデータ保存部と、
管理者による指示に基づいて評価対象とすべき期間を設定し、その期間における前記書込データ量の累計を算出する集計部と、
複数のユーザ間における前記累計の大小に基づいて相対評価値を決定する評価部と、
を有することを特徴とする評価支援システム。
【請求項３】
前記評価部は、前記書込データ量の累計が基準値を下回るユーザに対し、相対的に成果の乏しいユーザとする値を前記相対評価値に設定することを特徴とする請求項２に記載の評価支援システム。
【請求項４】
前記集計部は、前記データ保存部に蓄積された書込データ量に基づき、データ書込の頻度、書込データ量のばらつき、最新書込日時、書込データ量の変化の傾向をそれぞれユーザ別に出力し、
前記評価部は、前記データ書込の頻度、書込データ量のばらつき、最新書込日時、書込データ量の変化の傾向のうちいずれかを加味して前記相対評価値を決定することを特徴とする請求項２または３に記載の評価支援システム。
【請求項５】
前記評価部は、前記複数のユーザがその業務に応じて分けられたグループを認識し、そのグループ内におけるユーザ間で比較することによって前記相対評価値を決定することを特徴とする請求項２から４のいずれかに記載の評価支援システム。
【請求項６】
前記書込監視部は、前記ファイルへの書込に用いられたアプリケーションソフトウェア名を前記複数の端末から取得し、
前記データ保存部は、前記ユーザ別に前記アプリケーションソフトウェア名と対応づけて前記書込データ量を蓄積し、
前記集計部は、アプリケーションソフトウェア別に前記書込データ量の累計を算出し、
前記評価部は、アプリケーションソフトウェアの種類を加味して前記相対評価値を決定することを特徴とする請求項２から５のいずれかに記載の評価支援システム。
【請求項７】
各ユーザの部署、役職、報酬、勤務状況、家族構成、住所、評価実績、および給与実績のうち少なくともいずれかを要素として含んだ人事データを保持する人事データ格納部と、
管理者によって指定された前記人事データに含まれる要素の組み合わせを検索キーとしたユーザの抽出ルールを定義し、その抽出ルールに基づいて評価対象とすべきユーザを絞り込む検索処理部と、をさらに有し、
前記評価部は、前記絞り込まれたユーザに対する前記相対評価値を決定することを特徴とする請求項２から６のいずれかに記載の評価支援システム。
【請求項８】
前記検索処理部は、前記要素の組み合わせにおいてそれぞれの要素に重み付けを加えて前記抽出ルールを定義することを特徴とする請求項７に記載の評価支援システム。
【請求項９】
前記人事データ格納部は、前記人事データに含まれる要素に関する修正履歴をさらに保持し、
前記検索処理部は、前記人事データに含まれる要素の修正内容に応じた重み付けを加えて前記抽出ルールを定義することを特徴とする請求項８に記載の評価支援システム。
【請求項１０】
前記評価部は、前記相対評価値が基準値を下回った場合または前記相対評価値が一定値以上低下した場合にその旨を管理者へ通知するとともに、改善を求めるメッセージをそのユーザに通知することを特徴とする請求項２から９のいずれかに記載の評価支援システム。
【請求項１１】
業務の成果に着目した人事評価に用いる客観的な材料として、前記成果であるファイルへの書込を複数の端末のそれぞれについて監視する工程と、
前記複数の端末から前記書込を行うユーザ名を取得する工程と、
前記監視によって取得される書込データ量をユーザ別に蓄積する工程と、
管理者による指示に基づいて評価対象とすべき期間を設定する工程と、
前記期間における前記書込データ量の累計を算出する工程と、
複数のユーザ間において前記累計を比較する工程と、
前記累計の大小に基づいてユーザごとに相対評価値を決定する工程と、
をコンピュータに実行させることを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、評価支援方法および評価支援システムに関する。この発明は特に、端末上での検出結果に基づいてサーバが所定の評価を実行する技術に関する。
【０００２】
【従来の技術】
近年、長引く景気低迷の中、企業における労働生産性向上の重要性が年々高まっている。事業規模縮小や人件費削減など「量」の部分でコストダウンすることによって企業再生を図る場合が多いが、その分会社の弱体化を伴うことも多い。この点、従業員がもつ力を最大限に発揮させることによって企業体質を強化して生産力を向上させる方がより前向きな改善策といえる。
【０００３】
一方、ＰＣ（パーソナルコンピュータ）が広く一般に普及し、特にホワイトカラーと呼ばれる職種に関してはＰＣなしに進められる業務の方が少ないほどである。こうした普及を背景に、業務のあらゆる場面でＩＴ技術を用いた合理化が進められてきた。サーバをはじめとするインフラへの負担は増加する一途を辿っているが、その一方でそうしたインフラの障害管理は人事管理と同様に重要性が高い。
【０００４】
ここで、ネットワーク上の電子機器における障害の有無をソフトウェアで監視し、これをサーバが集中管理することによってトラブルを防止する技術が知られている（例えば、非特許文献１参照。）。これもまた事業の効率性を高める上で重要なツールのひとつといえる。
【０００５】
【非特許文献１】
日本ヒューレット・パッカード株式会社製品「ｈｐ  ＯｐｅｎＶｉｅｗ」、［ｏｎｌｉｎｅ］、［平成１４年１１月１日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｊｐｎ．ｈｐ．ｃｏｍ／ｏｐｅｎｖｉｅｗ／＞
【０００６】
【発明が解決しようとする課題】
労働生産性向上を図るにあたって、従業員に対する適切な人事評価が不可欠といえる。製品開発者であればその成果である製品の良否に基づいて評価し、営業部員であれば売上高などの成果に基づいて評価する。このように成果の評価を通じて客観的かつ的確な人事評価をする場合が多い。しかしながら、いわゆる中間管理職などのように、必ずしも製品や成績といった直接的に成果を生むことのない役職や部署も存在し、どのようにして具体的かつ客観的な評価を下すべきかが課題となっている。この点、進捗状況に関する自己申告に基づいて評価する方法もあるが、忙しそうな様子ばかり目立って実際の成果は不明であったり、作業工程の見積が複雑であるために真の負荷が把握しにくい場合もある。逆に、見えない成果があったにもかかわらず、上司が正当に評価しきれない場合もある。企業などの利益団体は、その利益を従業員全体で共有するために富の配分を図る。相対評価のための正確かつ客観的な評価軸を追加することは、正当な富の配分を図る上で重要である。
【０００７】
本発明者は以上の認識に基づき本発明をなしたもので、その目的は、データ処理によって人事評価の効率化を実現する点にある。本発明はさらに、以下のいずれかの目的、または本明細書の記述をとおして理解される他の目的も視野においてなされている。すなわち、コンピュータ処理による労働評価の実現、客観的なデータに基づく人事評価の支援、人事評価にかかる人的または時間的労力の削減、適切な評価を通じた労働生産性向上の支援などである。
【０００８】
【課題を解決するための手段】
本発明のある態様は、評価支援方法に関する。この方法は、業務の成果に着目した人事評価に用いる客観的な材料として、その成果を示唆するファイルへの書込を複数の端末のそれぞれについて監視する工程と、複数の端末から書込を行うユーザ名を取得する工程と、監視によって取得される書込データ量をユーザ別に蓄積する工程と、管理者による指示に基づいて評価対象とすべき期間を設定する工程と、その期間における書込データ量の累計を算出する工程と、複数のユーザ間において累計を比較する工程と、累計の大小に基づいてユーザごとに相対評価値を決定する工程と、を有する。
【０００９】
「成果を示唆するファイル」は、例えばワードプロセッサ、表計算ソフトウェア、オーサリングソフトウェア、ＣＡＤソフトウェアなどの業務用プログラムを用いて企業内で作成される文書である。「評価対象とすべき期間」は、管理者から特に明確な指示がないときに全期間を対象とするよう設定してもよい。「書込データ量」は、例えば新規にファイルを作成してこれを保存する場合におけるその保存データ量であってもよいし、ファイルに対して変更を加える場合におけるその変更箇所のデータ量であってもよい。「ユーザ」は例えば従業員である。
【００１０】
ここでは、「ファイル」の内容に関して成果としての質は考慮しなくてよい。単純に「データ量」という客観的な数値を材料としている。本発明者は、業務におけるパフォーマンスの高い従業員ほどファイルへの書込データ量も一般的に多い事実を経験的に発見した。現実の人事評価は、複雑な要素に基づいて総合的に判断すべきであり、書込データ量の大小だけでは最終的な判断はできない。しかし、少なくとも極端に書込データ量の少ない従業員に対しては相対的に成果の乏しい従業員であると認識または予測することが可能である。
【００１１】
多くの従業員に対して一律に数字で表れる客観的なパラメータは他にほとんどない。また根拠のない曖昧な評価に頼らず、具体的成果に注目して積極的に人事評価することが重要である。こうして、評価する側と評価される側の双方における人的浪費または時間的浪費を防止する。
【００１２】
本発明の別の態様は、評価支援システムに関する。このシステムは、業務の成果に着目した人事評価に用いる客観的な材料として、その成果を示唆するファイルへの書込データ量とその書込を行ったユーザ名を複数の端末から取得する書込監視部と、複数の端末から取得した書込データ量をユーザ別に分類して蓄積するデータ保存部と、管理者による指示に基づいて評価対象とすべき期間を設定し、その期間における書込データ量の累計を算出する集計部と、複数のユーザ間における累計の大小に基づいて相対評価値を決定する評価部と、を有することを特徴とする。
【００１３】
この態様においても、書込データ量という具体的な数値に基づいて客観的な評価値を得る。この評価値は、対象とするユーザのグループや対象とする期間における相対的な評価であってもよい。
【００１４】
本装置は他の形態として、ネットワーク上に設置されたサーバまたはユーザ端末の一方を指す場合と、ネットワークを介して接続されたサーバおよびユーザ端末からなるシステムを指す場合の双方を含み、書込監視部、データ保存部、集計部、および評価部の各機能ブロックは、サーバ側またはユーザ端末側のいずれに設けられてもよい。サーバおよびユーザ端末のそれぞれに設けられてもよいし、その場合の各機能ブロックはそれぞれ同じ名称でもよい。これら各機能は、それぞれプログラムモジュールのかたちで提供され、サーバおよびユーザ端末のいずれかまたはそれぞれにて実行されてもよいし、実行にあたりサーバからユーザ端末へダウンロードされてもよい。
【００１５】
なお、以上の構成要素の任意の組合せや、本発明の構成要素や表現を方法、装置、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体、データ構造などの間で相互に置換したものもまた、本発明の態様として有効である。
【００１６】
【発明の実施の形態】
本実施形態においては、アプリケーションで作成される「ファイル」を業務における一つの成果と位置づける。その上で、ファイルへのデータ書込を監視し、そのデータ量を検出すれば各従業員のパフォーマンスを知ることができる。書込データ量に基づく厳密な人事評価は難しいとしても、パフォーマンスの高い従業員は相対的に書込データ量も多く、逆にパフォーマンスの低い従業員は書込データ量も少ないことが経験的な事実である。少なくとも他者より極端にアウトプットの少ない従業員は何も成果を生み出していないことは明白である。
【００１７】
上記の指標による評価の精度を高めるために、単純な書込データ量だけでなく、書込頻度や書込間隔などの情報も加味する。さらに、業務環境に関するあらゆる要素を評価の上で加味する。このように本システムは、客観的に数値で表れる要素に着目して相対的な評価値を決定し、最終的な人事評価の効率化と評価の精度向上に資する。
【００１８】
図１は、実施の形態に係る評価支援システムの基本的な構成を示す。評価支援システム１０は、ネットワーク１６を介して接続される複数のユーザ端末１２、および管理サーバ１４により構成される。管理サーバ１４は、ファイルサーバを含む構成であってもよいし、ユーザ端末１２は、パーソナルコンピュータまたはファイルサーバと、これらにインストールされたクライアントソフトウェアを含む構成であってもよい。
【００１９】
管理サーバ１４およびユーザ端末１２のそれぞれは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子で実現でき、ソフトウェア的にはデータ送受信機能やデータ管理機能のあるプログラムなどによって実現されるが、以下説明する図２および図３ではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できる。
【００２０】
図２は、ユーザ端末の構成を示す機能ブロック図である。ユーザ端末１２は、主にユーザプロセス処理部２０とシステム処理部４０とファイル格納部５８を備える。ファイル格納部５８は、例えばハードディスクなどの補助記憶装置によって実現される。システム処理部４０は、例えばＯＳ（オペレーションシステム）によって実現される。ユーザプロセス処理部２０は、例えばＯＳ上で実行されるアプリケーションソフトウェア（以下、「アプリケーション」という）によって実現される。
【００２１】
ユーザプロセス処理部２０は、従業者であるユーザによる成果物として作成されるファイルへのデータ書込を監視する書込監視部２２と、アプリケーションによって実現されるべき各種処理を、システム処理部４０との連携によって実行するアプリケーション実行部３０を有する。書込監視部２２は、書込検出部２４、書込量管理部２６、および転送処理部２８を含む。
【００２２】
書込検出部２４は、ファイル格納部５８へのデータ書込を検出するとともに、そのデータ書込が、指定された特定のアプリケーションによるファイルへのデータ書込であるか否かを検出する。主なアプリケーションは、例えばワードプロセッサなど、業務において頻繁に利用されるプログラムである。一つのアプリケーションは、システム処理部４０において一つのプロセスとして扱われ、他のプロセスと区別するためのプロセス名が付与される。書込検出部２４は、予め指定された特定のアプリケーションをプロセス名によって識別する。プロセス名は、例えば「ｘｙｚｗｏｒｄ．ｅｘｅ」のようなアプリケーションのファイル名であってもよい。正確なプロセス名を取得できるかどうかは現実にはＯＳの仕様に依存するが、ＯＳの機能を介さずにプロセス名を取得してもよい。例えば、保存されたファイル名の末尾に付加される拡張子をもとにそのファイル作成に利用されたアプリケーションを推測し、そのアプリケーション名をプロセス名として扱ってもよい。
【００２３】
書込量管理部２６は、特定のアプリケーションによるデータ書込が検出されたときにその書込データ量を検出し、これを蓄積する。蓄積する内容は、例えば、書込データ量、最新書込日時、アプリケーションのプロセス名、書込回数などである。転送処理部２８は、蓄積した書込データ量などの情報をユーザ名とともに管理サーバ１４へ転送する。転送するタイミングは、ユーザ端末１２全体に対する終了指示をトリガーとするタイミングであってもよい。
【００２４】
書込監視部２２は、独立した一つのアプリケーションの形で実現してもよい。その場合、ユーザ端末１２の起動と同時に起動し、ユーザ端末１２の終了とともに終了する常駐ソフトウェアの形で実現してもよい。
【００２５】
アプリケーション実行部３０は、ユーザとの間でデータ入出力を処理するユーザインタフェイス３２と、ユーザの指示に基づいてファイルの作成を処理するファイル作成部３４と、ユーザが作成したファイルをファイル格納部５８へ保存する処理をなす保存処理部３６と、を含む。ファイル内容に変更があった場合、保存処理部３６はファイルを上書き保存する。アプリケーション実行部３０は、ワードプロセッサなどの独立したアプリケーションの形で実現してもよい。
【００２６】
システム処理部４０は、コア処理部４２と入出力管理部５０を含む。コア処理部４２は、アプリケーション実行部３０によって実行中のアプリケーションをプロセスとして扱う。プロセス管理部４４は、各プロセスを識別するためプロセス名を管理する。コア処理部４２は、プロセスの実行スケジュールやプロセスへのメモリ割当を管理するカーネルの形で実現してもよい。
【００２７】
イベント処理部４６は、各プロセスからシステム処理部４０に対して発せられたイベント、例えばデータ書込命令やデータ読出命令などの制御命令を実行する。入出力管理部５０は、特定のハードウェアの動作を制御するためのデバイス制御部５２、ファイルシステム制御部５４、およびネットワーク制御部５６を含む。デバイス制御部５２は、マウスやキーボードなどの入力デバイスにおける入力データの検出動作を制御する。ファイルシステム制御部５４は、ユーザ端末１２が内蔵する補助記憶装置などの記録媒体におけるデータ読出動作または書込動作を制御する。ネットワーク制御部５６は、ネットワーク１６経由でのデータ送受信動作を制御する。
【００２８】
図３は、管理サーバの構成を示す機能ブロック図である。この管理サーバ１４の主なユーザは評価支援システム１０全体の管理者、または各従業員の書込データ量の監視を担当する管理者を想定する。管理サーバ１４は、書込監視部６１、データ保存部６２、集計部６８、評価部７４、人事データ管理部８４、検索処理部９０、入出力部９６、および通信部６０を有する。各部は、通信部６０を介して各種データを送受信する。
【００２９】
書込監視部６１は、書込データ量、ユーザ名、最新書込日時、書込回数、プロセス名などの情報を複数のユーザ端末１２からネットワーク１６経由で取得し、データ保存部６２へ送る。
【００３０】
データ保存部６２は、書込監視部６１から受け取った情報をユーザ別に分類する分類処理部６４と、その分類にしたがって書込データ量をプロセス名などの情報と対応づけて蓄積するデータ量格納部６６と、を含む。
【００３１】
集計部６８は、管理者の指示に基づいて評価対象とすべき期間を設定する期間設定部７０と、その期間における書込データ量の累計を算出する累計算出部７２と、を含む。例えば、管理者は過去１週間、過去１ヶ月間、過去１年間、といった単位で期間を設定する。管理者の指示は、後述する入出力部９６から受け取る。書込データ量の累計は、そのデータ量を具体的な数値で示す絶対量であってもよいし、大中小などの概算値や等級で表す相対量であってもよい。
【００３２】
累計算出部７２は、データ量格納部６６に蓄積された書込データ量と書込日時に基づき、データ書込の頻度、書込データ量のばらつき、書込データ量の変化の傾向をそれぞれユーザ名別に算出する。累計算出部７２は、プロセス別に書込データ量の累計を算出してもよい。
【００３３】
評価部７４は、評価対象とする従業員について集計部６８から累計を抽出する抽出部７８と、複数の従業員間における累計の大小に基づいて相対評価値を決定する決定部８０と、その相対評価値を基準に複数の従業員に関する情報をソートするソート処理部７６と、相対評価値に基づくメッセージを従業員または管理者に通知する通知部８２と、を有する。
【００３４】
抽出部７８は、複数の従業員がその業務に応じて分けられたグループを認識し、特定のグループ内における従業員だけを評価対象として抽出してもよい。例えば、部署、役職、勤務地域などに応じてグループ分けしてもよい。この場合、決定部８０は、特定のグループ内における従業員間の比較によって相対評価値を決定する。例えば、従業員全体では評価が低い場合であっても、特定のグループ内では相対的に評価が高くなる場合もある。すなわち、部署や地域によって書込データ量に絶対的な差が存在する場合もあり、そうした差をグループ別で相対評価することによって吸収する。
【００３５】
決定部８０は、書込データ量の累計が基準値を下回るユーザに対し、相対的に成果の乏しい従業員とする旨の値を相対評価値に設定する。書込データ量の差だけで絶対的な人事評価をするのは難しいが、少なくとも成果の乏しい従業員は書込データ量の面でも他の従業員より少ないと推定できる。したがって、極端に書込データ量が少ない従業員がいればその事実をもって成果が乏しい蓋然性が高いと判断できる。
【００３６】
決定部８０は、プロセスの種類を加味して相対評価値を決定してもよい。例えば、電子メールによる書込量よりもワードプロセッサによる書込量を重視するなどの重み付け設定によってプロセスごとの評価値への影響度を調整してもよい。こうした設定を部署ごとに定めてもよい。
【００３７】
通知部８２は、相対評価値が基準値を下回った場合または相対評価値が一定値以上低下した場合にその旨を管理者へ通知するとともに、改善を求めるメッセージをその従業員に通知する。ここでいう「基準値」は、「評価値が５０００未満」のような閾値であってもよいし、「評価値が１０００低下」のように変動分を示す値であってもよい。「評価値が下位１０％以内」のように相対的な基準を示す値であってもよい。
【００３８】
管理者への通知内容は、１日、１週間、１ヶ月間、１年間などの期間を単位にした従業員ごとの集計レポートであってもよいし、例えば「評価値が５０００近くまで低下してきている従業員」のリストであってもよい。従業員への通知内容は、評価値の低下が続いている従業員を激励する内容であったり、逆に評価値の向上が続いている従業員を褒める内容であってもよい。通知を発生させる条件は従業員ごと、または従業員のグループごとに変えてもよい。
【００３９】
人事データ管理部８４は、各従業員の部署、役職、報酬、勤務状況、家族構成、住所、評価実績、および給与実績のうち少なくともいずれかを要素として含んだ人事データを保持する人事データ格納部８６と、管理者の指示に基づいてこの人事データに含まれる要素へ修正を加える修正処理部８８と、を含む。その修正履歴は人事データ格納部８６に保持される。
【００４０】
検索処理部９０は、管理者によって指定された人事データに含まれる要素の組み合わせを検索キーとした従業員の抽出ルールを定義する定義設定部９２と、その抽出ルールに基づいて評価対象とすべき従業員を絞り込む絞込処理部９４と、を含む。例えば、「部署が営業部である従業員」「家族構成が３人以上である従業員」といった抽出条件をルールに定義してもよい。
【００４１】
定義設定部９２は、人事データに含まれる各要素の組み合わせにおいてそれぞれの要素に重み付けを加えて抽出ルールを定義してもよい。例えば、役職の違いよりも部署の違いの方が書込データ量に対する影響が大きい場合、「役職」に関する重み付けを小さくして「部署」に関する重み付けを大きくすればよい。このように条件に軽重をつけることによって抽出結果に優先順位を与えることができる。
【００４２】
定義設定部９２は、人事データに含まれる要素の修正内容に応じた重み付けを加えて抽出ルールを定義してもよい。例えば、「家族構成」や「役職」に関する修正に着目し、「家族構成人数が増えた従業員」という条件や「役職が昇格した従業員」という条件に重み付けを大きくするなどである。
【００４３】
入出力部９６は、管理者から指示を取得する指示受付部９８と、評価部７４による評価の結果をモニタ画面に表示させる表示部９９と、を含む。
【００４４】
図４は、ユーザ端末において書込監視部が検出、管理、および転送する情報のテーブルを示す。ローカル管理テーブル１００には、ユーザ端末１２の稼働開始から終了までの検出結果が累積的に記録される。通常は、始業時刻から終業時刻まで１日分の結果が記録される。
【００４５】
ユーザ名欄１０２にはそのユーザ端末１２のユーザ名が格納され、プロセス名欄１０４にはその日に使用したあるいは使用中のアプリケーション名を示すプロセス名が格納される。書込データ量欄１０８には、その日のそのプロセスによる書込データ量の累計が格納され、最新書込日付欄１１０には最後にそのプロセスによる書込のあった日時が格納される。書込回数欄１１２には、その日のそのプロセスによる書込回数が格納される。このローカル管理テーブル１００の情報が転送処理部２８によって管理サーバ１４へ転送される。
【００４６】
図５は、管理サーバにおいて管理するユーザ名別の書込データ量が格納されたテーブルを示す。サーバ管理テーブル１２０は、書込監視部６１が複数のユーザ端末１２から取得し、データ保存部６２が保存する情報のテーブルである。
【００４７】
ユーザ名欄１２２にはユーザ名が格納され、プロセス名欄１２４にはその従業員がその日使用したアプリケーションのプロセス名が格納される。最新書込日付欄１２６にはユーザ名別でプロセスごとの最新書込日時が格納される。書込データ量欄１２８にはその日のプロセスごとの書込データ量の累計がユーザ名別に格納される。書込回数欄１３０には、その日のプロセスごとの書込回数がユーザ名別に格納される。
【００４８】
図６は、相対評価値の順に人事データおよび検出結果などの各情報をソートした結果を示す。この出力テーブル１４０は表示部９９によって画面表示される。従業員ＩＤ欄１４２、ユーザ名欄１４４、部署欄１４６、役職欄１４８、地域欄１５０、および家族構成欄１５２には、各従業員の識別番号、ユーザ名、部署名、役職名、所属地域、家族構成人数がそれぞれ格納される。
【００４９】
書込データ量欄１５４には、各従業員の１日あたりの平均書込データ量（Ａ）が格納される。書込頻度欄１５６には、各従業員の１日あたりの平均書込回数（Ｂ）が格納される。最新書込日時欄１５８には、各従業員ごとの最新書込日時（Ｃ）が格納される。評価値欄１６０には、各従業員の相対評価値（Ｄ）が格納される。ここでは、Ｄ＝（Ａ×１）＋（Ｂ×１０）＋（Ｃ×０．１）で相対評価値を求めているが、Ａ，Ｂ，Ｃに与える重み付けの大きさを管理者が調整すれば得られる評価値も変動する。どのような重み付けを加えるかは管理者の自由であり、職種など個別の状況に応じて判断すればよい。
【００５０】
出力テーブル１４０においては、評価値欄１６０に格納された相対評価値を基準に各従業員の情報がソートされている。この相対評価値が例えば５０００未満であった従業員は、他の従業員と比べて極端に書込データ量や書込頻度が少なく、また最後に書込があってからだいぶ時間が経過していることも分かる。このように、データ書込という客観的な事実に基づいて明らかにパフォーマンスの低い従業員を抽出できる。また、データ書込に関して単にデータ量だけに着目するのではなく、頻度や時間間隔といった複数の角度からバランスよく分析できるので、結果の客観性を高めやすい。
【００５１】
以上の構成に基づく処理の過程を以下説明する。
図７は、ユーザ端末によって書込を監視して書込データ量を管理サーバへ転送するまでの処理過程を示すフローチャートである。以下のフローは主にユーザ端末１２で稼働するクライアントソフトウェアによって実現される。ユーザ端末１２が起動する始業時に書込監視部２２による監視を開始し（Ｓ１０）、書込検出部２４が書込イベントを検出したときに（Ｓ１２Ｙ）、その書込イベントを発したプロセスのプロセス名を検出する（Ｓ１４）。プロセスが目的のアプリケーションに該当したとき（Ｓ１６Ｙ）、そのプロセスによる書込データ量を蓄積する（Ｓ１８）。予め設定された転送タイミングに達するまでＳ１２〜Ｓ１８の処理を繰り返し（Ｓ２０Ｎ）、転送タイミングが訪れたとき（Ｓ２０Ｙ）、蓄積していた書込データ量や最新書込日時などの情報をユーザ名とともに管理サーバ１４へ転送する（Ｓ２２）。以上の監視を終了するまでＳ１２〜Ｓ２２の処理を繰り返す（Ｓ２６Ｎ）。例えば、ユーザ端末１２をオフにするとき監視も終了する（Ｓ２６Ｙ）。
【００５２】
図８は、管理サーバによって評価値を決定する過程を示すフローチャートである。以下のフローは主に管理サーバ１４で稼働するサーバソフトウェアによって実現される。まず、管理者は必要に応じて評価対象期間を指定し（Ｓ２６）、また評価対象としていずれかのグループを指定する（Ｓ２８）。これら指定された期間における指定されたグループについてユーザ名別の書込データ量を集計部６８が集計し（Ｓ３０）、その集計に基づいて評価部７４が相対評価値を決定する（Ｓ３２）。決定した相対評価値を基準として各従業員の情報をソートし（Ｓ３４）、得られた図６のテーブルを出力する（Ｓ３６）。
【００５３】
ここで、さらに分析をすすめるために、評価対象とする従業員を様々な条件によって絞り込むことを本発明者は考えた。出力された評価結果を見た管理者が結果をさらに別の角度から判断すべきと考えたとき（Ｓ３８Ｙ）、ルール定義に基づく絞り込みを実行する（Ｓ４０）。出力された評価結果に応じた通知、例えば相対的に成果の乏しいと判断される従業員に対して改善を求める通知を送信する（Ｓ４２）。通知の対象となる従業員は、「評価値が５０００以下」のような絶対的な基準、または「評価値が下位１０％」のような相対的な基準に基づいて絞り込まれる。また、そうした通知がなされた旨や管理上の報告を管理者に通知してもよい。
【００５４】
図９は、ルール定義に基づく絞り込みのサブルーチンを示すフローチャートである。Ｓ４０において、管理者は絞り込むためのルールを定義する（Ｓ５０）。ルールの定義において、評価の対象期間の指定やグループの設定を見直してもよい。そのルールに基づいて評価対象となる従業員を絞り込み、再び相対評価値を決定する（Ｓ５２）。この相対評価値を基準として各従業員の情報をソートし（Ｓ５３）、得られた図６のテーブルを再度出力する（Ｓ５４）。その再評価の結果を見た管理者は、定義済みのルールに見直しが必要であると判断すれば（Ｓ５５Ｙ）、そのルールを調整し（Ｓ５６）、再び評価対象の絞り込みと再評価を実行する（Ｓ５２）。こうして管理者は納得のいく結果が得られるまでルール定義、絞り込み、評価の過程を反復する。
【００５５】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、その各構成要素や各処理プロセスの組合せにいろいろな変形が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下、変形例を挙げる。
【００５６】
実施の形態においては、ファイルへの書込データ量に基づいて評価値を決定していたが、変形例においては、読出データ量に基づいて評価値を決定してもよい。また、書込データ量および読出データ量の双方に基づいて評価値を決定してもよい。
【００５７】
実施の形態においては、ユーザ端末１２に含まれるファイル格納部５８にファイルを保存し、データを書き込んでいた。変形例においては、ファイルを管理サーバ１４上の補助記憶装置に保存し、データを書き込んでもよい。その場合、データ書込は上記実施形態と同様にユーザ端末１２の書込監視部２２が監視してもよいし、管理サーバ１４の書込監視部６１が監視してもよい。
【００５８】
実施の形態においては、ユーザ端末１２の転送処理部２８が管理サーバ１４へユーザ名を転送し、これを管理サーバ１４が管理する構成としている。変形例における管理サーバ１４は別の手法によりユーザ名を取得してもよい。例えば、保存されたファイル内に記録されるそのファイルの作成者情報からユーザ名を抽出してもよい。例えば、ユーザ端末１２のＩＰアドレスを検出してこれをユーザ名として扱ってもよいし、あらかじめＩＰアドレスを各従業員に固定で割り当てている場合は、ユーザ名とＩＰアドレスの対応テーブルを参照して、ＩＰアドレスをユーザ名に変換してもよい。例えば、各従業員が管理サーバ１４へファイルを保存する場合に、その保存先として従業員ごとに個別の保存フォルダが設定されていればそのフォルダ名からユーザ名を割り出してもよい。
【００５９】
実施の形態においては、終業時にユーザ端末１２から管理サーバ１４へ書込データ量を転送する構成としていた。すなわち、転送するタイミングは１日に１回であり、書込データ量は１日分の蓄積を基本としていた。変形例においては、転送処理部２８が例えば１週間に１度のタイミングで転送してもよいし、１日に数回、所定の時間間隔で転送してもよい。転送する周期、すなわち書込データ量を蓄積する期間は、管理者による設定が可能であってもよい。予め定められた転送タイミングにおいて転送が例外的に失敗となった場合、転送処理部２８は、次に転送が可能となるタイミング、例えば翌日の始業時に転送し直してもよい。
【００６０】
【発明の効果】
本発明によれば、客観的な情報に基づいて人事評価を支援することができる。
【図面の簡単な説明】
【図１】実施の形態に係る評価支援システムの基本的な構成を示す図である。
【図２】実施の形態に係るユーザ端末の構成を示す機能ブロック図である。
【図３】実施の形態に係る管理サーバの構成を示す機能ブロック図である。
【図４】ユーザ端末において書込監視部が検出、管理、および転送する情報のテーブルを示す図である。
【図５】管理サーバにおいて管理するユーザ別の書込データ量が格納されたテーブルを示す図である。
【図６】相対評価値の順に人事データおよび検出結果などの各情報をソートした結果を示す図である。
【図７】ユーザ端末によって書込を監視して書込データ量を管理サーバへ保存するまでの処理過程を示すフローチャートである。
【図８】管理サーバによって評価値を決定する過程を示すフローチャートである。
【図９】ルール定義に基づく絞り込みのサブルーチンを示すフローチャートである。
【符号の説明】
１０  評価支援システム、  １２  ユーザ端末、  １４  管理サーバ、  ２２書込監視部、  ３０  アプリケーション実行部、  ６２  データ保存部、  ６８  集計部、  ７４  評価部、  ８６  人事データ格納部、  ９０  検索処理部。
【図１】
2004164344.tif 000003
【図２】
2004164344.tif 000004
【図３】
2004164344.tif 000005
【図４】
2004164344.tif 000006
【図５】
2004164344.tif 000007
【図６】
2004164344.tif 000008
【図７】
2004164344.tif 000009
【図８】
2004164344.tif 000010
【図９】
2004164344.tif 000011