22 ポイント 投稿者 GN⁺ 2025-08-22 | 11件のコメント | WhatsAppで共有
  • AWS CEOのMatt Garmanは、AIがジュニア社員を代替できるという発想について「私がこれまで聞いた中で最も愚かな話だ」と発言
  • 彼は、ジュニア社員は最もコストが低く、なおかつAIツールの活用に積極的であり、人材育成と学習機会の提供が不可欠だと強調
  • また、AIの成果をコード記述量で測るのは無意味な指標であり、不必要に多いコードよりも少なく高品質なコードが重要だと指摘
  • AWS内部ではすでに80%以上の開発者がAIを活用しており、単体テスト、ドキュメント作成、コード補助、エージェントベースのワークフローなど多様な形で適用されている
  • Garmanは、急速に変化する技術環境で長期的に必要なのは批判的思考、創造性、学習能力であり、こうした能力を持つ人材がAI時代に成功すると展望

ジュニア社員代替論争に対する見解

  • Garmanは、一部の経営陣がAIですべてのジュニア社員を置き換えられると主張していることに強く反論
    • ジュニア社員は「最もコストが低く、それでいてAI活用に最も積極的」だという点を強調
    • 「10年後に誰も経験を積めなかったら、どうなるのか」と述べ、人材育成の必要性を力説
  • 彼は依然として、大学卒業者を採用し、問題解決の方法を教えて訓練するプロセスが不可欠だと主張

AI活用の方法と指標に対する批判

  • コード記述量を基準にAIの成果を測る慣行を「くだらない指標」だと批判
    • 無限に多くのコードを生成することはできても、そのコードの品質が低い可能性がある
    • 「少ないコードのほうがより良い場合が多い」と述べ、量的指標への執着を問題視
  • AWS内部データによれば、開発者の80%以上がすでにAIを活用
    • 単体テストの自動化、ドキュメント作成支援、コードの一部作成、エージェントベースの協業など多様な方法で利用
    • こうしたAIツールの利用率は毎週増加傾向にある

AI時代の教育とキャリアへの助言

  • Garmanは、AI時代に必要な能力として批判的思考、創造性、学ぶ姿勢を挙げる
    • 特定の技術習得ではなく、「学び方」そのもの
    • 「自分で考える方法、問題を分解して解決する能力、新しいことを学ぼうとする姿勢」が重要だと強調
  • 技術の進歩があまりにも速いため、特定の技術だけを学んでも30年のキャリアを支えるのは難しいと指摘
  • したがって教育者は、学生に問題を分解して考える力、新しいことを学ぶ姿勢を教えるべきであり、それを備えた人材がAI時代に繁栄すると展望

11件のコメント

 
minsuchae 2025-08-23

私は、どちらについても十分に考える必要があると思います。

会社を運営するには開発者が必要であり、現在はジュニア開発者の就職が難しい時期だと見ています。
表向きにはAIのせいにしていますが、コロナ禍の時期に大幅採用を行ったこと、そしてそれに見合う成功以上に会社全体の人件費が上昇したため、その負担から採用を減らしている面もあります。そうした状況でLLMの活用が、ジュニア開発者に業務を任せるのと同等以上の効率を示すようになり、就職市場そのものがさらに縮小したのだと思います。

しかし、記事にもあるように、ジュニア開発者がいてこそ最終的にシニア開発者へと成長できます。
ジュニア開発者の段階で採用しなければ、シニア開発者は生まれない構造です。

それでも、この過程ではかなりの調整が必要だと思います。
大企業の場合は体制が整っているのでまだましですが、ジュニア開発者が入ってきた場合、会社の中核業務をいきなり任せるのではなく、多少の雑務(失敗しても許容できる業務)を担当させながら教育します。

しかし、シニア開発者の立場からすると、体制が整っていないほどジュニア開発者を指導するのはより大変な状況です。

そして皮肉なことに、LLMを使うときは関連知識が多いほうが有利であって、初心者の開発者だからといって同じ効率を出せるわけではありません。
むしろ、すべての開発業務をジュニア社員で置き換えることは不可能です。非常に優秀な天才なら、シニア開発者がいなくても何とかできるでしょう。では、その人に仕事が集まり始めたら、その人は耐えられるでしょうか。

つまり、シニア開発者とジュニア開発者の両方を採用すべきであり、その過程では生産性や会社の人件費などを考慮した柔軟な採用が必要だと思います。

 
zxcv123 2025-08-22

この記事を否定する人は、
自分のレベルが低くて、レベルの低いジュニアとしか働いたことのないシニアばかりだよw
経歴に関係なく、AI時代は頭のいい人が圧倒的に有利な世界だ。
頭のいい新卒が1〜2年本気でやれば、無難な10年選手なんて食ってしまう

 
onixboox 2025-08-23

AIがなくても、頭の切れる新卒なら1〜2年みっちりやれば、そこそこの10年選手くらいは普通に食ってましたよね…

 
epdlemflaj 2025-08-22

なんだか「ジュニアは安くてAIもうまく使えるのに、なぜ置き換えるんだ? シニアを置き換えよう!」と言っているような感じがしますね

 
rlaaudgjs5638 2025-08-22

ああ、そのように理解することもできますね

 
ididid393939 2025-08-22

ふざけるなww

 
ifmkl 2025-08-22

はぁ…

 
aobamisaki 2025-08-22

このような形でコメントするのはご遠慮ください。ここはDC Insideではありません。

 
dlehals2 2025-08-22

ここはDCではありません..

 
kht6163 2025-08-22

口の利き方

 
GN⁺ 2025-08-22
Hacker Newsの意見
  • 完全に同意する。 一方で、LLMのコードを実際に使うには本当にプロンプトの魔術師にならないといけないと感じる。 自分はたまにデバッグやUIを素早くスケッチするときにだけ使う。 実際のコードについては、LLMが書いたコードは本当にスパゲッティコードで冗長だし、性能とセキュリティの面で深刻なリスクがあり、こちらが与えたほぼすべてのデザインパターンを完全に誤解したコードになっている。

    • Hacker NewsやRedditでAIコーディングに懐疑的な投稿を見るたびに、ますます驚いている。 まるでみんな完全に違う世界に住んでいるようだ。 ツールの多様性も原因だと思う。 「LLMのコードを使う」という言葉の意味は人によって違うと思う。 具体的にどのLLMを使うのか、どんなコンテキストが与えられるのか、どのIDEを使うのかが結果に大きく影響するように思う。 自分はagentic codingが流行る前まで20万行のB2B SaaSのコードを自分で書いていた。 今ではSonnet 4のAgentモードで、毎日書くコードのうち自分が書くのは20%ほどで、残りの80%はVS Codeのinteractive SonnetとGitHub Copilot Agentsが書いている。 Markdownでドキュメント化すればするほど、その比率は高くなる。 成果物は注意深くレビューしてテストしている。

    • どんなツールを使っているのか気になる。 自分はaiderを使っているが、gpt-5のようにコーディングが弱いと噂されるモデルを使っても、あなたの言うような経験はまったくなかった。 実際に「良い」コードを書いてくれるし、既存コードのスタイルにもよく合わせてくれる。 プロンプト作成は本当に重要で、既存コードベースでは具体的な実装のヒントを与えられると成功率がはっきり上がる。 これはコードベースをよく知っているシニアなら簡単にできるが、ジュニアには難しいかもしれない部分だ。 あらゆる面を明確に見ないといけないと思う。 今のところ、aiderを回すより自分でやる方がわずかに速いことが多いが、差は大きくなく、継続的に良くなっている。 LLMはジュニア開発者ができるいくつかの仕事は代替できるが、完全には代替できない。 ジュニアは会議にも出るし、議論も主導するし、最終的にはシニアになる成長経路もあるからだ。 ただし経営陣は、こうした事実には関心がないかもしれない。

    • AIは大量の情報をぼんやり検索するには素晴らしいツールだ。 最近はKagiのAssistantを通常の検索より先に使うことがどんどん増えている。 自分に足りない言葉を教えてくれて、その単語でページを探ると最終的に欲しいものにたどり着ける。 ただ、vibe codingで継続的に価値を得られたことはあまりない。 単発の仕事では優秀だ。 たとえばmatplotlibのチャートを作るとき、やりたいことを伝えてデータスキーマだけ見せれば、90%はうまく合わせてくれる。 シェルスクリプトも簡単に作ってくれる。 最近ではRAW写真をEXIF情報でフォルダ整理する小さなCLIツールを作らせてみたが、こういう類にはとても満足している。 でも少しでも複雑なことをさせると、役に立たないことをたくさんやる。 すでにプロジェクトにあるモデルを重複して生成したり、関係ない変更をしたり、存在しないAPI関数をでっち上げたりする。 結果を検証するくらいなら自分で書いた方がいい。 そして自分にとっては、直接コーディングする過程こそが一番楽しい部分だ。 LLMは、人間がプロンプトを通じて一時的に結果を得て、そのまま保存・統合・受け渡しする実運用の過程には、まだ適した例を見つけられていない。

    • AIは、広告まみれのぐちゃぐちゃなサイトが何百もある中から、自分の探している答えを素早く絞り込むのに非常に役立つ。 Duck Duck Go AIを質問応答用としてよく使っている。 データセンターを投げつけられる距離くらいにしか信用していないが、素早く検証できる情報、たとえばプログラムの文法やコマンドオプションのような明確な内容には有用だ。

    • AI活用では「入れた分だけ返ってくる」という言葉がぴったりだ。 多くの時間をかけて内部動作、エッジケース、アーキテクチャ、ライブラリ選定などを説明し、丁寧にMarkdownへ書き込めば、数回回すだけでも使えるコードが出てくる可能性は高い。 「X機能を作って」といった短いプロンプトとは大きな差が出る。 でも、そんな良いプロンプトを書ける時点で、実質的には問題をほぼ解いている。LLMは単なる高速な自動タイピング装置だ。 速くなるのはタイピングだけで、思考の大半はすでに人間が済ませている。

  • 少なくともCEOの一人はこの部分を理解していると思う。 ジュニア人材を飛ばしてAIだけで埋めようという考えは、長期的には企業に悪影響だ。 シニア人材が独立して去ってしまえば、何も残らない。 正直、AIがどんなエンジニアにとっても、ジュニアを含めて、本当に有益なのかはよく分からない。 ソフトウェアエンジニアリングは探究と学習の旅だ。 AIを使うたびに、数学の先生が「電卓を使うと頭に残らない」と言っていたのを思い出す。 全体として、AIはこの45年間のアメリカの経済政策の自然な帰結という気もする。 ひたすら1%のための短期成果追求であり、健全な企業生態系や経済の長期的発展を損なうやり方だ。 これを見ると、ジャック・ウェルチがとても誇らしく思いそうな状況だ。

    • 「シニアが去ったらどうなる?」 CEOは actually シニアが辞めることを心配する人ではない。 むしろ「ジュニアを残せ」と叫ぶが、その含意は「シニアを出せ」であり、既存の業界トレンドとも一致している。 OPの引用文では、「[ジュニア代替]という発想は『自分が聞いた中で最も愚かなこと』であり、その理由としてジュニアがおそらく最も安い社員であり、AIツールの使用にも最も積極的だからだ」と述べられている。 結局のところ、能力や実力を脅威、リスク要因として見ているということだ。 業界全体がこれからも『雑さ』を維持し、知的競争力が崩れていく速度をできるだけ速めろというシグナルだ。

    • 「CEOが少なくとも一人はちゃんと理解している」

「AIはすべてのエンジニアに利益をもたらすとは限らない」 CEOのインタビューを聞くと、このCEOはむしろコーディング用LLMの導入に全力の人だ。 AWSエンジニアの80%がすでにLLMを使っており、今後さらに増えるだろうと誇らしげに話している。 10分ほどでもインタビューを聞いてみることを勧める。

* AIは全体として、自分の学習過程に役立ったと思う。
  何年も作りたかった個人プロジェクトがあったが、いつも開始のハードルが高すぎて諦めていた。
  AIのおかげで反復的で退屈な作業を簡単に処理できるので、実際にプロジェクトを完成まで押し進められた。
  AIなしで最初から最後まで一人でやっていたら、もっと多くを学べたのかもしれないが、そもそも始められなかったなら得るものは何もなかった。
  今は実際に学ぶ量が確実に増えている。

* シニアが残っていても、変化や導入に関心がなかったり動きが遅かったりすれば、それもまたリスクだ。
  AI導入によってジュニアの学びと成長の速度はものすごく速くなると思う。
  • ここ数か月スタートアップと仕事をしてきて、LLMのvibe codingに深くはまり込み、もう抜け出せなくなっているケースをたくさん見た。 きちんと人材を採用できなかったり、技術人材を取り逃がしたりしたケースが多かった。 彼らはAIコード、とりわけClaudeのコードを社内10xエンジニアと勘違いして、より速い反復とより良いコードを期待している。 かなり賢い創業者たちが、自分でClaudeのコードに、まるで数週間あるいは数年分のソフトウェアエンジニアリング作業をこなしたかのような感覚を覚え、そのドーパミンに中毒していく様子を目撃した。 AIが複雑な問題を「考えたり」「理解したり」できると信じるのは、あまりに好意的すぎる評価だ。 私たちは実際の思考力ではなく、「タイピング速度の削減」を測るべきだと思う。 [1] vibebusters.com

  • 「考え方」と「問題の分解方法」を教えるべきだという点に完全に同意する。 工学部で最高だった教授は、いつもオープンブック試験を出していた。 現実では、誰もがすべてのデータと情報を見られる環境にいる。 単にデータを探すことに金を払うのではなく、データを分析し、理解し、論理的に応用する能力に対して報酬が支払われる。 これこそがエンジニアリングと呼ばれるもので、その教授はまさにこれを教えていた。

    • 大学時代に抽象代数学の講義を受けた。 試験問題はすべて、有名な証明を暗記して書くこと、そして新しい証明を作ることだった。 暗記自体は無理やりに感じたが、証明を理解せずに暗記することはできないと気づいた。 自分で新しい証明を作るときには、すでに頭の中にモジュールがあるので、ずっと直感的に取り組めるようになる。 真の暗記というのはアルゴリズム問題の解法スタイルのコードを覚えることとは違い、実際のアプリケーションコーディングはもっと人間中心の即興的で、状態ベースの即席グラフ探索に近いと思う。 現実の問題にはいつも新しい順序があるわけではなく、結局ヒューリスティクスが鍵だ。

    • これがこの分野の採用が直面している核心的な問題だと思う。 本当に有能な開発者は本質的にジェネラリストだ。 専門性に価値があるのは確かだが、古いレガシーコード地獄や限界突破のような状況でなければ、専門家が必須とは限らない。 むしろ、馴染みのないスタックを扱ったことがある人が弱点を埋めたり、新鮮な視点をもたらしたりする。 有能な汎用開発者なら、どんなスタックにも素早く適応する。 会社ごとに使っている技術がバラバラだからだ。 「React経験15年」みたいな条件を付けても、誰が来てもいきなり最大生産性は無理だ。 必ずオンボーディングの時間が必要になる。 しかし現場の採用担当者はこうしたことをあまり分かっていない。 大企業はまだトレーニングしてくれるが、最近はそういう雰囲気も昔ほどではない。 採用競争のために何十万ドルも使いながら、実際に誰かを採って育てるコストはあまり重く見ていない。 業界全体としても、専門職協会のようなものがあって、採用や人材育成の構造がここまで壊れるのを防ぐべきだが、そういうものがないのでなおさら問題だ。 (最近、リストラや外注化などを背景に労組が注目されているのも同じ文脈だと思う。)

    • すでにそういう変化は起きているのではないかと思う。 伝統的なCSカリキュラムの半分は数学で、残り半分も名前が違うだけで実質的には数学だ。 学界への批判は多いが、誰かが「学界は愚かだ、こういうことを教えるべきだ」と言うとき、その内容はたいていすでにやっているか、あるいは必要なだけ素早く習得できるものだ。 新しいトレンドの大半は、すでにやっていることだ。

    • 大学時代、哲学科に「考える学科、考えることを学ぼう」というマーケティングスローガンがあった。 採用担当者としての経験では、人文学を学んだ人の方が分析や理解といった本質的課題にずっと強い。 自分もCS/哲学のダブルメジャーなので偏見はあるが、本当にコードをたくさん書けるだけの人より、分析的思考力を備えたジュニアの方がずっと貴重だ。 分析的思考はコーディングよりはるかに教えるのが難しい。

    • コンピュータサイエンスのエリートが、ビジネスやユーザー視点で問題を分解せずにいきなりコーディングしようとすることを、「crazy finger syndrome」と呼んでいた教授が1年目にいた。 その教授の「とにかくコードを書きたがる不安な学生」に関する冗談が懐かしい。 最近のブートキャンプは、高い倫理基準と常に両立しているとは思えない。

  • 「将来、きちんと学んだ人が誰もいなくなったらどうなるのか?」という問いを聞いた。 この結論はすでに多くの人が当然のこととして受け入れているはずだ。 それでも、ほとんどの企業が長期的持続可能性より短期収益性に集中する構造から抜け出すのは簡単ではないと思う。 その中でも、インターンシップやco-opが人材パイプラインを維持する対策として引き続き重視されている。 今後は、ジュニア開発者採用の難しさを避けるため、さらに強くインターンシップへ注力する流れも予想している。

  • 自分の経験を要約すると、こんな感じだ。 うちの社長が「AI導入で大規模に人を減らす」と宣言的なPRをしてAIリーダーを気取っていたが、実際にやってみると完全にひどい出来で、今は自分が前に出て謝罪と釈明をしている最中だ。

    • 社長 -> VP: 「AIのせいで人を減らさないといけない」 VP -> 大衆: 「2年以内に全エンジニアをAIで置き換える」 社長 -> VP: 「VPもAIのせいで減らさないといけない」 VP -> 大衆: 「人をAIで置き換えるのは愚かなことだ」

    • それでもなお、ジュニア開発者は採用していない。

  • AWS CEOも立場を変えたようだ。 1年前には「AIが2年以内に全部コーディングするようになる」と言っていた。 [1] ついにc-suiteが現実を受け入れつつあるようだ。 [1] https://news.ycombinator.com/item?id=41462545

    • CEOが実際にそう言ったわけではない。 彼は、2年以内に開発者がコードをほとんど書かなくなる可能性があると言っただけだ。 そして続けて、「これからは何をどう作るか、そして実際の顧客に何が必要かにもっと集中すべきだ」と述べている。 記事リンク 前提から今回の発言まで一貫した文脈だ。 「コードを書くこと」自体の重要性は下がるかもしれず、だからこそジュニアを採用して学び方を教え、実際に役立つ能力を育てるべきだとしている。

    • 理論上、Amazonの企業価値の大半は人材の能力だ。 一部には、人員を単なるコストと見なし、すべての価値は株主のものだと主張する人もいる。 しかし実際に人的資産に価値があるなら、AIだけで誰でもその価値を得られると主張するのは、むしろ株価に悪影響だ。 PE(株価収益率)低下のリスクまであるのに、これを前向きに解釈するのは不思議だ。 もし本当にAIさえあれば何でもできると信じるなら、株主の立場では資金をFAANGのように安定して置いておけず、次々と新しい「成長ストーリー」を探し続ける負担が増すだけだ。

    • 経営幹部なら、常に時代の流れを察知することが不可欠だ。

    • まったく矛盾した発言ではない。 自律的なAIに指示を出すには、シニアだけでなくジュニアから育てる人材パイプラインが必ず必要だ。 大企業はこのパイプラインを心配しており、小さな会社はそれを受ける形で短期的にシニアだけ採用し、インターンは採らないかもしれない。

    • 二つの発言の間に論理的矛盾はない。 ジュニアを継続して採用しつつ、彼らの仕事が実務コーディングとは違うものになる可能性はある。

  • 社長と立場が違うように見えるなら、直接確認してみることを勧めたい。 ニュース記事を文脈なしでただ引用するのは望ましくない。 誰も実際には未来を予測できないからだ。 [1]: https://www.shrm.org/topics-tools/news/technology/ai-will-shrink-corporate-workforce--amazon-ceo-warns

    • 二人のCEOの発言が互いに衝突しているとは思わない。 「大学卒業生を継続して採用し、ソフトウェアを正しい方法で作ることを教える必要がある」 - Matt Garman 「今日やっている多くの仕事には、人があまり必要なくなるだろう」 - Andy Jassy ニュアンスが違うだけで、本質は似ている。

    • 引用するときは、必ず原文を文脈ごとできるだけ等価に引用するのが倫理的だと思う。 誰を引用対象に選ぶか、どんな文脈を作るかによって、ニュースの論調は決まってしまう。

    • 二つの発言は論理的に非常に一貫している。

    • AWSを辞めた経験者として言うが、AWSの公式発言を全面的には信用しない。 もともとAWSがどういう会社かも知っていたし、46歳のとき8社目として入った。 「永久リモート」と言っていた職種でも、自分がすでに退職した後にRTOが命じられた例もあった。

  • 学術界の研究人材パイプラインはこうだ。 学部生 -> 大学院生 -> 博士研究員 -> テニュア/シニア ごく一部の例外を除けば、最初の二段階を飛ばしてシニア研究者になることはない。 どの業界でも同じだ。 ジュニアがいなければシニアは生まれないのだから、「ボット」にすべてをやらせたいなら、そのリスクにも備えるべきだ。

  • これらのモデルと長く付き合ってきた人なら、みんな同意すると思う。 o3リリース前のsamaのAGI投稿や、当時のテック界のdoomer投稿は、振り返ると本当にばかばかしかった。

    • AGI doomerismは単なるマーケティング戦略だった。 今ではみんなAIの本質を理解していて、いま見ているのは、AIが文書を全部読んでくれる新しい検索市場の繰り返しだ。

    • もともと愚かなノイズだったが、誰一人として「ハイプ」から自由ではない。 とりわけ、技術の実態以上に話を膨らませるastroturfingに莫大な金が投じられたのだから、なおさらだと思う。

    • ChatGPTは、自分が一緒に働いたどのジュニア開発者よりも優れていると思う。 ジュニアは1年近くチームにとってマイナスだ。 実際のプロジェクトに責任を持つ立場として、「ジュニアがもっといてほしい」と思ったことは一度もない。 むしろ20%上乗せしてミドルクラスを引き抜く方がずっといい。