AIという「部下」がやってきた――技術の逆流を目の当たりにした組織はAIについていけるのか

はじめに

生成AIによって、プログラマーの仕事は大きく変わり始めています。

AIにコードを書かせることで、これまで人間が時間をかけていた実装を短時間で行えるようになりました。

その結果、

「AIを使えば、プログラマーを減らせるのではないか」

という考え方も出てきます。

しかし、私はここに一つの疑問があります。

コードを書く人間を減らせば、それだけで組織はAI時代に対応できるのでしょうか。

むしろ、これまでプログラマーを指揮してきた管理職自身が、急激な技術の変化に対応する必要が生じているのではないでしょうか。

これは、単純な「AIによる雇用削減」の話ではありません。

AIによって、組織の技術知識の流れそのものが変わり始めているのではないか。

私はそう考えています。

これまでの「上司と部下」

従来のソフトウェア開発では、ある程度単純な技術知識の上下関係がありました。

若いプログラマーは、先輩から技術を学びます。

先輩はさらに上の先輩から学び、経験を積み、やがて管理職になります。

管理職になった後は、自分が現場でコードを書く量が減っても、それまでに蓄積した経験を使って部下を指揮できます。

もちろん、すべての組織がそうだったわけではありません。

しかし、

「上司は部下より多くの経験を持っている」

という関係は、比較的成立しやすかったのではないでしょうか。

そして、技術の変化が比較的緩やかな環境であれば、過去に積み上げた経験が長期間にわたって役に立つこともあります。

これは決して悪いことではありません。

長い経験には、それだけの価値があります。

問題は、技術の変化する速度が、その経験の更新速度を上回ったときです。

ところが「AIという部下」が現れた

ここで生成AIが登場します。

AIに、

「この処理を書いて」

と頼めば、コードが出てきます。

さらに、

• 「このコードを高速化して」

• 「別の設計方法は？」

• 「このエラーの原因は？」

• 「このライブラリを使う場合の問題点は？」

と質問することもできます。

AIは、特定の人間が長い年月をかけて身につけた経験とは別の形で、非常に広い範囲の技術知識を扱うことができます。

ここで、従来の「部下」とは違う存在が現れました。

これまでの組織では、

自分より経験の浅い部下を指揮する

という構造が比較的自然でした。

ところがAIは、

自分では把握しきれないほど広い技術知識を持つ可能性がある存在を、部下のように使う

ことができます。

AIを「部下」と呼ぶことに違和感があるかもしれません。

しかし、実際に人間の仕事の一部をAIに置き換え、AIにコードを書かせ、AIに作業を指示する状況が広がっています。

すでに「AIを使う人間」と「AIが行う仕事」の境界は大きく変化しています。

「技術の逆流」が起こる

ここで、これまでとは違う現象が起こります。

従来の技術知識の流れは、

上司・先輩
↓
部下・後輩

でした。

ところがAIを使うことで、

AI
↓
部下
↓
上司

という流れが生まれます。

部下はAIを使って新しい技術を調べます。

AIにコードを書かせます。

AIに設計方法を尋ねます。

そして、その結果を上司に説明します。

場合によっては、

「AIに確認したところ、この方法のほうが適しています」

という会話さえ成立します。

これは単なる「AIによる生産性向上」ではありません。

技術知識の流れが変わっているのです。

私はこれを、 「技術の逆流」 と考えています。

プログラマーを減らすことが、管理職の負担を減らすとは限らない

ここで、

「AIがコードを書けるなら、プログラマーを減らせる」

という議論が出てきます。

確かに、AIによって実装の速度が上がり、必要な人数が減る仕事はあるでしょう。

しかし、

プログラマーが減ることと、技術的な判断が不要になることは同じではありません。

AIが大量のコードを生成するようになれば、

• そのコードは正しいのか
• 要件を満たしているのか
• 保守できるのか
• セキュリティ上の問題はないか
• 将来変更するときに困らないか
• 他のコードと矛盾していないか

といった判断が必要になります。

実際、AIによってコード生成が増える一方で、レビューや検証が新たなボトルネックになっているという調査もあります。

つまり、

「コードを書く仕事」が減っても、「コードを理解する仕事」まで消えるとは限らない。

ということです。

さらに「AIブーム」と「人件費削減」が追い打ちをかける

AIには、もう一つ厄介な側面があります。

それは、AIが単なる技術ではなく、大きな流行にもなっていることです。

「AIを導入しなければならない」

「AIで生産性を上げなければならない」

「AIを使えばプログラマーを減らせる」

という話が先に進むと、技術的な検証より経営上の判断が先に来てしまう可能性があります。

そこに人件費削減が加わります。

すると、

プログラマーを減らす
↓
AIを導入する
↓
AIにコードを書かせる
↓
残った人間で管理する

という構造が生まれます。

しかし、その「残った人間」がAIによって持ち込まれる技術の変化についていけなかったら、どうなるでしょうか。

過去の経験が長く通用する環境から、急激な変化へ

ここで問題になるのが、管理職がどのような環境で経験を積んできたかです。

安定した環境で長期間働き、経験を積み重ねることには大きな価値があります。

しかし、過去の経験が長く通用する環境では、

「これまでこうしてきた」

という経験が、そのまま判断基準になりやすい。

それ自体は悪いことではありません。

問題は、技術の変化速度が突然変わった場合です。

AIは、人間の世代交代を待ってくれません。

若手が育つのを待つこともありません。

管理職が新しい技術を少しずつ学ぶ時間を待つこともありません。

AIを導入した瞬間から、組織に新しい技術が流れ込みます。

そのため、これまで長い時間をかけて積み上げてきた技術経験を持つ管理職ほど、逆に急激な技術アップデートを迫られる可能性があります。

管理職にも急激な技術アップデートが必要になる

私はここが、この問題の最も重要な部分だと思っています。

AIによってプログラマーの仕事が変わる。

それだけではありません。

プログラマーを管理していた人間の仕事も変わります。

AIが生成したコードを理解する必要があります。

AIに適切な指示を出す必要があります。

AIが間違っていることを判断する必要があります。

そして、

AIが提示した新しい方法を、自分の過去の経験だけを理由に否定しないこと

も必要になります。

これは、管理職にとってかなり大きな技術アップデートです。

ところが、現在語られているAI導入の議論では、

「プログラマーがAIを使えば生産性が上がる」

という話に比べ、

「そのAIを使う組織の管理職は、どれだけ技術を更新しなければならないのか」

という問題は、まだ十分に注目されていないように思います。

AIはオブジェクト指向を露骨に導入する

ここで、もう一つ問題があります。

これまでの開発では、管理職や上級者が設計を決め、プログラマーがそれを実装するという役割分担がありました。

つまり、

上司：設計を考える
↓
部下：コードを書く

という関係です。

ところがAI時代には、この関係が変わります。

上司がAIに、

「この要件を実現する設計を考えて、コードを書いてください」

と指示すれば、AIは設計から実装まで一気に返してきます。

AIにコードを書かせていると、非常に露骨にオブジェクト指向的な構造を持ち込んでくることがあります。

• クラスを作る。

• インターフェースを作る。

• 責務を分割する。

• 継承やデザインパターンを使う。

もちろん、それが適切な場合もあります。

私は、オブジェクト指向が正しいとも、手続き型が正しいとも考えていません。

問題はそこではありません。

AIが何で書くかではなく、AIが返した設計を上司が判断できるのか。

ここに大きなギャップがあります。

これまでなら、上司が設計を作り、部下が実装する。

しかしAI時代には、

上司：設計を要求する
↓
AI：OOP的な設計・実装を返す場合がある
↓
上司：その設計を評価する

という構造になります。

つまり、上司は「設計者」であると同時に、AIが返してきた設計のレビューアにもならなければなりません。

しかも、AIは上司が経験したことのない技術や設計方法を提示する可能性があります。

ここで、

• 「クラスがあるからオブジェクト指向だ」
• 「インターフェースがあるから設計として正しい」

という判断しかできなければ、AIの出力を評価することはできません。

必要なのは、

「なぜAIはこの設計にしたのか」

を理解する能力です。

AIがコードを書く時代には、設計者に求められる能力も変わります。

設計を作る能力だけではなく、AIが作った設計を理解し、評価し、必要なら否定できる能力が必要になる。

そして、この能力を管理職が急激な技術の変化の中で身につけられるのか。

私は、ここがAIによるプログラマーの置き換えを考えるうえで、まだ十分に議論されていない問題だと思っています。

AIは技術の変化を加速する

AIの登場によって、技術の変化そのものが速くなっているのではないでしょうか。

人間だけで新しい技術を学び、実装し、経験として蓄積する場合、変化にはどうしても時間がかかります。

しかしAIを使えば、

調べる
↓
試す
↓
実装する
↓
修正する

というサイクルを非常に速く回せます。

そのため、AIを使える人間と、AIを十分に使えない人間の間でも、技術の更新速度に差が生まれる可能性があります。

そして、その差は必ずしも「若手だから」「ベテランだから」という単純なものではありません。

AIによる技術の逆流を受け入れられるかどうか

が重要になります。

人件費削減だけでは、この問題は解決しない

AIによって人件費を削減できる可能性はあります。

しかし、人を減らせば減らすほど、残った人間一人あたりの判断責任は大きくなります。

AIがコードを書く。
↓
AIがテストを書く。
↓
AIが修正案を出す。
↓
AIが設計案まで提示する。

そうなったとき、

「誰がそれを採用してよいと判断するのか」

という問題は残ります。

そして、その判断をする人間が技術的な変化についていけなければ、AIによって増えた実装能力を組織が十分に利用できない可能性があります。

AI生成コードについて、技術的負債やセキュリティ、保守性への懸念が報告されているのも、この問題と無関係ではありません。

おわりに

AIは、単にプログラマーの仕事を奪う技術ではないのかもしれません。

むしろ、

組織の技術知識の流れそのものを変える技術

なのではないでしょうか。

これまで、

上司・先輩
↓
部下・後輩

と流れていた技術が、

AI
↓
部下
↓
上司

という形で逆流する。

そして、その逆流によって、これまで過去の経験をもとに管理していた人間にも、急激な技術アップデートが求められる。

しかし現在のAI導入では、

「AIでプログラマーを何人減らせるのか」

という話が目立ちます。

私は、それだけでは不十分だと思います。

問うべきなのは、

「AIという、自分では把握しきれないほど膨大な技術知識を持つ『部下』が突然やってきたとき、私たちはそのAIについていけるのか？」

ということではないでしょうか。

そして、その問いの先には、もう一つの問題があります。

人間の世代交代を待たずに、技術だけが猛烈な速度で変化してしまったとき、組織はその変化に耐えられるのか。

AIによって起きているのは、単なるコード生成の高速化ではありません。

技術の流れそのものの変化です。

これまで上から下へ流れていた技術が、AIを経由して下から上へも流れ始めている。

私たちは、この 「技術の逆流」 に、組織としてどう対応するべきなのでしょうか？