管理人のプロフィール

■本当に訪問者が知りたい20の質問

■下のサイトの管理人の皆さんと統一した項目でプロフィールを作っています。
出典元 :個人WEBサイト文化研究所 経由 hardでloxseな日々
Excelサイト管理人のみなさん、回答ページを自サイトに作って、ページ上部による相互リンクしませんか。
訪問者に楽しいコンテンツとなるかもしれません。詳しい説明はExcelサイト連合プロジェクトにて
Excelサイト管理人リンク(同じ形式でプロフィールを掲示しています。)
 ・VBAアクションゲーム?Excelで動かそう!の管理人 近田さんの回答
 ・Nao & Shiho Home Page Excelでお役立ち !!の管理人 ymatsuさんの回答
 ・Office TANAKAの管理人 田中亨さんの回答
 ・ミコの黄色いおうちの管理人 ミコさんの回答
 ・よねさんのWordExcelの小部屋の管理人 よねさんの回答
 ・Excelの玉手箱 アドインコレクションの管理人 足利谷 毅さんの回答
 ・Excel豆知識の管理人 komaさんの回答
 ・GEN MUTO'S HOMEPAGEの管理人 武藤 玄さんの回答
 ・Excel四十八手の管理人 森田表計算さんの回答

1.サイト名とそのアドレス、あなたの希望する呼ばれ方(ハンドルネーム)についてお答えください
Excelでお仕事! https://www.ne.jp/asahi/excel/inoue/ 井上 治(「管理人」とでも。)
2.あなたのサイトがどんなところか、一言でご説明ください
Excelについて広い範囲で説明しようとしているサイトです。 ブログツールではない通常の「ホームページ」で300ページを超える記事を公開しており、トップページにサイトマップを置いているので内容は一目で判ると思います。
特に定型業務用の仕組み(マクロを含む)を持ったExcelワークブックを大勢に配布するような場合の後からのメンテナンス方法などが「売り」です。 一方でグラフなどの「分析系」はどちらかというと不得意であります。
(一言ではなくなりました...)
3.このサイトへのリンク、サイト内各ページへの直リンクについてどうお考えかお答えください
リンクは歓迎いたします。以前は下層ページへの直リンクは変更・廃止することはあり得ますのでご注意下さい。

なお、こちらのサイトのリンクページではリンク先を積極的に増やそうとは考えていません。
これは「サイトを作ったのでリンクして下さい。」的な安易で継続性も疑わしいサイトからの依頼メールが多いことによります。 「相互リンク」などという業界用語は来訪者には関係ないと思います。
例えば「Web素材」などのジャンルのサイトを検索すれば判りますが、リンク情報しか提供しない(独自コンテンツがほとんどない)サイトだらけで それらが多数「相互リンク」している状態なので、何かを探しに行っても失望させられるばかりです。
こんな風にはなりたくないので、私自身がお世話になっているサイトに厳選させていただいています。
4.「サイト上で訪問者にこれだけは絶対にして欲しくない」ということをお答えください
直接営利目的のものへの転用利用はお断わりしております。
(マクロなどの部品的利用はこの限りではありませんが、利用結果について当方では一切の責任は負いません)
5.このサイトを運営していく上であなたが何を一番重視しているかについてお答えください
「コンテンツ」そのものです。掲示板を持たない単一方向発信サイトとして、ある程度のアクセス数が維持できるような内容を維持したいものです。
Excelそのものには大きな変革はなさそうなので、当サイトの方針を変更することはありませんが、ご意見・ご要望、またご質問は歓迎いたします。
6.このサイトの更新頻度についてお答えください
不定期です。
平均して月に1回といったところですが、あくまで管理人の都合によります。
7.1回の更新にかかる時間についてお答えください
これも一定していません。数時間から数日の間です。サンプルの作成に数日かかることもあります。
OfficeWindowsがバージョンアップされた結果、掲示している画面の画像が古くなったりするので、 更新履歴に記載せずに入れ替えているものもあります。
8.現在の訪問者数と、今後希望する訪問者数についてお答えください
最盛期はトップページで3万ビュー弱/月、総ページだと40万ビュー/月くらいでしたが、現在では最盛期の数分の一です。
掲示板などのコミュニケーションツールを持たず、コンテンツだけでやっていますので、サイト立ち上げ前の自分の予想をはるかに上回っていました。 維持することが大事だと思っています。
最近ではスマホ時代になって若い人のパソコンやExcelへの関心が減っていると思われますが、ビジネス用途に絞っているので影響は少ない方なのかも知れません。 「スマホでは仕事はできない」と解ってから勉強されるのか判りませんが、学生さんからの問合せは明らかに減っています。
9.あなたにとって訪問者はどんな存在かお答えください
大切な「お客様(現状では営利的なものは伴いません。)」です。
10.閉鎖の予定についてお答えください
今のところ具体的な予定はありませんが、アクセス数などから見て明らかに利用度が下がってしまうようであれば閉鎖に動くかも知れません。
11.あなたの性別についてお答えください
男です。
12.あなたの生まれた年代、できればズバリ何年に生まれたかお答えください
1956年です。(孫が2人もいるジジイです!)
13.現在のご職業について差し障りない程度にお答えください
中堅SI系の会社で本社の管理部門におりました。現在はフリー(隠居?)です。
やっていたことは導入したパッケージシステム以外で、自社利用の個別業務系システムの設計・開発・運用保守です。
14.出身と現住地について差し障りない程度にお答えください
出身と元の勤務先は神奈川県横浜市、現住地は埼玉県川口市です。(長距離通勤でした)
15.振られたときに得意な話題、分野についてお答えください
シャイで寡黙な方で話は得意はありません。強いて挙げるならExcelVBを除くとパソコン自作と「孫の話」ですか。
16.あなたが一番良く使っているパソコンの性能、接続環境について分かる範囲でお答えください
「自作」です。←リンクをご覧下さい。
17.毎日あなたが閲覧するサイトの数をお答えください
多くありません。平均510カ所でしょうか。
18.Webを閲覧し始めた時期についてお答えください
質問が「古くさい」気がしますが、1997年です。個人メールアドレス取得(有償の)もこの年です。
19.初めてサイトを公開した時期についてお答えください
2003830日です。
20.影響を受けた or 大好き or ここが閉鎖したら落ち込むかも、というサイトがありましたらお答えください
DOBON.NETITInsider.NETHTMLクイックリファレンスとほほのWWW入門
(ちょっとExcelから離れてしましました。)
番外.どういう状況の時、自分はExcel が好きだと実感しますか?
お礼メールなどをいただいた時。つまり人様のお役に立てた時。

■勤怠管理システム

私がシステム開発に従事するルーツとなる「昔し話」です。でも勤怠管理はいまだに需要が多いジャンルです。
私の「備忘録」みたいなものですが、他にふさわしい置き場所がなく、ここに配置しました。

「勤怠管理システム」とは
「勤怠」というのはあまり一般的ではない業務用語だと思うのですが、「勤める(つとめる)」「怠ける(なまける)」ですから、就業に関する時間管理を中心とした、給与計算の前処理や、就業に関する労務・賞罰情報の集計を行なうシステムと考えれば良いでしょう。
私は社内系システムに携わる期間が長かったのですが、この「勤怠管理システム」については古くは外販もしていましたので、顧客要望の反映などでの製品改良を行なったりもしてきました。



私が携わった「勤怠管理システム」の処理概要は以下のような内容でした。
当時の「勤怠管理システム」は一般従業員が目にするものではなく、人事担当者だけが扱うシステムという設計でした。
項目概略説明
マスタ登録 個人マスタ登録 社員コード、氏名、入社日、退職日、配属事業所等の主要項目は人事システム等から取り込めますが、それ以外に「勤怠管理システム」特有の必要な項目があります。
まず、月給者か時給者かそれ以外かの区分で、月給者の場合は時間外有無や遅早管理の有無、交替制勤務の有無、基本勤務シフトといった細目を持たせており、時給者の場合は予定管理の有無、勤務可能曜日等、基本勤務シフトなどの細目を持たせていました。 「それ以外」というのは、在籍情報の登録だけでこのシステムでは勤怠処理を行なわないという区分です。



細目を含む多種な区分情報は事前に「勤務区分マスタ」で管理することにして、個人マスタからは「勤務区分コード」のみで指定する方が一見便利なのですが、 システムの導入時に社内の全ての勤務区分情報を事前に収集できなかったり、後から例外が発生するたびに「勤務区分マスタ」を追加する運用では、 「勤務区分コード」の採番自体も系統立った運用ができにくいことから、個人マスタに直接持たせるような仕組みとしていました。
勤務シフトマスタ登録 時間外や遅早の算出は勤務予定と実績の「差」を算出することになります。
ここで必要となる勤務予定を「勤務シフト」として短いコードを付けて登録しておきます。
月給者のみ、日勤のみの会社では基準となる「勤務シフト」は1つだけにできると思われるかもしれませんが、 育児休業明けの復職者が短時間勤務であったり、フルタイムで勤務できない障害者が在籍したりで、時給者の処理がないとしても複数の「勤務シフト」を登録することになるようです。
時給者がいる場合や交替制勤務、さらには事業所ごとに違うことも多いのでこのマスタの登録件数は数百種類になることもあります。



勤務シフトマスタの内容としては勤務シフトコード、名称、勤務時間帯、勤務時間、休憩時間の他、24時間スパンでの時間帯ごとの時刻・時間数・区分が登録できるようにします。この「区分」は勤務時間帯なのか休憩時間帯なのか、また深夜時間帯なのか等を判断するものです。勤務時間帯の区分ではフレックス制の対応するためコアタイムかフレキシブルタイムかの区別も行ないます。 「24時間スパン」とするのは勤務予定内だけではなく時間外勤務の場合でも休憩時間帯などの判断をするためです。
さらに、半休境界時刻、日付変更時刻なども登録できるようにします。半休境界時刻は半休取得時の遅刻等の判定に用い、日付変更時刻は「夜勤」「徹夜」などでどこまでを当日の出退時刻として取り込むかの判断に用いていました。
その他のマスタ登録 その他のマスタとしては「会社情報」「年間カレンダー」「勤怠科目」「タイムレコーダ情報」などを登録します。
「会社情報」では会社名、勤怠締め日、月次時間数単位、各種パラメータなどを登録するものです。
「年間カレンダー」は会社、事業所ごとの年間の休日を登録するものです。
「勤怠科目」は休暇、欠勤、長欠、遅早外などの科目名やその種別・区分を登録するものです。
「タイムレコーダ情報」はタイムレコーダ単位のマスタ情報で、現在もこの種の製品はあるのですが、データ収集の方式が全く異なるので後述します。
月初準備処理 勤務予定の登録 勤務予定は個人毎・日毎に登録がないと時間外や遅早の算出が行なえません。
ですが、これを毎月1人ずつ登録するというのは膨大な作業になってしまうので、前出のマスタ情報を利用してできるだけ自動化・合理化できるように配慮していました。
月給者で固定勤務の場合は、会社・事業所のカレンダー通りで月間の勤務予定を自動登録します。 交替制勤務の場合も一旦はデフォルトの勤務予定を自動登録した上で、変更箇所を画面登録してもらうという方法です。
時給者については個人毎・日毎の予定登録が必要な上、月中に入ってからの予定変更が発生するため、運用利便性上の対応として個人マスタ側で「予定管理の有無」を指定できるようにしており、 予定管理を使わない場合は遅早の算出はなく、実績時間数のみ集計されるようにしていました。
日次

随時処理
出退時刻情報の収集 当時のシステム環境は次項で説明するので割愛しますが「IDカード式タイムレコーダ」からの一括データ収集を行なう仕組みです。 当時はまだ「ICカード」ではなく、「磁気カード」です。
この「IDカード式タイムレコーダ」は通常は各従業員が「IDカード」を通した時のカードのIDコード・日付時刻・ファンクションが累積されており、これを「勤怠管理システム」から一括で取り込む方法でした。
ファンクションというのは「IDカード式タイムレコーダ」のフロントパネルにある「出社」「退社」ボタンに対応した数値です。 「出社」「退社」ボタンは毎回押す運用ではなく、液晶部分に表示されている「出社」「退社」のモードがこれから打刻を行なうモードと違う場合のみ押すものです。 「出社」「退社」以外に「出張」「外出」などを設定ができるタイムレコーダもあります。
各従業員が「IDカード」を通すオペレーションのことをシステムでは「打刻」と呼んでいました。
「出退時刻情報の収集」の処理自体は担当者がボタンを押して行なわれる一括処理です。
打刻データの更新 出退時刻情報をできるだけ正しく個人毎・日付(この日付は「勤怠日」と呼んでいました)毎の勤怠情報として自動更新するというのが結構重要な処理です。
「出退時刻情報の収集」の段階でこの更新まで行なうのは実際には「無理」があります。
まず、打刻データ自体の有効・無効の判定があります。
・同一人の3分以内の打刻は「やり直し」と判断して、後ろの打刻のみ有効とする(3分ルール」と命名)
・同一人、同一勤怠日同一ファンクションの打刻は、出社だったら「前」、退社は「後」の打刻のみ有効とする
といった判断です。
ところが、大きな工場などでは大人数に対応させるため複数のタイムレコーダが並んで設置されていることがあり、同一人の打刻が1台のタイムレコーダで行なわれるとも限定できませんから、 「やり直し」と判断ですら「出退時刻情報の収集」の段階ではできないことになります。



これらのことから、出退時刻情報は社員コード+打刻日時キーの「打刻情報テーブル」に累積的に収容させて、次に「打刻情報テーブル」を個人毎、打刻日時順に読み出して 有効・無効の判断を行なった上で実際に集計対象となる「勤怠情報テーブル」に更新させるという方法にしていました。 この方法なら、運用上の「打刻データ更新」の処理タイミングをまたいだ「3分ルール」の判定も行なえるからです。



処理でまず有効と判断された打刻データは、次に打刻日時から「勤怠日」を判断します。
日勤者で「出社」から始まるのであれば何も問題はありませんが、夜勤者や日勤でも徹夜した社員が「出社」打刻を忘れていた場合などにもできるだけ対応しなければならないということがあります。
打刻忘れがなくても、勤務予定が2425時始まりなどのケースもあって、その社員が前日にあたる23時台に「出社」打刻を登録するなどは正常な運用なので、これらの対応と処理結果に対する説明がつくようにする必要があるため、システム内では重要な処理だと思います。
日次データチェック 「日次データチェック」は実際の運用は「随時」です。 月初日から処理日前日までの「不正と思われるデータ」をレポートするだけの処理です。 「不正と思われるデータ」とは「欠勤無届」の他、「打刻不揃」「遅刻・早退あり」などをまとめてレポートするものです。



運用サイクルなどは作業を行なう人事担当者に依存することになりますが「月末にまとめて」だと「勤怠管理システム」を利用するメリットが薄れてしまいます。 というのは、例えば「紙」のタイムカードを月末に集めてきてチェックや集計作業を行なうレベルと同じになってしまうからです。
日次や週次での細かいサイクルでチェック、修正登録を済ませることで、月次での作業ボリュームを軽減するのが「勤怠管理システム」の大きなメリットのひとつに当たります。
休暇情報の登録 個人の出勤日に対する勤怠のデフォルトは「欠勤無届」としていました。 すなわち、出退時刻情報が入ってこない場合はこの「欠勤無届」のまま月次集計されます。
ここに承認された「休暇申請書」を登録するのですが、ネットワークが完備していない当時はこの部分のシステム化はできておらず、 人事担当者が承認された「休暇申請書」を画面登録するという方法でした。
「打刻忘れ」や「勤務予定誤り」に対する修正申請の登録も同様に行ないます。
月次処理 月次集計処理 名前は「月次集計処理」なのですが、処理内容としてはまず日次集計として日別の実働時間、時間外時間、遅刻、早退等を算出してから、 月次集計として個人別・月別に各科目ごとの縦合計を集計して「月次集計テーブル」へ更新を行なうというものでした。



このシステムの作成当時は「手作業からの移行」という段階でしたので、日別の実働時間でも「30分単位端数切り捨て」などが行なわれていてこれに対応していましたが、 現在では電算化はあたり前なので日別の計算は「分単位」、月次のまるめは許可されますが切り捨てはダメで四捨五入ということです。 これに反すると労基署から指摘を受けます。



時間外時間についても、勤務予定の外側を単に「時間外時間」、深夜時間帯に掛かる部分を「深夜時間」として算出する程度だったと記憶していますが、 社内系事案として近年でもこれらに携わっており、社労士からの意見を受けたりしていました。
現在では所定労働時間を8時間ではなく、7.5時間などとする企業が増えており、 こうなると、7.5時間から8時間の間は会社の所定労働時間は超えているけれど、 法定労働時間以内であるという「グレーゾーン」が発生します。
この処置や、8時間/日以外に40時間/週を超えた分も時間外時間として算出します。
また、週1回の法定休日を定めなければならず、その法定休日の労働時間は法定休日勤務時間として別枠で算出する必要があります。
さらに、月間の法定時間外時間が60時間を超えた分は別枠で集計する必要があります。 上場企業ではこの部分は手当てとして支払わなければならず、中小企業も2023年から手当てとする必要が発生するはずです。
月次集計レポート このシステムの作成当時はあまり多様な集計レポートは求められていませんでした。 但し、例えば「タイムカード」が撤廃されてこのシステムに移行すると、視覚的な原票がなくなってしまうので、 プルーフとして個人別の「月報」を用意しておりました。



現在であれば、法的に時間外時間の上限などが定められているので、個人別の年間各月の時間数を一覧化したものは最低でも必要になります。
月次確定登録 現在処理月を「確定」として、処理月を翌月に繰り越す処理です。
この処理を行なうまでは現在処理月内の修正や「月次集計処理」はやり直すことができます。
細かい話をグダグダと書きましたが、近年に見られるクラウドサービスでの「勤怠管理システム」はこういった細かい配慮が無視されているものが多く、割り切って利用するのでないと結局「不満だらけ」「業務実態に不適」という結果になってしまうようです。
かと言って、この処理概要のようなバッチ主体の仕組みでは現在のシステムとしては全くマッチしないでしょう。
「勤怠管理システム」はあまり業種に依存することがないシステムですが、利用方法は企業ごとにかなり異なるので、汎用的に使えるようにするための配慮が多々必要でした。

当時のシステム環境(ここが特に「昔し話」です。)
上記の「勤怠管理システム」を作成していた「当時」の環境なのですが、 1990年前後の話で、当然、Windowsも社内ネットワークもインターネットもまだ普及していなかった時代です。
項目説明
コンピュータ 民生パソコンでは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カード式タイムレコーダ」のみを設置して、人事部の担当者が直接データ収集を行なえるようにするのが合理的です。



このことは「モデム」で解決させていました。
アナログ電話回線でプロバイダ等にダイアルアップ接続するのに利用するような安価な「モデム」です。
本社側、事業所(店舗)それぞれにこの用途での電話回線を用意する必要はありますが、 上記の通信プログラムでは「タイムレコーダ情報」のマスタに電話番号の項目を設けてダイアルアップ接続ができるようにしておりました。

その後...
PTOS」の終息により、この「勤怠管理システム」も終息しました。 Windows版などで再開発するのに予算が立てられなかったことにもよります。



この少し前に、I社から専用OS版の「勤怠管理システム」の打診があり、 設計段階で参画していた時期がありました。
Windowsで開発しないというのは想像するに「MicrosoftにパソコンOSの覇権を取られたくない」ための対応に思われました。 I社からは、おそらく導入打診があった企業の意向らしき要件がかなり押しつけられており、汎用的な「勤怠管理システム」にはなりそうもないという印象で、 結局は販売実績には結びつかなかったと思われます。



その後は自社内での人事系含む社内系システムは担当しており、この中には「勤怠管理」も含まれていました。
コロナ問題が顕著になる前に退職しておりますが、2018~2019年頃に「スマートフォンでエントリができる勤怠管理システムの導入」という人事部からの打診があって、 既存製品数製品の比較検討を行なったことがありました。



現在は違うのかも知れませんが、古くから「勤怠管理システム」を手がけている会社を除くと「スマートフォンでエントリ」ばかりがうたい文句になっていて、 後方での時間外時間の集計すら現在の労基法にあった集計もできないものばかりだったと記憶しています。