0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

うつ病と休職、復職とその後を振り返って

Last updated at Posted at 2026-01-19

うつ病で休職したITエンジニアが復職して「再休職しない仕組み」を作るまで:なぜ崩れたか、どうすればよかったか、今どう設計するか

※この記事は医療アドバイスではありません。診断・治療・復職判断は主治医、産業医(会社側の医師)、人事、上長と相談してください。ここでは私の経験をもとに、再発を減らすための「環境」と「手順」を実務の形でまとめます。

厚生労働省の「心の健康問題により休業した労働者の職場復帰支援の手引き」は、復職を段階的に進め、支援内容を具体化した「職場復帰支援プラン」を作り、復職後もフォローする前提で整理しています。復職は“復帰日”ではなく“運用”です。

この記事のゴールは「元の100%」ではなく、「再休職せずに働き続ける形」を作ることです。


私が休職に至った状況(2024/5〜2024/11)

2024年5月頃から運用保守改修の案件を掛け持ちしはじめ、2024年6月〜11月は4案件を同時並行で対応していました。勤務形態はフルリモートで、月の稼働は190〜200時間程度です。

悪化した出来事が重なりました。私の上に立っていたマネージャーが離職し、人員補充がないままプロジェクトが進行しました。さらに4案件のうち1つで、比較的規模が大きく納期の短い改修が発生し、「仕様変更→再設計→改修実装→デプロイ」が短期間に詰め込まれ、前提が動くたびに手戻りが発生しました。

上長にTeamsの口頭MTGで2度相談し、人員追加と担当範囲縮小を求めましたが、回答は「様子見」で条件は変わりませんでした。その後、不眠、食欲不振、不安、集中力低下、ミス増、頭が回らない、朝起きられないといったサインが重なり、主治医の診断と体調悪化で動けなくなったことをきっかけに休職しました。休職期間は約3か月です。

復職後は1か月ほど慣らしとキャッチアップを行い、その後案件に段階的にアサインされました。会社と合意した配慮は「残業禁止」「担当範囲限定」で、これは守られました。


なぜ崩れたのか(原因を断言せず、構造として振り返る)

うつ病の原因を一つに断定はできません。ただ、仕事の構造として振り返ると、崩れやすい条件が揃っていました。

まず、負荷が「量」だけでなく「変動」と「切り替え」に寄っていたことです。仕様変更と再設計は判断回数を増やし、並行案件は切り替え回数を増やします。フルリモートだと限界が見えにくく、抱え込みやすいです。

次に、責任範囲の境界が曖昧になったことです。マネージャー離職後、優先順位や納期の現実化、調整と合意形成が宙に浮き、現場が埋める形になりました。実装以外の負担が増えるほど、回復の余白は消えます。

最後に、相談しても根本条件が変わらなかったことです。人員・優先度・納期が据え置きのままだと、現場は睡眠や食事を削って埋めがちです。短期を乗り切れても、中長期で折れます。


どのようにすればよかったのか(当時の私が取り得た現実的な手)

今だから言えることですが、当時の私は「頑張り方」を間違えました。頑張る前に、根本条件(人員・優先度・納期・担当範囲)を動かすための材料を作るべきでした。

一つ目は、負荷を事実で“見える化”することです。口頭相談は流れても、「4案件並行」「仕様変更回数」「週のリリース回数」「突発対応回数」「未処理チケット数」「見積もりと実績の乖離」などが揃うと、優先度調整や担当縮小が議論しやすくなります。ここは感情ではなくデータで殴るほうが強いです。

二つ目は、「何を止めるか」をセットで提案することです。「人を増やして」だけだと判断が止まります。「Aは継続、Bは延期、Cは担当外にする。代わりにこの品質線は守る」と、トレードオフ(何かを捨てる代わりに何かを守る)まで出すと、上長は決めやすいです。

三つ目は、相談ルートを増やすことです。上長が動けない場合に備えて、人事・産業保健(産業医や保健師)へ早めに相談する経路を使うべきでした。厚生労働省の両立支援の考え方でも、主治医と職場の情報交換を含め、関係者で就業上の配慮を作ることが重視されています。

四つ目は、サインが出た時点で“負荷を下げる手順”を発動することです。不眠やミス増が出ているのに、同じ条件のまま走り続けるのが最も危険でした。症状が進むほど相談も難しくなるので、「兆候が出たら機械的に下げる」を先に決めておくべきでした。


復職した現在、再休職しないために私が作りたい仕組み

復職後に最優先で変えたいのは、納期の持ち方、割り込み、会議、責任範囲、相談ルート、睡眠の優先です。これらは“気合い”では守れません。守れる形に“設計”します。

私は、仕組みを三層に分けると崩れにくいと考えています。

第一層は「入口のルール」です。納期を受けるときの前提、割り込みの線引き、会議の扱い、責任範囲の境界を、最初に言語化して合意します。入口が曖昧だと、後から調整するコストが跳ね上がります。

第二層は「日々の運用」です。タスクを小さくし、着手条件と完了条件を固定し、詰まりは早期共有に寄せます。通知を見る時間帯を固定し、集中時間帯を守ります。こうすると、調子の波があっても、仕事の形は崩れにくい。

第三層は「悪化時の手順」です。兆候が出たら、迷わず負荷を落とし、相談し、引き継ぎに切り替える。厚労省の手引きでも復職後フォローが重視されているので、フォロー面談の頻度と見直しタイミングも、最初から合意に含めます。

以下は、私が実際に作って運用したいテンプレです。Qiitaに貼ってそのまま使える形にしてあります。

【入口のルール(自分の合意メモ)】
納期:受ける前に前提を確認し、前提が動いたら再見積もりする
割り込み:緊急の定義を決め、緊急以外は“まとめて対応”に寄せる
会議:目的と決定事項がない会議は減らす/連続会議を避ける
責任範囲:「私が決めること/決めないこと」を言語化して共有する
相談ルート:上長→人事/産業保健→主治医(必要時)の順で使えるようにする
睡眠:睡眠が崩れたら仕事を下げる(次のカードを発動)

【負荷の見える化メモ(週1で更新)】
同時並行:○件
今週の変更:仕様変更○回、再設計○回
リリース:○回
突発対応:○回
未処理チケット:○件
困っている点:前提が動く/割り込みが多い/レビュー待ち など
求める調整:担当縮小/期限調整/割り込み窓口の一本化 など

【悪化時の手順カード(48時間ルール)】
兆候:不眠が続く/ミスが増える/朝起きられない/頭が回らない
48時間でやる:新規タスク停止→会議削減→期限の再交渉→上長へ短文共有
必要なら:人事・産業保健へ相談/主治医へ相談

【上長へ送る短文テンプレ】
体調の波が出ており、再発防止のため負荷調整が必要です。
今日から新規タスクを止め、会議参加を絞ります。期限は再調整させてください。
15分だけ状況共有の時間をください。

【引き継ぎの最小単位】
今やっていること/次にやること/詰まり点/関連リンク(チケット・ブランチ)

このテンプレの狙いは、頑張らなくても守れる形にすることです。特に睡眠は、崩れてから戻すのが難しいので「崩れたら仕事を下げる」を自動化します。


まとめ:再休職を避ける鍵は「気合い」ではなく「入口・運用・悪化時手順」の設計

私の場合は、並行案件と手戻りで判断と切り替えが増え、責任境界が曖昧なまま条件が変わらず、睡眠を削って埋めたことが崩れた要因だと感じます。
再休職を避けるために、入口のルール、日々の運用、悪化時の手順を文書化して守り続けてみようと思います。

参考ソース

厚生労働省「心の健康問題により休業した労働者の職場復帰支援の手引き」
https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000055195_00005.html

(同・全体版PDF)
https://www.mhlw.go.jp/content/000561013.pdf

厚生労働省「治療と仕事の両立について」
https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000115267.html

厚生労働省「治療と仕事の両立支援ナビ」
https://chiryoutoshigoto.mhlw.go.jp/

厚生労働省「〈治療と仕事の両立支援〉メンタルヘルス不調者の主治医向け支援マニュアル(PDF)」
https://www.mhlw.go.jp/content/11200000/001472029.pdf

0
0
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
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?