エンジニアのキャリアプランをどう考えるべきか〜VPoEの考えを披露してみる〜

f:id:conceal-rs:20210118171226p:plain

VPoEの小川です。今日はエンジニアのいわゆるキャリア・キャリアプランについて個人的に考えていることをお話ししたいと思います。個人的というのはロコガイドとしてこれ以外を考えていないというわけではないためです。自分のキャリアの道が見えない人の参考になれば幸いです。

エンジニアの気質には2種類ある

まずはじめにエンジニアの気質についてお話しておきたいと思います。個人的にはエンジニアには、「職業エンジニア」と「職人エンジニア」の2種類の気質があると思っています。この2つに善し悪しがあるわけではなく、個人の環境や状況によっても変わります。会社がどちらを求めるのかも、会社のフェーズや環境、状況によって変わります。この2つは何が違うのでしょうか。

職業エンジニア

職業エンジニアとは言葉を選ばずに言えば「仕事のために技術を学ぶ」という考えの人です。携わってみたい業種や業界、その中でのやりたい仕事のために技術が必要になる場合もあれば、純粋に給与を稼ぐために技術を学びたいと考えることもあるでしょう。特徴としては、このどちらも技術はあくまでも手段であり目的は別にあるという点です。例えば「〜を知っておくと〜のときに対応できそう」とか「最近は〜が流行っているのでおさえておきたい」「フルスタックになっておくと将来食いっぱぐれない」という気持ちで技術を学ぼう、習得しようと思っている方が当てはまります。後に役立つ技術を身につけたい、幅広い知識を身に着けて対応できることを増やしたい、いわゆるフルスタックエンジニアになりたいという方が多いように見受けられます。

また職業エンジニアを極めた方は、いわゆるプロフェッショナルとしての意識が強い印象があり、何事においてもきっちり仕事をする方が多いように思っています。必要十分な技術力を身に着け、限られた時間できっちり仕事をこなして帰っていく。そんなエンジニアに憧れる方は職業エンジニアだと考えてもよいでしょう。

職人エンジニア

一方で職人エンジニアはひたすら技術を追い求める人です。どちらかと言うと技術が目的になっている傾向があるため、会社によってはマイナスに受け取られる場合もありますが、技術に対するモチベーションが非常に高いために特定領域に対する課題解決能力は非常に高くなります。例えば言語特性やネットワーク、OSの知識があるとトラブルシューティングに強くなるし、言語やフレームワークの向き不向きの知識があると新サービスの技術選定を良い状態で行うことができるでしょう。このような人が社内にいると、いざというときに頼りになるという安心感を得られるという経験がある人は多いのではないでしょうか。

一方で興味がない技術に対してはあまり積極的に手を出さない人もいるので、技術に関して偏りがちになります。とは言え特定のことを深く知っていることは大きな強みになるし、そもそも過程でいわゆる技術力が高くなるので、興味があまりない領域で力を発揮できないわけではありません。純粋に興味がないのでやる気が出ないという傾向が顕著に現れがちであるという特徴があるというだけで、実力は高い印象があります。

その上でのエンジニアのキャリア

さてその気質を踏まえた上で、一般的に考えられているエンジニアキャリアを見直すとどうなるでしょうか。

マネージャーになる

エンジニアキャリアを考える際にまず最初に思い浮かぶのはマネージャーになるということでしょう。たとえばプロジェクトやメンバーをマネジメントする道に進むキャリアです。会社によって呼び方は様々だと思いますが、いまだとエンジニアマネージャーという呼び名が浸透しつつありますね。チームメンバーを何人か抱えて、プロジェクトマネジメントをしたり、1on1などを通じてヒューマンマネジメントをしたりなど、技術というよりもプロダクトやメンバーと向き合うのが主な仕事になります。なので前述の気質で言うと、どちらかと言えば職業エンジニアの人が向いており、さらに人と話すことが好きで得意という人のほうが適していると思っています。

一方で職人エンジニアだけどコードを書くのが好きな方が向いているかと言うと、なかなか判断が難しいところです。マネージャーというのはその名の通りマネジメントすることが主業務になるので、コードを書く優先度はかなり下がってしまいます。プレイングマネージャーという都合のいい言葉はありますが、下手すると2倍仕事するだけになるので、しっかり折り合いをつけないと辛くなる可能性が高いです。

またエンジニアマネージャーから先にはVPoEになることを考えるかもしれません。VPoEになると見る範囲がチームではなく会社全体になるので、マネジメント業務もそうですが、中長期的な計画や全体戦略も視野に入れないといけないため、よりマネジメント色が強くなってきます。こちらはどこまでこれら全社的なことを考えることに注力できるかにかかってくるので、興味がある方は目指してみるのもよいと思います。

技術を追求する

次は技術を追求していくキャリアでしょうか。マネージャーにならない場合のキャリアとしてよく話題に上がるものですね。こちらはいまだとテックリードとかアーキテクトといった職が思い浮かびます。テックリードは役割としてマネジメント色が強めな会社もありますが、個人的には技術でリードする役割が強いと思っています。チームにおける技術的な支柱ですね。なのでマネジメント力はそこまで強くなくてもよい、もしくはエンジニアマネージャーと二人三脚でチームを牽引するとよさそうです。こちらは職人エンジニアの人のほうが向いている印象があります。技術でチームを牽引するため、技術に対してどこまで貪欲になれるかや、こだわりを持って挑めるかが重要になってきますが、この意欲とかこだわりは職人エンジニアの気質にあっているという印象があるからです。

テックリードから先はCTOになることを考えるかもしれません。ただCTOとかになると技術だけではなく経営・マネジメントに関わることになるので、技術だけをやり続ける状況ではなくなってしまいます。このあたりは向き不向きや合う合わないなど個人差があるので、しっかり自分自身に合うかどうかの見極めをしたほうがいいでしょう。

現場のエンジニアであり続ける

「一生コードを書き続けていたい」という方はこちらがいいのかも知れません。一昔前はマネージャーにならないと、つまり昇進しないと昇給しないような環境でしたが、サービス系の会社が増えてきたり、そもそもエンジニアの職種自体が増えてきたこともあって状況は変わってきている印象があります。なので、「マネージャーにはあまりなりたくはない、一生現場でサービスを作っていきたい」という方はこちらを目指すといいかもしれません。

一方で現場のエンジニアでありながら成果や結果を出し続けるには、コーディング能力だけではなく、サービス全般のことやそれに付随する環境、経済や市況などの知識や情報をいかに収集し続けるかというのも重要になってきます。このあたりは追々記事にしていきたいと思っているところです。

キャリアの決め方

さて気質とそれに応じたキャリアについてざっとまとめてみましたが、じゃあ自分がどんなキャリアに進めばいいのかはどう決めればいいんでしょうか。その前にまず自分自身について見つめ直す事が必要になるので、以下の3つのことを書き出してみることをおすすめします。

やってて好きなこと

まず最初は「やってて好きなこと」です。好きこそものの上手なれではないですが、「やってて好きなこと」は上達も早くモチベーションも継続するため、重要な基準になってきます。ここにたとえばコードを書くことがある場合はエンジニアとして理想的ではあると思うのですが、これは何も仕事に限った話ではありません。仕事以外のことも含めて「やってて好きなこと」を挙げる必要があります。例えばゲームをすることや旅行に行くこと、料理をすることなどいろいろなことが思い浮かぶと思います。まずはそれらをすべて書き出してみましょう。この中のことを仕事に、つまりキャリアに結び付けられることが一番良いのですが、すべての人がそうなるとは思っていません。ただ明確にしておくと新しい発見につながるかもしれないので、やってみて損はないはずです。

やっておいたほうがいいと思うこと

次は「やっておいたほうがいいと思うこと」です。これは「やってて好きなこと」が自分自身から出るものである一方、周りの環境に依存して変わっていくものになります。例えば「新しい言語を習得したほうがいいと思っている」や「マネジメントの勉強をしたほうがいいと思っている」などがこれに該当します。こちらはみなさんいろいろ思いつくのではないでしょうか。こちらは自分の今後を考えたときに足りないことが挙がることが多いですが、つまりはキャリアとして考えていることに一番結びつきやすいことになります。これも思いつくまま書き出してみましょう。人によっては「やらないといけないことがこんなにあるのか」と絶望するかも知れませんが、整理するためにもざっと書き出してみてください。

他者から得意だと思われていること

最後はこれまでの2つとは異なり、周囲の評価である「他者から得意だと思われていること」になります。これは自分で考えても仕方ないところではあるので、同僚や友人、上司などいろいろな人に聞いてみるとよいでしょう。そこで「意外に◯◯が得意ですよね」という話が聞けると、自分の思ってもいなかった特性がわかったりして、意外な事実に気がつくことがあります。

この３つの重なるところを探す

キャリアを考える際には、これら3つのことが重なっている領域を探すのがまず最初のステップです。「やってて好きなこと」が「やっておいたほうがいいこと」であり、さらにそれが「得意だと思われる」ぐらいに評価されることであれば、一番良いことなのはおわかりいただけると思います。一方でこの3つが全部重なることは稀なので、無理に落とし込みを書けることはしないほうがいいでしょう。特に「やってて好きなこと」は偽らないほうがいいですね。ありのままをさらけ出した上で考えていくのがいいと思っています。

3つとも時間の経過とともに変わってくるのが通常です。かくいう私も今でこそマネージャーをやっていますが、昔はそれが嫌で転職をしていたりもします。当時は一生現役エンジニアでいようと思っていたので、いまは全く逆張りになってしまってます。ただ大事なのはこの3つを意識し続けることです。

参考：これまでの道のり

じゃあまずはおまえはどうなんだということだと思うので、私自身のキャリアについてざっとおさらいしておきます。

プログラミングを初めて35年ぐらい、エンジニアとして働き始めてからだいたい18年ぐらいでしょうか。職歴としては大学院の博士課程を終了してからなので、歳の割にはちょっと短めかもしれません。プログラミング歴としてはMSX BASICとZ80アセンブラでいろいろ遊んでたのが最初です。なので中学ぐらいまではずっと将来はプログラマになると思ってましたね。転機が訪れたのは高校生の頃で、生物の先生の授業中の雑談中に教えてもらった物理の話に興味を持ち、そこからは大学院までずっと物理一辺倒になりました。プログラミング自体は好きだったんですが、キャリアとしてプログラマ・エンジニアになるとはほとんど考えていなかったですね。

その後、大学院博士後期課程修了するときにいろいろアカポス*1に挑戦したのですがなかなか難しく、当時友人がやっていたWeb制作会社にアルバイトで入社し、その後正社員になりました。これが最初のキャリアになりました。このときはPerl/PHPを使ってホームページや社内システム、通販システムの開発などに携わってました。その後Webサービスの会社に転職したのですが、マネジメント業務から抜け出したかったというのが大きな理由です。今では考えられないんですが、当時はマネジメントなんてやりたくなかったんですね。なのでそのWebサービスの会社もマネジメントをやらざるを得ない雰囲気になってきたタイミングで転職しています。

ただ転機が訪れたのは3社目のときでしょうか。このときも最初はサービス開発をする現場のエンジニアだったんですが、徐々に役割としてチームや会社全体を見るような状態になっていきました。このときに初めてマネジメント業務をやりたいと思うようになり、個人的に色々勉強し始めました。実際1年半ぐらいコードを殆ど書かずに過ごしたんですが、不思議なことに特に不満とかを感じることはなかったですね。

このように自身のキャリアを振り返ると、これと決めたものを貫き通したわけではなく、周辺環境や個人的な状況などによっていろいろと変わってきているのが現状です。