技術の話ではないので若干Qiitaに書くような記事では無いような気がしますが、QiitaのAdvent Calendarなので書いてしまいます。
経歴概要
専門学校卒
転職回数６回
出向型下請けSIerからWeb系？へ
Javaエンジニア
アーキテクチャを決めるリードエンジニア経験
全くコードを書かないエンジニアマネージャ経験
エンジニア採用の面接官
現在36歳
転職について思うこと
一般の人より若干転職回数が多いと思うので、そこから思ったことを書いてみたいと思います。
まず、エンジニアとして技術が好きでそれをやっていきたいのか、安定した生活がしたくて、そのために技術を使っていきたいのかという人生の価値観の前提で大きく目指す会社の方向性が違います。
技術が好きでそれを伸ばしたいと考えるならばWeb系
安定した生活ならばSI系
の方が概ねあっていると言えると思います。(もちろん例外の会社もあります)
少し２つについて自分の考えを書いてみたいと思います。
SI系の仕事
SI系は全ての工程が細分化されていて、エンジニアとしての知識の一部しか仕事の中で要求されないケースが多いです。これは要員を確保するために必要なビジネスモデル上でカバーするための仕組みだと思います。
設計は設計要員。 (SE)
実装は実装要員。 (プログラマ)
テストはテスト要員。 (テスター)
この他にもっと分かれている会社もあります。
DBを管理するDB管理者 (DBA (Database Administrator))
ソースコードをマージするマージ担当者
アーキテクチャを設計する共通ライブラリ、アーキテクチャグループ
などなど
本当のエンジニアは長期的なシステムを考え、アーキテクチャの設計と実装を同時にしなければならないのです。
この構造は最低限の品質を担保しますが、最高のプロダクトを作るチームにはなっていません。
それぞれの担当の間には山よりも高い壁が存在することも多々あります。
技術を高めたい人には厳しい環境でしょう。
しかし、安定した仕事は沢山存在する分野でもあります。
Web系の仕事
次にWeb系ですが、基本的に要件が渡されるので、アーキテクチャ、DB決め、フレームワーク決め、設計、実装、テスト、リリース。
全てをやれる必要があります。
やれるのは当たり前で、その中で自分の得意なものが必要です。
この言語なら最新の動向やベターなフレームワークを知っています。とか。
インフラが強く、設定やIP制御など得意です。とか。
確固たる技術の自分を作っていく力が無いと、クソみたいなコードを書いて、いまいちなプロダクトしか産めないです。
プロダクト価値が直接自分の価値に繋がり、売上に繋がり、給与にも反映されます。
安定の環境とは逆の世界ですが、自分の力が直接プロダクトに与える影響は大きいです。
安定しないWebアプリをリリースしてしまえば、障害が起きたときに対応するのはあなたです。
土曜も日曜も関係ありません。直すのもあなたです。
技術やプロダクト、自分の作るものに情熱とプライドがなければ到底続けられないと思います。
転職理由 (と採用面接官としての思い)
基本的にポジティブであるべきです。
今の現場で自分のやれる権限の範囲でやれることはやったといい切れる人は強いです。
どんな提案をしたのか、どう動いたのか、何を考えたのか、上司のメリット、現場のメリット、会社のメリット、全ての視点で捉えた行動や提案が出来ているかなどを見ています。
実際、私もそうやって、この会社でやりたいこと、出来ることはやったと言えるくらいになってから転職を毎回してきました。
それであれば、数はそんなに関係ないのかなと思います。
今の会社はレベルが高く、自分の力も沢山向上したように思います。
この力を使って、ぜひこういうことがしたいと言う思いが生まれたら７回目の転職をするかもしません。
しかし、全く不安はありません。
技術力が高いことこそがエンジニアとしての一番の価値の軸であり、
それをひたすら高めることも出来ます。
また、それに掛け算するようにマネージメントなどのスキルを身につけたりもできます。
それでもエンジニアならば軸は技術力です。
プログラマ35歳限界説
僕はエンジニアマネージャ的な仕事を2年近くやっていました。
アーキテクチャまでは判断するけど、実装は人にお願いする。コードレビューはする。
ほとんどの時間をうちあわせと調整、設計に使っていました。
ただ、直近でまたプログラムを実装する１人のエンジニアに戻り、バリバリコードを書いています。
力があってやりたくて、技術を磨き続けていれば35歳の限界は無いと思います。
ただ、新しい技術は常に生まれ続け、最新で開発効率が高いものを学ぶと古いやり方の知識は過去の遺産になることも多いです。
今ならばプログラミング言語でいえば
Kotlin、Swift、Go、Scalaなどは勉強をしておくべきかと思いますし
その次に流行りが来るかもしれないElixirやRustなども勉強したほうがいいかもしれない。
もちろん基礎の深さが足りなければ、それらもどこかの機会でやった方がいい。
byte単位でメモリを操作し、何をやっているか理解するためにC言語は抑えたほうがいいかもしれない。
HTTPやTCP/IPがなにをどういう意味でやっているか知ったほうがいいかもしれない。
他にも流行りの技術をやるべきか決めたい。
大規模分散処理にはHadoopやSparkなども勉強したほうがいい。
VRやARなどの技術。
IoTなどの知識。
機械学習。Tensorflowなど。
DevOps系も最近話題が多いです。
JavaScriptなどのフロント技術は激流のように技術更新が起きています。
死ぬほど勉強することはある。
ただ、年齢を重ねて強みとなるのは、考え方の視野が広くなることだと思います。
なぜ、その技術を使うのか、その技術を使うとリスクがなんなのか。
流行度は？プロダクトの価値を担保する最低ラインの選択か？
総合的な判断で最も先進的な技術をチョイス出来れば、先進的な技術にチャレンジしたい優秀なエンジニアも集まります。
すると、またレベルが上がります。
ポジティブな技術向上サイクルが生まれやすくなります。
ただ、この技術向上スピードに追いつけるくらい技術が好きでなければ、数年以内に振り落とされてしまうことでしょう。
あらためて自分の強みを考え、強みを作る計画や勉強や知識、アンテナを作っていってみたらと思います。
プレイヤーとマネージャ
技術がなければエンジニアマネージャは務まりません。
もし技術が分からないマネージャが居たとしたら、それはエンジニアマネージャではなく、ただのマネージャです。
そのエンジニアがどれくらい仕事ができるのか、コードを見なければコードの品質は測れないですし、進捗もコードを見れなければ、エンジニアが報告した進捗が正しいのかどうかもわかりません。
エンジニアのあなたがチームをまとめたいと考えるときに目指すべきはエンジニアマネージャです。
エンジニアとしてやれないって思っている人が目指しているのはただのマネージャです。
真のエンジニアの管理者はプレイヤー(プログラマ)も認める人であり、ただ役割が違うから実装の仕事をしていない人だと思います。
終わりに
色々とりとめとなく書きましたが、本当に技術が好きなエンジニアは適切な会社で働ける視点を持ってほしいし、そういう会社に行くための勉強や知識、観点、アンテナ、行動をして欲しいと思います。
伝えきれてないこともたくさんありますが、何か不安や質問があればコメントでもなんでも連絡頂ければと思います。
宣伝
こちらで、アジャイル AdventCalendar2016 を1人で書いています。
単純なアジャイルな話ではなく、この記事のようなエンジニアとしてどう考えたら良いのか？みたいなこともきっと書くのでぜひ見てみて下さい。
http://qiita.com/advent-calendar/2016/agile