システムエンジニアとして仕事を始めて20数年。自分が「HSP気質」であると気づいたのは、ここ10年ほどのことだ。
HSP気質は生まれ持った気質ゆえに治すことができず、その繊細さゆえに生きづらさを感じることも少なくない。私自身、若い頃はその特性を知らないまま働き、何度も心が折れそうになった。
しかし、この気質はうまく使いこなせば、エンジニアの仕事において強力な武器になる。「HSPはSEに向かない」という声をネットで見かけることもあるが、それは一面的な見方に過ぎない。今回は、日々の現場シチュエーションの中で、HSP気質がどのように活かせるのか、私の実体験を交えて4つご紹介したい。
1. プログラミングに超集中できる
今振り返ると、プログラミングはHSP気質に非常に向いている作業だった。
新人から10年目くらいまで、私は主にプログラミングに没頭していた。基本的には、設計の確認やソースレビューを除けば、1人で黙々とコードと向き合う時間が長い。多数の人と関わりを持つと消耗してしまうHSPにとって、この「1人の作業時間」は心地よいものだ。
しかも、HSP特有の「細かいことに気づく力」が加わると、作成したプログラムの細部にあるバグや矛盾点に自ずと目が届く。私自身、プログラミングをしている時は非常に生き生きしており、早く会社に行って続きを作りたいと感じるほど楽しかった。
2. 個人のテストも、チームのテストもうまく回せる
プログラムの作成後に行う単体テスト、結合テスト、総合テスト。このプロセスでもHSPの特性は大きな強みになる。
- 単体テスト（1人の作業）： プログラミング同様、1人で集中して進められるため、細かな気づきを活かしてバグを根気強く潰していくことができる。
- 結合・総合テスト（チームの作業）： チームメンバーや顧客、他部署の担当者と一緒にテストを進める際、相手の微細な機微を察知する力が活きる。相手が「どこに疑問を感じているか」「何をやりたがっているか」をいち早く察知して会話に混ぜることで、周囲からの信頼を得やすく、テスト全体をスムーズにリードしていくことができるのだ。
3. リリース時の「不安」が、トラブルを未然に防ぐ
システムのリリースは、いつだって緊張を伴う。ちょっとしたミスが大きなトラブルに発展しかねないからだ。
HSP気質の人は、不安感が強いあまり「もしこうなったらどうしよう」と最悪のシナリオを先回りして考えがちだ。パニックになりがちというデメリットはあるが、一旦冷静になると、その思考の深さがトラブルにつながるミスを発見するきっかけになる。
- 「このファイルをこの場所に置いたら、挙動はどうなる？」
- 「こことこここでデータの整合性は本当に取れているか？」
こうした予感に従って事前に確認し、何度危機を救われたことか分からない。 ここで一つ注意したいのは、「自分のミスを見つけた時に報告をためらわないこと」だ。怒られることやネガティブな反応を恐れて隠したくなる気持ちは痛いほど分かるが、後から大トラブルに発展する方が何倍もダメージが大きくなる。リリース前であれば、気づいた時点で「早く報告する」のが鉄則だ。気づけた自分をまずは褒めて、すぐに共有しよう。
4. メンバーの小さなサインに気づける「リーダーシップ」
HSPの人は「失敗したらどうしよう」という不安がある一方で、うまく使いこなせば管理職やリーダーシップを発揮する大きな才能を秘めている。他人の感情の機微を鋭く察知できるため、メンバーの異変にいち早く気づけるからだ。
例えば、以下のような場面でそれが活きる。
- タスクの進捗確認での気づき： メンバーに任せたタスクの進捗を聞いている際、報告の言葉は「問題ありません」と言いつつも、表情の曇りや不自然な間（ま）に気づき、声をかけると「実は指示と違う方向で進めており、行き詰まっていた」ということが発覚する。放置していれば手遅れになるところを、早期にリカバリーできる。
- ドキュメントレビューでの気づき： メンバーが修正してきたドキュメントを見て、まだ納得いっていなさそうな表情に気づき、理由を尋ねると「顧客の意図と少しズレている気がして、そのまま直すべきか悩んでいた」と分かる。結果的に顧客に再確認し、より良い形にブラッシュアップできた。
他人の感情を過剰に感じすぎてしんどくなるというデメリット（これについてはまた別の機会に書きたい）はあるが、相手との境界線をしっかり持つことを覚えれば、HSP気質はチーム運営において絶大な強みになる。
まとめ
HSP気質であっても、エンジニアとして十分に、そして有利に戦っていくことはできる。
ネットの定説に惑わされず、自分の特性を正しく理解し、適材適所で活かしていくこと。これからも、HSP気質を持つシステムエンジニアが少しでも働きやすくなるような知恵を発信していきたい。
