| 項目 | 概略説明 | |
|---|---|---|
| マスタ登録 | 個人マスタ登録 |
社員コード、氏名、入社日、退職日、配属事業所等の主要項目は人事システム等から取り込めますが、それ以外に「勤怠管理システム」特有の必要な項目があります。 まず、月給者か時給者かそれ以外かの区分で、月給者の場合は時間外有無や遅早管理の有無、交替制勤務の有無、基本勤務シフトといった細目を持たせており、時給者の場合は予定管理の有無、勤務可能曜日等、基本勤務シフトなどの細目を持たせていました。 「それ以外」というのは、在籍情報の登録だけでこのシステムでは勤怠処理を行なわないという区分です。 細目を含む多種な区分情報は事前に「勤務区分マスタ」で管理することにして、個人マスタからは「勤務区分コード」のみで指定する方が一見便利なのですが、 システムの導入時に社内の全ての勤務区分情報を事前に収集できなかったり、後から例外が発生するたびに「勤務区分マスタ」を追加する運用では、 「勤務区分コード」の採番自体も系統立った運用ができにくいことから、個人マスタに直接持たせるような仕組みとしていました。 |
| 勤務シフトマスタ登録 |
時間外や遅早の算出は勤務予定と実績の「差」を算出することになります。 ここで必要となる勤務予定を「勤務シフト」として短いコードを付けて登録しておきます。 月給者のみ、日勤のみの会社では基準となる「勤務シフト」は１つだけにできると思われるかもしれませんが、 育児休業明けの復職者が短時間勤務であったり、フルタイムで勤務できない障害者が在籍したりで、時給者の処理がないとしても複数の「勤務シフト」を登録することになるようです。 時給者がいる場合や交替制勤務、さらには事業所ごとに違うことも多いのでこのマスタの登録件数は数百種類になることもあります。 勤務シフトマスタの内容としては勤務シフトコード、名称、勤務時間帯、勤務時間、休憩時間の他、24時間スパンでの時間帯ごとの時刻・時間数・区分が登録できるようにします。この「区分」は勤務時間帯なのか休憩時間帯なのか、また深夜時間帯なのか等を判断するものです。勤務時間帯の区分ではフレックス制の対応するためコアタイムかフレキシブルタイムかの区別も行ないます。 「24時間スパン」とするのは勤務予定内だけではなく時間外勤務の場合でも休憩時間帯などの判断をするためです。 さらに、半休境界時刻、日付変更時刻なども登録できるようにします。半休境界時刻は半休取得時の遅刻等の判定に用い、日付変更時刻は「夜勤」「徹夜」などでどこまでを当日の出退時刻として取り込むかの判断に用いていました。 |
|
| その他のマスタ登録 |
その他のマスタとしては「会社情報」「年間カレンダー」「勤怠科目」「タイムレコーダ情報」などを登録します。 「会社情報」では会社名、勤怠締め日、月次時間数単位、各種パラメータなどを登録するものです。 「年間カレンダー」は会社、事業所ごとの年間の休日を登録するものです。 「勤怠科目」は休暇、欠勤、長欠、遅早外などの科目名やその種別・区分を登録するものです。 「タイムレコーダ情報」はタイムレコーダ単位のマスタ情報で、現在もこの種の製品はあるのですが、データ収集の方式が全く異なるので後述します。 |
|
| 月初準備処理 | 勤務予定の登録 |
勤務予定は個人毎・日毎に登録がないと時間外や遅早の算出が行なえません。 ですが、これを毎月１人ずつ登録するというのは膨大な作業になってしまうので、前出のマスタ情報を利用してできるだけ自動化・合理化できるように配慮していました。 月給者で固定勤務の場合は、会社・事業所のカレンダー通りで月間の勤務予定を自動登録します。 交替制勤務の場合も一旦はデフォルトの勤務予定を自動登録した上で、変更箇所を画面登録してもらうという方法です。 時給者については個人毎・日毎の予定登録が必要な上、月中に入ってからの予定変更が発生するため、運用利便性上の対応として個人マスタ側で「予定管理の有無」を指定できるようにしており、 予定管理を使わない場合は遅早の算出はなく、実績時間数のみ集計されるようにしていました。 |
| 日次 ・ 随時処理 |
出退時刻情報の収集 |
当時のシステム環境は次項で説明するので割愛しますが「IDカード式タイムレコーダ」からの一括データ収集を行なう仕組みです。
当時はまだ「ICカード」ではなく、「磁気カード」です。 この「IDカード式タイムレコーダ」は通常は各従業員が「IDカード」を通した時のカードのIDコード・日付時刻・ファンクションが累積されており、これを「勤怠管理システム」から一括で取り込む方法でした。 ファンクションというのは「IDカード式タイムレコーダ」のフロントパネルにある「出社」「退社」ボタンに対応した数値です。 「出社」「退社」ボタンは毎回押す運用ではなく、液晶部分に表示されている「出社」「退社」のモードがこれから打刻を行なうモードと違う場合のみ押すものです。 「出社」「退社」以外に「出張」「外出」などを設定ができるタイムレコーダもあります。 各従業員が「IDカード」を通すオペレーションのことをシステムでは「打刻」と呼んでいました。 「出退時刻情報の収集」の処理自体は担当者がボタンを押して行なわれる一括処理です。 |
| 打刻データの更新 |
出退時刻情報をできるだけ正しく個人毎・日付(この日付は「勤怠日」と呼んでいました)毎の勤怠情報として自動更新するというのが結構重要な処理です。 「出退時刻情報の収集」の段階でこの更新まで行なうのは実際には「無理」があります。 まず、打刻データ自体の有効・無効の判定があります。 ・同一人の3分以内の打刻は「やり直し」と判断して、後ろの打刻のみ有効とする(「3分ルール」と命名) ・同一人、同一勤怠日同一ファンクションの打刻は、出社だったら「前」、退社は「後」の打刻のみ有効とする といった判断です。 ところが、大きな工場などでは大人数に対応させるため複数のタイムレコーダが並んで設置されていることがあり、同一人の打刻が１台のタイムレコーダで行なわれるとも限定できませんから、 「やり直し」と判断ですら「出退時刻情報の収集」の段階ではできないことになります。 これらのことから、出退時刻情報は社員コード＋打刻日時キーの「打刻情報テーブル」に累積的に収容させて、次に「打刻情報テーブル」を個人毎、打刻日時順に読み出して 有効・無効の判断を行なった上で実際に集計対象となる「勤怠情報テーブル」に更新させるという方法にしていました。 この方法なら、運用上の「打刻データ更新」の処理タイミングをまたいだ「3分ルール」の判定も行なえるからです。 処理でまず有効と判断された打刻データは、次に打刻日時から「勤怠日」を判断します。 日勤者で「出社」から始まるのであれば何も問題はありませんが、夜勤者や日勤でも徹夜した社員が「出社」打刻を忘れていた場合などにもできるだけ対応しなければならないということがあります。 打刻忘れがなくても、勤務予定が24～25時始まりなどのケースもあって、その社員が前日にあたる23時台に「出社」打刻を登録するなどは正常な運用なので、これらの対応と処理結果に対する説明がつくようにする必要があるため、システム内では重要な処理だと思います。 |
|
| 日次データチェック |
「日次データチェック」は実際の運用は「随時」です。
月初日から処理日前日までの「不正と思われるデータ」をレポートするだけの処理です。
「不正と思われるデータ」とは「欠勤無届」の他、「打刻不揃」「遅刻・早退あり」などをまとめてレポートするものです。 運用サイクルなどは作業を行なう人事担当者に依存することになりますが「月末にまとめて」だと「勤怠管理システム」を利用するメリットが薄れてしまいます。 というのは、例えば「紙」のタイムカードを月末に集めてきてチェックや集計作業を行なうレベルと同じになってしまうからです。 日次や週次での細かいサイクルでチェック、修正登録を済ませることで、月次での作業ボリュームを軽減するのが「勤怠管理システム」の大きなメリットのひとつに当たります。 |
|
| 休暇情報の登録 |
個人の出勤日に対する勤怠のデフォルトは「欠勤無届」としていました。
すなわち、出退時刻情報が入ってこない場合はこの「欠勤無届」のまま月次集計されます。 ここに承認された「休暇申請書」を登録するのですが、ネットワークが完備していない当時はこの部分のシステム化はできておらず、 人事担当者が承認された「休暇申請書」を画面登録するという方法でした。 「打刻忘れ」や「勤務予定誤り」に対する修正申請の登録も同様に行ないます。 |
|
| 月次処理 | 月次集計処理 |
名前は「月次集計処理」なのですが、処理内容としてはまず日次集計として日別の実働時間、時間外時間、遅刻、早退等を算出してから、
月次集計として個人別・月別に各科目ごとの縦合計を集計して「月次集計テーブル」へ更新を行なうというものでした。 このシステムの作成当時は「手作業からの移行」という段階でしたので、日別の実働時間でも「30分単位端数切り捨て」などが行なわれていてこれに対応していましたが、 現在では電算化はあたり前なので日別の計算は「分単位」、月次のまるめは許可されますが切り捨てはダメで四捨五入ということです。 これに反すると労基署から指摘を受けます。 時間外時間についても、勤務予定の外側を単に「時間外時間」、深夜時間帯に掛かる部分を「深夜時間」として算出する程度だったと記憶していますが、 社内系事案として近年でもこれらに携わっており、社労士からの意見を受けたりしていました。 現在では所定労働時間を8時間ではなく、7.5時間などとする企業が増えており、 こうなると、7.5時間から8時間の間は会社の所定労働時間は超えているけれど、 法定労働時間以内であるという「グレーゾーン」が発生します。 この処置や、8時間／日以外に40時間／週を超えた分も時間外時間として算出します。 また、週１回の法定休日を定めなければならず、その法定休日の労働時間は法定休日勤務時間として別枠で算出する必要があります。 さらに、月間の法定時間外時間が60時間を超えた分は別枠で集計する必要があります。 上場企業ではこの部分は手当てとして支払わなければならず、中小企業も2023年から手当てとする必要が発生するはずです。 |
| 月次集計レポート |
このシステムの作成当時はあまり多様な集計レポートは求められていませんでした。
但し、例えば「タイムカード」が撤廃されてこのシステムに移行すると、視覚的な原票がなくなってしまうので、
プルーフとして個人別の「月報」を用意しておりました。 現在であれば、法的に時間外時間の上限などが定められているので、個人別の年間各月の時間数を一覧化したものは最低でも必要になります。 |
|
| 月次確定登録 |
現在処理月を「確定」として、処理月を翌月に繰り越す処理です。 この処理を行なうまでは現在処理月内の修正や「月次集計処理」はやり直すことができます。 |
|
| 項目 | 説明 |
|---|---|
| コンピュータ |
民生パソコンではNECの「PC-9801」が「MS-DOS」で動いていた時代ですが、
企業向けにはコンピュータメーカー各社が独自OSの機器を「オフィスコンピュータ」「オフィスプロセッサ」などと呼んで供給していました。 上記の「勤怠管理システム」はNECの「N5200」という機種、「PTOS」というOSで動くものでした。 CPUはインテルの80286、メモリやディスクはMB(メガバイト)単位クラス、スクリーンは80字×25行のキャラクタディスプレィというスペックでしたが、 「PTOS」が優れていたのは、OSレベルで文字コード、日本語変換やファイル形式が統一されていて、索引順編成ファイル等が利用できたこと、 画面切替えによる最大4タスクが見かけ同時実行できることが挙げられます。 開発言語は「COBOL85」で画面節が記述できるので会話型処理も作成できました。 上記の「勤怠管理システム」は、通信系プログラムも含めて全てこの「COBOL85」で開発しました。 NECは当時、PTOSなどのオフィスプロセッサ用に「LANシリーズ」というプロダクトを供給しており、 「LANWORD」「LANPLAN」「LANFILE」などがありました。 古い話ではありますが、「Microsoft Office」の一部と似たようなラインナップです。 確か「カタログ」という名前だったと記憶していますが「マクロの記録」と同じような機能も搭載されていました。 「Microsoft Excel」はこの「LANPLAN」「LANFILE」を合わせたものと位置づけられたので、 私個人としては「Microsoft Excel」への移行が比較的楽だったと思います。 「PTOS」は2000年過ぎまで供給されていて、 その頃は当然Windows全盛の時代になるのですが、確か「PC-PTOS」という名前になって「PC-9801」で動くようになっていたと記憶しています。 当然、キーボードは「N5200」配列のもので、ディスク上にWindowsと領域を分けて切り替えられるものでした。 |
| タイムレコーダ |
「IDカード式タイムレコーダ」については、S社とA社から通信プロトコルの公開を受けており、
ACK／NAK応答を含むロジックを「COBOL85」で作成していました。 当然、スレッド動作はできないので送信／受信の切替えが想定通りとして処理するしかなく、 想定外動作はタイムアウトを待って打ち切るというものですが、これらのタイムレコーダは「打刻データ受信」と「受信済データ削除」は別のコマンドでの操作であるため、 受信途中での回線断でデータが消えてしまうことがないためトラブルはほとんどありません。 当時のタイムレコーダとの接続は「COMポート(RS-232C)」なのですが、 複数台接続が可能となる仕様で1台目までを「COMポート(RS-232C)」で接続した先は、 2台目から順にRS-422等に切り替えて接続するようになっており、 通信処理上は接続した2台目以降もそれぞれのアドレスでポーリングを掛けて呼び出せます。 処理上は1台ずつ収集する形です。 通信プログラムの開発・テストはそのままではデータが見えないので「RS-232Cラインモニタ」を使いました。 実際に「COMポート(RS-232C)」上に流れるデータをバイト単位に「文字」として確認できるものです。 現在でもこういった「IDカード式タイムレコーダ」は存在するらしく、 通信接続は「LANポート」になっているらしいです。 Windows版の打刻データ収集プログラムもタイムレコーダのメーカーから供給がある模様でした。 |
| 通信機器 |
複数事業所を持つ企業では、この「勤怠管理システム」を事業所ごとに配置するということはほとんどありませんでした。
導入以前のことを考えると、各事業所の庶務担当者が月末にタイムカードを回収して、本社人事部に送付する運用が普通であり、
後の集計処理は人事部の担当者が行なっているのが現状でしたから、各事業所の庶務担当者が「勤怠管理システム」をマスタするのは
事業所の規模が相当大きくないと一般的ではありません。 そうなると、各事業所や店舗には「IDカード式タイムレコーダ」のみを設置して、人事部の担当者が直接データ収集を行なえるようにするのが合理的です。 このことは「モデム」で解決させていました。 アナログ電話回線でプロバイダ等にダイアルアップ接続するのに利用するような安価な「モデム」です。 本社側、事業所(店舗)それぞれにこの用途での電話回線を用意する必要はありますが、 上記の通信プログラムでは「タイムレコーダ情報」のマスタに電話番号の項目を設けてダイアルアップ接続ができるようにしておりました。 |