SEの上流と下流は性格で分かれる──認知機能で読む工程別の適性マップ

SEの上流と下流、自分がどちらに向いているかは認知機能の構造でだいたい決まっている。向き不向きを無視してキャリアを進めると、得意なはずの仕事が苦痛に変わる。

上流に行きたいのに苦しい人

IT業界にいると、上流工程に行くことがキャリアアップだという空気がなんとなくある。要件定義ができるSEの方が単価も高いし、プロジェクトの全体像を描けるポジションの方がかっこいい。転職エージェントも上流経験ありますかと必ず聞いてくる。

でも実際に上流に移ったSEの中で、こんなはずじゃなかったと感じている人は意外と多い。IPAの統計によると、IT人材の約4割が現在の業務内容に不満を感じているというデータがある。そのうちかなりの割合がポジションの変化に伴うミスマッチを原因に挙げている。

SIerのキャリア構造には根深い問題があると思っている。下流→上流→PM→管理職という一本道のラダーが、全員に適用されていることだ。下流が得意で下流で最高のパフォーマンスを出せる人に、上流への異動が昇進として提示される。本人は嘘しいけど、実は其職から引き剥がされていることに気づいていない。

ある転職サイトの口コミにこういう投稿があった。コードを書いていた頃は没頭できていたのに、上流に回されてからは会議とドキュメントだけの毎日で、何のためにエンジニアになったのかわからなくなった──。その投稿には100以上の、わかるという反応がついていた。

これらは能力の問題ではなく、認知機能と工程の相性がズレているだけだ。

上流で活きる認知機能

Ne-Te型は要件定義の申し子

Ne（外向的直観）とTe（外向的思考）が上位に来るタイプ──ENTj、ENTpあたりは、上流工程の仕事と認知機能がかなり高精度に噛み合う。

Neは可能性を広く拾う機能だから、クライアントの曖昧な要望やまだ言語化されていないニーズを、こういうことですかと具体的な形にするのがうまい。相手の話を聴きながら、頭の中では3つくらい並行して仮説を走らせている。クライアントが本当の要望を言語化できないことの方が多いから、Ne型の先回り力は上流工程で圧倒的なアドバンテージになる。

Teは外に向けた論理構築の機能だ。仮説を構造化して、スケジュールに落とし込んで、リソース配分を決める。意思決定が速くて、曖昧な状態を曖昧なままにしておくのが生理的に無理なタイプでもある。要件定義で白黒つかない項目が残っていると、それが気持ち悪くて自分から確認に動く。

弊社の診断でNe-Te型と判定されたSEへのヒアリングでは、要件定義の打ち合わせが一番楽しいという声が多い。何もないところから構造を作る過程が快感だと。ゼロからイチを描く作業にドーパミンが出るのだ。逆に、誰かが作った仕様書通りにコードを書くだけの仕事だと、数ヶ月でエネルギーが枯渇する。

Ne-Te型の弱点は、決めたあとの細かい修正や保守に興味が持てないこと。新しいプロジェクトの立ち上げは最高に楽しいけれど、同じシステムの改修が3年続くと飽きてしまう。

Fe-Ni型は調整型PMに進化する

Fe（外向的感情）とNi（内向的直観）の組み合わせ──ENFjやINFjタイプは、上流工程の中でもステークホルダー間の調整や合意形成で力を発揮する。

Feは場の空気を読んで、誰が何を言いたそうにしているか察知する。会議で発言できていない人にさりげなく話を振る。クライアント側の担当者が上司の前で本音を言えない場面で、休憩中にそっと聞き出す。Niは長期的なビジョンを直観的に描く。この組み合わせがあると、クライアントの本音とチームの実力の間に落としどころを見つけるのがうまくなる。

ただしこのタイプは、純粋な技術的要件定義よりも、人を動かすプロジェクトマネジメント側にキャリアが流れていく傾向がある。それが嫌ではないならいいけれど、技術を深掘りしたかった人にとっては、いつの間にか違う道を歩いている感覚になるかもしれない。気がついたら技術の話より人の話ばかりしている自分に、ちょっとした寂しさを感じるFe-Ni型SEは少なくないと思う。

Ne-Te型の意外な落とし穴

Ne-Te型が上流で最強かというと、実はそうでもないケースもある。要件定義の初期フェーズで可能性を広げすぎて、プロジェクトが肥大するパターンだ。Neがあれもできる、これもできると可能性を広げすぎて、スコープが膨らみ、納期も予算も破綻する。Teが組織化しようとしても、Neが広げた風呂敷が大きすぎてカバーできない。

Ne-Te型の上流SEに必要なのは、Si的なモデレーターの存在だ。過去のプロジェクトの失敗パターンに基づいて、ここは削りましょうとブレーキをかけてくれる人がいれば、Ne-Te型は本当の意味で上流のエースになれる。

下流で本領を発揮する認知機能

Ti-Si型は品質の番人になる

Ti（内向的思考）とSi（内向的感覚）──ISTjやISTpタイプは、下流工程で驚くほどの精度を出す。

Tiは内部の論理整合性に異常なほどこだわる。コードの記述ルールが統一されていないと気持ち悪い、関数の命名規則に一貫性がないと直したくなる──そういうレベルの几帳面さが、実装とテストの品質を支えている。リファクタリングに没頭して気づいたら4時間経っていた、みたいな集中力はTi型ならではだ。

Siは過去のデータを正確に保持する機能だから、以前やったプロジェクトのバグパターンや、過去の障害発生条件を鮮明に覚えている。テスト設計で穴を見つけるスピードがTi-Si型は異常に速い。このパターンは去年のあのプロジェクトでも見たぞ、という経験則が蓄積されていて、それが品質の防波堤になっている。

このタイプが上流に配置されると、クライアントとの会話で疲弊することが多い。曖昧な要望を解釈するNe的な能力はTi-Siの得意分野ではないし、合意形成のために正論を曲げるような対応も性に合わない。自分が正しいと思っている仕様を、政治的な理由で変更させられることに強い抵抗を感じるのだ。

ある社内SEが話してくれたのだけど、上流に異動させられて半年で体調を崩し、下流に戻してもらったら途端に元気になったという。スキル不足ではなく配置ミスだったのだ。

Ti-Si型が上流に配置されてしまった場合の対処法もある。曖昧な要件を扱うときに、Tiの論理的な分解力を使って要件を小さなパーツに分解し、Siの正確さで一つずつ潰していく。大きな絵を描くのはNe-Te型に任せて、それを実装可能なレベルに分解する役割を担う。これならTi-Si型は上流でも生き残れる。問題は、そういう役割分担をにしてくれる上司がいるかどうかだけど。

Se-Ti型は火消し屋として最強

Se（外向的感覚）とTi──ESTpタイプは、本番障害やリリース直前のトラブルシューティングで本領を発揮する。

Seは今この瞬間の状況を高速に認識する。ログを読みながら同時にサーバーの状態を確認し、体感的にどこが怪しいかを瞬時に判断する。Tiがそれを論理的に裏付けて、最短ルートで原因を特定する。緊急対応中のSe-Ti型は、まるでゾーンに入ったアスリートのようだ。

日常的なコーディングだとSe型は退屈してしまうことがある。同じコードベースを半年触り続けるような保守案件だと、刺激が足りなくて集中力が持たない。でも緊急対応やデバッグの局面では圧倒的な集中力を発揮する。このタイプにとって下流工程とは、ルーティンの実装ではなくトラブルを解決するゲームなのだ。

SREやDevOps、プラットフォームエンジニアリングのように、常に何かが起きる可能性がある領域とSe-Ti型の相性は抜群にいい。あるインフラエンジニアが話してくれたのだけれど、障害対応で夜中に叩き起こされるのを、ストレスではなくむしろアドレナリンが出ると感じると。これはSe型ならではの感覚で、Si型が同じ状況に置かれたら平常心ではいられないだろう。

キャリアの方向を間違えないために

昇進がキャリアとは限らない

IT業界の暗黙のキャリアラダーは、下流→上流→PM→管理職という一本道になっていることが多い。でもこのラダーに全員が乗るべきかというと、認知機能的にはまったくそんなことはない。

Ti-Si型にとっては、技術のスペシャリストとして深掘りし続ける方が成果も出るし精神的にも健全だ。最近はIC（Individual Contributor）という役職を用意する企業も増えているし、アーキテクトやテックリードとして管理職と対等なポジションに就くキャリアパスもある。

Se-Ti型は、SREやプラットフォームエンジニアのように緊急対応と改善を繰り返すポジションが合うかもしれない。毎日同じことの繰り返しにならない環境で、刺激と問題解決の快感を維持できる。

上流が偉くて下流が下、という序列は認知機能の観点からすると完全に間違いだ。それぞれの工程に求められる情報処理の回路が違うだけで、どちらが上ということはない。

自分の認知機能を特定してから動く

キャリアの方向転換を考えているなら、まず自分の認知機能のスタックを正確に把握した方がいい。Ne-Teが強いのかTi-Siが強いのかで、取るべき選択はまるで変わる。

コードを書いている時間が一番集中できるならTi型の可能性が高い。クライアントとの打ち合わせでアイデアが湧いてくるならNe型かもしれない。チームの人間関係を整えるのが得意ならFe型で、障害発生時にアドレナリンが出るタイプならSe型だろう。

ここで、下流から上流に移りたいSEに向けて、もう少し具体的な話をしておきたい。転職市場では上流経験が単価に直結するから、上流に行きたいという気持ちはわかる。でもその前に自問してほしい。

曖昧な要望を具体化する作業は楽しいか。会議で合意形成を取るプロセスは苦ではないか。ドキュメント中心の仕事に充実感を感じられるか。クライアントとの関係構築にエネルギーが湧くか。

これらにイエスと答えられるなら、上流は向いているかもしれない。でも全部ノー」に近いなら、上流に行くことが本当にキャリアアップなのか考え直した方がいい。単価のために向いていない工程に移るのは、給料が上がるかもしれないが精神の健康を損なうリスクがある。

実際に、下流から上流に移ったことで燃え尽きて、エンジニア自体を辞めてしまった人を何人か知っている。下流で続けていれば、今も第一線でコードを書いていたかもしれないのに。キャリアアップの名の下に、才能を殺してしまう昇進がある。それを避けるための最初の一歩が、自分の情報処理パターンを特定することだ。

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