エンジニアに向いてる性格とは──認知機能で読み解くIT適職マップ

エンジニアに向いてる性格はINTjやINTpだと言われがちだけど、それは半分しか合っていない。IT業界には設計もあれば実装もあるし、インフラもPMもある。向いてる性格はポジションによってまるで違う。

適性神話と現実の乖離

IT業界の離職率は15.4%（厚生労働省・令和4年雇用動向調査）で、全産業平均とほぼ同水準。ただし注目すべきは入社3年以内の離脱率で、特にSES（客先常駐）から始めた若手エンジニアの3割以上が3年以内に業界を離れているとするデータもある。

Qiitaに投稿されていた元エンジニアの記事が印象に残っている。どれだけ休日にITスキルの勉強をしても仕事が上達しなかった。周りのエンジニアは楽しそうにコードを書いているのに、自分だけが苦痛だった──と。

この苦痛の正体を認知機能で読み解くと、構造がクリアになる。

プログラミングが生理的に合う人は、Ti（内向的思考）が主機能か補助機能にあるケースが多い。Tiは体系を自分の中で組み立てる機能で、コードの論理構造を頭の中で回しながら整合性を確認する作業がTiの得意領域そのものだ。INTp（Ti-Ne）やISTj（Ti-Se）がバックエンドの設計やアルゴリズム設計で力を発揮するのは、Tiが自然に稼働する環境だから。

逆にFe（外向的感情）が主機能のENFjやESFjがプログラミング主体の業務に配属されると、かなり苦しい。Feは人の感情を読む機能であって、コンパイラのエラーメッセージに共感はできない。Feが強い人がエンジニアをやっている場合、プログラミングそのものではなく、チーム内のコミュニケーション調整やクライアント折衝に認知リソースが向かっていて、コードは義務として書いている状態になりやすい。

弊社の診断データでIT業界ユーザーの認知機能分布を調べたところ、Ti主導型が全体の42%を占めていた。次いでTe主導型が28%。逆にFe主導型は8%に過ぎない。この偏りが、Fe型エンジニアの孤立感の背景になっている。

認知機能別のIT適職マップ

エンジニアという職種をひとくくりにするから向き不向きの話がぼやける。ポジション別に見ると、求められる認知機能がはっきり違う。

Ti型（INTp、ISTj）は、バックエンド開発やアルゴリズム設計との相性が抜群にいい。データ構造の整合性を内側で検証し続ける作業がTiの自然な動きだから、長時間のコーディングでも消耗しにくい。ただしTi型はドキュメントを書くのが苦手な人が多い。自分の頭の中では完璧に構造化されているのに、それを他人に伝えるFe的な作業が億劫になる。コードは美しいのにREADMEが3行しかないというのはTi型あるあるだ。

Te型（ENTj、ESTj）は、プロジェクトマネジメントやテックリードとの相性が高い。Teは外部に向かって効率的に物事を組織化する機能で、タスクの優先順位づけ、リソースの配分、デッドラインの管理がTeの得意領域。コードを書く力よりも、コードを書く人たちを束ねる力でIT業界に居場所を見つけるパターンが多い。

弊社の診断ユーザーでTe型のエンジニアが最もストレスを感じていたのは、自分で手を動かさずに部下の成果を待つ時間だった。Teは制御欲求が強いから、自分でやったほうが早いという衝動と管理職の役割が常にぶつかる。

Se型（ESTp、ESFp）は意外かもしれないがインフラやSREとの相性がいい。本番環境の障害対応はSe型の独壇場で、目の前で起きている事象にリアルタイムで反応する能力はSeならでは。障害発生→原因切り分け→暫定対応→恒久対応のサイクルをSeの瞬発力で回していく。一方でSe型が設計フェーズの長い書類作りをやらされると途端にストレスが上がる。先が見えないロードマップよりも、今燃えている火を消すほうが性に合っている。

Ni型（INFj、INTj）はアーキテクト職やCTO的なポジションとの相性がいい。Niは長期的なビジョンを描く機能で、3年後のシステム全体像を頭の中で構築してから逆算して現在の設計に落とす作業がNiの得意技だ。ただしNi型はプロトタイプを早く出すアジャイル開発よりも、じっくり設計してからコードを書くウォーターフォール的なアプローチを好む傾向がある。アジャイルが主流の現場ではNi型のペースと開発サイクルのテンポが合わず、常に急かされている感覚に陥りやすい。

Ne型（ENFp、ENTp）は技術選定や新規事業のPoC（概念実証）で力を発揮する。新しいフレームワークやサービスの可能性をいち早く嗅ぎつけてプロトタイプを作る速度はNe型が圧倒的に速い。ただしNeは興味が拡散するため、一つのプロダクトを長期メンテナンスし続ける運用保守には向いていない。レガシーコードの改修をNe型に任せると、既存コードを捨てて全部書き直したいという衝動と闘い続けることになる。

Fi型（ISFp、INFpなど内向的感情が強いタイプ）はフロントエンドやUI/UXデザインと相性がいい。Fiは内側の美的価値基準を持っている機能で、ユーザーにとって感覚的に気持ちいいインターフェースを直感で判断できる。CSSのピクセル単位の調整にこだわるフロントエンドエンジニアにFi型が多いのは、仕上がりの美しさに妥協できないFiの特性が反映されている。ただしFi型はコードレビューで論理的に否定されると個人攻撃と感じやすい。自分のコードは自分の表現だからだ。Fi型のコードレビューでは何がダメかだけではなく、ここは良いうえでここを変えるとさらに良くなるという伝え方がチーム運用上は大事になる。

Si型（ISFj、ISTjなど内向的感覚が強いタイプ）はQA（品質保証）やテストエンジニアとの適合度が高い。Si型は細部の正確さと反復作業の忍耐力に長けていて、テストケースの網羅性を担保する仕事が認知的にフィットする。バグを見つけると過去のバグパターンとの照合がSi型の中で自動的に走るから、同じ原因のバグの再発を防ぐ能力が高い。ただしSi型は新しい技術スタックへの移行に時間がかかる。慣れた環境でのパフォーマンスは最高だけど、毎年フレームワークが変わるようなチームだとSi型のキャッチアップコストが上がる。

チーム構成と認知の多様性

優秀なエンジニアチームは単一の認知タイプで構成されない。Ti型ばかり集めると、全員がコードを書くのは速いけど誰もドキュメントを書かないし、誰もスケジュール管理をしない。逆にTe型ばかり集めると管理層ばかりで手を動かす人がいなくなる。

理想的な開発チームの認知機能構成を挙げるなら、Ti型2-3人（実装の主力）、Te型1人（PM/リード）、Ne型1人（技術選定/イノベーション担当）、Si型1人（QA/テスト）、Fe型1人（チームのコミュニケーションハブ）。このバランスが取れたチームは、開発速度・品質・チームの持続可能性の3つが同時に成立する。

弊社の診断を導入しているあるスタートアップでは、エンジニア採用時に認知機能のバランスを考慮したところ、チームの離職率が前年比で30%改善したと報告があった。何をしたかというとTi型が5人中4人だったチームにFe型のスクラムマスターを1人入れただけ。Feが入ることで、Ti型同士が言語化を省略して暗黙知で進めていたプロセスが可視化され、ミスコミュニケーション由来のバグが減った。

辞めたいときの分岐点

エンジニアを辞めたいと思ったとき、一番大事なのはITそのものが無理なのか、今のポジションが無理なのかを分けること。

note.comに投稿されていた元SESエンジニアの話が象徴的だった。コーディングが苦痛で毎日辞めたかったけれど、転職してPMになったら仕事が楽しくなった。コードを書く能力ではなく人と調整する能力を使う仕事のほうが自分に合っていた──と。これは典型的なFe型やTe型がTi型向けのポジションに配属されていた例だ。

弊社の診断ユーザーでエンジニアからPMに転身した人のうち、Te型とFe型が合わせて7割を超えていた。逆にTi型でPMに転身した人は、テクニカルな判断は速いけどメンバーの感情ケアで消耗するという声が多かった。

もしTi型でコードを書くこと自体は嫌いじゃないけど環境が辛いなら、リモートワーク比率の高い企業や、少人数チームの開発環境を探すほうが、職種を変えるよりストレス低減効果が高い。Ti型のストレス源は大抵、技術力の問題ではなく対人コミュニケーションのコストだ。

Se型で運用保守に疲弊しているなら、障害対応やパフォーマンスチューニングに特化したSRE専門チームへの異動を検討する価値がある。Seの瞬発力が最も活きるのは計画的な改修ではなく即時対応が求められる場面だから。

Ni型であれば、社内のテクニカルアドバイザーやアーキテクト専任ポジションを狙うのが認知機能の使い方として最も合理的。Ni型はコードを書く速度では勝負できなくても、システム全体の設計力で替えが利かない存在になれる。

業界外に出る選択肢

認知機能を軸に考えると、IT業界を離れる判断も構造的にできる。

Fe型でエンジニアが辛い場合、IT知識を活かしたカスタマーサクセスやテクニカルサポートのほうが認知機能の自然な使い方になる。技術を自分で作るのではなく、技術と人をつなぐ翻訳者の役割。ITリテラシー×Feの共感力は、SaaS企業のCSポジションで高く評価される組み合わせだ。

Ne型でモノづくりの衝動が止まらないけど一つのプロダクトに集中できないなら、スタートアップのゼロイチフェーズや、フリーランスで複数プロジェクトを並行する働き方のほうがNeの拡散力が武器になる。

はてなブックマークで話題になっていた元エンジニアのブログには、エンジニアを辞めたことを後悔している理由として年収が下がったこととリモートワークができなくなったことが挙がっていた。認知機能の問題で辞めるなら、同じIT業界の中でポジションを変えるほうがこの2つのリスクを回避できる。辞めてから後悔するパターンの多くは、ITそのものではなく特定のポジションの問題を業界全体の問題とすり替えてしまったケースだ。

転職面接でエンジニアとしての強みを語るとき、認知機能を軸にすると解像度が上がる。私はTiが強いのでバックエンドの設計で力を発揮しますとは言わなくてもいいが、一人で黙々とコードを書く環境で最もパフォーマンスが出やすいですとか、システム全体のアーキテクチャを設計する仕事に情熱を持っていますという言い方は、認知機能の言語を翻訳したものだ。自分のOSを知っていれば面接での自己表現の精度が上がるし、入社後のギャップも減る。

24年間キャリア支援に携わってきて感じることがある。エンジニアに向いてないと悩む人の大半は、自分の認知機能と今のポジションのミスマッチに気づいていないだけだ。自分のOSの特性を知れば、同じIT業界の中でも消耗しないポジションは必ず見つかる。

※本記事は自己分析のフレームワークであり、医療的アドバイスではありません。