ラベル 採用通知 の投稿を表示しています。 すべての投稿を表示
ラベル 採用通知 の投稿を表示しています。 すべての投稿を表示

人事情報の発表方法

「人事異動の情報(配置変更や地位変更)を社内に公表する」という業務はフクザツです。

昇格・降格・採用・退職・休職・部署異動・関係会社出向…と、さまざまなパターンがあり、また個別の事情もそれぞれに異なります。

人事担当者の気持ちとしては、たとえば「信任の厚いベテラン社員が晴れて定年退職される」というケースなら何か月も前から周知しておきたくなるかも知れません。しかし一方で「競合他社に転職する」というケースなら秘密にしておきたいと思うかも知れません。また「家族介護のために休職する」といったケースでも、同僚や関係者に対して(守秘義務違反に配慮し)積極的に事前連絡しようとする人もいれば、黙っていたいと考える人もいるでしょう。

基本的には『既定の解禁ルール』にのっとって、粛々と「人事部内秘の情報」を「社内公知の情報」に切り替えるべきなのでしょう。(人事通達)

業務上の課題

公表方法として「社内掲示」という手法がとられている会社は少なくありません。

しかし、紙に印刷して「掲示板」や「壁」に張り出すという手法では、外出が多い人、長期休暇中の人、あるいはリモートワーカーにとっては見る機会が非常に少ないものになってしまいます。他方、人事部門としても「決められたタイミングで掲示作業を行う」や「決められたタイミングで掲示を終了させる」といった業務は、意外と大きな負担となります。

また「朝礼での口頭発表」という手法がとられている会社もあります。

しかし、これもまた長期休暇中の人やリモートワーカーは、朝礼出席者と同じだけの情報量を得ることは難しいと言わざるを得ません。さらに、口頭であるが故に「異動の日付」や「異動部署」などが正確に伝わらないリスクもあります。

[人事異動情報の公表]

和暦テキスト

日本では「西暦」ではなく「和暦」を使うケースが多くあります。

現在は『2017年』であるとともに『平成29年』でもあります。

すなわち「2017-03-13」といった日付型データも、印刷物やメール本文などにおいては、「平成29年3月13日」と表示されるべきケースが多くあります。およそ1年前の記事(※)では、自動工程である[スクリプト工程]を活用した和暦変換をご紹介しました。(クラウド型ワークフロー『Questetra BPM Suite』に流れる案件データの自動変換)

第467話:自動生成 PDF の「証明書発行日」を和暦表示する! (2016-01-25)

スクリプト工程とサービス工程

ただ、クラウド型ワークフロー『Questetra BPM Suite』のバージョン11.1以降(2016-09-05)は、「サービス定義ファイル」(アドオンXML)によって任意の[サービス工程]を追加することが可能となっています。(サービス工程の Addon)

すなわち、和暦変換を行う[サービス工程]を利用すれば、(プログラミング知識を必要とする)、[スクリプト工程]を使う必要がありません。

[証明書発行フロー-和暦変換アドオン]

『社員マスター』をセットしたい!

ただ、人事部のシゴトは「在職者」だけを管理すれば良いという訳ではない。「出向した人」や「退職した人」の情報も管理しなければならない。しかし、業務システム等で使われる「在職者の一覧」(社員マスター)も、きっちりメンテナンスしたい。

そして「Excel ファイル」での社員マスター管理は、すでに限界だ。。。
  • 基本情報(社員マスタ-):社員番号、メールアドレス、通称氏名、入社年月日
  • 詳細情報(法定管理項目):戸籍氏名、生年月日、性別、最終学歴、職歴、緊急連絡先、退職年月日、など

以下は「氏名・住所・電話番号等の新規申請もしくは変更申請」を処理する業務フローだ。

入社時だけでなく、氏名が変わった時、住所が変わった時、電話番号が変わった時に、逐次申請してもらう必要がある。秀逸な点は、必要に応じてワークフロー基盤の『社員マスター』を自動更新できる機能だ。そして自動更新される『社員マスター』は、たとえば「ワークフロー基盤にログインアカウントを持たない社員に通知メールが送られる仕組み」などを作る際に活用される

[社員個人情報の申請受付]

※この記事には「改善編」があります

「日付は、和暦で!」

日本において「年の表記」は複雑だ。つまり、行政や学校では「2016年」とは言わない。あくまでも今年は「平成28年」なのだ。『住民票』であれ『戸籍謄本』であれ、ハタマタ『卒業証書』であれ、、、少しでも重みある書類には「和暦」が記入される。


しかし、現実、、、「ことしは平成28年!」と即答できる日本人は少ない。。。
とは言え、この「数十年に一度、元年(1年)にリセットするという仕組み」は、もう1400年以上も続いている。時の政府の一存で止めてしまえるものでもないのだ。。。(そして、現在の天皇が亡くなった日には、また新しい『元号』が発表されるハズだ)

以下のワークフローは『在職証明書』の発行フローだ。

上流工程で在職者の「氏名」や「生年月日」が入力され、フロー途中の[自動工程]で証明書 PDF が自動生成される仕組みとなっている。特筆すべきは「生年月日」や「証明書発行日」などの日付データが自動的に和暦に変換される点だ。たとえば『卒業証明書』や『保護者だより』のなどの発行フロー等にも転用できるだろう。

[証明書発行フロー]

「子会社ごとに、マイナンバーを集めよ!」

人事制度は子各社ごとに違う。人数規模だって異なる。そう、、、アルバイトが何百人もいる会社もあれば、全くいない会社もある。全国に地方営業所を持つ会社もあれば、全くない会社もある。

グループ各社の間接部門を共有する「シェアードサービス」の仕組みは珍しくない。社会保障や税の手続きについてもシェアード会社に委託されるケースは多い。しかし、業種や業態が子会社それぞれに大きく異なるのであれば、「マイナンバー収集」については各社でやってもらうしかない。いわゆる「本人確認」の方法は、各社で工夫してもらうべきだ。

「マイナンバー収集」については、当ブログでも5つのプロセスを例示した。
  1. 小規模組織での申請承認
  2. チェックディジット機能追加
  3. 現場で本人確認
  4. 本店のみで本人確認
  5. 複雑な申請による本人確認

以下のワークフローは、これらの通じて収集されたマイナンバーが、最終的にシェアード会社側に自動集約される仕組みだ。各社での収集プロセスの最下流に自動イベント「HTTP 送信」を配置してもらうことを想定している。

[更新情報の受信プロセス]

『ご契約にはマイナンバーが必要です。フォームに入力してください。
(もしくは郵送してください) 株式会社○○○○』

インターネット上には、無数の「フィッシングサイト」が存在する。たとえば「クレジットカード番号」や「オンラインバンクの暗証番号」などがだまし取られる被害は、後を絶たない。「マイナンバー」(個人番号)を集めようとするフィッシングサイトも、遅かれ早かれ出現するだろう。(「マイナンバー占い」とか、絶対ダメ!!)

『もしウチの社名を名乗るフィッシングサイトが出現したら・・・』

多くの外部フリーランスを活用しているような会社であれば、「オンライン申請」に頼らざるを得ない。しかし、もしも模倣フィッシングサイトが出現するような事態になればタイヘンだ。基本的には、「データ送信先」や「郵送先」の確認をオネガイする、くらいしか方策がない。
  • 確認ファイル送信先のURLは「https://example.com」です!!
  • 確認書類のコピー郵送先は「京都市中京区○○番地」です!!

前回紹介した「マイナンバー申請プロセス」
の例では、遠隔地にいるフリーランスさんも、弁護士さんや税理士さんも、オンラインで申請することができた。しかも「マイナンバーの収集に関与する人」を極めて限定的な数に減らすことが可能な、秀逸なワークフローだ。その結果として「人的な情報漏洩のリスク」を限りなくゼロにできることができる。

しかしこの例では、「マイナンバー」や「証明書の画像ファイル」を添付してもらう必要があった。
  • A. 『運転免許証』の画像
  • B. 『通知カード』の画像
※A: 『個人番号カード(表)』や『パスポート』等といった写真つき身分証明書で代用可能
※B: 『個人番号カード(裏)』や『新住民票』といったマイナンバーが記載された証書で代用可能

つまり、フィッシングサイト側の視点でいえば「だまし取りやすい構造」と言える。情報セキュリティの有資格者によってもリスク評価は様々だが、少なくとも「リスクがゼロ」とは言い切れない。そもそもセンシティブな情報をオンラインやりとりしないですむ方法は無いものだろうか?


以下のワークフローは
  • オンラインで、「A.運転免許証の画像」も「B.通知カードの画像」も送信しない(!!)、
  • オンラインで、「12桁マイナンバー」の送信もない(?!?)、
という特徴がある遠隔地からのマイナンバー申請プロセスだ。キーワードは「情報の分割」だ。この業務プロセスを大雑把に説明すると、次の2工程で構成される。
  1. 先頭8ケタの送信
  2. 末尾4ケタの口頭連絡
注意)「同一の者であることが明らかである」について、行政機関等との間に「見解の相違」が発生するリスクがあります! 詳細については、法律施行規則3条(5)、法律施行規則9条(4)を確認してください。(あるいは、タライマワシを覚悟したうえで、行政機関に確認しに行ってください)
行政手続における特定の個人を識別するための番号の利用等に関する法律 (2013-05-31)
行政手続における特定の個人を識別するための番号の利用等に関する法律施行令 (2014-03-31)
行政手続における特定の個人を識別するための番号の利用等に関する法律施行規則 (2014-07-04)
特定個人情報保護評価指針 (2014-04-20)
特定個人情報の適正な取扱いに関するガイドライン(事業者編) (2014-12-11)

[マイナンバー申請フロー(5)]

「社員に申請してもらうだけの話でしょ!??」

それはソウなのだが、それだけでもない。。。 会社が集めるべきマイナンバーは、意外と多い。つまり、「社員/アルバイトのマイナンバー」とその「扶養家族のマイナンバー」だけに留まらない。

特にナンギなのは「外部委託先(個人)」だ。

すべての日本企業は「国の徴税業務」を手伝っている。すなわち、個人に対する報酬支払いの際には、所得税を源泉徴収している。そして、その預かった所得税を上納している(所得税法:源泉徴収義務)。(さらに言えば、源泉徴収額を集計して、源泉徴収票を本人にお届けしている)
  • 原稿料、作曲代、デザイン報酬、著作権使用料、講演料
  • 弁護士・司法書士・会計士・税理士・弁理士などの報酬
なるほど。外部の個人に対して、講演を依頼したり、デザインを依頼したりすると、、、そういった方からもマイナンバーを提供してもらう必要あるのだ。最近流行の「クラウドソーシング」を活用している企業などは、特に注意が必要だ。

前回までに紹介した「マイナンバー申請プロセス」
では、社員やアルバイトからの申請にフォーカスしてきた。そして、前回記事では、『本人確認の措置』を管理職者たち(店長やら課長やら)で分散/分担して行うワークフローを検討した。
  • X.分散型: 照合確認を組織内で分担する(全店長・全課長らが確認する)
  • Y.集中型: オンラインで照合確認できるだけの書類を添付してもらう

<チェックディジットUI>

今回紹介する業務プロセスは、すべてをオンラインで一元的に行う。(集中型)
  • デザイナやプログラマなど外部フリーランスをフル活用している会社
  • 外部個人に対して日常的に講演依頼や執筆依頼を行っている会社
などにおいて非常に便利だ。『本人確認の措置』を含めてすべての処理をオンラインで実現できる。しかも、(特定)個人情報を目にする人は、本社の「経理部門」に限定することができる。

ちなみにココでは、本社勤務者も遠隔地就労者も、、、バイトさんも社長さんも、、、新入社員さんもベテラン社員さんも、、、弁護士さんも税理士さんも、、、みんな「申請フォーム」(セキュアなWebフォーム)で申請することを想定している。

[マイナンバー申請フロー(4)]
マイナンバー法は、会社に対して
  • a: 正確性. 「入力ミス、しないでね」
  • b: 正当性. 「その人の番号か、確認してね」
と言っている。 前回までに紹介した「マイナンバー申請プロセス」
は、これらの法令理念に沿った取得プロセスと言えるだろう。しかも非常にシンプルだ。

番号確認担当(経理部門)は、申請フォームに「後日『通知カード』との照合確認を行います」と書かれているように、社員の座席まで行って確認すれば良い。そのついでにマイナンバー制度や日頃の管理業務に関する疑問や質問にも答えられる。中小企業であればこれで十分だ。(むしろ都合が良い)

しかし仮に、「大規模組織における申請プロセス」として見れば、色々と問題がある。
たとえば「在宅就労者が100人を超えるような会社」や「アルバイトを毎月100人雇用するような会社」を想像してみる。もはや経理部門だけで『a.タイプミス番号』や『b.なりすまし番号』を見抜くことは難しい。経理部門内のノウハウも分散するだろう。故意に他人になりすまして職を得ている人や、所得を分散しようとしている人には、無力と言わざるを得ない。(『タイプミス番号』については「チェックディジット」を活用すればその大半を回避できるかもしれない。→前回記事

<チェックディジットUI>

概していえば、管理部門の人手が足りない組織は、
  • X. 照合確認を組織内で分担する(全店長・全課長らが確認する)
  • Y. オンラインで照合確認できるだけの書類を添付してもらう
といった戦略をとらざるをえない。以下のワークフロー例は「X. 分担する」の発想となっている。

[マイナンバー申請フロー(3)]
マイナンバー申請での「誤入力」、、、ありそうだ。。。(怖)

経験論的な話として、社員からの申請にはその5%~10%くらいに「誤入力」が含まれる。(そして往々にしてアルバイトさんよりベテラン社員達からの申請の方がヒドイ!)。わざわざ申請してもらい所得税や社会保険の公的手続きに利用したとしても、そもそも「申請されたナンバー」が間違っていたのでは、手続きそのものをやり直さなければならなくなる。(悲劇)

マイナンバー法の想定では、「提供の要求」(H27法14)をする企業側が、(1)正確な12桁をあずかり、(2)それが本人のモノであることを確認する、、、のだが、、、たとえば子沢山な社員の場合では、何人分もの「12桁」を入力するワケで、「絶対ミスるな」とも言い難い。

以下のワークフローは、マイナンバー(個人番号)入力時に「チェックディジット判定」を行っている。

つまり、入力時の「12桁数字」が「マイナンバーとしてはありえない12ケタ数字」だった場合、入力エラーと表示される仕組みだ。この工夫だけで、誤入力を激減させることができるだろう。なお、このワークフローは、前回エントリの拡張であり、データ項目定義や基本的なフローは同じだ。

[マイナンバー申請フロー(2)]
日本にも「マイナンバー」がやってくる。

社会システム全体の効率化のためには、避けては通れない制度だ。
  • 行政の業務プロセスも、
  • 企業の業務プロセスも、
これから大きく変わっていくのだろう。。。何にせよ、今年(2015年)の10月にも「通知カード」が書留郵便で届く。赤ちゃんからお年寄りまで、「住民票」があるヒト全員に。。。 と言うことで、本ブログでは、企業に当座必要なワークフローについて考えてみたい。(「社会保障/税/災害対策」の3分野+αに展開される制度の全体像については他記事に譲る)

以下のワークフローは、非常にシンプルな「マイナンバーの申請フロー」だ。

ほぼ全ての企業は「所得税の納税」(源泉徴収)や「保険・年金の加入」の義務がある。つまり「マイナンバーを集めない」(個人番号を集めない)という選択肢はない。従業員や役員など、全員からモレなく集める必要があるのだ。早いウチに(=「通知カード」を紛失してしまうマデに?)申請してもらうのが、会社にとっても、社員にとっても良い。

[マイナンバー申請フロー(1)]

「Backend としての BPMS を強化する!」(Business Process Management System)

ナニコレ? じゅもん?? しかしコレ… IT 業界人の間では「珍しくない表現」らしい。要は、(沢山のコンピュータで構成される) IT システムを構成するコンピュータについて、
  • 人間に遠い側のコンピュータを「Backend」、
  • 人間に近い側のコンピュータを「Frontend」
と呼んでいるだけのようだ。(マーケティングの世界で「バックエンド」と言えば「本命商品」のコトだが…)

具体的に言えば、ユーザ管理、データベース管理、ファイル管理、などを担当する仕組み(コンピュータ)が Backend と呼ばれ、パソコンアプリやスマホアプリが Frontend と呼ばれている。最近では「Backend as a Service」や「mobile Backend as a Service」なる言葉もあって、より利便性の高い「フロント開発」に注力するのがトレンドになっている。

しかし、、、

情報通信が進化した時代、「ヒト」だって常にネットワーク上に居る。バックエンドと言う仕組み、、、何もコンピュータだけで構成される必要は無い。業務プロセス管理(BPMS)は、ヒトを含むバックエンド・システムだ。 (「(クラウド)コンピューティング」とは言えなくなるが…)

例えば「請求書発行システム」にヒトが介在していても良い。いや、むしろヒトが介在した方が成果物品質は向上するような気がする。。。そこで、ここでは「郵便物の送付依頼システム」と言うバックエンドについて考えてみた。このワークフローにおいては、送付状こそ自動生成されるが、封入や投函はヒトによって行われる。

ん?、、、更にこれに API を追加すれば、より自動化された「バックエンド・システム」になるような。。。

[郵便物郵送システム]

業務プロセス『アルバイト採用』、、、における課題。

<課題1:「今」が分からない>
  • ○○君の応募は、今、誰が対応しているのか?
  • ○○君の応募に対して、次は、何をするのか?
  • 採用(不採用)通知まで、何ステップが残ってるのか?
  • 応募者とのコミュニケーションに、ヌケモレは無いか?
<課題2:「過去」が分からない>
  • ○○君は、どんな評価で、いつ採用されたのか?
  • 不採用となった人の不合格理由は何だったのか?
  • 去年は何人の応募があって、何人合格したのか?
  • 結果の通知まで、どのくらいの時間がかかるのか?

例えば、『履歴書の受理』、『電話での面談日程調整』、『口頭での合否通知』と言った「日常的な業務」、、、いずれも、記録を残すとなると結構な手間だ。結果として、業務ノウハウは共有されず、業務の流れは属人的になる。組織としての「あるべき業務フロー」が議論される事も無い。

確かに

 「採用活動なんて、その時々のマネージャによって手法がチガウもんだ!」 

そう言う結論もアナガチ間違っていないのかも知れない。しかし、(他の業務にも言える事だが)、「標準化」なくして「分業化」は実現しない。『採用フロー』は、事業規模の拡大、新規事業の開発、他市場への進出など、会社の進化を大きく左右する業務だ。人事業務の進め方は、少しずつであっても、「可視化」する方向に、そして「標準化」する方向に改善して行きたい。

[アルバイト採用判定フロー]

『採用活動と就職活動』のあるべき姿は、何十年も議論されている。
特に、日本においては「永遠に解決されない社会問題」の様な気がする。

つまり、企業側は少しでも優秀な人材を獲得するために「青田買い競争」を展開し、一方で大学生達は、3年生にもなれば学生の本分たる「学業」はソコソコに、 就職先を探す活動に非常に多くの時間を割く。稚魚まで捕獲したい「漁師達」と、早く釣り上げてもらいたい「魚達」の利害は一致するのだが、当然、当事者た ちも「あるべき姿」だとは思っていない。

これまで企業も大学も、全く無策だったわけではない。
日本では「就職協定」なる紳士協定 があった。1952年に制定され1996年に廃止されるまで、守られないルールとして飾られ続けた。21世紀に入っても企業側で「倫理憲章」を定めてみた り、大学間においても「申合せ」を策定してみたり、様々な取り組みが行われてきた。しかし、それらも双方の自制を実現するに十分な制度だったとは言えな い。「恋に恋する男女」に自制を求めるがごとく、「必死になって就職先を探す大学生」と「早い段階で新卒を確保したい企業」の活動を制限するには至らな かったと言わざるを得ない。

2013年の春、安倍首相が『能力を伸ばす機会を失うのは看過できない』と経済団体を呼びつけ、採用選考時期 の「更なる後ろ倒し」を要請した。平たく言えば「【企業説明会】は、3年生の終わりの春休み(3月)以降にしなさい」と言う主旨だ。経済団体の『新しい倫 理憲章』が近く制定され、現行の「3年生の冬休み(12月)」より3か月遅い「3年生の春休み(3月)」と定められるだろう。

※ 参考)

紳士協定を(形式的に)順守せざるを得ない企業は、よりスムーズな「採用選考業務フロー」に改める必要がある。

[採用選考ワークフロー]

新卒採用フローの現場は、意外とローテクだ。
特に不採用の通知は、就職を希望する学生の立場に立った丁寧な対応が必要になるため、どうしても手間がかかってしまう。さりとて一方では、受験者に対して≪迅速な連絡≫も実現したい。
社内の業務フロー(ワークフロー)をブラッシュアップし続ける必要がある。(不採用通知の例文も、各社でブラッシュアップを!)

類似:『数百人のエントリーシートを管理する

<各タスク名>
0.郵送分の入力、1.書類合否判断、1a通知文、1b通知文、2.一次合否判断、2a通知文、2b通知文、3.二次合否判断、3a通知文、3b通知文、4.最終合否判断、4a通知文、4b通知文

[人事採用-結果通知メール:「4b通知文」画面]

<プロセスデータ名>
  • 件名(応募者氏名)
▼エントリ内容▼
  • 文字型: 応募者ふりがな
  • 日付型: 生年月日
  • 文字型: 電話番号
  • 文字型: メールアドレス、
  • 文字型(複数行-2行): 住所
  • 文字型(複数行-4行): 学歴
  • 文字型(複数行-4行): 志望動機
  • 文字型(複数行-4行): 会社でやってみたい事
  • ファイル型: 参考ファイル
▼コントロール▼
  • 選択型: 書類合否
  • 選択型: 一次面接合否
  • 選択型: 二次面接合否
  • 選択型: 最終面接合否
  • 掲示板型: 人事メモ
▼応募者との通信▼
  • 文字型(複数行-2行): 書類結果通知文
  • 文字型(複数行-2行): 一次結果通知文
  • 文字型(複数行-2行): 二次結果通知文
  • 文字型(複数行-2行): 最終結果通知文