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

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

2026年1月12日原文(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年前に引っ越してきたとき、彼らがどれくらい続けられるか気になったけど、今もやってるよ。

Hacker Newsで議論の続きを見る