ponwinkのひと

子どもとポケモンナインタイルで遊んでるの図 10月に子どもが産まれて、12月下旬より育休を取得しています。 期間は1月上旬まで取ったので、実質少し長い年末年始休暇という感じです。 これを書いてる現在、育休真っ只中ですが、育休について思ったことを書いてみます。 育休の取得について 実のところ、うちの家庭では育休を必要としている状況ではありませんでした。育休が必要か妻に聞いてみましたが、「大丈夫だから働いて稼げ」という回答でした（笑） 自分もまあそうだろうなという感想でした。 そんな中、賞与月の月末に育休を取ると、その月の社会保険料が免除されるという話を聞きました。この免除が、12月の給与と賞与が対象になるというから驚きです。もしかしたら、育休を取ったほうが金額的にお得なのでは？という思いから、育休の取得について本気で考えることにしました。 育休を取って一番困るのが、その間の給料が0になるということです。 とはいえ、育児休業給付金(*1)などの制度もありますが、（自分は期間が短すぎて対象外でした）給与が減るというデメリットが大きく捉えられる印象があります。育児休業給付金の対象という面から、育休を取るときは月をまたがずに最低1ヶ月を目安に取ったほうが良さそうです。 とりあえず、トントンぐらいになりそうな範囲で育休を取得してみようと決めました。トントンであれば金額面に問題がないのと、部署内でまだ育休を取った人がいなかったので、実績を作る意味で先陣を切ることにしました。 育休中の行動について 育休に入ってからですが、普通の土日と同じように過ごしても良くないので、とりあえず家事を率先してするように努めました。主に洗濯と掃除ですね。料理は得意ではないので、ここだけは妻に任せてその間は赤ちゃんをだっこしたりしています。 一番メリットが大きかったのは、妻が外でゆっくり買い物ができることでした。平日の日中に、妻が赤ちゃんを連れて買い物に行くことは大変厳しく（産後ということもありますが）、食べ物はヨシケイ(*2)やイオンのネットスーパーに頼っていました。 あとはちょっとした買い物や用事みたいのが全然できていなかったので、それが一番助かったようでした。 育休を取ったところで、大したことはできないんじゃないかな・・と考えていましたが、そうでもなかったので、今では育休を取ってよかったなと思いま

  「個と組織を生かすリモートマネジメントの教科書」という本を読みました。仕事において、リモートワークがメインになってきた最中、この本のタイトルに目が止まり購入に至りました。 どんな仕事をしているか？ システム開発のエンジニアをしています。３０歳も後半に差し掛かり（アラサーです）、メンバーの管理をする作業をすることも増えてきました。正直なところ、こういった管理作業は得意ではないので、コードをもくもく書いている方が楽しいです。おそらく、ほとんどのエンジニアがそうだと思います。 リモートワークが多くなってから、リアルと比べてメンバーとの距離が開いているのを感じていました。会社で作業していたのと同じようにリモートワークでもメンバーの状況を把握していきたいのですが、なんとなく現状でも出来ているような気がするものの、漠然とした不安を感じていました。 偶然やついでの機会を使ったマネジメント この本の中で使われている言葉ですが、一番共感できたところです。メンバーと偶然トイレなどで会って「そういえば、あのタスクどんな感じ？」とか、遠くからメンバーの作業している様子を見るとか、そういった空気を感じることができなくなる不安はあります。対面の時と変わらず、朝会などの定期的なMTGは行っていますが、それだけではメンバーの雰囲気を把握するには物足りないなぁと感じています。 この本の中では、こう書かれています。 偶然やついでの機会を使って行ってきた情報収集や働きかけを「意図して」起こす必要があります。 マネージャーがそういった場を設けるといったことに限らず、メンバー自身が動けるような環境を作ってあげるという意味も含まれているようです。現状は、雑談メインの自由参加の夕会を設置したりしてるので、ある程度の対策は取れているような気もしています。 リモートワークの下ではメンバーの責任も増す リモートワークで、変わらなければいけないのはマネージャーだけではなく、メンバー自体も変わっていく必要があるという内容です。メンバーの責任の中で「周囲を安心させる責任」という記載がありました。これは、マネージャーに向けて「逐一見守っていなくても、きちんと仕事を進め、成果を上げてくれるだろう」という安心感を与える必要があり、これには同感できます。メンバーは「成果を上げ」「適宜報連相を行う」責任があります。 私も２，３日

12月末で一つのプロジェクトが終わりました。 最後のデイリースクラムの時に、一年目のメンバーが「寂しいですね」と言ってくれました。何気ない一言でしたが、チームをまとめている私としてはとても嬉しい言葉でした。お世辞だったかもしれませんが、それでもうれしかったです。 自分としてはちゃんとうまくチーム作りが出来ているんだろうか、メンバーにとって幸せなチームになっているだろうか、ということがとても心配でした。でも、この一言で少し払拭された気がします。もちろん、思い返すと力不足なところも多々あります。 ここで、どういったチーム作りを心がけていたかについて、個人的な振り返りとして残しておきます。 # メンバーを理解する 自分はメンバーのことを理解できていないと思うことは重要です。理解できているという人は、理解した気になっているだけだと思っています。メンバーのことはメンバー自身にしかわからないということを理解するということです。 かと言って、「お前のことなんか知らんわ」ではもちろんダメです。メンバーの気持ちに耳を傾けてあげるようにします。それが解決できなくても、聞いてあげるだけでも大切なことだと思っています。 # 自分の意見を押し付けすぎない 開発者は、自分的にこうだ！という作り方を持っていて、そこを強く指摘されるのは、あまり良い気分にならないと思います。マジリクのレビューのときは、軽くコメントして、開発者と相談し、この作り方はバグの温床になるなどのよほどの要因がなければ、良しとしています。 # 怒っていないことを伝える マジリクにコメントしたときに、少しきついかな？という書き方になるときもあります。その場合は、マジリクにコメントした上で、口頭で話して説明します。コメントしただけでは、レビュアーが怒っているかどうか、メンバーが判断できないからです。口頭で顔を見て、やさしく説明すれば怒っていないことがなるべく伝えるようにしていました。 # discordのチャンネルに常に入っておく discordの特定のチャンネルに常に入っておくことで、いつでも話しかけやすい環境を作っておきます。会社にいれば、いつでもすぐに話しかけれますが、リモートが多くなった今、それに合わせた環境を作ることも大切です。実際にこれは好評でした。（よく入り忘れてます、すみません） # 部下は上司の顔色を伺っている