「コードを書くだけの仕事はなくなる」に感じる違和感

生成AIの話題になると「コードを書くだけの仕事はなくなる」とよく耳にします。でも私は、そんな仕事がもともとほとんど存在しなかったと考えています。実装は単なる入力作業ではなく、設計を検証し要件を見直す思考のプロセスだからです。AIが下げたのはコードを書くコストであって、エンジニアの本当の仕事——コードに至るまでの思考——はこれからも残る。そんな違和感を書いてみました。

「コードを書くだけの仕事はなくなる」に感じる違和感
Photo by Christopher Gower / Unsplash

生成AIの話題になると、「コードを書くだけの仕事はなくなる」という言葉をよく耳にします。

生成AIによってコーディングの効率が飛躍的に上がったのは間違いありません。それでも私は、この言葉を聞くたびに少し違和感を覚えます。「コードを書くだけの仕事」そのものが、もともとほとんど存在しなかったと思うからです。

実装工程は、そんなに純粋ではない

ソフトウェア開発の教科書には、要件定義・設計・実装・テストという工程が並んでいます。この図だけを見ると、実装とは設計書をもとにコードを書くだけの工程のように見えます。

しかし、現実の開発現場はそう単純ではありません。コードを書き始めると、「この設計では実現できない」「APIを少し変えた方が自然だ」「この仕様だと運用で困る」「こちらの方がユーザーに分かりやすい」——そんな発見が次々に生まれます。

つまり実装とは、単なる入力作業ではありません。設計を検証し、要件を見直し、より良い解決策を探す、思考のプロセスでもあります。

ウォーターフォールですら、実装は独立していない

「それはアジャイルだからでは?」と思う方もいるかもしれません。しかし私はそうは思いません。

ウォーターフォール開発であっても、実装中に設計書が修正されることは珍しくないからです。実際にコードを書いたからこそ、設計の矛盾に気付き、性能上の課題が見つかり、保守性に不安を覚え、よりシンプルな実現方法を思いつく。そうした発見のたびに設計者と相談し、ときには要件まで立ち返ります。

工程としては分かれていても、思考は分かれていないのです。むしろ「実装だけ」という工程がきれいに存在するのは、実験室や論文、教科書の世界くらいではないでしょうか。現実のソフトウェア開発は、工程同士を何度も往復しながら前に進んでいく営みです。

AIが変えたのは「コードを書くこと」ではない

では、生成AIは何を変えたのでしょう。私は、AIが変えたのはコードを書くコストだと考えています。定型的なコードは短時間で生成できるようになり、ボイラープレートを書く時間も減っていくでしょう。

しかし、「この設計は妥当か」「本当に解くべき課題は何か」「この実装で運用できるか」「将来の変更に耐えられるか」——こうした問いは残ります。そして、その答えを考えるために、私たちは実装という行為を続けます。

コードを書くことは目的ではない

現場で仕事をしていると、コードは目的ではなく手段だと何度も実感します。私たちが作っているのはコードではなく、ユーザーに価値を届けるシステムです。そのためにコードを書き、設計を見直し、議論し、試行錯誤する。

コードを書くことだけを切り出して「その仕事はAIに置き換わる」と語るのは、ソフトウェア開発という営みを少し単純化し過ぎているように感じます。

おわりに

生成AIがエンジニアの仕事を大きく変えていくのは間違いありません。しかし、その変化を語るときに「コードを書く」という一部分だけを見ていては、本質を見誤るのではないでしょうか。

コードは成果物ではあります。しかし、エンジニアの本当の仕事は、そのコードに至るまでの思考そのものです。だから私は、「コードを書くだけの仕事はなくなる」という言葉に少し違和感を覚えます。そもそも私たちの仕事は、昔から「コードを書くだけ」ではなかったのです。