我こそが＠駆け出しエンジニア

相変わらずエンジニア要・不要論が荒れてますがどっちも近視眼的だと思いますよ経済学の歴史に学びましょうジェボンズのパラドックス技術で生産性が効率化するとそれ以上のスピードで需要が増えていくというやつもう一つ見落としてるのはエンジニアリングの定義自体が変わるということむしろ全てがエンジニアリングになっていくんです古参のエンジニアは非エンジニアによる「AIの活用方法」的なものをバカにしがちですがそれは「スタックの誤謬」です https://t.co/Ga3AmPBeSE 「AI世代のエンジニア」というのは本人はエンジニアになるという意識のないままエンジニアリング的なスキルを自然に身につける古参エンジニアとは違う育ち方をするのですそして「未来の定義における」エンジニアの需要は全体として爆増するので古参エンジニアがビビるのはわかりますがちゃんとAIにキャッチアップしていれば全員にチャンスがあります振り落とされるのはAIを拒否する者だけ Sティアのエンジニアの給与はプロスポーツ化が進み Aティアも需要が減ることはありません AIでむしろ低いティアの裾野が広くなるわけですバイブコーダーが本格的なシステム作れるわけないとか悪口言う人たちこそ近視眼的だという話ですそういう人たちと仲間になる未来を描きましょう

767

472

205K

106

Who to follow

κeen

@blackenedgold

それ、kappaだよ ⸜( ¯⌓¯ )⸝ 。TechFeed公認エキスパート（Rust）。

ぽまこ@アプリ個人開発

@nekoko_555

iPhoneアプリ1つリリース🎉 Flutterで開発🔰2児の母😊 お気軽にフォローしてください🙌

tkty

@tkty

我こそが＠駆け出しエンジニア @jfs6100

5 days ago

一部のエンジニアが非エンジニア(ビジネス側)を舐める構造と似てる、気がする

Kenn Ejima

@kenn

about 1 month ago

スタックの誤謬、いい記事だったので全文訳します！ —— なぜ大企業は失敗し続けるのか：スタックの誤謬 Stack Fallacy（スタックの誤謬）は、非常に多くの企業が新しい市場を獲得しようと試みては派手に失敗する原因となってきた。データベース企業がアプリは簡単だと考えたり、VM企業がビッグデータは簡単だと考えたりするのを目にしたとき——彼らはスタックの誤謬に陥っているのだ。スタックの誤謬とは、自分の層の一つ上の層を作るのは些細なことだという誤った思い込みである。数学者はしばしば、自然界全体を数学的な言葉で記述できると信じている。ゆえに、物理学はすべて応用数学にすぎない。そしてそれが延々と続いていく。スタックの誤謬——「ただのアプリでしょ」ビジネスの世界にも、同様の幻想が存在する。データベース企業は、SaaSアプリは「ただのデータベースアプリ」だと信じている——これが、この新市場で簡単に作って、競争して、勝てるという誤った自信を彼らに与える。歴史が示してきたように、AmazonはクラウドのIaaS市場を支配し続けている。一方で、その素材となる下層の技術を作る技術ベンダーたちは競争に苦戦している。VMwareはAWSに勝つには程遠い。AWSのすべてが、VMwareの中核的な強みである仮想マシン技術の上で動いているにもかかわらず、だ。OracleはCRM SaaSでSalesforceに勝てずにいる。OracleはSalesforceを単なるホスト型のデータベースアプリだと見なしているにもかかわらず、である。それどころか、Salesforceは彼らのデータベース上で動いているのだ！ Appleはスタックを垂直に下へと統合することには成功し続けている——チップやプログラミング言語などを作っている——が、ここでもまたスタックを上へ登って、ああいった単純なアプリ、たとえば写真共有アプリや地図のようなものを作るのは非常に難しいとわかった。歴史はこうした例で満ちている。IBMは、自社のPCというハードウェア層を動かすソフトウェア層を大したものではないと考え、MicrosoftにあっさりとOS市場を握らせてしまった。 90年代、ラリー・エリソンはSAPがプロセス自動化ソフトウェア（ERP）を売って途方もない額の金を稼ぐのを目にした——彼にとって、ERPは一連のテーブルとワークフローにすぎなかった——そこで彼は何億ドルも費やしてその市場を獲りにいったが、結果はまちまちだった。最終的にOracleはPeoplesoftとSiebelを買収することで、アプリ市場に金で参入した。なぜ我々は繰り返しスタックの誤謬に引っかかるのか？スタックの誤謬は人間の本性の産物だ——我々は自分が知っているものを（過剰に）高く評価する。具体的に言えば、あなたが大手データベース企業で働いていると想像してほしい——そしてCEOがこう尋ねる——うちはIntelやSAPと競争できるか、と。リレーショナルデータベースのソフトウェアを作れるからといってコンピュータチップを作れると想像する人はほとんどいないだろう。だが、一つ上の層の構成要素に馴染みがあるために、ERPアプリなら作れると信じてしまいやすい。なにしろ、テーブルとワークフローなら知っているのだから。成功のボトルネックは、しばしばツールに関する知識ではなく、顧客のニーズに対する理解の欠如である。データベースエンジニアは、サプライチェーンソフトウェアの顧客が何を望み、何を必要としているかをほとんど何も知らない。そのために人を雇うことはできるが、それは中核的な強みではない。意外なことに、スタックを上へ向かって革新するよりも、下へ向かって革新するほうがはるかに簡単なのだ。その理由は、自分自身が下層の自然な顧客だからである。Appleは、理想的な未来のマイクロプロセッサに自分が何を求めているかを知っていた。それを作るのに必要なスキルは持っていなかったが、顧客としてのニーズはよく理解されていた。技術的なスキルは買ったり獲得したりできるが、市場ニーズの深い理解をただ買ってくることは非常に難しい。したがって、Appleが半導体チップを作るほうが、Apple Mapsを作るよりも楽だったのは何の驚きでもない。 Google、Facebook、WhatsApp Googleはここでの絶好の例だ。Googleは我々のメールのグラフを握り、我々の興味関心のデータ（検索）を握っていた。それでもなお、「作るのは些細なこと」に見えるアプリ——ソーシャルネットワーク——で成功するのは非常に難しいとわかった。実際のところ、これこそがスタックの誤謬の完璧な皮肉である。スタックの上のほうにあるものは作れる。ただ、何を作るべきかが明確でないことが多いのだ。プロダクトマネジメントとは、何を作るべきかを知る技術である。スタックの誤謬は、企業がなぜ明白なこと——あまりに手の届くところにあって、確実に作れそうなこと——で失敗し続けるのかについての洞察を与えてくれる。その答えはこうかもしれない。「何を」は「どうやって」よりも100倍重要なのだ、と。 https://t.co/xX49YyXY46

kenn's tweet photo. スタックの誤謬、いい記事だったので全文訳します！

——

なぜ大企業は失敗し続けるのか：スタックの誤謬

Stack Fallacy（スタックの誤謬）は、非常に多くの企業が新しい市場を獲得しようと試みては派手に失敗する原因となってきた。データベース企業がアプリは簡単だと考えたり、VM企業がビッグデータは簡単だと考えたりするのを目にしたとき——彼らはスタックの誤謬に陥っているのだ。

スタックの誤謬とは、自分の層の一つ上の層を作るのは些細なことだという誤った思い込みである。

数学者はしばしば、自然界全体を数学的な言葉で記述できると信じている。ゆえに、物理学はすべて応用数学にすぎない。そしてそれが延々と続いていく。

スタックの誤謬——「ただのアプリでしょ」

ビジネスの世界にも、同様の幻想が存在する。データベース企業は、SaaSアプリは「ただのデータベースアプリ」だと信じている——これが、この新市場で簡単に作って、競争して、勝てるという誤った自信を彼らに与える。歴史が示してきたように、AmazonはクラウドのIaaS市場を支配し続けている。一方で、その素材となる下層の技術を作る技術ベンダーたちは競争に苦戦している。VMwareはAWSに勝つには程遠い。AWSのすべてが、VMwareの中核的な強みである仮想マシン技術の上で動いているにもかかわらず、だ。OracleはCRM SaaSでSalesforceに勝てずにいる。OracleはSalesforceを単なるホスト型のデータベースアプリだと見なしているにもかかわらず、である。それどころか、Salesforceは彼らのデータベース上で動いているのだ！

Appleはスタックを垂直に下へと統合することには成功し続けている——チップやプログラミング言語などを作っている——が、ここでもまたスタックを上へ登って、ああいった単純なアプリ、たとえば写真共有アプリや地図のようなものを作るのは非常に難しいとわかった。

歴史はこうした例で満ちている。IBMは、自社のPCというハードウェア層を動かすソフトウェア層を大したものではないと考え、MicrosoftにあっさりとOS市場を握らせてしまった。

90年代、ラリー・エリソンはSAPがプロセス自動化ソフトウェア（ERP）を売って途方もない額の金を稼ぐのを目にした——彼にとって、ERPは一連のテーブルとワークフローにすぎなかった——そこで彼は何億ドルも費やしてその市場を獲りにいったが、結果はまちまちだった。最終的にOracleはPeoplesoftとSiebelを買収することで、アプリ市場に金で参入した。

なぜ我々は繰り返しスタックの誤謬に引っかかるのか？

スタックの誤謬は人間の本性の産物だ——我々は自分が知っているものを（過剰に）高く評価する。具体的に言えば、あなたが大手データベース企業で働いていると想像してほしい——そしてCEOがこう尋ねる——うちはIntelやSAPと競争できるか、と。リレーショナルデータベースのソフトウェアを作れるからといってコンピュータチップを作れると想像する人はほとんどいないだろう。だが、一つ上の層の構成要素に馴染みがあるために、ERPアプリなら作れると信じてしまいやすい。なにしろ、テーブルとワークフローなら知っているのだから。

成功のボトルネックは、しばしばツールに関する知識ではなく、顧客のニーズに対する理解の欠如である。

データベースエンジニアは、サプライチェーンソフトウェアの顧客が何を望み、何を必要としているかをほとんど何も知らない。そのために人を雇うことはできるが、それは中核的な強みではない。

意外なことに、スタックを上へ向かって革新するよりも、下へ向かって革新するほうがはるかに簡単なのだ。

その理由は、自分自身が下層の自然な顧客だからである。Appleは、理想的な未来のマイクロプロセッサに自分が何を求めているかを知っていた。それを作るのに必要なスキルは持っていなかったが、顧客としてのニーズはよく理解されていた。技術的なスキルは買ったり獲得したりできるが、市場ニーズの深い理解をただ買ってくることは非常に難しい。

したがって、Appleが半導体チップを作るほうが、Apple Mapsを作るよりも楽だったのは何の驚きでもない。

Google、Facebook、WhatsApp

Googleはここでの絶好の例だ。Googleは我々のメールのグラフを握り、我々の興味関心のデータ（検索）を握っていた。それでもなお、「作るのは些細なこと」に見えるアプリ——ソーシャルネットワーク——で成功するのは非常に難しいとわかった。

実際のところ、これこそがスタックの誤謬の完璧な皮肉である。スタックの上のほうにあるものは作れる。ただ、何を作るべきかが明確でないことが多いのだ。

プロダクトマネジメントとは、何を作るべきかを知る技術である。

スタックの誤謬は、企業がなぜ明白なこと——あまりに手の届くところにあって、確実に作れそうなこと——で失敗し続けるのかについての洞察を与えてくれる。その答えはこうかもしれない。「何を」は「どうやって」よりも100倍重要なのだ、と。

https://t.co/xX49YyXY46

649

140

724

204K

283

我こそが＠駆け出しエンジニア @jfs6100

13 days ago

最近はVSCode上でClaude Code ばっか使ってたけど、たまにGithub Copilot に戻ってみるとやっぱこっちも便利やな。VSCodeとの統合度合いが高くて、agentに任せっきり系じゃなく一緒に作業する系(まさにcopilot)はGithub Copilotのほうが使ってて心地良い。