エンジニアは「歴史に学ぶ」ことを避けるためなら何でもする?なぜ同じ失敗を繰り返すのか
Engineers will do anything to avoid learning from history
Engineers will do anything to avoid learning from history
世の中のエンジニアは、先人の教訓から学ぶことを避けるためなら、どれだけ苦労しても新しい車輪を再発明することを選びがちです。なぜ私たちは過去の失敗から学ばず、毎回同じ轍を踏んでしまうのでしょうか?その根底にある心理と、現場で起きている「車輪の再発明」のメカニズムを深掘りします。
「何か新しい、まだ見ぬ技術があるように見せかけることで大金を稼ぎ、結果として自分がスマートで最先端にいるように見せる」ってやつだね。これが本質だよ。VCの補助金で市場を破壊するまで叩き売って、既存のものを置き換える戦略とかなり似てるよね。
Brooksの法則を引用して、コミュニケーションの摩擦は人数の二乗に比例すると言ってるわけか。指数は正確に2である必要はなく、2に近ければいい。1+ε(イプシロン)ですでに致命的だからね。これはコースの天井(Coase's ceiling)と密接に関係している。
これ、ソフトウェア開発者がエンジニアと呼ばれない理由のまた一つとして挙げられそうだな。
関連して言うと、ソフトウェア業界が「限界費用がゼロでなくなったとき、他業界がいかに立ち回っているか」という教訓を(ほぼ)完全に無視し続けているのが気になる。ソフトウェア業界の人間が、他業界の人間を「俺たちほど賢くないから動きが遅いんだ」と決めつけているのを見ると本当にイライラするよ。実際は、鋳造部品を作るのに数ヶ月かかるからこそ、一発で完璧に仕上げなきゃいけないってだけなのにね。
俺は20人規模のエンジニアチームで現場叩き上げのエンジニアリーダーをやってるけど、この6ヶ月間、まさにそのことをチームに理解させようと努めてきたよ。
金曜に最近のワークフローを共有するコーヒータイムを設けたんだけど、俺が採用した進め方についてみんな困惑してたみたいだ。マネージャーをしばらくやってる人間には自然なことでも、その道を歩んだことがない人にはすごく異質に見えるんだろうね。
俺のワークフローが優れていると言いたいわけじゃない。ただ、今のチームのやり方とは根本的に違うんだ。実際にはPRD(製品要求仕様書)を徹底したり、エージェント間のコミュニケーションを制限したりといったことに頼ってるだけなんだけどね。
「新しい、まだ見ぬ技術があるように見せかけて大金を稼ぎ、自分がスマートで最先端にいるように見せる。周知の学問を正しく適用するために資金調達するやつなんていない」っていう指摘には興味があるな。投資家って手堅い賭けを好むものだと思ってたんだけど。
その一方で、あまりに早すぎるとビジネスとして成り立たない(というか、そもそもアイデアを売り込むことすらできない)場合があるのもわかる。
関連:You can't tell people anything (2004)
https://web.archive.org/web/20091025030730/https://habitatchronicles.com/2004/04/you-cant-tell-people-anything/
それは、ほとんどのソフトウェアエンジニアがエンジニアじゃなくて、コンピュータサイエンス専攻の卒業生だからだよ。全く別の学問なんだ。
これはエンジニアだけの問題じゃなくて、現代社会のシステムに根付いた問題だと思う。単純に言えば、今の世の中で博識(ポリマス)でいることが異常に難しいってことさ。
存在を知らなかったら、何であれ再発明しちゃうのは避けられない。
ソフトウェアの面白いところは、他のあらゆる分野にうまく組み込める点だ。だからこそ、他分野で(名前は違えど)すでに発明されている概念を理解するための「現代版の違法コピー的博識」を得るには最高の土台になる。
エージェントを扱うことが、既存のプロセスの単なる焼き直しだという主張は間違っているよ。
エージェントの管理にはエンジニアリングマネジメントやプログラム管理と似た部分もあるけど、トークン消費、ドリフトの回避、大規模な並行処理の成功、プロンプトのバリエーション、テスト、評価といった、全く別の次元の課題が山積みだ。言うまでもなく、エージェントは常識ゼロの超知能コーダーで、極端に文字通り解釈したり、やたらと冗長だったりする癖があるからね。
関連:https://news.ycombinator.com/item?id=49314744
AIを扱うことは、コーディングというよりリーダーシップに近い感覚がある