うーふ
@uufu_engineer
つよつよエンジニアを観察して言語化する人 / 現場で出会った優秀なエンジニアの思考と行動を実例ベースで発信 / 4年目 / Go・AWS・Terraform
858 フォロー中 2.1K ファン
AI前提で開発しているのに、エンジニアによって担当範囲で発生する不具合の数に明らかな差があるな。コードを書く部分をAIに任せているんだから、以前ほど人による差は生じないはずと思っていたんだけど。
不具合の内容を見てみると、「ここもやっておいて」とか「このパターンも考慮しておいて」と明示的には言われていない箇所。なので、担当した人の問題とも一概には言えない。
ただ、そもそも何を実現したいのかを理解していれば、「このケースはどうするんだろう？」とか「こっちの動線は対応しなくて良いのかな」と疑問を持てたんじゃないかと感じるものもある。全部は無理でも。
勝手に実装しちゃって「余計な気を利かせなくていいから言われたことだけやってよ」のパターンもあるけれど、「これも必要じゃないですか？」と事前に確認することはできる。
なんか昨日のポストに似てしまっているけれど、他者に対してどうこうではなく自戒を込めて。僕も同じような見落としをしてしまう時があるので他人事じゃない。
もっと見る
3年以上お願いしていた業務委託のフロントエンドエンジニアとの契約を更新しないと決まった。仕事ができない人ではなく、フロントの実装をお願いすれば速いし、アラートや問い合わせ対応もかなり積極的にやってくれていた。
なんだけど長年一緒にやっている割に、ドメイン知識が全然身に付いていない。
「〇〇の部分をお願いできますか？」と依頼するといまだに「〇〇ってなんでしょうか？」と返ってくることもある。
これまではそれを差し引いても十分助かっていたけど、AIによっていよいよ「それじゃあ厳しいな」という話になった。
実は直近の3ヶ月は契約を継続するかの見極めも兼ねて、タスクの抽象度を上げ、ドメイン知識の絡む部分から考えてもらうようにした。
だけど結局、「何からやったらいいでしょうか？」と聞かれることが多くて、うまくいかず。頑張ろうとしてくれていたのは伝わってきたけど。
与えられたタスクをこなす働き方から、自分で課題を整理する働き方に変えるのは、分かっていても簡単じゃないんだろうな。
もっと見る
AIによる開発効率化を提案する場面があったんだけど、現状を聞けば聞くほど「AI以前の提案」ばかりになってしまう。テストコードやCI/CDの整備、権限の設定など。
AIに大胆に仕事を任せるためにも、決定的に制御できる部分はAIではなく仕組みとして固めておきたい。
でも、AIどころかIT全然わかってないですみたいな人たちからすると、そこら辺も丸っとAIにお任せできるイメージを持っているようで、提案が期待値を下回ってしまう申し訳ない感じになってしまった。
エンジニアの自分からすると、AIによって開発の進め方がガラッと変わって、まさに革命が起きている感覚がある。
だけど、AIをガチの魔法だと思っている人にとっては、まだまだなんだなと。
もっと見る
あるエンジニア2人が、「他チームとの調整が面倒だから自分たちの側でなんとかしちゃうか」と話していた。本来は他チームが担当するマイクロサービス側で返す値を修正してもらうのが筋なんだけど、そのためにはやりとりが発生する。
で、その流れで「AIには気を遣わなくて済む分、他のエンジニアとのやり取りが余計にめんどくさく感じるよね」と言っていた。
この2人の会話は冗談半分で、実際には担当チームと調整して修正をしていた。
ただ、たしかに人間同士のコミュニケーションが相対的に面倒になっている感覚はある。今までなら普通にやっていたのに。相手のエンジニアが感じ悪いとかじゃなくて、AI相手なら気遣いゼロで済んでしまうから。
「人間同士のやり取りを避けたい」という動機が、無意識のうちに技術的な判断にまで入り込まないよう、今まで以上に注意する。
もっと見る
問い合わせ対応がめちゃくちゃ速い同僚のエンジニアが、なぜかSlackのスタンプだけはつけてくれない。チーム宛のメンションが来るとすぐに調査してくれているっぽいけど、他のエンジニアからそれが見えない。
だから他の人と対応が被ってしまい、結局二人で調査してたみたいなことがよくある。
「スタンプくらいつけようよ」って話をしてるんだけど、スタンプをつけるとその後は自分に直接メンションが来て、最後まで面倒を見なきゃいけなくなるから迂闊に反応したくないらしい。
チームとしてはめちゃめちゃ良くないんだけど、自分から勝手に調べている時は楽しいのに、担当になるのは躊躇してしまう感覚は、正直ちょっと共感してしまった。
もっと見る
もはや変数の命名とかあんまり気にしなくなってしまったな。
今まではテックリードからも「この命名は抽象的すぎるので他を考えてもらえませんか？」とか「既存と命名をそろえてください」とかレビューコメントをもらうことがあったけど、最近はほとんどない。
それよりも「〇〇のパターンがあり得るので、どういう仕様にするかPdMと調整してください」みたいな、コードベースから判断できない指摘が中心になっている。
コードを読む時もAIの説明ありきで読むので、多少わかりにくい命名があっても、以前ほど気にならない。もちろん全くとは言わないけど。
というか週に1回、月曜日の朝にリファクタリングのPRをAIに作らせているから、命名の不統一感とか粒度のズレとかはそもそもそんなに長期化しない。
「命名が重要じゃなくなった」とかではなく、後からすぐ直せるから、「その場で超こだわらなくても良くなった」という感じ。
もっと見る
あるエンジニアが先週、「自分ではAI臭を消しきれてない気ががするのでレビューもらえませんか」と言っていた。テックブログの下書きに対して。
その方の書いたテーマ自体はかなり独自性があるんだけど文章が綺麗すぎる。内容は面白いのに、どうしても「AIに書かせた感」があってノイズになってしまっている。
厄介なのは、「AIの臭い」が消せているか自分では判断しきれない点。だからレビューを依頼していた。
かといって、それを恐れて細部まで手直ししようととすると結局、「最初から自分で書けばよかったじゃん」となるし。
「AIが書いたように見えない文章を書く」という新たな難題が生まれているな。テックブログなど公式の外部発信だと特に。
もっと見る
TypeScriptもIaCもどう考えても必要だとしか思えない。
でも1年後には「どっちも不要」という論調になっていてもおかしくないのが、怖いところ。それくらいAIの進化が速いと感じる。
今この瞬間としての意見はしっかり持ちつつ、いつでも前言撤回する準備はしておきたい。
もっと見る
SESから自社開発へ転職してきたエンジニアが、「意思決定がしんどい」と嘆いている。
この人は、意思決定に必要な情報を整理してPdMやテックリードに提示するのがすごく上手い。しかも、ちゃんと自分の意見まで添えている。
それでも、自分に判断を任されてしまうと途端に怖くなるらしい。
前職では複数の現場を転々としていたそうで、適応能力には自信がある模様。実際、仕事も速いし、報連相などチームに溶け込むのもすごく上手い。良い意味で「傭兵」みたいな感じ。
だけど在籍期間が長くなるにつれ自分自身での意思決定を求められる場面が増えてきた。
これまでは最終的な判断は現場の人に仰ぐ働き方をしていたので、「自分で決めていい」という感覚が分からないとのこと。
自分の意見まで出せているんだから、それをそのまま採用すればいいように思えるけど、「自分はこう思う」と「だからこうする」の間の溝を感じた。
もっと見る
社内のあるエンジニアがPythonで書かれたコードベースをGoに丸ごと移植した。Pythonでめちゃめちゃ困ってたわけじゃないのに。
元々Pythonを採用したのは、初期の頃にLLMのAPIを扱うのに相性が良さそうだったから。機械学習系のライブラリに依存しているわけでもない。
一方で、社内の大半のリポジトリはGoで書かれている。慣れている人が圧倒的に多いからGoに揃えた方がメンテしやすそう、という程度の理由。
別にPythonのままAIでメンテしていく手もあるんだけど、「AI使えば簡単にリプレイスできるからやっちゃおう」という割と軽いノリで実施。
コード量はまあまああったのに、一人で数日でサクッと終わらせて、今のところ問題も出ていない。
今までだったら「Goに揃えた方が多少メンテしやすい」程度では、全面移植なんてなかなか踏み切れなかったと思う。
AIによって、「やった方がいいけど、そこまでしてやるほどではない」と見送っていたことが、どんどん実行の選択肢に入ってくるのを肌で感じた。
もっと見る
他社のエンジニアと話していたら、自社では積極的に使っているセキュリティサービスを、相手の会社では「新たなアタックサーフェスになりうる」という理由であえて避けていると聞いた。
話を聞くとそれはそれで「なるほど、そういう視点もあるか」と思うし、かといって自社の判断が間違っているとも思えない。
「AIにひたすら聞いて勉強していけばいいじゃん」と思っている派だったんだけど、このような会話を経て少し考えが変わった。
AIは壁打ち相手として優秀な反面、同じメンタルモデルの中で考え続けてしまい、視点が凝り固まる感覚がある。起点が自分のプロンプトなので。
社内の他のエンジニアと話すにしても、ある程度は自社の思想を前提としているし。
その点、他社のエンジニアとの会話だと自分が「ほしいとすら思っていなかった」視点が突然飛び込んでくる。
AIで思考を深掘れる今だからこそ、自分が無意識に置いている前提に気づくためにも、普段と異なるコミュニティに参加して、他社のエンジニアと話す機会を増やしていきたい。
もっと見る
ある新卒のエンジニアが目標シートに「人としてちゃんとする」というのを掲げていた。入社した時に自分で考えたらしい。
今までなら社会人としての欠陥があっても、エンジニアとしての尖った専門性があれば、差し引きでなんとかお釣りが来るので目を瞑ってもらえた。
だけどこれからはその尖った専門性で勝負しにくくなるので、高得点を狙いにくくなる。なのでその分、余計な減点を避ける必要がある。技術面でも得意分野を作るよりも、苦手を潰す動きをしていきたいとのこと。
雑談の中でこれを本人がこのまま口にしていて驚いた。新卒でこんなこと考えている時点で立派だなと。逆に綺麗にまとまりすぎだと感じてしまうくらい。
もっと見る
1on1で先輩エンジニアに「何がクリティカルかは立場によるよね」という話をもらった。最近はAI前提の開発環境が整備され、エンジニアが隅々までコードを読むことはなくなってきている。
「金融や医療でもない限り、これでいいでしょ」って意見も増えてきたし、僕もそう思っている。
でもよくよく考えたら、社会的なインパクトがそこまでじゃないとしても、そのサービスを提供してる個人や会社にとっては話が違う。
たとえばto Bであれば、一度の失敗で大口顧客の信頼を失うかもしれないので、提供する会社にとっては事業の存続に関わるクリティカルな問題。
そう考えると、どうしても「AI任せにせず細部まで自分でしっかり理解しておきたい」って気持ちになるのも分かる。
当事者じゃないから見えていない切実さがきっとあるので、言葉の使い方に要注意。
もっと見る
Claude Codeの持続可能な並列数について同僚のエンジニア5人と雑談した。
ここでいう「持続可能」は、それを一日続けても人間側が消耗し切らない並列数のこと。
多かったのは「メイン1つとサブ2つ」という配分。
重いタスクを1つやりつつ、その推論の待ち時間にサクッと片づきそうなタスクを2つくらい動かす。サブを完遂したらまた新しいサブを足す感じで。
「メイン1つとサブ1つ」にとどめて突発的な差し込みや問い合わせ、アラート対応などの余白を設けてるって人もいた。
隣席のエンジニアは日によって変えているらしく、「今日はサブだけを4並列でぶん回す」と意気込んでいる。
こんな会話をしている時点で、AIを使うのはすでに前提で、「どう無理なく使い続けるか」を探る段階に来ているんだなと、ふと思った。
もっと見る
AIを使って開発や調査をすることで、「仕様が記憶に定着しない」点に危機感があった。自力で試行錯誤してないから、記憶に残らない。
だけど開発スピードが上がってる分、同じ仕様に触れる機会が増えるので、さすがに刷り込まれるな。細かい仕様もだんだん頭にインプットされてきた。
一回の精読よりたくさんの流し読みという感覚。結局、量でなんとかなる。
もっと見る
技術書を写経するコスパの良さを感じている。『GitHub CI/CD実践ガイド』という書籍を3周したんだけど、CI/CDを完全に極めた。
そんな勘違いをしたくなるくらい、「理解できてる感」「操れてる感」が爆発的に高まっているので自分でもびっくり。
今までAIでワークフローファイルを読み書きする時は、説明とコードを照らし合わせて、どこがどう対応してるかを理解するのに時間がかかっていた。
だけど今は出力を見て「あーはいはい、そういうことね」とスッと頭に入ってくる。3周もしたのでさすがに見覚えのある記述ばかり。
理解すること自体にエネルギーを割かなくて済む分、出力に対して疑問や違和感を持つだけの余裕が生まれた。
普段はAIにコードを書かせるとしても、自分で手を動かして慣れておくことには大きな意味があるな。
基礎的な理解に使う思考体力を温存できるので、その分もっと高度なことを考えられる。
もっと見る
同僚のエンジニアと喋っていると「Cursorのタブ補完くらいの時が一番幸福度が高かった」という話になる。今も今で楽しいしできることも増えているんだけど、もはや別競技という声が多数。
たしかにあの頃はあくまでも主導権は自分にあって、従来の楽しさを残しつつ、面倒な部分だけAIが高精度で補助してくれた。開発が速くなると言っても、自分の頭がついていけるくらいのスピード感だったし。
これを思い出し、試しに昨日はCursorのタブ補完で昔のように開発しようとしてみたんだけど、もう全くうまくいかない。
やろうと思えばできるんだろうけど、遅いし普段と作業の粒度が違いすぎて、めちゃめちゃ面倒にしか感じなかった。
一度技術の進歩を経験すると、もう以前の状態には戻れないのを、肌で感じている。
もっと見る
面接官を務めるエンジニアが、「最近は候補者が均質化しててつまらない」と言っている。公開されているインタビュー記事やテックブログを参考にAIがまとめたような、そつのない回答が多いとのこと。
だけどもう1つ深く突っ込むと、答えに詰まることも多いため、「AIの出力の丸暗記になっているだけなのでは？」と邪推したくなるらしい。たとえそうじゃなかったとしても。
なので最近は、答えのある質問だけでなく、「何が好きか？」を問う質問も混ぜるようにしている模様。
その人が思わず熱を入れて話してしまう瞬間や人間味を見るのが目的で、評価基準とかは特にない。
そういえば僕も今の会社の面接で似たような質問をされ、あるライブラリの使い方や細かい設定について、やたら早口で喋りすぎてしまった。
入社後に「あのライブラリの話をしてたのがやたら印象に残っている」と言われたのを今でも覚えている。
もっと見る
SIerからWeb系へ転職してきたエンジニアがいる。技術をよくわかってない人が書いた仕様書に基づいて他の誰かが実装したり、逆によく分かってないのに仕様書を書く側になるのも嫌で転職してきたとのこと。
なんだけどWeb系に来た今、結果的に似たような状態になっている。
自分が仕様を文章にまとめ、AIにコードを書かせる。その結果を見て良し悪しを判断する。
SIer時代に嫌だと思っていた分業制と構造が同じ。実装者が人からAIに変わっただけ。
本人もそれに気づいていて、だからこそ技術の勉強へのモチベーションがめっちゃ上がってるらしい。
自分が技術を理解しなくなったら、今度は自分が、あのとき一番嫌だった「技術をよくわかってないのに仕様を書く人」になってしまうから。
もっと見る
2ヶ月前にテックリードが辞めてしまったチームがある。その人の実力が抜きん出ており、残されたエンジニアは歴5年未満ばかり。
彼らだけでやっていけるか心配されていたけど、想像以上に上手く回ってそう。
これまではテックリードが他のメンバーと一対一で相談、レビューする感じだった。
だけど新しいリーダーは「これは自分には無理」と判断し、やり方を変えているらしい。
開発に着手する前にDesign Docを書いてみんなでレビュー会を開いたり。プルリクのレビューも相互にやりあったり。
特に変化を感じるのが他チームからの問い合わせ。以前はテックリードがすべて返してたけど、今は程よくバラバラに答えるようになっている。
突出した人がいたのでどうしても頼ってしまっていたが、「この人なしじゃ回らない」はなんとかなるんだなと再実感。
もっと見る
