アマゾンで一部の開発者、自分の仕事が倉庫労働に似てきたと語る

• アマゾンの開発者たちは、AI導入後に作業スピードへの圧力と業務の単純化を経験している
• 管理職は生産性向上を理由に、AIツールの利用を強く推奨している
• 一部では反復作業が減って仕事の質が改善したと見る一方、新人開発者は成長機会を失うという懸念もある
• コーディングが直接的な創造から、レビューと確認中心の作業へと変わる中で、自分の仕事ではないように感じる場合もある
• Amazon Employees for Climate Justice などの社内グループでは、この問題を含めて職務ストレスや将来展望への不安を共有している

---

At Amazon, Some Coders Say Their Jobs Have Begun to Resemble Warehouse Work

コーディングも「スピード勝負」の時代

• 産業革命以降、繰り返し現れてきた機械化による職務単純化現象が、コーディング分野でも起きている
• AIは雇用をなくすというより、既存の職務を単純かつ迅速に遂行する形へと転換させている
• Microsoftの研究によれば、AIアシスタント「Copilot」を活用した開発者の生産性は25%以上向上した
• アマゾンはこれを受け入れ、AIによるより速く効率的な作業を要求しており、株主向け書簡でそれを「コスト削減と競争力維持」の中核として強調している
• 例えば、ある開発チームは昨年の半分の規模で運営されながら、同じ量のコードを求められている

企業全体の流れ

• Shopifyは全従業員に対し、AI利用を基本要件とし、評価にも反映すると明示している
• Googleは社内ハッカソンで、日常の生産性を高めるAIツール開発をテーマにしている。すでにコードの30%以上がAIの提案を通じて生成されている

前向きな面と懸念

• 一部のマネージャーは、AI導入により退屈で反復的な作業が減り、より創造的な業務に集中できると主張している
• AmazonはAIのおかげで4,500年分の開発業務を節約したと言及している
• しかし、ハーバード大学の経済学者Lawrence Katzは、初級開発者にとって職務成長の機会が失われる効果を指摘している
• 過去に工場労働者が経験した「スピード勝負」と同様に、開発者たちもより速く、より多くを処理するよう圧力を受けている

開発者たちが感じる変化

• アマゾンの物流倉庫と同じように、開発者たちもAIによる作業の自動化と分業化を実感している
• AI利用は「選択」だが、成果目標を満たすには事実上必須として機能している
• 以前は数週間かかっていた機能開発が、今では数日以内に完了しなければならず、そのために会議時間の削減とAIコード利用の拡大が行われている
• AIはプログラム全体の生成まで可能だが、コードを読んでレビューする作業が増え、面白さと没入感が低下している

キャリア成長と没入感の低下

• 新人開発者は、テスト自動化によってコードを深く理解する機会を失う可能性がある
• AIは企画書作成、コードテストなどさまざまな業務を支援するが、人間ではなくツール中心の評価環境へ移行しつつある
• オバマ陣営の元CTOであるHarper Reedは、すべての部分を深く理解しなくてもよい時代だと見ており、これは製造業に似た変化だと説明している
• 一方で、Simon Willisonはアイデア実現のスピードが速くなる点でAIを前向きに評価している

不満と組織的反応

• AI利用とそれに伴う職務変化により、多くの開発者がAmazon Employees for Climate Justice グループで不安やストレスを共有している
• とくに職務の質の低下とキャリアの不確実性への懸念が大きく、これは過去に自動車労働者が感じていたスピード勝負のストレスと似ている
• まだ開発者の労組結成の動きはないが、組織内での内部的な共感は広がっている

歴史的文脈と今後の見通し

• 1936年のGMストライキ当時のように、職務スピードと自律性の問題は労働者の行動の触媒になり得る
• 過去には個人が作業方式と速度を調整できたが、今では全工程が監視され、速度中心で評価される体制へと変わっている

[GN⁺]

Hacker News の意見

• archive.ph/HVZRL のリンク共有内容
• 私にとってLLMベースの開発は、クリプトやVRのように誇張された流行 hype に思える。最近、vibe coding で書かれたコードベースのバグを修正する経験をして、このやり方は体系のないビジネス上の問題が構造化されないままコードに移される、一種の混乱の塊だと感じた。改善が必要な部分を狭いパッチで埋め続けるため、結果として複雑で無秩序なコードが生成される。context window の限界にぶつかると、LLM は自分で当てたパッチすら覚えていられない。英語（または人間の言語）は、私の欲しいコードを正確に説明するには曖昧で、シニア開発者がコードに染み込ませてきた膨大な経験と試行錯誤の総体をプロンプトとしてすべて書き出すのは極めて重い作業だ。「なぜこう書いたのか」とは逆に、「こういう状況ではこうするな、ああしろ」という非常に具体的で終わりのないリストが必要になるという違いがある
  • 私がこの30年で見てきたコードベースの大半（ただ1つを除いて）の説明にぴったり当てはまる観察
  • 反論として—AI が構造を抽出すべき30か所ほどでコードパターンを見つけるのを助けてくれたこともあった。vibe coding の問題は態度だと思う。自分でコーディングするのを避けたい人が、長期的な構造や品質より今の楽さだけに集中しがちで、ある種の怠惰の増幅器だという考え
  • 実際、多くのプロダクションコードは、パッチを継ぎ当てしながら動いているコードスニペットの断片集合だ。現実には CPU が速すぎるので、こういうコードでもそのまま動いてしまうという悲しい状況
  • 人間の言語が明確ではないという指摘に同意する。結局、自然言語で明確にソフトウェアを扱おうという試みは何度も繰り返されてきたが、法律と同じくグレーゾーンの解釈は絶えない。将来、開発者がコンパイル前にプログラムの意味を議論しなければならないなら、その未来は暗い
  • AI もクリプトやVRと同じくらい誇張された hype に見えるのは確かだ。だが、ソフトウェアエンジニアのような高度に技術的な職業にも、結局は自動化が影響する。ここ10年ほどテック業界の人々は、自分たちは他の労働者の問題とは無関係だと錯覚してきたが、リプレースやレイオフの文化によって、いまや賃金抑制が本格化している。AI が全体を即座に置き換えなくても、5人でやっていた仕事を4人が AI と一緒にこなすようになり、1人が削減され、残った人たちも昇給を要求しにくくなる構造が繰り返される。テック職も結局は労働者なのだと気づくべきだという主張
• Harper Reed の「コードについて深く理解する必要はない」という意見について、こうした発言はむしろ「コンパイルさえ通ればデプロイしよう」という場当たり的な論理に感じられる。自動化ラインでは絶えず品質を測定していても、実際の機械は角度を取り違えたり、見当違いの溶接をしたりといった幻覚は起こさないのに、LLM ベースのソフトウェアではこうした些細な誤差が繰り返される
• LLM ベースのツールが本当に開発者の生産性を劇的に高めたのか、それとも組織が、より少ない—そして以前より特権的でない—開発者だけでも回ると気づいただけなのか疑問だ。大手テック企業の中で「革新的な生産性向上」の事例もあまり見ないし、今のところは投資を相殺できる程度のわずかな生産性向上しかない
  • かなりの部分は認識の問題だ。以前は開発は難しい仕事だったが、AI ツールの登場でコーディングの参入障壁が下がったと認識されている。ソフトウェア開発がますます工場労働のように感じられ、知的なやりがいが減っている現象
  • コードベースの長期的な保守性に疑問がある。vibe coding は徐々に複雑さや微妙なバグ、抽象化の問題を積み上げ、最終的に保守や新機能開発の難易度を上げる。短期的な生産性向上に閉じ込められ、長期的な品質低下につながる可能性
  • 組織は以前から官僚的な手続きによって「技術からの離脱」、つまり熟練度の低い人材を標準化で置き換えてきた。長期的には毒になり得る戦略だが、一貫性さえあれば「そこそこ使える平凡なソリューション」で満足してしまう
  • この論理に説得力を持たせるには、Amazon 経営陣が長期的な品質より短期利益を重視していると仮定しなければならないが、それについては確信がない
• もうすぐ引退する立場として、最近の変化には虚しさを感じる。90年代にキャリアを始めた当時は、長い時間をかけて実験や創造性に没頭する余裕があった。今は細かなタスクと進捗報告、絶え間ない正当化が必須だ。今後も面白い開発者はいるだろうが、そうした機会は減っている。実際、他の職業が自動化で苦しくなってきたのと同じ道をたどっているのだから、公平な結果ではある
  • 日常的な進捗報告の stand-up などは時間がかかるうえ、自分の仕事を理解していない人たちからもう1日自由でいるための形式的な対応にすぎず、仕事の価値を下げる
  • 私も90年代入社で、JIRA ベースで細かく統制される状況には共感する。ただ、昔だけが無条件に黄金時代だったとは思わない。過去の良い経験だけを記憶しようとするノスタルジー補正もある気がする。それでも今でも十分に挑戦的で良い仕事、学べることはある
  • エンジニア職の自動化というより、実際には管理職を AI 中心の監視に置き換える方向性
• ソフトウェア開発を画期的に速くするには、誰かのオープンソースコードをそのままコピーして使い、著作権やライセンスの痕跡を消して適用するという方法もある。自分で見つかるのが心配なら外注業者を使ってロンダリングすることもできるし、今では AI で安く速くロンダリングすることも可能だ。Google は以前はこうした行動を控えていて、大胆さが足りなかった。だが小規模な新興企業は、著作権侵害のリスクを無視した AI 活用で素早い成功を狙っている
  • 私の属する業界では、むしろコードの不在より「何をどう書くべきか」を定義することのほうが大きな問題だ。Stackoverflow や Github では解決できない固有の問題も多い
  • Google も実際には以前からサイトのコンテンツをクロールして検索結果に直接表示し、トラフィックなしで他人のコンテンツを利用してきた。今回も単に遅かっただけだ
  • 皮肉なことに、大企業にオープンソースコードを盗用してほしいとさえ思う人もいる。彼らが自分で作った冷淡で非効率なやり方を、利用者の立場で押しつけられるよりはましだからだ
  • オープンソースにコードを載せることの限界に共感する。大企業は無償労働力を得る手段としてオープンソースを奨励する傾向がある。短期的に貢献が減っても、長期的には業界が健全になるという考え
  • ChatGPT の登場と Sam Altman のリーダーシップの無責任さへの指摘
• コードを書くことより読むことのほうが難しくて面白くないという Simon Willison の発言と、AI が文書作成やテストなどの付随作業を多く助けているという Amazon 開発者の事例が印象的だ。いまやコーディングより、既存コードのレビューやバグ修正が中心の役割へと変化している
  • 初期にコードを書くのが楽しかった昔を思い出す。今ではバグ修正のほうがより面白く、LLM が単純な反復コーディングを代わりにやってくれるので、挑戦課題に集中できる。LLM のおかげで開発の楽しさの一部が生き残っている
  • この記事から感じられる雰囲気はかなり否定的だ
• 生産性向上の新技術が出ると、企業はすぐにその効果を取り込み標準化する。追いつき続けるには絶えず学ばなければならず、いつかは自分自身の成長利益を直接得られる環境（自営業など）への転換も考えるべきだ。だが一人で働くということは、AI に習熟した人たちと競争することを意味するので、簡単な解決策ではない
  • 3つの未来シナリオが予想できる。1) コードベースが徐々に混乱と不安定さの中で崩壊し、最終的には経験豊富な開発者を高額で再投入しなければならなくなる可能性。2) AI がどうにか使える程度のコードを作り、品質や信頼性は低いが大事故は起きないという楽観。3) AI が急速に賢くなってコードベースという概念自体が消え、必要なときに動的に生成・進化するソフトウェアの時代。現在の LLM はまだそこには遠く及ばない。企業の幹部たちは 3) を信じているが、今の現実は 1)〜2) だ。適切に管理されれば、2) のようなバランスの取れた見方にも移行できる
  • 生産性向上がもっと公正に分配されるモデルもある。かつてのヨーロッパのように労働時間短縮などだ。最近は労働者たちでさえ、忙しそうに見える正体不明の雑務に追われているように見える
  • 君は実質的にマルクス主義者の視点を語っているのに、妙なことに結論が自己疎外に行き着いているのが面白い。少し力を合わせれば改善できるのに、そうしていない
  • 絶えず自己啓発し続けなければ生きていけないと受け入れるのではなく、社会の構成員と力を合わせ、雇用主に対して一緒に要求するという方法もある。週5日制、8時間労働、児童労働の禁止も集団行動によって得られた成果だ。自分の仕事だけを頑張り、他人がうまくやることだけに注目する必要はない
• 私たちの業界が幼稚になっていく様子にはいつも驚かされる。大企業や大規模コードベースの経験者なら、新規コード生成が開発のごく一部にすぎないという現実を知っている
  • 実際には新規コード以外の仕事、つまりその他の付随部分も大企業では非効率だ。AI がこうした点も変え、終わりのない会議や抽象的な議論が減るという見通し
  • いま熱狂している人たちのかなりの部分は、実のところ最新パラダイムに縛られてコードを書くこと自体が難しくなっている人たちだ。Copilot などの LLM ツールで素早く POC を作ってそのままプロダクションまで持っていき、品質や拡張性などは深く考えない場合が多い。そしてこういう人たちが、AI 導入による生産性向上の事例を無条件に宣伝し、大企業の利益と噛み合った主張ばかり繰り返す。実務では物足りない点も多いことを、実際に使っている人たちは皆知っている
  • 私も全体時間の20%ほどしかコーディングしておらず、残りは要件収集、設計、テスト、スケジュール管理だ。その20%のコード作業が半分に減れば、浮いた時間でテストやドキュメント作成をもっとできると思う
• LLM の助けで開発効率が大幅に上がるという思い込みがある。実際には、品質を落とさずに生産性を上げられるのは基礎力がある場合だけだ。つまり熟練者には生産性の増幅効果があるが、人数だけ増やした初心者集団に LLM を持たせても、品質の高いソフトウェアを作るのは難しい
  • こういう主張は繰り返されるが、「品質」のカットラインがどこかが重要だ。実際、若い開発勉強会チームに SRE の友人が週次レビューしながら LLM を積極活用しているが、コード品質や拡張性も十分だ。速度は遅いが完成度は悪くない
  • 「良い」ソフトウェアが必要な場所は一部にすぎず、実際 Deloitte や Accenture のような企業の収益構造を見れば、ほとんどの企業は品質など気にしていない。大半にとっては「それらしく見える」ソフトウェアで十分だ