休むことは、チームのカオスエンジニアリング。育休中のEMが手放した“やらないこと”のトップ画像

休むことは、チームのカオスエンジニアリング。育休中のEMが手放した“やらないこと”

投稿日時:
iwashi / 岩瀬 義昌のアイコン

EM(育休中)

iwashi / 岩瀬 義昌

Xアカウントリンク

「もっと成果を出さなきゃ」「スキルを増やさなきゃ」。そんな焦りに押され、やることを積み重ねていないでしょうか?けれど、本当に働き方を変えるのは“足し算”ではなく、“引き算”かもしれません。この企画では、エンジニアたちがあえてやめたことと、その後に訪れた変化をたどります。ムダをそぎ落とした先に残る、本当に大切な仕事や自分らしい働き方とは。誰かの“やらない選択”が、あなたの次の一歩を軽くし、前向きに進むヒントになりますように。


こんにちは、iwashi(@iwashi86)です。普段は本業として通信事業者のR&D組織にてエンジニアリングマネージャーを担ったり、サイドワークでポッドキャスト(fukabor.fm)や書籍翻訳をしたりしています。ただ、現在は育児休職中でして仕事からすでに半年以上離れ、家族との時間を中心に生活しています。

この記事を読まれている方には、何かしらの理由でこれから長期で仕事を休みたい方もいらっしゃるかもしれません。あるいは育休を取ってみたいけど、仕事を休むことに不安がある方もいるかもしれません。そこで、この記事では育休に入る前に意識していた「やらないこと」を前半で説明します。後半では、育休に入ってから気づいた「やらないこと」に関する価値観の変化を書いていきます。いずれもn=1の事例ではありますが、何かしらの参考になることを願っています。

育休前に意識していたこと

自分がいなくなったら、チームに迷惑をかけるだろうなと思い込みすぎない

育休前に意識していたことの1つは、休んでしまうと誰かに負担をかけすぎてしまって申し訳なさすぎる、と考えてしまう思考を捨て去ることです。これは割と多くの人が考えがちな思考だと思っていて、実際にこう話している人を見かけたこともありますし、私自身もそう思ったことがあります。

ただ、これを気にしすぎていると誰も長期の休みに入れなくなります。なので、まずは自分が抜けてもなんとかなるという前提で考え始めるのが良いです。

もちろん、チーム全体として短期的にはマンパワーが減るので同じ出力を保つのは難しくなります。ですが、中長期で見ればこのような増減を吸収できる組織の方が強いと考えています(それにこういう組織・チームをつくるのがマネージャーの仕事でもあります)。

ただ残るメンバーに負担もあるため、無策で突然いなくなるわけではありません。策はいくつかありますが、ここでは実行すると良いポイントを2つ紹介します。1つは短い期間で実験してみること、もう1つは普段から自分の思考を言語化して伝えておくことです。

短い期間で実験する

自分が不在になった場合、当然のことながら自分がやっていた業務に穴があきます。この穴を見つけて引き継ぎできれば、抜けた後もチーム全体として業務が円滑に回りやすくなります。すぐに思いつく穴もたくさんあるでしょうが、自分ですら意識していないちょっとしたタスクは実際山ほどあるはずです。なので、問題はこの穴をどうやって見つけていくかにあります。

まずその方法として、事前にデスクワークで検討する方法があります。書籍『エレガントパズル』ではカレンダーを使った方法や、チャットやメールを使う方法を紹介しています。具体的にはカレンダーを眺めてみて、そこでの打ち合わせやタスク、役割を書き留めていくのです。これで日頃の業務の大部分はカバーされるでしょう。

ただ、これでも個人的には限界があると考えています。カレンダーには出てこないようなタスクや、メールやチャットを遡って見落としてしまったものが出てきます。

それを見つけるためにおすすめなのが思い切って休んでみることです。これは、チームにおけるカオスエンジニアリング[1]のようなものです。あえて不在になる状況をつくることで穴となる箇所を発見するチャンスになります。また副次的にチームの自律性を試す機会にもなります。いきなり長期で休むのが難しければ、まずは2〜3日ほど連続で休んでみるのも手です。

なお、マネージャーが休むのは別の効果もあります。それは、メンバーが休みやすくなることです。行動は言葉よりも雄弁に伝わります。また、メンバーの中には将来マネージャーになる人も出てくるでしょうが、「以前の上司がやっていたので」とその人も同じ行動を取りやすくなる面もあります。私の以前の上司も、子どもの学校の長期休暇に合わせてしっかり休みをとっていて、「あぁ、そうかやってもいいんだ」と理解して私自身も真似するようになりました。

自分の頭の中だけに考えを閉じ込めない

マネージャーがいない場合に困ることの1つが、チームで判断が必要なものが生じた場合の振る舞いです。権限が明示的に委譲されていればチームメンバー自身が判断できます。しかし、マネージャーの仕事には得てして定常業務から外れた例外がエスカレーションされてくるものです。その際に、できるだけマネージャー不在でも、チームが独自判断して自律自走するために何をすると良いでしょうか?[2]

いくつかの方法がありますが、EMConf 2025のクロージングでお話しさせていただいた「ポエムドリブンマネジメント」はおすすめの方法の1つです。具体的には、頭の中にある考えを、思考過程を含め1ページ程度に書き出してチームに伝えていきます。こうすると、チームに目指す方向性が伝わります。文書の長さはできるだけ画面1枚に収まる程度が好ましいです。短さは正義です。

また、単に文書へのリンクを送るだけではなく、全体ミーティングや1on1など複数のチャネルを使ってあの手この手で補足するのも効果的です。考えというのは全員に一度で伝わることはまずないので、マルチチャネルで繰り返し伝えることも大事です。

なお、思考を言葉にする際、頭の中がまだ整理しきれていない段階ではあえてAIを使わず、自分の手を動かして書くようにしています。「書くこと」と「考えること」は表裏一体であり、意図的にゆっくり思索を深める時間が重要だと考えているからです。効率化が求められる時代においては少し逆行しているかもしれませんが、この言語化のプロセスには時間を使う価値があります。[3]

育休中に気づいたこと

ここまでは、育休に入る前に考えていたことを書いてきました。以降では育休に入って一歩ひいて考えるようになったことを述べていきます。

問題は原因を探って解決しなければならないわけではない

今回の育休期間中に改めて気づいたことがあります。それは、自分自身の思考の癖についてです。振り返ってみると、いずれもソフトウェアエンジニアやエンジニアリングマネージャーとしての経験や考え方が強く反映されていました。

一方、育休に入って半年以上仕事から離れ、家族や地域コミュニティを中心とした生活を送る中で、改めて気づいたことがあります。

それは、そもそもあらゆることを問題として捉え、原因を分析して解決しようとする必要はない、ということです。

私はソフトウェアエンジニアリングの領域で20年近く働いてきました。ソフトウェアエンジニア関連の業務では問題が起きたときに、原因を分析して解決することがよくあります。例えば、システムに障害が発生したら、なぜ障害が起きたのかを調べます。その際は、問題を要素に分解し、原因を特定し、その原因を取り除いていきます。「なぜこうなったのか」「どうすれば直せるのか」を考えていくわけです。

こうした問題解決の考え方は、エンジニアとして非常に重要なものです。しかし、長くそういう仕事をしていると、どうしても思考の癖がついてきてしまい、仕事だけではなくてプライベートでも原因と解決法をつい考えてしまうようになります。

ただ、さまざまな人との関わりの中で改めて実感したのは、人と人が向き合う場面では、問題の原因を掘り下げて解決することが、必ずしも最善とは限らないということでした。話している相手は、解決策を求めているわけではないことも多くあります。また、どれだけ話してもそもそも原因がわからないこともよくあります。

もちろん相手が原因と解決策を考える相談に乗って欲しいのならば、一緒に掘り下げて考えることが有効でしょう。ただ、場合によってはただ共感して一緒にいて欲しいこともあるのです。

無理に元気にさせようとしなくていい

例えば、落ち込んでいる人がいたとして、別の誰かが善意で「元気を出して」と声かけしている光景をみたことがあるかもしれません。この発言自体は有効なケースもあり、励まされる人もいるでしょう。一方で、「悲しんでいる自分はだめなんだ」「早く元気にならないと」とプレッシャーを感じてしまう人もいます。そうすると余計にネガティブに考えてしまって、負のループを生み出します。

明るくて元気な人が絶対的な正解ではありません。悲しかったり落ち込んでいたりして行動できない人であっても、別に何の問題もありません。そのような状態であってもありのままで無条件に受容されて良いのです。

返答を「いや、」で始めない

無条件受容するためにいますぐできるコミュニケーションTipの1つです。私自身がつい出してしまって反省することでもあります。何かを伝えられた際に、つい「いや、〜」という言葉で話し始めてしまうのです。本人は単なる暫定応答のつもりで、必ずしも相手の意見を否定したいわけではなく、考えを整理しながら話し始めるための口癖になっている場合もあります。

ですが、言葉の響き自体はネガティブな印象を持っています。言われた側は「自分が否定された」と受け取ってしまうことがあります。これは前の節で述べた受容とは反対の話です。

たとえ相手の意見に同意できなかったとしても、まずは相手がそう考えているということ、そう感じたということを受け止めることはできます(それに同意することとは別の話です)。

無理に睡眠を削らない

無条件受容するためには、自分に余裕が必要です。なぜなら、自分に余裕がないとふとしたことでイライラしたり、あるいは落ち込んだりしやすくなってしまうからです。

自分に余裕をつくるために、個人的にいちばん効く方法が「いいからたくさん寝る」です。ただ育児中はこれが本当に難しい。

育児を始めると、生活がイベントドリブンになります。わかりやすい例は授乳タイミングです。新生児に近い段階だと、3時間おきに授乳やミルクをあげる必要があります。ただこれは成長に伴って間隔が広がっていくので問題ないかというと、別の割り込み要求が増えていきます。

これ自体は生活フェーズの自然な変化であり、全く悪いことではありません。むしろ子供の成長が見えるので喜びですらあります。ただ単に落ち着いて何かをゆっくりできる時間が減るので、それに適した生活リズムを作っていくだけです。

生活リズムの中では自分1人で何かしたい時間が出てきます。そうすると最初に考えるのは、早朝あるいは深夜を活用する方法です。私自身も当初はこのアプローチを採用することが多かったのですが、連続すると昼間の体力上限が削られていくことに数年かけて気づきました。体力の上限が削られると、日中の余力がなくなりやすくなります。そうすると最終的に自分のメンタル状態が不安定になります。

これは全体としてやりたいことからすると本末転倒です。なので、「いいからたくさん寝る」がとても大事なのです。

とはいえ何かしたい

そうは言えども、やっぱり何かしらストレス発散や学びをしたい場合もあると思います。私の場合は細切れの時間を使う + 1時間ぐらいに絞って集中してタスクをこなすようにしています。[4]

例えば、細切れの時間の有効活用であれば、哺乳瓶を煮沸消毒している5分などを使ってサクッと何かを学んでいます。幸いなことにAIで様々なことがより高度にできるようになっており、その1つが勉強方法の変化です。詳細は個人のブログ記事で書いたのですが、ざっくり言えばAIをフル活用して新しい概念などを学んでます。

また1日の中で子供が寝た後の1時間ぐらいであれば時間を確保できます。この際にやりたいことをガッとやってしまいます。私が良くやることの1つはXの集中ポストです。細切れでインプットしたことをまとめてアウトプットするために、予約機能を使って自動投稿しています。

おわりに

この記事では、育休に入る前と、育休中に考えるようになったやらないことや価値観の変化について書いてきました。

冒頭で述べたように本記事を読んだ方の中には、これから育休や長期休暇を取得したいが、自分が休むことで周囲に迷惑をかけてしまうと不安に思う方もいるかもしれません。ただ、一定の仕込みをした上で思い切って休んでみてはいかがでしょうか。自分が休むことで、チームの課題が見つかるかもしれませんし、誰かが新しい役割にチャレンジする機会にもなります。うまくいけば、強靭なチームの組成にもつながります。

何より、個人の人生の価値観にもよりますが仕事は人生の一部にしかすぎません。自身の価値観や優先順位に沿って悔いのないように行動すると良いと私は考えています。

本記事はn=1の事例でしかありませんが、記事全体で何か1つでも参考になっていれば幸いです。お読みいただきありがとうございました。

脚注
  1. カオスエンジニアリングとは、本番(またはそれに近い)環境に意図的に障害を注入し、システムが想定どおりに耐えられるかを実験的に検証する手法です。「壊れないことを祈る」のではなく、「壊れたときに何が起きるかを先に確かめておく」という考え方のことです。 ↩

  2. もちろん社内規定などで判断が必要なものは、それに沿った対応が必要です。 ↩

  3. まさにこの原稿自体もマニュアルにタイプして、何度も書いたり消したりしながら書いています。 ↩

  4. 日頃はこうしていますが、このリズムを1-2週で集中して破る時期もあります。 ↩

40
40
利用規約、プライバシーポリシーに同意の上サービスを、ご利用ください。