うーふ
@uufu_engineer
つよつよエンジニアを観察して言語化する人 / 現場で出会った優秀なエンジニアの思考と行動を実例ベースで発信 / 4年目 / Go・AWS・Terraform
626 フォロー中 1.6K ファン
強いエンジニアが入社してくると、最初の1ヶ月の動きがだいたい同じ。
最初の2,3日でまず、それまで社内の誰も気づいていなかったところを改善する。下手したら初日の時もある。
ついこの間も、たった1つトークンを入れ替えるだけで堅牢性を高めた人を目撃した。いきなりインフラコストを劇的に削減したエンジニアもいた。
ここはサービスの仕様とかあまり関係ない部分なので、純粋な技術力で進められる。
そうやって成果を出して社内から認知や信頼を勝ち取りつつ、その間にドメイン知識もじっくり蓄積していく。
みんな漏れなくこのパターン。
会社固有の知識はまだほとんどないのに、それまで培ってきた技術力だけで早々に成果を出してしまう。
やはりエンジニアにとって技術力って正義だなーといつも思う。
もっと見る
「拡張性を意識して」とシニアエンジニアから口酸っぱく言われてたけど、ようやく腹落ちした。
僕が長らく開発してた機能は、ビジネス上の都合や法令・コンプラ面の配慮で、仕様変更がかなり多い。
ただ、将来の仕様変更を想定し、変更されそうなロジックを特定の箇所に閉じるよう実装していたおかげで、想像以上に修正コストが軽く済んでいる。
結果的にリリース時期も早められ、大きなビジネスインパクトに繋がった。
もちろん、それを狙っていたので当たり前っちゃ当たり前。
だけど、転職やチーム移籍もあったので、自分が意図した設計の恩恵を、数ヶ月後の自分がダイレクトに体感することって意外となかった。
「やったー」という嬉しい気持ちもあるけど、それ以上に「なるほどー、こういうことなんだなぁ」というのが今の心境。
「拡張性が大事」なんて頭ではずっと分かってたけど、知ってるのと、身をもって体感してるのでは全然違うな。
耳にタコができるほど聞いてるプラクティスの中にも、まだ僕には「知ってるだけ」のものがたくさんありそうです。
もっと見る
リードエンジニアから、たまに「〇〇ってどうやればいいですか？」と一文だけ質問が飛んでくる。
本当にこれだけ。簡潔だからこちらも答えやすい。
単純に聞きたいことが明確で、的を射てるというのもある。
だけどそれとは別に、質問するときに「余計な気を遣ってない」のも、分かりやすさに繋がっていそう。
例えば僕なら、聞きたいこととは別に「お疲れ様です！」とか「〇〇でやってみたんですが、うまくいかないので確認した次第です！」とかいちいち書きたくなる。
申し訳なさや、「ちゃんと自分でも試したうえで聞いてます」ということを表したくて。
その結果、聞きたいこと本体は一文なのに、全体で5行くらいになっている。
でもこの方の質問を見ていると、少なくとも「ちゃんと自分でも考えてます」みたいな前置きは、なくても別に困らない。
文章が短いから重さもなく、気軽に反応しやすい。
質問の上手さ以前に、僕は質問するときに「質問してすみません」を伝えるための文章を書きすぎだなと思いました。
もっと見る
全社的にGitHubで情報を管理していく方向になり、非エンジニアにgitの操作を覚えてもらう場面があった。
あるエンジニアは、ステージングがどうとかマージがどうとか、gitの仕組みから丁寧に説明してたんだけど、どうも伝わっていなさそう。
そこで別のエンジニアが助け舟を出して、「こういうときは、このコマンドを叩けば大丈夫です」くらいまで説明を削ってた。
エンジニア的には、どうせなら裏側の仕組みまで理解してもらいたくなる。
でも、その場で必要だったのは仕組みの理解ではなく、まず必要な操作ができること。
少なくともそのときに根本から説明する必要はなかった。
全部を説明するんじゃなくて、どこまで説明する必要があるかを相手と場面に応じてチューニングできる。
この辺のバランス感覚も、エンジニアとして大事だなと思いました。
もっと見る
つよつよエンジニアとそうではないエンジニアの差は、緊急時の対応で分かるな。
先日サービスに障害が起きてしまい、僕とテックリードの2人で対応することになった。
僕が担当した分は正直、いつもの僕ならできたはずなんだけど、焦ってテンパってしまい、意外と手間取ってしまった。
「本当はもっとできたのに...」「緊急だったから...」と言いたくなるけど、それも含めて実力なんだと思う。
一方で、一緒に対応していたテックリードは真逆だなと。
緊急時や状況がヤバい時ほど冷静になって、判断も動きも速くなっていた。
まるで普段は温存しているかのように。
今回、僕の「普段の100」は、緊急時には60〜80くらいまで低下してしまうことがわかった。
エンジニアとして本当に強くなるなら、平常時の100を120にするだけじゃなく、緊急時でも100を出せるようになることも大事。
平常時の最大値ではなく、最悪の時に出せる最低値を実力と見なさなくては。
もっと見る
プルリクエストを出すと、たまに強いエンジニアから「このあたり違和感があるので他の書き方にできませんか？」とコメントをもらう。
「その違和感の中身を教えてよ、意図がわからない」って言いたくなる気持ちを抑えて、どういうことなのか考え、修正をしている。
今まで単にレビュワーが不親切なだけ、そういう指摘の仕方をする人なんだって割り切っていた。
あるいは自分で考えさせるためにあえてボヤッとした表現にしてるとか。
だけどそれとは別に、熟練してるからこそ、「上手く言えないけど何かおかしい」って嗅覚が発動してるのかもしれないな。
経験を積む中で「こういうコードは後で困る」「この書き方は何か危ない」みたいなパターンが蓄積されて、言語化できない違和感として出てくるのかなと。
こういう嗅覚も、熟練の一つなのかもしれない。
指摘された側の僕が、その違和感の正体を言語化するところまでやろう。
言葉になって初めて、個人の嗅覚がチームの知見になるし、今ならSKILLSやハーネスとして仕組みにも落とせるので。
もっと見る
社内のAI基盤を構築しているエンジニアたちを見ていると、今めちゃくちゃ面白い経験が溜まってそうだなと。
SlackやGitHubと連携させてClaude Codeから安全に参照できるようにしたり、権限管理、機密情報のマスキング、ガードレールなどを共通化したり。
試行錯誤しながら、AIを全社に仕組み化するための知見がどんどん溜まっていく。
一方で、それを使わせてもらうアプリケーション開発側は「そのAI基盤を使って、もっと生産性を上げよう」が中心になる。
だからやること自体はある意味で今までと同じ。
開発組織全体で見れば、その役割分担が合理的。というか、それがプラットフォームエンジニアリングなので。
ただエンジニア個人のキャリアで見ると少し気になる。
AI基盤そのものを設計・構築・運用する経験は、一部のチームにどんどん集中していく。
「AIを機能させる仕組みを作る側」と「用意された仕組みを使う側」で、数年後に積み上がっている経験の差がかなりつきそう。
事業を成立させる観点で「どっちが上」とかは本当にないと思っている。
だけど、個人的には基盤を作る側に回りたいな。
もっと見る
社内の実力者を見てて不思議なのが、ドメイン知識のキャッチアップが苦手なエンジニアが一人もいないこと。
技術的に強いのはわかる。
でも例えば、経理まわりの知識とかって完全にビジネス的なもので、技術力とは別物のはず。
本人は「こういうの苦手なんだよね」と言ってるんだけど、それでもほとんどの他エンジニアよりキャッチアップが速い。
これは何なんだろうか。
たぶん抽象化したり、過去に学んだことを別の領域に転用したりする能力が優れているんだと思う。
だから、技術もドメイン知識も複雑な仕様もすぐ吸収できる。
そう考えると「技術力が高い」というより、そもそも学ぶのが上手い人なのか。
もっと見る
周りの優秀なエンジニアに共通の要素として「内省を仕組み化してる」ことに気づいた。
日報なり週報なりを書くのはもちろん、Slackで催促用のボットを設定していたり、社内のAI基盤と連携させてGitHubやSlackの履歴からその週にやったことをリストアップさせたり。
当たり前のようで、毎日・毎週コンスタントに振り返りを続けるのってめちゃめちゃむずい。
僕もトライしてた時期があるけど、「なんとなく意味が感じられない」とか「今日は大して振り返ることないな」とかで、だんだんやらなくなった。
こうやって振り返り自体を仕組みにして、少しずつ軌道修正し続けてるなら、そりゃ強くなるなと。
もっと見る
「リファクタリングは先にやれ」と他チームの先輩エンジニアからアドバイスをもらった。
実際に仕事ぶりを見てみると、その先輩は機能開発に入る前に、必ずリファクタのPRをいくつか出している。
「後からリファクタリングの時間を取ろう」と思ったところで、そんな時間が確保されるはずがない。
だから、いったん残した負債を「あとで片付ける」のではなく、次にそのコードを触るタイミングで、機能開発の「前処理」として取り組んでいるとのこと。
「今から作る機能を安全に実装するための準備です」とでも言っておけば、ビジネス側からも比較的理解されやすいらしい。
リファクタリングを後処理にしない。次のタスクの前処理にする。
まあ言葉遊びみたいなもので、結局は後回しにしてるのと同じ。
だけど「次にこのコードを触るとき、機能開発の前にやる」とタイミングが決まっている分、少なくとも「いつかやる」よりは実施される可能性が高そう。
この考え方を実践してみます。
もっと見る
社内にはOSWEやOSCPに挑戦していたり、CTFに取り組んでいたりするエンジニアがいるんだけど、みんなめっちゃ優秀。
同じ年次でも明らかに差をつけられている。
その理由の一つは、セキュリティが独立して存在する領域ではないからだと考えた。
XSSを深ぼるとWebやブラウザの仕組みに行き着くし、SQLインジェクションならDB、権限奪取ならOSの知識が必要。
いわば総合格闘技に近い感覚がある。
だからセキュリティについて学ぶことは、エンジニアとしての基礎体力を底上げすることにもつながるんだと思う。
僕もそうなんですが、「エンジニアとしてもっと強くなりたい、でも何を学んだらいいんだ」って人は、セキュリティを勉強してみると良い気がしました。
もっと見る
社内のエンジニアのAIの使い方は人によってかなり違う。
Claude Codeに丸投げし、並列でぶん回して自分はレビューに徹する人もいる。
Cursorなどのタブ補完を軸に、あくまでも自分が手を動かす前提でAIを補助として使う人もいる。
同じエンジニアでも作る機能やタスクによって使い分けていそう。
ただ、AIに対して斜に構えた態度を取る人は、マジでいない。
セキュリティ面や理解負債といったネガティブな側面も認識してる。
だけど、それを理由にAIを遠ざけ、批評家に回ることはない。
「AIを使うのは当然」という前提のもと、「どうやればそれを乗り越えられるか？」という頭の使い方をしてる。
僕は学習のためにあえてAIを使わずにコードを書いてみたりと、AIから離れて自力で考える時間を作る方向で考えていた。
それはそれで続けていいはず。
ただ、それだけじゃなくて、「AIを使いながら、どう自分を成長させるか」にも、もっと頭を使う必要がありますね。
もっと見る
画面共有でいろんなエンジニアの手元を見るタイミングがあったんだけど、見事なまでにつよつよエンジニアほどタイピングが速かった。
最初はコードだったので「熟練してる分だけ速くて当然」と思った。
でも日本語を打つときも、やっぱり速い。圧倒的に差がついている。
というわけで僕の観測範囲では、エンジニアとしての実力とタイピング速度にはかなり相関がある。
AIでコードを書くのが当たり前になった以上、これから誕生するつよつよエンジニアに通用する物差しではない。
だけど、「今この時点で」強いエンジニアかどうかを測る指標としては、十分機能すると思いました。
もっと見る
「この人、やたら感じいいな」と思うエンジニアを見てると、やってることは意外と小さい。
・ミーティングの最後に「他に何かある人いますか？」と聞かれて「私は大丈夫です！」と反応する（普通は沈黙）
・質問や相談に対して即レスできない時に「すぐわかられないので〜に答えます！」と返す
・コードレビューで指摘する際、必ず冒頭に「実装ありがとうございます！」と一言添える
これらをやらなかったからと言って、減点されることはまずない。
だけどこの程度のことで「なんか感じの良い人」と思ってもらえるなら、やった方が得だなと。
技術力があるのは前提として。
「この程度」と言いつつ、できるエンジニアめっちゃ少ない気がするし、僕も無意識には絶対できてない。
AIで技術的な部分が底上げされていくほど、こういう「一緒に仕事しやすい」みたいな差は相対的に大きくなってしまうだろうな。
「感じの良いエンジニア」でいる努力も少しだけしていこう。
もっと見る
明るくてコミュ力も高い。でも、調べもせず無邪気に質問しまくるエンジニアがいて、地味にしんどい。
しかも好青年だから、下手に咎めるとこちらが悪者みたいな感覚になりかねない。
その点、自走力のあるエンジニアは質問内容が「まあそこで詰まるのはわかる」って範囲に収まっている。
いちいち言わなくても、ある程度は自分で試行錯誤してから聞いてきたんだな、というのが質問からなんとなく伝わってくる。
質問から「考えた痕跡」が滲み出るか。
これが、自走力の高いエンジニアとそうでないエンジニアを分ける差だなと思った。
ただし、考えた痕跡をわざとらしく残したところであざといだけ。
シンプルにちゃんと考える以外の道はない。
他人どうこうというよりも、自分自身がそう思われないよう気をつける。
もっと見る
最近になって、身の回りの実力あるエンジニアは3つに分類できることに気づいた。
1. 学生時代にコンピュータサイエンスをガッツリ学んだ
2. 小さい頃からコンピュータを触り倒している
3. エンジニアとは無縁だったけど、超高学歴
1,2はまあ分かるとして、最近発見したのが3のタイプ。
実際に何人か出会ったけど、みなさん元々はエンジニアとはほぼ無縁だったのに、わずか数年でシニアレベルまで到達している。
低レイヤーの挙動にも詳しいし、OSSにもコントリビュートを次々と決めている。
そのうえ、複雑なビジネスロジックや仕様のキャッチアップも異常に速い。
もちろん、学歴とエンジニアとしての実力がイコールだとは心の底から思わない。
高学歴じゃないけど強いエンジニアもたくさん知っている。
ただ、受験勉強をあれだけガッツリやれる人が、その勉強量をそのままエンジニアリングに向けたら、「そりゃ短期間で急成長するよな」とも思いました。
もっと見る
非エンジニアのPMが、AIを駆使してエンジニアばりのプルリクエストを出してくる。このリポジトリにはまだSKILLSやハーネスの整備が追いついていないのに。
無邪気に巨大なPRを出してくるとかも一切なく、適切な粒度で分割している。
AIに過去のPRを取得させて「小さく分割して出す」作法を把握したとのこと。
パフォーマンスについても考慮されており、N+1を避ける実装ができていた。
たぶん本人は「N+1」という概念自体はわかってない。
だけど、「何かしらここにはパフォーマンス上の問題があって、こう書くと避けられる」というところまではAIとの対話で辿り着いていたみたい。
地頭がよくて仕事ができる人なら、AIを駆使することで、かなり高い水準までこなせるようになったんだなと肌で感じる。
こういうシゴデキの非エンジニアになら、下手するとエンジニアも喰われかねない気がしてきた。
というか、もはや新種のエンジニアなのかもしれないな。呼称が分からないけど。
もっと見る
「switch文は絶対使うべきじゃない」と主張するエンジニアに勉強会で出会った。
スパゲッティコードを生みやすいからというのが理由。
とはいえ実際には普通に使われているし、一般的には「switchは絶対悪」とまでは認識されていない。
だからこの方の意見は非常に過激だと僕は感じた。
この持論の技術的な是非については踏み込まない。
それよりも「なぜその持論に至ったんだろうか」という背景に興味が湧く。
ここまで強いこだわりを持つまでには、過去にswitch文に苦しめられた経験が何かしらあるんだと思う。
極端な持論を持てるようになる頃には、それだけ自分なりの経験則が積み上がっているということなのかもしれないな。
もっと見る
会議や割り込みだらけでも普通に仕事を終わらせるエンジニアがいる。
何かコツがあるのか聞いたところ、返答が面白かった。
どうやら、Goの読み書きにほとんど頭を使わないことが大きいらしい。
その方は「Go言語を極めた」と自称している。
実際、画面共有でなにげなく見えたときのGoを書くスピードがレベチ。
日本語を書いているのかと思えるくらい、スラスラと淀みなく手を動かしている。
ここまで手に馴染んでるなら、Goを読むときの負荷もたしかに低そう。
ご本人いわく、
「たいていのエンジニアはコードを読む時、多少なりとも集中力を使う。でも俺はGoであればマンガを読むくらいの感覚で読める。だから簡単に頭を切り替えられる」
とのこと。
例えはだいぶ極端だけど、言っていることは分からなくもない。
すでにできることを「無意識にできる」レベルまで突き詰める。
そうやって、普段の作業に使う思考のリソースを減らす。
知識を広げるだけじゃなくて、「考えなくてもできることを増やす」のも、エンジニアとして1つの成長なんだなと思いました。
もっと見る
「めっちゃ技術力高いけど話しかけにくいエンジニア」より、「技術力はそこまでだけど話しかけやすいエンジニア」がいてくれる方が助かる。
僕が浮かぶ疑問なんて、神レベルのエンジニアに聞かなくても解消できる範疇だから。
なので日々の業務では話しやすいエンジニアにガンガン頼っていく。
だけどたまには、その話しかけにくさを乗り越えて圧倒的な技術力に殴られるのも、それはそれで良い刺激になる。
このバランスが、ほとんどの若手エンジニアには合ってる気がするな。
もっと見る
