エンジニアを分類する3タイプから考える自身のタイプとその先と

以下を多分に引用して記す。

「技術の人は技術の本質を追求しテックリード/アーキテクト、プロダクトの人は技術を手段と割り切りフルスタックエンジニア/PdM、組織の人は開発生産性を高めようとEM/PMOを目指すことが多い」とのこと。そのことについて突っ込んで書かれた記事。

3タイプ

3タイプについて見やすくまとめる

前提：エンジニアとしての志向性を以下３つに分類すると目指すキャリアが考えやすいと言う話

※この3つのタイプはスキルの絶対量ではなく、何を「目的」とし、何を「手段」とするかというスタンスの違いとのこと
※どの志向性が自分は強そうかというバランスとしてとらえておくと良い

3タイプとその特徴等まとめると以下

技術が好きな人
- 目的：技術の本質を追求すること
- 手段：理論の実践・検証（としてプロダクト開発を行う）
- 趣向：アーキテクチャの考え方自体、言語設計が興味深い言語を勉強の意味で学ぶ、できるだけ本質的なコードを書きたい、あるべきアーキテクチャを現実に落とし込みたい
プロダクトが好きな人
- 目的：良いプロダクトをつくりユーザーに価値提供すること
- 手段：技術が手段
- 趣向：自分のつくりたい機能をまるっと実装したい(技術領域はフルスタックに広く浅くなりやすい傾向) 、UXやUIの領域やデータ分析などにも強いこだわりを持つ、どう実装するかよりもなぜ何をつくるか/どう改善していくのかを考えるようになる
組織が好きな人
- 目的：高い開発生産性を持つ優れた開発チームつくること
- 手段：プロダクトのデリバリを重視（使用する技術やビジネス価値/事業インパクトそのものには深く踏み込まない）
- 趣向：一定の制約条件のなかで最大の成果を出すことにコミット（スクラムなどアジャイル開発などに強く専門性を持っていく、ピープルマネジメント領域でチームコンディションやスキル開発/技術広報的な分野で活動を広げていく、等人それぞれ）

自身のタイプと特性

どれにも当てはまるバランス型…

タイプ的には、プロダクト好きが中心ではあるが、プロダクト開発の手段として必要となる技術やチーム(組織)も重視している。比率的には、「技術：プロダクト：組織＝ 3.5:4:2.5」と考える（どちらかと言えば技術＞組織のため）。

そう考えた詳細は以下の通り。

技術の本質を追求したい
- 引用記事にある数学的なアルゴリズムやバイナリ・プロトコルなど低レイヤの技術/プログラム言語そのもの/個々のフレームワークというよりもアーキテクチャの考え方自体に興味を持ちます やチームの心理的安全性やカルチャーは重視しているが、非合理な人の感情と向き合うことは好きではなくにがっちり当てはまる。
が、技術は(プロダクトなど物を作る上での)手段と割り切っている＝プロダクト指向
- それ故か自分のつくりたい機能をまるっと実装したいやフルスタック足りたいと考えている。
- 自分がコードを書かなくてもいい とまでは思ってない。できれば書きたいが、必ずしも自身が書かなくても良い位の温度感（常にコードが書けるだけの実力は持っておき、必要な場面があれば自身がコードを書くor書けるようにしておきたいと思っている。≒サポート思考）
が、使用する技術やビジネス価値/事業インパクトそのものには深く踏み込まないには当てはまる
- 使用する技術に強いこだわりはないように思う(が全くない訳ではなく、プロダクトや開発組織/チームの状態や特性等を踏まえて適切な物を選びたい欲を持っている) 。目的を果たせるなら細かい手段までは気にしないが、ある程度プロダクトにとって適切なものを選びたい
- ビジネス価値/事業インパクトに関しては、そこを強く意識する機会が無かったため、正確にはまだ分かっていないだけかもしれない。（※詳細後述）
また、高い開発生産性を持つ優れた開発チームつくることにも関心がある
- (2022/3現在) 現職にて自身が属するチーム（6名程）のチームの心理的安全性が低く、理想とはかけ離れた状態が故、制約の多い中少しでも良くできないかと試行錯誤し続けている。そういった実体験があり、プロダクト開発に立ち向かう上で欠かせない要素だと強く肌で感じているため（※詳細後述）

上記を踏まえつつ、先を考えるため、現状を整理する（自身の特性含む）（2022/3、31歳時）。

SIer業界2次請けサイドSE。別会社のプロダクト開発に従事（2019/12～参画中）
現状(なんちゃって)フルスタック、サブチームのサブリーダー
- バックエンドが中心だが、RDBの経験が浅かったり、フロントエンド経験（フレームワーク経験無し）が多少あったりと中途半端
- フロントエンド～バックエンドのコードを見ていけるだけの力があり、機能追加する際に、どこにどういった修正が必要か見極められる
- RDBの経験は薄いが、時系列データベースやGraQLライクな独自DBを扱った経験があり、データ層及び扱っているデータをしっかりと意識して考えていける
プロダクトの全体～詳細を見ていけるだけの力がある（それだけ既存物への理解力が高い）
- 4～5システムが連携することで1つのサービスを形成する大規模プロダクトのうち2システムの改修に携わった。
- 携わった一方はマイクロサービスアーキテクチャで、(触れてない部分もあるため全てではないが)おおよそ各パーツの役割とどう連携しているかを掴んでいる
- もう一方は、6ヶ月前から開発に携わるようになったものであり、中身の詳細を着実に掴んでいき、実装面ではサブチームのメンバー全員を牽引しているレベル
- 各システムの役割をしっかりと掴み、新規参画メンバーにプロダクトの全体アーキテクチャの概要や、どうやってサービスを実現しているのか、ユーザ視点を交えて各システムがどういったことができるのか/機能を提供しているかを説明。
2次請けサイド故にプロダクトとの距離が遠い。
- プロダクトの価値、役割、位置づけ等、概要的なことは押さえているが、実際のユーザからどういった要望/フィードバックが来ているのか全く分からない。知ることができない。
チームの不足部分を埋めるような動きをする
- 所属サブチームで自身のみが突出しておりサポートに回るばかり≒サポート型
- 所属サブチームの心理的安全性や、開発生産性が低いと感じている＝不足部分をなんとか改善できないかを試行錯誤している

現状もやもやしている点＆先のキャリアへの考えは以下

どちらかと言えばプロダクト中心指向にも関わらずプロダクトとの距離感が遠いこと（解消には転〇必須）
本音はフルスタックを目指したいとどこかで思っている
- が、これまでの経験/スキル/年齢的にも技術/エンジニア一本の方向は厳しい。自身の地頭的にも
- 仮にそちらに倒すにしてもスタートアップが狙い目になるのかと思うが、0->1、1->10は経験がない上、不得意なため相性の問題から止めた方が良い。
(消去法的に)プロダクトor組織の方向かと考える
- マネージャーを目指すのは良しと考えているが、上記にある自身の特性がより活きる方向はどの方向か
- プロダクトコードとの距離が密接な方が自身の真価を発揮できると思われるし、将来的には少しでも手を動かしていたいため、プレイングマネージャー的な所を目指したいと考えている（プロダクト/組織の間？）。果たしてそんなポジションあるのか