キャリアに悩んだ時は、難易度が高そうなものを選ぶ
加川申祐氏（以下、加川）：ここ（までの話も）深掘りたいんですが、次のトピックに行けたらいいかなと思っています。
次は「キャリアに悩んだ時に何を指標にするか」というところです。また都筑さんからお話してもらえたらいいですかね。よろしくお願いします。
都筑友昭氏（以下、都筑）：わかりました。自身の経験をもとにしゃべるんですけれども、特に若い頃、自分はソフトウェアエンジニアからガッとキャリアチェンジしています。若い頃はけっこう興味が大きかったかなと思います。
振り返ってみると「どっちに行こうかな？」と悩んだ時に意識していたのは、難易度が高そうなものを選ぶことでした。ただ、やはり難易度が高いだけだと本当に折れちゃったりするというか、普通に「無理でした」みたいなことがあると思うので、少なくともそのタイミングでは自分が本当にやりたいと思っていて、かつ「こっちのほうが辛そうだな」とか、「難しそうだな」となったら積極的にそちらを選ぶというのが自分の考え方としてあります。
今はある程度シニアになってきて、自分がやりたいということだけで何か選択していくのはなかなか難しくなっている部分があると思っています。自分がある程度できることとか、自分の成長軸だけじゃなくてやれることとか、スキルや能力といったものをどうやって価値として社会に還元できるかとか、還元できる状況なのかを考えてキャリアの選択をしているのが直近の状況かなと思っています。
自分なりの“北極星的なもの”をしっかりと定義して、後悔しない場所を選ぶ
加川：2人は何かありますか？
武藤悠輔氏（以下、武藤）：そうですね。私がキャリアで悩んだ時に指標としていることでいうと、究極で言えば、どこまで内省を深めるか。自分のやりたいことというか、ある種の生きがいみたいなものを見つけられるところなのかなと思っています。いったんそういうのを取り除いて、もうちょっとシンプルに言うと、何年か単位とか、長期的な目標をしっかり立てることが大事かなと思っています。
エンジニアのPRD（Product Requirements Document）のドキュメントの説明する時の言葉を借りると、「北極星を作る」みたいなことが僕はけっこう大事かなと思っています。
例えば自転車に乗る時とかに、行き先を見て自転車に乗ると真っ直ぐに行けるんだけど、足元を見るとフラフラしちゃうようなことがけっこうあると思っています。なので、結局自分がどこを目指したいかを、短期にこだわらず、ある程度長期的に見て動くことが大事なのかなと思っています。
自転車での足元が何かというと、スタートアップだと必ず苦しいタイミングが来るので……。弊社でも今後またどこかで苦しいフェーズが来るんじゃないかなと思います。今はけっこう楽しいフェースですが、やはり事業がちゃんとスケールしきらないタイミングが来るんじゃないかなと思っていて、そういう時に表面的な待遇、例えば給料面、あるいはストックオプションの量や、自転車の足元みたいな場所に集中していると、たぶんどこかで挫折して転んでしまって、他のほうが魅力的に見えちゃうことがけっこうあるのかなと思っています。
「自分として何年かかけてやり遂げたいこと」とか、自分なりの北極星的なものをしっかりと定義して、それと自分が関わる会社が同じほうを向いているのか、違う場所に北極星を定義しているのかをしっかり見て、没頭して後悔しない場所に行くのがキャリアを選ぶ時には大事なのかなと思っているところです。
自分が得意なことと苦手なことを、振り返りで把握しておく
三上悟氏（以下、三上）：なるほど。じゃあ僕も話しますか。キャリアに悩む時は今でもありますよ。何せ6社もやっていますからね（笑）。指標が定量化できるといいんですが、定性的な話になるかなと思っています。なんだかんだで僕は1年とか半年みたいな感じで振り返りをけっこう行っているので。
当然、会社でも半年に1回目標設定とか目標の評価があるフェーズでもあるので、その時に自分ができたことや会社に貢献できたことを振り返って、自分が何が得意で何が苦手なのかを知っておくことが大事です。
シニアエンジニアになってくるとできることが増えるので、これもやりたいしあれもやりたいし、「新しい技術、（例えば）ChatGPTやLLMとかを書けないといけないよね」みたいな感じにもなりがちですが、どれも中途半端に終わって結局成果がなかなか伸びなかったりするので、やはり誰にも負けない得意な部分は持っておくというところ（は大事です）。
あとは、苦手なところや学習コストがメチャクチャ高いところは自分よりできる人を見つけて、その人に引き継ぐとか渡す勇気はすごく大事かなと思っています。
僕も部門で一番上のポジションにはいたんですが、今の上司は私より若くて得意な分野がぜんぜん違うので、それぞれに役割を意識した上でその仕事をパスします。
お願いするわけじゃなくて、パスする感じでボールを渡していけるところを意識しながら……。自分はその経験もあるので、相手の気持ちもわかった上で今の自分に何ができるかみたいなところを考えたりしていますね。
武藤：三上さんに聞きたいんですが、今の仕事では「今この瞬間」に悩んだりしていないんですか？ 「キャリアに悩んだ時」って、（表現でいうと）過去形の（ことの）質問みたいな感じだったんですが、今の悩みみたいな（ものは……）。
三上：今も悩んでいますよ。今も「僕はここのテックリードで（いて）価値があるのか」と考えているので（笑）。これは過去形でもないし本当にリアルな話ですよ。
テックリードを置いている会社はまだそんなに多くない
武藤：テックリードを置いている会社はまだそんなに多くないんですかね？ それともけっこう置かれているものなんですかね？
三上：多くないですね。本には「一般的には10人ぐらいの中に1人ぐらい（いるの）がちょうどいい」と書いてありましたけどね。
武藤：なるほど。それはマネジメントせずに技術をリードする人として置いておくというところですか？
三上：そうですね。組織の作り方によるところはあると思いますね。結局、他にもプロダクト開発のリードをする人はいるので、そういう意味でいうと、チームの中でリードテックやエンジニアリーダーみたいな人が本当にすべてのエンジニアのコードレビューをするかというと、しないです。
新しいプロダクトを作るとかアーキテクチャを考えるみたいな、もうちょっと基盤的なところをやるのはテックリードかというと、他の別メンバーがやったりするんですよ。だから僕がマネジメントをしているところは（組織）全体の2割ぐらいで、（他の仕事として）プロダクトのバックエンド開発をするところはあって。そういう意味でいうと、すごくもどかしいところでやっているといえばやっているんですよね。
武藤：先ほどの業務内容を聞いていて、VPoEと名乗ってもCTOと名乗っても嘘でもないような業務をされているように感じていたので。
三上：そうなんですよ。だからそういう意味でいうと、両方の経験があるから、わかった上で……。そういう意味では僕は面接官もやっているし、（役職が）被っていると言えば被っていますね（笑）。
だから、技術だけが尖がっていて、「何かをやるスペシャリスト」みたいなところじゃないんですよ。僕は最近そこはちゃんと分けたほうがいいかなと思っています。
「エンジニアの役割」の言語化に伴い、キャリアの整理はしやすくなっている
三上：そういう意味では、テックリードはすべての技術スキルがレベル99みたいになっているイメージをしがちだと思うんですが、それはデベロッパーエキスパートだと思っているんですよね。
だから例えば、iOSのプラットフォームについてメチャクチャ詳しい人とか、Androidに詳しい人とか。AndroidにもiOSにも詳しい人はいるけど、スペシャリストというか、両方書けるけど尖っている人はあまり見ないです。
やはり1つのプラットフォームに尖って（いる人が）、いわゆるカンファレンスに登壇したり運営したりというイメージがあります。テックリードはテクノロジーマネジメントなので、マネジメントの仕事をしているんですよ。
武藤：なるほど。確かにそうですね。テクノロジーのマネジメントをしている。
三上：ソフトウェアを作ってサービスを提供しているから、やはりそこのベースラインを上げるところを考えなければ、アウトカムはなかなか出ないです。みんなの開発の速度や生産性を上げるためには、そういった全体を俯瞰した上で効率を意識して作っていかなきゃいけないから、本当に特定の言語に詳しいとかフレームワークに詳しいとかではぜんぜんないというのが僕の考えているテックリードですね。
CTOも同じイメージでやっていると思うので、できるならその部分を他の人にパスしたいと思っているんじゃないんですかね（笑）。どうでしょうか（笑）。
都筑：そうですね。CTOの役割も非常に幅広いんですが、まさにその本にスタッフエンジニアの類型の話が書いてありましたが、やはりテックリードはテクノロジーのマネジメント（をする人）なんだなというところです。
自分は他の人に任せるか、もしくは例えば誰かにVPoEになってもらうことは考えますね。
ただ、やはり1人で全部できることはないように思っていて。スタッフエンジニアを含めてエンジニアの役割がどんどん言語化されていく中で、そのあたりはすごく自分の中で整理しやすくなってきているなと思っていますね。
加川：ありがとうございます。
（次回につづく）
