👶

子育て中のエンジニアの勉強との向き合い方

に公開

はじめに

ぺんぎん(@jitepengin)です。
今回はいつもの記事と趣向を変えて、子育てと勉強をどう両立するかについて考えてみたいと思います。

昨年、子どもが生まれてから生活の優先順位が大きく変わりました。
それまでは仕事が終わってから勉強をしていましたが、今はごはん、お風呂、寝かしつけ、家事とあっという間に時間が過ぎていくようになりました。

育休明けに管理職への昇進が決まり、マネジメントをしっかりとやったうえで、技術を諦めずにキャリアをどう進んでいくか考える必要もあり、悩む時期もありました。

特にデータ基盤周りは技術の進歩も早く、学ぶべきことも広範にわたるため、技術のキャッチアップや学びを止めたくはない。とはいえ、子どもと家庭を優先したい。
そんな葛藤の中、どうやってバランスを取っているのか、実体験をもとに紹介します。

※ちなみに、最適解はまだ見つかっていません。気合と試行錯誤でなんとかやっています。

勉強時間ではなく、やったか・やらなかったか(イチゼロ)で管理する

管理職になると日中はほぼ「人のための時間」になります。
組織マネジメントやプロジェクトマネジメントの他、見積もりや提案作業、メンバーの目標設定、評価や定期的な1on1、そして雑多な業務。
わたしの場合、データ基盤周りの技術選定や技術支援もやることもあるので、業務内でのキャッチアップはほぼ不可能となります。
そして、前述したように子どものお世話や家事もあるので、終業後も時間があまり確保できません。

そういった中で、一日一時間やるだとか時間で目標を管理すると、なかなかうまくいかず、焦りだけが募っていくことになります。
そこで意識しているのが、「1日◯時間」など時間ではなく、やったか・やらなかったかの「イチゼロ」で管理することです。
たとえ5分だけでも本を読んだ、メモを書いた、コードを書いた。そんな小さなことでも「今日はやった」と言えるようにしています。
完璧を求めず、「少しでも進めた自分、えらい!」と認めることで、焦りがなくなります。

勉強時間は早朝・深夜で確保

イチゼロ思考が重要とは言ったものの、ある程度まとまった時間は必要となります。
前述したようになかなか時間が取れない中、自由に勉強できる時間はどのタイミングでしょうか。
わたしにとって唯一の自由時間は、早朝と深夜です。
特に早朝は頭がスッキリしていて集中しやすく、短時間でもインプットの効率が高くなります。
時間は限られているので、「かけた時間」よりも「質」を重視するようにしています。
わたしの場合は下記のようなインプットを行っています。

  • O’Reilly Onlineで技術書を多読
  • データエンジニアリング関連のCommunityを覗く
  • Substackの配信を読む
  • AWS Community BuilderのSlackと投稿されたブログを読む

隙間時間を有効活用

通勤中、昼休み、子どものお昼寝中など、ちょっとした隙間時間も大切な勉強時間です。
前述のインプットはこの時間にこなすことも多く、スマホ一つでできることを準備しておくと、学びの総量が全然違ってきます。
ここでも大事なのが完璧を求めすぎないことです。

アウトプットも完璧を求めず、断片的に

以前は、まとまった時間を取って技術検証をしたり、記事を書いたりしていました。
でも今はそのスタイルは現実的ではありません。
そこで、私は以下のようにスタイルを変えました。

  • 隙間時間でNotionなどに記事のアイデアをメモする
  • 早朝深夜の時間が確保できそうなタイミングで検証を行う
  • 検証したネタをZennにまとめる

「アウトプット=まとまった時間が必要」という思い込みを捨て、断片でも記録しておけば、あとから形にできると思考を変えました。
「完璧な成果を出そう」とするより、「メモでもいいから残す」ことが継続の秘訣です。

とはいえ、断片的に書いたアイデアがどんどん溜まっていく一方なので、これは今後の課題です…

技術を諦めない

マネジメントに比重が移ると、技術から離れていく感覚に不安を感じることがあります。
特に技術の変化が激しいデータ基盤まわりでは、気を抜くとあっという間にわからないことが増えていきます。
チームの技術方針に関わる以上、ある程度の肌感覚を持ち続けることが必要だと考えています。
まとまった技術検証は難しくても、技術との接点を意識的に持ち続けています。

今の役割で求められているのは手を動かすことよりも、技術の全体像を把握し、適切な選択肢を提示できる広範な知識、そして技術とビジネスの橋渡しを行うことです。

完全に追うのではなく、少しでも触れるそして、「ソフトウェアアーキテクチャの基礎」で触れられているように「技術的な深さ」ではなく、「技術の幅」でクライアントの課題解決や価値向上につなげることが重要になります。

https://zenn.dev/penginpenguin/articles/753b19ebb55b37

技術者は技術的な深さが求められるが、アーキテクトは技術の幅が重要となり、技術を幅広く理解し、その知識をもとに具体的な解決策を検討することが求められる。

完璧を求めず、イチゼロ思考で今日はやったと言えるだけで十分です。

子どもとの時間はなによりも優先したい

そして何よりも、子どもと過ごす時間は今しかないと強く思っています。
はじめての笑顔、はじめての寝返り、はじめての離乳食、こういったイベントだけではなく、毎日の小さな瞬間は、どんなスキルにも代えがたい宝物です。
わたしは学びたいと家族と過ごしたいがぶつかりそうなときは、迷わず後者を選ぶと決めています。

まとめ

技術も大切。家族も大切。自分のキャリアだって大切。
その全部を諦めず、バランスを取りながら進んでいくことはとても難しいです。

継続のコツはゼロで終わらせないことです。
「できるときに、できることを、学びをゼロにしない」を意識するだけで、気持ちがラクになります。
イチゼロ思考で少しでもやった自分をほめてあげてください。
今日もやったというちょっとした達成感を感じながら継続してみてはいかがでしょうか。

おまけ 2025年の上半期に読んでよかった本

  • Deciphering Data Architectures

https://www.oreilly.com/library/view/deciphering-data-architectures/9781098150754/

  • Building Medallion Architectures

https://www.oreilly.com/library/view/building-medallion-architectures/9781098178826/

  • Data Engineering Design Patterns

https://www.oreilly.com/library/view/data-engineering-design/9781098165826/

  • Apache Iceberg: The Definitive Guide

https://www.oreilly.com/library/view/apache-iceberg-the/9781098148614/

  • データプラットフォーム技術バイブル

https://book.mynavi.jp/ec/products/detail/id=147013

  • AWSではじめる実践データマネジメント

https://gihyo.jp/book/2025/978-4-297-14913-0

そのうちこの記事に追加します。
https://zenn.dev/penginpenguin/articles/9a45913889c21c

Discussion