SEの上流工程が辛い理由──能力不足ではなく認知OSのミスマッチ

「プログラミングは好きだし技術力には自信がある。でも、顧客との要件定義やプロジェクト間の社内調整を任されるようになった途端、毎日吐き気がするようになった」

システムエンジニア（SE）として順調にキャリアを積み、「そろそろ上流工程を任せる」と上司から言われて絶望の淵に立たされているあなた。 プログラマーとしての市場価値を上げるには上流に行かなければならない、という業界の強迫観念に縛られて、「人間関係の調整ができない自分は無能なんじゃないか」と自己肯定感をすり減らしていないだろうか。

はっきり言う。あなたの技術力や能力が足りないわけじゃない。 ただ、コンピューターのコードを書くOSと、人間のドロドロした感情を調整するOSの「互換性」が1ミリも無いだけなんだ。

コードを書く方が100倍楽な理由

X（旧Twitter）のエンジニア界隈を覗けば、「一生コードだけ書いていたい」「客先交渉に行くくらいなら給料が下がってもいい」という悲痛な声が毎日大量に流れてくる。

彼らは技術から逃げているわけじゃない。 むしろ複雑なアルゴリズムを解読し、バグの原因を一晩中かけて特定するような知的な持久力は、他のどの職種よりもズバ抜けて高い。 彼らが耐えられないのは、仕様書には書かれていない「クライアントの顔色」「声の大きい部署の機嫌」「論理の欠片もない社内政治」といった、ノイズばかりの非論理的な変数だ。

コードは嘘をつかない。Aを入力すれば必ずBが返ってくる。エラーが出れば、必ずどこかに論理的な原因が存在する。 でも「人間」というシステムは違う。昨日Aと言っていた顧客が今日は平気でBを要求してくるし、その理由も「なんとなく気が変わったから」「部長がそう言ったから」という、論理的デバッグが不可能なものばかり。 ここに、SEを苦しめる認知負荷の正体がある。

論理構築(Ti)と感情調整(Fe)の溝

私たちの提供するソシオニクス理論でこの苦しみを構造化すると、非常にクリアな答えが出る。

優れたエンジニアの多くは、**内向的論理（Ti）**という认知機能を主軸に置いている。 Tiは、物事の矛盾を許さず、自分の中で完璧な論理の城を築き上げる機能だ。だからこそ、美しくて堅牢なコードが書ける。

一方で、上流工程（顧客折衝や調整）で最も要求されるのは、**外向的感情（Fe）**という機能だ。 Feは「その場の空気を読み、他人の感情に共鳴し、論理が破綻していても『みんなが気持ちよく動けること』を最優先にする」機能。 なんと、TiとFeは脳内でシーソーのような関係にあるんだよ。 Ti（論理）を極めれば極めるほど、Fe（感情調整）の機能は脳の奥底に押し込められ、一番苦手でストレスのかかる「アキレス腱」になる。

つまり、「卓越したコードを書けるエンジニアに上流工程をやらせる」というのは、F1マシンにオフロード用の泥除けタイヤを履かせて「さあ山道を走れ」と命令しているのと同じことなんだ。車体（OS）の設計思想が根底から衝突している。 上流工程で優秀な人が、必ずしも優れたコードを書けるわけではないように、その逆もまた然り。どちらが上という階層の話ではなく、完全に別職種のOSだということだ。

自分のOSに合った戦い方を探す

人事・組織開発の目線から見ても、優秀なプログラマーを「出世」という名目で無理やりマネジメントや折衝の最前線に配置転換するのは、会社にとっても個人にとってもキャリアの殺人行為に等しい。

「上流に行けないならSEとして底辺だ」という古い産業構造の価値観は捨てよう。 現代はスペシャリストとしてコードとアーキテクチャ設計に特化して生き残るパスがいくらでも存在する。 あなたに必要なのは、「苦手なFeを気合いで克服して、人間関係の泥沼で耐えること」ではなく、自分のTi（論理的追求）を100%発揮できる環境へ「戦略的撤退」をすることだ。

もし今の職場で「上流に行かないなら評価しない」という体制なら、それはあなたのOSが死ぬ「NG環境」でしかない。 自分がどのような上司やチームと組むべきか（相性がいいのは未来を描くNeか、それとも現実の実行部隊Siか）を知ることは、エンジニアとしての寿命を決定づける。

自分が本当にTi主導のOSなのか。あるいは、本当は別のエンジン（例えばTe：効率化）を積んでいるからこそ、別の不満を抱えているのか。 あなたのキャリアを他人の都合で破壊されないために、まずはAqsh Prismaのフル診断で自分の脳の設計図を客観的に把握してみてほしい。 システムのバグは、システムを理解するところからしかデバッグできないのだから。

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