👊

お前はゼネラリストではない! 〜 フルサイクルエンジニアという選択肢 〜

に公開

はじめに

最近、AI(LLM)にお悩み相談することが趣味になってきてる。
ある日、”自認何でも屋のITエンジニアなんだけど、プロジェクトマネージャー(PM)とか事業責任者(ステークホルダー)とあまりうまくいってないのよ。”とか、相談してたの。

そしたらAIさんたら、「お前、ステークホルダーマネジメント向いてないよ。フルサイクルエンジニアとして頑張んなよ」とか言ってきたわけ。
俺が知らん言葉使いやがって。

なぜ、うまくいかなかったか掘り下げてみようじゃないの。

読んでほしい人

  • 評価フィードバックでコミュニケーション能力が足を引っ張っている
  • 1on1などで期待値調整がキーワードになり始めた
  • これらの調整業務が苦痛またはストレス
  • 自分

どうして人はゼネラリストを目指してしまうのか

フルサイクルエンジニアとゼネラリストの決定的な違い

  • フルサイクルエンジニア: 技術選定、実装、デプロイ、オンコールまでを「一気通貫で所有(Ownership)」する人
  • ゼネラリスト: 複数の領域を平均的にこなせる人

両者は、学習能力の高さゆえに器用貧乏になる点で共通している。
ここで整理しておきたいのは、両者の違いが「スキル(縦)」ではなく「責任範囲(横)」ということ。

エンジニアが思うゼネラリストと会社が求めるゼネラリスト

「何でも屋(技術的ゼネラリスト)」=「マネジメント・事業サイド(組織的ゼネラリスト)」 という勘違い。

自認ゼネラリスト「スペシャリストほど技術尖らせてないからゼネラリストになるわ」
会社「お、じゃあ手始めにマネジメントよろ😄」

そして次のどちらかに分岐する。

  • 失敗例 : 事業部の要望を整理し、エンジニアリングマネージャー(EM)もこなして疲弊する(ただのバッファ・レイヤー)
  • 成功例 : 事業部に入り込み、「現場のオペレーションをノーコードや自動化で勝手に改善し、数字(利益・コスト)で成果を出して、その実績を引っ提げて組織の意思決定層にのし上がる」

責任範囲を越境できなければゼネラリストではないのである。
技術を幅広く知ってるだけならそれは技術のスペシャリストでしかない。
自分はスペシャリストではないという思い込みと周囲の理解不足によって、向いてないマネジメントでストレス爆発する例が後を絶たない。

回避策と生存戦略

スタッフエンジニアという回避策

マネジメントに疲弊しているなら、キャリアの座標軸を再設定する必要がある。
目指すべきは「エンジニアリングマネージャー(EM)」ではなく、「スタッフエンジニアといったIC(Individual Contributor)」である。

  • 技術的な広さで勝負する: 単なるマネジメントではなく、アーキテクチャの標準化やプラットフォームの構築を通じて、組織全体の開発速度を上げる
  • 「調整」を「技術」で解決する: 人間同士のコミュニケーションで解決するのではなく、CI/CDの改善や自動化、ドキュメント文化の醸成など、エンジニアリングのアプローチで組織課題を解決する

この2点を意識してフルサイクルエンジニアを目指す。

疲弊しないための生存戦略

マネジメント業務で「これじゃない感」を抱えているなら、以下の3点を意識する。

  • 「やらないこと」を決める: フルサイクルは「全部自分でやる」ことではなく、「自動化して手離れさせる」ことが正義
  • 自分の価値を「技術的影響力」で再定義する: 評価面談で「調整を頑張りました」ではなく「この仕組みを導入してチームのデプロイ頻度を上げた」ことを強調する
  • 役割のミスマッチを言語化する: 上長に対し、「自分がバリューを発揮できるのは、人間の管理ではなくシステムのオーナーシップである」と明確に伝える

おわりに

フルサイクルエンジニアは、「技術で事業を完結させる」というIC(Individual Contributor)の極致であり、マネージャーとは全く別の進化系統である。
もし、自認ゼネラリストで慣れないマネジメント業務に疲弊しまってるなら、もう一度キャリアを考えてみてもらいたい。

そして私は、フルサイクルエンジニアの道を歩むことにしたのであった。


参考になるリンク

Netflixにおけるフルサイクル開発者―開発したものが運用する
エンジニアよ、ゼネラリストなんて目指すな!

Discussion