X見てると、今日ソフトウェアエンジニアが近い将来オワコンになるか否かが明確にわかると思うな。自分的にはならんと思うけど、なったらそれは素晴らしい事で凄いイノベーションだよな。そうなったらブルースマンでもやるかw — 牛尾剛『世界一流エンジニアの思考法』(文藝春秋)🎸Tsuyoshi Ushio (@sandayuu) August 7, 2025 本心で言ったのだが、予想通りそうはならなかった。今回の AI ブームが過去と圧倒的に違う部分は、わけわかっていない人が言っているのではなく、ガチのエンジニアでも、「あー、わしもうリプレースされて、エンジニアいらんようになるかもしれん」と本気で思ったところだと思う。まぁ、実際そうかもしれないが、問題はどれぐらいでそうなるか？がまだ全然わからないということである。 「オワコン」と思われているかもしれないが、もしかすると今ソフトウェアエンジニアをやっ

最近は、自分はかなり Vibe Coding にお世話になっている。実際にプロダクションのコードでも使っていて自分的には普通のことと思っていたのだが、ある人にどうやってやってるのか聞いてみたいと言われたのでせっかくだからブログに書いておくことにした。みんなとっては普通のことかもしれないので、整理のためにも書いておこう。 Vibe Coding の光と影Vibe Coding を使うと、GitHub Copilot Agent などを使うと、自然言語で指示をすればプログラムを書いてくれる。これがあると、素人でもコーディングができそうだ。プロトタイピングや、ゼロから何かを作るときはなかなか良い感じだが、プロダクションで何も考えずに使えるというわけにもいかない。実はコードが複雑になればなるほど、そのままではうまくいかない。 今読んでいる AI Engineering より引用した次のグラフが興味

多分普通の人にとっては当たり前かも。でも自分にとっては、エンジニア人生最高のブレイクスルーなので、自分のメモのためにもブログを書いておきたい。 エンジニア人生の長年の苦しみ　専門のデベロッパーになってもう４年ぐらい経っている。アメリカに来てから５年だ。しかし、自分がエンジニアとして一人前になれたという感覚はついぞ持てていない。最高に優秀なメンターとストラテジーのお陰で何とか首にはなっていないが、自分がちゃんとしたデベロッパーになれた感覚は全然なかった。理由は、自分はどう考えても開発スピードが遅い。いやくっそ遅いと言っていいだろう。 もうダメだ。これダメならエンジニア辞めて日本に帰ろう　そんな時に決定的な事件が起きた。自分が新しい役割に移って早数か月、自分のアウトカムは０なのだ。いや、０に戻ったと言えよう。今はいろんなものが、移り変わっていて難しい時期ではあるが、たまたま趣味で書いていたAI

自分はADHDですので、もちろん集中力は暗黒です。週末とかでも、あれしたい、これせなとかおもってだらだらしているうちに夕方になったりします。とにかくスイッチが入るのが遅いです。それに、１日終わったら脳が相当つかれている感もありました。この問題が解決したので、シェアしたいと思います。 きっかけはこちらの動画でした。マジありがとうございます。 暗黒の以前の習慣 以前の私はこんな感じで１日を過ごしていました。まず朝起きたら、ベッドの中でゴロゴロと、SNSを観たり、仕事の自分の通知を観たり、携帯で漫画を読んだりします。やる気が出ない時は、時間が過ぎて本来ランニングに行きたいところでも、今日はいいやとか明日からにしようと思ったりします。 朝食は、オートミールと卵ですが、それを調理しながらYoutubeの動画を観たりします。そして、いろいろ詰め物をして、仕事に出かけます。職場についたらコーヒーを入れて

多分今回のポストは多くの人には参考にならないだろう。相当ニッチなので。でもこれは自分にとってはとても大きなことだったので、忘れないように記録しておきます。 生産性の悩み　あまりこの世界では生産性とはあいまいな言葉で、何をもって生産性が高いとは言いにくい。速いのが良いのではない。ただ、自分の実感として自分は生産性が良くないといつも感じていた。だからいろいろ努力したり、考え方をできる人を観察して真似してみたり、直接本人に聞いたりして工夫をしてきた。 実は自分はめっちゃコーディングが早い人になりたいわけではない。そうではなくて、「平均的」になりたいだけだ。それぐらいいければ「Strategy」でカバーできるどころかもっと上に行けると確信があったから。でもそうではなくて明らかに遅いのでそれが自分の足を引っ張っていた 努力の方向性　様々な努力をして、特に有効だったことを自分の本に書いたつもりではある

今日はちょっと驚いたことがあったので、自分の記録のためにも書き残しておきたい。 ライブサイトの問題　自分のやっているプロジェクトで問題が起こって、その障害の復旧と調査にあたっていた。問題は大きいが、DividedByZero が起こっている。これはスポットしやすい。 自分の見慣れたコードパスをログを頼りに DividedByZero が起こりうるところを特定する。 実際にそれが起こるところは２点と特定する。 フロントエンドが０台になる アプリケーションの必須の設定が０になっている どちらも通常あり得ないが、どう考えても前者である可能性は低い。もし前者だとしたら、問題はここだけに収まらない。最近変更を他のチームが加えた後者が最も有力だろう。何せ今までそれは起こったことが無いから。調査に協力してくれた Cooper も同意見だった。 問題の特定に時間を使う　残念ながらログが出てないので、調査が

私はADHDで短期記憶が最悪で、とても気が散りやすい。些細なことかもしれないが、本人にしてはなにやってもめっちゃくちゃ効率わるいし、やる気になるまで相当時間がかかる。よくあるのは休日に「これやらなきゃ」とか思ってスイッチがはいるのが夕食の前ぐらいで、夕食が始まるからそれも終了…ということもしょっちゅうある。 ADHDの特性の出方はかなり個人差があり、環境によってなにが「困りごと」になるかも様々だから他の人がどんな感じかわからないけど、集中力がクソほどなくて、効率が悪い自分にとって、働きやさ・生きやすさにつながった対処法を紹介したい。 自分が手を動かす前にメモを書く　自分にとってはとても有効な方法で、特に仕事するときとかそうだけど、今から自分が何をするのかの箇条書きを初めて、そこに書かれた通りに作業をする。だから自分は会社に着いたらその日にやることを書きだす癖をつけている。いきなり作業をやり

大変多く読んでいただいた「プログラミングというより物事が出来る思考法」というポストや、世界一流エンジニアの思考法の書籍で紹介した内容がある。 私の職場でも、ものすごく出来る人が「実践」しているところを何回も目撃しているので「実践編」として皆さんにシェアしようと思って今回のポストを書いてみた。 タイトルにもある通り、私はエンジニアだが、ビジネス書である書籍と書かれた多くの思考法と同じく、あまりエンジニアリングというものに関係ない要素であると感じている。 上記のポストや書籍でシェアした内容を端的に言うと「理解には時間がかかるがかける価値が十分あり、それによって自分が物事をコントロールしている感覚を身につけることが出来る」という自分の小さな発見だ。私がこのことを最初に発見したのは、新卒の出来る人々との出来事がきっかけだが、今回その小さな自分なりの発見を後押しするような出来事がいくつかあった。それ

私はアメリカでクラウドの中の人をやっている開発者だ。最近アメリカの方でも当初の予定がとても延びたプロジェクトを経験した。このような時に、日本では多分ものすごい炎上プロジェクトになると思うのだが、アメリカで体験したそれは全然違う感じだった。 これは一言でいうと「納期感の違い」がもたらしている感覚だった。 炎上感のなさ　私が感じた「予定がとても延びた」プロジェクトの場合、日本にいたときのプロジェクトでは、受託開発、内製双方ともに物凄く「大問題」になっていた。上位のマネジメントも連日のように進捗の会議を行い、人が追加投入され、エンジニアは時には泊りで一日も早く後れを取り戻すために皆遅くまで、そして土日も働き、お客様はもう怒り心頭…　だったと思うのだが、こちらで体験したプロジェクトは拍子抜けするぐらい炎上感が無かった。 当初予定していた日程が一か月以上伸びても、みんな慌てる様子もなく、私はわからな

私は長年 Pull Request のコメント数が多くて何回もレビューを往復することが多くて大変つらかったが最近ものすごく単純なコツに最近きづいたのでそのことをシェアしようと思う。 Pull Requestレビューの悩みこれはならない人はならないので、共感してもらえる人は少ないかもしれないが自分の悩みは Pull Requestのコメント数でこれが本当に多い。何がつらいって、レビューのコメントが多いという事は、マージに時間が掛かるということだ。最初にコードを書いてテストして完成させるのは２時間もかかってないのに大抵レビューで何往復もして時間を取られるのが本当につらいし、進捗がでないもの嫌だし、時間かかるし、自分が最近解決したい問題の中でも筆頭の問題だった。 何が悪いのだろう？すごく嫌なので物凄く考えたがうまくいかなかった。例えば、英語のスペルミスも良くしたし、ログやコメントの英文にレビュー

アメリカの職場にいると、日本にいるときよりも身近でレイオフだとか、職を変えるというのを頻繁に見かける。先日もそういう場面があったのだが昔日本で働いていた時のことを思い出した。 ドキュメントを書く理由　日本のソフトウェア企業にいたときは、「納品物であるから」という理由以外にも、「人がいなくなったときに会社が困るから」という理由でもドキュメントを書くことが推奨されていた。しかし、少なくとも今の職場ではそんな理由でドキュメントを書くのは推奨されていないのに、なぜ問題にならないのだろうとふと思った。 うちのマネージャは、バディ制ににして、みんな休暇できるようにしようとは言っているが、多分本当に退職対策ではないと思う。 チームのメンバーが抜けたときも、「とても残念で、ワークロードをどうしようという問題はあるけど、彼女の門出を祝福しよう」言っていた。つまり、こちらでも「工数」は問題になるけど、「引継ぎ

私が人生でずっと悩んで追い求めていたものがついに解決した。それは、なんでも良いから何かが「出来るようになる」ことだ。 昔からいくらその対象に時間をかけても、努力しても、人並みにすらならない。人にやってもらうとか自分がやらないことに関してはうまくいくのだが、自分が何かが出来るようになるということに関しては人生５０年目だが、絶望的で、それが自分の自己肯定感や、人並みに生きることへの罪悪感を生んでいた。人生で解決したかった問題 No.1 だ。だからそれをずっと解決しようと頑張ってきた。 ギター演奏での解決方法私はクソ不器用で、なにやってもできないので、人生で出来たらいいことを２つだけ定めた。ギター演奏と、プログラミング。ギター演奏に関しては少し前に解決した。根本的な問題を一つ上げるとすると、「ゆっくりから、メトロノームで練習する」これだけだ。 ギターはもう何十年も演奏しているのに弾ける感がなかっ

私はクラウドのプロダクトチームで働いているが、何を隠そう一番苦手で克服できていないことが、コードリーディングだ。ものすごーく時間かかるし、時間かかったうえに読み間違えたりするし、しかもめっちゃ頭使うのに他の人はずっと速いので敗北感しか残らない。先日もマネージャの Pragna に相談したら、最初は２時間かかるけど、３か月もしたら５分で終わるわよ。って言われたけど、いや、そもそも俺４時間は最低かかるねんけどな、、、って感じ。 技術イケメンの皆さんのアドバイス　よくよく私のキャリアを考えると、OSSにコントリビュートとかしていることはあったが、めっちゃくちゃ巨大でややこしいコードベースを読んで理解する必要が無いことが多かった。１からコードを書くのは得意だが、他の人のを読んでがっつり理解してとか、どうやったら出来るのかわからない。 当然自分の周りの技術イケメンの皆さんにコツを聞いていたのだが、ど

私はシアトルのクラウドの中の人として、ソフトウェアの開発を行っているが、先日ある問題がきっかけで、技術者には試行錯誤がとても良くないということが腹落ちしたので、忘れないように書いておきたい。 先日起こった事先日起こった事は、私がシアトルから一時帰国して、普段使わないラップトップを使って日本から仕事をしている。 Application Insights というログを管理するプラットフォームがあるのだが、とても不思議なことに、Application Insights のログファイルを見ると完全に正常に動いているようにしか見えないのだが、クラウドのポータルに行くと、テレメトリが来ていない。 Application Insights のチームのメンバーが助けてくれることになったので、彼女に、Teamsで画面共有をして、「ほら、出ないでしょ？」と見せると、なんとテレメトリがポータルに来ている。その後