tuqulore / employee-handbook

株式会社ツクロアで運用中の就業規則
0 stars 0 forks source link

病気休暇、生理休暇の申請に関するQ&A #71

Closed knokmki612 closed 2 years ago

knokmki612 commented 2 years ago

がより親切な資料に記載されていると申請しやすくなるとフィードバックをもらった

knokmki612 commented 2 years ago

回答としては就業規則としては事前である必要も事後である必要も記載がないので

になるのかなと思った(記載がないとはいえ締め日以降に申請されると現実的に対応が難しかったりすることの付記は必要そう)

Takashi-U commented 2 years ago

育児休業などの特殊な休業・休暇については別ですが、一般的にはこういった申請は始業時刻までに申請乃至報告を行う事が多いかと思います。その上で、例えば緊急入院などをして連絡がすぐに出来ないケースを想定して、事業主側の裁量で事後の申請や報告を認めるという形が良くあるパターンです。

緊急入院だとおおげさでしたが、他にも、前日に熱が出て寝ていたら、体調が良くならず寝過ごしてしまったみたいな事は想定出来るでしょう。その様な場合は、起きたらすぐに連絡すれば事業主目線も申請が遅れても仕方無いと感じるのではないかと(私の主観ですが)思います。

事後でもok!というのはありがたい様に聞こえるかもしれませんが、反面、事後というのはいつまでなのか(翌日までなのか、翌月までなのか、あるいは翌年までなのか…)というのが曖昧になることが問題です。 良くない例としては「Aさんは翌週に申請して何も言われなかったのに、私は5日後に申請して怒られた」みたいな事が考えられます。もちろん、申請を受けた方も悪気は無い(そもそも事後申請を認めている時点で親切)わけですが、休んだ方はともかく、申請を受ける方はいちいち以前どうしていたかを覚えてはいないでしょう。

休暇を取る本人にとっても、事前でも事後でも良いという形よりも「事前なら絶対にOK」という、誰が見ても明らかに日付時刻で判断が出来る基準にした方が良いというのが、規則というものの性格上からは言えると思います。裁量が入る余地を極力少なくするのが、筋としては良いというのは一つの考え方です。

そもそも、会社の同僚や上司からしても、仕事の段取りだけならまだしも、連絡も無く出勤が無いと事故にでも遭ったのかもしれないと心配してしまいますので、常識的にも始業前に休暇を申し出るべきかと思います。

上記は良くあるパターンという事で挙げましたので、一例と捉えてください。 給与の締め日までに申請すれば良いとしても良いですし(それだと一意に決まるので上記の主旨とも合致します)、事後は一切認めないというのもあり得ます。

長くなりましたが、単に事後とすると、裁量が大きいというのは少し筋が悪いかなと思いました。

knokmki612 commented 2 years ago

裁量が大きいというのは少し筋が悪い

ありがとうございます、おっしゃるとおりと思います

申請できる期間を明確にすることはより良いと考えます。

気になる点としては、今回の件に留まらない話になりますが、運用上の疑問点が生じたときに、それをどのような形で反映することを原則として考えればいいのかという点でしょうか。

今回の病気休暇、生理休暇の申請期間が分からないという疑問に対しては、当初はQ&Aのような資料を設けることを考えていました。しかしコメントをいただきまして、今は当該規則を改定することがより明確な反映になるかと思いました。

Takashi-U commented 2 years ago

規則について疑義がないようにQ&Aにて説明する形でも、きちんと労働者と共有出来ていれば問題はありません。

シンプルに決まるものならば規則そのものに記載、冗長になるならば他の書面を作成、というのが良いと思います。 さらに、他の書面を作成するにあたっては、クリティカルなものについては別規則に、そうでなければQ&Aなど利便な形にされて良いかと思います。これは私の感覚です。

この辺りも線引きは確たるものは無いところではあります。法律の事なので、何がクリティカルであるかというのも直感的には分かりにくい事もあるかと思います。 身も蓋もない話ですみませんが、それがQ&Aという形なのか、あるいは規則という形なのか、どの様な形であっても就業規則と一体となって運用されているのであれば形式は特に問われません。自由に決めていただいて問題はありません。だからこそ、冗長ならば他の書面を作成しようというテクニック的な話になりますし、その書面の形も感覚の話になってしまいます。

これを踏まえて、御社に限った話になりますが、具体的には

  1. 一文で収まることは規則へ
  2. 文量が大きくなりそうならどの様な形式でも良いのでWikiに記載
  3. Wikiに記載したもののうちクリティカルと思えるものは 1.複数文になっても条を立ててでも規則へ 2.あまりにも量が多いなら別規則へ ※1と3の場合は規則変更の手続きを行う。

※の手続きについては自分で書いておいて言うのもなんですが、微妙な点も若干あるとは思います。ただ、ここまでオープンにしているのであれば、規則として成立していると考えられますので問題は無いかと存じます。

という事でどうでしょうか。

==以下は補足です。==

一つ注意しなければならないことは、規則とWikiが一体となって運用されていると、Wikiもまた規則である可能性があるという点です。 これはつまり、厳密に言えば従業員代表の意見を聴くとか、周知をするとかいった部分が守られている必要が出てくる可能性があるという事です。また、変更をした場合、事業場の規模によっては就業規則の届出義務が発生します。 Wikiに記載される内容にもよりますし、この辺りの区別は難しい所です。微妙は点があるとしたのは、上記の対応は元々難しい区別を、ほんの少しですがさらに難しくしている側面があるからです。

私は個別具体的な事案で問われれば、その事案に対して私なりの見解を出せますが、皆さんが運用していく中ではそうはいかないと思います。私もサイ本を読んだことはありますが、日常的にプログラミングをしないので、内容は綺麗さっぱり忘れております。Javascriptは書けません。同様に、この区別は日常的にこういった規則などに触れていないと難しいものです。それでも見解が分かれることもあります。

それでも、これでどうでしょうかという結論に達しているのは、どのみち明確な区別がつかないので、規則として妥当と思われる運用を第1に考えれば良いという考え方からです。 (別に、上記のやり方が間違っているというわけではなく、殆ど正しいという事は付記致します。可能性として小さなバグを踏むことがあるという事にはご留意いただきたいという話です。また、そのバグを踏んだとしても、就業規則の提出義務があるのかどうか、しかも微妙な所であるという程度の話です。私は立法趣旨を無視して形式的に法律を守ることは好まないので、なるべく明示することを重要視したわけです。それを伝えたいがための補足となります。)

少し話が逸れますが、規則とWikiをPDFにしてしまって電子申請すれば、データなので控えもかさばりませんし、とりあえず全部出しておくという考え方はあり得ます。実務的にも支障は無いでしょう。以前は電子申請が無い頃は紙面にしなければなりませんでしたので、記載内容が冗長になると大変でした。とりあえず全部フルセットで出してしまうと言うのも また、規則の変更は規則をまるごと全て出す必要は無く、変更届、意見書、差分だけ出せば良いですので、変更届と意見書の他に、diffだけ提出すれば足ります。GitHubでの差分の見た目に面食らって難色を示す担当者はいるのかもしれませんが、法的には有効です。(もっとも、見た目だけで難色を示して受取を拒まれたとして、受け取らない事が間違っている事を主張するよりは、提出し直した方が早いのかもしれませんが…)

ちなみに、私の経験則ですが、コンパイルしていないtexの差分も受け付けてもらった事があります。法的には当たり前ですが、特に何も言われませんでした。(最近は、行政手続法もしらない窓口の人が散見され、書類の見た目だけで判断される方も…)

knokmki612 commented 2 years ago

これを踏まえて、御社に限った話になりますが、具体的には

  1. 一文で収まることは規則へ
  2. 文量が大きくなりそうならどの様な形式でも良いのでWikiに記載
  3. Wikiに記載したもののうちクリティカルと思えるものは 1.複数文になっても条を立ててでも規則へ 2.あまりにも量が多いなら別規則へ ※1と3の場合は規則変更の手続きを行う。

※の手続きについては自分で書いておいて言うのもなんですが、微妙な点も若干あるとは思います。ただ、ここまでオープンにしているのであれば、規則として成立していると考えられますので問題は無いかと存じます。

という事でどうでしょうか。

補足含め興味深い話ありがとうございます。

規則変更の手続きをいかにしておこなうのかあいまいであったので、 #72 にて明文化し社内でレビュー中です( @Takashi-U さんもレビュワーにつけようと思いましたがなぜかできなかった)

少なくとも直近ではWikiのような容易に変更可能な文書管理は想定しておらず、リポジトリ上のマークダウンファイルとして管理することになるかと思います。しかしそれは本質ではなくて規則、規程という名がついていようがいなかろうが、実質的に規則としての役目を果たしているなら同様に規則変更の手続きを踏まえる必要があると理解しました。

どのみち明確な区別がつかないので、規則として妥当と思われる運用を第1に考えれば良いという考え方からです。

その点賛成します。

72 で規則変更の手続き(就業規則・各規程の改正施行手順)の適用範囲を明示しており、今後対象を拡大する必要が出てくるかも知れませんが今のところは #72 をベースにすすめていこうかと思いました。

knokmki612 commented 2 years ago

話が私の方で脱線しましたが、このissueとしては

57 にて生理休暇の申請については病気休暇に委任するかたちで変更したのち、

  • 原則として事前(始業前なら当日でも事前です)の申請
  • 事業主が事前の申請が出来ない事につきやむを得ないと認めた時は、そのやむを得ない事情が止んだら速やかに申請

のような申請のタイミングについての規程を病気休暇に追加することで対応完了かと思いました

knokmki612 commented 2 years ago

申請のタイミングについてなんらかの規則の追加が必要かと思っていましたが、欠勤の取り扱いがそのまま適用されるということでとくに追加は不要と理解しました

https://github.com/tuqulore/employee-handbook/blob/master/01_%E5%B0%B1%E6%A5%AD%E8%A6%8F%E5%89%87.md#%E7%AC%AC21%E6%9D%A1%E6%AC%A0%E5%8B%A4

Originally posted by @knokmki612 in https://github.com/tuqulore/employee-handbook/issues/57#issuecomment-1181209903

上記の認識により完了