arclamp

ITアーキテクト 鈴木雄介のブログ

AI駆動開発で、なぜミドルエンジニアは不安になるのか ── AIによる分業の終わりと始まり

AI駆動開発が「使える」となってきたことで、20代後半から30代中盤のミドルエンジニアが疲弊しているという話を聞きました。たしかに、エンジニアの中でも「AIは楽しい・これでもっと良くなる」という意見と「不安だ・これからどうなるのだろう」という意見に分かれているようです。

私の周りでは、特にベテランが楽しんで、ミドルが不安になっているような構図を感じています。

この記事では、システム開発における30年間の分業と統合の歴史を振り返りつつ、それぞれの世代が何を経験してきたのかを整理します。そのうえで、AI駆動開発が既存の分業をどのように統合しようとしているのかを見ていきます。そして、これがベテランとミドルの違いに、どのように影響しているのかを考えます。

最後には、AI駆動開発が「分業の終わり」ではなく、AIを前提にした「新たな分業の始まり」でもある、という見方を提示します。

この30年の歴史を振り返る

世代の違いを考えるには、まずこの30年のシステム開発史を、ひとつの流れとして見ておく必要があります。細かな技術の流行はいろいろありますが、大きく見ると、分業と統合を繰り返してきた歴史だったと言ってよいでしょう。

  • 1995〜2005年 <未分化>Webシステムの創成期
  • 2005〜2010年 <分業>統制と責務分離
  • 2010〜2015年 <統合>クラウドとDevOps
  • 2015〜2020年 <分業>マイクロサービスによる分散化
  • 2020〜2025年 <統合>プラットフォームによる基盤整備
  • 2025年~ <??>AI駆動開発

(なお、私の専門は企業システムなので、ウェブ業界からみると、ズレている部分もあります)

1995〜2005年 <未分化>Webシステムの創成期

  • インターネット、Webシステム、ブラウザ、3層アーキテクチャ

この時期は、Webシステム開発そのものが立ち上がっていった時代です。役割も技術もまだ固まりきっておらず、何をどう作るのか、どう運ぶのかも含めて、現場ごとの差が大きかった。今から見れば混乱期ですが、裏を返せば、まだ何でも自分たちでやることができた時代でもあります。筆者も、データセンターまでサーバを運んで、物理の電源ボタンを押したことがあります。

2005〜2010年 <分業>統制と責務分離

  • ISMS、ISO/IEC 27001、内部統制、J-SOX

2000年代後半になると、統制の観点から、システム開発は堅苦しくなっていきます。責務分離や権限管理が重くなり、企画、開発、インフラ、運用のように役割を分けること自体に意味が出てきました。監査や統制のために強制的な分業を強いられる時代でした。

2010〜2015年 <統合>クラウドとDevOps

  • クラウドコンピューティング、IaaS、PaaS、DevOps、Infrastructure as Code

2006年に「クラウド」という言葉が使われるようになり、2010年代になると企業システムでの利用が始まります。仮想化が前提になることで、インフラ構築作業がソフトウェア化され、自動化されていきます。これにより、アプリとインフラが統合されていく時代になっていきます。

2015〜2020年 <分業>マイクロサービスによる分散化

  • マイクロサービス、CNCF、Kubernetes、Docker、React、フロントエンドエンジニア、API、SRE

この時期は「標準化の否定」による分業が進みました。マイクロサービスは、1つのシステムを作り上げるのに分散した技術と組織を推奨しました。また、1つ1つの技術分野が高度になり、エンジニアとして活躍するためには高い専門性が必要になります。あえてフルスタックエンジニアという言葉が生まれたように、全部の技術分野を深く理解するのが困難になっていく時代です。

2020〜2025年 <統合>プラットフォームによる基盤整備

  • プラットフォームエンジニアリング、IDP、デベロッパーエクスペリエンス、ゴールデンパス、ガードレール

しかし、分業と専門化が進みすぎると、その複雑さをエンジニア個人に背負わせ続けるのが難しくなります。そこで出てきたのが、プラットフォームによる統合です。共通基盤を整備することで複雑さを吸収し、エンジニアは、その前提で開発を行うようになります。

2025年~ <??>AI駆動開発

  • コーディングアシスタント、AI駆動開発、マルチエージェント

そしてAIが登場しました。AIは、これまで人間が実施していた「仕様からコード」への変換作業そのものを代替するようになりました。特に2025年以降は「AIエージェントに開発させる」というスタイルが広がりつつあります。

世代の定義

こうした中で、各世代を類別してみます。年齢は2026年時点を基準にしています。ちなみに筆者はベテランです。

  • ベテラン(1980年以前生まれ/45歳以上)
  • シニア(1981〜1990年生まれ/36〜45歳)
  • ミドル(1991〜1998年生まれ/28〜35歳)
  • ジュニア(1999年以降生まれ/27歳以下)

ベテラン(1980年以前生まれ/45歳以上)

ベテランは、この流れをほぼ通しで見てきた世代です。インターネットの立ち上がりから、新たな技術によって分業と統合が繰り返される中で生き残り、それらを連続した変化として捉えやすい立場にあります。

シニア(1981〜1990年生まれ/36〜45歳)

シニアは、統制が強い時代から実務に入り、クラウド以降の再編を中核で経験してきた世代です。分業が強かった時代も知っているし、その後の統合や専門化も知っている。便利さと複雑さの両方を、かなり実感として持っている世代です。

ミドル(1991〜1998年生まれ/28〜35歳)

ミドルは、クラウドやDevOpsが前提化した世界でキャリアを始め、分業され、専門化した技術世界の中で主力になった世代です。マイクロサービス、CNCF、フロントエンドの独立といった流れを、後から来た変化というより、最初から向き合うべき前提として経験しています。そういう意味で、分業の世代の中心にいると言ってよいと思います。

ジュニア(1999年以降生まれ/27歳以下)

ジュニアは、プラットフォームやAI支援がすでに存在する状態から入ってくる世代です。過去の変化を転換として経験したというより、変化後の世界を最初から受け入れる形でキャリアを始めています。

AIが、分業された役割を統合する

AIを活用したシステム開発は、ここ1〜2年で使い方が明確に変わってきています。

以前はコード補完やクラス生成といった支援が中心でしたが、現在はAIエージェントを開発チームとして扱い、「この機能を実装してほしい」「このタスクを解決してほしい」といった単位で仕事を委譲する使い方に変わりつつあります。

Claude Code のようなエージェント型の開発環境では、役割を分けたサブエージェントを定義し、開発チームのように扱うことができます。たとえば、

  • Architect(設計)
  • Implementer(実装)
  • Reviewer(コードレビュー)
  • Tester(テスト設計)

といった役割のAIエージェントを用意し、それぞれが設計、実装、レビュー、テストを担当します。

AIエージェントに、人間の開発チームと同様の役割を与えることには、2つの意味があります。

1つ目は、AIエージェントの挙動が安定することです。
LLMは、やりとりの文脈から「どの立場で答えるべきか」を推定します。設計、実装、レビュー、テストのように前提が異なる役割を同一の文脈で扱うと、判断の基準が混ざりやすくなります。実装では前に進むことが重要ですが、レビューでは疑うことが重要になります。このように異なる前提が必要な場合は、役割を分けた方が出力は安定します。

2つ目は、人間が出力を評価しやすくなることです。
AIエージェントに与える役割は、現実の分業構造に対応しており、それぞれの役割が何を担うべきかという基準があります。なので、人間からみても、それぞれの出力を評価やすくなるのです。

これはAIが、歴史の中で分業されてきた役割を統合しようとしているとも表現できるのではないでしょうか。

楽しむベテランと、不安になるミドル

では、このようなAI駆動開発を、エンジニアはどのように受け入れているのでしょうか。単純な世代論にすべきことではありませんが、あえて、ベテランとミドルの違いに注目して考えてみます。

楽しむベテランエンジニア

私の周りでも、同世代のベテランエンジニアが嬉々としてAI駆動開発に取り組む姿を見ることが増えました。そのたびに同じ質問をしています。

「コードを書くのがあんなに好きだったのに、AIにコードを書かせてつまらなくないの?」

大抵のベテランは「楽しい」と答えてくれます。代表的な答えは、以下のようなものです。

  • 「表現が変わっただけだよ」
  • 「作る楽しみは変わらない」
  • 「一人でやれる範囲が増えた」
  • 「誰かにお願いしなくていいのがよい」
  • 「AIと話しているとペアプロみたいで楽しい」

ベテランは、インターネット以降の変化をほぼ通しで見ています。技術によって、自分たちのやってきたことが、少しずつ抽象化され、自動化され、ある部分が便利になり、別の側面で複雑さが増していく。その歴史を超えても生き残っているベテランエンジニアは、AIについても「また、面白い技術が出てきたぞ。今度は、どこが便利になって、どこが複雑になるんだ?」と考えやすいのでしょう。

ベテランには、AIが「人間の仕事を奪うもの」というより、「これまで分業化されてしまった作業を、もう一度自分の手元に引き寄せる技術」として見えやすいのでしょう。

不安になるミドルエンジニア

一方で、ミドルはクラウドやDevOpsが前提化した後にキャリアを始め、分業化され、専門性の高い技術分野の中で主力になってきた世代です。つまり、彼らにとっては「分業と専門化」が後から来たものではなく、最初から仕事の前提でした。フロント、バック、あるいはインフラと、自分の専門領域を深く持ち、その中でコードを書き、レビューし、品質と速度を担保することが、チームの中での存在意義と強く結びついてきた世代です。

ここにAIが入ってきます。AIが入り込んできたのは、まさにミドルが日々価値を出してきた専門領域です。自分と同じ役割を名乗るAIエージェントが、自分よりも高速にコードを書き始めてしまうのです。

ここでミドルエンジニアが感じるのは「自分がチームにいる意味」の揺らぎではないか、と感じています。ベテランにとっては自分の範囲を拡げられるものに見えるものが、ミドルには、自分の担当領域を代替してくるものに見えやすい。プライドを持って専門性に取り組んできたミドルエンジニアであるほど、この構図が、AIに対して複雑な受け止め方を生みだすのではないか、と考えています。

AIを前提にした、新たな分業の始まり

この30年、システム開発は分業と統合を繰り返してきました。そして今、AIによって、分業された役割そのものが統合されようとしています

その結果、ミドルエンジニアが感じている不安は、これまで価値を出してきた領域そのものが、AIによって直接的に代替されることから起きていると考えています。たしかに、大きくエンジニアの役割が変わっていくでしょう。

これから起きるのは、

  • どこをAIに任せるのか
  • どこを人間が担うのか
  • その境界をどう設計するのか

という、新たな分業の姿です。AIが既存の役割を担うことを前提に、人間が新たな役割を担っていくのです。

どの世代のエンジニアであれ、積み上げてきた知識や経験は、この新たな分業への転換に活用できるはずです。AIは、専門性を不要にするのではなく、専門性の使いどころを変えているだけなのだと思います。

AIを前提にした開発は、すでに避けて通れないものになりつつあります。どうせ向き合うなら、その変化を、少しでも自分の側に引き寄せていきたいですね。