コードが書けなくなった日──エンジニアが燃え尽きる性格の構造

エンジニアの燃え尽きは、ある日突然コードが1行も書けなくなる瞬間に始まるのではない。休日に新しい技術を触って個人開発のコードを書くことがあんなにワクワクして楽しかった頃の自分を、どうしても思い出せなくなった瞬間に静かに始まっている。

夜中の3時。暗い部屋のデュアルモニターの中でVSCodeが開いている。黒い背景の上で白いカーソルだけが無機質に点滅している。コーディングが創造からただの苦痛な作業に成り下がり、簡単なIssueを一つ消化することすら鉛のように重い。

かつては寝食を忘れて没頭できたはずのプログラミングが、いまはただの苦痛な労働にしか感じられない。はてブのテクノロジー新着タブを開く気力もない。GitHubの草なんてもう何週間も真っ白なままだ。

周囲からは技術力が高くて信頼されているシニアエンジニアに見えるかもしれない。でも中身はもう完全に空っぽだ。この空虚さをどう説明すればいいかわからないから、Slackで大丈夫です進んでますとだけ返して、また明日もフリーズした画面と向き合う。

はてなブックマークのテクノロジーカテゴリでも、ここ数年エンジニアのバーンアウトに関するエントリが明らかに増えている。コメント欄を見ていると、自分も同じ経験があるという共感の声が毎回大量につく。IT業界という環境そのものが、特定の性格タイプのエンジニアを構造的に追い詰めているのだと筆者は感じている。

エンジニアのバーンアウトは能力不足から起きるのではない。むしろ能力が高いからこそ起きる。その構造を認知パターンの視点から解剖していく。

INTpの終わりなき最適化地獄

IT業界には特定の認知パターンを持つ人が集まりやすい。そのパターンごとに、燃え尽きの出方がまるで違う。

INTp（正確にはINTj＝LII）の主機能はTi（内向的論理）だ。Tiは純粋な論理的整合性を追求する。コードの構造が美しくないと気持ち悪い。冗長なコードを見ると書き直したくて我慢ができない。

これがリファクタリング沼という名のバーンアウトを生む。

機能としてはもう動いている。納品できる状態だ。でもINTpの脳が、ここの設計が気に入らないと叫び続ける。もっとエレガントに書けるはずだと、完成したコードを何度も書き直す。仕事の工数の半分がリファクタリングに消えていく。

プロダクトは進んでいないのに、INTp本人は猛烈に仕事をしている。でもその仕事は自分のTi的美学を満たすための作業であって、ビジネス上の価値を生み出していない。本当はこんなに無駄なことをしているのに、自分の能力が活かせていないという罪悪感と焦燥がじわじわと蓄積していく。

Qiitaの投稿で、あるバックエンドエンジニアがこう書いていたのが印象に残っている。

──リファクタリングをやめられなくなったのは、自分の書いたコードが汚いまま世に出ることが生理的に耐えられなかったからだ。でもそれで納期を3回ブチ壊した。お客さんが求めているのは美しいコードではなく動くプロダクトだった。

これは技術力の問題ではない。Tiのこだわりとビジネスの現実が構造的に噛み合わない問題だ。当サイトの診断データでも、Ti主導型のエンジニアユーザーのうち約6割が完成したコードを納品前にリファクタリングしたことがあると回答しており、うち3割が納期に影響したと答えている。

INTjの完璧な設計図症候群

INTj（正確にはINTp＝ILI）はNi（内向的直観）が主機能だ。Niは未来の完璧なビジョンを見据える能力であり、コードを書く前に最終形態がどうあるべきかの設計が脳内で完成していなければ着手できない。

これがアーキテクチャ麻痺を引き起こす。

完璧な設計が見えるまで手を動かさない。でも現実のプロジェクトでは要件はころころ変わるし、技術的な制約は日々更新される。INTjが描いた美しい設計図は、実装途中で何度も修正を迫られる。

本来はこうあるべきなのに、現実がそれを許さない。この理想と現実のギャップへの絶望がINTjを静かに蝕んでいく。完璧主義がバーンアウトを起こす構造の典型的なパターンでもある。

当サイトの診断データでは、Ni主導型のエンジニアユーザーのうち約7割が設計段階で過度に時間をかけてしまうと回答している。Se主導型の約2割と比べると差は歴然で、認知機能の仕様がそのまま仕事の進め方の癖に直結していることが分かる。

ISTjの静かな取り残され

ISTj（正確にはISTp＝SLI）のSi（内向的感覚）は、過去に蓄積した経験や知識を正確に保存・参照する機能だ。一度学んだ技術やベストプラクティスを丁寧に守る。

しかし技術の世界では、去年のベストプラクティスが今年のアンチパターンになることが日常的に起きる。ISTjが苦労して構築したシステムが、新しいフレームワークの登場によって一夜にしてレガシーと呼ばれる。

さらに厄介なのが、ISTj自身がレガシーコードの保守を真面目に引き受けてしまうことだ。責任感が強いSi-Teの配線が、誰かがやらなくてはと彼らを技術的負債の尻拭い係に固定する。やりがいのない保守業務を黙々とこなし続けた結果、気づいたときには自分のキャリアの技術スタックが時代遅れになっている。

この静かな取り残され感がISTjエンジニアの燃え尽きの核心だ。INTpが理不尽な上司にストレスを溜める構造とも共通するが、論理的に正しい仕事のやり方を押し通せない環境が、Ti/Te型のエンジニアを最も消耗させる。

X（旧Twitter）で現役のISTjと思われるインフラエンジニアがこう呟いていた。

──5年間保守をやり続けた結果、転職活動のときに自分のスキルが何もアピールできなくて愕然とした。真面目にやってきたのに、市場価値がゼロに近い。誰も保守エンジニアの価値なんか見てくれない。

正直、この投稿を読んだとき筆者はかなり胸が痛くなった。真面目さゆえに報われない構造は、本当に残酷だと思う。

ENFpエンジニアの飽きる地獄

あまり語られないが、ENFp（Ne主導型）のエンジニアにも独特の燃え尽きパターンがある。

ENFpは新しいプロジェクトが始まった瞬間のワクワク感が異常に強い。技術選定、アーキテクチャの議論、プロトタイプ開発。この初期フェーズではENFpのNeが猛烈に回転して、チーム内で誰よりもアイデアを出しまくる。

ところがプロジェクトが安定期に入り、実装とテストの地味な繰り返しフェーズに移行した途端、エネルギーがストンと落ちる。Neは新しい可能性の発見に特化した機能だから、同じことの反復にはバッテリーを供給してくれないのだ。

ガールズちゃんねるのIT転職トピックで、ある女性エンジニアがこう書いていた。

──新規開発のときは神みたいに仕事できるけど、保守フェーズに入ると途端にポンコツになる。自分でも怖い。転職のたびに新しい環境でハイになって、1年たつと辞めたくなるの繰り返し。

ENFpの燃え尽きは、同じ場所にいることへの窒息だ。ESTpの束縛嫌いとは また違う種類の自由への渇望がある。

チーム開発での認知摩擦

エンジニアの燃え尽きは、個人の認知パターンだけでなくチーム内の認知摩擦からも発生する。

INTpとISTjが同じチームにいると、コードの書き方一つで衝突が起きる。INTpは構造の美しさを追求したがり、ISTjは実績あるパターンの踏襲を重視する。どちらも論理的に正しい主張をしているのに、価値観のレイヤーで噛み合わない。

コードレビューのたびにじわじわとストレスが蓄積し、気づいたときにはPRを出すこと自体が億劫で仕方がなくなっている。これもバーンアウトの一形態だ。

当サイトの診断データでも、Ti主導型とSi主導型がチーム内にいるプロジェクトにおいて、コードレビューにストレスを感じると回答した人が約5割に上った。技術的な議論は健全に見えてペイロードに大量の感情的消耗が積まれている場合がある。

壊れる前にできること

エンジニアのバーンアウトは、本人が気づいたときにはかなり進行していることが多い。論理的な人間ほど、自分の感情的な消耗をデータとして認識しにくいからだ。

予兆のサインを言語化しておくと早期発見に役立つ。以下の3つ以上に心当たりがあったら黄色信号だと思ってほしい。

──以前は楽しかった技術記事やカンファレンスの動画を見る気が起きない。 ──PRを出す前のセルフレビューが苦痛でたまらない。 ──Slackの通知音が鳴るたびに胃が痛くなる。 ──土日に個人開発をする気力がまったくない。 ──コードを書かない日が続いても焦りを感じなくなった。

最後の一つが特に危険なサインだ。以前なら焦りを感じていたはずなのに感じなくなったということは、すでに感情の麻痺が始まっている可能性が高い。

完了の定義を外に置く

INTpの底なしのリファクタリング沼から抜け出すには、完了の定義を自分の内なる美学から強制的に切り離すしかない。

CIのテストが全部グリーン。要求された機能は動いている。PRのレビューもLGTMをもらってマージされた。この3条件を満たしたら、それはもう完了だ。たとえ自分の内なるTiがあそこのClass設計まだダサいじゃんと叫んでいても、物理的にPCを閉じる。

筆者もTi寄りの認知を持つ人間なので、この気持ち悪さは骨の髄まで分かる。でもMergeした後にエディタのタブを閉じてしまえば、翌朝には不思議とそこまで気にならなくなるものだ。完了とは完璧の同義語ではないと、意識的に脳内ルールを上書きしてほしい。

設計は仮説だと認める

INTjのアーキテクチャ麻痺には、最初の設計は仮説であり修正されることが前提だと腹を括ることが薬になる。Niが見せてくる美しい最終形態は、現時点ではあくまで仮説だ。まず動くものを作り、フィードバックを受けて設計を育てる。このアプローチに頭ではなく身体でシフトするまでが一番苦しいところだと思う。

技術のポートフォリオを分散する

ISTjの技術的取り残されは、現業務の保守に時間の100%を投入してしまうことから起きる。

週の20%、あるいは最低でも10%の時間を新しい技術のインプットに強制的に割り当てる。業務に直結しなくていい。触ったことのないフレームワークを動かしてみるだけで、自分のSiに新しい引き出しが追加される。取り残されている恐怖は、新しいデータがSiに入ってくるだけで大幅に軽減する。

---

エンジニアという職業を選ぶ人間には、ある種の共通点がある。問題を解くのが好きで、論理に信頼を置いていて、自分の技術力にプライドを持っている。

でもそのプライドと責任感が、自分自身を壊す燃料にもなる。コードは書けるのに自分の不調のデバッグだけは苦手だという皮肉。

今まさにコードを書く喜びを見失っている人がいたら、それはあなたの能力が消えたわけじゃない。エンジンの使い方が環境と噛み合っていないだけだ。自分のOSの仕様を知り直すことが、リブートの第一歩になる。

※本記事は自己分析のフレームワークであり、医療的アドバイスではありません。強い抑うつや意欲の著しい低下がある場合は、メンタルヘルスの専門機関への相談を優先してください。