Django のプロジェクトのテストを並列実行してとりあえず2倍高速にした
結果
Django のプロジェクトのテスト実行時間が、 GitHub Actions 上で 10min 超えになっていてつらみが出てきていた。
のを、 manage.py test
の --parallel
オプションを活用することで実行時間を約半分に短縮できた。
やったこと
Django のプロジェクトでおそらくよくお世話になるだろう manage.py test
には --parallel
オプションがある。
読んで字の如くであるが、このオプションを渡すだけで実行環境のコア数分並列実行をしてくれて便利。
Django のテストにおいてはデータベースにべったり依存したテストコードを書くことも多いと思うが、このオプションを渡すと起動時にワーカ分のテストデータベースを自動でいい感じに作ってくれるので、 並列実行におけるデータベース周りへのケアをあまり気にしなくて良くなる。
... Creating test database for alias 'default'... Cloning test database for alias 'default'... Cloning test database for alias 'default'... Cloning test database for alias 'default'... Cloning test database for alias 'default'... ...
自前で並列実行されることを想定されていない共用されると破綻するリソースがあるときは別途対策を入れる。
自分が今回扱ったプロジェクトにおいては、「一時ディレクトリ」「Elasticsearch のインデックス」があった。
この例においてはとりあえず共用リソース名の末尾に f"-{os.getpid()}"
を付与してワーカ毎に異なる名前付けを行うことで回避するようにした。
その他、 --parallel
オプションを使用する上で tblib
などパッケージをインストールすることを求められるケースがある。
これらの工夫で、冒頭のように一定(自分の事例では 2 倍)高速になるなら儲け物ではないだろうか。
組織を考慮してアーキテクチャとシステム運用を改善する
前回の記事で軽く触れていますが、現職 Ubie では症状検索エンジン「ユビー」の、リアーキテクチャを計画しています。
さらに冒頭で触れたアーキテクチャ図は我々の理想にはあまり沿っておらず、特に肥大化している FE 、 BFF 部分に関してはモジュラーモノリスに置き換えていく構想もあります。このようなリアーキテクチャ活動にどうシステム運用を装着していくかも課題の一つになっていきます。
本記事では特にこの BFF 部分に言及しますが、リアーキテクチャの方針としてモジュラーモノリスへの移行を検討しており、実現に向けた検証が今月から始まっています。 この取り組みが功を奏せば、前述の記事で言及した信頼性向上のためのアクションが取りやすくなるのはもちろんながら、プロダクトの開発生産性も向上することができるでしょう。
合わせて考えるべき組織の話
モジュラーモノリスとして引き合いに出されるのはやはりマイクロサービスアーキテクチャでしょう。 マイクロサービスアーキテクチャでは典型的にはドメイン毎に分割されたサービスを持ち、サービス毎に異なるチームで開発・デプロイ・運用を行えます。 ここでよく、マイクロサービスをどう切るかがが問題となり、コンウェイの法則に従いマイクロサービスに関わる組織をどう設計するかへ波及します。 アーキテクチャとしてはよりシンプルで開発・ネットワークコストの少ないモジュラーモノリスでも、モジュールをどう切るかの問題は発生して、ひいては組織をどうすべきかの問題から逃げられません。
組織に関する課題を考える上で、 Ubie においてはホラクラシーの導入などの効果により各メンバーが組織に対して強い関心を払っているのが効いてくると感じています。 誰かが組織をいい感じに整えてくれるのを待つ(あるいは自分がいい感じにして整えたものを皆に下ろす)のではなく、自発的に組織課題に向き合うメンバーばかりが揃っています。 それゆえモジュラーモノリスへのリアーキテクチャとそれに伴う組織への影響も、独りよがりなものにならず意見を反映させた形に持っていきやすいです。
一方で Ubie ならではの難しさもあると予感しています。 Ubie のプロダクト開発組織ではチームトポロジーの導入が進んでおり、実際に症状検索エンジン「ユビー」を取り巻く組織構造はチームトポロジーの考え方を反映したものになっています。 (ちなみにチームトポロジー導入前は、組織構造が大きく変わりプロダクトに及ぼす影響が甚大で、たとえばある機能に関心を払っていたチームが解散して誰もオーナーシップを持っていない状態になるなどの問題も起こっていました)
チームトポロジーの導入により明確に長生きすべきストリームアラインドチームが可視化されました。 一方で Ubie のプロダクトはまだまだ発展途上にあり、プロダクト開発も激しさを増していきます。 これを支える組織構造も引き続き、安定した箇所はありつつも変化が激しい箇所も存在し続け、チーム間のコミュニケーションも刻一刻と変わっていきます。
組織を意識しながらリアーキテクチャを進める
コンウェイの法則によると、組織のコミュニケーション構造はシステムの設計に影響を及ぼします。 チームトポロジーに従って安定を見せた箇所はありますが以前としてコミュニケーション構造は変わりやすく、リアーキテクチャではこれを念頭に置いた上で行えると良いと考えます。 (まあこの辺の変わりやすい性質を考慮してモジュラーモノリスという選択肢を選んでいる側面もあり、変化に合わせて柔軟にあるべきアーキテクチャを更新するのはありそうですが)
冒頭で述べた通りリアーキテクチャではプロダクトの開発生産性を改善したく、実際にプロダクト開発に携わるチームに価値を届けなければなりません。やっていくしかない!
最後に、アーキテクチャと組織の両面を意識しながらプロダクト開発を邁進できる仲間を圧倒的に募集中ですので、何卒何卒!!!
症状検索エンジン「ユビー」の共通基盤を支えるシステム運用改善活動
こんにちは、syucream です。最近は業務で、症状検索エンジン「ユビー」 のプロダクト開発に携わっています。
お陰様で症状検索エンジン「ユビー」はユーザ数も伸びて事業的にも重要なプロダクトとなってきています。プロダクトの成長に伴い、関わるチーム・エンジニアも増えて活発に機能開発がされています。一方で現在のスケールが見えてきたフェーズにおいて、今まで多少雰囲気でシステム運用してきたことの反動も起こっています。本記事ではシステム運用の観点で直近やってきたことやこれから取り組もうとしていることについて記述します。
職人芸での運用、カオスなエラー捕捉体制、低いオブザーバビリティ
今年初め頃はまだまだ属人性の高いシステム運用を行っていました。何かトラブルが発生した場合に、感度が高いエンジニアが勘や職人芸で対応しているシーンが多々ありました。システム運用はやや職人芸が輝く性質があるとは思われますが、属人的であるゆえプロダクトがスケールし始めていることを考えるとこのバス係数が低い体制は不健全です。また感度が高い特定のエンジニアが当事者意識を発揮しすぎてあらゆることをすることで、そのメンバーの燃え尽きや他メンバーの(システム運用における)当事者意識を育むチャンスの毀損など、長期的に見て様々なマイナスの影響もあると考えます。
さて、以下に症状検索エンジン「ユビー」を支えるシステムの概略図を示します。(ここでは雰囲気が掴める程度まで簡単にしていますが)この図において FE・BFF・core BE は機能を継ぎ足し開発されていき肥大化してきています。加えてこれらのうち特に FE・BFF は複数のチームが関心を持っており活発に開発されてもいます。その裏側はややマイクロサービスアーキテクチャに倣ったような思想のもとドメインごとに基盤系サービスが分離された状態で配置されています。このアーキテクチャがベストかと言うと全くそうとは考えておらずリアーキテクチャプロジェクトが進行してはいるのですが、システム運用を考えると現状にも十分に目を向けなければなりません。
システム運用体制は基本的な下地は整っているのですが、細部は詰まりきっていない状態でした。例えば、症状検索エンジン「ユビー」を支えるサービス群では Sentry でエラーを捕捉可能にしているのですが、捕捉はされるものの放置されるエラーが多く混沌としているのも問題でした。とりわけ FE はエラー量も多く愚直にトリアージするのは不可能な状態です。またオブザーバビリティが低く、どこで何の問題が起こっているかを迅速に把握するのが困難になっていました。
一歩進んだシステム運用体制へ
プロダクトの成長に合わせて、システム運用も完璧とは言わずとも現状より一歩先に進みたいものです。そのためにまず目指したのが属人性の低減です。
従来、属人的な職人芸で特に支えられてきたのが Sentry で捕捉していたエラーです。しかしカオスな状態でそのまま活用するのは困難です。これに対して以下の軸で整理を行いました
- 特に有効活用できそうな BFF のエラー整理
- 新規エラーに限定した通知
- エラー数の監視
まず BFF のエラー整理について。前述の通り比較的活発に開発が行われているのは FE と BFF です。この中で FE はユーザの利用環境に依存してバリエーションが非常に豊かなエラーが発生する一方、 BFF の方はバリエーションは定まっています。これに着目して、まず BFF のエラーをトリアージして特に立ち向かうべきエラーを明らかにしていきました。この時のトリアージ方法としては以下の記事を参考にしました。
次に新規エラーの通知です。 Sentry のアラート機能では、 Sentry 上で初出と判定されたエラーかどうかを条件にできます。これを用いて「初出のエラーのみ Slack に通知する」ことを実現しました。例えば何らかのリリースを行った直後に Slack に通知が来るようになったのならリリース内容を見直すといった活用が可能になります。
Sentry の初出かどうかの判定はエラーが既存のものと同じグループに属するかの判定で行われ、これが期待に反する場合もあります。そのような場合には Issue Grouping の記述を参考に Fingerprint Rules を追記するなどの対応を行います。
また、 Sentry のアラート機能ではエラー数が閾値を超えた時に通知することができるのでこれも合わせてセットしています。前述の新規エラー通知では把握しきれない、既出のエラーが大量発生しているようなケースもこれで拾えます。 これらにより、 Sentry で捕捉しているエラーがカオスな状態でトリアージがしきれていない状態でも、一定はその中から価値ある洞察を得られています。
また、基礎的なところからですがオブザーバビリティを高める活動にも着手しています。 Ubie のシステムのインフラは GCP に乗っかっていることを加味して、親和性の高い Cloud Trace を活用する、あるいは近しいところで Sentry の Profiling 機能を使い始めています。
アーキテクチャがまだ複雑過ぎると言うほどではないにせよ、人目でぱっと把握できるレベルは通り過ぎはじめています。その中で、どの処理がどこで遅くなっているかなど状況を把握できるデータが増えることの重要性は増してきています。 この基礎的なオブザーバビリティ改善活動によって、例えば N+1 を解決してレイテンシを安定させた事例などもでてきています。
ここまででシステム運用を簡単にする最低限の下地は改善してきているものの、これを一部メンバーで回している限りは属人性課題は改善していきません。これへの対処はまだ草の根的に模索中なのですが、
- アラートが届くチャンネルに関心を持ってくれそうなメンバーを広く巻き込む
- 各メンバーが担当するシステムに当事者意識を持てるようなアーキテクチャ・システム・ガバナンス上の工夫をする
を試しているところです。これも模索中ではありますが、粗々でも今あるツールを有効活用して異常時に多人数でコトに当たりインシデントハンドリングを以前より迅速に行えています。
これから目指したいところ
ということで、プロダクトの成長に寄り添いシステム運用も改善する活動を紹介しました。もちろん現状が理想の形ではなく不足は多々ありますし、プロダクトがさらに成長することで要求も高まります。それにどう組織として立ち向かうかは引き続き考える必要があります。 Ubie のプロダクト開発組織においてはちょうど数ヶ月前に名前を「Ubie Discovery」から「Ubie Product Platform」に変更してより長期に渡るプロダクト価値最大化を目指すようになりました。このような組織レベルでのマインドの変化にも合わせてシステム運用の登り方もアップデートしていきたいものです。
個人的には、さらなるオブザーバビリティや長期的にシステム運用に向きあるガバナンス整理、妥当な SLO の策定と運用、持続可能なトイル対処体制などやれることはまだまだあると感じています。さらに冒頭で触れたアーキテクチャ図は我々の理想にはあまり沿っておらず、特に肥大化している FE 、 BFF 部分に関してはモジュラーモノリスに置き換えていく構想もあります。このようなリアーキテクチャ活動にどうシステム運用を装着していくかも課題の一つになっていきます。
最後に、 Ubie ではシステム運用にも知見が豊富なソフトウェアエンジニアを募集しております!プロダクトの成長に伴いやることは枚挙に暇がありません。ぜひ一緒にやっていきませんか!少しでもご興味があれば、まずはカジュアル面談からでも、何卒!!
自社のエンジニアとラフに話せるSlackワークスペースをクローズした
以下のように紹介していた、 Ubie のエンジニアとラフに話せる Slack ワークスペースを運営していたのですが、このたびクローズしました。ご参加頂いたみなさま、ありがとうございました。
ユビーに興味があるエンジニアの人たちとユビーの中の人でもっとラフに非同期で話せる場所が欲しいな......と思ったので、このたびそれ専用の Slack ワークスペースを作ってみました!🥳ご興味がある方、以下フォームより参加表明を!何卒何卒〜〜!!✨✨✨https://t.co/QHChQPIuLK
— しゅー くりーむ (@syu_cream) 2021年12月16日
なぜやっていたのか
- エンジニア採用の促進
- プレゼンスの向上
- (あわよくば) 技術交流によるナレッジシェア
を目的としていました。 特に採用のための施策としての色が強く、いわゆるカジュアル面談よりさらにカジュアルに交流できるコミュニケーションパスを用意したかった次第です。カジュアル面談は会社とその雰囲気を知るのに有効ですが、同期コミュニケーションの日程調整をしたり心理的ハードルが高く感じられる場合もあると踏んで、よりラフに非同期コミュニケーションを可能にしたかったのでした。
なぜやめるのか
運営がうまくいかなかった為です。何か重大な問題が発生した訳ではないのですが、ただただコミュニティ運営が疎かになりコミュニケーションがうまく発生しなかったのでした。
コミュニティ運営はそれなりの熱意と時間を、長期的に継続して注ぎ込まないとワークしないと思われます。しかし現実、業務でこれを行うと会社の状況や業務で抱えるタスクの都合でリソースを回しきれないこともあり、十分な活動ができませんでした。またこのコミュニティの運用体制とそこから得たい成果を明瞭にし、改善を回すのもやるべきだったと反省しています。
おわりに
というわけで、ワークスペースを閉じることにしました。着眼点は悪くはないと考えているのですが、打ち手とその全体設計は改善の余地があったかと考えております。またどこか別の場所でおもしろコミュニケーションパスが爆誕することがあれば、より活発に皆様と交流できると嬉しいです。
ちなみに Ubie では引き続き絶賛エンジニア募集中です! Slack コミュニティはなくなってしまいますが、ユートラのカジュアル面談募集や情報発信、もしご興味がおありでしたらご覧いただけると嬉しいです!
GitHub Actions と GitHub Packages を使って、継続的に社内向け gem をリリースする
こんにちは、 syu_cream です。普段は Ubie でプロダクト開発エンジニアをやっています。本日は業務で構築した社内向け gem の継続的なリリースを行う仕組みを紹介します。 GitHub Actions & Packages の組み合わせは問題にハマると原因究明が難しいことがあり、また意外にも世の中に情報が乏しいように思えます。この情報がひとつの参考になればと思います。
はじめに
Ubie では、以下記事で紹介しているように新規に開発するサービスを Go か Node.js で、通信プロトコルを GraphQL か gRPC で実装する方針を進めています。
最近、僕の所属チームでも新規サービスを追加したい状況に直面し、上記記事の基準を加味して NestJS による gRPC サーバを実装することにしました。現在 Ubie では Protocol Buffers による gRPC のサービスやメッセージの定義と付随するコード生成等のエコシステムは中央集権的なリポジトリが担っています。ここで NestJS で使いやすいコードは既に GitHub Packages で社内向け npm パッケージとして利用可能になっていました。しかし今回開発する gRPC サーバに対する想定クライアントとして昔から存在する Ruby on Rails 実装の REST API サーバがあり、他言語に従い Ruby 向けのコード生成も行いたくなりました。
このような経緯があり、本記事タイトルの「GItHub Packages を使って社内向け gem をリリースする」のを、属人性を排除しつつ簡素な構成で行うため GitHub Actions で完結させたい次第になりました。
GitHub Actions から社内向け gem をリリースする
今回まず Protocol Buffers, gRPC のコード生成をする必要があったのですが、ここは Buf を使いあまりハマることなく実現することができました。以下ページを参考に、 Ruby 向けの gRPC/Protocol Buffers プラグインを導入して buf generate するだけです(まだ複雑なことをしていないが故に問題にハマってないだけの可能性は否めないですが)
本題の gem のリリースですが、基本的には以下ドキュメントに従うことになります。
まず gemspec を用意します。(一部置換を含みつつ抜粋)今回 GitHub のリリースタグからバージョンコントロールしたいので、環境変数から注入可能にしています。また allowed_push_host
メタデータは gem push する先にを指定しておきます。 lib/**/*.rb
には buf generate で生成されたコードが配置されている想定です。
Gem::Specification.new do |spec| spec.name = "..." spec.version = ENV["PACKAGE_VERSION"] spec.authors = ["..."] spec.summary = "" spec.required_ruby_version = Gem::Requirement.new(">= 2.7.0") spec.files = Dir["Gemfile", "lib/**/*.rb"] spec.require_paths = ["lib"] spec.metadata["allowed_push_host"] = "https://rubygems.pkg.github.com/<namespace>" spec.add_runtime_dependency "grpc", "~> 1.x" end
次に GitHub Actions のワークフローを組みます。実際に作成したものは以下のようなものになります。(一部置換を含みつつ抜粋)
gem push をするにあたり Actions に Packages に書き込みを行う権限が必要です。リポジトリの設定 ( Settings > Actions > General > Workflow permissions ) で書き込み権限が付与されているかワークフローの設定で permissions.packages: write
が必要になるはずです。 また公式ドキュメントを参考に gem push する際の認証情報を渡します。
ruby: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: Setup Buf uses: bufbuild/buf-setup-action@v1 with: github_token: ${{ github.token }} - name: Setup Ruby uses: ruby/setup-ruby@v1 with: ruby-version: '2.7' bundler-cache: true - name: Generate code run: | buf generate .. - name: "Define PACKAGE_VERSION" run: | echo "PACKAGE_VERSION=${{ github.event.release.tag_name }}" >> $GITHUB_ENV - name: Build run: | gem build <gem name>.gemspec - name: Publish artifact run: | echo ":github: Bearer ${GITHUB_TOKEN}" >> ~/.gem/credentials chmod 600 ~/.gem/credentials gem push --key github --host https://rubygems.pkg.github.com/<namespace> <gem name>-${{env.PACKAGE_VERSION}}.gem env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
このワークフローではそのために明示的に PAT 払い出しをする必要がなく、 GITHUB_TOKEN で簡潔に構成できます。 それゆえ GITHUB_TOKEN 起因の認証エラーにハマることがあるかもしれませんが、トークンの渡し方や付与されている権限を確認しながらトラブルシュートしていくことが求められます。
社内向け gem を利用する
gem がリリースされたら、利用する側も作り込んで行きます。これも基本的に公式ドキュメントにあるように、 Gemfile にリリースされた gem への依存を書いて
source "https://rubygems.pkg.github.com/<namespace>" do gem "<gem name>", "<version>" end
bundle config で source にアクセスする時の認証情報をセットしておきます。これで bundle install でリリースされた社内向け gem をインストールできます。
$ bundle config https://rubygems.pkg.github.com/<namespace> <GitHub のユーザ名>:<GitHub の PAT>
このやり方は GitHub Actions 上で行いたい時障壁になるかもしれません。その場合は環境変数を介して渡すことも可能なようです。
- uses: ruby/setup-ruby@v1 with: ruby-version: ${{ env.RUBY_VERSION }} bundler-cache: true env: BUNDLE_RUBYGEMS__PKG__GITHUB__COM: ${{ secrets.GITHUB_TOKEN }}
おわりに
というわけで社内向け gem を GitHub Actions & Packages でリリース・利用する事例について紹介しました。 GitHub Actions、 Packages は上手く使えれば簡潔で使いやすい開発基盤を構築できると思うのですが、問題にハマるとストレスフルな状況になりがちかなと思います。本記事がひとつの事例としてお役に立てば幸いです。
育休復帰後 3 ヶ月を振り返って、仕事とプライベートの両立ハードパーツ
ライフワークバランスが重視される昨今、そのバランスを保つのって簡単なんでしょうか?他人が多くを語らない詳細は、見えないからこそ想像を掻き立ててしまって自分には手が届かない理想的な生活を描いてしまいそうですよね。でも実際は全然そんなことはないはず。 本記事では、僕が直近 2023 年 1 月から育休復帰して 3 ヶ月を振り返って、仕事と育児のバランスの実情や難しい点を綴ってみます。
育児にコミットしながら仕事に復帰すること
自分の家庭では、自分と妻の実家の手助けはほとんど得られず自分たちで育児を成立させる必要があります。 また主に家計を支えるのが自分となる都合、妻になるべく育児に集中して欲しい期待感もでてきます。 しかし妻が産後思いのほか体調が優れないことが多く、育児をワンオペで回し続けるのは負担がかかりすぎます。 妻にばかり負担を掛けぬよう、なるだけ自分も育児に参加して負荷分散する必要があります。なるべく仕事の出力を維持しながら。
幸いなことに現在の職場 Ubie(ユビー)株式会社 では リモートワーク が可能です。出社する機会はあるのですが、あまり無理なくリモートワーク主体で働くこともできます。 ここ 3 ヶ月はほぼリモートワークで、仕事をしながらも子供がミルクを欲しがったり不機嫌になる状況でスポット的に仕事を中断して育児の時間を設けるようにしました。 この柔軟な勤務状況は、 裁量労働制 で働けることも手伝っている結果です。一部仕事を抜けてしまった分を他の時間で補填しやすいのです。 また Ubie では自分と同じく 子供を育てながら仕事しているメンバーも数多く 、仕事しながらも育児も大切にすることへの抵抗感も少ないことも助かりました。
一方リモートワーク主体で仕事をしていると、オフラインコミュニケーションの機会が少なくなります。 Team Geek という書籍に「フェイスツーフェイスの帯域を過小評価してはいけない」という表現が出てきますが、まさに制限されたコミュニケーションパスで仕事していたような心地ではありました。 その制限により、オフラインで誰かと会って話せていれば獲得できていた情報の欠如などを引き起こしていたかもしれません。
仕事と育児以外のもの
育休から仕事復帰する以上、仕事で成果を上げたいものです。しかし育児にもコミットしたい。 この 2 要素を天秤にかけることはよくあると思うのですが、当然人生には他の要素も絡んできます。
自分の反省として、仕事と育児以外のものをだいぶ劣後させてしまったことがあります。
優先度的には、 仕事 >> 育児 >>>>> 妻のこと >>>> 自分のこと
みたいな構図になってしまい、妻との関係性の悪化や自分自身の不調を招いてしまいました(そんなに致命的ではないですが)
短期的には仕方ない部分もありつつも、妻と自分、子のみならず親のコンディションにも気を配るべきでした。
お金
子育てにお金がかかるのは本当にそうで、まず赤ちゃんの為のグッズに少なくない金額がかかります。 それで済んでいればよいのですが、僕の家庭ではベビーシッターやヘルパーさんを頼んで自分と妻の負荷軽減と妻の通院を柔軟にできるようにした都合、 1-3 月にそれぞれ 5 万円以上かかるという家計に苦しい状況にもなりました。
これについては正直しょうがないと思っています。 大変かつ他の手段も限られている状況で、お金で解決できる領域があり支払い能力があるならお金で解決してしまう、は一定正解のはず。 幸いなことに 0 歳児で保育園に入れたので解消もされていく、はず。
それでも希望はある
大変なことを列挙するとうんざりしてしまいますが、やはり子供は可愛く癒されるものです。(自意識過剰でなければ、子供が僕に特に懐いている気がする!!) また、子供の圧倒的成長や保育園入園などの節目を一緒に体験していると、人生二週目をやっているような心地というか、刺激が数多くあるように感じられます。
仕事とプライベートの両立はやはり難しく上手に行える気がいまだにしないのですが、現実な落とし所は探っていきたいところです。
ソフトウェアエンジニア子育てログ (3 ヶ月 ~ 4 ヶ月)
引き続き子育てエントリです。前回はこちら。
3.5 ヶ月
この頃から子供が寝返りをするようになりました。 ちょうど 3.5 ヶ月にわずかに満たない頃から、ぎこちないものの寝返り可能になり、 3.5 ヶ月を過ぎたあたりからスムーズに寝返りし始めました。 典型的な赤ちゃんの発達においては 4 ヶ月頃から寝返りをする子が多いようで、それと比較するとやや早いタイミングでの寝返り開始となります。
仕事面では、この頃職場復帰して 1 ヶ月が経過しました。 仕事と育児を両方とも上手くこなすのは、体力的にはギリギリ捌けると感じます。 自分の今の勤務体制がガチガチに決まった時間に働かなければならないものでもないことを生かし、概ね日中〜夕方くらいまで仕事してその後は家事育児のために離脱。やり残した仕事があれば寝る前に少しおかわりするという日々を送っています。 これにより仕事と育児の両方のバランスを取ることはできそうです。注意しないと疲労を延々と引きずってしまいそうですが。 ちなみに私的な時間、たとえば子供が生まれる前にやっていたゲームや読書などする時間までは正直割けず...犠牲になったのだ。
4 ヶ月
3.5 ヶ月頃から開始した寝返りは更なる安定をみせます。 ただし所詮は赤子の限られた体力であり、うつぶせになった状態でしばらく経過すると疲れて泣き始めてしまいます。 泣き始めるものだから仰向けに戻すと、自分で再び寝返りをして、さらに疲れて泣き始める...無限ループかな? 寝返り以外だと、徐々に手を器用に使っておもちゃで遊ぶようにもなり始めました。
仕事面では大きな変化はないですが、やはり出力を上げたい時に悩ましくはなってしまいます。 夕方〜夜は育児のために継続的に時間を割いているものの、その時間も仕事に避ければより進捗するのでは、と考えないかというと嘘になります。 無理して作業時間を捻出しても体力や家庭の平和を損ないそうですし、ライフワークバランスは難しい。
ここから
ライフワークバランスはギリギリ問題にはなっていないものの一定の整理をつけないといけない課題になってきているようにも感じます。 また薄い望みですが子供が保育園に通えるかどうかがそろそろ分かり、通える場合はまた日々の過ごし方、生活リズム、妻との育児上の役割分担など考えることが多々出てきそうです。