【HSPとエンジニア】──繊細な人が開発現場で壊れる構造

HSP（ハイリー・センシティブ・パーソン）など、人に気を遣いすぎる繊細なタイプの人は、対人関係のストレスが少ないエンジニア職に向いている。 ネット上の適職診断や転職サイトでよく見かけるこの耳障りの良い文句を見て、未経験から高いお金を払ってプログラミングスクールに通い、晴れてエンジニアになったものの、半年経たずに心を病んで休職してしまう。 こうした残酷なケースが、私たちのキャリア相談の現場では後を絶ちません。

結論から言えば、現代のシステム開発の現場は、HSP気質の人（性格の認知機能で言えば、感情機能であるF型をメインに使う人々）にとって、ある種のスラム街のような過酷な生態系です。 彼らが自分はエンジニアに向いていないと絶望するのは、決してプログラミングの言語やアルゴリズムが理解できないからではありません。コード以外の部分で発生する強烈な心理的過負荷が、彼らの繊細なOSをショートさせてしまうのです。

コード以外の重圧

世間の多くの人が誤解していますが、現代のエンジニアリングは「綺麗なオフィスで一人で黙々と設計図通りに物を作る」仕事では決してありません。 終わりのないアジャイル開発によるスケジュールのプレッシャー、ビジネス側からの理不尽で曖昧な要求変更、そしてチーム内での容赦ないソースコードのたたき合い（コードレビュー）。 そこにあるのは、一人作業ではなく、高度な論理を通じた激しいコミュニケーションの格闘技です。

HSPの人々が持つ、他人の感情の機微を察知する鋭すぎるアンテナは、この格闘技のリングの中では、ただサンドバッグのように他者からの刺激を全裸で受け続けるためのマイナス機能として働いてしまいます。 では、彼らの認知機能のどこが、開発現場の何とバグを起こしてしまうのか。現場で起きている生々しい現実を見ていきましょう。

壊れる認知機能

HSPという言葉は学術的な性格分類（16タイプ診断など）とは厳密には異なりますが、多くの場合において、外部の感情を強く受信するFe（外向的感情）や、内面の価値観を重んじるFi（内向的感情）、そして過去の経験や安定を重視するSi（内向的感覚）が強く出ているケースと重なります。

Fe型のレビュー恐怖

システム開発において絶対に避けて通れないのが、自分が書いたコードを他のエンジニアに見てもらい、指摘を受ける「コードレビュー」あるいはGitHub上での「Pull Request（PR）」です。 優秀なエンジニアであればあるほど、ここは無駄が多い、なぜこんな可読性の低い設計にしたのかと、論理的でストレートな指摘を（悪気なく）バシバシと書き込んできます。

Fe機能が強い人にとって、この指摘は単なる「文字」や「技術的なアドバイス」としては処理されません。 赤字でびっしりと書かれたマウンティングにも近いレビューコメントを見た瞬間、彼らは自分の能力を全否定された、自分はチームのお荷物だと思われている、先輩を怒らせてしまったといった強烈な感情の波を強制受信してしまいます。 ただコードの欠陥を指摘されただけなのに、自分の人格や存在そのものが否定されたように感じてしまい、レビューをもらうたびに心拍数が跳ね上がり、ひどい時には吐き気すら催すようになります。

Si型の仕様変更負荷

また、内向的感覚（Si）が強い人にとって、現代主流となっているアジャイル開発（走りながら仕様をどんどん変えていく手法）は、まさに地獄のデスマーチです。 Si型は、あらかじめ決められた明確なゴールと仕様に向かって、着実にレンガを積み上げていく作業に最も安心感を覚えます。 しかし現実の現場では、昨日決まった仕様が、今日の朝の会議でクライアントやプロダクトマネージャーの鶴の一声で完全に覆る、といった理不尽が日常茶飯事です。

せっかく寝る間を惜しんで積み上げたはずのレンガを突然、やっぱりこれ全部壊して別のものにしてと無慈悲に蹴り飛ばされる。 この不確実性と徒労感は、Si型にとって単なる作業のやり直しではなく、自分の積み上げた秩序ある世界そのものを根本から破壊される凄まじいストレスとなります。

攻撃的なT型文化

そして何より、エンジニアの組織文化の中核を担っているのは、論理と効率を至上命題とするT型（思考タイプ）の人々です。 彼らの日常のコミュニケーションは、何が正しいか、いかに無駄がないかが絶対的な正義であり、そこに相手の気持ちへの配慮や空気を読むといったファジーな感情の要素が入り込む余地はありません。 仕事に向いてない理由の解剖の中でも述べていますが、T型のドライな正論が飛び交う殺伐とした空間は、HSP気質（F型）の人間にとっては、真冬の吹雪く屋外に全裸で立たされているのと同じレベルの冷酷さを手加減なしに浴び続けることになります。

生存戦略と処方箋

もしあなたが今、開発現場で心を壊しそうになっているなら、もっと図太くならなければと自分のOSを憎み、精神論で乗り越えようとするのはやめてください。 あなたの才能を活かすための生存戦略は、図太くなることではなく、戦う土俵と解釈のフレームを変えることにあります。

コードと人格の分離

第一に必要なのは、強引にでも「自分の書いたコード」と「自分自身の人格」の間に分厚い境界線を引くという訓練です。 T型の先輩がレビューで厳しいダメ出しをしてきた時、彼らはあなたのことを嫌っているわけでも、バカにしているわけでもありません。本当にただ純粋に、コードという物体の不具合を直そうとしているだけなのです。 車を修理に出した時に「ここのブレーキパッドが摩耗してますね」と言われて、自分が怒られていると感じる人はいないでしょう。それと同じです。指摘はあくまで修理報告であって、あなたの人間性へのダメ出しではないという認知の書き換えを、意識的に行ってください。

F型が輝ける領域へ

また、私たちが勧める多くは、同じIT業界でも、ゴリゴリのバックエンド開発やインフラ構築といった論理の純度が高い領域から、少し人間側に近い領域へとシフトするという戦略です。 たとえば、ユーザーの感情や使いやすさを考えるUI/UXデザイナー、クライアントの要望を丁寧に汲み取るカスタマーサクセス、あるいはチーム内の調整役となるスクラムマスターなどへのキャリアチェンジです。 HSPの持つ「他者の痛みに気づく力」や「空気を読む力」は、機械向けの仕事ではなく、人間向けの仕事において圧倒的な武器となります。

環境選びの条件

そして最終的には、所属する組織のカルチャー選びにすべての命運がかかっています。 どうしてもエンジニアを続けたいのであれば、技術力よりも何よりも、心理的安全性やコミュニケーションの丁寧さを評価軸にしている会社を血眼になって探してください。 面接の場で「チーム内でコードレビューをする際のルールはありますか？」と質問し、そこに言葉遣いへの配慮が含まれていないようなら、どんなに給与が高くても辞退するべきです。

自分の性格に疲れる本当の理由をもう一度読み直してみてください。 繊細さは治すべきバグではなく、高感度センサーという立派なハイスペック機能です。そのセンサーが四六時中鳴り響くような毒の沼地で無理に呼吸をするのではなく、センサーが綺麗に機能する透き通った水の世界へ、自ら環境を移す勇気を持ってください。

※本記事は自己分析のフレームワークであり、医療的アドバイスではありません。強い抑うつや心身の不調が続く場合は、専門の医療機関や公的相談窓口への受診を優先してください。