11
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

LITALICOAdvent Calendar 2024

Day 25

3年周期で来る超多忙な時期に育休を取得しながらも乗り切った話

Last updated at Posted at 2024-12-24

この記事はLITALICO Engineers Advent Calendar 2024 カレンダー3 の 25日目の記事です。

ご挨拶

メリークリスマス!!:tada:

我が家では、サンタさん :santa: から業務委託を受けた事にしている @YellowLemon です。
株式会社LITALICOでエンジニアをしています。
Qiita初投稿になります。よろしくお願いします。

もくじ

  • ご挨拶
  • 本記事の内容について
  • 本記事を書くきっかけについて
  • 私について
  • 3年周期で来る超多忙な時期とは
  • なぜ超多忙と分かっていて育休を取ろうと思ったのか、取ったのか
  • 育休までにやったこと
  • 引き継ぎメンバーからのフィードバック
  • 育休中の奮闘記
  • 育休明け
  • 育休取ってみてどうだった?
  • 全体を振り返ってみて
  • 終わりに

本記事の内容について

タイトルにある内容を技術的な細かい話は抜きにしてまとめています。
前提となる知識などは無いので、気軽に読んでいただければ。
ボリュームが大きめなので、年末年始とかでも良いかもしれません。

馴染みのない単語かも?と思うものに対しては、ゆるめの解説を都度入れています。
(その解説、ちょっと怪しいぞ?!)というのがあればご指摘いただけると助かります。 :bow:

タグに気なるワードがあれば、ぜひ前のめりにどうぞ。

本記事を書くきっかけについて

SlackのDMでのお誘いが始まりでした。 :mailbox:
前年度は、(お祭り的な感じでワイワイやってるなぁ)と外から見ているような感じだったのですが、お誘いいただいた方の記事に背中を押していただきました。

「そのとき」にしか書けない記事があるし、「その人」にしか書けない記事がある。だから、1つ1つの記事に価値があると思っています。

私について

エンジニア歴は10年後半。
ここ12~3年は、介護保険のシステムに携わっています。
ちなみに、初めての就職はアミューズメント業界でした。(今とは全然違う業種ですねぇ)

3年周期で来る超多忙な時期とは

介護保険について

用語に馴染みの無い方は、↓のゆるい解説を御覧ください。

介護保険ってどんなの?

介護保険制度は、介護が必要になった高齢者等やその家族を社会全体で支えていく仕組みです。
代表的なものとして下記のようなサービスがあります。

  • ヘルパーさんが、ご利用者様のお住まいに訪問して日常生活の支援を行う
  • ご利用者様が、事業所様の運営する施設に通って日中の生活を行う
    ※一般的にデイサービスと呼ばれます
  • 事業所様が、ご利用者様に補助杖や車椅子等の用具を貸与する

より詳しい解説については、厚生労働省のページに委ねます。
https://www.kaigokensaku.mhlw.go.jp/commentary/about.html

介護保険制度は、3年に一度の周期で大きな改正があります。
2000年4月1日より始まり、2003, 2006, ..., 2018, 2021 と法改正があり、
次の法改正は、2024年4月1日という流れになります。

超多忙、って実際のところどれくらい多忙なの?

(話盛ってるんじゃないの?:thinking:)とお思いの方、ここでご説明させてください。

今までの改正スケジュール感を箇条書きにしますと以下のような感じです。

1. 法改正の前年の年度末

  • こんな方針で改正をするよ、という情報が厚生労働省から公開されてくる
  • まだ具体的な内容が見えきっていないので、こちら側としては手探り状態
    • とは言え、この時点である程度のボリューム感は見えてきます
    • 新しい概念のサービスが出てくる、となった場合は影響度が高いなぁ、という肌感はこの頃だと既に得ています

2. 1月末頃

  • 厚生労働省から具体的な改定内容が公開される
    ドキュメントには、(案) が付いており確定版ではない事が多い
    ※後に多少なりひっくり返される事がある
  • この時点でシステムにてどう対応するか具体的な方針が決まっていく
  • 本格的な実装が入れるのはこの頃

3. 2月中旬

  • 個々のサービスによる単位数(請求額を算出するにあたり基礎となる点数)が載った「サービスコード表」と呼ばれるものが公開されます
    • この表もまだ確定段階のものではないため、後にコードが増減したりします

4. 3月下旬

  • ケアマネージャーと呼ばれる方が、ご利用者様に対して4月の支援内容をスケジューリングします

よって、この頃にシステム改修が完了していないといけない

5. 3月末頃

  • 確定版の資料が出る
    • 確定版と言いつつ、4月入ってから確定版の 一部修正 が爆誕する事も :thinking:

6. 4月1日

  • 改正後の運用がスタート

7. 5月1~10日

  • 改正後の運用での事業所様初請求
  • この期間は事業所様からのお問い合わせが3年間でピークと言えます
    • 制度上、請求期間が決まっているのでお問い合わせに対しては、迅速な回答が求められます

1月末頃~3月下旬の短期間で対応を行わなければならず、対応が間に合わないとなった場合、直接のお客様となる事業所様のみならず、事業所様が介護サービスを提供するご利用者様にも影響が出ることになります。

また、請求の計算に誤りがあった場合、事業所様に本来入ってくるはずのお金が入らない、という事態に繋がります。そうなると、事業所様に所属する従業員の方たちへのお給料が出せない、という事にもなりかねません。

(スケジュール感、納期が遅れたら時のリスク等については分かった :ok_hand:
(対応ボリュームはどうなの? :thinking:

期間だけでなく、対応ボリューム感が分からないと、忙しさも見えてこないですよね。
「介護保険について」の項で代表的なサービスについて少し触れましたが、具体的には60種類を超えます。
携わっているシステムは、全網羅はしていないものの幅広く対応しています。
中には似たような形態のもの、制度改正で基本的に変化が少ないもの、色々な性質があるものの、個々に変更点があるので改修においても個々に行う必要があります。

1月末頃~3月下旬、となると約2ヶ月。営業日数的に大体40日。
1つのサービスの対応に1~2人日。60種類あるなら単純計算で短く見ても60人日。
これだけだと明らかに複数人で対応しないと間に合わないですね。
複数人で手分けして対応するのはしますが、規模としては数名レベルです。

この短期間だけメンバー大増員!なんてことをしても、上手く行かないでしょう。
最初のキャッチアップには誰しも相応の時間がかかりますし、ドメイン知識も必要な部分となると尚の事です。

なぜ超多忙と分かっていて育休を取ろうと思ったのか、取ったのか

法改正対応は何度も経験しているので、その大変さは身を持って知っているつもりです。
それ故に、超多忙なタイミングで育休取るのは勇気が要りました。
1ヶ月抜けて法改正対応乗り切れなかったらどうする?!って何度も自問しました。
それでも育休を取ろうと決めたのは、色々な要因ありますが列挙すると

外的要因(会社側)

  • 弊社社長が「LITALICOでの男性育休を推進したい」と行動に移した
    • トップが実際に育休を取った、というのは男性育休の風土形成に大きく影響したと思います(自分が影響を受けたその1人です)
  • 直属の上司が半年ほど前に育休を取得した
    • 上司が育休の際は、引き継いだ業務もあり、引き継ぎに対する知見が少しできていた

内的要因(家庭内)

  • 妻と二人暮らしでそれぞれの両親からはサポートを得るのが難しい環境にあった
  • 実父と1on1で食事した時に「父親らしい事をあんまりしてあげられなくてすまなかった」(要約)と、言われ気持ちに少なからず変化が
    • 同じようなセリフを子ども(妻にも)に言いたくない
    • 何でもできるだけの事をしてあげたい
  • 私自身が子ども好きなのもあり、いっぱいお世話したい
    • 姪っ子が2人居り、週末に小さい頃はちょこちょこ面倒見る事があった

育休までにやったこと

勇気を持って育休取得宣言をしました。
でも、育休中は法改正対応が進まない…と、なると先述のように色々とヤバいです。
そうならいように立ち回る必要があります。
育休までにこんな事に取り組みました。

作戦会議

まず名前が良いですね!作戦って何か色々練って面白そうな感じのする会議名です。
自分が法改正対応で今まで主に担当している部分の棚卸し的な事をしました。
その中から大きく引き継げるもの、復帰後に自分で対応するもの、を分類していきました。

引き継ぎ

今まで自分がメンテしていた所となると、改修の勘所は身体が覚えているような感じではあります。
そこを引き継いでいただく事になるので改修の勘所を伝えなければなりません。

どうやって引き継ぐか?

まず前提として、フルリモートワークで日々の業務を行っています。
実際に口頭での説明よりコーディングした方が理解度も高いのでは、と考えると有力なのはモブプログラミングかな、と判断しました。

モブプログラミング

教わる側が実際に手を動かす、というのは目で見て学ぶより効果的なのは自身でも感じるところです。
始める際は、今回はこんな事をやります、という お品書き を準備した上で進めました。


お品書き
image.png

ドキュメントとして残すことで、以下の効果を狙いました。

  • やる事を事前にイメージして着手する事で記憶の定着度合いを高める
  • メモる手間を取らずに集中できる
  • 後で見返しができるので、忘れても思い出しがしやすい

これを1日1時間程の枠で3日間実施しました。

もう少し回を重ねておけるとより良かったのですが、妻と産まれた子を迎えに行くタイミングが来たので「すみません、後はよろしくお願いします!」という事で1ヶ月の育休に入る事となります。

引き継ぎメンバーからのフィードバック

この記事を書くにあたって、フィードバックを頂きそびれていることに気づきました。 :sweat_smile:
記事公開の前日に急遽いただきました。ありがとうございます。 :bow: :bow:

はフィードバックをいただいての感想になります

良かった点

  • モブプロで1例を一緒に実装して頂いたこと(ここは大きい!!!)
    • ※評価いただけてホッとしています :grinning:
    • ※可能であれば、直接同じモニターを同じ場で見ながらが一番良さそうですね
  • 上記の中で事前にやるべきこと、関連資料確認方法、動作確認箇所や方法を示して頂いていたので、実装時の漏れは少なかったこと
    • ※「お品書き」の準備の時点では、リストアップしきっていたつもりでしたが、いざ始めて見ると説明の最中にあれも、これも、みたいなのがありました。事前にロープレしたら防げたかも

改善点

  • (ドメイン知識は経験していくしかないと思う)
    • ※コアな箇所になればなるほどドメイン知識が求められますね。コアな部分をお手伝いいただく際は、法改正対応入る前からいくつかの課題を対応して頂くなどして、あらかじめドメイン知識を高める期間を設けられると良さそうです
  • 設定ファイルやクラス間の関係図の様なものがあれば、参画したばかりの方も最初のコストが下がるかと思いました
    • ※ご指摘の通りですね。ドキュメントの拡充は、新たな参画メンバーにもメリットが大きいと思います

育休中の奮闘記

全てが初めてで、覚える事・やる事いっぱいですね。※今もですが

お子様の居るご家庭だと、既にご経験された事もあるかと。
また、そうでない方は経験談の1つとして読んでいただければ。

産まれてすぐの赤ちゃんの行動 :baby:

大きく分けて3つかなと思います。

  • 寝る
  • 泣く
  • ミルクを飲む

寝る :sleeping:

寝ます。とにかくよく寝ます。
トータルで見ると、1日の大半は寝ています。

泣く :sob:

起きたら大体泣きます。
泣かれたら最初は何が要因で泣いているのか?となるわけですが、大半は

  • お腹が減った
  • おむつを替えてほしい

このどちらかに該当すると思います。

ミルクを飲む :baby_bottle:

飲む、といっても最初の方は1回が40mlとか大人からすればごく少量です。
1回が少量で回数が多め、というイメージですね。

粉ミルクを作った事ある方はご存知かと思いますが、一定の工程を踏む必要があります。

「粉ミルクを低い温度で溶かすとどうなる」でGoogle検索

調乳の際にはいったん100℃以上に沸騰させたお湯を、70℃まで冷まして粉ミルクと混ぜます。 100℃に近い高温のお湯では、栄養成分のうち一部が熱変性をおこすなどの可能性があるためです。 一方70℃よりも低い温度では、もしもクロノバクターサカザキ菌などの雑菌が発生していた場合に病原体となり危険です。

70℃を狙う :thinking: 難しいですよね。

ミルクを飲ませようとするタイミング的には既に泣いている事が多いです。
夜中(特に深夜)だと、ご近所にも気を使うところなので尚更スピード感が求められます。
そんな訳で1~2週間くらいで早々に調乳ポットを買いました。神アイテムです。

親はどう立ち回るのか?

授乳の間隔は、最初3時間おきと言われています。
飲んだらすぐ寝て大体3時間経ったら起きて泣いて、の流れが続く感じです。

親の就寝・起床について

子どもが寝ている時に合わせて寝るとした場合、どうしても3時間足らずの細切れの睡眠になります。最初はそれでやってみたのですが、日に日に睡眠不足が身体にきてしまう事態に。
このままではマズい、という事で睡眠は6時間確保しようという方向性にしてみました。

  • 妻:21~3時
  • 私:3~9時

大体こんなイメージです。
9時起きなのは、復帰した際を想定して仕事直前まで睡眠を取るためです。
通勤時間ゼロというのはリモートワークの強みですね。

調乳について

調乳ポット購入前は、毎回(推定)70℃のお湯を作っていました。
その温度では大人でも飲めない熱さなので、人肌まで冷ます必要があります。
冷水で哺乳瓶の外を冷やしてみたり、ボウルに保冷剤でキンキンに冷やしたところに入れてみたりと色々と試行錯誤するわけですが、冷めるまでどうしても一定時間がかかってしまいます。

では、泣かれる前にミルクを作って準備しておくのはどうか?という育児経験が無かった故の考えに至ったのですが、作ってから2時間で消費期限が来てしまうという現実が。

参考例:「明治ほほえみ」の調乳方法
https://www.meiji.co.jp/baby/club/category/study/milk_powder/st_milk_powder281.html
image.png

最初の頃は、煮沸した湯冷ましを足すような事をしていなかった(さじ加減が不安だった)ので、悪戦苦闘したところです。

育休明け

さて、育休明けた時は法改正対応真っ只中にあります。
1日のタイムスケジュールはこんな感じでした。(育児日記読み返し)

タイムスケジュール

0時:ミルク、おむつ交換
3時:ミルク、おむつ交換、就寝
5時:ミルク、おむつ交換
8時:ミルク、おむつ交換、起床
9時:業務開始、おむつ交換
10時:おむつ交換
11時:ミルク、おむつ交換
12時:お昼
14時:ミルク、おむつ交換
17時:ミルク、おむつ交換
19時:休憩&晩ごはん
20時:ミルク、おむつ交換、沐浴
22時:退勤
23時:ミルク、おむつ交換

日中のミルクやおむつ交換は、仕事の合間を見て手伝う感じでした。
生後1ヶ月だとまだ寝返りとかはしない時期なので、おむつ交換自体はしやすい方かと思いますが、ミルクと共に頻度が多いので片方がミルクの準備している間にもう片方がおむつ交換、といった感じで連携してました。

復帰後のキャッチアップ

復帰後は、まず改正対応の進捗状況の確認から入りました。
予め見えている改正対応の内容をリスト化して取り組んでいたのもあって、どれができていてどれがまだなのか、の確認がしやすかったです。

確認すると、サービスコード表(介護の報酬内容がコード化されたもの)の対応がまだでした。
それにより手分けして進めている部分のテストができていない状況でした。

この対応自体は、自分で復帰後に対応するつもりで居ました。とは言え、ボリュームと一人で進めた場合の対応完了見込みを考えた場合、ボトルネックになると見て上長と手分けして対応しました。

反省点

育休入る前にこの対応方法についても引き継ぎができていたら、手分けして進めている部分のテストも都度できて不具合修正までの期間を短くできたのではないかと思います。

育休取ってみてどうだった?

一言で言えば、凄く貴重で濃密な1ヶ月でした。
想像以上にお世話が大変で、一人に負荷がかからないようなるべく分担して取り組んで何とかなった感があります。
ミルク飲んで眠っている姿を見ると一日の疲れも吹っ飛ぶ勢いです。

復帰してからも仕事の休憩タイミングでお世話をしていますが、この1ヶ月でしっかりお世話のスキルが付いたので
妻の負担も少しは軽くなっているのではないかと思います。

全体を振り返ってみて

法改正対応、引き継ぎどちらにも言えるのはダンドリが重要である、という事を再認識しました。
場当たり的に進めてしまうと、全体のスケジュール感が見えない、進め方が適切かどうかの認識合わせが不十分になる、といったリスクが出てきます。タイトなスケジュールでの対応であれば、尚の事と思います。

終わりに

忙しい時期に育休を取らせていただきました。
会社、チームメンバー各位に改めて感謝です。

長文のお付き合いありがとうございました。

11
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
11
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?