CLOSE

Re.33 「技術力」って何?(全3記事)

一騎当千のスペシャリストか、万能のジェネラリストか AI時代のエンジニアにおける"スキルツリー"戦略

Engineering ManagerによるEngineering ManagerのためのPodcast「EM . FM」。単なるスキルの蓄積ではなく、問題設定力と解決力の融合、探究心の重要性、そしてキャリアパスにおける位置づけまで、幅広い視点から「技術力」の真の姿を探ります。AI時代におけるエンジニアの役割にも触れ、技術者に求められる本質的な能力を再考しました。全3回。前回の記事はこちら

スタッフエンジニアとキャリアラダー

広木大地氏(以下、広木):ちょっとその中で……けっこうしゃべりすぎちゃったので(笑)、もう少し別の話をすると、最近こう……最近というわけじゃなくて、いわゆるスタッフエンジニアが、技術力的なものを見いだしていった先に、スタッフエンジニアとして一騎当千の活躍をするような、そういうIndividual Contributorの在り方みたいなものが、時々、本も出ましたし注目されることが出てきたと思っています。

これはいわゆるデュアルトラックのキャリアラダーと言われるような、エンジニアのグレードが上がっていくと、あるところからスタッフ系のエンジニアとエンジニアリングマネージャーみたいな管理者のコースに分かれていって、EMになる人は、次はディレクションやVPoEになってCTOになるとか、スタッフエンジニアがプリンシパルエンジニアになっていくみたいな。

そういうふうに階級が途中でスペシャリストとして分かれていったり、管理職として分かれていくみたいなキャリアのラダーが用意されていることが増えてきているかなと思います。

僕もそういう環境でキャリアを築いてきたところがあるので、それはいいのかなと思うのですが、ちょっとイメージが、そういうキャリアを目指していくこと自体はポジティブだと思いつつ、それのイメージは釣り合っていないことが多いなと思っています。

要は、マネジメントと同格に当たるIndividual Contributorの割合はどのぐらいいるんでしょう。どのぐらいが会社にとって適切というか、あり得るかたちなんでしょう、というのはけっこう考えると難しいところがあります。

というのは、例えばエンジニアが10人しかいなかったりすると、その中で特定の専門職みたいな人、スペシャリストみたいな人を雇用してマネージャーと同格の給料を出すだけのことができるかというと、できないことが多いと思うんですよね。

いろいろやってもらわないと進まないみたいな。フロントエンドのスペシャリストだけじゃなくて、要は、コーディングをしてちゃんとプロジェクトの管理をしてとか、いろいろやってくれないと割に合わないことが多いのに対して。

1,000人とかいるようになると、この領域のスペシャリスト、狭い領域のスペシャリストが1人いると問題解決になってうれしいみたいな、やたらめったらアクセシビリティに詳しいとか、そういうことが成立することになっていくと思うんですよね。これは、10人の会社でやると、そこの観点だけではちょっと難しいです、ということになると思います。

多くなっていったとしても、管理職の人数はだいたい、例えば10パーセントぐらいが適正ラインだとして、1,000人いたら100人が管理職です。1,000人のエンジニアがいて100人が管理職ラダーにいて、この管理職ラダーより多いかというと、そうじゃないことが多い。

管理職並みの給与がもらえるIndividual Contributorがその半分だとすると、1,000人いて50人くらいしかスペシャリストキャリアにチャレンジしていく人はいない状況になるわけです。

これは、普通にラダーとして管理職にならないところの給与帯が高い会社がけっこうあるので勘違いされがちですが、例えばそういう大手のテックジャイアントみたいな企業でも、本当にプリンシパルやスタッフクラスの人は、めちゃめちゃ少ないわけですよね。なので、ヤフーさんとかだと「黒帯」みたいな制度とかあったかなと……そんなにメチャクチャいるわけじゃないです。

一騎当千のエンジニア

広木:そうすると、スペシャリストクラスのラダーとして働ける人はそんなに多くなくて、その人は一騎当千の結果を出していきます。「当千」とまではいかなくても、少なくとも10xプログラマーと言われるような、人の10倍以上の成果を出せるような人だから、1チームを任せるんじゃなくて、この人はもう1部署と同じぐらいの戦略的意味があるから、部長と同じような給料帯なんだよねみたいなことがアサインされるわけです。

そうなった時の成果は、通常想像している「仕事が速い」的な要素とは質を異とするわけですよね。この人がいないと解決できなかった会社の大きな問題が、その人によって解決できるわけです。

少なくともその製品の大きな生産性に影響を与えたり、パフォーマンスに影響を与えたりするかもしれないような成果を残していける人になっていて、それは、キャリアとして目指すのはなかなか難しい部分もあります。

実際そういう人は、最初っからそんな感じだなと思うんですよ。最初からそういう探究心がメチャクチャあって、この人はスペシャリストキャリアとしてぶち抜いていくんだなというタイプの人がぶち抜いていきます。

あるところまで普通のエンジニアだった人が、あるところまでノーマルなキャリアだった人が突然、「スタッフエンジニアの方向に行きます」と言って行くような感じじゃなくて、「この人、異質だな」という人が上がっていくような、そういうレベル感のものだと思っています。

それを「やります」って言うのは、けっこうチャレンジングなことだなと、少なくとも、「マネジメントやります」よりは、チャレンジングなことだなと僕には見えています。

そういう、「一エンジニアとして成果を残せるキャリアを目指したいです」と言うわりに、ちょっとそうじゃないよみたいな。今までどおりのことをやっていたら、そういうふうなグレードで上がっていくっていうイメージでいるとなかなか厳しいよという現実の部分が見えないまま、今と同じことをやっていたいの裏返しで、技術力の話に転嫁されていくような構造も、ままあるなと思います。

レベルアップではなくスキルツリー

広木:これはあまり健全じゃないなと思っていて、イメージとして、レベルアップのイメージと、スキルツリーのイメージをイメージすると想像しやすいのかなと思っています。

レベルアップは、スライムをいっぱい倒してもレベルは上がるじゃないですか。だから、いっぱい同じことをやっていると、気がついたらレベルが上がっていて、レベルが30になったら次のことに挑戦できるみたいな、そんな感じだと思います。

しかし、エンジニアの技術スキルは、レベルアップ方式じゃないんですよ。スキルツリーのように、あれもこれもやっていったら、次の難しい課題とか、これに挑戦してみようみたいなのが無数に選択肢がある中で、異様なこだわりを持ってある1個のスキルツリーだけ掘り下げて、ある1個の方向に深めていったら、そこに金脈があって、それを持っていると会社の中ですごくレアな存在になって、結果的にメチャクチャ大きな問題の解決にたどり着けるみたいな。

そういう、スキルツリー方式になっている部分があって、その掘っていく速度は、異様に速かったり幅広だったり深かったりする人が、こういった一騎当千のエンジニアになっていくなと思います。

逆に、レベルアップ方式で同じ課題をこなしていこうっていうふうにやって、慣れたなっていう先にあるかというと、その先にはそのジョブはないです。それは、けっこう当たり前にこなした上で、なにかそこの部分を掘っていく感じにならないと、テックキャリア、テックだけの部分というのは難しいです。

このスキルツリーをどう幅を広げて……なり、深さを取って、自分のアイデンティティを作っていくかというのがキャリアプランだとしたら、やはりそこには、明確な課題や興味を自分自身のキャリアの中に持てていないと、そういうふうにはなりづらいのかなと思います。

汎用的にいろいろなところをちょこちょこって取るだけじゃなくて……とか、同じことを繰り返すだけじゃなくて、やたら幅が広いとかやたら深いとか、2ヶ所はメチャクチャ深いんだけど、この2ヶ所が同時に深い人はいないよなとか、そういう感じでキャリアを作っていくイメージなんじゃないかなと思っています。

そこが技術力の正体で、スキルツリー方式的な部分で課題解決に役立てる設定力と課題解決力、知の探索の部分と、深く解いていく部分の両立なんじゃないかなと思っています。

今、そこの領域は、東大の数学の問題をポンと生成AIに投げたら簡単に解いちゃうような感じの時代の中で、一騎当千的な活躍ができる幅は、今めちゃめちゃ広がった瞬間だと思うんですよね。

「いつまで我々は、人をマネジメントしないとソフトウェアが出来上がらないのか?」というのは、今の時代に持つべき大きな問いだと思っています。

1,000人分のリソースは、別にクラウドで提供してもらえばいいじゃないと考えて、その問題解決に臨んでいくのが、ここから先の一騎当千で結果を残すことの重要なポイントなのかなと思っています。っていうところですかね、ゆのんさん。

マネジメントと個人の能力

湯前慶大氏(以下、湯前):ちょっと、最後のAIの話とはちょっと違うというか、戻っちゃう話ですけど、技術力というかエンジニアリングという意味でのスキルをどんどんつけていくことと、マネジメントのところも結局そういうのもあるかなと思っています。

そして、マネジメントや技術だけではなくて、そのほかのところもけっこういろいろと、深くももちろん必要だけど、いろいろなスキルツリーとしていろいろなスキルをつけていくことによって、そこから表れてくる見え方が変わって、また新しい課題解決ができるようになっていくのは、けっこういろいろなところにも共通しているのかなと思います。

そういう意味では、技術力の話だけでもなく、いろいろなところでも通用する話なのかなと、聞いていて思いましたね。

広木:これは、そうなんですよね。なので、仕事力とも言い換えられるじゃないっていうところ。

湯前:はいはい、そうですね。

広木:僕自身は、けっこうそうかなと思っていて、単にマネジメントするのも、自分の知恵やコンピューターのリソースを使って解決できる問題を解決するのか、やはりお金や人を調達して問題を解決するのかという、必要なリソースをどこに定義するか、問題解決のためにするかという違いでしかなくて、どちらもできるに越したことないなと思うんですよね。

マネジメントで問題解決することもしたほうがいいし、技術的な方法論で問題解決もできるようにしたほうがいい。だけどそのうち、人海戦術というか人のリソースを調達したりお金のリソースをしてきて解決するわけではないことに限ると技術力になるみたいな、そんなイメージですね。

ドメイン知識の重要性

佐藤将高氏(以下、佐藤):なんかちょっと、ドメインによったりの話もけっこうあるなと思っています。何でしょう。問題解決しようとした時に、各ドメインで、やはり自分の携わっている業務の領域はこういうことが起こっているから、こういう問いの設定の仕方のほうが一般的にはこうなんだけど、うちの業界だとこうだよねというふうな、ちょっと違う解決の仕方とかは、やはり生まれてくるなと思っています。

それは、今やっている業務や、もしくはその会社でしか出てこないようなこともあるから、それもユニークさにつながってきたりするし、いろいろなドメインでいろいろな解決をしていく強みみたいなところも出す必要もあるかもしれないですが、「ここの領域だったらこういうことをやってきたから」と自信を持てるような状態も、もっと作ってあげたいなと僕は思ったりしました。

それぞれのドメインでの良さ。大規模の開発や少人数での開発とか、いろいろなものもあるし、こういう業界はこうだしねとかというのもあって、掛け算でスキルというか技術力を高めていくみたいなところも1個、手なのかなと思ったりしました。

広木:そうですよね。なので、どの問題を設定するのかということで、ドメインが深くなればなるほどその解決策が比較的シンプルであったとしても、すごく劇的な成果につながることもあったりすると思います。

そして、そういった珍しい環境に自分が置かれていること自体が、いい問題を解くチャンスになるかもしれないという感覚を持てたほうが、キャリアという観点では築きやすいのかなと思いますよね。

佐藤:「大規模開発をした経験がないといけないんじゃないか?」みたいな、僕も新卒ぐらいの時にそう思ったりしたのですが、必ずしもそういうわけではないです。もちろんやっていたほうが大規模のスケールのさせ方とかがわかるからいいけど、とは思うのですが、一概にこれだよねというものに当てはまって行動しなくてもいいんじゃないかなと思います。

広木:そうですよね。そういうふうに問題は自分の状況に置かれているから最適化して解いたほうが、ユニークな経験や技術的な力を発揮しやすい部分、いい解決策になりやすい部分があるのに、流行っているものをそのまま取り入れる感じのほうが好きという人もいるじゃないですか。

それは、うまくチューニングできるならいいのですが、チューニングしていないで持ってきて、やるだけやって転職しちゃうみたいなことをすると、いろいろな人に迷惑をかけるからなと思うところがあります。

そこを、自分なりに考えて、「これがいい」と思えるところまで深く思考して取り組んできたことが、僕は、けっこう技術力に転化される部分があると思っています。

それがどこかから持ってきたものをそのまま読み上げるみたいな感じになると、経験として弱くなっちゃう。自分なりに考えたことがやはり重要なポイントなのかなとは思うんですよね。

生成AIと技術力

湯前:先ほど、最後に生成AIの話も出ましたが、生成AIを使って可能性を広げていくこともとても大事で、今いろいろな会社でもやっているところだと思います。

例えば生成AIに、「こういう時にどうすればいいんだろう?」というのを考えていろいろ案を出してもらった時に、その中で、「このやり方は絶対ないよな」みたいなのを判断できるかどうかもけっこう大事だよなと思っています。

鵜呑みにしすぎないで自分で考えてなにかを決めていくことは、結局、自分なりにその周辺の知識やスキルがないと難しいところもあるかな、意思決定ができないかなと思うので、そういう意味での自己研鑽は、いろいろな意味でも必要なんだろうなと思うし、そういう幅広い角度から見ていくことは大事なんだよなと思います。

広木:そうですね。なので、技術的なものに関して手触り感を持ち続けるみたいなことがないと、どういうふうに使える道具なのかわからなくなってしまいます。だから、そういった意味で、そういったエンジニアリング的な所作として、よく、「毎年新しい言語をエンジニアは学んでおいたほうがいい」と昔ながらの教えとしては言いますが、毎年1個ずつやっていると、「あっ、今こういうのがあるんだな」とか、「こんな考え方があるんだな」とかが身についたり、それが使える道具に変わっていくという意味では、ちょっと新しいものに触っていくことは、ぜんぜん悪いことではありません。

しかし、そこが強迫観念的になっちゃうとあまり意味がないなと思っていて、なにか解決したい問題に対する手がかりや課題意識は持ちながら、なにかを掘っていこうというような、そういう探究心みたいなのが重要なのかなと思っています。

「世の中で流行っているから、これ知らなきゃ」みたいなことを繰り返していると、常に世の中から一歩遅い人みたいになっちゃうので。

湯前:(笑)。

広木:そういうのじゃないアプローチが、けっこう重要なのかなとは思いましたね。そろそろ終わりにしますか(笑)。

湯前:というわけで、あっという間に時間が過ぎてしまいましたが、今回は、広木さんから、「『技術力』って何?」ということについてお話しいただきました。

今日はどうもありがとうございました。

広木:ありがとうございました。

佐藤:ありがとうございました。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!