メンタルヘルス

Slackが怖くなったエンジニアが半年かけて整えたバーンアウト対策2026

「開いたら何か増えてる」——その感覚、ありませんか？バーンアウト寸前まで追い詰められた筆者が、週次ログ・CBT・チーム設計で立て直した実践記録を全公開します。

メンタルヘルスバーンアウト予防エンジニアリング文化

去年の秋、毎朝スタンバイ前に胃が締まる感覚があった。Slackを開くのが怖いというか、正確には「開いたら何か増えてる」という確信があって、それが嫌だった。コードを書く気が起きないのに「コードを書かなければいけない」という焦りだけが残る状態。典型的なバーンアウト手前の症状だったと、あとから振り返って分かった。

そのときのことは以前「Slackの通知音が怖くなった日——バーンアウト寸前のエンジニアが2年かけて試したこと」で書いたんだけど、あれから半年以上経って、もう少し体系的な知識と実践が積み上がってきた。今日はそれを全部ひっくり返して書く。

2026年時点でエンジニアのバーンアウトをめぐる状況は、以前よりさらに複雑になってる。AIコーディングアシスタントが当たり前になって「アウトプット速度への期待値」が爆上がりした。リモートワーク常態化で「どこにいても仕事できる」が「どこにいても仕事すべき」に変容した。オンコール文化も見直されつつあるけど、まだ改善途上のチームは多い。

バーンアウトは精神論の話じゃない。設計の話だと最近強く思う。

バーンアウトの前兆を定量的に観測する

最初の壁は「気づくのが遅い」問題だ。バーンアウトは突然来るわけじゃなくて、6〜12ヶ月かけてゆっくり進む。自分でも「最近ちょっと疲れてるかな」くらいにしか思わない。だから測定が必要になる。

僕が今やってるのは週次のセルフチェックをログに残すことで、Notionのデータベースに毎週月曜に入力してる。項目はシンプルで、以下の5つを1〜10でスコアリングするだけ。

## 週次メンタルヘルスチェック（毎週月曜 9:00実施）

| 指標 | スコア(1-10) | メモ |
|------|-------------|------|
| 仕事に向かう意欲 | | |
| 集中できた時間の体感 | | |
| 人と話したいと思えるか | | |
| 睡眠の満足度 | | |
| 「休んでいい」と感じられるか | | |

3項目以上で5以下が2週間続いたら要注意サイン

「主観だろ」って思う人もいると思う。そこで、もう少し客観的な指標としてGitのコミット数・時間帯・PR作成頻度も自動収集してる。深夜（23時以降）のコミットが週3回以上になってきたとき、ほぼ確実に翌月の体調が悪い。自分のパターンとして3年分のデータで確認済みだ。

# git log から週次アクティビティを集計するスクリプト
import subprocess
from datetime import datetime, timedelta
from collections import defaultdict

def get_commit_stats(weeks=8):
    since = datetime.now() - timedelta(weeks=weeks)
    since_str = since.strftime("%Y-%m-%d")
    
    result = subprocess.run(
        ["git", "log", f"--since={since_str}", "--author=YOUR_NAME",
         "--format=%H|%ad", "--date=format:%Y-%W|%H"],
        capture_output=True, text=True
    )
    
    weekly_stats = defaultdict(lambda: {"total": 0, "late_night": 0})
    
    for line in result.stdout.strip().split("\n"):
        if not line:
            continue
        parts = line.split("|")
        if len(parts) < 2:
            continue
        week_key = parts[0]  # YYYY-WW形式
        hour = int(parts[1]) if len(parts) > 1 else 0
        
        weekly_stats[week_key]["total"] += 1
        if hour >= 23 or hour < 5:
            weekly_stats[week_key]["late_night"] += 1
    
    return weekly_stats

stats = get_commit_stats()
for week, data in sorted(stats.items()):
    late_ratio = data["late_night"] / data["total"] if data["total"] > 0 else 0
    flag = "⚠️ 深夜率高め" if data["late_night"] >= 3 else ""
    print(f"{week}: 総コミット={data['total']}, 深夜={data['late_night']} {flag}")

実行結果のイメージ：

2025-38: 総コミット=23, 深夜=1
2025-39: 総コミット=31, 深夜=2
2025-40: 総コミット=18, 深夜=4 ⚠️ 深夜率高め
2025-41: 総コミット=12, 深夜=5 ⚠️ 深夜率高め
2025-42: 総コミット=8,  深夜=3 ⚠️ 深夜率高め  ← このあと体調不良

自分のパターンを把握しておくと「あ、また深夜作業多くなってきた」で早めに手を打てる。

xychart-beta
  title "週次バーンアウト指標の変化（実データイメージ）"
  x-axis ["W38", "W39", "W40", "W41", "W42", "W43", "W44", "W45"]
  y-axis "スコア" 0 --> 10
  line [8, 7.5, 6, 5, 4, 4.5, 6, 7.5]
  bar [1, 2, 4, 5, 3, 2, 1, 1]

折れ線が「意欲スコア」、棒グラフが「深夜コミット数」。見事に相関してる。几帳面にやり続けるのはなかなか大変だけど、せめて月次で振り返る習慣だけでも作っておいて損はない。

2026年に増えた「AI疲れ」という新しいバーンアウト要因

ここ1〜2年で確実に増えたと感じてるのが、AIツール周辺の疲弊だ。Cursor・GitHub Copilot・Windsurf、そしてチームに導入されたAIコードレビューボット——これらが「助けてくれるはずのツール」なのに、なぜか疲弊する。

何が起きてるのかを整理するとこうなる。

flowchart TD
    A[AIが提案を出す] --> B{受け入れる？}
    B -->|受け入れる| C[コードが増える]
    B -->|拒否する| D[また提案が来る]
    C --> E[レビュー負荷が増える]
    D --> F[精神的な摩擦コスト]
    E --> G[全体の作業量増]
    F --> G
    G --> H[「AIで生産性上がってるはず」という期待値との乖離]
    H --> I[自己効力感の低下]
    I --> J[バーンアウト要因に]
    
    style H fill:#ff6b6b,color:#fff
    style I fill:#ff6b6b,color:#fff
    style J fill:#c0392b,color:#fff

「AIを使えば速くなる」という外部からの期待と、「実際にはコンテキストを伝えたり提案を取捨選択する認知コストがある」という現実のギャップが、地味にメンタルを削ってくる。個人的にはこれが一番やっかいで、「使いこなせてない自分が悪い」という自責にまで発展しやすい。

うちのチームで2026年から始めたのは「AIツールの利用状況を週次で振り返る」という文化だ。毎週金曜の雑談で「今週Copilotに何回イライラした？」を聞くだけ。これだけで「あの機能は使うの止めよう」という意思決定が格段に早くなった。ツールに振り回されるんじゃなくて、ツールを使いこなすという感覚を取り戻すのが大事なんですよね。

ツール利用パターンバーンアウトリスク対策
全サジェストを受け入れる高（自律性喪失）利用率を意識的に下げる日を設ける
全サジェストを精査する中（認知コスト過多）精査する時間帯を朝1時間に限定
用途を絞って使う低「これには使わない」ルールを明文化
使わない日を週1設ける低AIフリーデーの導入

「AIフリーデー」を週1日設けるようになってから、コードを書く楽しさが戻ってきた気がする。完全に主観だけど、チームメンバー4人中3人が「効果あった」と言ってるから少なくとも再現性はある。「生産性下がるんじゃ」という懸念もあったけど、今のところそんな感じはない。

認知行動療法の実践——チームで使えるレベルに落とし込む

以前「認知行動療法でITエンジニアのバーンアウト対策」で触れた内容の、実践編を書く。CBTって最初に聞いたとき「心療内科で受けるやつでしょ？」と思ってたんだけど、日常に取り入れられる技法が結構ある。難しい話じゃない。

特に効いたのが「認知の歪みをメモする」という習慣だ。エンジニアに多いパターンを3つ挙げる。

1. 全か無か思考

「このPR、バグがあったから完全に失敗だ」 → 実際：99%は正しく動いてる

2. 過度の一般化

「また見積もりミスった。自分はいつもこうだ」 → 実際：このスプリントで1回ミスしただけ

3. 心の読みすぎ

「レビューコメントが多い。こいつは俺のことを評価してない」 → 実際：丁寧にフィードバックしてくれてるだけかもしれない

# 認知ログ（Notion APIで自動集計するためのJSONスキーマ例）
cognitive_log_entry = {
    "date": "2026-06-28",
    "trigger": "PRのレビューコメントが15件あった",
    "automatic_thought": "自分のコードはひどい、もうダメだ",
    "cognitive_distortion": "全か無か思考",
    "evidence_against": "15件のうち12件はnitpick、実際の設計批判は2件だけ",
    "balanced_thought": "改善点はあるが、コア設計は評価されてる",
    "emotion_before": 3,  # 1-10
    "emotion_after": 6   # 1-10
}

これをNotionに溜めて月1回眺めると、自分がどのパターンでつまずくか見えてくる。僕は「心の読みすぎ」が断然多くて、Slackの短いメッセージを悪い方向に解釈しがちだと気づいた。それから「テキストでの感情読みは基本的に外れる」を前提にするようにしたら、Slack見るのが少し楽になった。

チームへの導入という観点では、1on1の最後5分に「今週認知の歪みあった？」を軽く話すだけでも効果がある。心理的安全性が高いチームなら、みんながポツポツ話し始める。ここは正直チームの雰囲気によって差が出るところで、無理に導入するよりまず自分一人でやってみるのがいいかもしれない。

「回復するための設計」をシステム化する

「休もう」と精神論で言うだけでは続かない。エンジニアなら特に共感してもらえると思うけど、仕組みがないと「気合いで頑張る」にどんどん戻ってしまう。

2026年に僕が実装してるのは「エネルギー残量モデル」だ。バッテリーみたいに考えて、消費と回復の両方を設計する。

pie title 週40時間のエネルギー配分（理想モデル）
  "深い集中作業（創造的）" : 15
  "コミュニケーション・会議" : 10
  "ルーティン・管理作業" : 8
  "学習・インプット" : 4
  "バッファ（予期せぬ対応）" : 3

特に「バッファを意識的に確保する」のが重要で、カレンダーに色分けで入れてる。深い集中作業（コーディング）は青、会議はグレー、バッファは白、学習は緑。1週間を俯瞰したときに「青が足りない週」「グレーばかりの週」が可視化されて、事前に調整しやすくなった。これ、やってみると意外と自分がいかに青を削ってたかが分かって少し凹む。

もう一個、地味に効いてるのが「業務終了儀式」だ。

## 業務終了チェックリスト（17:30に実施）

- [ ] 明日のTODOトップ3を書いた
- [ ] 未読Slackを「あとで読む」か「スターなし削除」に仕分けた
- [ ] 今日1つ良かったことをメモした
- [ ] PCのSlackをミュートモードにした
- [ ] ドア（物理またはメンタルの）を閉めた

リモートワークってオンオフの切り替えが難しくて、気づいたら22時になってることがある。「リモートワーク5年目、気づいたら集中できない環境を自分で作ってた話」でも書いたけど、物理的な終了サインがないと脳が「まだ仕事時間」と判断し続ける。儀式っぽくてちょっと照れくさいんだけど、1ヶ月やると確実に効果が出た。

もう一つ大事なのが「オンコール設計」だ。インシデント対応のベストプラクティスについては「インシデント対応の最新ベストプラクティス2026」に詳しく書いてあるけど、バーンアウト予防の観点から補足すると「週末のオンコール後に代休を確保する」というルールをチームに明文化するだけで、精神的な負担が全然違う。合意を取るのが一番のハードルだけど、一度決めてしまえばあとはルーティンになる。

施策実装難易度効果体感備考
週次セルフチェックログ低高継続が重要
深夜コミット率のモニタリング中中パターン把握に有効
AIフリーデーの設定低中〜高チーム文化による
業務終了儀式低高リモート勢に特に有効
認知ログの記録中高習慣化まで2週間かかる
エネルギー配分のカレンダー可視化中高月次見直しが必要
オンコール後の代休ルール低（合意さえあれば）非常に高チーム合意が先

チーム・組織レベルのバーンアウト予防設計

個人の取り組みだけでは限界がある。特に「チームが燃え尽きてる」状態は、個人の努力でどうにもならないことが多い。これは経験則として強く感じてる。

2026年現在、1on1の設計を大きく見直したチームが増えてる印象がある。「進捗確認の1on1」から「エネルギー状態の確認」にフォーカスを移すイメージ。うちのチームで使ってる1on1のテンプレートはこんな感じ：

## 1on1テンプレート（隔週30分）

### エネルギー確認（5分）
- 今週のエネルギー残量は何%くらい？
- 何が一番消耗した？

### ブロッカー・困ってること（10分）
- 技術的に詰まってることは？
- 人間関係で気になることは？

### 良かったこと（5分）
- 今週うまくいったことは？
- 誰かに感謝したいことは？

### 次のアクション（5分）
- 来週僕（マネージャー）に何かしてほしいことは？
- 自分がやると宣言すること1つ

最初に「エネルギー残量は何%？」と聞くのが実は一番効いてる。数字で答えてもらうことで「30%くらいです」という会話が自然に始まって、そこから深掘りしやすい。「大丈夫です」で終わりにくくなるんですよね。最初は「なんで数字で答えるの」という空気になることもあるけど、3回くらいやると慣れてくる。

もう一つ、2025年後半からチームで取り組んでるのが「無理なスプリント計画の見える化」だ。スプリントのベロシティが連続3回以上で予測を20%以上下回ってる場合、それはプランニングの問題じゃなくてエネルギー不足のサインとして扱う——というルールを決めた。

# Jiraのスプリントデータを取得してバーンアウトリスクを算出するスクリプト例
# （Jira REST API v3使用）

import requests
from typing import Optional

def calculate_burnout_risk(
    planned_points: list[float],
    actual_points: list[float],
    threshold: float = 0.8  # 達成率80%以下を「低達成」と定義
) -> dict:
    """
    直近スプリントのベロシティ達成率からバーンアウトリスクを算出
    """
    if len(planned_points) < 3:
        return {"risk": "insufficient_data", "score": None}
    
    ratios = [
        actual / planned 
        for actual, planned in zip(actual_points, planned_points)
        if planned > 0
    ]
    
    recent_ratios = ratios[-3:]  # 直近3スプリント
    consecutive_low = all(r < threshold for r in recent_ratios)
    avg_ratio = sum(recent_ratios) / len(recent_ratios)
    
    if consecutive_low and avg_ratio < 0.7:
        risk = "HIGH"  # 要緊急対応
    elif consecutive_low:
        risk = "MEDIUM"  # 要注意
    elif avg_ratio < threshold:
        risk = "LOW"  # 観察継続
    else:
        risk = "NORMAL"
    
    return {
        "risk": risk,
        "avg_achievement_rate": f"{avg_ratio:.1%}",
        "consecutive_low_sprints": sum(1 for r in recent_ratios if r < threshold),
        "recommendation": {
            "HIGH": "即座にスプリント負荷を30%削減し、チームのエネルギー状態を確認",
            "MEDIUM": "次のプランニングで意識的にキャパシティを下げる",
            "LOW": "1on1でエネルギー確認を追加",
            "NORMAL": "現状維持"
        }.get(risk, "")
    }

# 使用例
result = calculate_burnout_risk(
    planned_points=[40, 42, 38, 45, 40],
    actual_points=[39, 38, 28, 31, 27]
)
print(result)
# 出力例:
# {'risk': 'HIGH', 'avg_achievement_rate': '70.7%', 
#  'consecutive_low_sprints': 3,
#  'recommendation': '即座にスプリント負荷を30%削減し、チームのエネルギー状態を確認'}

これをスプリント終了後に自動実行してSlackに通知するだけで、「なんか最近みんな疲れてない？」という気づきが数値として出てくる。数値化することでマネージャーが動きやすくなるのが大きい。

「スプリント達成率が低い = 怠けてる」ではなくて「バーンアウトサインかもしれない」という解釈軸をチームで持てると、文化が変わる。これ、言うのは簡単だけど実際に定着させるには時間がかかる。うちも半年くらいかかった。

まとめ

2026年のエンジニアのバーンアウト予防について、自分の実践から得た知見を書いた。教科書的なアドバイスじゃなくて「実際に動いてるコードと習慣」として書いたつもりだ。

要点をまとめるとこうなる。

  1. 前兆を定量観測する: 週次スコアリング＋深夜コミット率のモニタリングで、バーンアウトを3〜4週間前に察知できるようになった
  2. AI疲れは2026年の新しい要因: AIサジェスト疲れは「生産性への期待値と認知コストのギャップ」から来る。AIフリーデーは地味に効く
  3. 認知の歪みログは個人・チーム両方に有効: 自分のパターンを知ると、次に同じ罠にハマりにくくなる
  4. 業務終了儀式とエネルギー配分の可視化: リモートワーク環境では特に「仕組みとしての切り替え」が必要
  5. チームのベロシティ達成率をバーンアウト指標として扱う: スプリントデータを人間の状態指標として再解釈することで、マネージャーが動きやすくなる

次のステップとして

  • まず「週次セルフチェックログ」だけでも始めてみてほしい。5分で終わる
  • チームでやるなら「1on1にエネルギー%の質問を追加」するだけで変化が出る
  • 深夜コミット率の自動集計スクリプトは、Gitがあれば今日から動かせる

最後に一つ聞いてみたいんだけど、バーンアウトの前兆として「これが来たら危ない」というサインを自分で持ってる人、どのくらいいるだろう。チームごとにパターンが違うと思うので、ぜひ言語化してみてほしい。僕は「アイデアが浮かばない日が3日続く」がシグナルで、これが来たら強制的に週20時間モードに切り替えるルールを持ってる。完全に個人差あるけど、「自分だけのサイン」を持っておくのが一番の予防策かもしれない。

U

Untanbaby

ソフトウェアエンジニア｜AWS / クラウドアーキテクチャ / DevOps

10年以上のIT実務経験をもとに、現場で使える技術情報を発信しています。 記事の誤りや改善点があればお問い合わせからお気軽にご連絡ください。

関連記事

メンタルヘルス

Slackの通知音が怖くなった日——バーンアウト寸前のエンジニアが2年かけて試したこと

メンタルヘルス

Slack通知で胸が痛くなるエンジニアが認知行動療法を3ヶ月やった話

メンタルヘルス

エンジニアのセルフケア、3年間の失敗と「続く仕組み」にたどり着いた話

メンタルヘルス

納期3ヶ月前の夜眠れない問題、Excelで解決した話

メンタルヘルス

Slackの通知音が怖くなった日｜エンジニアの燃え尽きから9ヶ月で立て直した記録

メンタルヘルス

Slackの通知音で胃が痛くなってたエンジニアが、バーンアウト手前から回復した話

← 記事一覧に戻る