毎週、営業会議とかメディア会議とかやってるなかで、代表もちゃんとブログ書いてよ的な見えない圧力が日々高まってきていて、だんだんと「忙しくてさあ」とばかり言ってられなくなってきました。
ブログって大事ですね。普段はしゃべってることがかなり多いんですが、時間を取って文字を書くというのも夜の長い秋には最適です。もっと最適なのは、新鮮な鮪や烏賊あたりを酒肴にキリッと冷えた日本酒を飲むことですが。そういえば吉祥寺だったか中野だったかで出された、クリームチーズに蜂蜜をかけたものと、岐阜の百十郎 純米吟醸 雪化粧、この組み合わせは「完璧」と書いたTシャツを着たくなるくらい完璧だったのを思い出しました。
さて、エンジニアのキャリアパスについて。35歳定年説という話はもう大昔から言われています。５年前も１０年前もあった話です。ただ、またいま若手エンジニアがこんな用語を聞いた途端に、この先どうしていこうか、少しずつ心配になるになるかもしれません。有るのか無いのか、どうすればいいのか、はっきりしておきましょう。
35歳定年説
35歳定年説がどういうものかと言うと、
プログラミング技術は進歩が激しく、技術の陳腐化も著しいため、プログラマは常に新しい技術に目を向け習得していくバイタリティや、場合によっては永年の努力によって培ってきた技術を捨て去る柔軟性が必要である。また、年功序列的賃金体系のもとでは、高年齢のプログラマはコストが高すぎると考える企業がある（特にプログラミングを単純作業と考える企業に多い）。俗にIT土方とも呼ばれデスマーチとなった場合は徹夜が続いたり体力が必要となってくる。そのため、プログラマとしての限界は30～35歳前後であるという説が存在した。これは「プログラマ35（30）歳定年説」と呼ばれる。
バイタリティなんていう曖昧な言葉は信用できないですね。バイタリティが有る人は年寄りでも有るし、バイタリティが無い人は若くても無い、ウスバカゲロウのような人もいるので、年齢とはあまり関係ない。
そこは無視してよくて、こういう説が生まれるのは主に利益の話が背景にあり、年齢があがればアホでも給与が上がるような古き良き日本の年功序列な会社では、単純計算で35歳くらいが損益分岐点になるわけです。エンジニア個人の売上を給料が上回ってくる。それでは赤字になるので、一介のプログラマではなく、マネージャになるか、群を抜いた技術力で高い売上をあげるか、この2種類のキャリアパスから選んでねと言われると。そうすれば利益がちゃんと出る。2種類ある会社はまだましで、ほとんどはマネージャになってねと言われる。
プログラマは、技術に向き合いたいのに、それができないのか、人の管理とか嫌だなあ、と悩む。というものが35歳定年説のストーリーです。
技術かマネジメントか
で、実際のところどうなのか。
確かにいることはいます。40歳前くらいでマネジメントできない、年収は上げたい、今後どうしようと悩む人は。ただ、こういうタイプは人とのコミュニケーションに難があることも多いので、深い相談をしたり、議論で揉まれて誤りを改善したりといった、話すことで解決に向けて動くということがないので一人で悩んでたりします。結局、本質的な問題はそこじゃないことに気づかないまま、狭い考え方にとらわれてダークサイドへ陥っていく。
そもそもの本質的な問題は技術かマネジメントかではないと、日本で最も有名なプログラマの１人、Rubyのまつもとゆきひろ氏が明確に答えています。
けれども、マネジメントの方へ行かないからといって「技術だけで」生きているかというと、必ずしもそうではない。設計するためには使う人が何を求めているか把握する必要があるし、効率よく問題解決する方法を考えられる必要もある。エンジニアとして成果を出すためには周りの信頼を得ないといけない。
ソフトウエア開発と「技術だけで」という言葉をつなげて考えると、「マネジメントがしたくない」という思いを満たす上で、違うものを示してしまう可能性があるのではないかと感じました。
まつもとゆきひろ氏が「生涯プログラマー」でやっていきたい若手に贈る3つの言葉 - エンジニアtype | 転職＠type
エンジニアとかプログラマとか、技術とかマネジメントとかそれぞれの言葉が広い意味を含むので、個々人によって思い込んだものを指すようになってしまっているのが根本的に大きな間違いで、マネジメントという未知で不安を煽る、おそらくストレスフルであろうものを避けるために技術だけを行って他人のことを考えない、かかわらない、なんて職業は地球上に存在しないわけです。
技術だけといっても、一人で黙々と毎日画面に向き合うだけが技術の仕事ではないし、エンジニアといっても徹夜で長時間仕事するのが偉いわけでは全くない。対人恐怖症でもエンジニアだったら容認される、という種類の仕事では無いわけです。むしろ、エンジニアの現場はコミュニケーションや相互理解がかなり問われる仕事ですし、プロダクトを作ろうと思ったら人に対する理解、交流なしには他人の感覚は分からない。
なので、そもそも技術かマネジメントかという単純な選択肢ではないということです。
エンジニアの軸
どんな仕事でも、他者に対して価値を提供してその対価を得るというのが仕事なので、自分が提供できる価値とは何かを考えるのが大切ですが、若いうちは大した価値を創り出せるわけではないのですぐに分かるわけではない。何年かの実務開発とか、いいクライアントとの出会いとか、尊敬する上司とか、同僚、部下、ユーザ、いろいろな人と交流をもって経験値を上げていけばいい話です。技術というのはあくまで道具、ツール。誰かの課題を解決する道具でしかないので、道具という手段が目的化すると、選択の幅を狭めて人生を無駄にします。この道具を使って誰のニーズをどのように満たすかを先に考えるべきです。
それに、20代の時に他人の面倒みて苦労するの嫌だなと思うでしょ。でも逆に、40代、50代で部下が誰もいない時の心境は想像つくでしょうか。「全然平気、俺は俺がすげーから俺だけで10人分くらいの価値を生み出せるぜ、ロックンロール」という人はそのまま突っ走ってもらえればと思いますが、多くの人はそこまでぶっ飛んだ能力も勢いもない。想像つかないことを仮定に仮定を重ねて考えても無意味でしかないですね。
結局、マネジメントか超ハイスキルになるかの2択しかないなんてことはなくて、業界業務知識という軸もあれば、自分でサービスやアプリを作るという手もある、フルスタック的にサーバ周りをプログラムからAWSまで全部できれば新規事業にはとても役立つ、価値を生み出す方法なんていくらでもあります。しかも、チャレンジして上手くいったものだけ残せばいい。
そういった「技術軸」と、誰のどういった問題を解決するために使うのかの「人軸」、この2軸が交差するところにエンジニアの価値が生まれます。
