ハクソク

世界を動かす技術を、日本語で。

次の2年間のソフトウェアエンジニアリング

95日前原文(addyosmani.com)

概要

  • ソフトウェア業界はAIの進化と経済環境の変化で大きな転換点に直面
  • ジュニア採用減少やスキルの変化など、今後数年を左右する重要課題が浮上
  • AI活用が進む中でのエンジニアの役割変化に注目
  • それぞれの課題に対し、二つの異なるシナリオと生き残り戦略を整理
  • 本記事は予測ではなく備えるための視点を提供

ソフトウェア業界の転換点とAI時代の生存戦略

  • ソフトウェア業界はAIの進化により、単なる自動補完から自律的に開発タスクを実行するエージェントの時代へ移行
  • 経済環境の変化（利益重視、経験者優遇、小規模精鋭志向）により、採用やチーム構成が大きく変化
  • 新世代開発者はキャリア安定志向かつAI活用前提で就業
  • 今後の展開は不透明だが、2026年までを左右する5つの重要な問いが存在
  • 本記事では各問いごとに対照的な2つのシナリオと具体的な対応策を提示

1. ジュニアデベロッパー問題

  • AIの普及でジュニア採用が激減または産業横断的に開発需要が拡大という2つの未来
  • Harvardの調査：生成AI導入でジュニア雇用が約9-10%減少、シニアはほぼ変化なし
  • 大手テック企業は新卒採用数を過去3年間で50%削減
  • AIによる効率化で少人数・高スキルチームが主流、ジュニアは「静かに採用されなくなる」傾向
  • 逆シナリオ：AIが非IT業界にも開発需要を拡大、AIネイティブなジュニアが新たな役割を担う
  • Bureau of Labor Statistics（米労働統計局）は2024-2034年でソフトウェア職15%増を予測
  • ジュニア排除の長期的リスク：リーダー人材の枯渇（スローディケイ現象）
  • 対応策
    • ジュニア：AI活用力・多能性の習得、AIツールで成果を出しつつ基礎理解を重視
      • AIに置き換えにくいスキル（コミュニケーション、課題分解、業界知識）強化
      • QA、DevRel、データ分析など隣接職種も視野
      • AI API連携プロジェクトのポートフォリオ作成
      • 即戦力志向でインターン・契約・OSS参画も検討
    • シニア：雑務増加への自動化活用、CI/CDやAIテストで負担軽減
      • ジュニア不在リスクを経営層に提言
      • ジュニア復活時の効率的なオンボーディング体制準備
      • チーム全体の生産性最大化に注力

2. スキルの変質問題

  • AIがコードの大半を書く時代に、基礎スキルが衰退するか、逆に重要性が増すか
  • 84%の開発者がAI支援を日常的に利用
  • 新人は「とりあえずAIに聞く」→基礎アルゴリズムやデバッグ力の低下懸念
  • スキル要求の変化：実装力からAIへの適切な指示・検証力へ
  • シニア層は「AIが見落とすバグやセキュリティリスクを拾える人材が必要」と指摘
  • 逆シナリオ：AIが定型作業を担い、人間は難題や設計に集中する「ハイレバレッジエンジニア」像
  • AI時代の差別化要素は「AIの誤りを見抜く力」
  • プログラミングの本質：レビュー・設計・セキュリティ分析重視へ
  • 対応策
    • ジュニア：AIを学習ツールとして活用、出力コードの理由や弱点を分析
      • 時にはAI無効化し基礎アルゴリズムを自力実装
      • **CS基礎（データ構造・アルゴリズム・メモリ管理）**の徹底
      • AIと手動の両方で同じ課題を解く比較学習
      • プロンプトエンジニアリングやツール習熟
      • テスト・デバッグ力の強化、AI依存しすぎない習慣
      • システム設計・UX直感・並行処理などAIが苦手な領域も強化
    • シニア：品質・複雑性の守護者としての立ち位置
      • 設計・セキュリティ・スケーリング・ドメイン知識の深化
      • AI生成コードの脆弱性把握、システム全体設計力
      • メンタリング・レビュー役割の強化
      • AI利用範囲と人間レビュー必須領域の明確化
      • 創造的・戦略的業務へのシフト、AI+ジュニアに定型作業を任せる
      • ソフトスキル・他分野知識・新ツール習熟も重視

3. 開発者ロールの変化

  • 開発者の役割が「AI監査官」へ縮小するか、「AI駆動システムのオーケストレーター」へ拡大するか
  • 一方ではAI生成コードのレビュー・管理業務が中心になり、創造性が減少
    • ノーコード・市民開発者の台頭で人間は「チェック役」に
    • コード作成の楽しみ＜リスク管理のストレスという声も
    • 「コードの掃除屋にはなりたくない」との嘆き
  • 逆に、開発者が技術・戦略・倫理を担う高次オーケストレーターへ進化する未来
    • AIワーカーを指揮する建築士・プロダクト戦略家的役割へ
    • 複数AI・サービスを組み合わせる設計・統合力が重要
    • AI時代の開発現場は創造性・横断的思考が求められる
  • どちらの道を辿るかは**企業のAI導入方針（労働代替 vs. チーム強化）**次第
  • 対応策
    • ジュニア：コード以外の役割にも積極的に挑戦
      • テストケース作成、CIパイプライン構築、監視など監査・運用スキル習得
      • 個人開発で創造性を維持
      • システム全体思考（API設計、コンポーネント連携）を磨く
      • AI・自動化ツールの幅広い知識（オーケストレーションフレームワーク等）
      • ドキュメント作成・説明力強化
      • 設計・検証・コミュニケーション能力を伸ばす
    • シニア：リーダー・アーキテクトとしての責任強化
      • AI・ジュニアが従う標準・フレームワークの策定
      • コード品質・AI倫理指針の整備
      • AI生成ソフトのコンプライアンス・セキュリティ最新動向把握
      • システム設計・サービス統合の専門性強化
      • 失敗パターン・リスク分析力の向上
      • チーム・組織の知識伝承と育成への貢献

Hackerたちの意見

私の経験では、LLMはコーディングを自動化するんじゃなくて、ただスピードアップするだけだね。解決策がどうなってほしいかは分かっていて、それをLLMに説明する感じ。だいたい特定のコードブロックごとにやって、ブロックごとに組み立てていく。ハッカーニュースを読むと、みんなもっとすごいことをしてるみたいに話してるけど、私には全然自動化ツールに感じられない。結局、自分がやりたかったことを手助けしてくれるだけで、ライブラリの関数呼び出しや言語特有の構文を調べる手間が省けるって感じ。
└
私にとっては、より良いGoogleだね。AWSやStackOverflowを検索する代わりに、十分な出力を幻覚のように出してくれて、それをリファクタリングして使える。
└
> 私の経験では、LLMはコーディングを自動化するんじゃなくて、ただスピードアップするだけだね。これが、私の知っているほとんどの人が実際にLLMを使っている方法だよ。バイブコーディングやLLMがエンジニアを置き換えるって話は、本当に有益な議論から目をそらさせる大きな distraction になってる。HNでLLMについて話すのはほぼ不可能だよ、みんながバイブコーディングのストローマンを攻撃するのに忙しいから。
└
大規模なシステムでたくさんのマイクロサービスを扱うのと、自分のために小さなアプリやツールを作るのでは、すごい違いを感じる。大規模システムの作業はあなたが言ってる通りだけど、小さなアプリやツールでは自動化コーディング派に共感する。いくつかのものをエンドツーエンドで作ったけど、そのツールやアプリが私の望むことをしているか確認できたし、LLMが書いたコードの一行も見てない。最初にそれが起こったときはちょっと気味が悪かったけど、日常の多くの仕事では本当に使えるワークフローじゃないね。
└
私は両方やってるよ。気に入ってるプロダクションコードでは、LLMが書いたすべての行を読んで、たくさん修正してる。観察者のLLMとチャットしながら、最初のLLMと私が書いているものをチェックしてもらってる。スピードアップしてるし、物事を始めるときの摩擦も減ってる。確実に時間の節約になってるね。それから、コードの品質を気にしない非トリビアルなサイドプロジェクトもあって、そっちはただ動かしてる。コードを見ようとしたら、繰り返しが多い。最初からうまくいくことはほとんどないけど、それは大丈夫。うまくいかないって言ったら修正してくれるし。多分セキュリティホールだらけで、コードも汚いけど、私がやりたいユースケースには関係ない。ここで作ったソフトウェアは、私の生活を良くしてくれてるし、ほとんど監視なしで進められた。
└
LLMは、使っているプログラミング言語の上位レベルの言語だと思えばいいけど、カジュアルで曖昧な文法なんだよね。
└
自分はその中間くらいかな。LLMが出る前は、気が散るサイトをブロックするために、/etc/hostsファイルにエントリーを追加して、それを127.0.0.1にマッピングしてた。さらに、そのファイルを不変にして、サイトを解除するのに手間がかかるようにしてたんだ。次のステップは、cronジョブを書いて、5分ごとにchattr +1を再適用してファイルを書き換えることだった。ちょっとした強制力みたいな感じ。これをClaude（ウェブ）で書いて、bashの文法を覚えては忘れてたから、コピペしたんだ。もっと強力なものが欲しくて、pluckeyeみたいな公開されてるものを見たけど、思ったようには動かなかった。それで、Claude（ウェブ）を使って簡単なバージョンを書いて、動かし始めた（2025年10月）。これで自分の問題が解決したんだ。aiderを使うプログラムが欲しくて、これから始めた。毎回、機能が必要になるたびに（例えば、一時的な解除、改ざん防止、アンインストール防止、ブラウザでのブロック、違反追跡など）、自分が欲しいことを書き出して、エージェントにやらせてた。数ヶ月で、約4000行（単一ファイル）に成長した。12月頃には、aiderからClaudeコードに移行して、引き続きやってた。大きなタスクは、コードを小さなファイルにリファクタリングして、コンテキストを管理しやすくすることだった。これも上手くやってくれて、テストも追加してくれた（2025年12月末）。さまざまなソースからブロックするURLを更新するためのヘルパースクリプトも追加した。バイブコーディングもした。問題なく動いた。その後、初期にやった粗いミスでメモリを食ってるのを見つけて、修正した。これに約2ドルかかった（2026年1月）。それから、違反の閾値を超えたときに画面をロックする機能も追加した。これにはXlibのコードを書く必要があった。自分でも書けたと思うけど、あんまり意味がないからやらなかった。何をすべきかは分かってるし、手でやってもライブラリの内部構造を知るくらいしか学べないから。それを追加した。要するに、これは98%がAIでコーディングされてるけど、自分の問題を本当に解決してくれて、コンピュータの前での行動を変える手助けをしてくれた。自分の調査では、Linux向けにこれをサービスとして提供している会社は見つからなかった。何をすべきかは分かってるけど、書いたりデバッグしたりする時間がない。AIのおかげで、自分の問題が解決されて、かなり価値のあるものを手に入れた。だから、あなたに同意するけど、「自動化ツール」ではないにしても、環境にもたらすスピードと深さが、以前にはなかった可能性を開いてくれた。それが本当の価値で、全体を探求するための窓なんだ。
└
知ってるのは、従業員の半分を解雇して、今後エントリーレベルの人を雇わない方が、次の四半期にボーナスがもらえるってことだけ。この記事が2年後のことを話してる理由はよくわからない。だって、それはお金や権力を持ってる人が気にする時間の8倍も長いから。
└
ジュニアに対する最高のアドバイスは「AIを使うな！」だね。著者がAIを使ったジュニアがチーム全体の「成果」に匹敵すると考えてる理由がわからない。もしコードの行を生成することを指しているなら、それは技術的負債のことだよ。画面にたくさんの言葉を並べることがプログラミングの成果じゃない。大抵は、自分の能力を完全に超えてるってことだよ。
>> スキルセットは、アルゴリズムを実装することから、AIに正しい質問をする方法やその出力を検証することにシフトしている。問題は、検証だけの方が手作業でコードを書くよりどれだけ速いかってこと。自分でコードを書くと、たくさんの理解が得られるし、理解は検証の前提条件だからね。アイデアとしては、簡単なレビューだけで「LGTM」ってのが必要だと思われてる。それは、自分がどんなトレードオフをしているか理解していれば大丈夫。今のAIでは、スピードと正確性をトレードオフするか、もっと控えめ（かつプロジェクト特有）な生産性の向上を受け入れなきゃいけない。
└
レビューの部分でショートカットを取る人間のインセンティブがめっちゃあるよね。プロセスが警戒心を緩めさせる感じで、コードを書いてる間に実際に観察する時間が減るし、大きなコードの塊がドンと来るし、イテレーションがすごく変わるから頭の中のモデルを維持するのが難しい。スピードアップの期待もあって、レビューの質が悪くなるのは目に見えてるよ。
COBOLから離れられない人たちの話が面白いね。私の隣人は銀行で働いていて、毎日COBOLでプログラミングしてる。14年前に引っ越してきたとき、彼らがどれくらい続けられるか気になったけど、今もやってるよ。
└
市場は、あなたが持続可能でいるよりも非合理的でいられる。
今、ジュニアができる最も有用なことは、AIを使って新しいスキルの基準に素早く追いつくことだ。めちゃくちゃ学べ。自己学習はAIによって強化される。エンジニア > デベロッパー > コーダー。
└
科学者 > エンジニア > デベロッパー > コーダー
└
それはちょっと夢見がちすぎるね。ほとんどのジュニアは気にしないで、ただ雰囲気でコードを書いていくと思う。痛いことをやるのは、楽な方法があるなら、余計な自制心と意志力が必要だよね。
└
AIは、個人的な常時稼働のティーチングアシスタントとしての可能性がすごくあるよね。学ぶときの摩擦を減らす「イントロスキップ」ボタンみたいなもんだし。バグが出たら、時間をかけて解決するより、さっと聞けばいいし。プロジェクトをゼロから始める方法がわからない？スキャフォールディングを頼めばいい。最初の上司がチケットを求めたら？失敗しないように機械に渡すのがベストだよね。そういう誘惑を避けられれば進めるけど、成功する人がどれだけいるかはわからない。それに、同僚が5倍のスピードで進んでる中で、ゆっくりする余裕があるのかも疑問だし。現代の生活はあまり希望を与えてくれないよね。みんな料理の摩擦を避けるためにウーバーイーツを使ってるし、クラブの気まずさを避けるためにティンダーを使ってるし、そういう感じ。摩擦がない方が勝つ傾向があるよ。
└
雇用主はスキルに基づいて採用するって有名だよね。資格や存在なんかじゃなくて。
ソフトウェアがなくなったら、すべての文書化された知識分野は消える。そうなったら、文書化されていないものが文書化され、それも消える。ジュニア開発者への最良のアドバイスは、ロボットが完璧に動く前に、実際の仕事を手に入れることだ。そうしないと、人間は水っぽい肉の塊になってしまう。
└
自分としては、初代ロボット配管工や電気技師の antics を楽しみにしてるよ。
> 逆のシナリオ：AIがあらゆる業界で開発者の需要を大きく解放する、テクノロジーだけじゃなくて。医療、農業、製造業、金融もすべてソフトウェアと自動化を組み込むようになる。これにはちょっと信じがたいな。ソフトウェアはすでにこれらの業界に大量に存在していて、仕事を置き換えてる。最後のステップは完全自動化（例えば、ハブで積み込み、自分で畑に行って散布するドローントラクター）だけど、そのボトルネックは「もっとコードが必要」じゃなくて、AIが解決できない現実の問題だと思う（特に政治的な）。
└
ヨーロッパでは需要が増える可能性が高いと思う。ソフトウェアの依存をリスクヘッジする必要があるし、ドイツはコンピュータを使わなきゃいけない。ドイツはすごく盛り上がると思うよ。
└
同意だね。人々はLLMが参入障壁を大幅に下げるずっと前から、ソフトウェアに過剰に焦点を当てることを心配してた。
> シニア開発者：ジュニアが減ると、もっと雑務が自分のところに回ってくる。これには同意できないな。今、シニアとしての自分の仕事はジュニアのコードをレビューすることだけど、ジュニアの代わりにAIが来たら、AIのコードをレビューすることになる。ほぼ同じことだと思う。
└
> だいたい同じことだね。むしろ悪化してる。AIは責任を全然持たないから。
└
ジュニアたちはこのプロセスを通じて、私のチームが求める理想に近づいていくよ。今のAIは、同じようにはいかないけどね。
└
現在、ジュニアとしての仕事は、シニアが「書いた」バイブコードをレビューすることなんだ。ほんとにクソみたいなもので、僕が学校の1年目に犯さなかったようなミスをしてる。
正直、今の時点では全部が大きな賭けに感じる。スキルや教育、制度的なつながり、現在の雇用が安定した生活の基盤を保証するわけじゃないからね。この不安定さが始まる前にどれだけお金や社会的資本、借金を抱えていたかで、影響が大きく変わるよ。もし借金を返済して、家を買って、家族の生活を安定させたなら、これからの数年がどれだけ快適かを賭けてることになる。もし新卒で学生ローンがあって、家もなくて、社会的ネットワークもないなら、ほぼ命を賭けてるようなもんだよ。
└
若い頃の卒業生だった時は、今よりずっと安全だと感じてた。今は子供を養わなきゃいけないから、最高の仕事のチャンスがある場所に引っ越すこともできないし、節約のためにレンズ豆だけで生活するなんて無理だし。
└
経済的独立を目指して頑張れ。始めるのに最適な時期はキャリアを始めた時、次に良い時期は今だよ。
> 結論：ジュニア開発者の採用は、AIがエントリーレベルのタスクを自動化することで崩壊するかもしれない。もしAIが今日からエントリーレベルのタスクを自動化したら、それは「エントリーレベル」という言葉の意味が変わるだけだよ。エントリーレベルがなくなるわけじゃない。今のエントリーレベルは変わるけど、一般的なエントリーレベルは残る。
この質問に対する分析の中では、かなり良い方だと思う。楽観的な見方をすると、ソフトウェアがもっと多くのニッチに浸透する可能性があるけど、それが雇用市場にどう影響するかはわからない。つまり、ソフトウェアとソフトウェアエンジニアの需要が、追加のソフトウェア需要のために少し切り離されるかもしれない。
└
今のところ、雇用市場は一時的にしか影響を受けないって確信してる。これは結局、別の形の自動化で、物事を早く進めるだけなんだよね。今は、もっとカスタマイズされたソフトウェアを、より早く安く作れるようになった。市場もその事実に気づき始めてるし、性能が高くてオーダーメイドのソフトウェアを、低コストで求める声が増えてる。ソフトウェアデザインの主要な課題を理解して、うまくコミュニケーションが取れる人は、これからも引っ張りだこだと思うよ。