Slackの通知音が怖くなった日——バーンアウト寸前のエンジニアが2年かけて試したこと
「疲れてるだけ」と思って寝まくっても月曜は同じ状態……そんな経験ありませんか？バーンアウトの入り口に立ったエンジニアが、2年間の試行錯誤で見つけた習慣・仕組み・チーム設計を正直に書きました。
2年前の冬、朝起きてPCを開くのが怖くなった時期があった。
Slackのバッジを見るたびに胃がキュッとなる。コードを書き始めてもぜんぜん集中できない。タスクは積み上がっているのに手が動かない。「疲れてるだけだろう」と思って週末に寝まくっても月曜は同じ状態。それが3週間続いたとき、さすがに「これはやばい」と気づいた。
診断名はついてないけど、あの状態はまさにバーンアウトの入り口だったと思う。あのまま放置してたら、もっと深刻な状態になっていたはずだ。
それ以来、バーンアウト予防を「技術的な課題」として真剣に取り組んできた。仕組みで解決できるものは仕組みで、習慣で解決できるものは習慣で。2年間試行錯誤した結果を、今日は書いておこうと思う。同じような状態のエンジニアに少しでも届けばいい。
バーンアウトはある日突然来るわけじゃない
振り返ると、あの冬の状態は半年かけてゆっくり積み上がっていた。「消耗の解剖図」として自分のケースを図にするとこんな感じだ。
flowchart TD
A[慢性的な残業 週60時間超] --> B[睡眠の質低下]
A --> C[運動習慣の消滅]
B --> D[集中力・判断力の低下]
C --> D
D --> E[生産性低下 → さらに残業]
E --> A
D --> F[小さなミス増加]
F --> G[自己嫌悪・罪悪感]
G --> H[Slackへの恐怖感]
H --> I[バーンアウト入り口]
style I fill:#ff4444,color:#fff
style A fill:#ff8800,color:#fff悪循環の構造は見てわかる通りで、一度ループに入ると自力で止めるのがすごく難しい。「もっと頑張れば解決できる」と思えば思うほど深みにはまる。これ、経験ある人は共感してもらえると思う。
2026年時点で研究が進んでいる点として、バーンアウトは「意志の弱さ」でも「メンタルの弱さ」でもなく、累積した認知負荷と自律神経の疲弊によって起きる生理的な現象だということが明確になってきている。つまり、適切な「回復設計」と「負荷の構造的削減」があれば、かなりの確率で予防できる。
2年間で効いた予防策を正直に話す
「効いた」「効かなかった」を正直に書く。全部成功談にはしない。
1. エネルギー残量を可視化する「バッテリーログ」
これが一番効いた。やることはシンプルで、毎日朝・昼・夜に主観的なエネルギー残量を1〜10で記録するだけだ。
# energy_tracker.py — 実際に使ってるスクリプト
import json
import datetime
from pathlib import Path
LOG_FILE = Path.home() / ".energy_log.json"
def log_energy(level: int, note: str = "") -> None:
"""エネルギーレベルを記録する (1=完全枯渇, 10=絶好調)"""
if not 1 <= level <= 10:
raise ValueError("Level must be between 1 and 10")
records = []
if LOG_FILE.exists():
records = json.loads(LOG_FILE.read_text())
records.append({
"timestamp": datetime.datetime.now().isoformat(),
"level": level,
"note": note,
"weekday": datetime.datetime.now().strftime("%A")
})
LOG_FILE.write_text(json.dumps(records, indent=2, ensure_ascii=False))
print(f"✅ Logged: {level}/10 at {datetime.datetime.now().strftime('%H:%M')}")
def weekly_summary() -> dict:
"""週次サマリーを生成"""
if not LOG_FILE.exists():
return {}
records = json.loads(LOG_FILE.read_text())
week_ago = datetime.datetime.now() - datetime.timedelta(days=7)
recent = [
r for r in records
if datetime.datetime.fromisoformat(r["timestamp"]) > week_ago
]
if not recent:
return {"message": "No data in the last 7 days"}
levels = [r["level"] for r in recent]
avg = sum(levels) / len(levels)
return {
"average": round(avg, 1),
"min": min(levels),
"max": max(levels),
"records_count": len(recent),
"warning": avg < 4.0 # 平均4未満で要注意
}
if __name__ == "__main__":
import sys
if len(sys.argv) > 1:
level = int(sys.argv[1])
note = sys.argv[2] if len(sys.argv) > 2 else ""
log_energy(level, note)
summary = weekly_summary()
print(f"\n📊 週次サマリー: {summary}")
if summary.get("warning"):
print("⚠️ 平均エネルギーが低下しています。意図的な休息を取ってください。")実行するとこんな感じになる：
$ python energy_tracker.py 7 "朝のコーヒー後、まあまあ調子いい"
✅ Logged: 7/10 at 09:15
📊 週次サマリー: {'average': 5.2, 'min': 3, 'max': 8, 'records_count': 14, 'warning': False}
$ python energy_tracker.py 3 "夕方になって頭痛。会議連続がきつかった"
✅ Logged: 3/10 at 17:30
📊 週次サマリー: {'average': 4.8, 'min': 3, 'max': 8, 'records_count': 15, 'warning': False}地味に見えるけど、これが本当に価値があった。数値として見えると「今週ちょっとやばいな」が客観的にわかるし、何より「記録している」という行為が自分の状態への意識を保つ。週に1回チームのスタンドアップでさらっと共有するようにしたら、マネージャーも早めに気づいてくれるようになった。
2. 「回復不能な疲弊」と「回復可能な疲れ」を区別する
これは認知行動療法でITエンジニアのバーンアウト対策｜2026年最新ガイドでも触れてるテーマだけど、実務レベルで自分に定着させるのに1年かかった。正直、最初はこんな区別が意味あるのかと半信半疑だった。
疲れには種類がある。これ、ちゃんと整理すると全然違う話なんだよなと気づいてからが大きかった。
| 疲れの種類 | 特徴 | 回復手段 |
|---|---|---|
| 身体的疲労 | 筋肉痛、目の疲れ | 睡眠、軽い運動 |
| 認知的疲労 | 判断力の低下、ぼーっとする | 集中作業の休憩、散歩 |
| 感情的疲弊 | 気力がわかない、無感動 | 意味ある活動、他者との繋がり |
| 価値観の枯渇 | 「なんのためにやってる」感 | 長期目標の見直し、キャリア対話 |
睡眠で回復できる疲れと、そうじゃないものがある。感情的疲弊や価値観の枯渇は、寝ても翌朝同じだ。自分がバーンアウト入り口にいたときは、後者の二つが溜まっていた。「寝たのになんで回復しないんだろう」と思ってたあの感覚、今振り返るとすごく腑に落ちる。
チームでは四半期に一度、1on1で「今どの疲れが溜まってますか」を話し合うようにしている。最初はぎこちなかったけど、今は普通の習慣になってきた。
3. カレンダーに「回復ブロック」を入れる（これが一番難しかった）
正直、最初は懐疑的だった。「そんな時間確保できるわけない」という感じで。でも集中できてる時間、1日2時間しかなかった話を読んで考え方が変わった。
意識的に確保しなければ、回復の時間は永遠に来ない。それだけだ。
今やっていることは3つで、どれも「場所」と「時間」をセットで固定している：
- 月曜9〜10時：週の優先度整理（メール・Slack禁止）
- 水曜12〜13時：昼休みは必ず外出か、完全オフライン
- 金曜16〜17時：週次振り返り + 来週の不安を書き出す
カレンダーブロックだけだと「他の人が会議入れてしまう」問題があるので、Googleカレンダーで「予定あり」に設定している。これを見て「なんで空いてないんですか」と聞いてくる人は今のところゼロだ。
チームレベルで導入してみた仕組み
個人の習慣だけじゃ足りないと思っている。バーンアウトは構造的な問題なので、チームの設計も変えないといけない。個人が頑張るだけでどうにかなるなら、とっくにどうにかなってるはずだし。
うちのチームで2025年後半から運用している指標がある。名付けて「持続可能性スコア」だ。
xychart-beta
title "チーム持続可能性スコアの推移(月次)"
x-axis ["2025-07", "2025-08", "2025-09", "2025-10", "2025-11", "2025-12", "2026-01", "2026-02", "2026-03", "2026-04", "2026-05"]
y-axis "スコア (0-10)" 0 --> 10
bar [4.2, 3.8, 5.1, 5.6, 6.0, 6.8, 7.1, 7.4, 7.2, 7.8, 8.1]
line [4.2, 3.8, 5.1, 5.6, 6.0, 6.8, 7.1, 7.4, 7.2, 7.8, 8.1]2025年7〜8月が底値で、そこから対策を打ち続けて今は8点台まで来た。スコアは以下の要素の平均だ：
- 週次エネルギー平均（チームメンバーの自己報告）
- 残業時間（設計目標40時間/週に対する乖離度）
- オフコール達成率（「今日はもう触らない」と決めた時間の遵守率）
- Sprint完了率（過負荷の代理指標として使ってる）
これをスプリントレビューに毎回出すようにしたら、マネージャーが「次スプリントのポイント上限を下げましょう」みたいな判断をしやすくなった。数字があると話しやすい。感覚で「しんどいです」と言うより、グラフ一枚出す方がずっと動いてもらいやすい。
非同期コミュニケーションの再設計
「常に即レスしなきゃいけない」プレッシャーがバーンアウトの大きな要因だったと気づいたのは後からだ。当時はそれが当たり前だと思ってたから、しんどさの原因として認識すらしていなかった。
3年かけて気づいた、リモートチームが本当に必要とした非同期文化に書いてあることが本当によくて、うちのチームでも似たアプローチを取った。
具体的にはSlackのチャンネルに以下のルールを明記した：
# チームSlack通信プロトコル v2.1（2026年改定）
## 応答期待時間
- 🟢 #general, #random: 翌営業日でOK
- 🟡 #dev-team: 4時間以内
- 🔴 #incidents: 即時（ただしオンコール担当のみ）
## メンション禁止時間
- 平日 22:00〜翌8:00
- 土日（インシデント除く）
## 「既読無視」は失礼じゃない
- 通知OFFは権利です
- 深夜の「👀」反応は不要このルールを作っただけで「Slackを見なきゃいけない」という感覚が薄れた。心理的安全性という言葉は使い古されてるけど、「返信しなくていい」の明文化は効いた。むしろなんでもっと早くやらなかったんだろうとさえ思う。
2026年時点で注目している予防ツール・アプローチ
正直まだ検証中のものもあるけど、試してみている内容を書いておく。
Continuous Stress Monitoring（生体データ活用）
Apple Watch Series 10やGarmin Fenix 8に搭載されたHRV（心拍変動）モニタリングを、ストレス管理に使い始めた人がチームに増えてきた。HRVは自律神経の回復指標として医学的根拠があって、低い状態が続くとバーンアウトリスクが高いとされている。
自分はGarmin使いで、朝のHRVスコアをエネルギーログと照らし合わせている。主観スコアと生体データが乖離するとき——「気力はあるつもりだけど身体は疲弊している」状態——が一番危険だとわかってきた。
ただし数字に依存しすぎると「今日HRVが低いからやる気出ない」という言い訳に使い始めるリスクがある。個人的には補助情報として見る程度が健全だと思っていて、ここは好みが分かれるかも。
AI支援の感情チェックイン
2026年に入って、Notion AIやSlack AIを使った「感情状態のサマリー」機能を試している。日報に気持ちを書いておくと「今週のあなたの感情傾向：疲労感の高い表現が多い傾向です」みたいなフィードバックが来る。
正直、まだ精度には懐疑的だ。ただ、自分の文章を振り返るきっかけとしては悪くない。「あ、確かに今週愚痴っぽいことばっかり書いてた」という気づきがあったりする。道具として割り切れるかどうかが使いこなすコツかもしれない。
マイクロリカバリーの実装
エンジニアの昼寝術2026｜科学的ナップで生産性・コード品質を最大化の内容が参考になったんだけど、長い休みじゃなくて「ちょっとした回復」を1日に何度も入れる設計が重要だと感じている。
15〜20分の集中作業 → 5分の完全離席、これをポモドーロ的にやるんじゃなくて、「認知的に重いタスクが一区切りついたタイミング」で入れるようにした。タイマーで強制するんじゃなく、完了感と紐付けるのがポイントだ。
まだ実験中だけど、午後の中盤（14〜15時）に5分外に出るだけで夕方のパフォーマンスが維持できている感覚がある。地味に便利というか、地味に効く。
「バーンアウト予防」と「生産性向上」は矛盾しない
ここを誤解している人が多い気がするので、最後に書いておく。
「休み方を考えるのは甘え」「ストイックに働いてナンボ」という文化が、特に日本のエンジニア界隈にはまだ残ってると思う。自分もかつてそう思ってた。あの頃の自分に「それ間違ってるよ」と言えるなら言いたい。
でも実際に数字を見るとまったく逆で、バーンアウト寸前のエンジニアの生産性は健康な状態の40〜60%しか出ないという研究が2025年に複数出ている。コードレビューの質も下がるし、設計の意思決定も悪くなる。インシデント対応の最新ベストプラクティス2026でも触れられているように、ヒューマンエラーの多くは認知リソース不足が根本原因だ。
つまり、バーンアウト予防は「個人の健康管理」でもあるし、「チームのアウトプット品質を守ること」でもある。この二つは同じことだ。
試行錯誤してみて、「持続可能に働けること」が最終的に一番の武器になると確信している。10年後も同じ品質でコードを書き続けられるかどうかが、長期的なエンジニアとしての価値だと思うから。
皆さんのチームでは、バーンアウト予防に向けてどんな取り組みをしてますか？ まだなにもやってないという人は、まずエネルギーログだけでも試してみてほしい。Pythonスクリプトは前述のやつをコピペするだけで動くはずだ。
まとめ
- バーンアウトは突然来ない。半年かけてゆっくり積み上がる。悪循環の構造を早めに認識することが予防の第一歩。
- エネルギーログで状態を可視化すると、客観的な判断ができる。主観だけに頼らず、週次サマリーで「平均4未満」が続いたら行動を変えるトリガーにする。
- チームのSlack通信ルール明文化は即効性がある。「返信しなくていい」の明文化が心理的プレッシャーを大幅に下げた。
- カレンダーに回復ブロックを入れるのは最初抵抗があるが、確保しなければ永遠に来ない。月曜・水曜・金曜の固定スロットが今は習慣になっている。
- バーンアウト予防と生産性向上は矛盾しない。消耗しきったエンジニアは健康時の半分以下の生産性しか出ない。持続可能な働き方が長期的な最強の戦略だ。
次のアクション： まずは今日から3日間、朝・夜のエネルギーレベルを1〜10でメモするだけ始めてみてください。それだけで何かが変わり始めるはずです。