活躍するエンジニアに求められる「野武士力」ミドル・シニアエンジニアのキャリアの築き方

ネットのエンジニア界隈では「35歳定年説」というキーワードがあります。「定年」が本当にあるのか、またエンジニアとしてどのように生きていくかという話は、話題になることがあるのではないでしょうか。

ジェネラリストかスペシャリストなのか、何を強みにするか、PDMやデータ関連のスペシャリストを目指すのか、CTOやVPoEを目指すのかなど、多様なキャリアパスの中でどの様にキャリアを築いていくか、overflowのCTO 大谷氏(@koko1000ban)と田中氏(@tanamako327)の対談の第2弾です。

今回は、大谷氏のキャリアを振り返った前篇(「ミドル・シニアエンジニアのキャリアの築き方【CTO×CPO対談】」)を踏まえて、エンジニアとしてのキャリアの考え方やインプットの方法などを伺いました。

Offers MGR」は、プロダクト開発組織の生産性を最大化したい企業・担当者の皆さま向けのサービスです。個人、チームの業務プロセス・生産性を可視化し、皆で強いチームを作っていきませんか?

→Offers MGRをもっと詳しくみる!

ソリューションの数がエンジニアの質

田中氏:4,5年目のときはどのような意識で仕事をされていましたか?

大谷氏:私が4,5年目の時は、CTOというポジションはまだ馴染みがなくて、参考になるロールモデルもなかったんですよね。

なので私はやりたいことを追求した結果、今の自分があります。

キャリアとして意識してきたことではないのですが、エンジニアとして意識してきたことはあって、ソリューションとしてどのような提案を数多く提供できるか、またそれを裏打ちされた経験を持って提供できるかを意識していました

経験に裏打ちされたソリューションを自信を持って提供できるか、また雇う側の目線に立った時にその経験と提案に納得感あるかみたいなことを裏付けるために経験してきた感じがあります。

学習としても、提供したいソリューションから逆算で考えて、遅延学習をしていました。WebAPIから、経路探索エンジン、コミュニティサービス作り、世界規模のサービス実装、運営など、その時にいる会社の方向性を踏まえて、解決策として提供したいものを先回りしてインプットしてきた感じです。

田中氏:つまりは実装したいプロダクトや解決したい課題に対してどうしたら実現できるかを整理してインプットしていたのですね。

大谷氏:そうですね。最終的には自分で責任を取れるかという考えが根底にありました。なので、複雑な仕組みを形にできるかとか、エラー・障害があった時に低レベル層も含めて自分でパッチ当てて直せるかのようなことを意識して、内部実装に興味のある開発言語を学んでいた感じです。インプット部分では、流行を追っかけるような感じではなかったです。

田中氏:根底にある解決策の部分を意識されている感じですね。

大谷氏:いかにソリューションを多く提示できるかがエンジニアの質だと思っています。

チームで取り組むことで、大きなプロダクトは作れるし、より大きな課題も解決できるので、そのためにマネジメントの意識や立ち振る舞いなどを今も遅延学習して学んでいるところです。

田中氏:凌芸舎ではVPoEをやられてましたよね?

大谷氏:一応肩書きではやっていましたが、名刺的には他にもデータマイニングエンジニアやらシニアアーキテクトやらインフラマネージャーやらいろいろな肩書きがありました(笑)

凌芸舎時代は、国産のチャットサービスを大手SIerと協業して立ち上げていて、バックエンドからフロントエンド、インフラ設計・管理まで全ての層を開発してました。初期のVueも使ってましたね。version0時代だった記憶。

並行して、立ち上げた会社でも色々なサービスを開発していてCyberAgentの子会社に作ったサービスが導入段階まで行ったりもしていたのですが、なかなかシード以上へ踏み込むところまではいかなかったんです。その時にちょうど鈴木さんに声をかけてもらって、overflowの立ち上げに参画した感じです。

インプットは本か公式ドキュメント

田中氏:インプットする時の遅延学習の工夫ってありますか?

今の話を聞いても「最終的にはググってなんとかする力」がエンジニアには重要だなと感じます。そんな中で「大谷さんだからできたんだろう」という考えを持つ人もいると思います。

例えば僕は、インターネットサービス・プロダクト大好き人間だったので、副業で自分で Web メディア開発してやったりしてインプット/アウトプットが高速でできたので効率的に知見を貯められたなという実感があります。。。

大谷氏:言語はやはり好きですし、フレームワークなどその周辺のエコシステムもゲームと同じくらい好きなんですよね。理解できないものがあって、吸収する瞬間がたまらないんです。壁に当たると嬉しくなってつい勉強したくなる感じですね。

ブログとかはなるべく見ないようにしていて、体系的に学べる本を読んでいます。ネットはあまり信用していないです(笑) TIPSは最新の情報が必要なので、そういう時にネットで情報を得ています。

田中氏:インプット方法はすごく古いイメージがあります。

大谷氏:どの段階の情報なのか分からないケースもありますし、書かれた人が実行して得た知識なのかが同じ用にはっきり判別できないこともあるので、基本は本か公式ドキュメントを基にしていますね。Rustは特に公式ドキュメント良いですね。

Rustの日本語ドキュメント

キャリアは何を作りたいかによって決めるのが良い

田中氏:エンジニアのスペシャリストとジェネラリストについてはどのようにお考えですか?何を得意とするとか色々あると思いますが。

大谷氏:所属している会社や進みたいキャリアから逆算して、そのソリューションとしてよりコアなものが求められるのであればスペシャリストになった方が良いと思います。

プロダクトをチームマネジメントしてスケールさせたり、インフラ周り含めてバリバリやりたいのであればジェネラリストを目指す必要がありますね。進むべき方向を定めた上で進んでいくと良いと思います。

なので、スペシャリストを目指したいというよりかは、何を作りたいかによって決めるのが良いのではないでしょうか

私も一番最初の会社に今も居続けたら、おそらく研究開発をしているのでC++やRustなどの低レベル言語のスペシャリストになっていたかもしれません。それが必要とされる世界ですからね。マネジメントもやっていたかもしれませんが。

ただその会社には今はいないので(笑)、必要なものを先回りして遅延学習した結果、ジェネラリストにならざるを得なかったですね。

私のようなキャリアを積むのであればジェネラリストになるのが必然と言いますか、自分自身含めてチームでいろいろな知識を組み合わせながら多彩なソリューションを提供していく必要があります。

マネジメントに関しても、様々なソリューションを結合させる必要があるので避けては通れないです。

マネジメントも含めて、バックエンド、フロントエンド、インフラ、デザインを広く理解し、ただどこかは尖らせるといったキャリアを目指すことになると思います。

田中氏:新卒の時から受託開発をやると営業から納品まで全て一人でやらないといけないですよね。プロダクト思考がそれによってつきますよね。

大谷氏:誰かに聞くのが苦手かもしれないですね。教えを乞うというか、一人でやってきたので。そこはデメリットかもしれません。

ただ、一人でひたすらやってきたことで、目的に対して手段を柔軟に考えながら、なんとか成果を出していくという、「野武士力」はあるかもしれません。

田中氏:「野武士力」は、「これまで経験したことがないことでも最短でインプットして、結果を出すこと」。今まさに僕が管轄している全チームで大事にしてほしいこととして言っていることなんですよ!

大谷氏:実は横で聞いていました(笑) 良い言葉だなぁと思って聞いてたので使ってしまいました。

野武士力は身につきましたし、無い限りはスタートアップのCTOはできないと思います。精神的に辛いですし、自分で責任を取る力や、表立って話していく力が必要になります。

自主性という根底には好きかどうかという考えがある

田中氏:ありがとうございます。

冒頭に立ち返って「35歳定年説は本当か?」のテーマに戻ると、WEB・ITの中でSMBの中でWebアプリケーションやネイティブアプリケーションを開発しています。特にToCでいうと年齢のフィルターがあったり、プロダクトの開発経験がありスプリントでスクラム組んで、PMやデザイナーとのコミュニケーションをとって、Notionに入れていっていますよね。

これは難易度高いと思います。皆が皆やれていないと思うのですが、市場的にできる人は35歳以下でどれくらいいると思いますか?

大谷氏:私が当時CyberAgentにいた時は、周りにできる人しかいなかったので、その時の仲間をふまえると感覚値ですが全体の2-3割になるのかなと思います。

特別、自走自立できるエンジニアが限られた人しかいないというわけではないと思います。私が当時28歳でしたし、それ以下の人もいたので。

もちろんメガベンチャーの中でもできない人はいますが、半数は問題なく自立自走できていた印象があります。ユニコーン的な存在ではないと思います。

田中氏:メガベンチャーやスタートアップなど小さめの組織には結果的に自立自走型のエンジニアが残るということですかね?

大谷氏:その意見は正しいと思います。

田中氏:経営者や人事の中には、プロダクト志向の高いエンジニアを採用したいという意見もあります。

大谷氏:エンジニアであれば基本的にプロダクトが好きで、色々なSaaSサービスを使って好きになる人は多いですよね。

色々なサービスを「こういう仕組みは綺麗でかっこいいな」「自分で作りたいな」という思考で見て行った結果、自分が使いやすいと思うサービスについて言語化できない感覚的な判断軸が生まれるようになると思います。

最近だとNotionも使い勝手がシンプルですし、かっこいいですよね。

▲ ドキュメントツール「Notion」。overflowでもNotionを使用している。

田中氏:結局、1から自分でアプリを開発して運用しているかとか、自主性があるかどうかも大事だと思います。

大谷氏:自主性という根底には「好きかどうか」という考えがあると思います。好きなら自分で学びますからね。その中で共通的な美意識も生まれると思っています

田中氏:プロダクトマネジメントの本もありますよね。

大谷氏:そういうものを読むと、より言語化できると思います。私もユーザーストーリーマッピングなどの本をたまに読みますね。

基本は定年説はない

田中氏:「35歳でエンジニアになった友人がいますが、この定年説が成り立つと仮定するとスタート何歳のエンジニアに対して言われている定年説なんでしょうか?」

大谷氏:定年説の背景は、私も正直微妙というか、なんでこれが流行ってるのかわからなくて、SIer関連から生まれた言葉だと思っています。

ロールモデルになる人がマネジメントをやらないと給料上がらないといったことがあるんですよね。

私がちょうどWebが流行ってきた頃の世代なので、Web業界としては定年説でいう年齢を超えた人たちがぼちぼち出てき始めたのが今なんじゃないかと思います。なので、今の35歳以上の人では定年しているといった結果やソースはなくて、私含めてそのような年の方たちは模索している状況だと思います。「35歳定年説」というワードが先行している状態だと思います。

田中氏:僕の友人のスタートアップは35歳までの人を採用するようにしていました。

大谷氏:年齢が上がるにつれて単価が高くなるという前提であれば、同じソリューションが提供できる人がいるとすると若い人を採る、それだけだと思います。閾値としてわかりやすいのが35歳になるのかな、と。

基本は定年説は無いし、ソリューション提供力を増やし続ける限りは意識しなくて良いんじゃないでしょうか。

ただ、成長止めて停滞している人は、定年説は意識すべきだとは思っています。例えばエンジニアリングマネージャーや、デザイン学んで一人で全て作れるとか、スペシャリストとしてコアな課題を解決するとか、そういった技術があれば年齢を見ている会社も雇う理由がたくさん出てきます。

求められるものを客観視して先を読んで動けるかが大事です。私もマネジメントやファイナンス、経営的なものを必要があれば学んでいく意識は持っています。プログラミングにおいても学び続ける意識が大事ですね。

お金を稼ぐだけであればなんとなくでも良いのかもしれないですが、年齢が上がるとともに、ダウントレンドに入らないようにしないといけないと思ってます。

田中氏:今、カスタマーサクセスで同じような経験をしていますが、能力高くて候補に入れるけど年齢で断る場合もあるんですよね。

大谷氏:なぜ35歳が区切りになるのかは、論理的な理由は私は分からないですね。SIerの定年説が言葉だけ先行しているイメージがやはりあります。

ただこれを覆すのは難しいです。よりコアな専門領域が必要になる程、ある程度経験のある方のほうが高度なものを提供できることが多いので、エンジニア側からすれば自分の価値を上げていくことを重要視した方が良いですね。

~~を学んでいましたや、~~~言語が書けますといったことだけだと、その価値を証明するにはちょっと弱いので、経歴や実績で証明できるよう経験も深めていけばいいのかと思います。

なので、背景を知らずにリテラシーなく単なる年齢だけ見て区切っていくのはナンセンスだと思います。

田中氏:さまざまな組織 / ポジションを経験してきたからこそ語れるキャリアの話や、CTO経験を踏まえた『野武士力』というエンジニア観など、大谷さんならではのお話を聞かせていただきました。ありがとうございました!

この記事をシェア

関連記事


副業・フリーランス

プログラミング

デザイン

インタビュー

お金

採用・組織

転職

イベントレポート