Slack通知で胸が痛くなるエンジニアが認知行動療法を3ヶ月やった話
バーンアウトで夜中に目が覚める日々。認知行動療法を実践したら思考パターンが変わった。エンジニア視点で解説します。
認知行動療法でエンジニアのバーンアウト対策を本気で試してみた
先日のプロジェクトでメンタルがマジでやばくなった。Slack通知の音が鳴るだけで胸が痛くなって、夜中に目が覚めるし、朝起きた時点で疲れてる。うちのチームでも同じような症状の人が何人かいて、「これ、仕事のペース問題じゃなくてメンタルの問題かも」って気づいたんですよね。
そこで試してみたのが認知行動療法(CBT)です。心理学のアプローチなんで最初は懐疑的だったんですが、3ヶ月ちゃんと実践したら、けっこう変わった。今回は、実際に試してみて気づいたことを、正直に書きます。
認知行動療法ってぶっちゃけ何なのか
認知行動療法は、簡単に言うと「思考パターンを認識して、それを変える」というアプローチだ。よくある勘違いは「ポジティブシンキングで気分を無理に上げる」みたいな話だけど、そうじゃない。むしろ逆です。
エンジニアの僕らってさ、ログを読むのと同じ感覚で自分の思考を追跡できるんですよ。「このエラーはなぜ起きたのか」って詰めていくのと同じで、「なぜこの思考が浮かんだのか」を掘り下げる。その過程で、自分がどれだけ根拠のない悲観的なストーリーを作り続けてるかに気づく。
具体的には、こんな感じだ。
思考の自動化プロセス
僕が経験したのは、こういう流れです:
- きっかけ:デプロイがコケた
- 自動思考:「またやった。俺ダメだ。プロジェクト失敗する」
- 感情:不安、無価値感、罪悪感
- 行動:萎縮する、報告を遅延させる、深く寝られなくなる
一見、この流れは自然に見える。でも実は、ステップ2の「自動思考」が完全に主観的なんですよ。デプロイのコケは単なるコケ。それが「俺はダメなエンジニア」という結論に飛び跳ねてしまう。ここのギャップに気づくのが認知行動療法の第一歩だ。
実際に3ヶ月やってみた、具体的な実装方法
最初は本を読みました。有名なのは「こころが晴れるノート」とか「認知療法自習ガイド」とか。でも正直、本だけだと「ふーん」で終わっちゃう。だから、自分で仕組みを作ったんですよ。
思考記録を自動化する
エンジニアだから、まずはログを取ることから始めました。Notionを使って、こんな表を作った:
| 日時 | きっかけ(事実) | 自動思考 | 根拠(思考の検証) | 新しい考え | 行動 |
|---|---|---|---|---|---|
| 7/2 10:15 | マージがリジェクト | 「また失敗した」「もう無理」 | リジェクトは日常茶飯事。前回は承認された。3回やって2回は通ってる | 「成功率66%。次に改善するポイントがある」 | 指摘を読み込む、改善提出 |
| 7/3 14:30 | スロークエリ指摘 | 「設計が糞」「俺が原因」 | 最初のドラフトでパフォーマンス測定はしてない。これは学習ステップ | 「パフォーマンス測定が甘かった。次に改善する」 | インデックス設計を見直す |
これを毎日3-5個つけました。最初は1件につき5分かかってたけど、1ヶ月で1-2分に短縮された。習慣化するとそのくらいになるんですね。
思考の歪みを認識する
認知行動療法で言う「思考の歪み」ってのがあるんです。エンジニアなら、これはバグパターンだと思ってください。同じパターンの歪みが何度も出てくるんですよ。
よくある思考の歪みはこんな感じ:
- 全か無か思考:「デプロイがコケた=俺は完全に失敗」
- 破局的思考:「これが続いたらプロジェクト全滅する」
- 読心術:「あいつは俺を評価してないに違いない」
- 自責化:「すべては自分の責任」
- 過度な一般化:「1回失敗した=いつもこうだ」
これらをNotionで分類して、自分が「どの歪みにハマりやすいのか」を追跡してみたんです。するとね、気づくんですよ。僕の場合は「破局的思考」と「過度な一般化」が異常に多かった。つまり、1つの問題を全体の失敗に繋ぎ合わせるのが得意だったってわけ。
こうやって見える化してみるとどうなるか:
破局的思考の頻度推移(7月のデータ)
7月1週目:12件
7月2週目:10件
7月3週目:6件
7月4週目:4件
こういう形で見えると、「あ、ちょっと改善してるじゃん」って気づく。地味に重要なんですよ、この感覚。
チームに取り入れてわかったこと
個人でやるのと、チームでやるのは全然違う。うちの場合は、マネージャーに相談して「メンタルヘルス勉強会」という名目で、月1回30分の会を設定しました。
最初は4人くらいだったんですが、今は8人が参加してますね。内容はシンプル:
- 思考記録の事例シェア:「こんなことで悩んだけど、こうやって考え直した」という実例を紹介
- 思考の歪みの認識:「みんなはこういう歪みありますか?」って質問して共有
- 実装の工夫:「こういうツール使ってみたら?」という試行錯誤の報告
正直、最初はちょっと重い雰囲気でしたね。「メンタルの話?大丈夫ですか?」みたいな反応。でも事例シェアを始めたら、みんなが「あ、俺もそれ」って反応するんですよ。
一番印象的だったのは、ベテランエンジニアの発言。彼は「デプロイがコケた時、『これで俺のキャリアが終わる』と思ってた。でも、考え直したら『コケることは学習機会』に変わった」って言ったんです。それを聞いて、個人的には「あ、これはシニアレベルのエンジニアも同じメンタル課題を持ってるんだ」って気づいた。つまり、これは誰にでも起こる問題なんだということですね。
思考を変えるより、行動を変える方が楽って気づいた
ここからが大事なんですが、認知行動療法って「思考を変える」ってよく言われるんですけど、実務的には「行動を変える」の方が先なんですよ。
心理学的には「行動→感情→思考」の順で変わるんです。思考を先に変えようとすると、「それでも不安が…」ってループに入っちゃう。
うちのチームで効いたのは、こういう施策だった。
1. Slack通知の時間制限
Slackの通知音が怖いって話を聞いて、チーム全体でルール作りました。
- オンコール中以外:19時以降と朝8時前は通知OFF
- 優先度付け:アラート・デプロイ通知のみ即時通知、それ以外は朝の確認
単純ですけど、これで「夜中に突然起こされる」という行動パターンが消えました。その結果、睡眠の質が上がって、朝の不安が減った。思考を変えようとするより、環境を変える方が早いんですよ。
2. デプロイ後の「報告儀式」
破局的思考が強い人って、問題が起きた後に「報告が怖い」ってなっちゃうんです。で、報告を遅延させちゃう。すると問題はさらに悪くなる。この悪循環ですね。
そこで、デプロイ後は必ず30分以内に、Slack通知で「デプロイ完了」と報告するルールにしました。これだけで、「報告しなきゃ」という不安が消える。心理的には「報告 = 完了」になるからですね。
3. 「やらかし共有会」の廃止と「学習共有会」への変更
うちは以前、月1回「今月のやらかし」を共有する会をやってました。意図は「みんなで学ぼう」だったんですが、心理的には「失敗を責める」に見えてしまってた。
そこで会を「学習共有会」に変えた。「こういう問題が起きたから、こう対策した」という形式で。微妙な変化ですが、心理的負荷が全然違うんですよ。
データで見える変化
チーム全体で3ヶ月追跡した結果、こんな感じになりました。
メンタルスコアの推移(スケール:1-10、高いほど良い):
6月(導入前): 4.2
7月末: 5.8
8月末: 6.9
9月末: 7.3
これは簡単なアンケート(「今週、仕事に関する不安はどの程度?」を1-10で回答)の平均です。ちゃんと上がってるんですね。
もう1つ、これは確実に見えた変化だ。
月単位での休職・早退者数
導入前(4-5月):2人
導入後(7-9月):0人
サンプルサイズが小さいので因果関係は言えませんが、「施策が効いてる可能性はある」という状態です。
認知行動療法を続けるコツ
正直、最初の1ヶ月が一番つらい。毎日思考記録を付けるのは習慣になるまで時間かかりますね。でも、ここを超えると変わるんですよ。
うちのチームが工夫したこと:
1. ツール選びを正しくやる
Notionとか、もっとシンプルな手書きとか、アプリを使うとか。自分に合うものを選ぶことが重要。僕はNotionにしたのは、Markdownで書けて、グラフが作れて、チームで共有しやすいから。個人的には地味に便利ですね。
2. 完璧を目指さない
毎日書くのが理想ですけど、正直無理な日もあります。週3-4日でいい。継続が大事なんですよ。
3. 成果を定期的に見える化する
月1回、自分の思考の歪みを数えてグラフ化する。「減ってる!」という実感が続ける力になります。これは心理的にけっこう大事。
正直な課題
ここまで良いことばっか書きましたけど、課題もあるんですよね。
1. メンタル問題の根本原因まで解決しない
うちの場合、チームのスケジューリング管理が甘かったんですよ。つまり、根本的なストレス要因が「期限が厳しすぎる」だったわけ。認知行動療法は「その圧力にどう対処するか」は教えてくれますが、「圧力を減らす」方法は別です。
結果、認知行動療法と並行して、プロジェクト管理も改善しました。つまり、組織的な対策と個人の対策を両輪でやることが大事ってわけですね。
2. ラポール(信頼関係)がないと難しい
チーム導入では、マネージャーと僕が信頼できる関係だったのが大きい。もし「メンタルの話=弱さ」みたいな組織文化だと、誰も話さない。逆にいえば、心理的安全性がある組織ほど、認知行動療法は効きやすいってわけですね。
3. 個人差が大きい
うちのチームでも、思考記録が「役に立った」という人と「退屈」という人に分かれました。性格や思考タイプで、合う合わないがあるんですよ。
2026年現在、認知行動療法の状況
CBTはここ数年で、テック業界でも認知が高まってます。理由は2つある。
1. AIと組み合わせた実装が増えてる
メンタルケアアプリの大手(Mindly、Woebot、Youperとか)は、AIを使って思考パターンを認識・提案する機能を入れてきました。つまり、カウンセラーに頼らず、自分で進められるハードルが下がってるんですね。
2. エンジニア向けメンタルヘルスの重要性が言語化された
「バーンアウト」「メンタルヘルス」がIT業界でも当たり前に話題になってきた。UberとかMeta、Googleでも、メンタルヘルス施策を組織的に進めてます。
ただし、重要な注意点:認知行動療法は「ツール」です。本当に深刻なうつや不安障害の場合は、心理士や医者に見てもらう必要があります。自分で判断しないでください。
次のステップ:組織設計との組み合わせ
個人レベルの認知行動療法は効くんですが、僕が思ってるのは「組織にどう組み込むか」が次の課題だってことですね。
うちのチームではこんなことを試してます:
- オンボーディング時の思考記録トレーニング:新人が入るときに、認知行動療法の基礎を教える
- マネージャー向けの研修:メンタルヘルスリテラシーを高める
- バーンアウト予防指標の組み込み:スケジュール管理に「メンタル負荷」という要素を入れる
これらがどこまで効くか、今検証中です。
まとめ
認知行動療法は、エンジニアのメンタルケアとして本当に有効だ。理由は3つ:
- 論理的である:思考を「パターン」として認識できるから、エンジニア的アプローチが使える
- 行動変化が先:思考を無理に変えるんじゃなく、行動と環境を変えることで自然と思考が変わる
- チームで共有できる:個人の問題じゃなく、組織文化として組み込める
あと、重要な点を1つ:メンタルヘルスは「弱さ」じゃなく、「スキル」です。最初のプロジェクトで躓いたエンジニアが、デバッグスキルを身につけるのと同じ。思考パターンをデバッグするのは、コード品質を上げるのと同じ重要性があるんですよ。
皆さんのチームでも、バーンアウトや不安の問題ありませんか?もし興味あれば、まずは思考記録を1週間試してみてください。1週間で体感が変わりますよ。
次は、これを組織設計レベルで落とし込む記事を書きたいと思ってます。