#24 強いエンジニアを言語化する

00:00

こんにちは。言語化.fmは、あんな話やこんな話を、きりんと伊達の2人で緩く話しながら、言語化を試みるポッドキャストです。

というわけで、今回のテーマは、強いエンジニアとは何かを言語化していこうじゃないかと思っております。

強いエンジニア。

強いエンジニア、言語化したいですか?

したいって聞きました、僕は。なんかしたいという噂。

僕があげたんですけど、一応経緯をお話ししておきますと、

あるイベントに行ったときに、つい最近、だいぶオフラインのイベントを抱えてきていいなと思っている昨今でございますけども、

その中、直接会ったことのない、SNSで僕のことを知っているという方にお会いしまして、その方がある質問を僕にぶつけたんですね。

強いエンジニアになるにはどうしたらいいですか?って言われたんですよ。

その瞬間、僕はこのFMで話すトピックやなって思ったわけなんですけども、

ぶっちゃけ、別に僕ら強いエンジニアだと思っていないかもしれないし、

なりたいと思っているかどうかよく分からないんですけども、

でもやっぱり強いっていうかね、強いってすごい曖昧な言葉じゃないですか。

そうだね。

強いエンジニアって一般に言われたときってそれって何に指してるんだっけっていうのを、

多分人によって違うって話もありつつも、

我々が考える強いエンジニアとは何ぞやっていうのをおしゃべりしておくのは、なんかいいんじゃないかなと思って。

いいと思います。

多分これ話すたびに変わっちゃうし、

年を取ると多分また無駄に多感して変わるんだと思うんです。

だから現時点のこの令和5年、何で悪気で言ったことがないけど、

2023年の10月時点での我々の考える強いエンジニアとは何かというのを言語化してみようと思った次第でした。

よっしゃ、やっていきましょう。

確かに毎月変わってる可能性さえあるね。

毎日変わってる可能性さえあるよね。

あるね。

なんか、すごいクソ真面目に強いという言葉を考えた時に、

スポーツとかはわかりやすいなと思ってて、勝ち負けがあるから。

どんなスタイルだろうと勝つ奴が強いじゃん。

そうだね、試合に勝てば強いっていう風になるよね。

ズルくても、ドロくさくても、かっこいいテクニックがなくても勝つ奴が強いけど、

別にエンジニア勝負の世界じゃないから。

いやー、なんかいろんな軸があるよね。強いもの。

スポーツの話もさ、試合に勝てば強いと思われるっていうのがあったけどさ、

03:01

じゃあ結果が全てですかっていうとさ、

そういう側面も正直あるとは思いつつも、

でも、じゃあ例えばプロ野球のスカウトとかもさ、優勝しないとスカウトされないわけじゃないじゃん。

なるほど。なるほどね、確かに。

実は意外とプロセスも見てるっていう。

いい論点ですね。なるほどね、確かに。

強く、あー、

いやー、面白いな。

確かにな、そのスナップショットでの強さだもんね。

今俺が話した、試合が。

その試合ではその人が強いんだけど、

今出してくれたプロ野球の世界とかだと強くあり続けられる人材かみたいなのが一つ資料としてある。

そうだね、その一点突破型か、

マラソン的に長期間頑張れますみたいな。

いやー、エンジニアはなんか校舎の話が、

例えるならすごいしっくりくる気がするな。

なんか、分かんない。

キリンの思う強いエンジニアを、

今、超抽象度高く雑に言えるとしたら、

なんか、一定以上のスキルセットを、

コスパよく吸収し続けて、

業務の、その業務レベルを一定以上に保てる人は強いと言えるんじゃないかという気がした。

なるほどね、多分これいろんな方があって、

例えば、他の人にはできない超難しい実装を何なくやってしまうっていう人とか、

他の人よりも手が早くてすぐ機能が出来上がるとか、

障害対応がピカイチとか、

なんかそういう、ある種一点突破型に見えるところと、

とりあえずスケジュールに遅延なくコンスタントに仕事がこなせる、

コーディングがこなせるタイプの人、

大変タフで、どんなに長時間働いても、

どんなに長時間って言ってもちょっとブラックみがあるけど、

長く働けるとか、いろんな方があるなっていう気がしたんですけど、

そういった意味ではキリンさんはどこにはまるんでしょう?

でも、僕は強いて言うのが、

前者も、今だてしが言ってくれた前者の中にも、

一点突破と継続型が僕はある気がしていて、

例えば、特定の実装がめちゃくちゃ早いみたいなので、

条件付きの人もいると思うんですよね。

特定の言語で10年選手で言語使用を完全にし尽くしていて、

06:01

ライブラリーもあれとあれと使えばあれができるみたいなのが分かってるから、

その言語においては、それも継続型か、

ダメな散らかし方したな、ちょっとリセットするわ。

一旦切りまーす。

恥ずかしいな。

例えば、いやー。

でも今の話は経験の話が感じがしてて、

結局、引き出しが多いというか、

LINE聞いてもすぐ答えられますみたいな人もいるし、

そんなのどうやって知ったの?みたいなのもあるわけじゃないですか。

そういうのって、すぐに思いつく、

頭の中で計算して思いつくことは不可能なので、

たぶん普段からいろんな新しいものに触れて、

知識を蓄えて、引き出しを増やすタイプの人だと思うんだよね。

確かにそうかも。

同じ一見すると、

同じスクリプトって思っているように見える人が2人ととしても、

今言ったような、今私が言ったような振る舞いをできている人は、

継続して技術が変わったり、同じ技術であっても、

環境が変わっても、同じパフォーマンスを出せるし、

そういう振る舞いができていない人からと、

応用が効きづらいみたいなところはある気がするな。

応用が効かないはあるよね。

だから、

その関連で言うとさ、

綺麗なコードを書く人は強いかっていう話があって。

はいはいはい。

みんなが好きそうな命題かも。

いい原点だね。

新卒の頃の気持ちが蘇ってきた。

やっぱりほら、リーダブルコードとかみんな読むでしょ、きっと。

そうですね。読みましたよ。

ペキペキペーの時は。

いやー、綺麗、いやー。

いや、なんか、

いや、僕、答え出ました、僕の中で。

整いました。

課題解決能力が高い人が、僕は強いエンジニアだと思うわ。

その心は、

綺麗なコードを書くのは課題解決の手段だと思うんですよね。

シンプルに。

綺麗なコードを書くのは別に目的ではなくて、

例えばチーム開発をしていく上で、

そのチームメンバーとか組織とかのメンバーが、

なるべく長く運用保証しやすいとか、

回収コストが低いみたいな、

賞味期限の長いコードを書くっていう目的があって、

綺麗なコードを書くみたいなところがあって、

で、

なんで、先にも解きたい課題があって、

その手段として綺麗なコードを書くっていうのがある話だから、

同じ綺麗なコードを書けるっていう人でも、

聞いてるあなたのことを話してるわけではないと強くエクスキューズした上で言うと、

09:03

綺麗なコードを書くことが目的になっている人も、

今まで少なからず見たことがあって、

そういう人は僕的には、

課題解決能力が高いとは結びつかないかなと思ったりする。

確かに書くことは綺麗なんだけど、

解決したいことが何かが目的だったり、

解決したいことにも別に直結してないから、

その場面でその手段は適してないよねって思うというか、

そういう立ち回りをしてると、

僕的にはそんな必ずしも強いわけじゃないなと思います。

いかがですか?

98%くらい同意した上で、

あえて深掘ってみますと、

綺麗だねって思う瞬間っていうか、

綺麗なコードを眺めた、

今の話で言うと、

綺麗なコードイコール課題解決能力が高いっていうお話だったと思うんですけども、

綺麗なコードを手段として適切な場面で使いこなせる人。

そうするとさ、綺麗なコードを眺めた時でも課題解決した後だったりするじゃん。

そうだね。

それはさ、そのコードを見ても感じ取れない可能性はあるよね。

あるね、確かに。

そうするとさらにもう一段深掘りしたいのは、

綺麗って何ですかっていうことなんですよ。

なるほどね、綺麗って何ですか。

いやー、綺麗って何なんすかね。

いやでも、答えがあったらみんなこんな苦しんでないよね。

身も蓋もないことを言うと。

そうなんだよね。

結構、

だし、

要するに読みやすいコードが綺麗なコードだと思うんだけど、

読みやすいを言語化するのはめちゃくちゃ難しくて、

まあでも、基本的にはみんながよく知る原則を適切に取り入れたコードが読みやすいことが多いんじゃないかなと思うけどね。

個人的にはさ、GWコードとかに書いてある原則は当たり前すぎてさ、

そういう意義じゃないんだよね、その綺麗だなと思うコードって。

そうだね、そういう意義ではないね。

何なんだろうね。

なん…綺麗なコード…

いやー、難しいな。

ぶっちゃけさ、だいたい読めるじゃん。

よほど汚くなければ。

だからそういう意味では、

綺麗っちゃ綺麗かなと思うコードはぼちぼち見るけど、

美しいとまで思えるコードは、

12:01

まあ思い出せない範囲だと、そんなに数えるくらいしか目の当たりにしたことはない気がしていて、

で、それを今、そのコードを今必死に思い出しながら、

あれってなんで美しいと思ったんだろうなっていうのをね、すごい考えてるけど、

いやー、なんだろうね。

まあいろいろ観点はある気はするけどね、

例えばそのなんか、

あえて言語化するとその抽象化がちゃんとなされている、

ある機能を使った適切な抽象化がなされているみたいなものを見たときは、

綺麗に書けてますねっていうふうに思うことはあるけどね。

何だろうな、使用書、コメントが一切なくても、

それを読めば、まんま凄い整った使用書だよねみたいな感じるときは、

すごい美しいコードなのかもしれない。

そうだね、なんかそのパッと見の感動の観点と、

ちゃんとテストコードが漏れなく無駄な書かれているとかさ。

いやー、それね、出すか迷ったんだよな。

テスト史上主義者ではないから、

絶対に書けというつもりはないけどもね、

なんかここ書いといてほしいなってところがちゃんと書いてあるみたいな。

なんか、そうね、なんか読みやすいって観点を出すと、

僕が真っ先に思いつく反論としては、

例えば正規表現は絶対読みやすいコードを書けないと個人的に思っていて、

あれは人間が読むもんではないけど、でも書かなきゃいけないみたいなときには、

あれは多分テストコードとかセットしないと絶対にいいコードにならないと思っていて、

なんかそういう観点とかを含めると、

このコードが綺麗だからOKっていうことを必ずしも言えるわけではないという気持ちにもなるよね。

もちろんコードだけで完結したらいいんだけど、

併せてテストも適切な流度と適切なボリュームで書かれていると最高って感じかな。

綺麗なコード。

そうだね。

というわけで、綺麗なコードだけが強いエンジニアじゃねえというふうに持っていきたかったんだが、

これ以上話すと綺麗なコードとは何ぞで終わっちゃうから、

これだけで話せる。

立ち返って、綺麗だっていうことも価値の一つにあって、

もちろん課題解決能力、課題解決する際の手段であるっていうのは読みやすさがつながってくるってところもあるので、

一つそうだよねっていうところで、

コーディングも頑張りましょうっていうお話なんだけど、

他にその強いエンジニアっていう要素で言うと何がありますかね。

うーん、なんか要素を出していくか。

俺の中では8角形か12角形ぐらいのスキルマットがあって、

15:01

それを一個ずつひねり出していく作業だなっていう気がしてるんだけど。

でもそれそうでさ、

みんな得意なとこ違うよねって。

違う、全然違う。

ほんとスペシフィックな、一番ロウレイヤーの、ロウレイヤーって言い方ちょっと語弊があるな。

普通にアプリケーションコードを仕様書をもとに死ぬほど書くのが早いみたいな、

かつクオリティも常に一定以上担保できるみたいなタイプの人もいれば、

僕は多分そういうタイプではなくて、もう少しジェネラルなというか、

何だろうな、仕様に口を出したり、

もうちょっと一歩引いて、

アーキテクチャー全体感とかでバランスを取るみたいなのが得意みたいなのもあるし、

あと何ですかね、

なんか話に出たかわかんないけど、

めちゃくちゃ尖った技術領域で、

業界最前線を走るみたいな人も一つの強みだし、

まあ、突き抜けたスキルだよね、と思うよね、って感じ。

そうだね。

だって、俺の中では結構そのiOSでの業界最前線を走りつつも、

まあ、プロダクト中かものづくりの現実世界のところもバランスを取れるみたいな、

スキルマップのイメージを勝手に持ってたりする。

ああ、やっぱそう思います。

そう思いますね。とても良いバランスだと思います。

自分で言うのもあれだけど、割とその辺のバランスは、

自分で自分のことは超スペシャリストではないと思っていて、

割とジェネラリストな方だなって思いつつも、

なんかやろうと思えば何でもできちゃうみたいな。

超プロな仕事家っていうとそうでもないけど、

iOSはプロとしてやってますけども、

他の領域でもプロと言えないところもあるかもしれないけど、

まあ、いないようにいた方がいいかなぐらいのパフォーマンスは出る気がするので。

そうだよね。

いやー、だからそう。

いやー、突きつけて考えると、

俺はもう課題解決能力にたどり着いてしまうな。

結局そうなんだよね。

仕事で評価されるところが強いっていう風にしちゃうと、

多分そうなるかな。

確かにそうかもね。

課題解いてなんぼみたいなとこあるからね。

今の俺の本業での仕事もセキュリティチームでセキュリティのことやってるけど、

セキュリティのバックグラウンド全くない状態から、

それなりにいろいろ頑張っていて、

頑張ってるんですよ。ブログとか頑張って書きますって感じなんですけど、

頑張れてるのは一つ、

課題解決能力が高いからと言っていいのか、

言っていい気がする。

課題が何かを捉えれば別に、

解決する手段は自分で調べればいいっていうのと、

18:03

あとなんか、今喋りながら思い出したんだけど、

もう一つ個人的にいいかなと思う切り口としては、

ググり力が高い人は強いんじゃないですか。

それはあるね。

間違いなく。

それはあるわ。

情報収集能力が高い人は強い、

逆だな。情報収集能力が高い人が強いエンジニアなんじゃなくて、

強いエンジニアになるためにの、

かつ少ない必須アイテムの中に情報収集能力がある気がする。

そうだね。車輪の再発明が求められることもあるけども、

大体はどこかのすごい人が作った何かしらを使って、

課題解決を図るケースがほとんどなので。

あとは全く同じシチュエーションがなかったとしても、

自分の状況に活かせるパーツを集めてくるとか、

事例をインプットしてくるとか、

そういうのも大事だよね。

あとそういうところのライトパーソンを知ってるかどうかっていうのもあるよね。

そうだね。間違いない。

この人に聞けばとりあえず正しいみたいな。

そうだね。まさしく。

情報収集能力、本当めっちゃ最大公約数な気がするな。

そうだね。

不具合とか何かに困った時にも、

とりあえず直し方の探し方がわかるっていうか、

何を当たればいいかの勘どころがあるっていうのが多分あるよね。

確かにな。

その野生の勘みたいなのが上手く言語化できたら、

割と強いの言語化なのかもね。

何かあるよな、勘どころ。

何か、俺らにはあるじゃん、そういう再現性が。

こうやって当たればとりあえず、まあこの辺だろうみたいな。

うん、あるね。

どれ…

いやー、経験積みなさいで終わらせたくないんだよな。

経験積みなさいだとは思うんだけど。

でも経験積むとさ、この間自分で遭遇してすごい舞い上がってたことがあるんだけど、

コード見なくてもスタックトレース見るとだいたい原因がわかっちゃうっていう。

これどうせこれだろうと思って、ソースコードが読めない環境下にあるときに、

ちょっとスクショ貼ってもらっていいですか、スタックトレース貼ってもらっていいですかって言われて、

貼ってもらったときに、これ多分こうすれば直りますよっていうのをエスパーして、

どうせ外れんだろうっていう気持ちで行ってみたら、ありがとうございます、直りましたって返ってきて。

これはめちゃくちゃ気持ちいい。

気持ちいいこれ。

なるほどね。

なんかあれかもな、インプットがまず一番最初どう考えても大事で、

今めちゃくちゃ強い人も絶対最初はハローワールドから始まってるから、

インプットがひたすら大事で、

インプットしたものを何かの本で読んだんだけど、脳内できちんと整理していくみたいなのが大事な気はしていて、

21:05

ただただ毎日日取りに登録した技術ブログを読みまくればいいわけでは決してなくて、

たぶんひたすらインプットしていった点と点を自分でつなげる作業も必要だし、

それを仕事の中で活かす、仕事じゃなくてもいいです、趣味とかでもいいですけど、

実際に実践していく中でもその点と点をつなぎ直したり整理していく力とかは結構必要なのかもね。

だからそのダーティッシュの例とかも、俺も直近でそういう例はないんだけど、

社内でセキュリティチームに対してこういうエラーが出てますって問い合わせ来た時に、

自分の脳内の動きを今バッとフラッシュバック思い出したんだけど、

なんか自動であれじゃないですか、なんだろうな、

2分探索じゃないけど、一番切り分けのツリーみたいな、

なんかフローチャートあるよね、こういう事象が来た時、これはこれですか、はい、いいえ、みたいなやつがあって、

そうそう、候補がバーって出てきて、そこでバーって走ってって、これかこれが原因かな、みたいな当たりがつくというか。

脳内アキリエーターをやってる感じだよね。

近いかも。

で、それができるのは多分今までの経験とインプットで組み上げてきた脳内の知識のチャートというか。

そうだよね、あるよね。

その組み上げ方がちょっとさっきの十二角形みたいなところでいうと、

いやでもなんか本質は一緒な気がするけどな、そのノードの性質がなんか違うだけで、

僕みたいなタイプじゃない強いと呼ばれるエンジニアの人もなんかやってること同じな気するけどな。

まあそうだね、この業界のトラブルシュートの仕方はだいたい一緒な気がするね。

とりあえずログなりスタックトレースを見て、それっぽいエラーっぽいものを探してきて、

そこから思い当たるケースを頭の中で列挙して、角度の高いものから試していくっていう。

この手法、このやり方自体はだから、全ての仕事に通するところはあって、

多分ビジネス的なところでもそうなんでしょうね。

何かしらのエラーが出てきたときに、原因となっているところを探して、それに対応するための弾をたくさん用意して、

それを打つ打たないの判断をして、打てるものから打てるみたいな。

そうだね。

今話しながらちょっと思ったのは、時代によっても強さの定義は頻繁には変わらないけど緩く変わるかもっていう気がして、

今の話で自然と結構、自分が書いたコード、もしくは誰かが書いたコードを運用していく過程で遭遇する場面の話になってた気がしていて、

24:14

でも例えばだけど極端な話、分かんないです。

違ったら誰か提出してほしいんだけど、2,30年前とか3,40年前とかの世界だと、

作ったものを運用するみたいな概念とかプラクティスが多分今より薄かった気がしていて、

それは歴史が物語っている気はしてるんだけど、

なぜアジャイルが流星してきたのかみたいなところとかそういうところを推察するとそうな気がしてて、

だから3,40年前とかはもしかしたら強いエンジニアっていうのは動くものをすぐに作れる人だったのかもという気がしているが、

今の時代は作ったものを動かしていかなきゃいけないよねみたいな、

しかも同じメンバーでずっと動かせる前提っていうのは基本的にありえないから、

そこへの耐性も得るようなものを作って運用していかなきゃいけないよねみたいな、

運用能力も求められるっていうのは時代から見た時の強いエンジニアの定義としてはある気がしました。

大規模なシステムができる前ってコーディングって一人でやるもんだったって考えればさ、

あとそのPCのスペックも今ほどGIGAとかTeraとかそういう話じゃなくて、

メガバイトでやってた時期とかを考えるとメモリーマネジメントの方が重要だったりするかもしれないからね。

たしかにね。スタック的にもっていうのはあるかもね。

いやー、たしかにな。ゲームとかめっちゃわかりやすいだろうな。

わかりやすいよね。

ファミコン時代はもうコードゴルフじゃないですか。

何キロなのかな?たぶんキロぐらいは。キロあったのかな?まだまだ。

たぶんわけわからん容量にいかに面白いゲームを詰め込むかみたいな感じだけど、今だったらもう。

今もたぶんそれなりに制約はあるんだろうけど、アップデートでしていくことを考えると運用できる。

運用というか回収しやすいとか、コンフィグラブルなソフトを作らなきゃいけないとか。

そうだよね。今ハードもソフトも全部、ハードもソフトもって言うとあれだけど、

本体の方にもゲーム機本体の方もソフトウェアで制御されていて、

全部アップデートができるっていうところがやっぱり全然違うし。

全然違うよね。

何が言いたいかっていうと、当時のその手法が出てきた背景を理解しないまま手法だけ適用していくと大体やけどするよねっていうのは。

確かにね。それはそうかもね。

手段が目的になるのは、さっき言った情報収集能力と逆で、エンジニアとして強くなるのを阻む要素な気がするな。

27:03

そうだね。

綺麗なコードを書くのが目的とか、アジャイル開発が目的とか、そうなってきちゃうと。

そうなんだよな。

モダンなものばっか使いこなせることが別にスキルではないっていう。

そうね。本当に。

使えた方がいいんだよ、もちろん。

使えた方がいいんだけど、どういう思想、どういう技術、どういうテクニックでそれがなされているのかっていうのを、やっぱり背景から理解しようかないと。

詰まったときどうしようもなくなっちゃうからね。

そうね。先生がいないと何もできなくなっちゃうね。

1000?まあそうね。

おもろいな。メモしときたいな。

情報収集能力はリクワイヤードで、ノットリクワイヤードは手段目的、しかし手段目的お兄さん、お姉さん。

そんなあなたに朗報です。

なんと今の会話はすべて録音されております。

ありがとうございます。

文字起こします。

いつでも聞き返せます。

やったぜ。文字起こしてチャットGPDまとめてもらおう。

いやー、いい時代だ。

そうだね。でも本当、強いエンジニア突きつけめていくと、あるべきものと持ってはいけないものの明確な、今の2つは結構自分の中ではクリアだな。

情報収集能力に、あれか、情報収集して、それを脳内で組み上げる能力っていうのも必要か。

じゃあその能力どうやってつけるねっていう話になると、うーん、うーんって感じだね。

でも経験なのかな。

経験が物を言う領域は正直あるよね。

なんでそれができるんですかって言われたら、経験でしか語りようがねえよみたいなのはどうしてもあるじゃない。

さっき言ったスタックトレースを見てさ、バグの原因がわかるとかって、こうしたらわかるとかそういう話じゃないもんね。

そうね。なんか、自分の脳みそをちょっと拡張していくイメージは、いやー、あんまり立てじゃないかな。

でもね、その観点はね、あって、やっぱ自分と近いレベルの人と働くことだと思うね。

あー、なるほどね。

自分が本当は分身したらやれるんだけどなっていうのをちゃんと任せられる同僚がいるっていう。

確かにね。それはいいかも。

なんか点と点をつなぐっていう考え方で、なんか、頭の中に思い浮かんだのちょっと別の話になっちゃうかも。

話にならない気がするけど。

言語化してみましょう。

スマブラが好きで一時期死ぬほどやってたんですけど、一時期って言ってもだいぶ前。

スマブラに限らずだけど、ゲーム配信よく見ると、エアプゼという概念があって、

30:04

ゲームやったことないけど、ゲーム動画を見すぎてなんか自分ができるような気分になって、いろいろ支持しちゃって、ちょっとなんか叩かれるみたいな。

いるよね。

ゲーム配信見たことある人は100万回見た光景だと思うんですけど、

あれが情報収集しかしなかった末路感があるかもなって今一瞬思ってて。

そうかもね。

スマブラ始め、多分格闘ゲームは、情報収集からその実践までのギャップが多分、

ゲーム以外の領域で見たときの結構広いコンテンツだからすごいわかりやすいんだけど、

例えばスマブラだったら、他自分が使うキャラの技のフレーム数とかコンボとか、

このキャラに攻撃されたときにこれぐらいのフレームから動けるとか、

暗記、多分全部暗記しよう、暗記してないけど暗記しようと思えばできるし、なんかゲームのキワキワの仕様も全部知ってるんですよ。

で、こういうふうに動けば強いってのも頭の中ではわかってるんですよ。

わかってるんだけど、プレイすると全然その通りにうまくいかなくて、

それなんでかっていうと、なんていうかその、

頭に手が追いついてないっていうのがシンプルにあるし、

やっぱ無意識下でコントロールできるようになっていかなきゃいけない部分ができてないから、

全然頭でっかちになっていて、

エンジニアはなんかその距離がさすがに格闘ゲームほど距離があるとは思わないけど、

そういう側面はある気はするなぁとちょっと思った。

なんか知識だけつけていっても、なんだろうな、

やっぱ経験をしていくと、さっきの伊達氏みたいにパッとなんか、

自称と脳内のやつが紐づいてすぐにアウトプットが出るみたいな状態にできるけど、

その線が弱かったり繋がってなかったりするっていうのはある気はする。

なんかその例を聞いてパッと思い浮かんだのは、

テレビの前でサッカーの戦術家になってる。

そうそうね。

人たち。

いやでもあれはちょっと、話するからやめよう。

サッカーはね、ちょっと擁護できる部分はあって、

視聴者が見えてる景色とプレイヤーが見えてる景色が違いすぎるから、

そうだね。

なんか上から見たらここ怖じゃんみたいに言うのが、

プレイヤーから見た時に盤面見えてるわけじゃないから、

まあ難しいみたいな。

確かにそうやって楽しむもんだしね、あれはね。

そうね、そうだね。

ゆえにの。

ゆえにの、うん。

なんか、なんだろうね。

なんかリフティングのフォームとか知ってても、

別にリフティング100回できるわけじゃないとか、

なんかそういう話もあるし。

まあ要はやってみた難しさを実感してるかどうかですな。

うん、実感してたり、そうだね。

なんか、そういう意味でもさっき言った伊達氏の話は、

森林に近い気がしていて、

自分と同じレベルか、もしくは一歩先のレベルかという人といて、

33:02

まあ自分の、ほんとまんま一歩先だよね。

自分が脳内に入れたものを行動に落としていたり、

アウトプットできてる人を見て、

まあ見て学ぶもよし、聞いて学ぶもよしって感じだよね。

そうだね。

なんかやっぱこの業界もそういう側面は、

コーディングの域だと書きゃ分かるっていうか、

プレイグラウンドがあれば、

とりあえず小さく関数作って試すみたいなことはできると思うんですけど、

これがアーキテクチャーとかになってくると途端に評論家が増えるんですよ。

不思議なんだよね。

エアップってことですか。

そうそう、アーキテクチャーエアップ勢がいてですね。

別にディスってるわけじゃなくて、

勉強することはやっぱりすごくいいことだと思うんです。

いろんなアーキテクチャーのパターンを知った上で、

アプリケーションに最適な設計とは何ぞやっていうことを知っておくことはかなり重要なんだけど、

それを知っているレベルなのか、

手を動かして自分で組んだことがあるレベルなのかだと結構一定の差があると思っていて、

間違いない。

ハマりどころがやっぱりあるんですよね。

そういうところを身をもって学んでいて、

このパターンをやったときはこれにはまるっていうのがズバッといるみたいなところが結構やっぱあります。

確かにね。

そういうのをひと回しとか経験として詰めると、

次の2周目が全然違う状況だとしても、

ちょっとそれでこの話、

FM通して出てきた勘どころみたいなのがついてくるかもね。

そうだね。

学生をやってみながれみたいな感じで、

手を動かしてやれる環境があることがやっぱ成長にはいいんじゃないですか。

インプットの上でアウトプットを出せるのが大事です。

それを身につけるにはインプットはもう頑張れとしか正直言いようがなくて、

たださっき言った、

だてしが使ってくれたワードを忘れたけど、

ライトパーソンをアンカーとして何個か押さえておくみたいなところはやれるとおよって、

いい経験を詰める場所を選べるかどうかは大事だろうね。

自分、

いやー、そうね。

生存バイアスになっちゃうから、

あんま自分の話すんのよくないかもしれないけど。

いや、今日全部生存バイアスだから大丈夫だよ。

なるほどね、オッケー。

でもやっぱその、そうだね。

そういう意味では、わかんない。

悩める若者がいた場合は、若者は一社目は、

人依存で会社選んでもいいのかもなとか思っちゃったりしたな。

僕は人依存で選んだんですよ、一社目。

そうなんだ。そんな素敵な選び方をしたんですね。

そうなんですよ。

36:00

いい言い方をしたけど、一社しかないと語れなかったっていうのもあって、

でもその一社で就活辞めと思ったのは、

この面接をした人とか面談をした人が結構強い人で、

背中を追えば良さそうみたいに思ったっていうのがあって、

それは生存バイアスかもしれないが正解だった気がしてて、

さっき言ったいろんな話がまさにというか、

インプットしてめっちゃ頭デカちゃった自分を、

その人たちからのボコボコのコードレビューとか、

なるほどそうやるのねっていうのを見て、ある程度学んで、

あとは一回それができれば、それを繰り返していくだけだから、

いうのができたし、逆に言うと何が言いたいかっていうと、

Xとかインスタにはあんまりいないかもしれないけど、

インターネットを眺めてると、正直僕も今でも思いますけど、

Google内定しました?みたいな新卒の子とか、

名だたるビッグテックに内定した超優秀な若者っていうのが

全然いっぱいいるわけですけど、

彼らの進路を全く否定するわけではないが、

一生懸命そういうところに入る能力がなかったからといって、

強くなれないというわけでは全くなくて、

カンパニーネームは別にどうでもよくて、

その環境とついていける人、自分と同じか、

自分が追えるような人がいるかどうかは一つ、

もしかしたら見てもいいのかなと思ったりしました。

いい話。

就活に困っている人がいたら、DMください。

DMください。

いや、ちょっとダメだな。

就活に困っている人はどうしようもないというか、

手助けしてあげられないかもしれない。

いい会社知ってたらいいんだけどな。

ベンチャーをお勧めするのはちょっとダメだからな。

ベンチャーは別にいいか。

聞かれれば答えるよ。

ベンチャー1社目だった身からすると、

就活しときゃよかったなっていう気持ちはなくもないが、

でもベンチャー入ってなかったら今の自分はいないなっていうのもあって、

まあ好きにすればって感じですね。

だから俺らに聞くべきはどの会社を受けるかじゃなくて、

ライトパーソンを聞こうとかもね、もしかしたら。

その業界のね。

ライトパーソンに聞けばいいというか、

なんか俺らがいい会社を教えることはできないかもしれないが、

俺らがライトパーソンを教えて、

その人から、まあそうか。

就活のライトパーソンっているんかね。

いないかもしれない。話しながら思ったけど。

なんか視野を広げるっていう意味では、

そうね、

いや、就活というのは言うのはやめよう。

まあ今はインターンとかあるから、インターンとか行けばいいかもね。

インターンとか行って自分的にいいと思えば行けばいいんじゃないかって感じかもね。

どっちかっていうと。

今はインターンっていうのが充実してるからいいよね。

39:03

まだまだね、当分は売り手、

このFMを聞いてくれてる間は、

人がこのFMを聞いてる間は売り手市場が続く気がするし。

うん。

いやー、強いエンジニアね。

その子に教えてあげたいな。

ぜひ教えてあげてください。

いや、俺は分かんないよ。

俺も分かんない。

分かんないわ。

インターネットの海からこのFMを見つけてもらってって感じやな。

じゃあ、リスナーからお手紙が来た想定での質問なんですけど、

この先、きりにさんはどういうエンジニアになりたいと思いますか?

いやー、それ…

めっちゃ来そうじゃん、これなんか。

いやー、これなー、

これなんか別の回でも多分話したか、

だてしさんに話したんだっけか忘れたけど、

僕はもうそういうのなくて、

考えるのをやめました。

4年前に。

4年前に考えるのをやめました。

なぜかというと、4年前僕はメルカリって会社にいたんですけど、

大会再席時代に僕が憧れる

この人なんでこんな最強なんだろうってエンジニアの人たち、

3、4人ぐらいに、

どういうこと考えてキャリア積んだんですか?

みたいな質問をした時に、

もうみんなの答え全部一緒で、

何かっていうと、何も考えずに

人すら目の前にある

課題とかやるべきことを

がむしゃらにやったらここまで来ただけっていうことを言っていて、

そこで僕が悟ったのは

キャリア計画に

意味がないのかもしれないっていう。

計画立てて上手くいってるパターンの人もいると思うけど、

僕はなんか、

立てても意味ないなと思って思ったし、

新卒の頃に研修で

実は10年ぐらいのキャリアプラン立ててたやつがあったんで、

それをその後に掘り返してみたんだけど、

もう全然違う場所にいたんで、

まあ考えなくていいやと思って、

まあ明日って感じ。

その時その時で面白い場所で必死に

仕事してれば大丈夫っすよ。

どんなエンジニアになれたかは知らないっす。

なるようになるって感じです。

よかった。言いたいこと全部言ってくれた。

よかった。

そうなんだよ。

キャリア的にこうなろうなんて考えて

俺ら仕事してないんだよな。

キャリア、年功序列の考え方なのかもね。

なんかさ、わからない。

俺ら、超わかりやすいキャリア教科書を

社会人に受けが良さそうな

キャリアアップ教科書書けって言われたら、

そしてエンジニアでまずは

開発経験を積みましょうみたいな。

で、次はテックリードになりましょう。

エンジニアリングマネージャーになりましょう。

エンジニアリングマネージャーの上の部長になりましょう。

いずれはCTOになりましょうみたいなのを

段々で書くんだったら書くかもしれないけど、

別になんかパスがそれだけじゃないって話もあるし、

今言ったCTOとかEMってそもそも

42:00

頑張ればなれるわけじゃない

というのもあって、それはなんか

座席の数が限られてるから

なんか機械が転がってないとやれないし、

それ計画しても計画できなくねみたいなのを

普通に思う。

やっぱさエンジニアリングラウドとさ

その役職は違うんだよっていうところが

なってみないと時間がないんだろうな。

確かにな。それいい言語かだめ。

確かエンジニアリングラウドと

そうだね。違うね。

明確に違いますね。

だってそれと目指すべきはスタッフエンジニアってやつじゃないですか。

スタッフエンジニアって何ですか。

俺もよく知らないんだけどさ、

すごいエンジニアの人なんでしょ。スタッフエンジニアって。

そうなんだ。

スタッフってSTAFFじゃなくて?

STAFFですよ。

STAFFだったと思うけど。

なんかシニアエンジニアの上とかにいる

スタッフレベルみたいな。

なるほどね。

シリコンバレー業界とかのジョブディスクリプションに書いてあるような

ワードかなと想像したわ。

たぶんそう。

なるほどね。

いやースタッフエンジニア別に

目指したければ目指せばいいけど

だから

会社によって違うしな。

役職とかロールも結局役割が。

会社が役職を与える意味っていうのをちゃんとした方がいいと思っててさ、

誰に責任が

この業域の責任を誰が取るかっていうところのボールを渡してるだけなんだよね。

その責任を取るっていうのは

ジャパニーズ腹切り的な精神ではなくて

障害が起きたら腹切ってやめますとか

そういう話ではなくて

なんていうか

意思決定のボールをちゃんと持っているっていう

そういう話だと思うんですよね。

確かにね。

いい言語化するね。

ゆえに当然責任は伴うし

裁量ももちろんあるんだけど

裁量あった方がいいと思ったことは

裁量と権限かな

あった方がいいなと思うこともあるけど

同時に

誰かが何かをやらかしたときに

全部自分に飛んでくるっていうのは

そうね。

両方物派の剣なんで

なんていうか

一緒にやりたいポジションかって言われると微妙ですけど

あと会社によっては

同じロールでも

責任だけ渡される会社とかもあるわけですから

一口にね

そういうロール役職に就くことが

それを望むんで

その人が望んであれば別に全然

それは正解だと思うけどね

共通会として

どの会社にいてもこういうキャリアアップすれば

いいですよねっていうのは

ないよね

難しいよね

そこがどうしても社内の

制度設計に依存してしまうところが

やっぱりいまだに

うまくいってないなと思う

うまくいってる会社もあるのかもしれないけど

うまくいってないなと思っていて

45:00

いまだにやっぱり転職すると

年収が上がる

バグみたいな仕様があるじゃないですか

あるかもしれないです

Stars

Sota Sugiura

Stars

コメント

こちらもおすすめ